<div dir="ltr">I probably should have started this discussion as a GitHub issue (better formatting, linking, tracking etc).  I will try and move this content there soon.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 6, 2022 at 2:37 PM Martin Davis <<a href="mailto:mtnclimb@gmail.com">mtnclimb@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"><div dir="ltr">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).<div><br></div><div>Here's some examples of coverage operations and their geometric signatures:</div><div><br></div><div>- Validation: List of Polygons -> List of linear geometries for invalid locations</div><div>- Cleaning: List of Polygons -> Coverage</div><div>- Union: Coverage -> Polygonal geometry</div><div>- Simplification: Coverage -> Coverage </div><div><br></div><div>A key question is how to expose these operations in the GEOS C API.  I see two options:</div><div>1) Model a Polygonal Coverage as an array of simple Polygons (and possibly MultiPolygons)</div><div>2) Provide a Polygonal Coverage datatype (which might contain internal topology)</div><div><br></div><div>So far I've been favouring #1, both for the C API and for the underlying C++ and JTS APIs.  Reasons are:</div><div><br></div><div>- Simplicity of use and implementation</div><div>- Some operations (such as validation and cleaning) have to operate on non-coverage lists of polygons anyway</div><div>- A potential advantage of having a Coverage data model is that coverage operations could be chained without needing to convert back to the simple polygon representation - but it's not clear to me that this will be very common (and this is not an option for PostGIS, and maybe other downstream projects).  </div><div>- It seems more in the spirit of the Simple Features philosophy (if that's a thing)</div><div><br></div><div>Any thoughts or comments on this?</div><div><br></div><div>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><div><br></div><div>[1] <a href="http://lin-ear-th-inking.blogspot.com/2022/07/polygonal-coverages-and-operations-in.html" target="_blank">http://lin-ear-th-inking.blogspot.com/2022/07/polygonal-coverages-and-operations-in.html</a></div><div>[2] <a href="http://lin-ear-th-inking.blogspot.com/2022/08/validating-polygonal-coverages-in-jts.html" target="_blank">http://lin-ear-th-inking.blogspot.com/2022/08/validating-polygonal-coverages-in-jts.html</a></div><div>[3] <a href="https://github.com/libgeos/geos/commit/62c928c9f37957c62fab8db69e6c8efd26ce4085" target="_blank">https://github.com/libgeos/geos/commit/62c928c9f37957c62fab8db69e6c8efd26ce4085</a></div></div></div>
</blockquote></div>