[
https://issues.apache.org/jira/browse/LUCENE-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217034#comment-15217034
]
Robert Muir commented on LUCENE-7150:
-------------------------------------
I think as a start haversin would be nice? It would at least allow us to do
some nice comparisons with the other geo impls. I too am curious about
performance of not just distance but also things like polygon queries.
Remember, we can always provide 'alternatives' at a later point or more
advanced apis. We can always add Geo3DAdvancedPoint in the future with wider
apis (e.g. taking planetmodel or using an ellipsoid model/vincenty/whatever),
or add additional methods. Its just as a start we need a sorta dumb-downed/very
simple lucene integration to start exploring the differences e.g. in query
performance and so on.
So I think we should steer in the direction of simplicity, make it brain dead
simple, and hard for someone to mess up (like us, trying to run benchmarks). We
have to start somewhere...
> 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
