[ https://issues.apache.org/jira/browse/LUCENE-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14538373#comment-14538373 ]
Karl Wright commented on LUCENE-6450: ------------------------------------- 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