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. If the JTS dependency is not acceptable, then we will look for a good home elsewhere (maybe in apache, maybe at osgeo). Before doing the work to actually integrate with the lucene build system, it would be nice to see what the general feeling is about the plan. If folks are OK with the idea, we can make a concrete patch/branch to flush out the details [] OK with JTS compile dependency. Spatial support should be a module [] OK with JTS, but think this spatial stuff should happen elsewhere [] Please, no LGPL dependencies in lucene build thanks ryan --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
