Hey folks,
I took an initial cut at updating FORMATS.md. Let me know what you think. I am happy to re-organized any of the content as you see fit.
In going through the various format encodings I found a few things which I think deserve some discussion.
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).
WKT encoding for Buffered LS
At the moment it seems the WKT won't encode buffered line strings (or at least the buffer part of them). I'm thinking just to use the "BUFFER" syntax that is already there, and that way we don't have to do any work on the decoding side.
So a buffered line string would look like:
BUFFER (LINESTRING (1 2, 3 4), 10))
Sound ok? If so I will whip up a patch. Not sure if we want it for the release or not...
WKT case and spacing
Final point is that through this all I noticed a few things related to case and spacing for WKT.
- Circle seems to be oddball with regard to case and uses "Circle" instead of "CIRCLE".
- JTS WKT encoding appends a space after the shape type whereas the non JTS encoding does not. So we get "POINT(1 1) vs POINT (1 1)".
Should we change these?
Thanks!
-Justin
