Okay fine, I'm not going to block spatial stuff going into core. (celebration). I foresee the spatial stuff there growing beyond the one default impl though.
Perhaps most of us are still not happy with seeing spatial code across so many modules? Nick and I have voiced this concern so far. Given the pittance of utility of what's in the spatial module today, can we agree to simply remove it? I pity users trying to figure out what is where to make sense of it. I wonder how new users discover/browse to look around -- I'm too used to the codebase to have any idea what newbies do. That seems to be this: http://lucene.apache.org/core/7_3_1/index.html Each module only gets one terse sentence fragment. It'd be nice to have potentially a paragraph of information? Even without more verbage, the spatial ones could have better descriptions. I propose these changes: * spatial: remove it :-) -- see above * spatial3d: Computational geometry on the surface of a sphere or ellipsoid, including Lucene index & search solutions * spatial-extras: Spatial code that has external dependencies like Spatial4j and JTS, including Lucene index & search solutions perhaps "spatial-sphere" might be a more meaningful name than spatial3d? Yes, it's ellipsoidal but sphere is close enough ;-) ~ David On Mon, Jun 25, 2018 at 10:42 AM Michael McCandless < [email protected]> wrote: > I also favor B: move the common case, good performing spatial > implementations to core, but still bake new things in sandbox. LatLonPoint > has baked way too long already! The addition of first class (codec > support) KD trees in Lucene (dimensional points) was/is really a game > changer for Lucene supporting common geo spatial applications. > > It would be nice to find a better name than geo3d / spatial3d: it confuses > 100% of the people I explain it to, on first impression :) But we should > tackle that separately/later. > > Merging the 2D/3D abstractions sounds a little too ambitious at this > point, so I think it's fine to leave them separate for now. > > Mike McCandless > > http://blog.mikemccandless.com > > On Wed, Jun 20, 2018 at 1:00 PM, 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] >> > > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
