+1 to move LatLonPoint and friends to core, and nuke the spatial module
> On 25 Jun 2018, at 16:32, David Smiley <david.w.smi...@gmail.com> wrote: > > Okay fine, I'm not going to block spatial stuff going into core. > (celebration). I foresee the spatial stuff there growing beyond the one > default impl though. > > Perhaps most of us are still not happy with seeing spatial code across so > many modules? Nick and I have voiced this concern so far. Given the > pittance of utility of what's in the spatial module today, can we agree to > simply remove it? > > I pity users trying to figure out what is where to make sense of it. I > wonder how new users discover/browse to look around -- I'm too used to the > codebase to have any idea what newbies do. That seems to be this: > http://lucene.apache.org/core/7_3_1/index.html > <http://lucene.apache.org/core/7_3_1/index.html> Each module only gets one > terse sentence fragment. It'd be nice to have potentially a paragraph of > information? Even without more verbage, the spatial ones could have better > descriptions. I propose these changes: > > * spatial: remove it :-) -- see above > * spatial3d: Computational geometry on the surface of a sphere or ellipsoid, > including Lucene index & search solutions > * spatial-extras: Spatial code that has external dependencies like Spatial4j > and JTS, including Lucene index & search solutions > > perhaps "spatial-sphere" might be a more meaningful name than spatial3d? > Yes, it's ellipsoidal but sphere is close enough ;-) > > ~ David > > On Mon, Jun 25, 2018 at 10:42 AM Michael McCandless > <luc...@mikemccandless.com <mailto:luc...@mikemccandless.com>> wrote: > I also favor B: move the common case, good performing spatial implementations > to core, but still bake new things in sandbox. LatLonPoint has baked way too > long already! The addition of first class (codec support) KD trees in Lucene > (dimensional points) was/is really a game changer for Lucene supporting > common geo spatial applications. > > It would be nice to find a better name than geo3d / spatial3d: it confuses > 100% of the people I explain it to, on first impression :) But we should > tackle that separately/later. > > Merging the 2D/3D abstractions sounds a little too ambitious at this point, > so I think it's fine to leave them separate for now. > > Mike McCandless > > http://blog.mikemccandless.com <http://blog.mikemccandless.com/> > > On Wed, Jun 20, 2018 at 1:00 PM, Nicholas Knize <nkn...@gmail.com > <mailto:nkn...@gmail.com>> wrote: > If I were to pick between the two, I also have a preference for B. I've also > tried to keep this whole spatial organization rather simple: > > core - simple spatial capabilities needed by the 99% spatial use case (e.g., > web mapping). Includes LatLonPoint, polygon & distance search (everything > currently in sandbox). Lightweight, and no dependencies or complexities. If > one wants simple and fast point search, all you need is the core module. > > spatial - dependency free. Expands on core spatial to include simple shape > searching. Uses internal relations. Everything confined to core and spatial > modules. > > spatial-extras - expanded spatial capabilities. Welcomes third-party > dependencies (e.g., S3, SIS, Proj4J). Targets more advanced/expert GIS > use-cases. > > geo3d - trades speed for accuracy. I've always struggled with the name, since > it implies 3D shapes/point cloud support. But history has shown considering a > name change to be a bike-shedding endeavor. > > At the end of the day I'm up for whatever makes most sense for everyone here. > Lord knows we could use more people helping out on geo. > > - Nick > > > > On Wed, Jun 20, 2018 at 11:40 AM Adrien Grand <jpou...@gmail.com > <mailto:jpou...@gmail.com>> wrote: > I have a slight preference for B similarly to how StandardAnalyzer is in core > and other analyzers are in analysis, but no strong feelings. In any case I > agree that both A and B would be much better than the current situation. > > > Le mer. 20 juin 2018 à 18:09, David Smiley <david.w.smi...@gmail.com > <mailto:david.w.smi...@gmail.com>> a écrit : > I think everyone agrees the current state of spatial code organization in > Lucene is not desirable. We have a spatial module that has almost nothing in > it, we have mature spatial code in the sandbox that needs to "graduate" > somewhere, and we've got a handful of geo utilities in Lucene core (mostly > because I didn't notice). No agreement has been reached on what the desired > state should be. > > I'd like to hear opinions on this from members of the community. I am > especially interested in listening to people that normally don't seem to > speak up about spatial matters. Perhaps Uwe Schindlerand Alan Woodward – I > respect both of you guys a ton for your tenure with Lucene and aren't too > pushy with your opinions. I can be convinced to change my mind, especially if > coming from you two. Of course anyone can respond -- this is an open > discussion! > > As I understand it, there are two proposals loosely defined as follows: > > (A) Common spatial needs will be met in the "spatial" module. The Lucene > "spatial" module, currently in a weird gutted state, should have basically > all spatial code currently in sandbox plus all geo stuff in Lucene core. Thus > there will be no geo stuff in Lucene core. > > (B) Common spatial needs will be met by Lucene core. Lucene core should > expand it's current "geo" utilities to include the spatial stuff currently in > the sandbox module. It'd also take on what little remains in the Lucene > spatial module and thus we can remove the spatial module. > > With either plan if a user has certain advanced/specialized needs they may > need to go to spatial3d or spatial-extras modules. These would be untouched > in both proposals. > > I'm in favor of (A) on the grounds that we have modules for special feature > areas, and spatial should be no different. My gut estimation is that 75-90% > of apps do not have spatial requirements and need not depend on any spatial > module. Other modules are probably used more (e.g. queries, suggest, etc.) > > Respectfully, > ~ David > > p.s. if I mischaracterized any proposal or overlooked another then I'm sorry, > please correct me. > -- > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker > LinkedIn: http://linkedin.com/in/davidwsmiley > <http://linkedin.com/in/davidwsmiley> | Book: > http://www.solrenterprisesearchserver.com > <http://www.solrenterprisesearchserver.com/>-- > Nicholas Knize | Geospatial Software Guy | Elasticsearch & Apache Lucene > | nkn...@apache.org <mailto:nkn...@apache.org> > > -- > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker > LinkedIn: http://linkedin.com/in/davidwsmiley > <http://linkedin.com/in/davidwsmiley> | Book: > http://www.solrenterprisesearchserver.com > <http://www.solrenterprisesearchserver.com/>
