OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


     [ 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
-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 

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


> 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

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]