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] Commented: (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:comment-tabpanel&focusedCommentId=33421#action_33421 ] 

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

Interesting topic :-) but I would suggest to better not  copy the above paragraphs - cited in the description of this issue - from version 3 of OData **unchanged** into one of our work products.

Some feedback:

As I read it, the current spec of GeoJSON explicitly states in [section 2.1.4](http://geojson.org/geojson-spec.html#linestring) that "a LinearRing is not explicitly represented as a GeoJSON geometry type". We should not refer to a GeoJSON type, that does not exist (it is used to declare rules for Polygons in the GeoJSON spec, but as key in a JSON object it is not defined).

Also the use of coordinate reference systems is a rather under-used feature in the wild (mostly two of the many possible systems dominate there is my understanding) and also might be removed from future versions of the spec (if I interpret the current state of discussion on the geojson mailing list right).

Going further in my "guestimates" there is a non-zero probability, that in an updated GeoJSON spec there will only be an optional reference to a CRS (maybe with key crsRef) and not the current (also optional) CRS object, as this has prooved to be a very weak point of the format (promising more, than it holds).

I also do not understand the sentences: "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." and would like to have an idea what is assumed here about GeoJSON "uncut" and what is said about GeoJSON in OData with these statements, before I can evaluate, if we should or should not include it.





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