You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Karl Wright (JIRA)" <ji...@apache.org> on 2016/03/30 00:32:25 UTC
[jira] [Comment Edited] (LUCENE-7150) geo3d public APIs should
match the 2D apis?
[ 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: kwright@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org