Skip to content

Commit c96aa00

Browse files
committed
add version conformance (opengeospatial#162)
1 parent ebff466 commit c96aa00

File tree

1 file changed

+57
-37
lines changed

1 file changed

+57
-37
lines changed

standard/clause_specification_text.adoc

Lines changed: 57 additions & 37 deletions
Original file line numberDiff line numberDiff line change
@@ -15,6 +15,9 @@ The following is an illustrative example of using CoverageJSON to encode air tem
1515
[%unnumbered%]
1616
```json
1717
{
18+
"conformsTo": [
19+
"http://www.opengis.net/spec/covjson/1.0"
20+
],
1821
"type" : "Coverage",
1922
"domain" : {
2023
"type": "Domain",
@@ -107,7 +110,24 @@ ParameterGroup "0..1" *-- "1..*" Parameter
107110
@enduml
108111
....
109112

110-
//## 2. i18n Objects
113+
//##
114+
=== Version
115+
116+
//## 2. Conformance
117+
=== Conformance
118+
119+
The ``conformsTo`` property to identifies the version of the CoverageJSON standard that the metadata record conforms to. Conformance identification is valuable for version detection and handling of content.
120+
121+
Example:
122+
123+
[%unnumbered%]
124+
```json
125+
"conformsTo": [
126+
"http://www.opengis.net/spec/covjson/1.0"
127+
]
128+
```
129+
130+
//## 3. i18n Objects
111131
=== i18n Objects
112132

113133
An i18n object represents a string in multiple languages where each key is a language tag as defined in http://tools.ietf.org/html/bcp47[BCP 47], and the value is the string in that language.
@@ -123,7 +143,7 @@ Example:
123143
}
124144
```
125145
[[parameter_objects]]
126-
//## 3. Parameter Objects
146+
//## 4. Parameter Objects
127147
=== Parameter Objects
128148

129149
Parameter objects represent metadata about the values of the coverage in terms of the observed property (like water temperature), the units, and others.
@@ -208,7 +228,7 @@ Example for a categorical-data parameter:
208228
}
209229
```
210230
[[parametergroup_objects]]
211-
//## 4. ParameterGroup Objects
231+
//## 5. ParameterGroup Objects
212232
=== ParameterGroup Objects
213233

214234
Parameter group objects represent logical groups of parameters, for example vector quantities.
@@ -307,17 +327,17 @@ and `"SST_stddev"`:
307327
}
308328
```
309329
[[reference_system_objects]]
310-
//## 5. Reference system objects
330+
//## 6. Reference system objects
311331
=== Reference system objects
312332

313333
Reference system objects are used to provide information about how to interpret coordinate values within the domain. Coordinates are usually geospatial or temporal in nature, but may also be categorical (based on identifiers). All reference system objects MUST have a member `"type"`, the possible values of which are given in the sections below. Custom values MAY be used as detailed in the <<extensions,Extensions>> section.
314334

315335
[[geospatial_coordinate_reference_systems]]
316-
//### 5.1. Geospatial Coordinate Reference Systems
336+
//### 6.1. Geospatial Coordinate Reference Systems
317337
==== Geospatial Coordinate Reference Systems
318338
Geospatial coordinate reference systems (CRSs) link coordinate values to the Earth.
319339

320-
//#### 5.1.1 Geographic Coordinate Reference Systems
340+
//#### 6.1.1 Geographic Coordinate Reference Systems
321341
===== Geographic Coordinate Reference Systems
322342

323343
Geographic CRSs anchor coordinate values to an ellipsoidal approximation of the Earth. They have coordinate axes of geodetic longitude and geodetic latitude, and perhaps height above the ellipsoid (i.e. they can be two- or three-dimensional). The origin of the CRS is on the surface of the ellipsoid.
@@ -350,7 +370,7 @@ Example of a three-dimensional geographic CRS (latitude-longitude-height):
350370
}
351371
```
352372

353-
//#### 5.1.2 Projected Coordinate Reference Systems
373+
//#### 6.1.2 Projected Coordinate Reference Systems
354374
===== Projected Coordinate Reference Systems
355375

356376
Projected CRSs use two coordinates to denote positions on a Cartesian plane, which is derived from projecting the ellipsoid according to some defined transformation.
@@ -371,7 +391,7 @@ Example of a projected CRS using the http://spatialreference.org/ref/epsg/osgb-1
371391
}
372392
```
373393

374-
//#### 5.1.3 Vertical Coordinate Reference Systems
394+
//#### 6.1.3 Vertical Coordinate Reference Systems
375395
===== Vertical Coordinate Reference Systems
376396

