<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 7, 2022 at 5:30 PM 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"><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">
But not sure how much extra overhead or difficulty that would cause for<br>
other projects consuming such a new type.<br></blockquote><div><br></div><div>It would be the same difficulty/overhead as creating a GeometryCollection instead of passing around an array of geometries or creating an Envelope instead of working with arrays of four doubles. In other words, negligible. We're just saying "this isn't a random array of polygons, it's a set that has some special properties."</div></div></div></blockquote><div><br></div><div>If the Coverage type is just a list of polygons, then agreed, it has low overhead.  </div><div><br></div><div>If it is actually a full topological structure, then it has significant overhead both in constructing the topology and allocating objects representing the topology graph.  I think some of the ideas in this thread might require this kind of structure to be efficient.  But it obviously has significant extra complexity.  I'm not working in this direction (for now, anyway).   I'm interested in seeing how many operations can be done efficiently using the list-of-polygons representation.</div></div></div>