<div dir="ltr"><div><div>Yep, simple features compatibility was the motivation. Most consumers of GeoJSON are going to be baffled by lines with a single point.<br><br></div>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.<br>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 15, 2013 at 8:53 AM, Tim Schaub <span dir="ltr"><<a href="mailto:tschaub@opengeo.org" target="_blank">tschaub@opengeo.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">You could call it cargo cult.<div><br></div><div>See, for example, the geometry primitives schema for GML 3.2.1:</div>
<div><a href="http://schemas.opengis.net/gml/3.2.1/geometryPrimitives.xsd" target="_blank">http://schemas.opengis.net/gml/3.2.1/geometryPrimitives.xsd</a><br>
</div><div><br></div><div><div> <span style="white-space:pre-wrap"><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>So perhaps the justification is to work well with other geometry serializations.</div><div><br></div><div>Tim</div><div><br></div></div></div><div class="gmail_extra"><div><div class="h5"><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></div></div><span class="HOEnZb"><font color="#888888">-- <br>Tim Schaub<br>OpenGeo <a href="http://opengeo.org/" target="_blank">http://opengeo.org/</a><br>Expert service straight from the developers.<br>
</font></span></div>
<br>_______________________________________________<br>
GeoJSON mailing list<br>
<a href="mailto:GeoJSON@lists.geojson.org">GeoJSON@lists.geojson.org</a><br>
<a href="http://lists.geojson.org/listinfo.cgi/geojson-geojson.org" target="_blank">http://lists.geojson.org/listinfo.cgi/geojson-geojson.org</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Sean Gillies
</div>