Hi, I'm using the Geometry class' boolean predicates in a project and found myself in the situation where I would like to evaluate such predicates for GeometryCollection arguments. Although they do work for the specialized subclasses (MultiPoint, MultiLineString and MultiPolygon) they do not work for the generic GeometryCollection class with possibly mixed geometry types.
I've seen in the source code that there's a check for the arguments not being of type GeometryCollection before computing the DE-9IM matrix and deriving the result of the predicates from that. My guess is that it is hard to compute the intersection matrix for GeometryCollections? Now I'm wondering if there's anything in JTS I've missed that would help dealing with such situations? In my case I'm currently interested in the 'intersects' predicate because I'm testing whether a group of objects that define a geographic feature intersect a polygonal region. In some situations a feature contains geometries of all three possible types, i.e. points, lines and polygons. Of course I can compute the predicate for the three types independently and combine it to a global result: Defining an own GeometryCollection subclass helped for some situations. I defined a simple sublass[1] called 'GeometryGroup' that overrides the intersects() method and loops through all members, which works as long as it does not contain other generic GeometryCollections recursively. Since I know what I'm putting into the GeometryGroup, it works fine for me. However this only works when calling GeometryGroup.intersects(Geometry) but of course not when calling Geometry.intersects(GeometryGroup). The latter situation is unfortunately the more intersting one, because existing code is usually designed to work with Geometry arguments. As soon as this existing code is using predicates somewhere, it won't work. Changing a lot of existing code to check for GeometryCollection in order to execute a specialized version of the predicate does not seem like a good idea to me. I'm suspecting the only clean solution would be to implement the predicates for GeometryCollections somehow. I have no clue whether calculating the intersection matrix is an option at all. However I was thinking it should be possible to implement them relatively straight forward using existing components, something like this: * Use Point/LinearComponent/PolygonExtracter to extract 1-3 collections of geometries from the GeometryCollection arguments, then combining these elements to MultiPoint/MulitLineString/MultiPolygon, so that we have 1-3 objects that support all predicates. * Compute the predicate for the individual parts of the collection and the argument geometry (or the parts thereof in case the argument to the predicate method is also a GeometryCollection) * Combine the results (OR for intersects, AND for contains, OR for touches, etc.) Do you think such a solution would be possible and desirable? I'm not sure whether it would work for all available predicates. If yes I'd be happy to come up with a draft. Sebastian [1] https://github.com/topobyte/osm4j-geometry/blob/master/src/main/java/de/topobyte/osm4j/geometry/GeometryGroup.java ------------------------------------------------------------------------------ _______________________________________________ Jts-topo-suite-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
