lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicholas Knize (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LUCENE-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...
Date Thu, 28 Jan 2016 15:53:39 GMT

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


Mime
View raw message