[Dev] ESRI java library... apache license!

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[Dev] ESRI java library... apache license!

ryan
Just found:

I have not dug too deep, but it seems like it may be an interesting/robust ASL alternative to JTS!

ryan

_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com
Reply | Threaded
Open this post in threaded view
|

Re: [Dev] ESRI java library... apache license!

dsmiley
Wow!  I'm blown away.

Some random thoughts about it, and it's relation to what we need/are doing:
* Finally, an ASL licensed alternative to JTS!  I've got nothing against JTS but it's LGPL license.
* It does indeed appear to have the functionality we use JTS for -- WKT parsing and computing the intersection of polygons with rectangles (aka envelopes).  In fact, I'd say there's probably >90% overlap with JTS.
* I like that in JTS I can find the intersection matrix in one call so I can map that to an appropriate Spatial4j relation.  In ESRI, that's going to be a series of method calls that could be more computationally expensive (e.g. if ! intersects, return disjoint, else check isWithin, else check isContains, return intersects).
* The code is poorly documented but at least it has some documentation.  It has enough that I think I could make effective use of the code, at least.  But lots of the innards have no comments.  Some of it has a feel of it being ported from some other language.  Loads of classes in one package which is hard to navigate.  Lots of package level access which may make subclassing/extension difficult if we should need to.  It has a decent JUnit test suite (it beats JTS there).  It has some stub classes (e.g. ProjectionTransformation)
* The WKT parser is not extensible (nor was JTS's).  We still need our own parser in Spatial4j, I think.

After I think about this how, my initial excitement is wearing off.  Remember that we always knew we could use the java.awt.Polygon & java.awt.geom stuff right in the JDK.  We haven't because it simply hasn't been a priority.  So, I guess this isn't a big deal after all, in terms of Lucene/Solr/Spatial4j.

~ David



On Wed, Jul 17, 2013 at 1:59 AM, Ryan McKinley <[hidden email]> wrote:
Just found:

I have not dug too deep, but it seems like it may be an interesting/robust ASL alternative to JTS!

ryan

_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com



_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com
Reply | Threaded
Open this post in threaded view
|

Re: [Dev] ESRI java library... apache license!

Itamar Syn-Hershko
For WKT parser take a look here: https://github.com/sibartlett/RavenDB.Client.Spatial/blob/master/Raven.Client.Spatial/WktReader.cs (C#, but easily convertible to Java)


On Wed, Jul 17, 2013 at 10:59 PM, [hidden email] <[hidden email]> wrote:
Wow!  I'm blown away.

Some random thoughts about it, and it's relation to what we need/are doing:
* Finally, an ASL licensed alternative to JTS!  I've got nothing against JTS but it's LGPL license.
* It does indeed appear to have the functionality we use JTS for -- WKT parsing and computing the intersection of polygons with rectangles (aka envelopes).  In fact, I'd say there's probably >90% overlap with JTS.
* I like that in JTS I can find the intersection matrix in one call so I can map that to an appropriate Spatial4j relation.  In ESRI, that's going to be a series of method calls that could be more computationally expensive (e.g. if ! intersects, return disjoint, else check isWithin, else check isContains, return intersects).
* The code is poorly documented but at least it has some documentation.  It has enough that I think I could make effective use of the code, at least.  But lots of the innards have no comments.  Some of it has a feel of it being ported from some other language.  Loads of classes in one package which is hard to navigate.  Lots of package level access which may make subclassing/extension difficult if we should need to.  It has a decent JUnit test suite (it beats JTS there).  It has some stub classes (e.g. ProjectionTransformation)
* The WKT parser is not extensible (nor was JTS's).  We still need our own parser in Spatial4j, I think.

After I think about this how, my initial excitement is wearing off.  Remember that we always knew we could use the java.awt.Polygon & java.awt.geom stuff right in the JDK.  We haven't because it simply hasn't been a priority.  So, I guess this isn't a big deal after all, in terms of Lucene/Solr/Spatial4j.

~ David



On Wed, Jul 17, 2013 at 1:59 AM, Ryan McKinley <[hidden email]> wrote:
Just found:

I have not dug too deep, but it seems like it may be an interesting/robust ASL alternative to JTS!

ryan

_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com



_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com



_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com
Reply | Threaded
Open this post in threaded view
|

Re: [Dev] ESRI java library... apache license!

dsmiley
Thanks Itimar!  Spatial4j already a WKT parser in-progress; it's a partial port from ElasticSearch that Chris Male wrote for them.  I'll look at your WktReader for ideas when I'm next working on it.

~ David


On Wed, Jul 17, 2013 at 4:08 PM, Itamar Syn-Hershko <[hidden email]> wrote:
For WKT parser take a look here: https://github.com/sibartlett/RavenDB.Client.Spatial/blob/master/Raven.Client.Spatial/WktReader.cs (C#, but easily convertible to Java)


On Wed, Jul 17, 2013 at 10:59 PM, [hidden email] <[hidden email]> wrote:
Wow!  I'm blown away.

Some random thoughts about it, and it's relation to what we need/are doing:
* Finally, an ASL licensed alternative to JTS!  I've got nothing against JTS but it's LGPL license.
* It does indeed appear to have the functionality we use JTS for -- WKT parsing and computing the intersection of polygons with rectangles (aka envelopes).  In fact, I'd say there's probably >90% overlap with JTS.
* I like that in JTS I can find the intersection matrix in one call so I can map that to an appropriate Spatial4j relation.  In ESRI, that's going to be a series of method calls that could be more computationally expensive (e.g. if ! intersects, return disjoint, else check isWithin, else check isContains, return intersects).
* The code is poorly documented but at least it has some documentation.  It has enough that I think I could make effective use of the code, at least.  But lots of the innards have no comments.  Some of it has a feel of it being ported from some other language.  Loads of classes in one package which is hard to navigate.  Lots of package level access which may make subclassing/extension difficult if we should need to.  It has a decent JUnit test suite (it beats JTS there).  It has some stub classes (e.g. ProjectionTransformation)
* The WKT parser is not extensible (nor was JTS's).  We still need our own parser in Spatial4j, I think.

After I think about this how, my initial excitement is wearing off.  Remember that we always knew we could use the java.awt.Polygon & java.awt.geom stuff right in the JDK.  We haven't because it simply hasn't been a priority.  So, I guess this isn't a big deal after all, in terms of Lucene/Solr/Spatial4j.

~ David



On Wed, Jul 17, 2013 at 1:59 AM, Ryan McKinley <[hidden email]> wrote:
Just found:

I have not dug too deep, but it seems like it may be an interesting/robust ASL alternative to JTS!

ryan

_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com



_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com



_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com



_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com
Reply | Threaded
Open this post in threaded view
|

Re: [Dev] ESRI java library... apache license!

ryan
In reply to this post by dsmiley



On Wed, Jul 17, 2013 at 12:59 PM, [hidden email] <[hidden email]> wrote:
Wow!  I'm blown away.

Some random thoughts about it, and it's relation to what we need/are doing:
* Finally, an ASL licensed alternative to JTS!  I've got nothing against JTS but it's LGPL license.
* It does indeed appear to have the functionality we use JTS for -- WKT parsing and computing the intersection of polygons with rectangles (aka envelopes).  In fact, I'd say there's probably >90% overlap with JTS.
* I like that in JTS I can find the intersection matrix in one call so I can map that to an appropriate Spatial4j relation.  In ESRI, that's going to be a series of method calls that could be more computationally expensive (e.g. if ! intersects, return disjoint, else check isWithin, else check isContains, return intersects).

Looks like what you want is in:

perhaps we push to make that a public part of the api


 
* The code is poorly documented but at least it has some documentation.  It has enough that I think I could make effective use of the code, at least.  But lots of the innards have no comments.  Some of it has a feel of it being ported from some other language.  Loads of classes in one package which is hard to navigate.  Lots of package level access which may make subclassing/extension difficult if we should need to.  It has a decent JUnit test suite (it beats JTS there).  It has some stub classes (e.g. ProjectionTransformation)


I'm sure this is derived from years of closed source stuff -- it is great to see them taking serious steps into open source.

 
* The WKT parser is not extensible (nor was JTS's).  We still need our own parser in Spatial4j, I think.
 
After I think about this how, my initial excitement is wearing off.  Remember that we always knew we could use the java.awt.Polygon & java.awt.geom stuff right in the JDK.  We haven't because it simply hasn't been a priority.  So, I guess this isn't a big deal after all, in terms of Lucene/Solr/Spatial4j.


It is worth looking at what would need to get exposed/changed to make things work well.  They are likely open to suggestion and change -- the less we need to re-invent, the better

ryan




_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com
Reply | Threaded
Open this post in threaded view
|

Re: [Dev] ESRI java library... apache license!

dsmiley

On Jul 17, 2013, at 4:43 PM, Ryan McKinley <[hidden email]> wrote:

Looks like what you want is in:

perhaps we push to make that a public part of the api

I saw that class before and I reviewed it again.  Correct me if I'm wrong, but there's no method that returns *what* the relation is (e.g. within, contains, ...).  Instead it is asked if it meets a relation (or set of relations given the matrix) and it returns a boolean true or false.

~ David

_______________________________________________
dev mailing list
[hidden email]
http://lists.spatial4j.com/listinfo.cgi/dev-spatial4j.com