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

Tim Schaub tschaub at opengeo.org
Wed May 15 07:53:41 PDT 2013


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20130515/d69b2939/attachment-0005.htm>


More information about the GeoJSON mailing list