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

[Stefan Drees]

On 15.05.13 16:02, Stefan Drees wrote:
> 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]
>> }
>>

I overlooked that you entered Point as type here, sorry. So my below 
statements of course do not summarize your position, I presume ;-)

If there is in some precision and scale say a LineString, with two 
distinct positions, does the GeoJSON concept thus expect that if the two 
points under an assumed new scaling and precision become identical, then 
the producer of the GeoJSON message must be either so clever as to

1) convert the type from LineString to Point, to be allowed to only 
state one position or

2) keep the type (LineString i.e.) but still has to report two 
(identical) positions?

Both are valid options, right? Also there might be applications having 
trouble when receiving lines with only one position ...

All the best,
Stefan.

>> 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
>
> _______________________________________________
> GeoJSON mailing list
> GeoJSON at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org