[geos-devel] OverlayNG for Testing

[Paul Ramsey]

> On Jul 30, 2020, at 5:55 PM, Nyall Dawson <nyall.dawson at gmail.com> wrote:
> 
> On Fri, 31 Jul 2020 at 10:30, Daniel Baston <dbaston at gmail.com> wrote:
>>> 
>>> What are people's thoughts on this?  It is probably possible to build in the old behaviour (with a bit of coding effort), and make it the default path.  But I think the new behaviour is preferable and more sensible.
>> 
>> 
>> This behavior seems confusing to me, and I'm struggling to tell if it's just because I'm used to the old behavior. But it did occur to me that this introduces an inconsistency between the predicates and overlay functions wherein A and B may intersect at a point outside the intersection of A and B.
> 
> +1 This potentially opens the door for many hidden issues.
> 
>> It's also easy enough for a user to remove the unwanted components of the result
> 
> ... and every downstream project/user already had handling for this in place.
> 
> (and then just because this email sounds too negative -- this is
> seriously exciting stuff, and I'm really happy to see all this hard
> work land! Big kudos on all your efforts here)

No, this is great, and thank you Dan for articulating a more compelling reason to keep the old behaviour than "it's always been that way". I had not thought of consistency with the predicates and, yeah, that's really a good thing to have.

I just thought while at the gym that ST_CollectionExtract() could be made a smidge smarter to also have a one-argument variant that figures out the highest dimensionality component and return that, so getting the "nicer" behaviour would be just one extra function call, and involve no magic numbers.

On a similar note, Martin has recovered the old behaviour for linstrings in overlays so we should be able to be back-compatible there too. As with the collections, there's an existing mechanism to get "nicer" behaviour already, the ST_Linemerge function. 

My hope is that, if we do these pieces to get old semantics, we will just be left with adding in the Z handling and be very very close to original semantics, enough so that we can stamp it 3.9 instead of 4.0. I love backwards compatibility on principle.

P

> 
> Nyall
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel