feat: Add ST_LineMerge#78
Conversation
| // Assumptions: | ||
| // - No arrow arrays (record batches?) larger than 2GB. | ||
| // - A trip through WKB is probably the fastest path. The only other obvious option is using geo_types as an intermediate, | ||
| // but that is probably going to STILL require going out to WKB, since WKB looks to be the cheapest interchange format. |
There was a problem hiding this comment.
I believe these assumptions are valid, but flagging for extra visibility.
There was a problem hiding this comment.
Ideally this would be refactored into an external helper to manage the conversion from GeoArrow to GEOS and back. We have some of those helpers already here and here.
Ideally if you're interested, we'd also move the core of the the operation into geoarrow-rs so that it could be shared across other libraries and not just geodatafusion. You can see what I prototyped with geoarrow-expr-geo. I started geoarrow-expr-geos with the same idea, but haven't worked on it at all.
What do you think?
There was a problem hiding this comment.
Yeah, that'd be ideal! I'm sure we're going to hit this pattern a bunch, and I agree it'd be great if we can get this done the "right" way once in a reusable manner before we start cranking out other GEOS-backed UDFs.
There was a problem hiding this comment.
Cool; I haven't gotten back to this yet but probably will in the next week or so (unless you're already working on it). I think it belongs in geoarrow-rs long term too, and I've got at least one more function in my near-term needs that'll probably want GEOS so I'll try to work on that next.
|
Looks like GitHub Actions are stuck, but I think I've addressed all the feedback. |
| - name: Install dependencies | ||
| run: | | ||
| sudo apt-get update | ||
| sudo apt-get install -y libgeos-dev |

This adds
ST_LineMergevia an optional dependency on GEOS. A pair of features control the GEOS linking:geosuses the version available on the system, andgeos-staticbuilds + statically links the library.Fixes #77.