elasticsearch/elasticsearch — pull request #2460 by IamJeffG (2012-12-03 18:37:30+00:00)
Title: Fixes #2361 - geo_shape filter does not match false positives.

This fixes #2361, geo_shape filter should not match false positives, by indexing the shape's WKB and doing an actual comparison between the doc's shape and the filter's shape to verify results from the spatial prefix tree. This comparison is optional, and used only when "fuzzy"="false" (fuzzy matching is "true" by default), as there will be a slight performance hit when used.

I would prefer you do not actually pull this, because there are a few things I don't love about the implementation; I wasn't able to find the appropriate solution by myself but instead request your advice about the best way to solve this problem:

1. Right now I base64-encode the WKB into a ```StringFieldMapper```, which is wasteful. I had preferred to use the ```BinaryFieldMapper```, but that gives "Fields with BytesRef values cannot be indexed at org.apache.lucene.document.Field.(Field.java:222)".
2. I'd prefer to only store, *but not index,* the WKB (with whatever mapper gets used). However it seems that the fieldDataCache can only read indexed fields. I am still not clear on the difference.

Once we establish the best way to resolve bullet 2, should this non-fuzzy filter be cachable or not? Which data, precisely, is getting cached in memory (the Geometrys themselves or just a bitmask over docs)? My inclination is not to cache by default, assuming that repetition of the exact same query shape will be low, but this depends on the end use case.

Please provide guidance around these concerns and I can iterate on this patchset and provide a follow-up pull request afterwards.