[
https://issues.apache.org/jira/browse/LUCENE-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15120317#comment-15120317
]
Nicholas Knize commented on LUCENE-6997:
----------------------------------------
bq. ...can you explain better? I'm unfamiliar with restrictions imposed by
sandbox.
I had the understanding the sandbox module provides no backwards compatibility.
Not "it doesn't guarantee backwards compatibility" but there is "NO backwards
compatibility". Other modules do not have this restriction. In this particular
case the restriction makes it difficult/impossible to experiment and evolve
alternative postings based encoding methods without adding some crazy
abstraction layer (that just masks backcompat), or duplicating code and (like
codecs) changing class names.
bq. ...doesn't depend on Spatial4j (what I assume you imply by "dependency
free")
Just no dependencies whatsoever, be them optional or not (to include JTS or
future dependencies).
bq. I don't think that need be fundamental to the spatial module's future.
I agree. While the GeoUtils API is really close to being able to remove the JTS
dependency there are some Apache friendly libraries I think would really boost
lucene-spatial's capabilities. And IMHO that's what defines the lucene-spatial
module. A provider of the more advanced GIS capabilities with dependencies from
only "friendly" licenses (I'm not a lawyer so I don't know what this list would
include).
bq. From a maven standpoint, they could be marked "optional".
I think that's part of the benefits for having a lightweight dependency free
module. I was told (and did some quick research - a la elgoog) that optional
dependencies are no longer going to be supported by Java 9? I'm sure someone
far smarter than me on Java 9 can chime in but if class A depends on B which
optionally depends on C you can no longer include B without C? Sounds like that
will break the current Spatial4J / JTS model? Also Optional dependencies aren't
well supported for build systems other than maven (e.g., gradle)? I'm certainly
not a gradle expert (by any means) but I know I've seen this as enough of a
headache in the past that gradle users try to avoid them unless necessary.
To me these seem like compelling reasons to split the complexity of spatial
into a lightweight dependency free core module that can be leveraged by modules
that either do or do not have a dependency restriction.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
