Re: [spatial4j-dev] Format documentation and some minor encode/decode is

[Ryan McKinley <ryantxu@xxxxxxxxx>]

GeoJSON decoding for Buffered LS

First is how the GeoJSON format handles buffered line strings on the read side of thing. At the moment it more or less ignores the buffer part, which I think is a disconnect since it can encode it. I took an initial shot at a patch which you can look at here:

  https://github.com/jdeolive/spatial4j/compare/geojson-encode-bufline...jdeolive:geojson-decode-bufline

I haven't submitted it as a PR yet since it adds a method to GeneralReadWriteShapeTest which breaks the WKT tests (which leads to the point in the next section). 

What does a GeoJSON buffer look like?   I thought it is just a bigger polygon, or a polygon rather than a line.

But yes -- lets fix it if possible!

It depends on the spatial context. If you are using non-jts and you call SpatialContext.makeBufferedLineString, or call Shape.getBuffered then you get something that looks like this.

  {"type":"LineString","coordinates": [[0,0],[1,1]],"buffer":10}

If you are using JtsSpatialContext and you call makeBufferedLineString you get the same. But if you use Shape.getBuffered() with a JtsGeometry then it actually does the buffer and you get a polygon. 

right, GeoJSON has no way to represent buffered shapes, we either have to:

1. say it is unsupported

2. just return the original, but add unsupported attributes about the buffer size

3. return a shape that is transformed.

I don't know the right answer :)

Maybe option #2 and adding units?  Like we do for Circle?

https://github.com/geojson/geojson-spec/wiki/Proposal---Circles-and-Ellipses-Geoms

ryan