[
https://issues.apache.org/jira/browse/LUCENE-6480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14542001#comment-14542001
]
Karl Wright edited comment on LUCENE-6480 at 5/13/15 2:28 PM:
--------------------------------------------------------------
bq. The question is the max value of the altitude?
To clarify, geo3d is not using (lat,lon,altitude) tuples. When I said (x,y,z)
I meant unit sphere (x,y,z), where z = sin(lat), x = cos(lat)**cos(lon), y =
cos(lat)**sin(lon). The reason you'd want to pack (x,y,z) instead of just
(lat,lon) is that computing cosines and sines is quite expensive, so you don't
want to be constructing a geo3d.GeoPoint using lat/lon at document scoring
time. Instead you'd want to unpack the (x,y,z) values directly from the
Geo3DPointField. The range of *all three* parameters in this case is -1 to 1,
which is how I came up with the packing resolution I did.
bq. Locality is important since it will drive the complexity of the range
search and how much the postings list will actually help
The reason you need (x,y,z) instead of (lat,lon) at scoring time is because
geo3d determines whether a point is within the shape using math that requires
points to be in that form. If you do that, then the evaluation of membership
is blindingly fast. The splitting proposal does have locality.
was (Author: [email protected]):
bq. The question is the max value of the altitude?
To clarify, geo3d is not using (lat,lon,altitude) tuples. When I said (x,y,z)
I meant unit sphere (x,y,z), where z = sin(lat), x = cos(lat)*cos(lon), y =
cos(lat)*sin(lon). The reason you'd want to pack (x,y,z) instead of just
(lat,lon) is that computing cosines and sines is quite expensive, so you don't
want to be constructing a geo3d.GeoPoint using lat/lon at document scoring
time. Instead you'd want to unpack the (x,y,z) values directly from the
Geo3DPointField. The range of *all three* parameters in this case is -1 to 1,
which is how I came up with the packing resolution I did.
bq. Locality is important since it will drive the complexity of the range
search and how much the postings list will actually help
The reason you need (x,y,z) instead of (lat,lon) at scoring time is because
geo3d determines whether a point is within the shape using math that requires
points to be in that form. If you do that, then the evaluation of membership
is blindingly fast. The splitting proposal does have locality.
> Extend Simple GeoPointField Type to 3d
> ---------------------------------------
>
> Key: LUCENE-6480
> URL: https://issues.apache.org/jira/browse/LUCENE-6480
> Project: Lucene - Core
> Issue Type: New Feature
> Components: core/index
> Reporter: Nicholas Knize
>
> [LUCENE-6450 | https://issues.apache.org/jira/browse/LUCENE-6450] proposes a
> simple GeoPointField type to lucene core. This field uses 64bit encoding of 2
> dimensional points to construct sorted term representations of GeoPoints
> (aka: GeoHashing).
> This feature investigates adding support for encoding 3 dimensional
> GeoPoints, either by extending GeoPointField to a Geo3DPointField or adding
> an additional 3d constructor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
