Dan Baston

The problem is that the GEOS "prepared" implementation is never invoked because the argument to `GEOSPrepare` is a `GeometryCollection`, not a `Polygon` or `MultiPolygon`. GEOS does not know that the...

That's a good point about "contains", though calling `GEOSPrepare` on a `GeometryCollection` is still a silent no-op for less complicated predicates like "intersects". I think that's a confusing result (as...

> How so? I had been thinking of just extracting the points, lines, and polygons from the `GeometryCollection` and implementing `PreparedGeometryCollection::intersects` as `PreparedPoint::intersects() || PreparedLineString::intersects() || PreparedPolygon::intersects()`. But with the...

> I am a bit surprised that your brute-force code is so much faster than the GEOS internal code, so maybe there is something awry with that code. I think...

> I had been thinking of just extracting the points, lines, and polygons from the GeometryCollection and implementing PreparedGeometryCollection::intersects as PreparedPoint::intersects() || PreparedLineString::intersects() || PreparedPolygon::intersects(). But with the current Geometry...

> I just got bit by this define deep down in CoordinateSequence: GEOS_COORDSEQ_PADZ which erroneously makes space for Z's, but then crucially, does not set hasZ! This is by design...

It doesn't have anything to do with helping someone trying to load 3D points. It has to do with incrementally fitting a variable-dimension capability into a 22-year old library that...

@rouault A challenge I'm finding with this is a pixel function has no good way (that I can see) to determine which sources actually overlap a given pixel. We have...

> we should probably initialize to the nodata value What if we don't have a NoData value? I was thinking of a non-standard NaN (this is how R handles `NA`,...

> What if we don't have a NoData value? I think we can just issue a warning. Providing the pixel functions with a mask seems too disruptive, and creating a...