On Wed, Oct 5, 2022 at 7:56 AM Howard Butler wrote:
> In PDAL's (albeit unusual) usage, we pass through millions of points to do
> things like point-in-poly. Changing/copying data to fit GEOS' data
> arrangement starts to get really expensive, and for PDAL, we ended up doing
> our own PiP
Thanks for the context!
On Tue, 4 Oct 2022 at 17:17, Daniel Baston wrote:
> GEOS is pretty tied to the interleaved representation. LIke JTS, it uses
> Coordinate struct to pass around coordinates, with fields for X, Y, and Z
> values. If we wanted to support a separate-array representation,
> On Oct 4, 2022, at 10:15 AM, Daniel Baston wrote:
>
> - Allowing the use of an external buffer instead of the one managed by
> std::vector, so we could have a zero-copy method of bringing data into GEOS
> from an interleaved buffer
This.
In PDAL's (albeit unusual) usage, we pass
GEOS is pretty tied to the interleaved representation. LIke JTS, it uses
Coordinate struct to pass around coordinates, with fields for X, Y, and Z
values. If we wanted to support a separate-array representation, we'd
either need to either change our Coordinate struct to store pointers to the
X
We are currently having a discussion about interleaved (XYXY) vs separate
arrays (XX YY) in the GeoArrow context (
https://github.com/geopandas/geo-arrow-spec/pull/26), and I was wondering
if the GEOS developers have thoughts on that topic (whether it was ever
specifically discussed if the current
This has come up a few times and despite some pushback from users [1] I
agree that the benefits of the simplification probably outweigh the costs.
Replacing CoordinateSequence with a concrete implementation is top on my
list for the GDAL grant work [2] that I will be available to begin on
One of the things that tinkering with the SegmenString layer of overlay brought
out to me was the extent to which we construct CoordinateSequence almost
exclusively out of CoordinateArraySequence. Like, all the time. At yet, because
we handle those CoordinateArraySequence at the API level
