<div dir="ltr"><div>Very excited about progress on this front! Thanks for the update Martin.<br></div><div><br></div>I think the idea of a separate coverage type in the C API captures my thoughts as well.<div><br></div><div>I anticipate wanting to run chained operations (esp. simplify, precision reduction, smoothing) on coverages. Having final outputs (e.g., coverage => polygons) relate 1:1 to the input polygons so we can re-attach associated data will be essential; I think it will be OK for the intermediate coverage to be its own collection type and not relatable back 1:1. I.e., I don't anticipate wanting to simplify elements of the coverage differently from each other.<div><br></div><div>Should the signature for Union instead be Coverage -> Coverage? Then it could also be used in a chain of operations affecting coverages.</div><div>Then a separate function for Coverage -> Polygonal geometry (since it could be used for more than just union)</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 7, 2022 at 7:29 AM Daniel Baston <<a href="mailto:dbaston@gmail.com">dbaston@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">Lots of useful stuff here!<br><br>I would prefer a specific coverage data type, because it more clearly captures intent, allows <br>preservation of structural information (or other data we haven't yet anticipated) between function calls, and <br>results in function signatures that are simpler those associated with geometry arrays, e.g.<br><br>GEOSPolygonCoverage* GEOSCoverageSimplify(GEOSPolygonCoverage* in, double tol);<br><br>vs<br><br>int GEOSCoverageSimplify(GEOSGeometry* in, size_t ngeom_in, GEOSGeometry** out, size_t* ngeom_out, double tol);<br><br>For cleanup, it would also be cleaner to call<br><br>GEOSCoverageDestroy(coverage);<br><br>rather than<br><br>for (size_t i = 0; i < ngeoms; i++) {<br> GEOSGeom_destroy(coverage[i]);<br>GEOSFree(coverage)<br><br>although we could write a utility function around the latter.<br><br>I think some chained operations may not be uncommon, e.g.;<br><br>create coverage -> validate coverage -> simplify coverage -> reduce precision of coverage.<br><br><div>It may be useful to be able to define owning and non-owning variants of coverages.</div><div><br></div><div>Another (probably unpopular) option is to define a polygon coverage as another subtype of Geometry, and use</div><div>our existing API to manipulate it (GEOSisValid, GEOSSimplify, etc.)</div><div><br></div><div>Dan<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 6, 2022 at 5:37 PM Martin Davis <<a href="mailto:mtnclimb@gmail.com" target="_blank">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>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geos-devel</a><br>
</blockquote></div>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geos-devel</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font size="4">Brendan C. Ward</font><div><font color="#666666">Owner | Lead Software Engineer</font><br><div>Astute Spruce, LLC</div></div><div><a href="https://astutespruce.com/" target="_blank">astutespruce.com</a><br></div><div>541-250-9544</div></div></div></div></div></div></div>