The reason behind the lack of general support for predicates against GeometryCollections is given here:
http://tsusiatsoftware.net/jts/jts-faq/jts-faq.html#C4 However, as it and you point out, this doesn't apply to some simpler predicates such as intersect. This would be a relatively easy enhancement.. Note that in general it's not possible to simply combine Polygonal components into a MultiPolygon, since they may overlap, giving an invalid result which (currently) causes the basic predicate algorithm to fail. There's ways around this - in fact, PreparePolygonIntersects does not have this issue. So it could form the basis for handling GeometryCollections. Moreover, it's not possible to compute some predicates in a piecewise fashion (e.g. contains, covers). These require topology across the entire input geometry to be computed in order to determine the predicate value. Ultimately, I am working on a new approach to predicate computation which will allow GeometryCollections to be handled in the same way as other geometry (and will also be more efficient and provide caching natively). Work is going slowly on this unfortunately, due to lack of funding. On Mon, Dec 14, 2015 at 6:41 AM, Sebastian Kürten < [email protected]> wrote: > 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 >
------------------------------------------------------------------------------
_______________________________________________ Jts-topo-suite-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
