Overview

As noted in #3289, we have some problems dealing with GeometryCollections. This bug was traced to the implementation of getAll which used reflection to extract the contained geometries that matched a desired type. This was intended to be used to extract specific types or subclasses (gc.getAll[Geometry] would be useful). The problem was with gc.getAll(GeometryCollection), since MultiPoint, MultiLineString, and MultiPolygon are subclasses of GeometryCollection. Therefore, gc.getAll[GeometryCollection] would return all Multi* and GeometryCollection entities. This caused problems for methods like reproject, which would duplicate Multi* elements.

This PR, in it's first form, is for discussion purposes. The simple solution presented here is that getAll loses it's subclass semantic. This is the most straightforward, requiring no additional changes, but it does break the semantics, and therefore, technically must wait for GT 4. A more laborious change could be implemented, keeping the subclass semantics of the old getAll implementation, but reimplementing reproject and other functions that don't correctly differentiate types. This latter solution is more work, but may be preferred to maintain certain functionality.

In all cases, GT 3 broke with the model of GT 2 and down where the contents of geometry collections were explicitly compartmentalized, so we might have some latitude for bending semver rules, as this PR's content can be seen as a bugfix of a broken API rather than a change of interface.

Signed-off-by: jpolchlo [email protected]

Checklist

• ./CHANGELOG.md updated, if necessary. Link to the issue if closed, otherwise the PR.
• Unit tests added for bug-fix or new feature

Notes

Closes #3289