Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [spatial4j-dev] Writing shapes to WKT/GeoJSON
I took a stab at generalizing format support.  The main API is here:
https://github.com/spatial4j/spatial4j/blob/formats/src/main/java/com/spatial4j/core/io/ShapeFormat.java

I then made a GeoJSON version -- the writing just directly writes to a the stream, and it uses noggit to parse JSON

I also converted WktShapeParser so it is now WKTFormat.  

Tests need some work, but I wanted to get it out for people to look at

thoughts?

ryan





On Mon, Mar 23, 2015 at 7:54 AM, david.w.smiley@xxxxxxxxx <david.w.smiley@xxxxxxxxx> wrote:

On Fri, Mar 20, 2015 at 7:36 PM, Ryan McKinley <ryantxu@xxxxxxxxx> wrote:
I have seen this comment:
<b>Spatial4j in the near future won't support writing shapes to strings.</b>

I wasn’t sure, and I think I merely had that to manage scope at the time since the use-cases I was working with didn’t involve turning a Shape into another format.  I’m very supportive of removing the aforementioned statement and adding WKT output.  I say WKT because Spatial4j already reads WKT, not that Spatial4j shouldn’t handle other formats like GeoJSON.
 

  If the problem is that we do not have a consistent format (WKT vs 'x, y') can't we just pick a standard format?


I don’t think we need to pick one...
 

Are there objections to adding 'write' functions on the Shape interface?  Maybe:


  public void writeGeoJSON(Writer writer) throws IOException;

  public void writeWKT(Writer writer) throws IOException;


I think Shape read/write should be separate from the Shape interface.  If we only ever wanted WKT then I think I’d feel differently, but there are other formats out there.  Even with just WKT, I think there’s value by centralizing the WKT read/write into it’s own class that can be customized, which is the case right now.
 

Alternatively, should this be done in the SpatialContext?  If so, is there a reason we do not have:


  public SpatialContext getSpatialContext();


Yeah… originally I thought Shape instances shouldn’t necessarily have such a method because it might weigh down a Point, and then what if you have millions of Points.  But I now feel that a design closer to JTS in which you aren’t expected to have a ton of Points; there is a separate “Coordinate” abstraction that is the internal light-weight non-Geometry.
 

With some write options available, we could add out-of-the-box support for Shapes in the Solr response.  As is, we kind of require the output to be a stored text field, and have no option if the Shape is modified (clipped, whatever)


Yeah.

~ David 

_______________________________________________
spatial4j-dev mailing list
spatial4j-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
http://www.locationtech.org/mailman/listinfo/spatial4j-dev

Back to the top