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