Fix GeometryCollection::getAll extension method

[jpolchlo]

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

[pomadchin]

@jpolchlo could you update the changelog?

[pomadchin]

Hm, I also have a feeling that changes intorduced in this PR #3288 are not neccesary now. I think it makes sense to revert them to keep the code consistent?

[jpolchlo]

Happy to update the changelog, but I was/am waiting for discussion as to whether this is the right solution. If you and others are happy with what's presented here, then I'll note the changes and we can move to merge.

[pomadchin]

Thanks Justin, PR looks good 💯 // I rebased it to resolve CHANGELOG conflicts // merging it once CI is happy