[
https://issues.apache.org/jira/browse/LUCENE-5271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilad Barkai updated LUCENE-5271:
---------------------------------
Attachment: LUCENE-5271.patch
Ryan, thanks for looking at this.
bq. If the lat/lon values are large, then the index would be out of bounds for
the table
Nice catch! I did not check for values over 90 degs Lat. Added a % with the the
table's size.
bq. Why was this test removed? assertEquals(314.40338, haversin(1, 2, 3, 4),
10e-5)
Well the test's result are wrong :) The new more accurate method gets other
results. I added other test instead:
{code}
double earthRadiusKMs = 6378.137;
double halfCircle = earthRadiusKMs * Math.PI;
assertEquals(halfCircle, haversin(0, 0, 0, 180), 0D);
{code}
Which computes half earth circle on the equator using both the harvestin and a
simple circle equation using Earth's equator radius.
It differs in over 20KMs from the old harvesin result btw.
bq. Could you move the 2 * radius computation into the table?
Awesome! renamed the table to diameter rather than radius.
bq. I know this is an already existing problem, but could you move the division
by 2 from h1/h2 to h?
Done.
> A slightly more accurate SloppyMath distance
> --------------------------------------------
>
> Key: LUCENE-5271
> URL: https://issues.apache.org/jira/browse/LUCENE-5271
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/other
> Reporter: Gilad Barkai
> Priority: Minor
> Attachments: LUCENE-5271.patch, LUCENE-5271.patch, LUCENE-5271.patch
>
>
> SloppyMath, intriduced in LUCENE-5258, uses earth's avg. (according to WGS84)
> ellipsoid radius as an approximation for computing the "spherical" distance.
> (The TO_KILOMETERS constant).
> While this is pretty accurate for long distances (latitude wise) this may
> introduce some small errors while computing distances close to the equator
> (as the earth radius there is larger than the avg.)
> A more accurate approximation would be taking the avg. earth radius at the
> source and destination points. But computing an ellipsoid radius at any given
> point is a heavy function, and this distance should be used in a scoring
> function.. So two optimizations are optional -
> * Pre-compute a table with an earth radius per latitude (the longitude does
> not affect the radius)
> * Instead of using two point radius avg, figure out the avg. latitude
> (exactly between the src and dst points) and get its radius.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