377397
Vertical CRSs use a single coordinate to denote some measure of height or depth, usually approximately oriented with gravity.
@@ -391,7 +411,7 @@ Example of a vertical CRS, here representing height above the NAVD88 datum in me
391411
```
392412

393413
[[temporal_reference_systems]]
394-
//### 5.2. Temporal Reference Systems
414+
//### 6.2. Temporal Reference Systems
395415
==== Temporal Reference Systems
396416

397417
Time is referenced by a temporal reference system (temporal RS). In the current version of this Community Standard, only a string-based notation for time values is defined. Future versions of this Community Standard may allow for alternative notations, such as recording time values as numeric offsets from a given temporal datum (e.g. “days since 1970-01-01”).
@@ -423,7 +443,7 @@ Example:
423443
```
424444

425445
[[identifier_based_reference_systems]]
426-
//### 5.3. Identifier-based Reference Systems
446+
//### 6.3. Identifier-based Reference Systems
427447
==== Identifier-based Reference Systems
428448

429449
Identifier-based reference systems (identifier RS) .
@@ -463,7 +483,7 @@ Example of a geographic identifier reference system:
463483
The domain values in the above example would be `"de"` and `"gb"`.
464484

465485
[[coveragejson_objects]]
466-
//## 6. CoverageJSON Objects
486+
//## 7. CoverageJSON Objects
467487
=== CoverageJSON Objects
468488

