[
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:13 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
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 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]
