lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <>
Subject [jira] [Commented] (LUCENE-7150) geo3d public APIs should match the 2D apis?
Date Tue, 29 Mar 2016 21:41:25 GMT


Robert Muir commented on LUCENE-7150:

One problem at the moment is that all of geo3d works against a unit sphere/ellipsoid, and
uses units of radians.

But this is an implementation detail. Literally, no user cares about this.

The api should be simple: it should take common stuff that users have like latitude, longitude,
distance in meters. A user could care less what is happening behind the scenes!

It does not matter about esoteric use cases, it does not matter if this geo3d can be used
to model the earth the shape of an apple or to compute distance on jupiter’s rings.

We should provide one field: one that works on planet earth, takes lat,lon,meters, stuff like
that. Anything else can be a custom query.

> geo3d public APIs should match the 2D apis?
> -------------------------------------------
>                 Key: LUCENE-7150
>                 URL:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message