469489
CoverageJSON documents always consist of a single object. This object (referred to as the CoverageJSON object below) represents a domain, range, coverage, or collection of coverages.
@@ -472,7 +492,7 @@ CoverageJSON documents always consist of a single object. This object (referred
472492
- The CoverageJSON object MUST have a member with the name `"type"` whose value is one of: `"Domain"`, `"NdArray"` (a range encoding), `"TiledNdArray"` (a range encoding), `"Coverage"`, or `"CoverageCollection"`. The case of the type member values MUST be as shown here.
473493

474494
[[domain_objects]]
475-
//### 6.1. Domain Objects
495+
//### 7.1. Domain Objects
476496
==== Domain Objects
477497

478498
A domain object is a CoverageJSON object which defines a set of positions and their extent in one or more referencing systems.
@@ -496,7 +516,7 @@ Its general structure is:
496516
- A domain object MUST have a `"referencing"` member if the domain object is not part of a coverage collection or if the coverage collection does not have a `"referencing"` member.
497517

498518
[[axis_objects]]
499-
//#### 6.1.1. Axis Objects
519+
//#### 7.1.1. Axis Objects
500520
===== Axis Objects
501521

502522
- An axis object MUST have either a `"values"` member or, as a compact notation for a regularly spaced numeric axis, have all the members `"start"`, `"stop"`, and `"num"`.
@@ -562,7 +582,7 @@ Example of an axis object with Polygon values:
562582
```
563583

564584
[[reference_system_connection_objects]]
565-
//#### 6.1.2. Reference System Connection Objects
585+
//#### 7.1.2. Reference System Connection Objects
566586
===== Reference System Connection Objects
567587
A reference system connection object creates a link between values within domain axes and a reference system to be able to interpret those values, e.g. as coordinates in a certain coordinate reference system.
568588

@@ -582,7 +602,7 @@ Example of a reference system connection object:
582602
}
583603
```
584604

585-
//#### 6.1.3. Examples
605+
//#### 7.1.3. Examples
586606
===== Examples
587607

588608
Example of a domain object with <<grid,Grid>> <<common_domain_types,domain type>>:
@@ -648,7 +668,7 @@ Example of a domain object with <<trajectory,Trajectory>> <<common_domain_types,
648668
```
649669

650670
[[ndarray_objects]]
651-
//### 6.2. NdArray Objects
671+
//### 7.2. NdArray Objects
652672
==== NdArray Objects
653673

654674
A CoverageJSON object with the type `"NdArray"` is an NdArray object. It represents a multidimensional (>= 0D) array with named axes, encoded as a flat, one-dimensional JSON array in row-major order.
@@ -685,7 +705,7 @@ The ordering of the data values with respect to their dimensions is equivalent t
685705
```
686706

687707
[[tiledndarray_objects]]
688-
//### 6.3. TiledNdArray Objects
708+
//### 7.3. TiledNdArray Objects
689709
==== TiledNdArray Objects
690710

691711
A CoverageJSON object with the type `"TiledNdArray"` is a TiledNdArray object. It represents a multidimensional (>= 1D) array with named axes that is split up into sets of linked NdArray documents. Each tileset typically covers a specific data access scenario, for example, loading a single time slice of a grid vs. loading a time series of a spatial subset of a grid.
@@ -802,7 +822,7 @@ Example:
802822
```
803823

804824
[[coverage_objects]]
805-
//### 6.4. Coverage Objects
825+
//### 7.4. Coverage Objects
806826
==== Coverage Objects
807827

808828
A CoverageJSON object with the type `"Coverage"` is a coverage object.
@@ -821,7 +841,7 @@ Example:
821841
See the <<annex_vertical_profile_coverage,Vertical Profile Coverage Example>>.
822842

823843
[[coverage_collection_objects]]
824-
//### 6.5. Coverage Collection Objects
844+
//### 7.5. Coverage Collection Objects
825845
==== Coverage Collection Objects
826846

827847
A CoverageJSON object with the type `"CoverageCollection"` is a coverage collection object.
@@ -838,13 +858,13 @@ Example:
838858
See the <<annex_coverage_collection,Coverage Collection Example>>.
839859

840860
[[extensions]]
841-
//## 7. Extensions
861+
//## 8. Extensions
842862
=== Extensions
843863

844864
A CoverageJSON document can be extended with custom members and types in a robust and interoperable way. For that, it makes use of absolute URIs and compact URIs (prefix:suffix) in order to avoid conflicts with other extensions and future versions of the format. A central registry of compact URI prefixes is provided which anyone can extend and which is a simple mapping from compact URI prefix to namespace URI in order to avoid collisions with other extensions that are based on compact URIs as well. Extensions that do not follow this approach MAY use simple names instead of absolute or compact URIs but have to accept the consequence of the document being less interoperable and future-proof. In certain use cases this is not an issue and may be a preferred solution for simplicity reasons, for example, if such CoverageJSON documents are only used internally and are not meant to be shared to a wider audience.
845865

846866
[[custom_members]]
847-
//### 7.1. Custom members
867+
//### 8.1. Custom members
848868
==== Custom members
849869

850870
If a custom member is added to a CoverageJSON document, its name SHOULD be a compact URIs of the form `"prefix:suffix"`.
@@ -881,7 +901,7 @@ Example of a different value structure:
881901
```
882902

883903
[[custom_types]]
884-
//### 7.2. Custom types
904+
//### 8.2. Custom types
885905
==== Custom types
886906

887907
Custom types MAY be used with the following members:
@@ -927,7 +947,7 @@ Example of a custom reference system type using a compact URI:
927947
```
928948

929949
[[jsonld]]
930-
//## 8. JSON-LD
950+
//## 9. JSON-LD
931951
=== JSON-LD
932952

933953
If no JSON-LD context is given, then the default context `https://covjson.org/context.jsonld` SHALL be assumed. Note that this context includes https://covjson.org/prefixes/[registered namespace prefixes] and MAY be updated in a backwards-compatible way as the format evolves.
@@ -961,14 +981,14 @@ Example:
961981
In this example, additional semantics for the registered `dct` prefix are provided by stating that the `"dct:license"` member value in this document is an identifier and not just an unstructured string.
962982

963983
[[resolving_domain_and_range_urls]]
964-
//## 9. Resolving domain and range URLs
984+
//## 10. Resolving domain and range URLs
965985
=== Resolving domain and range URLs
966986

967987
If a domain or range is referenced by a URL in a CoverageJSON document, then the client should, whenever is appropriate, load the data from the given URL and treat the loaded data as if it was directly embedded in place of the URL. When sending HTTP requests, the `Accept` header SHOULD be set appropriately to the CoverageJSON media type.
968988

969989

970990
[[common_domain_types]]
971-
//## 10. Common Domain Types
991+
//## 11. Common Domain Types
972992
=== Common Domain Types
973993

974994
This OGC Community Standard defines the following domain types: Grid, VerticalProfile, PointSeries, Point, MultiPointSeries, MultiPoint, PolygonSeries, Polygon, MultiPolygonSeries, MultiPolygon, Trajectory, Section.
@@ -1011,7 +1031,7 @@ Requirements for all domain types defined in this OGC Community Standard:
10111031
|=====
10121032

10131033
[[grid]]
1014-
//### 10.1. Grid
1034+
//### 11.1. Grid
10151035
==== Grid
10161036

10171037
- A domain with Grid domain type MUST have the axes `"x"` and `"y"` and MAY have the axes `"z"` and `"t"`.
@@ -1065,7 +1085,7 @@ Coverage example:
10651085
}
10661086
```
10671087
[[vertical_profile]]
1068-
//### 10.2. VerticalProfile
1088+
//### 11.2. VerticalProfile
10691089
==== VerticalProfile
10701090

10711091
- A domain with VerticalProfile domain type MUST have the axes `"x"`, `"y"`, and `"z"`, where `"x"` and `"y"` MUST have a single coordinate value only.
@@ -1121,7 +1141,7 @@ Coverage example:
11211141
```
11221142

