On Wed, Apr 6, 2011 at 22:43, Robert Muir <rcm...@gmail.com> wrote: > On Wed, Apr 6, 2011 at 2:12 PM, Ryan McKinley <ryan...@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: ear...@gmail.com Phone: +7 (495) 683-567-4 ICQ: 104465785 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
