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 22:15:25 GMT


Ryan Ernst commented on LUCENE-7150:

bq. It escapes me why degrees and distance in meters is a "natural" measurement. To me, that's
an arbitrary decision that somebody made (here). 

It is the way humans have viewed distance and location for hundreds of years.

bq. If your notion of a geometric query is only all documents within circles with a center
then I challenge that – it's very very limiting and would not handle polygons, paths, rectangles,
or any of the other many variants of areas somebody may well want to search within.

Of course I think users should be able to express queries (and indexed values!) with these
concepts. But for a user to have to use do the conversion themselves from the standard units
we describe locations on earth with into a spheroid location is asking too much, they will
never use it.

> 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