<div dir="ltr"><div dir="ltr">On Wed, Jul 29, 2020 at 12:53 PM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">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>