[Dev] Spatial4j Roadmap

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

[Dev] Spatial4j Roadmap

dsmiley@mitre.org
Administrator
I want to outline what the Spatial4j roadmap looks like from my perspective.  I'm not dictating what it is (although admittedly I'm the only one actually working on it).  It's intended more of as a proposal.  This isn't complete but it's what comes to mind as I think about it for a few minutes.

Short term:
* New shape: BufferedLineString. I have this done locally but need to integrate & commit.
* Add an extensible WKT parser, one that does not depend on JTS. Remove the old simple parser; transfer to Solr. I have this partially done locally but need to integrate & commit.
* Finalize ShapeCollection API.  Add visitor pattern.  Add some subclasses (e.g. PointCollection?).
* Issue #33 - clockwise coordinate order rectangle

(potential v1.0 here)

Medium term:
* Separate the shape factory functionality from validating shape arguments.  Only the shape codec (read shape from string) should validate args by default.
* The isGeo() notion is poorly done.  As I see it, there is pure spatial (what do we call this?  cartesian? euclidean?  planar?) then there's WGS84, then there's a cylindrical projection with dateline wrap.  In this latter case, distance math is all cartesian.
* The DistanceCalculator abstraction bothers me but I can't quite explain what it is.  Maybe flushing out the "geo" stuff above will lead to something better here.
* (related to above) shape.getArea(ctx); the api here is wonky
* Add Shape.contains(point) direct support.  (Does it improve performance?)
* Decide/document when a shape needs to reference the ctx.

Longer term:
* Projections
* java.awt.geom based polygon
* test/evaluate supposed performance gain of the reset() methods (using Caliper?).
* multi-dimensional API?  Int vs Long, Float vs Double

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

Re: [Dev] Spatial4j Roadmap

Chris Male
Hi,

Thanks for pulling this together.  I've answered inline.


On Tue, Dec 11, 2012 at 9:52 AM, Smiley, David W. <[hidden email]> wrote:
I want to outline what the Spatial4j roadmap looks like from my perspective.  I'm not dictating what it is (although admittedly I'm the only one actually working on it).  It's intended more of as a proposal.  This isn't complete but it's what comes to mind as I think about it for a few minutes.

Short term:
* New shape: BufferedLineString. I have this done locally but need to integrate & commit.

Anything holding you back here? Just throw it in and lets move on.

 
* Add an extensible WKT parser, one that does not depend on JTS. Remove the old simple parser; transfer to Solr. I have this partially done locally but need to integrate & commit.

Again, anything holding you back here? Lets get the parser in master and we can then deal with integrating with Solr.
 
* Finalize ShapeCollection API.  Add visitor pattern.  Add some subclasses (e.g. PointCollection?).

This seems pretty minor.  Must it be done in the short term?
 
* Issue #33 - clockwise coordinate order rectangle

(potential v1.0 here)

Depending on what we feel 1.0 means, I think theres some very major issues in the medium term below that should be tackled if we want to 'put our best foot forward' with 1.0.  But I think we should definitely cut a 0.4 here maybe.
 

Medium term:
* Separate the shape factory functionality from validating shape arguments.  Only the shape codec (read shape from string) should validate args by default.

I think this is the best way forward.  All validation should be in the Codec and we should have a clean Factory that does shape instantiation.  We can then combine the two into an easy to use class for users.
 
* The isGeo() notion is poorly done.  As I see it, there is pure spatial (what do we call this?  cartesian? euclidean?  planar?) then there's WGS84, then there's a cylindrical projection with dateline wrap.  In this latter case, distance math is all cartesian.

This is a biggie and I feel it must be addressed before 1.0.  I have tried to tackle it in a few places locally already, but it is pervasive and it's not always clear how best to provide extensions.
 
* The DistanceCalculator abstraction bothers me but I can't quite explain what it is.  Maybe flushing out the "geo" stuff above will lead to something better here.
* (related to above) shape.getArea(ctx); the api here is wonky

Seem like reasonable improvements.  For me the API always looks a little complex, daunting even.
 
* Add Shape.contains(point) direct support.  (Does it improve performance?)

Good idea.
 
* Decide/document when a shape needs to reference the ctx.

Agreed.  We should really actually make Shapes as cheap and line as possible, with as few arguments as needed.  One thing that might save us a little is in creation of RectangleImpl and PointImpl instances inside other Shapes.  Must the Shape really go through the Factory just to create a PointImpl?  Food for thought.
 

Longer term:
* Projections
* java.awt.geom based polygon
* test/evaluate supposed performance gain of the reset() methods (using Caliper?).
* multi-dimensional API?  Int vs Long, Float vs Double

I think it'd be great to see some sort of benchmarks made so we can validate performance improvements.  I know I've said that alot, but I feel it remains a huge issue.

Thanks,
Chris
 

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



