[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15216980#comment-15216980
]
Karl Wright edited comment on LUCENE-7150 at 3/29/16 10:32 PM:
---------------------------------------------------------------
bq. What does Geo3D want instead?
It wants an angle. As I said, it currently uses radians for this. Conversion
from degrees is straightforward. Conversion from meters, on the other hand,
implies that you have to compute the inverse of the Vincenty distance (if you
want to do it accurately), or if your "distance" is in fact really the
spherical surface distance (what you guys are calling the "haversine
distance"), then it is a simple division.
bq. So it would be better to provide a Geo3DPoint class that has less
parameters (no PlanetModel), takes degrees (not radians), etc. It can
internally do any conversion that is needed to work with Geo3D.
That's fine as far as it goes but runs into two issues: (1) the distance
metric, and (2) how you specify shapes to search against. I proposed possibly
wrapping the shape factory methods too, but before that happens you will need
to inform me what measurements are meters and what are degrees. It really is
not obvious to me what the "obvious" choice is.
was (Author: kwri...@metacarta.com):
bq. What does Geo3D want instead?
It wants an angle. As I said, it currently uses radians for this. Conversion
from degrees is straightforward. Conversion from meters, on the other hand,
implies that you have to compute the inverse of the Vincenty distance (if you
want to do it accurately), or if your "distance" is in fact really the
spherical surface distance (what you guys are calling the "haversine distance",
then it is a simple division.
bq. So it would be better to provide a Geo3DPoint class that has less
parameters (no PlanetModel), takes degrees (not radians), etc. It can
internally do any conversion that is needed to work with Geo3D.
That's fine as far as it goes but runs into two issues: (1) the distance
metric, and (2) how you specify shapes to search against. I proposed possibly
wrapping the shape factory methods too, but before that happens you will need
to inform me what measurements are meters and what are degrees. It really is
not obvious to me what the "obvious" choice is.
> 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
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
