[GeoJSON] LineString with length zero (in a certain precision regime)

Stefan Drees stefan at drees.name
Wed May 15 07:02:58 PDT 2013


On 15.05.13 15:24, Calvin Metcalf wrote:
> This has come up before for me and I had assumed the way represent that was:
>
> {
>        "type": "Point",
>        "coordinates": [1.023456, 0.987633]
> }
>
> There is a similar restriction with polygons which need a minimum of 4
> points (3 distinct points and the first and last must be the same).
>
> I have mainly run into this in the context of converting to GeoJSON from
> other formats that do not have this restriction, i.e. representing
> circles as polygons with 1 point.
>

that is good to read. As I did not help create the original GeoJSON 
spec, I am still trying to collect what real use cases might have caused 
which statements.

Would it be safe to state: Whatever geometrical object, at least a 
single position should be inside the coordinates array, as one can 
always shrink the represented object along some dimension and in the 
limit (of precision) culminate in a single point. At the moment I would 
not expect a type change just because a shape has been shrunk, eg. a 
polygon reached area zero (in my precision and units) but I would 
refrain from allowing a shape object without even a single position info 
inside GeoJSON. That would be something like a Promise or a callback and 
what should the consumer do with it?

Is this somehow summarizing/embracing your experiences described above?

All the best,
Stefan.

>
> On Wed, May 15, 2013 at 7:53 AM, Stefan Drees <stefan at drees.name
> <mailto:stefan at drees.name>> wrote:
>
>     Dear all,
>
>     from a current discussion
>     (https://tools.oasis-open.org/__issues/browse/ODATA-390
>     <https://tools.oasis-open.org/issues/browse/ODATA-390>) in the open
>     data context, where GeoJSON has been referred to/included in since
>     at least version 3 (odata.org <http://odata.org> community produced
>     v3, now version 4 being developed at oasis-open.org
>     <http://oasis-open.org>) a question or two arose for me.
>
>     I simply do not know, what lead the members of this mailing list
>     (historically) as authors to the conclusion, that a GeoJSON
>     LineString MUST have at least two positions in it's coordinates
>     array. I am not opposed to it, I would just like to understand the
>     reasoning behind it.
>
>     """For type "LineString", the "coordinates" member must be an array
>     of two or more positions."""
>
>     On paper that is easy reading, a line must have at least two points,
>     check.
>
>     As a physicist and programmer alike, I can well imagine noting a
>     line with length zero (in a certain precision scheme) with only one
>     point given, instead of doubling the point and risking errors in
>     length computations after casting to the final type by the consuming
>     script, but maybe the members of this community have much better
>     examples or counter examples at hand ?
>
>     So if I have a line from say [1.023456, 0.987633] with length zero,
>     to represent it, do I really have to state:
>
>     // A)
>     {
>            "type": "LineString",
>            "coordinates": [
>                [1.023456, 0.987633],
>                [1.023456, 0.987633]
>            ]
>     }
>
>     or would it suffice to note:
>
>     // B)
>     {
>            "type": "LineString",
>            "coordinates": [
>                [1.023456, 0.987633]
>            ]
>     }
>
>     Meanwhile I am still waiting for real life examples of claimed
>     "valid geospatial values" to show up, that historically lead to the
>     following wording in odata v3:
>
>     """The GeoJSON [GeoJSON] standard requires that LineString contains
>     a minimum number of Positions in its coordinates collection. This
>     prevents serializing certain valid geospatial values. Therefore, in
>     the GeoJSON requirement "For type 'LineString', the 'coordinates'
>     member must be an array of two or more positions" is replaced with
>     the requirement "For type 'LineString', the 'coordinates' member
>     must be an array of positions" when used in OData. """ [from
>     2.2.6.3.1.1 "Modifications to GeoJSON for Use in OData" in the old
>     community standard v3 for odata]
>
>
>
>     What do the others think (or find in the historic mailboxes to
>     maintain the spirit of GeoJSON) Should we also allow inside the
>     GeoJSON RFC variant B) or remain with enforcing A) in the above
>     given context?
>
>
>     All the best,
>
>     Stefan.
>     _________________________________________________
>     GeoJSON mailing list
>     GeoJSON at lists.geojson.org <mailto:GeoJSON at lists.geojson.org>
>     http://lists.geojson.org/__listinfo.cgi/geojson-geojson.__org
>     <http://lists.geojson.org/listinfo.cgi/geojson-geojson.org>
>
>
>
>
> --
> -Calvin W. Metcalf




More information about the GeoJSON mailing list