Upgrade to Spatial4j 0.4.1 and JTS 1.13 #5286
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes #5279
The main think irking me is that ElasticSearch uses a global hard-coded instance of JtsSpatialContext.GEO as the one and only SpatialContext as a static final in ShapeBuilder.SPATIAL_CONTEXT. That wasn't what I had in mind when I (or was it Ryan or Chris, I forget) devised SpatialContext concept. If you look at JtsSpatialContextFactory (or don't even use JTS, look at SpatialContextFactory) you'll see a bunch of options that trigger various behavior. The most important one is "geo" (aka geodetic or geodesic, synonyms) which is a boolean that chooses between a latitude-longitude spherical world model or a flat plane (Euclidean geometry). It's not quite clear to me at this time how ElasticSearch users that want a flat world model and who pre-project their data are using this.