<div dir="ltr"><div dir="ltr">On Thu, Jul 30, 2020 at 5:30 PM Daniel Baston <<a href="mailto:dbaston@gmail.com">dbaston@gmail.com</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"><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>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></blockquote><div><br></div><div>This behavior seems confusing to me, and I'm struggling to tell if it's just because I'm used to the old behavior. </div></div></div></blockquote><div><br></div><div>FWIW, It seems like simpler behaviour to me.  And I think that's evidenced by clients needing to introduce special code to strip out the unwanted components.  </div><div> </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"><div>But it did occur to me that this introduces an inconsistency between the predicates and overlay functions wherein A and B may intersect at a point outside the intersection of A and B.</div></div></div></blockquote><div><br></div><div>There isn't absolute consistency between the predicates and overlay functions anyway, due to the snapping heuristics in overlay, and the lack of a tolerance in the predicates.  But agreed, this would move "further" from consistency.  Although I'm not sure that really matters - if consistency cannot be guaranteed (which it can't), then clients should not rely on it being true.  (I am hoping to implement a new approach to computing predicates, which supports a tolerance.  But this still won't provide full consistency, and I'm not sure that can ever be provided given heuristics, finite precision, and robustness issues)   </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"><div><br></div><div>It's also easy enough for a user to remove the unwanted components of the result but quite difficult to generate lower-dimension components that were not included in the result.</div></div></div></blockquote><div><br></div><div>That's a good point.  And that is often the motivation for design decisions in JTS - do the hard things, if it's easy to derive simpler things.</div><div><br></div><div>Actually there are two aspects to this semantic.  There are of course situations where geometries "natively" intersect in multiple dimension components.  And then there are situations where topology collapse occurs during noding (e.g. where a narrow area is turned into a line), and that "line" intersects the other geometry.  The old behaviour was to return collapses as lines (or points), if they intersected.  That is more consistent with the predicates as noted above.</div><div><br></div><div>Unfortunately I'm not sure how easy these behaviours are to implement with the new OverlayNG codebase.  Something to investigate, I guess.</div><div><br></div></div></div>