lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Desruisseaux (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-6196) Include geo3d package, along with Lucene integration to make it useful
Date Sun, 12 Apr 2015 21:03:12 GMT

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message