[postgis-devel] Coverage Functions

[Paul Ramsey]

Cc’ing over to geos-devel too

> On Apr 28, 2023, at 8:21 AM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> 
> 
> 
>> On Apr 28, 2023, at 7:18 AM, Sandro Santilli <strk at kbt.io> wrote:
>> 
>> On Tue, Apr 25, 2023 at 05:03:25PM -0700, Paul Ramsey wrote:
>>> The first coverage functions are ready to merge.
>>> 
>>> https://github.com/postgis/postgis/pull/731/files
>> 
>> As mentioned in chat, I'm thinking having a GEOSCoverage
>> datatype would be advisible here, with one constructor
>> taking a vector of Geometry pointer for now but eventually
>> getting more constructors.
>> 
>> Validation could be performed in the constructor itself OR
>> delegated to the validator function. Simplification could be
>> a method taking that datatype, and possibly return again a
>> (simplified) GEOSCoverage from which one could derive a single
>> GEOSGeometry as the current proposed return from the simplification
>> function.
>> 
>> I've the feeling there will be more coverage-related functions,
>> that's why I'm suggesting to have a datatype for it.
> 
> I used to think this too, but I changed my mind. I made “logical sense” to me that there should be an intermediate stage of “built out” coverage hanging around that one then asks to do things. It turns out, though, that just having “clean inputs” is sufficient to achieve what people really want, which is really just replacing map shaper and being able to do polygon simplification that respects neighbours. That’s the use case, pretty much full stop. Secondarily, high-speed union is a benefit to having a set of cleaned polygons lying around.
> 
> Isn’t that inefficient? Well, marginally perhaps, but I can run through very large inputs (150MB, 2M vertices) and get results in under a second. The “having a real coverage” buys me nothing.
> 
> Also worth noting, these operations run on pretty distinct code lines. There isn’t an edge/node/face abstraction being built under the covers, mostly it’s sets of edges. If we build up a “coverage object” it will be a Potemkin structure, because it won’t have underneath the kinds of things people expect it to have.
> 
> On the PostGIS side, exposing this as operations against SF collections cuts down the friction to people using it in their normal lives. They just want map shaper. Persisting a topology is overkill. Once we have a basic cleaner, the work flow will become: load shape file; clean; simplify; run various (high speed) unions for outputs. All with SF data.
> 
> In summary, if we in fact *need* an explicit coverage object, if for example we are going to start having an in-memory modifiable edge/node/face object, then we should then make it, but until then this SF approach makes a great deal of sense to me.
> 
> P.
> 
> 
> 
> 
>> 
>> --strk;
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/postgis-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20230428/47796786/attachment.htm>