[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