+1 ________________________________ From: Alan Woodward <[email protected]> Sent: Monday, June 25, 2018 5:56:16 PM To: [email protected] Subject: Re: [DISCUSS] Geo/spatial organization in Lucene
+1 to move LatLonPoint and friends to core, and nuke the spatial module On 25 Jun 2018, at 16:32, David Smiley <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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<http://blog.mikemccandless.com/> On Wed, Jun 20, 2018 at 1:00 PM, Nicholas Knize <[email protected]<mailto:[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]<mailto:[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]<mailto:[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<http://www.solrenterprisesearchserver.com/> -- Nicholas Knize | Geospatial Software Guy | Elasticsearch & Apache Lucene | [email protected]<mailto:[email protected]> -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com<http://www.solrenterprisesearchserver.com/>
