<div dir="ltr"><div>Thanks for the feedback, Nyall.  Comments inline below.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 6, 2022 at 3:51 PM Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 7 Sept 2022 at 07:37, Martin Davis <<a href="mailto:mtnclimb@gmail.com" target="_blank">mtnclimb@gmail.com</a>> wrote:<br>
><br>
> 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).<br>
><br>
> Here's some examples of coverage operations and their geometric signatures:<br>
><br>
> - Validation: List of Polygons -> List of linear geometries for invalid locations<br>
> - Cleaning: List of Polygons -> Coverage<br>
> - Union: Coverage -> Polygonal geometry<br>
> - Simplification: Coverage -> Coverage<br>
<br>
This is exciting, I'm very happy to see this on the horizon. Thank you!<br></blockquote><div><br></div><div>Great to hear this is going to be useful. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> 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.<br>
<br>
This sounds fine to me! A must-have would be that the geometries are<br>
always guaranteed to be returned in the same order as the input<br>
geometries, so that we can easily link input->output geometries and<br>
re-attach non spatial attributes.<br></blockquote><div><br></div><div>Yes, that's definitely part of the model - should have mentioned it. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
One consideration for the  "Simplification: Coverage -> Coverage" use<br>
case would be whether only a fixed set of simplification algorithms<br>
are permitted (eg Visvalingam/Douglas-peucker only), or whether custom<br>
simplification/modification operations would also be permitted (via<br>
some callback function or similar). I'd love to see support for custom<br>
operations, so eg I could write a coverage -> coverage operation which<br>
applies both simplification and smoothing to the boundaries.<br></blockquote><div> </div><div>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.</div><div><br></div><div>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...</div></div></div>