lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan McKinley <>
Subject Re: Lucene Spatial Future
Date Tue, 05 Apr 2011 20:08:45 GMT
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
 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

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:

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?

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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message