[OASIS Issue Tracker] Commented: (ODATA-390) Additional description of use of GeoJSON in OData JSON.

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/ODATA-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33452#action_33452 ] 

Stefan Drees commented on ODATA-390:
------------------------------------

Mike;

IMO good decision not to simply copy over in this case. 
The current proposal in all its brevity seems to be more to the point.

The "LineString heads up" to ease acceptance for certain implementations (?) looks a bit bizarre but acceptable as far as I understand. 
But please see in details below as I found no indications or samples of actual use or where this allowance is stated.

If  we change at least the last list item though as the two MUSTs are irritating (due to the brevity) I will second the proposal. 
The Coordinate Reference System (CRS) as defined in GeoJSON is 1) optional and 2) has a lowercase key name (crs). 
In the GeoJSON spec it is referred to as the "CRS object".

So I suggest instead of:
"""The CRS MUST be a Named CRS and MUST be an ESPG SRID legacy identifier. OGC CRS URNs are not supported."""

something like:
"""If the optional CRS object is present, it MUST be of type name where the value of the contained properties object name member is an EPSG SRID legacy identifier."""

As I understand from the docs at e.g. [1](http://www.odata.org/2011/10/geospatial-properties/) there is also in OData and related frameworks some notion of a useful default CRS. So no problem here, even if the crs member goes away for ever ...

Details to the LineString exception: 

A) At [1]  I did not find any indication for LineString possibly having less than two coordinates but I may have overlooked it. I find:
"""The LineString types—Edm.GeographyLineString and Edm.GeometryLineString

"LineString" is defined as per the OGC. Roughly, it consists of a set of positions with "linear" interpolation between those positions, all in the same topology and CRS, and represents a path. Edm.GeographyLineString is used for geographic LineStrings; its segments are great elliptical arcs. Edm.GeometryLineString is used for geometric coordinates; it uses ordinary linear interpolation.

These primitives are used for properties with a static path type. Example properties would be the path for a bus route entity, or the path that I followed on my jog this morning (stored in a Run entity).

"""

B) As [1] states to be also based upon [2](http://portal.opengeospatial.org/files/?artifact_id=25355) which in turn gives in section 6.1.7.1 Description: 
"""A LineString is a Curve with linear interpolation between Points. Each consecutive pair of Points defines a Line segment.
A Line is a LineString with exactly 2 Points.""" 

C) and other clients that directly use the GML schema [3](http://schemas.opengis.net/gml/3.2.1/geometryPrimitives.xsd) for validation have the LineStringSegment element with a minOccurs attribute set to 2 and documented as "A LineStringSegment is a curve segment that is defined by two or more control points including the start and end point, with linear interpolation between them. The content model follows the general pattern for the encoding of curve segments.".

D) it is assumed by authors of the current GeoJSON spec, that "Most consumers of GeoJSON are going to be baffled by lines with a single point."(http://lists.geojson.org/pipermail/geojson-geojson.org/2013-May/000754.html)

PS: If there are occurrences of crd strings in this comment,  please forgive me not having always forbidden auto.correction suggestiosn when having typed crs ;-)


> Additional description of use of GeoJSON in OData JSON.
> -------------------------------------------------------
>
>                 Key: ODATA-390
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-390
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData JSON Format
>    Affects Versions: V4.0_CSD01
>         Environment: [Proposed]
>            Reporter: Michael Pizzo
>             Fix For: V4.0_CSD02
>
>
> The following verbage from OData 3.0's description of the use of GeoJSON within an OData JSON payload is missing from our OData JSON 4.0 specification. I believe this was an accidental omission, and that it should be added:
> 2.2.6.3.1.1   Modifications to GeoJSON for Use in OData
> Any GeoJSON value that is used in OData SHOULD order the keys with type first, then coordinates, then any other keys. This improves streaming parser performance when parsing values on open types or in other cases where metadata is not present.
> 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.
> All other arrays in GeoJSON are allowed to be empty, so no change is necessary. GeoJSON does require that any LinearRing contain a minimum of four positions. That requirement still holds that LinearRings can show up only in other arrays and that those arrays can be empty.
> GeoJSON allows multiple types of CRS. In OData, only one of those types is allowed. In GeoJSON in OData, a CRS MUST be a Named CRS. In addition, OGC CRS URNs are not supported. The CRS identifier MUST be an EPSG SRID legacy identifier.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira