[
https://issues.apache.org/jira/browse/LUCENE-6908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6908:
-----------------------------------
Attachment: LUCENE-6908.patch
Thanks [~mikemccand]. In {{isClosestPointOnRectWithinRange}} it was still using
{{SloppyMath.haversin}} where it should have been using the Sinnott haversine.
Looks like it was caused by a premature diff from my benchmark workspace.
A quick interesting benchmark re: distance methods. Using 2M iterations I
benchmarked average computation time, average spatial error, and maximum
spatial error between 5 different geospatial distance methods:
* Vincenty
* Karney - Modified Vincenty that uses Newton's series expansion to fix
problems w/ antipodal points
* HaverECF - Same as {{SloppyMath.haversin}} but uses ECEF to accurately
compute semi-major axis at the given latitude.
* Sinnott's Haversine - Implementation from the original haversine publicatoin
* SloppyMath
|| Distance Method || Avg Computation (ns) || Avg Error (%) || Max Error (%) ||
| Vincenty | 1286.5529689998828 | 8.4561794778802E-11 | 7.2565793775802E-10 |
| Karney | 31770.479206999946 | 8.4561794778802E-11 | 7.2565793775802E-10 |
| HaverECF | 717.1139850000152 | 0.18409042301798453 | 0.6681179192384695 |
| SloppyMath.haverin | 159.3095249999995 | 0.22594450803222424 |
0.6539314586426048 |
| Sinnott Haversine | 146.81236699999738 | 0.18158435835918563 |
0.4931242857748373 |
I need to run some better descriptive statistics before drawing any
conclusions. At the moment, the discrepancy between {{Sloppymath.haversin}} and
Sinnott's implementation is consistent with the error described in the original
publication (which is where the tolerance of 0.5% originated).
More to come....
> TestGeoUtils.testGeoRelations is buggy with irregular rectangles
> ----------------------------------------------------------------
>
> Key: LUCENE-6908
> URL: https://issues.apache.org/jira/browse/LUCENE-6908
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Nicholas Knize
> Attachments: LUCENE-6908.patch, LUCENE-6908.patch, LUCENE-6908.patch,
> LUCENE-6908.patch
>
>
> The {{.testGeoRelations}} method doesn't exactly test the behavior of
> GeoPoint*Query as its using the BKD split technique (instead of quad cell
> division) to divide the space on each pass. For "large" distance queries this
> can create a lot of irregular rectangles producing large radial distortion
> error when using the cartesian approximation methods provided by
> {{GeoUtils}}. This issue improves the accuracy of GeoUtils cartesian
> approximation methods on irregular rectangles without having to cut over to
> an expensive oblate geometry approach.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
