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

thanks for looking at this...  see below

On Mon, Sep 14, 2015 at 8:54 AM, Justin Deoliveira <jdeolive@xxxxxxxxx> wrote:
Hey folks,

I took an initial cut at updating 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.

merged -- we can keep improving too...

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!

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... 

+1 from me

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?



Back to the top