Thanks for the feedback, Nyall. Comments inline below. On Tue, Sep 6, 2022 at 3:51 PM Nyall Dawson <nyall.daw...@gmail.com> wrote:
> On Wed, 7 Sept 2022 at 07:37, Martin Davis <mtncl...@gmail.com> wrote: > > > > I've started to build out operations on Polygonal Coverages in JTS ([1], > [2]). These will be ported to GEOS (started here with CoverageValidator > etc in C++ [3]). Hopefully these will be exposed in PostGIS as well (and of > course other downstream projects). > > > > Here's some examples of coverage operations and their geometric > signatures: > > > > - Validation: List of Polygons -> List of linear geometries for invalid > locations > > - Cleaning: List of Polygons -> Coverage > > - Union: Coverage -> Polygonal geometry > > - Simplification: Coverage -> Coverage > > This is exciting, I'm very happy to see this on the horizon. Thank you! > Great to hear this is going to be useful. > > > If Model #1 is used, what would the C API look like? Accept a Geometry > array with a size parameter, and return a Geometry array? It will likely > be good to have some support functions to free Geometry arrays too. > > This sounds fine to me! A must-have would be that the geometries are > always guaranteed to be returned in the same order as the input > geometries, so that we can easily link input->output geometries and > re-attach non spatial attributes. > Yes, that's definitely part of the model - should have mentioned it. > > One consideration for the "Simplification: Coverage -> Coverage" use > case would be whether only a fixed set of simplification algorithms > are permitted (eg Visvalingam/Douglas-peucker only), or whether custom > simplification/modification operations would also be permitted (via > some callback function or similar). I'd love to see support for custom > operations, so eg I could write a coverage -> coverage operation which > applies both simplification and smoothing to the boundaries. > At the moment I'm only working on VW simplification, because it reuses a lot of code already in place. Pluggable algorithms would be a bit of a research project, because the requirement of preserving topology and being performant requires quite a bit of indexing structure to be available. And it's not clear how much could be common between different algorithms. The idea of smoothing is a good one - hadn't thought of that. Of course, that might require a different approach yet again to preserve topology...
_______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
