I don’t normally speak up on spatial issues because I don’t know anything about spatial stuff, but I suppose a point of view from somebody outside the code may be helpful, so…
I think I’d lean towards B. Having the 99% case in core makes most sense to me, and it means that we can add some pointers to the search package-info to make it easier for people starting out. Common interfaces in core make it easier to put specialist classes into separate modules without having cross-dependencies. I’m not sure that having separate ‘spatial’ and ‘spatial3d’ modules is particularly useful, though. I’d combine these into a single module, with clear package docs explaining what each part is useful for - fast shape searching vs high-precision, etc. I spent a bit of time in the spatial-extras code last year when I was working on replacing ValueSource. One question I have, again as an outsider to all this, is this: are there still circumstances where indexing spatial data into the terms index, as spatial-extras does, is better in terms of accuracy or performance than using the Points API? Or should we think about spatial-extras as we do about the legacy numeric encodings, and direct users to LatLonPoint or the geo3d classes instead? It’s not at all clear to me what the trade-offs are here. - Alan > On 20 Jun 2018, at 18:00, Nicholas Knize <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>
