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]
