<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"><div dir="ltr"><div class="gmail_quote"><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>
</blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">This is really an implementation question, isn't it? I was responding only to your request for feedback on the API. Maybe it makes sense to implement everything based on arrays of polygons. But exposing it to an API client that way doesn't seem especially clean, future-proof, or consistent with the rest of the GEOS API. Is it that improbable that we would ever want to store a coverage's extent? Remove a polygon from a coverage?<br></div><div class="gmail_quote"></div><div class="gmail_quote"><br></div><div class="gmail_quote">Dan<br></div><div class="gmail_quote"><br></div></div>