[
https://issues.apache.org/jira/browse/LUCENE-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538584#comment-14538584
]
Karl Wright commented on LUCENE-6450:
-------------------------------------
I agree that, to consider it seriously, geo3d would have to be moved to core.
So somebody would need to understand the benefit.
If that happens, though, I could foresee an almost-completely-parallel
implementation of the GeoPointField type, let's call it Geo3DPointField, which
would encode X,Y,Z instead of lat and lon. Almost all the same ideas and
architecture would work, AFAICT. The "cons" are that the index would be bigger
(3 floating values instead of two, etc.), and slower to build (more math). The
search, on the other hand, would be not much slower I believe.
As for the politics of ISO 19107, let's remember that FOSS4G exists to
implement standards. I'm interested, though, in the search problem, as are
you. And there's a world of difference between the cartesian view of things
and a 3D one. I think there's room for both.
> Add simple encoded GeoPointField type to core
> ---------------------------------------------
>
> Key: LUCENE-6450
> URL: https://issues.apache.org/jira/browse/LUCENE-6450
> Project: Lucene - Core
> Issue Type: New Feature
> Affects Versions: Trunk, 5.x
> Reporter: Nicholas Knize
> Priority: Minor
> Attachments: LUCENE-6450-5x.patch, LUCENE-6450-TRUNK.patch,
> LUCENE-6450.patch, LUCENE-6450.patch, LUCENE-6450.patch, LUCENE-6450.patch
>
>
> At the moment all spatial capabilities, including basic point based indexing
> and querying, require the lucene-spatial module. The spatial module, designed
> to handle all things geo, requires dependency overhead (s4j, jts) to provide
> spatial rigor for even the most simplistic spatial search use-cases (e.g.,
> lat/lon bounding box, point in poly, distance search). This feature trims the
> overhead by adding a new GeoPointField type to core along with
> GeoBoundingBoxQuery and GeoPolygonQuery classes to the .search package. This
> field is intended as a straightforward lightweight type for the most basic
> geo point use-cases without the overhead.
> The field uses simple bit twiddling operations (currently morton hashing) to
> encode lat/lon into a single long term. The queries leverage simple
> multi-phase filtering that starts by leveraging NumericRangeQuery to reduce
> candidate terms deferring the more expensive mathematics to the smaller
> candidate sets.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
