Nick, are you not only arguing for spatial code to be in Lucene core, but also for the "spatial" module to continue to exist? And I believe Adrien still wants some spatial stuff in sandbox so that means spatial code in 5 modules. Five modules... let that that sink in... wow. Gosh that's kinda overwhelming IMO.
Karl do you have any opinions about this stuff? I don't know what your opinions are, come to think of it. ~ David On Wed, Jun 20, 2018 at 1:01 PM Nicholas Knize <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 | Book: >>> http://www.solrenterprisesearchserver.com >>> >> -- > Nicholas Knize | Geospatial Software Guy | Elasticsearch & Apache > Lucene | [email protected] > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
