[postgis-devel] Big New Functionality

[Regina Obe]

-1 for accepting this.  There are several things that bother me with this patch.

1) No code I can see, I don't want to be in the business of QA'ing someone's thesis (and in German?  I got to learn another language) which is what this sounds like it's going to be
2) The guy is too busy to continue forward with it, and for something this big that none of us want to maintain, and no prior reference for this guy's I'd much assume not bother

3) Most of the complaints geography these days are speed and for smallish areas geometry intersection is generally sufficient, if big is going to be even slower it's not worth it.
I can hear users now

"The answer was more accurate, but took longer to give than I had the patience for.  Fail."

Thanks,
Regina

-----Original Message-----
From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Paul Ramsey
Sent: Monday, January 08, 2018 9:03 AM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: [postgis-devel] Big New Functionality

So, I never expected anyone would show up with an overlay implementation for geography, but there it is.

https://trac.osgeo.org/postgis/ticket/3973

The trouble is, overlay is difficult and geography is even worse, insofar as segment intersection is a lot less stable in geography space than in planar space, so there's going to be a couple issues with this implementation for sure:

* it'll have failure modes for inputs that geometry handles fine
* I could be wrong, but eyeballing it I'd expect O(n^2) performance, so for large things it could be quite slow, even by the standards of geometry, since the intersection calculations are also much slower in geodetic space.

So, putting on my old fuddy duddy hat, I admit that Something is always in principle better than Nothing, while being concerned that we'll have a lot of support to do on this block of code.

In my heart of hearts, I guess I had always hoped/thought that geodetic support would come from a generalization of the 'edge'
concept in GEOS, so that the same graph structure currently used for relate/union/intersect could be used for geodetic operations.
Topologically, geodetic objects have the same structure as geometric ones, it's just the calculations of intersections and stuff are different, so it made sense that it should be possible to get a lot of GEOS functionality for "free" once the edge handling was generalized.
Part of that work would be a lot of experimenting and so on with making geodetic edge intersection more robust. (quad-double?)

Anyways, now there's a different avenue, and I'm wondering what you other fuddy duddies are thinking?

P
_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-devel