Okay, so I understand the new approach to predicate computation will make special implementations for simple predicates superfluous eventually. As you mentioned that things are going slowly with this, is it planned for 1.14 or rather for a later release? If not 1.14 I'd consider it worthwhile to work on a patch that implements some of the simpler predicates.
On Mon, 14 Dec 2015 09:15:45 -0800 Martin Davis <[email protected]> wrote: > 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
