Definitely not 1.14 - that's just about ready for release.
On Wed, Dec 16, 2015 at 5:34 AM, Sebastian Kürten < [email protected]> wrote: > 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
