lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Earwin Burrfoot <ear...@gmail.com>
Subject Re: [POLL] JTS compile/test dependency
Date Wed, 06 Apr 2011 21:07:05 GMT
On Wed, Apr 6, 2011 at 22:43, Robert Muir <rcmuir@gmail.com> wrote:
> On Wed, Apr 6, 2011 at 2:12 PM, Ryan McKinley <ryantxu@gmail.com> wrote:
>> Some may be following the thread on spatial development...  here is a
>> quick summary, and a poll to help decide what may be the best next
>> move.
>>
>> I'm hoping to introduce a high level spatial API that can be used for
>> a variety of indexing strategies and computational needs.  For simple
>> point in BBox and point in WGS84 radius, this does not require any
>> external libraries.  To support more complex queries -- point in
>> polygon, complex geometry intersections, etc -- we need an LGPL
>> library JTS.  The LGPL dependency is only needed to compile/test,
>> there is no runtime requirement for JTS.  To enable the more
>> complicated options you would need to add JTS to the classpath and
>> perhaps set a environment variable.  This is essentially what we are
>> now doing with the (soon to be removed) bdb contrib.
>>
>> I am trying to figure out the best home for this code and development
>> to live.  I think it is essential for the JTS support to be part of
>> the core build/test -- splitting it into a separate module that is
>> tested elsewhere is not an option.  This raises the basic question of
>> if people are willing to have the LGPL build dependency as part of the
>> main lucene build.  I think it is, but am sympathetic to the idea that
>> it might not be.
>
> I'm sorta confused about this (i'll probably offend someone here, but so be
> it)
> We have a contrib module for spatial that is experimental, people want to
> deprecate, and say has problems.
> Why must the super-expert-polygon stuff sit with the basic capability that
> probably most users want: the ability to do basic searches (probably in
> combination with text too) in their app?
> Its hard for me to tell, i hope the reason isn't "elegance", but why aren't
> we working on making a simple,supported,80-20 case in lucene that
> non-spatial-gurus (and users) understand and can maintain... then it would
> seem ideal for the complex stuff to be outside of this project with any
> dependencies it wants?
> Users are probably really confused about the spatial situation: is it
> because we are floundering around this expert stuff????

Handling Unicode code points outside of BMP is highly expert stuff as
well. And is totally unneeded by 80% of the users for any other reason
except "elegance". I think you two guys can really understand each
other here : )

-- 
Kirill Zakharenko/Кирилл Захаренко
E-Mail/Jabber: earwin@gmail.com
Phone: +7 (495) 683-567-4
ICQ: 104465785

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message