<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">You read my mind.  I'm fine with an additional type in PostGIS.<br>
<br>
Along the lines with what Dan Baston said, the idea of having a special<br>
coverage type that multiple operations can be applied to is very appealing<br>
to me.<br>
<br>
But not sure how much extra overhead or difficulty that would cause for<br>
other projects consuming such a new type.<br>
Maybe for some it can have a mutator to convert it to a polygon array or<br>
something, for projects that can't handle consuming additional types.<br></blockquote><div><br></div><div>I'm actually thinking the opposite!  My goal is to provide operations which can be used to process sets of records in PostGIS with polygonal geometry, which *implicity* form a coverage.  That fits in better with the relational and SQL paradigm, I think.  In particular, coverage polygon attributes are simply represented by the table rows.  By using window functions coverage operations can run over sets of rows and produce new values for the geometry in each row (for example:</div><div><br></div><div>- linework indicating coverage errors</div><div>- a coverage-clean version of the input</div><div>- a simplified version of the input</div><div><br></div><div>  </div></div></div>