The abstractions in spatial3d are not the same abstractions as you find in spatial, and yet they sound similar. So I'd worry that if we threw them together we'd be setting ourselves up for a shotgun marriage at some point. I would strongly disagree that that was in any way a good idea.
The fundamental difference between the two is one treats the world as a 2D surface, and the other treats the world as an actual ellipsoid. So it's not just about numeric accuracy, since lines in 2D are not the proper great circles, and there are singularities at the poles. Karl On Fri, Jun 22, 2018 at 4:44 AM Alan Woodward <[email protected]> wrote: > 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 <[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] > > >
