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

[Calvin Metcalf]

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.


On Wed, May 15, 2013 at 7:53 AM, Stefan Drees <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 community produced v3, now version 4
> being developed at 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
> http://lists.geojson.org/**listinfo.cgi/geojson-geojson.**org<http://lists.geojson.org/listinfo.cgi/geojson-geojson.org>
>



-- 
-Calvin W. Metcalf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20130515/17936029/attachment-0005.htm>