[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15218229#comment-15218229
]
Karl Wright edited comment on LUCENE-7150 at 3/30/16 4:18 PM:
--------------------------------------------------------------
As I discussed at length with Robert above, going from precise meters to angles
for anything other than a sphere is hard. For this reason, Geo3d uses angles
exclusively when specifying its shapes. This was a key design decision and
cannot realistically change. And the accurate conversion math is well-known to
be challenging; it's an iterative convergence loop, in fact, much like
computing the forward Vincenty distance.
It so happens that this problem exists for the 2D stuff as well; for example,
the test code Mike was using to exercise the 2D stuff uses a Haversine distance
in computing a circle radius based on a bounding box. So I *chose* to use the
great circle (haversine) distance as the basis of the "distance in meters"
rather than expect people to an expensive calculation every time they create
their query.
The number I have in the last two versions of the patch for mean earth radius,
by the way, comes from the constant Mike pointed me at elsewhere in the code.
The number you state above is in fact incorrect; it is *not* the mean radius,
but rather the equatorial radius.
https://en.wikipedia.org/wiki/Earth_radius
About WGS84 vs. SPHERE: Yes, if you changed all usages of "PlanetModel.WGS84"
in Geo3DPoint.java to "PlanetModel.SPHERE", you should get numbers exactly like
any other spherical model. However, please also noted that for ellipsoids,
Geo3D has a unique way of approximating the actual surface distance. All Geo3d
"circles" are in fact described by a plane that cuts through the world. Since
the world in WGS84 is an ellipsoid, the shape actually described on the surface
of the world is an ellipse, not a circle. The error this approach introduces
has been calculated to be at most 0.5% for WGS84 vs. the Vincenty calculation.
was (Author: [email protected]):
As I discussed at length with Robert above, going from precise meters to angles
for anything other than a sphere is hard. For this reason, Geo3d uses angles
exclusively when specifying its shapes. This was a key design decision and
cannot realistically change. And the accurate conversion math is well-known to
be challenging; it's an iterative convergence loop, in fact, much like
computing the forward Vincenty distance.
It so happens that this problem exists for the 2D stuff as well; for example,
the test code Mike was using to exercise the 2D stuff uses a Haversine distance
in computing a circle radius based on a bounding box. So I *chose* to use the
great circle (haversine) distance as the basis of the "distance in meters"
rather than expect people to an expensive calculation every time they create
their query.
The number I have in the last two versions of the patch for mean earth radius,
by the way, comes from the constant Mike pointed me at elsewhere in the code.
The number you state above is in fact incorrect; it is *not* the mean radius,
but rather the equatorial radius.
https://en.wikipedia.org/wiki/Earth_radius
> geo3d public APIs should match the 2D apis?
> -------------------------------------------
>
> Key: LUCENE-7150
> URL: https://issues.apache.org/jira/browse/LUCENE-7150
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael McCandless
> Attachments: LUCENE-7150.patch, LUCENE-7150.patch, LUCENE-7150.patch
>
>
> I'm struggling to benchmark the equivalent to
> {{LatLonPoint.newDistanceQuery}} in the geo3d world.
> Ideally, I think we'd have a {{Geo3DPoint.newDistanceQuery}}? And it would
> take degrees, not radians, and radiusMeters, not an angle?
> And if I index and search using {{PlanetModel.SPHERE}} I think it should
> ideally give the same results as {{LatLonPoint.newDistanceQuery}}, which uses
> haversin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
