lucene-dev mailing list archives

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


Ryan Ernst commented on LUCENE-7150:

bq. One problem at the moment is that all of geo3d works against a unit sphere/ellipsoid,
and uses units of radians.
bq. But this is an implementation detail. Literally, no user cares about this.

I agree this should be an implementation detail. Having all of these "solids" and stuff as
part of the public api just means 0.00001% will ever use this, and that is a lot of code to
keep around for such an esoteric use case.  Advanced users like that can still use eg PointsFormat
to index in multiple dimensions as their use case necessitates, but "geo" functionality should
really be simple for 99.9999% of users.  I'm happy that we have geo3d here, but I think the
name still needs to be clearer (this is *not* 3d that almost any user would ever think about)
and we need public apis (and those to be the *only* public apis) that operate the exact same
as the other sphere based lat/lon geo support we have (as the issue title implies).

> 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