[
https://issues.apache.org/jira/browse/LUCENE-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491718#comment-14491718
]
Martin Desruisseaux commented on LUCENE-6196:
---------------------------------------------
I had a quick look at the new classes. I would like to mention one possibility
in case it may be of interest. I saw various classes related to a
latitude/longitude bounding box. If a dependency toward the GeoAPI interfaces
is considered acceptable (GeoAPI is a translation of some international
standards into Java interfaces, and is [published by the Open Geospatial
Consortium|http://www.opengeospatial.org/standards/geoapi/]), then those
classes could implement the [Envelope
interface|http://www.geoapi.org/3.0/javadoc/org/opengis/geometry/Envelope.html].
The {{getCoordinateReferenceSystem()}} method could return {{null}} for now,
but this would keep the door open for connecting the Geo3D bounding box to a
map reprojection engine in a future version if desired. For example if a future
Geo3D version returns a non-null value, then the Apache SIS [reprojection
method|http://sis.apache.org/apidocs/org/apache/sis/geometry/Envelopes.html#transform-org.opengis.geometry.Envelope-org.opengis.referencing.crs.CoordinateReferenceSystem-]
could work directly with those Geo3D classes. If a GeoAPI dependency is
considered not desirable at this time, just checking that there is no
incompatibility between the Geo3D classes and {{Envelope}} API may help to keep
the door open.
By the way, the Geo3D documentation said that it works with latitude/longitude
in radians, but I saw no mention of which geographic system (there is many,
with differences up to 3 kilometres between them - ignoring those who do not
use Greenwich as their prime meridian). This is the kind of information which
is normally provided by {{Envelope.getCoordinateReferenceSystem()}}, but
otherwise just a note in the documentation may help. I presume that Geo3D
implies the WGS84 system?
> Include geo3d package, along with Lucene integration to make it useful
> ----------------------------------------------------------------------
>
> Key: LUCENE-6196
> URL: https://issues.apache.org/jira/browse/LUCENE-6196
> Project: Lucene - Core
> Issue Type: New Feature
> Components: modules/spatial
> Reporter: Karl Wright
> Assignee: David Smiley
> Attachments: LUCENE-6196_Geo3d.patch, ShapeImpl.java,
> geo3d-tests.zip, geo3d.zip
>
>
> I would like to explore contributing a geo3d package to Lucene. This can be
> used in conjunction with Lucene search, both for generating geohashes (via
> spatial4j) for complex geographic shapes, as well as limiting results
> resulting from those queries to those results within the exact shape in
> highly performant ways.
> The package uses 3d planar geometry to do its magic, which basically limits
> computation necessary to determine membership (once a shape has been
> initialized, of course) to only multiplications and additions, which makes it
> feasible to construct a performant BoostSource-based filter for geographic
> shapes. The math is somewhat more involved when generating geohashes, but is
> still more than fast enough to do a good job.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
