RFC: OverlayNG Z handling

[dr-jts]

In order to provide enhanced functionality, and to match functionality already in GEOS, OverlayNG needs to compute Z values for results when one or both of the input geometries are 3D.

Motivating Use Cases

• Intersection and Difference for a 3D geometry by a 2D geometry
• Overlay operations on input 3D geometries based on the same Z model.

NON Use Cases

These cases are handled, but only with "best-effort" semantics

• Input geometries with inconsistent Z models
• Geometries with some Z values missing

Assumptions

• If both geometries are 3D, it is assumed that their underlying 3D models are consistent. In particular, it is assumed that points which are equal in 2D have the same Z value.
  • Inconsistent Z models are supported, but no guarantees are made about the consistency of the computed Z values.

Semantics

• Intersection points are interpolated along one or both of the intersecting segments. If both segments have Z values, the Z value of the intersection is the average of the interpolated values.
• The Z value for points with the same location is chosen non-deterministically from the source Zs.

Questions

• Should difference(geom2D, geom3D) be a geom2D?

[strk]

Why not taking the average even in case of same-location ? I believe this was the intended semantic in GEOS.
How would you deal with intersection of a 2D line (or point) contained by a 3D polygon ? Would you attempt to give a Z to the resulting point (ala ElevationMatrix)

[dr-jts]

Why not taking the average even in case of same-location ? I believe this was the intended semantic in GEOS.

Well, maybe. Not clear to me that that is any better than just taking one of the input Zs (which presumably are considered authoritative).

A reason for not doing this is because it requires quite a few more tests.

[dr-jts]

How would you deal with intersection of a 2D line (or point) contained by a 3D polygon ? Would you attempt to give a Z to the resulting point (ala ElevationMatrix)

In general, an intersection of 2D with 3D should produce a 3D result. Am going to follow the GEOS implementation of ElevationMatrix (although this is only a very rough approximation I think. Is it motivated by any concrete use case?)

I will make this explicit in the design doc.

[jodygarnett]

Going back my 1st job at Facet where functional GIS environment (called Cause and Effect) had a "drape" function for this purpose.

If you define a callback object for generate the z values, folks can provide their own, sampling from a dem if they have that available, you can supply a default that uses interpolation, or uses all z values weight by distance (allowing missing z values to be ignored).

[jodygarnett]

A: Based on difference javadoc: Computes a Geometry representing the closure of the point-set of the points contained in this Geometry that are not contained in the other Geometry:

• difference(geom2D, geom3D) should be 2D
• difference(geom3D, geom2D) should be 3D

The way I imagine it is that a geom2D has all values for Z.

[dr-jts]

If you define a callback object for generate the z values, folks can provide their own, sampling from a dem if they have that available, you can supply a default that uses interpolation, or uses all z values weight by distance (allowing missing z values to be ignored).

Yes, or else can just leave the Z values as NaN and leave it to user to populate them via a CoordinateSequenceFilter. In this case will need a switch to prevent interpolating missing Z values.

[dr-jts]

WIP branch is here: https://github.com/dr-jts/jts/tree/overlayng-z

[strk]

GEOS port ticket: https://trac.osgeo.org/geos/ticket/1063

[strk]

In the GEOS port I've used CoordinateFilter instead of CoordinateSequenceFilter, for populating the Z. I think it would be faster (less virtual calls) and for the GEOS case, it works around a bug which prevents a CoordinateSequence to update its view about presence of Z when its coordinates are updated (CoordinateSequenceFilter calls setOrdinate for each coordinate, and in GEOS that operation currently does NOT clear the cache). As I think it would be faster to use CoordinateFilter I didn't bother plugging the bug (as it would slow down use of setOrdinate in general)

[dr-jts]

In the GEOS port I've used CoordinateFilter instead of CoordinateSequenceFilter, for populating the Z.

Sounds fine to me. Generally JTS is moving towards using CoordinateSequenceFilter instead of CoordinateFilter, to avoid the overhead of creating temporary Coordinate objects for CoordinateSequence implementations which do not store explicit coordinate objects. But C++ provides more options for efficient passing of coordinate values, so CoordinateFilter is simpler and possibly more efficient.

[strk]

Yes in GEOS is actually more efficient as we only have a concrete Coordinate class, instances of which are passed by reference for CoordinateFilter

[dr-jts]

Done by #645