[OASIS Issue Tracker] Updated: (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:all-tabpanel ]

Michael Pizzo updated ODATA-390:
--------------------------------

    Proposal: 
In section 7.1, Primitive Value, replace the following sentence:
"Geography and geometry values are represented as defined in [GeoJSON]."
with:
"Geography and geometry values are represented as defined in [GeoJSON], with the following modifications:
-Keys SHOULD be ordered with type first, then coordinates, then any other keys
-The 'coordinates' member of a 'LineString" can have zero or more positions
-The CRS MUST be a Named CRS and MUST be an ESPG SRID legacy identifier. OGC CRS URNs are not supported.

  was:
In section 7.1, Primitive Value, replace the following sentence:
"Geography and geometry values are represented as defined in [GeoJSON]."
with:
"Geography and geometry values are represented as defined in [GeoJSON], with the following modifications:
-Keys SHOULD be ordered with type first, then coordinates, then any other keys
-The 'coordinates' member of a 'LineString MUST be an array of zero or more positions
-The CRS MUST be a Named CRS and MUST be an ESPG SRID legacy identifier. OGC CRS URNs are not supported.


Stefan;

Note that the proposal does not propose copying the text from V3, which I believe contains the contentious assertions about GeoJSON, but instead merely states the restrictions in representing spatial types in OData. Does the wording of the proposal (with the minor edit) capture the issue and alleviate your concerns?

> 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