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 so much for this effort Justin!

Couple comments:
* Circle(x y d=) is obsolete and *not* handled by the WKT classes.  It’s in the old LegacyShapeReader/Writer and I prefer we make no mention of it.  In WKT we use BUFFER(POINT(x y), d)  to get the equivalent, with our buffer extension of course.
* I’m not well versed in GeoJSON but I noticed that the Buffered LineString example makes no mention of the units of buffer… yet the Circle one shows the units.  Is that a limitation of GeoJSON?  In any case I think we should try and tell users how that number is interpreted.

On Mon, Sep 14, 2015 at 1:28 PM Justin Deoliveira <jdeolive@xxxxxxxxx> wrote:
Thanks for the feedback Ryan. Comments below. 

On Mon, Sep 14, 2015 at 10:36 AM, Ryan McKinley <ryantxu@xxxxxxxxx> wrote:
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 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.


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!

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. 



 
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?

+1

Cool, I will work on putting these together.  
 
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
_______________________________________________
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
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker

Back to the top