11231143
[[pointseries]]
1124-
//### 10.3. PointSeries
1144+
//### 11.3. PointSeries
11251145
==== PointSeries
11261146

11271147
- A domain with PointSeries domain type MUST have the axes `"x"`, `"y"`, and `"t"` where `"x"` and `"y"` MUST have a single coordinate value only.
@@ -1177,7 +1197,7 @@ Coverage example:
11771197
```
11781198

11791199
[[point]]
1180-
//### 10.4. Point
1200+
//### 11.4. Point
11811201
==== Point
11821202

11831203
- A domain with Point domain type MUST have the axes `"x"` and `"y"` and MAY have the axes `"z"` and `"t"` where all MUST have a single coordinate value only.
@@ -1230,7 +1250,7 @@ Coverage example:
12301250
```
12311251

12321252
[[multipointseries]]
1233-
//### 10.5. MultiPointSeries
1253+
//### 11.5. MultiPointSeries
12341254
==== MultiPointSeries
12351255

12361256
- A domain with MultiPointSeries domain type MUST have the axes `"composite"` and `"t"`.
@@ -1318,7 +1338,7 @@ Coverage example:
13181338
```
13191339

13201340
[[multipoint]]
1321-
//### 10.6. MultiPoint
1341+
//### 11.6. MultiPoint
13221342
==== MultiPoint
13231343

13241344
- A domain with MultiPoint domain type MUST have the axis `"composite"` and MAY have the axis `"t"` where `"t"` MUST have a single coordinate value only.
@@ -1403,7 +1423,7 @@ Coverage example:
14031423
}
14041424
```
14051425
[[trajectory]]
1406-
//### 10.7. Trajectory
1426+
//### 11.7. Trajectory
14071427
==== Trajectory
14081428

14091429
- A domain with Trajectory domain type MUST have the axis `"composite"` and MAY have the axis `"z"` where `"z"` MUST have a single coordinate value only.
@@ -1511,7 +1531,7 @@ Coverage example:
15111531
```
15121532

15131533
[[section]]
1514-
//### 10.8. Section
1534+
//### 11.8. Section
15151535
==== Section
15161536

15171537
- A domain with Section domain type MUST have the axes `"composite"` and `"z"`.
@@ -1578,7 +1598,7 @@ Coverage example:
15781598
```
15791599

15801600
[[polygon]]
1581-
//### 10.9. Polygon
1601+
//### 11.9. Polygon
15821602
==== Polygon
15831603

15841604
Polygons in this domain domain type are defined equally to GeoJSON, except that they can only contain `[x,y]` positions (and not `z` or additional coordinates):
@@ -1647,7 +1667,7 @@ Coverage example:
16471667
```
16481668

16491669
[[polygonseries]]
1650-
//### 10.10. PolygonSeries
1670+
//### 11.10. PolygonSeries
16511671
==== PolygonSeries
16521672

16531673
- A domain with PolygonSeries domain type MUST have the axes `"composite"` and `"t"` where `"composite"` MUST have a single Polygon value. Polygons are defined in the Polygon domain type.
@@ -1714,7 +1734,7 @@ Coverage example:
17141734
```
17151735

17161736
[[multipolygon]]
1717-
//### 10.11. MultiPolygon
1737+
//### 11.11. MultiPolygon
17181738
==== MultiPolygon
17191739

17201740
- A domain with MultiPolygon domain type MUST have the axis `"composite"` where the values are Polygons. Polygons are defined in the Polygon domain type.
@@ -1783,7 +1803,7 @@ Coverage example:
17831803
```
17841804

17851805
[[multipolygonseries]]
1786-
//### 10.12. MultiPolygonSeries
1806+
//### 11.12. MultiPolygonSeries
17871807
==== MultiPolygonSeries
17881808

17891809
- A domain with MultiPolygonSeries domain type MUST have the axes `"composite"` and `"t"` where the values of `"composite"` are Polygons. Polygons are defined in the Polygon domain type.

0 commit comments

Comments
 (0)