A couple quick thoughts, I had not heard of the project before but I really
like the idea of having an answer to PostGIS geography type for the Java
community.
And it is good that Martin's recent email on moving JTS to BSD+EPL is
having an immediate benefit, I wonder how many other projects are held back
by a non LGPL requirement.
I have been going through the steps of joining LocationTech for the uDig
project. When that group was being formed I tried to provide clear marching
orders: ie implementation of Geometry and Referencing. That list appears to
be expanding to include geocoding (providing a bridge from business objects
to location). If you are interested I suggest getting in early while a
technology stack is being assembled - it would be a valuable contribution.
As for it being used - it may not be clear, but the GeoTools feature model
does support using different implementations for the "geometry" of a
feature and I have long looked for an excuse to try this out. This mostly
needless flexibility was originally intended to allow the library a chance
to work with any ISO 19107 implementations that came along. I suspect that
following in the footsteps of PostGIS with a Geography representation makes
more immediate sense.
On Wed, Sep 25, 2013 at 4:06 PM, Smiley, David W. <[email protected]> wrote:
> Hello JTS list,
>
> I'm writing to solicit the opinions of the folks on the JTS list on the
> direction I should take with Spatial4j — a ~2 year old open-source project
> I run with Ryan McKinley.
> https://github.com/spatial4j/spatial4j
>
> Background:
> Spatial4j came about as a subset of a body of Java spatial code in support
> of spatial information-retrieval for Apache Lucene and Solr. Spatial4j is
> the subset that deals solely with defining shapes, computing distances,
> shape intersection, and parsing and writing shape strings. To my knowledge,
> it is only used by Lucene's new spatial module. Spatial4j is an independent
> part of Lucene spatial for two reasons: Most importantly, it uses (albeit
> optionally) the 3rd party JTS library which is LGPL licensed. The Apache
> Software Foundations forbids a dependency, even an optional one, on LGPL
> licensed software. The second reason is that Spatial4j should be
> independently useful on its own. I don't know of the geodetic shape
> intersection algorithms it has existing in any other open-source software.
> Perhaps I didn't look hard enough but that is to the best of my knowledge.
>
> Some specific features of note to the list here:
> * A circle implementation, both in euclidean 2D mode and geodetic
> surface-of-sphere mode
> * computs intersection cases (disjoint, contains, within, intersects)
> between the shapes it has and points and rectangles (either euclidean 2D or
> geodetic)
> * Rewrites JTS geometries of lat & lon coordinates to support dateline
> crossing. No pole wrap support yet.
> There are extensive randomized tests, by the way.
>
> So there's useful code here for sure, but it's only used by Lucene's
> Spatial module (which I work on a great deal). With JTS about to be
> re-licesned in a way compatible with ASF projects, it is no longer required
> that Spatial4j's code exist outside of Lucene spatial.
>
> I'm thinking of taking one of two paths:
> (A) Merge it into Apache Lucene's spatial module. I'm a committer there.
> Spatial4j as an independent project would be effectively dead but the code
> would live on co-located where it is used. It would always be in sync with
> Lucene (no separate releases).
> (B) Join LocationTech. This approach will only be deemed successful, as
> far as I'm concerned, if "eventually" people start using it.
>
> What do you guys think of Spatial4j and what I should do with it?
>
> ~ David Smiley
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Jts-topo-suite-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>
>
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Jts-topo-suite-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
