[
https://issues.apache.org/jira/browse/LUCENE-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15120052#comment-15120052
]
David Smiley commented on LUCENE-6997:
--------------------------------------
It's good to see this wonderful work graduating out of sandbox, Nick.
bq. This will allow support for experimental encoding methods with (minimal)
backwards compatibility - something sandbox does not allow.
Just curious but can you explain better? I'm unfamiliar with restrictions
imposed by sandbox.
bq. Since GeoPoint classes are dependency free, all GeoPointField and support
and utility classes currently in sandbox would be promoted to the spatial3d
package. (possibly a separate issue to rename spatial3d to spatialcore or
spatiallite?) Such that for basic lightweight Geo support one would only need a
handful of lucene jars. By simply adding the lucene-spatial module and its
dependency jars users can obtain more advanced geospatial support (heatmap
facets, full shape relations, etc).
I know spatial3d doesn't depend on Spatial4j (what I assume you imply by
"dependency free") but I don't think that's what defines this module -- it's
the Geo3d code and hence it's name. So I don't think GeoPointField would make
sense there at all. And I think wherever Geo3d lives, it should have a name
reflective of what it is; "spatialcore" or some-such is IMO not a good name.
I'd even like to see it not have any dependency whatsoever; the Lucene Field &
Query adapters could go to the lucene-spatial module. This would make it
easier for external (non-Lucene) consumption. It's very odd to me they even
share the same Java package today; that used to not be the case.
Much of the lucene-spatial module currently has a dependency on Spatial4j, and
one part of it has a dependency on Geo3d/spatial3d (Geo3dShape.java) but I
don't think that need be fundamental to the spatial module's future. In other
words, just because there are parts of the lucene-spatial module that have
certain dependencies doesn't mean there could/should be new things to add to
the module that don't have those dependencies, and thus user's needn't add such
dependencies to their classpath. From a maven standpoint, they could be marked
"optional". This would be a bit of a renaissance to the module; a very welcome
one IMO. What do you think?
> Graduate GeoUtils and postings based GeoPointField from sandbox...
> ------------------------------------------------------------------
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Nicholas Knize
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field
> currently in sandbox. It has evolved into a very fast lightweight geo option
> that heavily leverages the optimized performance of the postings structure.
> It was originally intended to graduate to core but this does not seem
> appropriate given the variety of "built on postings" term encoding options
> (e.g., see LUCENE-6930).
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight
> relational approximation utilities used by both {{GeoPointField}} and the BKD
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial
> module.
> These classes have been evolving and baking for some time and are at a
> maturity level qualifying for promotion from sandbox. This will allow support
> for experimental encoding methods with (minimal) backwards compatibility -
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and
> utility classes currently in sandbox would be promoted to the spatial3d
> package. (possibly a separate issue to rename spatial3d to spatialcore or
> spatiallite?) Such that for basic lightweight Geo support one would only need
> a handful of lucene jars. By simply adding the lucene-spatial module and its
> dependency jars users can obtain more advanced geospatial support (heatmap
> facets, full shape relations, etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
