<div dir="ltr">You could call it cargo cult.<div><br></div><div style>See, for example, the geometry primitives schema for GML 3.2.1:</div><div style><a href="http://schemas.opengis.net/gml/3.2.1/geometryPrimitives.xsd">http://schemas.opengis.net/gml/3.2.1/geometryPrimitives.xsd</a><br>
</div><div style><br></div><div style><div>    <span style="white-space:pre"><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>
<br></span></div><div style>So perhaps the justification is to work well with other geometry serializations.</div><div style><br></div><div style>Tim</div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, May 15, 2013 at 5:53 AM, Stefan Drees <span dir="ltr"><<a href="mailto:stefan@drees.name" target="_blank">stefan@drees.name</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dear all,<br>
<br>
from a current discussion (<a href="https://tools.oasis-open.org/issues/browse/ODATA-390" target="_blank">https://tools.oasis-open.org/<u></u>issues/browse/ODATA-390</a>) in the open data context, where GeoJSON has been referred to/included in since at least version 3 (<a href="http://odata.org" target="_blank">odata.org</a> community produced v3, now version 4 being developed at <a href="http://oasis-open.org" target="_blank">oasis-open.org</a>) a question or two arose for me.<br>

<br>
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.<br>

<br>
"""For type "LineString", the "coordinates" member must be an array of two or more positions."""<br>
<br>
On paper that is easy reading, a line must have at least two points, check.<br>
<br>
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 ?<br>

<br>
So if I have a line from say [1.023456, 0.987633] with length zero,<br>
to represent it, do I really have to state:<br>
<br>
// A)<br>
{<br>
      "type": "LineString",<br>
      "coordinates": [<br>
          [1.023456, 0.987633],<br>
          [1.023456, 0.987633]<br>
      ]<br>
}<br>
<br>
or would it suffice to note:<br>
<br>
// B)<br>
{<br>
      "type": "LineString",<br>
      "coordinates": [<br>
          [1.023456, 0.987633]<br>
      ]<br>
}<br>
<br>
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:<br>
<br>
"""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]<br>

<br>
<br>
<br>
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?<br>
<br>
<br>
All the best,<br>
<br>
Stefan.<br>
______________________________<u></u>_________________<br>
GeoJSON mailing list<br>
<a href="mailto:GeoJSON@lists.geojson.org" target="_blank">GeoJSON@lists.geojson.org</a><br>
<a href="http://lists.geojson.org/listinfo.cgi/geojson-geojson.org" target="_blank">http://lists.geojson.org/<u></u>listinfo.cgi/geojson-geojson.<u></u>org</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Tim Schaub<br>OpenGeo <a href="http://opengeo.org/" target="_blank">http://opengeo.org/</a><br>Expert service straight from the developers.<br>
</div>