You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Helleringer, Nicolas" <ni...@novacodex.net> on 2010/04/01 00:08:05 UTC
Re: [SPATIAL] CartesianPolyFilterBuilder ?
I do.
It is clearly related to prime meridian handling but it is unreadable and
buggy.
I did a complete rewrite of this sector of code commited to Chris Male
repository (working together to rework the whole thing).
Commit of this work should be done by Chris very soon.
Hope it will help.
Nicolas
2010/3/31 Grant Ingersoll <gs...@apache.org>
> Anyone know what the point of this code is from the
> CartesianPolyFilterBuilder:
>
> <code>
> shape = getShapeLoop(shape, ctp, latX, longX, latY, longY);
> if (longX2 != 0.0) {
> if (longX2 != 0.0) {
> if (longX == 0.0) {
> longX = longX2;
> longY = 0.0;
> shape = getShapeLoop(shape, ctp, latX, longX, latY, longY);
> } else {
> longX = longX2;
> longY = -180.0;
> shape = getShapeLoop(shape, ctp, latY, longY, latX, longX);
> }
> }
>
> </code>
>
> Why the double check on longX2? I think it's trying to get at edge cases
> (based on earlier statements to do with prime meridian and the 180
> longitude.
>
> Also, I see the following comment:
> double startY = beginAt - startX ; //should give a whole number
>
> Yet, in debugging, I don't see how it is ever a whole number, b/c, AIUI,
> the left side of the decimal of a box number is the X value (latitude) and
> the right side of the decimal is the Y value.
>
> FWIW, I'm testing how all this tile stuff behaves across the 180th degree
> longitude (and it doesn't seem to be behaving well)
>
> -Grant
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Re: [SPATIAL] CartesianPolyFilterBuilder ?
Posted by "Helleringer, Nicolas" <ni...@novacodex.net>.
Grant,
I shall create a patch for LUCENE-1921 based on the code @ GoogleCode as
soon as the patch I just post on LUCENE-2359 is ok for you and comitted.
For info, pole flipping, large distance and other buggy behaviors around
prime meridian have to do with how LatLngRect is coded and how the bounding
area for a search radius and point is computed + matching tier boxes are
fetched.
Code we ve done at Google Code should solve all of those and I hope is more
readable.
Regards,
Nicolas
2010/4/1 Grant Ingersoll <gs...@apache.org>
>
> On Apr 1, 2010, at 1:22 PM, Helleringer, Nicolas wrote:
>
> > I did. It is bugged.
>
> https://issues.apache.org/jira/browse/LUCENE-1921 It has come up before.
>
> > It has also been re worked and will be patched (this weekend If I can)
> and comitted by Chris afterwards.
>
> slight reword: can be committed by someone afterwards ;-)
>
> I'm pretty hot on this right now, so if you can put up a patch for this
> issue sooner, I can work on it.
>
> -Grant
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
Re: [SPATIAL] CartesianPolyFilterBuilder ?
Posted by Grant Ingersoll <gs...@apache.org>.
On Apr 1, 2010, at 1:22 PM, Helleringer, Nicolas wrote:
> I did. It is bugged.
https://issues.apache.org/jira/browse/LUCENE-1921 It has come up before.
> It has also been re worked and will be patched (this weekend If I can) and comitted by Chris afterwards.
slight reword: can be committed by someone afterwards ;-)
I'm pretty hot on this right now, so if you can put up a patch for this issue sooner, I can work on it.
-Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [SPATIAL] CartesianPolyFilterBuilder ?
Posted by "Helleringer, Nicolas" <ni...@novacodex.net>.
I did. It is bugged. It has also been re worked and will be patched (this
weekend If I can) and comitted by Chris afterwards.
Code is again @GoogleCode for the moment.
Nicolas
2010/4/1 Grant Ingersoll <gs...@apache.org>
>
> On Apr 1, 2010, at 9:09 AM, Helleringer, Nicolas wrote:
>
>
>
> 2010/4/1 Grant Ingersoll <gs...@apache.org>
>
>>
>> No.
> The longitude has an effect because of the projection used to go from a
> spherical world to a flat coordinates system.
> See
> http://www.nsshutdown.com/projects/lucene/whitepaper/locallucene_v2.html
> and http://en.wikipedia.org/wiki/Sinusoidal_projection
>
>
> Duh, I always forget about the projection.
>
>
> Next question: Have you tried the CartPFilterBldr with large distance
> values?
>
> For instance, I put in distance of 5000 around a point (33.0, -80) and get
> 9 matches in my test. Using the same point and 10000 miles, I get 5
> matches.
>
> My points are (never mind the Solr syntax):
> assertU(adoc("id", "1", fieldName, "32.7693246, -79.9289094"));
> assertU(adoc("id", "2", fieldName, "33.7693246, -80.9289094"));
> assertU(adoc("id", "3", fieldName, "-32.7693246, 50.9289094"));
> assertU(adoc("id", "4", fieldName, "-50.7693246, 60.9289094"));
> assertU(adoc("id", "5", fieldName, "0,0"));
> assertU(adoc("id", "6", fieldName, "0.1,0.1"));
> assertU(adoc("id", "7", fieldName, "-0.1,-0.1"));
> assertU(adoc("id", "8", fieldName, "0,179.9"));
> assertU(adoc("id", "9", fieldName, "0,-179.9"));
> assertU(adoc("id", "10", fieldName, "89.9,50"));
> assertU(adoc("id", "11", fieldName, "89.9,-130"));
>
> At any rate, I'm debugging.
>
Re: [SPATIAL] CartesianPolyFilterBuilder ?
Posted by Grant Ingersoll <gs...@apache.org>.
On Apr 1, 2010, at 9:09 AM, Helleringer, Nicolas wrote:
>
>
> 2010/4/1 Grant Ingersoll <gs...@apache.org>
>
> No.
> The longitude has an effect because of the projection used to go from a spherical world to a flat coordinates system.
> See http://www.nsshutdown.com/projects/lucene/whitepaper/locallucene_v2.html and http://en.wikipedia.org/wiki/Sinusoidal_projection
Duh, I always forget about the projection.
Next question: Have you tried the CartPFilterBldr with large distance values?
For instance, I put in distance of 5000 around a point (33.0, -80) and get 9 matches in my test. Using the same point and 10000 miles, I get 5 matches.
My points are (never mind the Solr syntax):
assertU(adoc("id", "1", fieldName, "32.7693246, -79.9289094"));
assertU(adoc("id", "2", fieldName, "33.7693246, -80.9289094"));
assertU(adoc("id", "3", fieldName, "-32.7693246, 50.9289094"));
assertU(adoc("id", "4", fieldName, "-50.7693246, 60.9289094"));
assertU(adoc("id", "5", fieldName, "0,0"));
assertU(adoc("id", "6", fieldName, "0.1,0.1"));
assertU(adoc("id", "7", fieldName, "-0.1,-0.1"));
assertU(adoc("id", "8", fieldName, "0,179.9"));
assertU(adoc("id", "9", fieldName, "0,-179.9"));
assertU(adoc("id", "10", fieldName, "89.9,50"));
assertU(adoc("id", "11", fieldName, "89.9,-130"));
At any rate, I'm debugging.
Re: [SPATIAL] CartesianPolyFilterBuilder ?
Posted by "Helleringer, Nicolas" <ni...@novacodex.net>.
2010/4/1 Grant Ingersoll <gs...@apache.org>
>
> On Apr 1, 2010, at 8:22 AM, Helleringer, Nicolas wrote:
>
> I did put a comment on the jira issue pointing to the code I wrote inside
> Chris Male perspective.
> He answered on the JIRA topic as well.
>
>
> Yep, saw that. If you wish for that code to be in Lucene, you need to post
> it as a patch to Lucene and grant provenance to the ASF.
>
That is what we want to happen. We are working on it, both of us.
> Here's another question:
> Given the same latitude and same distance, shouldn't there be the same
> number of box ids no matter the longitude? Yet the following code says
> otherwise:
> public void testCartesianPolyFilterBuilder() throws Exception {
> CartesianPolyFilterBuilder cpfb = new
> CartesianPolyFilterBuilder(CartesianTierPlotter.DEFALT_FIELD_PREFIX, 2, 15);
> //try out some shapes
> final double miles = 20.0;
> // Hawaii
> // 2300 miles to Marshall Island Airfield
> //Hawaii to Midway is 911 miles
> lat = 0;
> lng = -179.9;
> Shape shape;
> shape = cpfb.getBoxShape(lat, lng, miles);
> System.out.println("Tier: " + shape.getTierLevel());
> System.out.println("area: " + shape.getArea().size());
> lat = 30;
> lng = -100;
> shape = cpfb.getBoxShape(lat, lng, miles);
> System.out.println("Tier: " + shape.getTierLevel());
> System.out.println("area: " + shape.getArea().size());
>
> lat = 30;
> lng = 100;
> shape = cpfb.getBoxShape(lat, lng, miles);
> System.out.println("Tier: " + shape.getTierLevel());
> System.out.println("area: " + shape.getArea().size());
> }
>
> -Grant
>
No.
The longitude has an effect because of the projection used to go from a
spherical world to a flat coordinates system.
See http://www.nsshutdown.com/projects/lucene/whitepaper/locallucene_v2.html
and http://en.wikipedia.org/wiki/Sinusoidal_projection
You can clearly see that all longitude are not equals in terms of number of
boxes.
You could ask why using Sinusoidal projection ? Because it is does not have
to much distance distortion in populated places and it is very simple to
calculate.
Hope it helps.
Nicolas
Re: [SPATIAL] CartesianPolyFilterBuilder ?
Posted by Grant Ingersoll <gs...@apache.org>.
On Apr 1, 2010, at 8:22 AM, Helleringer, Nicolas wrote:
> I did put a comment on the jira issue pointing to the code I wrote inside Chris Male perspective.
> He answered on the JIRA topic as well.
Yep, saw that. If you wish for that code to be in Lucene, you need to post it as a patch to Lucene and grant provenance to the ASF.
Here's another question:
Given the same latitude and same distance, shouldn't there be the same number of box ids no matter the longitude? Yet the following code says otherwise:
public void testCartesianPolyFilterBuilder() throws Exception {
CartesianPolyFilterBuilder cpfb = new CartesianPolyFilterBuilder(CartesianTierPlotter.DEFALT_FIELD_PREFIX, 2, 15);
//try out some shapes
final double miles = 20.0;
// Hawaii
// 2300 miles to Marshall Island Airfield
//Hawaii to Midway is 911 miles
lat = 0;
lng = -179.9;
Shape shape;
shape = cpfb.getBoxShape(lat, lng, miles);
System.out.println("Tier: " + shape.getTierLevel());
System.out.println("area: " + shape.getArea().size());
lat = 30;
lng = -100;
shape = cpfb.getBoxShape(lat, lng, miles);
System.out.println("Tier: " + shape.getTierLevel());
System.out.println("area: " + shape.getArea().size());
lat = 30;
lng = 100;
shape = cpfb.getBoxShape(lat, lng, miles);
System.out.println("Tier: " + shape.getTierLevel());
System.out.println("area: " + shape.getArea().size());
}
-Grant
Re: [SPATIAL] CartesianPolyFilterBuilder ?
Posted by "Helleringer, Nicolas" <ni...@novacodex.net>.
I did put a comment on the jira issue pointing to the code I wrote inside
Chris Male perspective.
He answered on the JIRA topic as well.
Regards,
Nicolas
2010/4/1 Grant Ingersoll <gs...@apache.org>
>
> On Mar 31, 2010, at 6:08 PM, Helleringer, Nicolas wrote:
>
> I do.
>
> It is clearly related to prime meridian handling but it is unreadable and
> buggy.
>
>
> Yeah, I put up and committed a bunch of comments.
>
>
> I did a complete rewrite of this sector of code commited to Chris Male
> repository (working together to rework the whole thing).
>
>
> I put up a patch on https://issues.apache.org/jira/browse/LUCENE-2359.
> How does your's compare? Can you post it?
>
>
> Commit of this work should be done by Chris very soon.
>
> Hope it will help.
>
> Nicolas
>
> 2010/3/31 Grant Ingersoll <gs...@apache.org>
>
>> Anyone know what the point of this code is from the
>> CartesianPolyFilterBuilder:
>>
>> <code>
>> shape = getShapeLoop(shape, ctp, latX, longX, latY, longY);
>> if (longX2 != 0.0) {
>> if (longX2 != 0.0) {
>> if (longX == 0.0) {
>> longX = longX2;
>> longY = 0.0;
>> shape = getShapeLoop(shape, ctp, latX, longX, latY, longY);
>> } else {
>> longX = longX2;
>> longY = -180.0;
>> shape = getShapeLoop(shape, ctp, latY, longY, latX, longX);
>> }
>> }
>>
>> </code>
>>
>> Why the double check on longX2? I think it's trying to get at edge cases
>> (based on earlier statements to do with prime meridian and the 180
>> longitude.
>>
>> Also, I see the following comment:
>> double startY = beginAt - startX ; //should give a whole number
>>
>> Yet, in debugging, I don't see how it is ever a whole number, b/c, AIUI,
>> the left side of the decimal of a box number is the X value (latitude) and
>> the right side of the decimal is the Y value.
>>
>> FWIW, I'm testing how all this tile stuff behaves across the 180th degree
>> longitude (and it doesn't seem to be behaving well)
>>
>> -Grant
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>
> --------------------------
> Grant Ingersoll
> http://www.lucidimagination.com/
>
> Search the Lucene ecosystem using Solr/Lucene:
> http://www.lucidimagination.com/search
>
>
Re: [SPATIAL] CartesianPolyFilterBuilder ?
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 31, 2010, at 6:08 PM, Helleringer, Nicolas wrote:
> I do.
>
> It is clearly related to prime meridian handling but it is unreadable and buggy.
Yeah, I put up and committed a bunch of comments.
>
> I did a complete rewrite of this sector of code commited to Chris Male repository (working together to rework the whole thing).
I put up a patch on https://issues.apache.org/jira/browse/LUCENE-2359. How does your's compare? Can you post it?
>
> Commit of this work should be done by Chris very soon.
>
> Hope it will help.
>
> Nicolas
>
> 2010/3/31 Grant Ingersoll <gs...@apache.org>
> Anyone know what the point of this code is from the CartesianPolyFilterBuilder:
>
> <code>
> shape = getShapeLoop(shape, ctp, latX, longX, latY, longY);
> if (longX2 != 0.0) {
> if (longX2 != 0.0) {
> if (longX == 0.0) {
> longX = longX2;
> longY = 0.0;
> shape = getShapeLoop(shape, ctp, latX, longX, latY, longY);
> } else {
> longX = longX2;
> longY = -180.0;
> shape = getShapeLoop(shape, ctp, latY, longY, latX, longX);
> }
> }
>
> </code>
>
> Why the double check on longX2? I think it's trying to get at edge cases (based on earlier statements to do with prime meridian and the 180 longitude.
>
> Also, I see the following comment:
> double startY = beginAt - startX ; //should give a whole number
>
> Yet, in debugging, I don't see how it is ever a whole number, b/c, AIUI, the left side of the decimal of a box number is the X value (latitude) and the right side of the decimal is the Y value.
>
> FWIW, I'm testing how all this tile stuff behaves across the 180th degree longitude (and it doesn't seem to be behaving well)
>
> -Grant
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
--------------------------
Grant Ingersoll
http://www.lucidimagination.com/
Search the Lucene ecosystem using Solr/Lucene: http://www.lucidimagination.com/search