Sorry, I just returned from an overseas trip. I'll try to put some thought into a cogent response when I get a little less scrambled.
Karl On Fri, Jun 22, 2018 at 4:16 PM David Smiley <david.w.smi...@gmail.com> wrote: > 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 <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> 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> 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 | nkn...@apache.org >> > -- > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: > http://www.solrenterprisesearchserver.com >
