<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br><div><br><blockquote type="cite"><div>On Apr 28, 2023, at 2:57 PM, Martin Davis <mtnclimb@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr"><div dir="ltr">On Fri, Apr 28, 2023 at 7:18 AM Sandro Santilli <<a href="mailto:strk@kbt.io" target="_blank">strk@kbt.io</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
As mentioned in chat, I'm thinking having a GEOSCoverage<br>
datatype would be advisible here, with one constructor<br>
taking a vector of Geometry pointer for now but eventually<br>
getting more constructors.<br></blockquote><div><br></div><div>Sandro, are you suggesting a GEOSCoverage type containing a *topological* structure, or one containing a set of Polygons/MultiPolygons?</div><div><br></div><div>For a topological structure, that may be useful, but that is a fair bit of work and is NOT required by the recent coverage functions. If and when this is done, I suggest it is called GEOSTopology to be totally clear.</div><div><br></div><div>For a coverage type that simply contains a list of polygonal geometries, that is what I have called a Simple Features Coverage. GEOSCoverage would be a fine name for this. This is actually what I considered at the start of developing the various coverage operations. I backed away from this in order to keep things simple. But it does have some advantages for understanding and documenting the concept of a simple coverage.</div></div></div></div></blockquote><div><br></div><div>We had a little discussion of something much like this when bringing these functions into GEOS CAPI, whether to use a GeometryList as a container, which except for the name, is basically all a GEOSSimpleCoverage container would be doing too. In the end, I was persuaded that a super lightweight approach was better than adding another scruff of a type.</div><div><br></div><div>P</div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div> </div></div></div>
_______________________________________________<br>postgis-devel mailing list<br>postgis-devel@lists.osgeo.org<br>https://lists.osgeo.org/mailman/listinfo/postgis-devel<br></div></blockquote></div><br></body></html>