[
https://issues.apache.org/jira/browse/LUCENE-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538465#comment-14538465
]
Nicholas Knize commented on LUCENE-6450:
----------------------------------------
bq. It's only loosely coupled to the spatial module right now.
I've seen the code. Its well designed. My point is that its in the spatial
module right now. It would need to be taken out of the spatial module for it to
be usable in core and by this patch. Sounds like a separate issue for lucene
committer buy in.
bq. Most GIS code can readily map a point on an earth model to a point on a
sphere.
I'm not arguing with you. My point refers to the, maybe 2%, class of lucene geo
users you mentioned. Those same Cartographers that would counter-argue that
geo3d is not ISO 19107 compliant so sphere accuracy is not good enough for them
(enjoy those passionate discussions at FOSS4G). Don't misunderstand me - I'm
not calling your baby ugly. There's great stuff there and I'm all for
investigating using it to improve the simple approach in this patch. In the
meantime, since it sounds like accuracy concerns for the large poly use case
are for real?, it might be easier just to add the few lines of mercator
re-projection code to the post-filter and investigate using geo3d in a phase 2
performance improvement (if it becomes available 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
