+1 On Mon, Jun 25, 2018, 11:32 AM Ignacio Vera Sequeiros <iv...@eso.org> wrote:
> +1 > ------------------------------ > *From:* Alan Woodward <romseyg...@gmail.com> > *Sent:* Monday, June 25, 2018 5:56:16 PM > *To:* dev@lucene.apache.org > > *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 <david.w.smi...@gmail.com> 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 < > luc...@mikemccandless.com> 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 <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 > > > -- Nicholas Knize | Geospatial Software Guy | Elasticsearch & Apache Lucene | nkn...@apache.org
