[
https://issues.apache.org/jira/browse/LUCENE-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538373#comment-14538373
]
Karl Wright edited comment on LUCENE-6450 at 5/11/15 6:41 PM:
--------------------------------------------------------------
bq. That would require it be decoupled from the spatial module and committed
stand alone to a core.geometry package. (maybe not a bad idea?)
It's only loosely coupled to the spatial module right now. There's a single
class integrating it with spatial4j (not counting the random tests).
bq. but in that case I'd point out that most cartographers/photogrammetrists
would still consider geo3d inaccurate since the sphere is not an accurate
representation of the earth's surface.
Most GIS code can readily map a point on an earth model to a point on a sphere.
And even if you don't do that, and just use the sphere, your accuracy for
whether a given lat/lon is within a given shape is a few meters at most.
Whereas the error for a cartesian projection can be thousands of kilometers.
And, there's all sorts of edge cases when you cross the date line or go near a
pole. Given that geo3d is also designed to be very fast, and equally
compatible with geohash construction, I would think you might be interested in
integrating your simple geopoint proposal with it.
was (Author: kwri...@metacarta.com):
bq. That would require it be decoupled from the spatial module and committed
stand alone to a core.geometry package. (maybe not a bad idea?)
It's only loosely coupled to the spatial module right now. There's a single
class integrating it with spatial4j (not counting the random tests).
bq. but in that case I'd point out that most cartographers/photogrammetrists
would still consider geo3d inaccurate since the sphere is not an accurate
representation of the earth's surface.
Most GIS code can readily map a point on an earth model to a point on a sphere.
And even if you don't do that, and just use the sphere, your accuracy for
whether a given lat/lon is within a given shape is a few meters at most.
Whereas the error for a cartesian projection can be thousands of kilometers.
Given that geo3d is also designed to be very fast, and equally compatible with
geohash construction, I would think you might be interested in integrating your
simple geopoint proposal with it.
> 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
