You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Karl Wright (JIRA)" <ji...@apache.org> on 2016/04/13 15:24:25 UTC
[jira] [Comment Edited] (LUCENE-7212) Add Geo3DPoint equivalents of
LatLonPointDistanceComparator and LatLonPointSortField
[ https://issues.apache.org/jira/browse/LUCENE-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15239219#comment-15239219 ]
Karl Wright edited comment on LUCENE-7212 at 4/13/16 1:24 PM:
--------------------------------------------------------------
bq. Ideally we wouldn't need to expose things like GeoDistance and DistanceStyle to the user? Can these somehow be under-the-hood implementation details?
The classes that correspond to LatLonPointDistanceComparator and LatLonPointSortField will need to have a GeoDistance and DistanceStyle passed to them.
The newDistanceSort method would need to be equivalent to the LatLonPoint API, so it would construct a GeoCircle that occupies the whole world with the specified center, and use a standard arc distance DistanceStyle. But the problem is that such a query is completely unconstrained without the ability to go from shape/distance to XYZSolid bound, so it would not perform reasonably in that form. If you introduced an upper bound to the circle radius as an additional argument, then it would work fine without additional geo3d code.
I would in general think that all "newXXXQuery" methods would have a corresponding "newXXXSort" method, if the underlying shape implements GeoDistance. So there would be "newDistanceSort" and "newPathSort", but not "newBoxSort" or "newPolygonSort". The arguments would have to correspond exactly, though, to "newXXXQuery", including distance bounds, for the geo3d API.
was (Author: kwright@metacarta.com):
bq. Ideally we wouldn't need to expose things like GeoDistance and DistanceStyle to the user? Can these somehow be under-the-hood implementation details?
The classes that correspond to {code}LatLonPointDistanceComparator{code} and {code}LatLonPointSortField{code} will need to have a {code}GeoDistance{code} and {code}DistanceStyle{code} passed to them.
The {code}newDistanceSort{code} method would need to be equivalent to the LatLonPoint API, so it would construct a GeoCircle that occupies the whole world with the specified center, and use a standard arc distance DistanceStyle. But the problem is that such a query is completely unconstrained without the ability to go from shape/distance to XYZSolid bound, so it would not perform reasonably in that form. If you introduced an upper bound to the circle radius as an additional argument, then it would work fine without additional geo3d code.
I would in general think that all "newXXXQuery" methods would have a corresponding "newXXXSort" method, if the underlying shape implements GeoDistance. So there would be "newDistanceSort" and "newPathSort", but not "newBoxSort" or "newPolygonSort". The arguments would have to correspond exactly, though, to "newXXXQuery", including distance bounds, for the geo3d API.
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org