[geos-devel] OverlayNG for Testing

[Martin Davis]

On Thu, Jul 30, 2020 at 5:30 PM Daniel Baston <dbaston at gmail.com> wrote:

> 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.
>>
>
> This behavior seems confusing to me, and I'm struggling to tell if it's
> just because I'm used to the old behavior.
>

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.


> 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.
>

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)

>
> 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.
>

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.

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.

Unfortunately I'm not sure how easy these behaviours are to implement with
the new OverlayNG codebase.  Something to investigate, I guess.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20200730/2de12802/attachment.html>