[
https://issues.apache.org/jira/browse/LUCENE-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538618#comment-14538618
]
Nicholas Knize commented on LUCENE-6450:
----------------------------------------
bq. 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.
+++1 This was the intent of the PackedQuadTree patch for lucene spatial and
can certainly be added to core. Add a 3d morton encoding to GeoUtils using 3
bits. Thus naive morton Hypercube ordering w/ 0/1 representing Left/Right ||
Bottom/Top || Front/Hind at level 1 gives 000:111. This is where locality
really matters though, so phase 2 would extend this into something more
organized, e.g., Hilbert ordering at level 1 is: 010, 011, 111, 110, 100, 101,
001, 000. There are numerous issues with this; ordering becomes non-trivial,
encoded values do not fit nicely in Longs, term size becomes larger.
But I agree, I don't believe search will be much slower. The first phase here
is to investigate improving this patch w/ Auto-prefix. I think if we can get
that working and leave prefix matching to the automaton then the hardest part
becomes optimizing the encoding? Maybe I'll open an issue around this for
separate discussion so as to not dilute this issues comments.
On topic here; I propose we sandbox geo3d along w/ these field types. Get
something incubated before proposing the addition to core?
> 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]
