[
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: [email protected]):
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: [email protected]
For additional commands, e-mail: [email protected]
