[
https://issues.apache.org/jira/browse/LUCENE-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259819#comment-15259819
]
Michael McCandless commented on LUCENE-7212:
--------------------------------------------
So the 2D world has now separated out doc values ({{LatLonDocValuesField}}),
used if you need distance sorting, from points ({{LatLonPoint}}), used if you
need filtering by shape.
It sounds like 3D can likely do the same? I.e., we don't need two-phase
support for geo3d shapes since the per-hit check is fast?
In which case ... we can do a more lossy (x/y/z -> 64 bits) encoding, solely
for distance sorting? Will the geo3d distance checking APIs be upset about the
heavy quantization (21 bits per value, instead of 32 bits per value points is
using)? I know we've had issues with "the point is not on the earth's surface"
already with 32 bits per x/y/z.
Alternatively, we could maybe use BINARY dvs, and keep 32 bits per component
... but this gets messy with multi-valued fields. geo2d
({{LatLonDocValuesField}}) does support multi-valued fields but I wonder how
necessary that really is ...
> Add Geo3DPoint equivalents of LatLonPointDistanceComparator and
> LatLonPointSortField
> ------------------------------------------------------------------------------------
>
> Key: LUCENE-7212
> URL: https://issues.apache.org/jira/browse/LUCENE-7212
> Project: Lucene - Core
> Issue Type: Improvement
> Affects Versions: master
> Reporter: Karl Wright
> Assignee: Karl Wright
>
> Geo3D has a number of distance measurements and a generic way of computing
> interior distance. It would be great to take advantage of that for queries
> that return results ordered by interior distance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
