[
https://issues.apache.org/jira/browse/LUCENE-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14511182#comment-14511182
]
Nicholas Knize commented on LUCENE-6450:
----------------------------------------
bq. ds. particularly once a point-radius (circle) query is added. Did you
forget or are you planning to add that in the future? The other super-common
use-case is distance sorting...
I'm working on adding both point-radius query and distance sorting. I wanted to
get the first version out for initial feedback. Seemed to work out nicely with
all of the great suggestions so far.
bq. uwe: so shifted terms will never appear. I just have the question (why do
this?).
Space-filling curves are highly sensitive to precision - especially the morton
or lebesgue curve since they don't do a great job of preserving locality.
Indexing reduced precision terms can lead to (potentially significant) false
positives (with nonlinear error). Here's a great bl.ock visualizing the range
query from a bounding box over a morton curve:
http://bl.ocks.org/jaredwinick/raw/5073432/ For an average example: encoding
32.9482, -96.4538 with step = 32 results in two terms/geo points that are >500m
a part. The error gets worse as this precision step is lowered. With the single
high precision encoded term the error is 1e-7 decimal degrees.
bq. mm: Is there a requirement that these poly points are clockwise or
counter-clockwise order or something?
There is. The points have to be cw or ccw and the polygon cannot be
self-crossing. It won't throw any exceptions, it just won't behave as
expected. I went ahead and updated the javadoc comment to make sure that is
clear.
bq. mm: For GeoPolygonQuery, why do we have public factory method that takes
the bbox? Shouldn't this be private (bbox is computed from the polygon's
points)? Or is this for expert usage or something?
The idea here is that polygons can contain a significant number of points, and
users may already have the BBox (cached or otherwise precomputed). I thought
this provided a nice way to save unnecessary processing if the caller can
provide the bbox.
bq. ds: Have you thought about a way to use GeoPointFieldType with
pre-projected data
Yes, this can potentially be left as an enhancement but the intent is to have
this apply to the most basic use cases. So I'm curious as to what the other's
think about adding this capability or just leaving that to the spatial module.
bq. ds: GeoPointFieldType has DocValues enabled yet I see that these queries
don't use that; or did I miss something?
Not using them yet. The intent was to use them for sorting.
bq. ds: I would love to see some randomized testing of round-trip encode-decode
of the morton numbers.
Agree. I'll be adding randomized testing for sure.
> 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: 5.x
> Reporter: Nicholas Knize
> Priority: Minor
> Attachments: 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, GeoPolygonQuery, and GeoDistanceQuery 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
