Thanks for your response Grant. I already have the bounding box based implementation in place. And on a document base of around 350K it is super fast.
What about a document base of millions of documents? While a tier based approach will narrow down the document space significantly this concern might be misplaced because there are other numeric range queries I am going to run anyway which don't have anything to do with spatial query. But the keyword here is numeric range query based on NumericField, which is going to be significantly faster than regular number based queries. I see that the dynamic field type _latLon is of type double and not tdouble by default. Can I have your input about that decision? -Pradeep On Tue, Oct 19, 2010 at 6:10 PM, Grant Ingersoll <gsing...@apache.org>wrote: > > On Oct 19, 2010, at 6:23 PM, Pradeep Singh wrote: > > > https://issues.apache.org/jira/browse/LUCENE-2519 > > > > If I change my code as per 2519 > > > > to have this - > > > > public double[] coords(double latitude, double longitude) { > > double rlat = Math.toRadians(latitude); > > double rlong = Math.toRadians(longitude); > > double nlat = rlong * Math.cos(rlat); > > return new double[]{nlat, rlong}; > > > > } > > > > > > return this - > > > > x = (gamma - gamma[0]) cos(phi) > > y = phi > > > > would it make it give correct results? Correct projections, tier ids? > > I'm not sure. I have a lot of doubt around that code. After making that > correction, I spent several days trying to get the tests to pass and > ultimately gave up. Does that mean it is wrong? I don't know. I just > don't have enough confidence to recommend it given that the tests I were > asking it to do I could verify through other tools. Personally, I would > recommend seeing if one of the non-tier based approaches suffices for your > situation and use that. > > -Grant
