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 ``version`` property to identifies the version of the CoverageJSON standard that the metadata record conforms to, which is valuable for version-specific detection handling of content.
118
+
119
+
Example:
120
+
121
+
[%unnumbered%]
122
+
```json
123
+
"version": "1.0.1"
124
+
```
125
+
126
+
//## 3. i18n Objects
111
127
=== i18n Objects
112
128
113
129
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 +139,7 @@ Example:
123
139
}
124
140
```
125
141
[[parameter_objects]]
126
-
//## 3. Parameter Objects
142
+
//## 4. Parameter Objects
127
143
=== Parameter Objects
128
144
129
145
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 +224,7 @@ Example for a categorical-data parameter:
208
224
}
209
225
```
210
226
[[parametergroup_objects]]
211
-
//## 4. ParameterGroup Objects
227
+
//## 5. ParameterGroup Objects
212
228
=== ParameterGroup Objects
213
229
214
230
Parameter group objects represent logical groups of parameters, for example vector quantities.
@@ -307,17 +323,17 @@ and `"SST_stddev"`:
307
323
}
308
324
```
309
325
[[reference_system_objects]]
310
-
//## 5. Reference system objects
326
+
//## 6. Reference system objects
311
327
=== Reference system objects
312
328
313
329
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
330
315
331
[[geospatial_coordinate_reference_systems]]
316
-
//### 5.1. Geospatial Coordinate Reference Systems
332
+
//### 6.1. Geospatial Coordinate Reference Systems
317
333
==== Geospatial Coordinate Reference Systems
318
334
Geospatial coordinate reference systems (CRSs) link coordinate values to the Earth.
319
335
320
-
//#### 5.1.1 Geographic Coordinate Reference Systems
336
+
//#### 6.1.1 Geographic Coordinate Reference Systems
321
337
===== Geographic Coordinate Reference Systems
322
338
323
339
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 +366,7 @@ Example of a three-dimensional geographic CRS (latitude-longitude-height):
350
366
}
351
367
```
352
368
353
-
//#### 5.1.2 Projected Coordinate Reference Systems
369
+
//#### 6.1.2 Projected Coordinate Reference Systems
354
370
===== Projected Coordinate Reference Systems
355
371
356
372
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 +387,7 @@ Example of a projected CRS using the http://spatialreference.org/ref/epsg/osgb-1
371
387
}
372
388
```
373
389
374
-
//#### 5.1.3 Vertical Coordinate Reference Systems
390
+
//#### 6.1.3 Vertical Coordinate Reference Systems
375
391
===== Vertical Coordinate Reference Systems
376
392
377
393
Vertical CRSs use a single coordinate to denote some measure of height or depth, usually approximately oriented with gravity.
@@ -391,7 +407,7 @@ Example of a vertical CRS, here representing height above the NAVD88 datum in me
391
407
```
392
408
393
409
[[temporal_reference_systems]]
394
-
//### 5.2. Temporal Reference Systems
410
+
//### 6.2. Temporal Reference Systems
395
411
==== Temporal Reference Systems
396
412
397
413
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 +439,7 @@ Example:
423
439
```
424
440
425
441
[[identifier_based_reference_systems]]
426
-
//### 5.3. Identifier-based Reference Systems
442
+
//### 6.3. Identifier-based Reference Systems
427
443
==== Identifier-based Reference Systems
428
444
429
445
Identifier-based reference systems (identifier RS) .
@@ -463,7 +479,7 @@ Example of a geographic identifier reference system:
463
479
The domain values in the above example would be `"de"` and `"gb"`.
464
480
465
481
[[coveragejson_objects]]
466
-
//## 6. CoverageJSON Objects
482
+
//## 7. CoverageJSON Objects
467
483
=== CoverageJSON Objects
468
484
469
485
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 +488,7 @@ CoverageJSON documents always consist of a single object. This object (referred
472
488
- 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
489
474
490
[[domain_objects]]
475
-
//### 6.1. Domain Objects
491
+
//### 7.1. Domain Objects
476
492
==== Domain Objects
477
493
478
494
A domain object is a CoverageJSON object which defines a set of positions and their extent in one or more referencing systems.
@@ -496,7 +512,7 @@ Its general structure is:
496
512
- 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
513
498
514
[[axis_objects]]
499
-
//#### 6.1.1. Axis Objects
515
+
//#### 7.1.1. Axis Objects
500
516
===== Axis Objects
501
517
502
518
- 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 +578,7 @@ Example of an axis object with Polygon values:
562
578
```
563
579
564
580
[[reference_system_connection_objects]]
565
-
//#### 6.1.2. Reference System Connection Objects
581
+
//#### 7.1.2. Reference System Connection Objects
566
582
===== Reference System Connection Objects
567
583
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
584
@@ -582,7 +598,7 @@ Example of a reference system connection object:
582
598
}
583
599
```
584
600
585
-
//#### 6.1.3. Examples
601
+
//#### 7.1.3. Examples
586
602
===== Examples
587
603
588
604
Example of a domain object with <<grid,Grid>> <<common_domain_types,domain type>>:
@@ -648,7 +664,7 @@ Example of a domain object with <<trajectory,Trajectory>> <<common_domain_types,
648
664
```
649
665
650
666
[[ndarray_objects]]
651
-
//### 6.2. NdArray Objects
667
+
//### 7.2. NdArray Objects
652
668
==== NdArray Objects
653
669
654
670
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 +701,7 @@ The ordering of the data values with respect to their dimensions is equivalent t
685
701
```
686
702
687
703
[[tiledndarray_objects]]
688
-
//### 6.3. TiledNdArray Objects
704
+
//### 7.3. TiledNdArray Objects
689
705
==== TiledNdArray Objects
690
706
691
707
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 +818,7 @@ Example:
802
818
```
803
819
804
820
[[coverage_objects]]
805
-
//### 6.4. Coverage Objects
821
+
//### 7.4. Coverage Objects
806
822
==== Coverage Objects
807
823
808
824
A CoverageJSON object with the type `"Coverage"` is a coverage object.
@@ -821,7 +837,7 @@ Example:
821
837
See the <<annex_vertical_profile_coverage,Vertical Profile Coverage Example>>.
822
838
823
839
[[coverage_collection_objects]]
824
-
//### 6.5. Coverage Collection Objects
840
+
//### 7.5. Coverage Collection Objects
825
841
==== Coverage Collection Objects
826
842
827
843
A CoverageJSON object with the type `"CoverageCollection"` is a coverage collection object.
@@ -838,13 +854,13 @@ Example:
838
854
See the <<annex_coverage_collection,Coverage Collection Example>>.
839
855
840
856
[[extensions]]
841
-
//## 7. Extensions
857
+
//## 8. Extensions
842
858
=== Extensions
843
859
844
860
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
861
846
862
[[custom_members]]
847
-
//### 7.1. Custom members
863
+
//### 8.1. Custom members
848
864
==== Custom members
849
865
850
866
If a custom member is added to a CoverageJSON document, its name SHOULD be a compact URIs of the form `"prefix:suffix"`.
@@ -881,7 +897,7 @@ Example of a different value structure:
881
897
```
882
898
883
899
[[custom_types]]
884
-
//### 7.2. Custom types
900
+
//### 8.2. Custom types
885
901
==== Custom types
886
902
887
903
Custom types MAY be used with the following members:
@@ -927,7 +943,7 @@ Example of a custom reference system type using a compact URI:
927
943
```
928
944
929
945
[[jsonld]]
930
-
//## 8. JSON-LD
946
+
//## 9. JSON-LD
931
947
=== JSON-LD
932
948
933
949
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 +977,14 @@ Example:
961
977
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
978
963
979
[[resolving_domain_and_range_urls]]
964
-
//## 9. Resolving domain and range URLs
980
+
//## 10. Resolving domain and range URLs
965
981
=== Resolving domain and range URLs
966
982
967
983
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
984
969
985
970
986
[[common_domain_types]]
971
-
//## 10. Common Domain Types
987
+
//## 11. Common Domain Types
972
988
=== Common Domain Types
973
989
974
990
This OGC Community Standard defines the following domain types: Grid, VerticalProfile, PointSeries, Point, MultiPointSeries, MultiPoint, PolygonSeries, Polygon, MultiPolygonSeries, MultiPolygon, Trajectory, Section.
@@ -1011,7 +1027,7 @@ Requirements for all domain types defined in this OGC Community Standard:
1011
1027
|=====
1012
1028
1013
1029
[[grid]]
1014
-
//### 10.1. Grid
1030
+
//### 11.1. Grid
1015
1031
==== Grid
1016
1032
1017
1033
- A domain with Grid domain type MUST have the axes `"x"` and `"y"` and MAY have the axes `"z"` and `"t"`.
@@ -1065,7 +1081,7 @@ Coverage example:
1065
1081
}
1066
1082
```
1067
1083
[[vertical_profile]]
1068
-
//### 10.2. VerticalProfile
1084
+
//### 11.2. VerticalProfile
1069
1085
==== VerticalProfile
1070
1086
1071
1087
- 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 +1137,7 @@ Coverage example:
1121
1137
```
1122
1138
1123
1139
[[pointseries]]
1124
-
//### 10.3. PointSeries
1140
+
//### 11.3. PointSeries
1125
1141
==== PointSeries
1126
1142
1127
1143
- 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 +1193,7 @@ Coverage example:
1177
1193
```
1178
1194
1179
1195
[[point]]
1180
-
//### 10.4. Point
1196
+
//### 11.4. Point
1181
1197
==== Point
1182
1198
1183
1199
- 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 +1246,7 @@ Coverage example:
1230
1246
```
1231
1247
1232
1248
[[multipointseries]]
1233
-
//### 10.5. MultiPointSeries
1249
+
//### 11.5. MultiPointSeries
1234
1250
==== MultiPointSeries
1235
1251
1236
1252
- A domain with MultiPointSeries domain type MUST have the axes `"composite"` and `"t"`.
@@ -1318,7 +1334,7 @@ Coverage example:
1318
1334
```
1319
1335
1320
1336
[[multipoint]]
1321
-
//### 10.6. MultiPoint
1337
+
//### 11.6. MultiPoint
1322
1338
==== MultiPoint
1323
1339
1324
1340
- 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 +1419,7 @@ Coverage example:
1403
1419
}
1404
1420
```
1405
1421
[[trajectory]]
1406
-
//### 10.7. Trajectory
1422
+
//### 11.7. Trajectory
1407
1423
==== Trajectory
1408
1424
1409
1425
- 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 +1527,7 @@ Coverage example:
1511
1527
```
1512
1528
1513
1529
[[section]]
1514
-
//### 10.8. Section
1530
+
//### 11.8. Section
1515
1531
==== Section
1516
1532
1517
1533
- A domain with Section domain type MUST have the axes `"composite"` and `"z"`.
@@ -1578,7 +1594,7 @@ Coverage example:
1578
1594
```
1579
1595
1580
1596
[[polygon]]
1581
-
//### 10.9. Polygon
1597
+
//### 11.9. Polygon
1582
1598
==== Polygon
1583
1599
1584
1600
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 +1663,7 @@ Coverage example:
1647
1663
```
1648
1664
1649
1665
[[polygonseries]]
1650
-
//### 10.10. PolygonSeries
1666
+
//### 11.10. PolygonSeries
1651
1667
==== PolygonSeries
1652
1668
1653
1669
- 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 +1730,7 @@ Coverage example:
1714
1730
```
1715
1731
1716
1732
[[multipolygon]]
1717
-
//### 10.11. MultiPolygon
1733
+
//### 11.11. MultiPolygon
1718
1734
==== MultiPolygon
1719
1735
1720
1736
- 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 +1799,7 @@ Coverage example:
1783
1799
```
1784
1800
1785
1801
[[multipolygonseries]]
1786
-
//### 10.12. MultiPolygonSeries
1802
+
//### 11.12. MultiPolygonSeries
1787
1803
==== MultiPolygonSeries
1788
1804
1789
1805
- 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