You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
111
131
=== i18n Objects
112
132
113
133
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:
123
143
}
124
144
```
125
145
[[parameter_objects]]
126
-
//## 3. Parameter Objects
146
+
//## 4. Parameter Objects
127
147
=== Parameter Objects
128
148
129
149
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:
208
228
}
209
229
```
210
230
[[parametergroup_objects]]
211
-
//## 4. ParameterGroup Objects
231
+
//## 5. ParameterGroup Objects
212
232
=== ParameterGroup Objects
213
233
214
234
Parameter group objects represent logical groups of parameters, for example vector quantities.
@@ -307,17 +327,17 @@ and `"SST_stddev"`:
307
327
}
308
328
```
309
329
[[reference_system_objects]]
310
-
//## 5. Reference system objects
330
+
//## 6. Reference system objects
311
331
=== Reference system objects
312
332
313
333
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.
314
334
315
335
[[geospatial_coordinate_reference_systems]]
316
-
//### 5.1. Geospatial Coordinate Reference Systems
336
+
//### 6.1. Geospatial Coordinate Reference Systems
317
337
==== Geospatial Coordinate Reference Systems
318
338
Geospatial coordinate reference systems (CRSs) link coordinate values to the Earth.
319
339
320
-
//#### 5.1.1 Geographic Coordinate Reference Systems
340
+
//#### 6.1.1 Geographic Coordinate Reference Systems
321
341
===== Geographic Coordinate Reference Systems
322
342
323
343
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):
350
370
}
351
371
```
352
372
353
-
//#### 5.1.2 Projected Coordinate Reference Systems
373
+
//#### 6.1.2 Projected Coordinate Reference Systems
354
374
===== Projected Coordinate Reference Systems
355
375
356
376
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
371
391
}
372
392
```
373
393
374
-
//#### 5.1.3 Vertical Coordinate Reference Systems
394
+
//#### 6.1.3 Vertical Coordinate Reference Systems
375
395
===== Vertical Coordinate Reference Systems
376
396
377
397
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
391
411
```
392
412
393
413
[[temporal_reference_systems]]
394
-
//### 5.2. Temporal Reference Systems
414
+
//### 6.2. Temporal Reference Systems
395
415
==== Temporal Reference Systems
396
416
397
417
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:
423
443
```
424
444
425
445
[[identifier_based_reference_systems]]
426
-
//### 5.3. Identifier-based Reference Systems
446
+
//### 6.3. Identifier-based Reference Systems
427
447
==== Identifier-based Reference Systems
428
448
429
449
Identifier-based reference systems (identifier RS) .
@@ -463,7 +483,7 @@ Example of a geographic identifier reference system:
463
483
The domain values in the above example would be `"de"` and `"gb"`.
464
484
465
485
[[coveragejson_objects]]
466
-
//## 6. CoverageJSON Objects
486
+
//## 7. CoverageJSON Objects
467
487
=== CoverageJSON Objects
468
488
469
489
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
472
492
- 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.
473
493
474
494
[[domain_objects]]
475
-
//### 6.1. Domain Objects
495
+
//### 7.1. Domain Objects
476
496
==== Domain Objects
477
497
478
498
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:
496
516
- 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.
497
517
498
518
[[axis_objects]]
499
-
//#### 6.1.1. Axis Objects
519
+
//#### 7.1.1. Axis Objects
500
520
===== Axis Objects
501
521
502
522
- 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:
562
582
```
563
583
564
584
[[reference_system_connection_objects]]
565
-
//#### 6.1.2. Reference System Connection Objects
585
+
//#### 7.1.2. Reference System Connection Objects
566
586
===== Reference System Connection Objects
567
587
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.
568
588
@@ -582,7 +602,7 @@ Example of a reference system connection object:
582
602
}
583
603
```
584
604
585
-
//#### 6.1.3. Examples
605
+
//#### 7.1.3. Examples
586
606
===== Examples
587
607
588
608
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,
648
668
```
649
669
650
670
[[ndarray_objects]]
651
-
//### 6.2. NdArray Objects
671
+
//### 7.2. NdArray Objects
652
672
==== NdArray Objects
653
673
654
674
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
685
705
```
686
706
687
707
[[tiledndarray_objects]]
688
-
//### 6.3. TiledNdArray Objects
708
+
//### 7.3. TiledNdArray Objects
689
709
==== TiledNdArray Objects
690
710
691
711
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:
802
822
```
803
823
804
824
[[coverage_objects]]
805
-
//### 6.4. Coverage Objects
825
+
//### 7.4. Coverage Objects
806
826
==== Coverage Objects
807
827
808
828
A CoverageJSON object with the type `"Coverage"` is a coverage object.
@@ -821,7 +841,7 @@ Example:
821
841
See the <<annex_vertical_profile_coverage,Vertical Profile Coverage Example>>.
822
842
823
843
[[coverage_collection_objects]]
824
-
//### 6.5. Coverage Collection Objects
844
+
//### 7.5. Coverage Collection Objects
825
845
==== Coverage Collection Objects
826
846
827
847
A CoverageJSON object with the type `"CoverageCollection"` is a coverage collection object.
@@ -838,13 +858,13 @@ Example:
838
858
See the <<annex_coverage_collection,Coverage Collection Example>>.
839
859
840
860
[[extensions]]
841
-
//## 7. Extensions
861
+
//## 8. Extensions
842
862
=== Extensions
843
863
844
864
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.
845
865
846
866
[[custom_members]]
847
-
//### 7.1. Custom members
867
+
//### 8.1. Custom members
848
868
==== Custom members
849
869
850
870
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:
881
901
```
882
902
883
903
[[custom_types]]
884
-
//### 7.2. Custom types
904
+
//### 8.2. Custom types
885
905
==== Custom types
886
906
887
907
Custom types MAY be used with the following members:
@@ -927,7 +947,7 @@ Example of a custom reference system type using a compact URI:
927
947
```
928
948
929
949
[[jsonld]]
930
-
//## 8. JSON-LD
950
+
//## 9. JSON-LD
931
951
=== JSON-LD
932
952
933
953
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:
961
981
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.
962
982
963
983
[[resolving_domain_and_range_urls]]
964
-
//## 9. Resolving domain and range URLs
984
+
//## 10. Resolving domain and range URLs
965
985
=== Resolving domain and range URLs
966
986
967
987
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.
968
988
969
989
970
990
[[common_domain_types]]
971
-
//## 10. Common Domain Types
991
+
//## 11. Common Domain Types
972
992
=== Common Domain Types
973
993
974
994
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:
1011
1031
|=====
1012
1032
1013
1033
[[grid]]
1014
-
//### 10.1. Grid
1034
+
//### 11.1. Grid
1015
1035
==== Grid
1016
1036
1017
1037
- 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:
1065
1085
}
1066
1086
```
1067
1087
[[vertical_profile]]
1068
-
//### 10.2. VerticalProfile
1088
+
//### 11.2. VerticalProfile
1069
1089
==== VerticalProfile
1070
1090
1071
1091
- 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:
1121
1141
```
1122
1142
1123
1143
[[pointseries]]
1124
-
//### 10.3. PointSeries
1144
+
//### 11.3. PointSeries
1125
1145
==== PointSeries
1126
1146
1127
1147
- 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:
1177
1197
```
1178
1198
1179
1199
[[point]]
1180
-
//### 10.4. Point
1200
+
//### 11.4. Point
1181
1201
==== Point
1182
1202
1183
1203
- 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:
1230
1250
```
1231
1251
1232
1252
[[multipointseries]]
1233
-
//### 10.5. MultiPointSeries
1253
+
//### 11.5. MultiPointSeries
1234
1254
==== MultiPointSeries
1235
1255
1236
1256
- A domain with MultiPointSeries domain type MUST have the axes `"composite"` and `"t"`.
@@ -1318,7 +1338,7 @@ Coverage example:
1318
1338
```
1319
1339
1320
1340
[[multipoint]]
1321
-
//### 10.6. MultiPoint
1341
+
//### 11.6. MultiPoint
1322
1342
==== MultiPoint
1323
1343
1324
1344
- 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:
1403
1423
}
1404
1424
```
1405
1425
[[trajectory]]
1406
-
//### 10.7. Trajectory
1426
+
//### 11.7. Trajectory
1407
1427
==== Trajectory
1408
1428
1409
1429
- 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:
1511
1531
```
1512
1532
1513
1533
[[section]]
1514
-
//### 10.8. Section
1534
+
//### 11.8. Section
1515
1535
==== Section
1516
1536
1517
1537
- A domain with Section domain type MUST have the axes `"composite"` and `"z"`.
@@ -1578,7 +1598,7 @@ Coverage example:
1578
1598
```
1579
1599
1580
1600
[[polygon]]
1581
-
//### 10.9. Polygon
1601
+
//### 11.9. Polygon
1582
1602
==== Polygon
1583
1603
1584
1604
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:
1647
1667
```
1648
1668
1649
1669
[[polygonseries]]
1650
-
//### 10.10. PolygonSeries
1670
+
//### 11.10. PolygonSeries
1651
1671
==== PolygonSeries
1652
1672
1653
1673
- 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:
1714
1734
```
1715
1735
1716
1736
[[multipolygon]]
1717
-
//### 10.11. MultiPolygon
1737
+
//### 11.11. MultiPolygon
1718
1738
==== MultiPolygon
1719
1739
1720
1740
- 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:
1783
1803
```
1784
1804
1785
1805
[[multipolygonseries]]
1786
-
//### 10.12. MultiPolygonSeries
1806
+
//### 11.12. MultiPolygonSeries
1787
1807
==== MultiPolygonSeries
1788
1808
1789
1809
- 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