RFC: Bag semantics for operations on GeometryCollections

[dr-jts]

GeometryCollections are not supported as inputs for many useful JTS operations (e.g. overlay, spatial predicates, boundary). This is because the JTS design philosophy in the past has been that GeometryCollections should have full topological semantics. This requires substantial processing for all topological operations (e.g. overlay, predicates, boundary), which has essentially prevented them from being implemented.

However, there seems to be a general consensus that "bag" semantics are sufficient for GeometryCollections. This substantially simplifies their semantics, and allow all the above methods to be provided.

Bag semantics means that operations are evaluated piecewise on the collection(s), and the results are returned as collections. No attempt is made to "condense" the result into a simpler, topologically valid geometry.

See #539, NTS-213 comment.

For prior art, it seems like MS-SQL provides these semantics for at least some operations. I'm not aware of any normative OGC semantics for GeometryCollections.

Questions

• Buffer currently works with GeometryCollections. Its semantics should not change, I think.

[dr-jts]

While implementing bag semantics is relatively simple, there is also a good argument for providing "point-set-topology" semantics for overlay operations and predicates. Probably this is the most natural way to extend the current Geometry methods.

A step in this direction is #915, which provides overlay support for simple GeometryCollections.

[dr-jts]

The two main operations of overlay and relate now handle GeometryCollections using Point-Set Topology semantics. So this design choice is no longer an issue.