On Tue, Apr 5, 2011 at 2:46 PM, Grant Ingersoll <gsing...@apache.org> wrote: > > On Apr 3, 2011, at 3:50 PM, Ryan McKinley wrote: >> If we do elect for option A, I would also suggest we delete the >> spatial contrib (in 4.0) and have solr depend on the external .jar -- >> this way lucene users would have what they need directly with the >> external .jar, and solr users would get lots of fancy new stuff >> off-the-shelf. > > > At the end of the day, Solr only uses a few methods in the Lucene contrib: > the geohash stuff and a few other distance utils (some static methods that I > moved from Solr down to Lucene). That's about it. Everything else is just > FieldTypes and function queries (the tier stuff is broken b/c of the > sinusoidal projection impl. and I didn't see a need for the geometry stuff). > If we move function queries to modules, those utils could just be hidden in > there (or they could just be put in Solr for that matter if function queries > stay where they are) and there would be no need for any external dependency. > Then, there is no spatial package at all and anyone who wishes to work on > Spatial can go do it in the proposed external project if they need anything > beyond point search. >
The spatial API in google code takes a pretty different approach to spatial search in general. It is organized into three key packages: 1. core stuff, no lucene dependencies. Most of the math is here 2. lucene stuff 3. solr interface -- configure and manage the lucene implementations It does not rely on function queries (it will use ValueSorceQuery when necessary). The solr integration is handled via FieldType.getFieldQuery() This way we can send complex queries in the regular 'q' param or an 'fq' (or even a function query) -- syntax looks like: q=geo:"Operation( shape )" Operation is one of: BBoxIntersects BBoxWithin Contains Intersects IsEqualTo IsDisjointTo Overlaps SimilarTo And the same is either a point, bbox, point+radius, or complex polygon q=geofield:"Intersects( -10 20 -10 20 )" q=geofield:"IsWithin( PointDistance( x y distance )" q=geofield:"Intersects( POLYGON ((30 10, ...)) )" Different fields can be indexed with different strategies, but the interface stays the same > Nothing wrong with that, of course, people can do as they wish, it's just why > I would prefer a single solution as part of our modules. Hypothetically, if a stable Apache licensed spatial module were released by a reputable 3rd party foundation (osgeo.org) are you against including it in solr as a .jar? It could get tested directly in solr framework the same we do with carrot2 and tika. Assuming the legal stuff is up-to-snuff and the build is solid, I'm confused why spatial support for lucene needs to be in lucene modules? > If SIS or something else w/ a better license was as mature as JTS, we >probably wouldn't even be having the discussion. > There is more to it then that -- the JTS license issue just slams the issue to the forefront so we can not ignore it. For me the bigger issue is that the development choices for a serious spatial module are not the same as for core lucene development. Also the people are potentially quite different (with overlap of course) > On a different level, for me personally, and I really stress this just my > personal choice, I don't have much interest in contributing to non-ASF (or > similar foundation based open source projects) because they don't offer the > same legal framework, branding, resources and other opportunities that the > ASF does. > This is why I suggest osgeo.org -- they are a foundation similar to ASF. They are the home to most of the key opensource geographic projects, including: PostGIS, GDAL, Geotools, Openlayers, and MapServer. Unlike the ASF, there is not a single license model across all projects, but they make sure work is licensed properly and have most of the same procedures as ASF (incubation, infrastructure, mentors, etc) I could suggest a new ASF project, but there seems like too much overlap with SIS and very different philosophy on 3rd party libraries. In the end, osgeo.com seems like a more natural home and has better branding for spatial related work anyway. ryan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
