[
https://issues.apache.org/jira/browse/LUCENE-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15121761#comment-15121761
]
Nicholas Knize edited comment on LUCENE-6997 at 1/28/16 4:12 PM:
-----------------------------------------------------------------
bq. What's missing, in your opinion? And did you actually mean Spatial4j? FYI
JTS as of yesterday is licensed BSD.
Hey wonderful! I actually meant JTS. Last conversation I had with Martin he
wasn't confident in a friendly timeline for relicense. I think the larger
discussion re: dependencies is still relevant? Unless there's a blacklist
somewhere of licenses we will always reject.
bq. I think Maven "optional" dependencies are for uses cases where you need a
class only at compile time (mandatory), but consumer (runtime) may not need it,
Its likely I misunderstood this so this clarification will certainly help. I
thought Java's module system is changing in Java 9 such that it needs all
dependencies at runtime (even if the dependencies are not used)? That's the
relevancy of Java 9 in the discussion.
was (Author: nknize):
bq. What's missing, in your opinion? And did you actually mean Spatial4j? FYI
JTS as of yesterday is licensed BSD.
Hey wonderful! I actually meant JTS. Last conversation I had with Martin he
wasn't confident in a friendly timeline for relicense. I think the larger
discussion re: dependencies is still relevant? Unless there's a blacklist
somewhere of licenses we will always reject.
bq. I think Maven "optional" dependencies are for uses cases where you need a
class only at compile time (mandatory), but consumer (runtime) may not need it,
Its likely I misunderstood this so this clarification will certainly help. I
thought Java's module system is changing in Java 9 such that it needs all
dependencies at runtime? That's the relevancy of Java 9 in the discussion.
> 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
