+1
On Mon, Jun 25, 2018 at 12:46 PM Nicholas Knize <[email protected]> wrote: > +1 > > On Mon, Jun 25, 2018, 11:32 AM Ignacio Vera Sequeiros <[email protected]> > wrote: > >> +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]> 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]> 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 >> >> >> -- > Nicholas Knize | Geospatial Software Guy | Elasticsearch & Apache > Lucene | [email protected] >
