Martin,
Incorporating Spatial4j into JTS is a third option I didn't mention because I
didn't think you'd consider it. It's very encouraging to hear you suggest this
possibility; others have too. Lets explore wether this is a realistic. If
this is going to work effectively, I ask for commit privileges OR a move to
GitHub where we can more easily collaborate via pull requests (or both, which
I'd prefer). I don't mind being subordinate to any veto decisions you make.
I'm not married to the Spatial4j API; Lucene-spatial can change to meet a new
API provided it has Spatial4j's current capabilities and it implements them in
a performant manner. Small independent parts of Spatial4j that JTS might not
want (say my WKT parser in-progress or Geohash encoder/decoder) could instead
go to Lucene-spatial.
I started to think of some technical considerations Lucene-spatial requires but
I think JTS's API pretty much has it covered, and a new JTS that incorporated
Spatial4j capabilities could work out. The Spatial4j Shape interface is
smaller and simpler than a JTS Geometry, but with one key difference:
* A Spatial4j Shape (AKA a Geometry) has a relate(otherShape) method which
returns a SpatialRelation (an enumeration of Intersects, Disjoint, Contains,
Within). In practice, this only needs to be supported when otherShape is a
Point or Rectangle (aka Envelope). A JTS Geometry instead has a series of
predicate methods like within(), contains(), intersects() etc. and so
Lucene-spatial would have to be modified to call several of these in some
algorithms rather than a universal relate() method. And the circle
implementation in Spatial4j would need to be modified to do its relation logic
via separate predicate test methods rather than do it all at once. I'm not
sure which approach would result in faster code as each has a pro & cons but
it's probably negligible.
Aside from that, there's of course the Spatial4j feature in which all its
shapes can exist in one of several mathematical world view models —
Euclidean/Cartesian 2D (what JTS currently assumes), the same but with
world-wrap support at the dateline, and Geodetic surface-of-a-sphere. No
matter what the world view is, you work with the same set of classes. You
construct them out of a factory (the Spatial4j "SpatialContext") that is aware
of the world-view and sometimes chooses a different concrete implementation
that supports the world model in effect. In some form, I think this concept
should continue into JTS if it were to adopt Spatial4j.
I've had a wish-list feature of supporting n-dimensional rectangles & points,
and aggregating existing 2D shapes with another dimension to form an aggregate.
For example a hypothetically new ShapeMD(Shape, minZ, maxZ), which could be
aggregated again, etc.
Some other things I would really like to see out of a future JTS:
* Move to Maven from Ant. I volunteer to do all the work to make this
happen.
* Move to GitHub. That means moving to git too, of course.
~ David
From: Martin Davis <[email protected]<mailto:[email protected]>>
Date: Thursday, September 26, 2013 12:54 AM
To: "Smiley, David W." <[email protected]<mailto:[email protected]>>
Cc:
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: Re: [Jts-topo-suite-user] What to do with Spatial4j?
I can't really comment on Spatial4J directly, not having used it or reviewed
the API and code in depth. However, I can say that geodetic functionality
seems like the next major direction for JTS to move in. (David, I think we've
had some interaction about this in the past). And circular geometries seem
like an obvious next step in the direction of supporting non-linear geometric
types.
It's hard to advise on whether to fold Spatial4J into Lucene or whether to keep
it separate. This will mostly depend on your team's ability to keep running a
separate project, I think. Certainly the functionality per se seems like it
might be useful outside of Lucene.
Another question that could be asked is why not add the Spatial4J functionality
into JTS? There's a lot of management questions that would need be be
resolved, but from a purely functional point of view this seems interesting.
Martin
On Wed, Sep 25, 2013 at 4:06 PM, Smiley, David W.
<[email protected]<mailto:[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]<mailto:[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
