<div dir="ltr"><div>A clarification on the semantics of output from OverlayNG.  Some operations CAN return heterogeneous (mixed-dimension) outputs in some situations.  </div><div><br></div><div>The exact semantics are:</div><div><br></div><div><ul style="color:rgb(0,0,0);font-family:-webkit-standard"><li>Results are always valid geometries. In particular, result<span class="gmail-Apple-converted-space"> </span><code>MultiPolygon</code>s are valid.</li><li>Repeated vertices are removed.</li><li>Linear results are merged node-to-node (e.g. are of maximal length).</li><li>Polygon edges which collapse completely due to rounding are not output.</li><li>The<span class="gmail-Apple-converted-space"> </span><code>intersection</code><span class="gmail-Apple-converted-space"> </span>operation produces a homogeneous result. The result contains the components of highest dimension in the intersection. (For instance, the intersection of a<span class="gmail-Apple-converted-space"> </span><code>Polygon</code><span class="gmail-Apple-converted-space"> </span>and a<span class="gmail-Apple-converted-space"> </span><code>LineString</code>might produce a<span class="gmail-Apple-converted-space"> </span><code>Point</code><span class="gmail-Apple-converted-space"> </span>result.)</li><li>The<span class="gmail-Apple-converted-space"> </span><code>difference</code><span class="gmail-Apple-converted-space"> </span>operation produces a homogeneous result. The result dimension is that of the left-hand operand.</li><li>The<span class="gmail-Apple-converted-space"> </span><code>union</code><span class="gmail-Apple-converted-space"> </span>and<span class="gmail-Apple-converted-space"> </span><code>symmetric difference</code><span class="gmail-Apple-converted-space"> </span>operations may produce a heterogeneous result if the inputs are of mixed dimension </li><li>Homogeneous results are output as<span class="gmail-Apple-converted-space"> </span><code>Multi</code><span class="gmail-Apple-converted-space"> </span>geometries.</li><li>Heterogeneous results are in the form of a<span class="gmail-Apple-converted-space"> </span><code>GeometryCollection</code><span class="gmail-Apple-converted-space"> </span>containing a set of atomic geometries. This provides backwards compatibility with the original JTS overlay implementation. (However, this loses the information that the polygonal results have valid<span class="gmail-Apple-converted-space"> </span><code>MultiPolygon</code><span class="gmail-Apple-converted-space"> </span>topology.)</li><li>Empty results are atomic<span class="gmail-Apple-converted-space"> </span><code>EMPTY</code><span class="gmail-Apple-converted-space"> </span>geometries of dimension appropriate to the operation.</li></ul></div><div><br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 29, 2020 at 2:08 PM Martin Davis <<a href="mailto:mtnclimb@gmail.com">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"><div dir="ltr">On Wed, Jul 29, 2020 at 12:53 PM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</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>
- 3D! GEOS uniquely has supported adding in Z coordinates to introduced coordinates, and that code hasn't been added to JTS (and thus overlayng). How this will affect existing expectations for 3D output is unknown, but it's sure to be broken in some way.<br>
- Union on linestrings! OverlayNG extracts maximal length linestrings from the unioned graph. Old overlay extracted minimal length linestrings. This change is probably "for the best" but it's a change which might impact existing logic.<br></blockquote><div><br></div><div>Another behavioural change is that now overlay operations do not return mixed-dimension results.  Instead, a homogeneous geometry containing only the highest dimension resultants is returned.</div><div><br></div><div>So for example, if two polygons intersect in an area and along an edge, the new overlay will only return the area resultant.  The old overlay returned a GEOMETRYCOLLECTION containing both a polygon and a line.  </div><div><br></div><div>Or, if two polygons intersect along an edge and at a point, the new result is a LineString for the shared edge.  The old overlay returns a GC ccntaining a line and a point.</div><div><br></div><div>The old behaviour seemed like a pain, since most (all?) uses were only interested in the highest dimension resultants.  And since GeometryCollections cannot be processed by overlay ops or spatial predicates, it made chaining together operations painful.</div><div><br></div><div>What are people's thoughts on this?  It is probably possible to build in the old behaviour (with a bit of coding effort), and make it the default path.  But I think the new behaviour is preferable and more sensible.</div><div> </div></div></div>
</blockquote></div></div>