lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: Lucene Spatial Future
Date Wed, 06 Apr 2011 13:30:04 GMT

On Apr 5, 2011, at 4:08 PM, Ryan McKinley wrote:

> On Tue, Apr 5, 2011 at 2:46 PM, Grant Ingersoll <> 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

Aren't you just replicating what SIS is doing for this piece?  If you don't have a JTS requirement,
that means you are going to need equivalent math, right?  Isn't that what SIS is about?  

> 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 ( 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?

It doesn't, we just already have point search working and released.  Which means it would
have to go through deprecation, etc.  Obviously, it can be done.

>>  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.  

That's true of all of our modules.  That's why they are modules and not core.

> This is why I suggest -- 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, seems like a more natural home and has better
> branding for spatial related work anyway.

By all means go for it.  I don't see any reason not too.  I guess in the end, I'm not sure
what you are asking us to do.  Do you want Lucene/Solr to remove all of our spatial support
in favor of incorporating this new project or do you just want those who are interested in
spatial to join the new project and it can be seen as an add on?
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message