Maybe it should be spatial2D vs. spatial3D then? To avoid sounding that spatial3D is a child of spatial.
Regards, Alex. On 22 June 2018 at 05:41, Karl Wright <[email protected]> wrote: > 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] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
