[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (ODATA-965) UpdateGeoJSON Reference to RFC7946
[ https://issues.oasis-open.org/browse/ODATA-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=64022#comment-64022 ]
Stefan Hagen commented on ODATA-965:
------------------------------------
Analysis based on "odata-json-format-v4.01-wd01" (as downloaded from kavi 2016-NOV-07):
This document has only two places specific to GeoJSON:
a) the reference itself - which is proposed to be changed - and
b) inside section 7.1 "Primitive Value" last two paragraphs before (and one entry in) "Example 11"
Ad a) OK
Ad b) Analysis:
Context:
"""
Geography and geometry values are represented as geometry types 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 name
member of the contained properties object is an EPSG SRID legacy identifier.
Geography and geometry types have the same representation in a JSON payload. Whether the value represents a geography type or geometry type is inferred from its usage or specified using the type annotation.
Example 11:
{
"NullValue": null,
"TrueValue": true,
"FalseValue": false,
"BinaryValue": "T0RhdGE",
"IntegerValue": -128,
"DoubleValue": 3.1415926535897931,
"SingleValue@Core.NumericValueException": "INF",
"DecimalValue": 34.95,
"StringValue": "Say \"Hello\",\nthen go",
"DateValue": "2012-12-03",
"DateTimeOffsetValue": "2012-12-03T07:16:23Z",
"DurationValue": "P12DT23H59M59.999999999999S",
"TimeOfDayValue": "07:59:59.999",
"GuidValue": "01234567-89ab-cdef-0123-456789abcdef",
"Int64Value": 0,
"ColorEnumValue": "Yellow",
"GeographyPoint": {"type": "Point","coordinates":[142.1,64.1]}
}
"""
Evaluation:
W.r.t. Keys (a.k.a. members) we deviate from RFC (unchanged!) as we did from current referenced draft before, in that in that we strongly suggest a specific ordering.
W.r.t. LineString coordinates member we deviate from RFC (unchanged!) as we did from current referenced draft before, in that we allow 0 or more elements instead of two or more.
W.r.t. to the optional (!) CRS member - this has been removed in RFC which should be perfectly ok ;-) - given the consensus that it was never really useful before and was optional in the first place. So we have a MUST but in an optional member ... and all previous generated data will have either followed or not followed our MUST not withstanding the new RFC.
In draft's 3.1 Named CRS section it states:
"""
The value of that "name" member must be a string
identifying a coordinate reference system. OGC CRS URNs such as
"urn:ogc:def:crs:OGC::CRS84" are RECOMMENDED over legacy identifiers
such as "EPSG:4326".
"""
in RFC it now states in 4. "Coordinate Reference System":
"""
The coordinate reference system for all GeoJSON coordinates is a
geographic coordinate reference system, using the World Geodetic
System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units
of decimal degrees. This is equivalent to the coordinate reference
system identified by the Open Geospatial Consortium (OGC) URN
urn:ogc:def:crs:OGC::CRS84. An OPTIONAL third-position element SHALL
be the height in meters above or below the WGS 84 reference
ellipsoid. In the absence of elevation values, applications
sensitive to height or depth SHOULD interpret positions as being at
local ground or sea level.
Note: the use of alternative coordinate reference systems was
specified in [GJ2008], but it has been removed from this version of
the specification because the use of different coordinate reference
systems -- especially in the manner specified in [GJ2008] -- has
proven to have interoperability issues. In general, GeoJSON
processing software is not expected to have access to coordinate
reference system databases or to have network access to coordinate
reference system transformation parameters. However, where all
involved parties have a prior arrangement, alternative coordinate
reference systems can be used without risk of data being
misinterpreted.
"""
> UpdateGeoJSON Reference to RFC7946
> ----------------------------------
>
> Key: ODATA-965
> URL: https://issues.oasis-open.org/browse/ODATA-965
> Project: OASIS Open Data Protocol (OData) TC
> Issue Type: Improvement
> Components: OData JSON Format
> Affects Versions: V4.01_WD01
> Environment: Proposal needed for CSD01
> Reporter: Stefan Hagen
> Assignee: Stefan Hagen
> Priority: Minor
> Fix For: V4.01_WD01
>
>
> The GeoJSON community submitted it's standard as an internet draft to IETF.
> This lead to the foundation of the IETF Geographic JSON Working Group (https://datatracker.ietf.org/wg/geojson/charter/).
> As of August, 11 2016 the GeoJSON specification now is the RFC 7946 (on the internet standards track).
> We should reference this one instead of the intermediate draft (after evaluation of the changes cited below from the RFC, Appendix B):
> Appendix B. Changes from the Pre-IETF GeoJSON Format Specification
> This appendix briefly summarizes non-editorial changes from the 2008
> specification [GJ2008].
> B.1. Normative Changes
> o Specification of coordinate reference systems has been removed,
> i.e., the "crs" member of [GJ2008] is no longer used.
> o In the absence of elevation values, applications sensitive to
> height or depth SHOULD interpret positions as being at local
> ground or sea level (see Section 4).
> o Implementations SHOULD NOT extend position arrays beyond 3
> elements (see Section 3.1.1).
> o A line between two positions is a straight Cartesian line (see
> Section 3.1.1).
> o Polygon rings MUST follow the right-hand rule for orientation
> (counterclockwise external rings, clockwise internal rings).
> o The values of a "bbox" array are "[west, south, east, north]", not
> "[minx, miny, maxx, maxy]" (see Section 5).
> o A Feature object's "id" member is a string or number (see
> Section 3.2).
> o Extensions MAY be used, but MUST NOT change the semantics of
> GeoJSON members and types (see Section 6).
> o GeoJSON objects MUST NOT contain the defining members of other
> types (see Section 7.1).
> o The media type for GeoJSON is "application/geo+json".
> B.2. Informative Changes
> o The definition of a GeoJSON text has been added.
> o Rules for mapping 'geo' URIs have been added.
> o A recommendation of the I-JSON [RFC7493] constraints has been
> added.
> o Implementers are cautioned about the effect of excessive
> coordinate precision on interoperability.
> o Interoperability concerns of GeometryCollections are noted. These
> objects should be used sparingly (see Section 3.1.8).
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]