Hi Ryan, On Apr 3, 2011, at 12:50 PM, Ryan McKinley wrote: > > 2. 3rd party tools -- In general people working on complex geographic > problems use JTS and other LGPL tools. There is some great work > happening at Apache SIS now, but it is a long way from being a viable > ASL alternative.
Thanks for actually recognizing the work going on in Apache SIS. So far, we've got a 0.1-incubating release that includes: 1. a working QuadTree implementation (which I've heard you say you think would be a good idea for Lucene/Solr). We think it's a good idea in general. 2. a method of loading/populating the QuadTree with GeoRSS. 3. a web service (REST-ful, but could use improvement) to query the QuadTree using a bounding box or point/radius and get back XML. 4. a demo (part of the web service WAR) that uses GMaps to show it off. There are a number of interesting ideas folks have had in the SIS community (including OGC-like layer services that connect to OODT, HBase, etc.) and implementation platforms for services (JAX-RS from CXF, etc) that I think will help make the project awesome. But, like all open source, there is tons of work to do. I can say is that we'd welcome you (and anyone else interested) working on geospatial stuff at Apache in SIS, if you're interested. Patches welcome. Contributions welcome. Collaborations welcome. >From the original SIS proposal, accepted into the Incubator in February 2010 >[1]: "We propose to construct Apache SIS, an ASL 2.0 licensed toolkit that spatial information system builders or users can leverage to support the aforementioned activities, alleviating much of the software and potentially legal difficulties in implementing SIS/GIS systems. This project will look to expand on those concepts and serve as a place to store reference implementations of spatial algorithms, utilities, services, etc. as well as serve as a sandbox to explore new ideas. Further, the goal is to have Apache SIS grow into a thriving Apache top-level community, where a host of SIS/GIS related software (OGC datastores, REST-ful interfaces, data standards, etc.) can grow from and thrive under the Apache umbrella." One thing to note: we're not trying to build our system so that it depends on any underlying storage/search/indexing/etc platform (e.g., Lucene or Solr). We're trying to build it so that that part is swappable out. That doesn't preclude us from being interested in having such a plugin-though. Cheers, Chris [1] http://wiki.apache.org/incubator/SpatialProposal > Within ASF, it is legally ok to have build > dependencies on LGPL. The Lucene contrib bdb even includes a > dependency on a GPL(ish)! However, these dependencies are not > recommended and only happen if the community (and PMC) think the > tradeoff is worthwhile. Given the primary concerns of the lucene > community, I totally understand why a build dependency on LGPL may not > be acceptable. > > As designed the proposed spatial API does not require JTS. All > geometry has a 'simple' implementation what works for points and > boxes. I even refactored the JTS dependencies to different packages > that could be hosted elsewhere. This works, but it is far from ideal > because it makes testing the JTS implementations much more difficult > -- given that the community of developers working on the code is > likely to use the complex implementations, this separation is > unacceptable (for me anyway). If I am going to spend the time to make > good tests, i want to make sure the classes I use are a 1st class > citizens. Likewise, if the real work goes into testing the external > packages, it stinks if it does not apply to the simple implementations > / base framework. I don't think the spatial developer community > should be split across two code bases and build systems. > > In the days of sub-projects, I would have proposed that option, but > now I see two options: > > A. Work on spatial lucene outside of apache -- perhaps osgeo or even > just github. (would need a different name) > B. Allow JTS compile-time dependency in lucene, and move spatial > contrib to a real module > > I think option A is better long term, but I feel like the kid saying > "if I can't have my way I'll take my ball (code) and go home" -- i > don't want this to sound like an ultimatum, but an honest discussion > about what has the best chance of fostering a thriving development > community. > > 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. > > Thoughts? Ideas? Concerns? > > thanks > ryan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
