Move SpatialOperation from lucene to spatial4j

[ryantxu]

Right now the spatial operation code is in the lucene module. This means that libraries require lucene core to know the supported operations. We should have access to the operations from client code

Lets move this to spatial4j

[ryantxu]

in the next release, we could deprecate the lucene values and have them extend from here

[dsmiley]

Where do you see this being used within Spatial4j? Especially SpatialArgs? I suspect your answer is nowhere but your client code happens to have Spatial4j on its classpath but not Lucene spatial, so that is what's actually driving this -- which isn't really convincing. That was also the argument for GeohashUtils being here, which still feels arbitrary; it's got nothing to do with the rest of Spatial4j. It's fundamentally not about shapes. Something could be said about SpatialPredicate (formerly SpatialOperation) specifically though... especially if we want to break out of the limited SpatialRelation options.

[ryantxu]

Good point about SpatialArgs -- i removed that from this request.

SpatialPredicate does feel like a generally useful client action

[dsmiley]

Before this can be moved forward (merged to master) I think it needs to be clear where the Shape API might use this. If it sits there with no other class using it (like GeohashUtils) then why bother?

[ryantxu]

Isn't this for people trying to use the Shape API? As a Shape consumer, i would WAY rather write:

SpatialPredicate.IsDisjointTo( a, b )
vs
! a.relate(b).intersects()

[dsmiley]

Okay +1.

Perhaps some day we might have the Shape API have a method like boolean satisfies(predicate, shapeB) or something like that, so that it could perhaps optimize for just knowing the boolean answer rather than a SpatialRelation which is a more rich answer. I dunno yet what the API might look like -- just throwing that out there. Another approach would have direct predicate methods like isWithin(shapeB) right on the shape but that would lead to a lot more methods.

It's a shame the more rich set of predicates supported by JTS in JtsGeometry is isolated there. Maybe that's somewhat inevitable.

[ryantxu]

It's a shame the more rich set of predicates supported by JTS in JtsGeometry is isolated there. Maybe that's somewhat inevitable.

Yes -- it seems like that is the tradeoff for having JTS as an optional dependency