[
https://issues.apache.org/jira/browse/LUCENE-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15123704#comment-15123704
]
David Smiley commented on LUCENE-6997:
--------------------------------------
It seems this has more to do with the presence of external dependencies than
trying to define what "lite" is vs "heavy" (very contentious / subjective), and
enumerating the number of abstractions. Geo3d has a ton of abstractions (I
forget them often) yet we're not advocating moving them into lucene-spatial.
Geo3d is a gem. By itself, it depends on nothing but Java; it's not a Lucene
thing, its a math thing :-). So long as Geo3d stays with us hosted in our
project, I really strongly want to see it remain in its own module -- and it
mostly is right now, notwithstanding some Lucene bits that IMO really ought to
be separated either by package and module. This enables other projects out
there to use it more easily by itself, and to some extent helps with
establishing its identity. That identity would be lost if it was mixed into a
jar file of unrelated stuff. As it is, it's jar/module is "spatial3d" yet has
package (and original name) as "geo3d". That'll make finding it harder for
people in the wild who are looking for it and not Lucene.
Here's a compromise proposal with respect to non-Geo3d stuff. Perhaps have the
current spatial module be renamed to "lucene-spatial-spatial4j" and then all
the other cool spatial stuff you two have been working on goes into the name
"lucene-spatial" (the current name). This frees us from subjective discussions
about what constitutes "heavy" vs "light" or "advanced" vs "simple" -- you're
free to do whatever "advanced" (non-lite) stuff you want in the new
lucene-spatial module. I do suggest we keep that module dependency-free (other
than Lucene of course). That could be the main differentiator -- dependencies
or no dependencies. I'm not in love with the module name
"lucene-spatial-spatial4j"... maybe "lucene-spatial-deps" or -s4j or I dunno.
IMO the Lucene bits in the spatial3d module should go here too as I view Geo3d
as a standalone thing and not Lucene. This module would depend on spatial3d.
What do you think guys?
> 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
