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

[Sean Gillies]

Yep, simple features compatibility was the motivation. Most consumers of
GeoJSON are going to be baffled by lines with a single point.

There are certainly inherent numerical precision issues in this business,
but I don't think we should try to solve them in GeoJSON because 1) it'll
keep us from shipping the I-D, and 2) the real possibility that we'll get
it wrong, like we did CRS in the original spec. I'm also not in favor of
adding zero-length line or zero-area polygon concepts.



On Wed, May 15, 2013 at 8:53 AM, Tim Schaub <tschaub at opengeo.org> wrote:

> You could call it cargo cult.
>
> See, for example, the geometry primitives schema for GML 3.2.1:
> http://schemas.opengis.net/gml/3.2.1/geometryPrimitives.xsd
>
>     <complexType name="LineStringSegmentType"> <complexContent>
> <extension base="gml:AbstractCurveSegmentType"> <sequence> <choice> <choice
> minOccurs="2" maxOccurs="unbounded"> <element ref="gml:pos"/> <element
> ref="gml:pointProperty"/> <element ref="gml:pointRep"/> </choice> <element
> ref="gml:posList"/> <element ref="gml:coordinates"/> </choice> </sequence>
> <attribute name="interpolation" type="gml:CurveInterpolationType"
> fixed="linear"/> </extension> </complexContent> </complexType>
> So perhaps the justification is to work well with other geometry
> serializations.
>
> Tim
>
>
>
> On Wed, May 15, 2013 at 5: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>
>>
>
>
>
> --
> Tim Schaub
> OpenGeo http://opengeo.org/
> Expert service straight from the developers.
>
> _______________________________________________
> GeoJSON mailing list
> GeoJSON at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>
>


-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20130515/6f985af1/attachment-0005.htm>