Cc’ing over to geos-devel too > On Apr 28, 2023, at 8:21 AM, Paul Ramsey <pram...@cleverelephant.ca> wrote: > > > >> On Apr 28, 2023, at 7:18 AM, Sandro Santilli <s...@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-de...@lists.osgeo.org <mailto:postgis-de...@lists.osgeo.org> >> https://lists.osgeo.org/mailman/listinfo/postgis-devel
_______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
