You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Pradeep Singh <pk...@gmail.com> on 2010/10/20 00:23:40 UTC
Spatial
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 am not talking about changing Lucene/Solr code, I can duplicate the
classes to create my own version. Just wanted to be sure about the results.
Pradeep
Re: Spatial
Posted by Grant Ingersoll <gs...@apache.org>.
On Oct 20, 2010, at 12:14 PM, Pradeep Singh wrote:
> 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?
It's just an example. There shouldn't be any problem with using tdouble (or tfloat if you don't need the precision)
>
> -Pradeep
>
> On Tue, Oct 19, 2010 at 6:10 PM, Grant Ingersoll <gs...@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
--------------------------
Grant Ingersoll
http://www.lucidimagination.com/
Search the Lucene ecosystem docs using Solr/Lucene:
http://www.lucidimagination.com/search
Re: Spatial
Posted by Pradeep Singh <pk...@gmail.com>.
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 <gs...@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
Re: Spatial
Posted by Grant Ingersoll <gs...@apache.org>.
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