Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [spatial4j-dev] Format documentation and some minor encode/decode issues


On Mon, Sep 14, 2015 at 11:48 AM, Ryan McKinley <ryantxu@xxxxxxxxx> wrote:

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:


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?

Makes sense to me. I'll go that route.  

ryan





 

 


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

Back to the top