--
Chris Male | Open Source Search Developer | elasticsearch | www.elasticsearch.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] Spatial4j Roadmap

dsmiley

On Dec 11, 2012, at 11:31 PM, Chris Male <[hidden email]> wrote:

Short term:
* New shape: BufferedLineString. I have this done locally but need to integrate & commit.

Anything holding you back here? Just throw it in and lets move on.

It lacks SpatialContext.createXXX integration; there's no interface for it.  It's a concrete stand-alone shape impl.
 
* Add an extensible WKT parser, one that does not depend on JTS. Remove the old simple parser; transfer to Solr. I have this partially done locally but need to integrate & commit.

Again, anything holding you back here? Lets get the parser in master and we can then deal with integrating with Solr. 

I'll add BufferedLineString & the WKT parser these this week.

* Finalize ShapeCollection API.  Add visitor pattern.  Add some subclasses (e.g. PointCollection?).

This seems pretty minor.  Must it be done in the short term?

Well... in the not too distant future, on the Lucene spatial side of things I'd like to give a collection of points to the strategy for indexing in one shot.  If it gets a collection of them instead of createIndexableFields() getting called X times, then it can return a DocValues field for multi-value.  The lack of a standard shape for this is one obstacle.  There are other obstacles like the Solr side of things reacting to the value being instanceof Collection which triggers it to iterate over the values instead of passing it the collection forward; I need to create a JIRA issue for a proposed solution to that.

So maybe make an explicit PointCollection extends ShapeCollection, and/or a method: ShapeCollection<T>.getComponentType() Class<T>

 
* Issue #33 - clockwise coordinate order rectangle

(potential v1.0 here)

Depending on what we feel 1.0 means, I think theres some very major issues in the medium term below that should be tackled if we want to 'put our best foot forward' with 1.0.  But I think we should definitely cut a 0.4 here maybe. 

Definitely agree.


Medium term:
* Separate the shape factory functionality from validating shape arguments.  Only the shape codec (read shape from string) should validate args by default.

I think this is the best way forward.  All validation should be in the Codec and we should have a clean Factory that does shape instantiation.  We can then combine the two into an easy to use class for users.

Well I don't think the Codec has to have built-in validation into its code; someone should be able to write a GeoJSON codec and re-use our validation without dragging in WKT.  The solution I envision is a shape factory impl that validates then delegates to the real one.

~ David

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

Re: [Dev] Spatial4j Roadmap

Chris Male



On Wed, Dec 12, 2012 at 8:14 PM, David Smiley <[hidden email]> wrote:

On Dec 11, 2012, at 11:31 PM, Chris Male <[hidden email]> wrote:

Short term:
* New shape: BufferedLineString. I have this done locally but need to integrate & commit.

Anything holding you back here? Just throw it in and lets move on.

It lacks SpatialContext.createXXX integration; there's no interface for it.  It's a concrete stand-alone shape impl.

Lets add the class and then deal with those.  Small steps and all.
 
 
* Add an extensible WKT parser, one that does not depend on JTS. Remove the old simple parser; transfer to Solr. I have this partially done locally but need to integrate & commit.

Again, anything holding you back here? Lets get the parser in master and we can then deal with integrating with Solr. 

I'll add BufferedLineString & the WKT parser these this week.

* Finalize ShapeCollection API.  Add visitor pattern.  Add some subclasses (e.g. PointCollection?).

This seems pretty minor.  Must it be done in the short term?

Well... in the not too distant future, on the Lucene spatial side of things I'd like to give a collection of points to the strategy for indexing in one shot.  If it gets a collection of them instead of createIndexableFields() getting called X times, then it can return a DocValues field for multi-value.  The lack of a standard shape for this is one obstacle.  There are other obstacles like the Solr side of things reacting to the value being instanceof Collection which triggers it to iterate over the values instead of passing it the collection forward; I need to create a JIRA issue for a proposed solution to that.

So maybe make an explicit PointCollection extends ShapeCollection, and/or a method: ShapeCollection<T>.getComponentType() Class<T>

 
* Issue #33 - clockwise coordinate order rectangle

(potential v1.0 here)

Depending on what we feel 1.0 means, I think theres some very major issues in the medium term below that should be tackled if we want to 'put our best foot forward' with 1.0.  But I think we should definitely cut a 0.4 here maybe. 

Definitely agree.


Medium term:
* Separate the shape factory functionality from validating shape arguments.  Only the shape codec (read shape from string) should validate args by default.

I think this is the best way forward.  All validation should be in the Codec and we should have a clean Factory that does shape instantiation.  We can then combine the two into an easy to use class for users.

Well I don't think the Codec has to have built-in validation into its code; someone should be able to write a GeoJSON codec and re-use our validation without dragging in WKT.  The solution I envision is a shape factory impl that validates then delegates to the real one.

I'm sure I suggested that along the way.. but okay, great!
 

~ David

_______________________________________________
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