ISO 19168-2:2022
(Main)Geographic information – Geospatial API for features — Part 2: Coordinate Reference Systems by Reference
Geographic information – Geospatial API for features — Part 2: Coordinate Reference Systems by Reference
This document specifies an extension to the Geospatial API for Features — Part 1: Core standard that defines the behaviour of a server that supports the ability to present geometry valued properties in a response document in one from a list of supported Coordinates Reference Systems (CRS). Each supported CRS is specified by reference using a uniform resource identifier (URI). This document specifies: — how, for each offered feature collection, a server advertises the list of supported CRS identifiers; — how the coordinates of geometry valued feature properties can be accessed in one of the supported CRSs; — how features can be accessed from the server using a bounding box specified in one of the supported CRSs; and — how a server can declare the CRS used to present feature resources.
Information géographique — API géospatiale pour les entités — Partie 2: Systèmes de coordonnées de référence par référence
Le présent document spécifie une extension à la norme «API géospatiale pour les entités — Partie 1: Profil minimal» qui définit le comportement d'un serveur qui est en capacité de présenter des propriétés associées à une valeur géométrique dans un document de réponse dans une liste de Systèmes de coordonnées de référence (CRS) pris en charge. Chaque CRS pris en charge est spécifié par référence à l'aide d'un identifiant de ressource universel (URI). Le présent document spécifie: — comment, pour chaque collection d'entités proposée, un serveur publie la liste des identifiants de CRS pris en charge; — comment les coordonnées des propriétés d'entités associées à une valeur géométrique peuvent être accessibles dans l'un des CRS pris en charge; — comment les entités peuvent être accessibles depuis le serveur à l'aide d'un rectangle englobant spécifié dans l'un des CRS pris en charge; et — comment un serveur peut déclarer le système de CRS utilisé pour présenter des ressources d'entités.
General Information
Relations
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 19168-2
First edition
2022-09
Geographic information – Geospatial
API for features —
Part 2:
Coordinate Reference Systems by
Reference
Information géographique — API géospatiale pour les entités —
Partie 2: Systèmes de coordonnées de référence par référence
Reference number
ISO 19168-2:2022(E)
© ISO 2022
---------------------- Page: 1 ----------------------
ISO 19168-2:2022(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2022
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
© ISO 2022 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 19168-2:2022(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Conformance . 2
5 Conventions and background.2
6 Requirements Class Coordinate Reference Systems by Reference . 3
6.1 Overview . 3
6.2 Discovery . 3
6.2.1 CRS identifier list . 3
6.2.2 Storage CRS . 4
6.2.3 Global list of CRS identifiers . 5
6.3 Query . 8
6.3.1 Parameter bbox-crs . 8
6.3.2 Parameter crs . 9
6.3.3 Output format considerations . 10
6.3.4 Coordinate reference system information independent of the feature
encoding . 11
Annex A (normative) Abstract Test Suite .12
Bibliography .16
iii
© ISO 2022 – All rights reserved
---------------------- Page: 3 ----------------------
ISO 19168-2:2022(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by the Open Geospatial Consortium (as OGC API — Features — Part 2:
Coordinate Reference Systems by Reference) and drafted in accordance with its editorial rules. It was
assigned to Technical Committee ISO/TC 211, Geographic information/Geomatics, and adopted under
the “fast-track procedure”.
The main changes are as follows:
— addition of an Introduction;
— alignment of spellings with ISO spelling rules;
— renumbering and reordering of Clauses 2-4 in order to accommodate the fixed structure of ISO
documents;
— set texts introduced in Clauses 2 and 3;
A list of all parts in the ISO 19168 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
iv
© ISO 2022 – All rights reserved
---------------------- Page: 4 ----------------------
ISO 19168-2:2022(E)
Introduction
OGC API standards define modular API building blocks to spatially enable Web APIs in a consistent way.
The OpenAPI specification is used to define the API building blocks.
The OGC API family of standards is organized by resource type. This document extends the fundamental
API building blocks for interacting with features. The spatial data community uses the term 'feature'
for things in the real world that are of interest.
For those not familiar with the term 'feature,' the explanations on Spatial Things, Features and
[6]
Geometry in the W3C/OGC Spatial Data on the Web Best Practice document provide more detail.
OGC API Features provides API building blocks to create, modify and query features on the Web. OGC
API Features is comprised of multiple parts, each of them is a separate standard. This document extends
the core capabilities specified in OGC API — Features — Part 1: Core (ISO 19168-1) with the ability to
use coordinate reference system identifiers other than the defaults defined in the core.
By default, every API implementing this document will provide access to a single dataset. Rather than
sharing the data as a complete dataset, the OGC API Features standards offer direct, fine-grained access
to the data at the feature (object) level.
The API building blocks specified in this document are consistent with the architecture of the Web.
In particular, the API design is guided by the IETF HTTP/HTTPS RFCs, the W3C Data on the Web
Best Practices, the W3C/OGC Spatial Data on the Web Best Practices and the emerging OGC Web API
Guidelines. A particular example is the use of the concepts of datasets and dataset distributions as
defined in DCAT and used in schema.org.
A subset of the OGC API family of standards is expected to be published by ISO. For example, this
document is published by ISO as ISO 19168-2. To reflect that only a subset of the OGC API standards
will be published by ISO and to avoid using organization names in the titles of ISO standards, standards
from the "OGC API" series are published by ISO as "Geospatial API," i.e. the title of this document in OGC
is "OGC API — Features — Part 2: Coordinate Reference Systems by Reference" and the title in ISO is
"Geographic Information — Geospatial API for Features — Part 2: Coordinate Reference Systems by
Reference."
For simplicity, this document consistently uses:
— "OGC API" to refer to the family of standards for geospatial Web APIs that in ISO is published as
"Geospatial API;"
— "OGC API — Features" to refer to the multipart standard for features that in ISO is published as
ISO 19168 / "Geographic Information - Geospatial API for Features;"
— "OGC API — Features — Part 1: Core" to refer to the document that in ISO is published as ISO 19168-1
/ "Geographic Information - Geospatial API for Features - Part 1: Core."
v
© ISO 2022 – All rights reserved
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 19168-2:2022(E)
Geographic information – Geospatial API for features —
Part 2:
Coordinate Reference Systems by Reference
1 Scope
This document specifies an extension to the Geospatial API for Features — Part 1: Core standard that
defines the behaviour of a server that supports the ability to present geometry valued properties in a
response document in one from a list of supported Coordinates Reference Systems (CRS).
Each supported CRS is specified by reference using a uniform resource identifier (URI).
This document specifies:
— how, for each offered feature collection, a server advertises the list of supported CRS identifiers;
— how the coordinates of geometry valued feature properties can be accessed in one of the supported
CRSs;
— how features can be accessed from the server using a bounding box specified in one of the supported
CRSs; and
— how a server can declare the CRS used to present feature resources.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 19168-1:2020, Geographic information — Geospatial API for features — Part 1: Core
3 Terms and definitions
For the purposes of this document, the terms and definition given in ISO19168-1 and the following
apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
NOTE The terms feature (3.4) and feature collection (3.5) and the acronym CRS (3.2) are duplicated here
from ISO 19168-1.
3.1
coordinate
one of a sequence of numbers designating the position of a point
Note 1 to entry: In a spatial coordinate reference system, the coordinate numbers are qualified by units.
[SOURCE: ISO 19111:2019, 3.1.5]
1
© ISO 2022 – All rights reserved
---------------------- Page: 6 ----------------------
ISO 19168-2:2022(E)
3.2
coordinate reference system
CRS
coordinate system (3.3) that is related to an object by a datum
Note 1 to entry: Geodetic and vertical datums are referred to as reference frames.
Note 2 to entry: For geodetic and vertical reference frames, the object will be the Earth. In planetary application,
geodetic and vertical reference frames may be applied to other celestial bodies.
[SOURCE: ISO 19111:2019, 3.1.9]
3.3
coordinate system
set of mathematical rules for specifying how coordinates (3.1) are to be assigned to points
[SOURCE: ISO 19111:2019, 3.1.11]
3.4
feature
abstraction of real world phenomena
Note 1 to entry: The explanations on Spatial Things, Features and Geometry in the W3C/OGC Spatial Data on the
[6]
Web Best Practice document provide more detail.
[SOURCE: ISO 19101-1:2014, 4.1.11, modified – Note 1 to entry has been added.]
3.5
feature collection
collection
set of features (3.4) from a dataset (ISO 19168-1, 3.1.1)
3.6
spatial feature collection
spatial collection
feature collection (3.5) that includes one or more features (3.4) that have properties whose value is a
geometry
[SOURCE: ISO 19168-1:2020, 3.1.4]
4 Conformance
This document defines one requirements class, Coordinate Reference Systems by Reference. The
standardization target is "Web APIs".
The URI of the associated conformance class is http:// www .opengis .net/ spec/ ogcapi -features -2/ 1 .0/
conf/ crs.
Conformance with this standard shall be checked using all the relevant tests specified in Annex A of
this document. The framework, concepts, and methodology for testing, and the criteria to be achieved
to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC
Compliance Testing web site.
5 Conventions and background
See ISO 19168-1:2020, Clauses 5 and 6.
2
© ISO 2022 – All rights reserved
---------------------- Page: 7 ----------------------
ISO 19168-2:2022(E)
6 Requirements Class Coordinate Reference Systems by Reference
6.1 Overview
Requirements Class
http:// www .opengis .net/ spec/ ogcapi -features -2/ 1 .0/ req/ crs
Target type Web API
Dependency OGC API - Features - Part 1: Core, Requirements Class 'core'
The OGC API — Features — Part 1: Core standard defines support for only two coordinate reference
systems:
— WGS 84 longitude, latitude;
— WGS 84 longitude, latitude, ellipsoidal height.
This extension defines the behaviour of a server that supports additional coordinate reference systems.
Requirement 1 /req/crs/crs-uri
Each CRS supported by a server shall be referenceable by a uniform resource identifier (i.e. a URI).
Recommendation 1 /rec/crs/crs-format-model
Servers that implement this extension should be able to recognize and generate CRS identifiers with the following
format model:
http://www.opengis.net/def/crs/authority/version/code
In this format model, the token {authority} is a placeholder for a value that designates to authority responsible
for the definition of this CRS. Typical values include "EPSG" and "OGC".
The token {version} is a placeholder for the specific version of the CRS definition or 0 for un-versioned CRS
definitions.
The token {code} is a placeholder for the authority’s code for the CRS.
For more information, see 6.2 in OGC Name Type Specification, Part 1.
Note that while the EPSG register itself is versioned, the registered items are not versioned and the
"version" is always "0" in URIs of the authority "EPSG".
6.2 Discovery
6.2.1 CRS identifier list
Requirement 2 /req/crs/fc-md-crs-list
A The crs property in the collection object of a spatial feature collection shall contain the
identifiers for the list of CRSs supported by the server for that collection.
B This list shall include the default(s) defined in OGC API - Features - Part 1: Core.
The list has to include the default CRS — that is the CRS used unless something else is explicitly
requested — is defined in ISO 19168-1, Geographic information — Geospatial API for features — Part 1:
Core as:
— http:// www .opengis .net/ def/ crs/ OGC/ 1 .3/ CRS84 (for coordinates without height);
— http:// www .opengis .net/ def/ crs/ OGC/ 0/ CRS84h (for coordinates with ellipsoidal height).
3
© ISO 2022 – All rights reserved
---------------------- Page: 8 ----------------------
ISO 19168-2:2022(E)
6.2.2 Storage CRS
The storage CRS for a spatial feature collection is the CRS identifier that may be used to retrieve
features from that collection without the need to apply a CRS transformation.
Note that coordinates referenced to a dynamic coordinate reference system are ambiguous if the
coordinate epoch is unknown. It is therefore recommended to also provide the coordinate epoch when
the storage CRS is dynamic, such as an ITRF realization or WGS 84. For more information on dynamic
coordinate reference systems and coordinate epoch, please see ISO 19111, Geographic information —
Referencing by coordinates (same as OGC Abstract Specification Topic 2: Referencing by coordinates).
Requirement 3 /req/crs/fc-md-storageCrs
If all features in a spatial feature collection are stored using a particular CRS then the proper-
ty storageCrs shall be specified in the collection object of the spatial feature collection to indicate the identifi-
er for this storage CRS.
Recommendation 2 /rec/crs/fc-md-coordinateEpoch
If the storage CRS of the spatial feature collection is a dynamic coordinate reference system, the proper-
ty storageCrsCoordinateEpoch in the collection object of the spatial feature collection should provide the
coordinate epoch of the coordinates.
This document does not provide a mechanism to associate different coordinate epochs with feature
geometries in a collection. If data with different coordinate epochs is merged in a collection, one option
is to perform point motion operations (PMO) to convert all geometries to the same coordinate epoch.
See ISO 19111, Geographic information — Referencing by coordinates (same as OGC Abstract Specification
Topic 2: Referencing by coordinates), for more information.
Requirement 4 /req/crs/fc-md-storageCrs-valid-value
The value of the storageCrs property shall be one of the CRS identifiers from the list of supported CRS identi-
fiers found in the collection object using the crs property.
The following schema fragment extends the collection object to add the storageCrs and
storageCrsCoordinateEpoch properties.
type: object
required:
- id
- links
properties:
id:
description: identifier of the collection used, for example, in URIs
type: string
example: address
title:
description: human readable title of the collection
type: string
example: address
description:
description: a description of the features in the collection
type: string
example: An address.
links:
type: array
items:
$ref: link.yaml
example:
- href: http://data.example.com/buildings
rel: item
- href: http://example.com/concepts/buildings.html
rel: describedby
type: text/html
extent:
4
© ISO 2022 – All rights reserved
---------------------- Page: 9 ----------------------
ISO 19168-2:2022(E)
$ref: extent.yaml
itemType:
description: indicator about the type of the items in the collection (the default
value is 'feature').
type: string
default: feature
crs:
description: the list of CRS identifiers supported by the service
type: array
items:
type: string
default:
- http://www.opengis.net/def/crs/OGC/1.3/CRS84
example:
- http://www.opengis.net/def/crs/OGC/1.3/CRS84
- http://www.opengis.net/def/crs/EPSG/0/4326
storageCrs:
description: the CRS identifier, from the list of supported CRS identifiers, that
may be used to retrieve features from a collection without the need to apply a CRS
transformation
type: string
format: uri
storageCrsCoordinateEpoch:
description: point in time at which coordinates in the spatial feature
collection are referenced to the dynamic coordinate reference system in
`storageCrs`, that may be used to retrieve features from a collection without
the need to apply a change of coordinate epoch. It is expressed as a decimal
year in the Gregorian calendar
type: number
example: '2017-03-25 in the Gregorian calendar is epoch 2017.23'
6.2.3 Global list of CRS identifiers
To prevent unnecessary duplication of lists of supported CRS identifiers in the collection object, a global
list of supported CRS identifiers may be provided as part of the collections object.
This global list of CRS identifiers is not automatically inherited by each collection offered by the service.
Rather the global list of CRS identifiers must be explicitly referenced in the crs property of the collection
object using a JSON Pointer (RFC 6901).
Requirement 5 /req/crs/fc-md-crs-list-global
If the crs property in the collection object of a spatial feature collection includes a JSON Pointer to the global
list of CRS identifiers (#/crs), then all CRS identifiers in the global list shall be valid for the referencing collec-
tion.
Note that only a local JSON Pointer within the same document is supported.
The following schema fragment extends the collections object to add the crs property which contains
the global list of CRS identifiers.
allOf:
- $ref:
'http://schemas.opengis.net/ogcapi/features/part1/1.0/openapi/schemas/collections.yaml'
- type: object
properties:
crs:
description: a global list of CRS identifiers that are supported by spatial feature
collections offered by the service
type: array
items:
type: string
format: uri
The following example illustrates the use of a global list of CRS identifiers.
EXAMPLE Collections object containing a global list of CRS identifiers.
5
© ISO 2022 – All rights reserved
---------------------- Page: 10 ----------------------
ISO 19168-2:2022(E)
{
"links": [
{ "href": "http://data.example.org/collections.json",
"rel": "self", "type": "application/json", "title": "this document" },
{ "href": "http://data.example.org/collections.html",
"rel": "alternate", "type": "text/html", "title": "this document as
HTML" },
{ "href": "http://schemas.example.org/1.0/buildings.xsd",
"rel": "describedby", "type": "application/xml", "title": "GML
application schema for Acme Corporation building data" },
{ "href": "http://download.example.org/buildings.gpkg",
"rel": "enclosure", "type": "application/geopackage+sqlite3", "title":
"Bulk download (GeoPackage)", "length": 472546 }
],
"crs": [
"http://www.opengis.net/def/crs/OGC/1.3/CRS84",
"http://www.opengis.net/def/crs/EPSG/0/4326",
"http://www.opengis.net/def/crs/EPSG/0/3857",
"http://www.opengis.net/def/crs/EPSG/0/3395"
],
"collections": [
{
"id": "bonn_buildings",
"title": "Bonn Buildings",
"description": "Buildings in the city of Bonn.",
"extent": {
"spatial": {
"bbox": [ [ 7.01, 50.63, 7.22, 50.78 ] ]
},
"temporal": {
"interval": [ [ "2010-02-15T12:34:56Z", null ] ]
}
},
"links": [
{ "href":
"http://data.example.org/collections/bonn_buildings/items",
"rel": "items", "type": "application/geo+json",
"title": "Bonn Buildings" },
{ "href": "https://creativecommons.org/publicdomain/zero/1.0/",
"rel": "license", "type": "text/html",
"title": "CC0-1.0" },
{ "href":
"https://creativecommons.org/publicdomain/zero/1.0/rdf",
"rel": "license", "type": "application/rdf+xml",
"title": "CC0-1.0" }
],
"crs": [
"#/crs",
"http://www.opengis.net/def/crs/EPSG/0/4258",
"http://www.opengis.net/def/crs/EPSG/0/25831",
"http://www.opengis.net/def/crs/EPSG/0/25832"
]
},
{
"id": "tor_buildings",
"title": "Toronto Buildings",
"description": "Buildings in the city of Toronto.",
"extent": {
"spatial": {
"bbox": [ [ -79.62, 43.58, -79.12, 43.87 ] ]
},
"temporal": {
"interval": [ [ "2010-02-15T12:34:56Z", null ] ]
}
},
"links": [
{ "href":
"http://data.example.org/collections/tor_buildings/items",
"rel": "items", "type": "application/geo+json",
"title": "Toronto Buildings" },
{ "href": "https://creativecommons.org/publicdomain/zero/1.0/",
6
© ISO 2022 – All rights reserved
---------------------- Page: 11 ----------------------
ISO 19168-2:2022(E)
"rel": "license", "type": "text/html",
"title": "CC0-1.0" },
{ "href":
"https://creativecommons.org/publicdomain/zero/1.0/rdf",
"rel": "license", "type": "application/rdf+xml",
"title": "CC0-1.0" }
],
"crs": [
"#/crs"
]
},
{
"id": "dc_buildings",
"title": "Washington DC Buildings",
"description": "Buildings in the city of Washington DC.",
"extent": {
"spatial": {
"bbox": [ [ -77.12, 38.80, -76.89, 39.01 ] ]
},
"temporal": {
"interval": [ [ "2010-02-15T12:34:56Z", null ] ]
}
},
"links": [
{ "href":
"http://data.example.org/collections/dc_buildings/items",
"rel": "items", "type": "application/geo+json",
"title": "DC Buildings" },
{ "href": "https://creativecommons.org/publicdomain/zero/1.0/",
"rel": "license", "type": "text/html",
"title": "CC0-1.0" },
{ "href":
"https://creativecommons.org/publicdomain/zero/1.0/rdf",
"rel": "license", "type": "application/rdf+xml",
"title": "CC0-1.0" }
],
"crs": [
"http://www.opengis.net/def/crs/OGC/1.3/CRS84"
]
}
]
}
In the above example, the bonn_buildings collection is offered in all the CRSs specified in the global list
plus three other CRSs.
The tor_buildings collection is offered in the CRSs specified in the global list.
The dc_buildings collection is only offered in the default CRS (i.e. WGS 84 longitude, latitude).
7
© ISO 2022 – All rights reserved
---------------------- Page: 12 ----------------------
ISO 19168-2:2022(E)
6.3 Query
6.3.1 Parameter bbox-crs
The bbox-crs parameter may be used to assert the CRS used for the coordinate values of
the bbox parameter.
Requirement 6 /req/crs/fc-bbox-crs-definition
Each GET request on a 'features' resource shall support a query parameter bbox-crs with the following char-
acteristics:
name: bbox-crs
in: query
required: false
schema:
type: string
format: uri
style: form
explode: false
Requirement 7 /req/crs/fc-bbox-crs-valid-value
A If the value of the bbox-crs parameter is not one of the CRS identifiers from the list of
supported CRS identifiers, then the server shall respond with the HTTP status code 400.
B The list of supported CRS identifiers is found in the collection object using the crs prop-
erty.
As usual, it is good practice to include a message about the reason for the error in the response.
Requirement 8 /req/crs/fc-bbox-crs-valid-default-value
If the bbox-crs parameter is not specified then the coordinate values of the bbox parameter shall be assumed
to be in the default CRS specified in OGC API - Feature - Part 1: Core; that
is http:// www .opengis .net/ def/ crs/ OGC/ 1 .3/ CRS84 for coordinates without height
and http:// www .opengis .net/ def/ crs/ OGC/ 0/ CRS84h for coordinates with ellipsoidal height.
Requirement 9 /req/crs/fc-bbox-crs-action
If the bbox-crs parameter is specified, then the values of the bbox parameter shall be assumed to be in the
specified CRS and the server shall perform the necessary internal transformations to properly fetch data from
within the specified bounding box.
The following fragment illustrates the use of the bbox-crs parameter (reserved characters have to be
encoded):
EXAMPLE Specifying a bounding box in one of the supported coordinate reference systems.
...&bbox=32507317%2C5224265%2C33427450%2C5603836&bbox-crs=http%3A%2F%2Fwww.opengis.net%2Fd
ef%2Fcrs%2FEPSG%2F0%2F25832
8
© ISO 2022 – All rights reserved
---------------------- Page: 13 ----------------------
ISO 19168-2:2022(E)
6.3.2 Parameter crs
Requirement 10 /req/crs/fc-crs-definition
Each GET request on a 'features' or 'feature' res
...
ISO/TC 211
Date: 2022-0911
ISO 19168--2:2022(F)
ISO/TC 211
Secrétariat : SIS
Information géographique — API géospatiale pour les entités — Partie 2 : Systèmes de coordonnées
de référence par référence
Geographic information — Geospatial API for features — Part 2: Coordinate Reference Systems by Reference
---------------------- Page: 1 ----------------------
ISO 19168--2:2022(F)
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2022, Publié en Suisse
Droits de reproduction réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise
en œuvre, aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque forme que
ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie, l'affichage sur
l'Internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d'autorisation peuvent
être adressées à l'ISO à l'adresse ci-après ou au comité membre de l'ISO dans le pays du demandeur.
ISO copyright office
Ch. de Blandonnet 8 •• CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
copyright@iso.org
www.iso.org
www.iso.org
ii © ISO 2022 – Tous droits réservés
---------------------- Page: 2 ----------------------
ISO 19168--2:2022(F)
Sommaire Page
Avant-propos . iv
Introduction . v
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Conformité . 2
5 Conventions et contexte . 3
6 Classe d'exigences Systèmes de coordonnées de référence par référence. 3
6.1 Vue d'ensemble . 3
6.2 Découverte . 4
6.2.1 Liste des identifiants de CRS . 4
6.2.2 CRS de stockage . 4
6.2.3 Liste globale des identifiants de CRS . 6
6.3 Requête . 9
6.3.1 Paramètre bbox-crs . 9
6.3.2 Paramètre crs . 10
6.3.3 Considérations relatives au format de sortie . 11
6.3.4 Informations de systèmes de coordonnées de référence indépendants de l'encodage des
entités . 13
Annexe A (normative) Suite de tests abstraits . 14
Bibliographie . 18
Avant-propos . v
Introduction . vi
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Conformité . 2
5 Conventions et contexte . 3
6 Classe d'exigences Systèmes de coordonnées de référence par référence. 3
6.1 Vue d'ensemble . 3
6.2 Découverte . 4
6.2.1 Liste des identifiants de CRS . 4
6.2.2 CRS de stockage . 4
6.2.3 Liste globale des identifiants de CRS . 6
6.3 Requête . 9
© ISO 2022 – Tous droits réservés iii
---------------------- Page: 3 ----------------------
ISO 19168--2:2022(F)
6.3.1 Paramètre bbox-crs . 9
6.3.2 Paramètre crs . 10
6.3.3 Considérations relatives au format de sortie . 11
6.3.4 Informations de systèmes de coordonnées de référence indépendants de l'encodage des
entités . 12
Annexe A (normative) Suite de tests abstraits . 14
Bibliographie . 18
iv © ISO 2022 – Tous droits réservés
---------------------- Page: 4 ----------------------
ISO 19168--2:2022(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée
aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire partie du
comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l'ISO, participent également aux travaux. L'ISO collabore étroitement avec
la Commission électrotechnique internationale (IEC) en ce qui concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont décrites
dans les Directives ISO/IEC, Partie 1. Il convient en particulier de prendre note des différents critères
d'approbation requis pour les différents types de documents ISO (voir www.iso.org/directives).
L'attention est attirée sur le fait que certains des éléments du présent document peuvent faire l'objet de droits
de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable de ne pas
avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant les références aux
droits de propriété intellectuelle ou autres droits analogues identifiés lors de l'élaboration du document sont
indiqués dans l'Introduction et/ou dans la liste des déclarations de brevets reçues par l'ISO
(voir www.iso.org/brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données pour
information, par souci de commodité, à l'intention des utilisateurs et ne sauraient constituer un engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions spécifiques
de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion de l'ISO aux
principes de l'Organisation mondiale du commerce (OMC) concernant les obstacles techniques au commerce
(OTC), voir le lien suivant : www.iso.org/iso/fr/avant-propos.html.
Le présent document a été élaboré par l'Open Geospatial Consortium (sous le titre OGC API — Features —
Part 2: Coordinate Reference Systems by Reference) et rédigé conformément aux règles de rédaction. Il a été
assigné au comité technique ISO/TC 211, Information géographique/Géomatique, et adopté dans le cadre de la
« procédure rapide ».
Les principales modifications sont les suivantes :
— ajout d'une introduction ;
— harmonisation de l'orthographe selon les règles d'orthographes ISO ;
— renumérotation et réorganisation des Articles 2-4 afin de correspondre à la structure fixe des
documents ISO ;
— introduction de textes types aux Articles 2 et 3 ;
Une liste de toutes les parties de la série ISO 19168 se trouve sur le site Webweb de l'ISO.
Il convient que l'utilisateur adresse tout retour d'information ou toute question concernant le présent
document à l'organisme national de normalisation de son pays. Une liste exhaustive desdits organismes se
trouve à l'adresse www.iso.org/fr/members.html.
© ISO 2022 – Tous droits réservés v
---------------------- Page: 5 ----------------------
ISO 19168--2:2022(F)
Introduction
Les standards OGC API définissent les modules de construction de l'API pour activer spatialement les API Web
de façon cohérente. La spécification OpenAPI permet de définir les modules de construction de l'API.
La famille de spécifications OGC API est organisée par type de ressource. Le présent document développe les
modules de construction fondamentaux de l'API en vue de l'interaction avec les entités. La communauté des
données spatiales utilise le terme « entité » pour désigner des objets du monde réel qui présentent un intérêt.
Pour ceux qui ne connaîtraient pas le terme « entité », les explications concernant Spatial Things, Features
[6]
and Geometry dans le document Web Best Practice du W3C/OGC Spatial Data donnent de plus amples
informations.
OGC API Features fournit des modules de construction d'API pour créer, modifier et interroger les entités sur
le Web. OGC API Features est composé de plusieurs parties, dont chacune constitue un standard distinct. Le
présent document développe les capacités essentielles spécifiées dans l'OGC API — Features —
Part 1 : Core (ISO 19168--1) avec la possibilité d'utiliser des identifiants de système de coordonnées de
référence autres que les identifiants par défaut définis dans le profil minimal.
Par défaut, chaque API mettant en œuvre le présent document donnera accès à un seul jeu de données. Plutôt
qu'un partage de données sous forme de jeu de données complet, les spécifications OGC API Features offrent
un accès direct et précis aux données au niveau entité (objet).
Les blocs de construction de l'API spécifiés dans le présent document sont en harmonie avec l'architecture du
Web. En particulier, la conception de l'API est gouvernée par les RFC IETF HTTP/HTTPS, par les bonnes
pratiques W3C pour publier des données sur le Web (W3C Data on the Web Best Practices), par les bonnes
pratiques W3C pour publier des données spatiales OGC sur le Web (W3C/OGC Spatial Data on the Web Best
Practices) et par les lignes directrices émergentes OGC Web API Guidelines. Un exemple en particulier est
l'utilisation des concepts de jeux de données et de distribution des jeux de données tels que définis dans DCAT
et utilisés dans schema.org.
La publication d'un sous-ensemble de la famille de standards OGC API par l'ISO est prévue. Par exemple, le
présent document est publié par l'ISO sous la référence ISO 19168--2. Pour indiquer que seul un sous-
ensemble des standards OGC API sera publié par l'ISO, et pour éviter d'utiliser des noms d'organismes dans
les titres des normes ISO, les normes de la série « OGC API » sont publiées par l'ISO sous forme de « API
géospatiale », c'est-à-dire que le titre du présent document dans l'OGC est « OGC API — Features —
Part 2: Coordinate Reference Systems by Reference » et le titre dans l'ISO est « Information géographique —
API géospatiale pour les entités — Partie 2 : Systèmes de coordonnées de référence par référence ».
Pour des raisons de simplicité, le présent document utilise systématiquement :
— « OGC API » pour désigner la famille de normes pour les API Web géospatiales qui est publiée dans l'ISO
comme « API géospatiale » ;»;
— « OGC API — Features » pour désigner la norme en plusieurs parties pour les entités qui est publiée dans
l'ISO comme ISO 19168 / « Information géographique — API géospatiale pour les entités » ;»;
— « OGC API — Features — Part 1: Core » (profil minimal) pour faire référence au document qui est publié
dans l'ISO comme ISO 19168-1 / « Information géographique — API géospatiale pour les entités —
Partie 1 : Profil minimal ».
vi © ISO 2022 – Tous droits réservés
---------------------- Page: 6 ----------------------
NORME INTERNATIONALE ISO 19168-2:2022(F)
Information géographique — API géospatiale pour les entités —
Partie 2 : Systèmes de coordonnées de référence par référence
1 Domaine d'application
Le présent document spécifie une extension à la norme « API géospatiale pour les entités — Partie 1 : Profil
minimal » qui définit le comportement d'un serveur qui est en capacité de présenter des propriétés associées
à une valeur géométrique dans un document de réponse dans une liste de Systèmes de coordonnées de
référence (CRS) pris en charge.
Chaque CRS pris en charge est spécifié par référence à l'aide d'un identifiant de ressource universel (URI).
Le présent document spécifie :
— comment, pour chaque collection d'entités proposée, un serveur publie la liste des identifiants de CRS
pris en charge ;
— comment les coordonnées des propriétés d'entités associées à une valeur géométrique peuvent être
accessibles dans l'un des CRS pris en charge ;
— comment les entités peuvent être accessibles depuis le serveur à l'aide d'un rectangle englobant spécifié
dans l'un des CRS pris en charge ; et
— comment un serveur peut déclarer le système de CRS utilisé pour présenter des ressources d'entités.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu'ilsqu’ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l'éditionl’édition citée
s'appliques’applique. Pour les références non datées, la dernière édition du document de référence s'applique
(y compris les éventuels amendements).
ISO 19168-1:2020, Information géographique — API géospatiale pour les entités — Partie 1 : : Profil minimal
3 Termes et définitions
Pour les besoins du présent document, les termes et les définitions donnés dansde l'ISO 19168-1 ainsi que les
suivants s'appliquents’appliquent.
L'ISOL’ISO et l'IECl’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes ::
— ISO Online browsing platform : disponible à l'adressel’adresse
https://www.iso.org/obp/ui/fr/https://www.iso.org/obp
— IEC Electropedia : disponible à l'adressel’adresse https://www.electropedia.org/
NOTE Les termes entités (3.4) et collection d'entités (3.5) et l'acronyme CRS (3.2) sont dupliqués de l'ISO 19168-1.
© ISO 2022 – Tous droits réservés 1
---------------------- Page: 7 ----------------------
ISO 19168-2:2022(F)
3.1
coordonnée
l'une des séquences de nombres désignant la position d'un point
Note 1 à l'article : : Dans un système de coordonnées de référence spatial, les coordonnées sont établies par
unités.
[SOURCE : ISO 19111:2019, 3.1.5]
3.2
système de référence de coordonnées
CRS
système de coordonnées (3.3) associé à un objet par une référence
Note 1 à l'article : Les référentiels géodésiques et verticaux sont appelés « repères de référence ».
Note 2 à l'article : Pour les repères de référence géodésiques et verticaux, l'objet est la Terre. Dans les applications
planétaires, les repères de référence géodésiques et verticaux peuvent être appliqués à d'autres corps célestes.
[SOURCE : ISO 19111:2019, 3.1.9]
3.3
système de coordonnées
ensemble de règles mathématiques déterminant la façon dont les coordonnées (3.1) sont affectées à des points
[SOURCE : ISO 19111:2019, 3.1.11]
3.4
entité
abstraction d'un phénomène du monde réel
Note 1 à l'article : Les explications concernant Spatial Things, Features and Geometry des W3C/OGC Spatial Data dans le
[6]
document Web Best Practice donnent de plus amples informations.
[SOURCE : ISO 19101--1:2014, 4.1.11, modifiée – La Note 1 à l'article a été ajoutée.]
3.5
collection d'entités
collection
ensemble d'entités (3.4) provenant d'un jeu de données (ISO 19168--1, 3.1.1)
3.6
collection d'entités spatiales
collection spatiale
collection d'entités (3.5) qui comprend une ou plusieurs entités (3.4) qui ont des propriétés associées à une
valeur géométrique
[SOURCE : ISO 19168--1:2020, 3.1.4]
4 Conformité
Le présent document définit une classe d'exigences, Systèmes de coordonnées de référence par référence. La
cible de normalisation est « API Web ».
2 © ISO 2022 – Tous droits réservés
---------------------- Page: 8 ----------------------
ISO 19168-2:2022(F)
L'URI de la classe de conformité associée est http://www.opengis.net/spec/ogcapi-features-2/1.0/conf/crs.
La conformité avec la présente norme doit être vérifiée à l'aide de tous les essais concernés spécifiés
à l'Annexe A du présent document. La structure, les concepts et la méthodologie d'essai, ainsi que les critères
à remplir pour revendiquer la conformité sont spécifiés dans les OGC Compliance Testing Policies and
Procedures et sur le site Web OGC Compliance Testing.
5 Conventions et contexte
Voir l'ISO 19168--1:2020, Articles 5 et 6.
6 Classe d'exigences Systèmes de coordonnées de référence par référence
6.1 Vue d'ensemble
Classe d'exigences
http://www.opengis.net/spec/ogcapi-features-2/1.0/req/crs
Type de cible API Web
Dépendance
OGC API - Features - Part 1: Core, Classe d'exigences « Profil minimal »
La norme OGC API - Features - Part 1: Core ne définit le support que pour deux systèmes de coordonnées de
référence :
— WGS 84 longitude, latitude ;
— WGS 84 longitude, latitude, altitude ellipsoïdale.
Cette extension définit le comportement d'un serveur qui prend en charge des systèmes de coordonnées de
référence supplémentaires.
Exigence 1 /req/crs/crs-uri
Chaque CRS pris en charge par un serveur doit être référençable par un identifiant de ressource universel (c'est-à-
dire un URI).
Recommandation 1 /rec/crs/crs-format-model
Il convient que les serveurs qui implémentent cette extension soient capables de reconnaître et de générer des
identifiants de CRS avec le modèle de format suivant :
http://www.opengis.net/def/crs/authority/version/code
Dans ce modèle de format, le jeton {authority} est un paramètre fictif pour une valeur qui désigne l'autorité
responsable de la définition de ce CRS. Les valeurs typiques comprennent « EPSG » et « OGC ».
Le jeton {version} est un paramètre fictif pour la version spécifique de la définition du CRS ou 0 pour les
définitions du CRS non versionnées.
Le jeton {code} est un paramètre fictif pour le code pour le CRS de l'autorité.
Pour de plus amples informations, voir le paragraphe 6.2 de l'OGC Name Type Specification, Partie 1.
© ISO 2022 – Tous droits réservés 3
---------------------- Page: 9 ----------------------
ISO 19168-2:2022(F)
Il est à noter que bien que le registre EPSG lui-même soit versionné, les éléments enregistrés ne sont pas
versionnés et la « version » est toujours « 0 » dans les URI de l'autorité « EPSG ».
6.2 Découverte
6.2.1 Liste des identifiants de CRS
Exigence 2 /req/crs/fc-md-crs-list
A La propriété crs dans l'objet collection d'une collection d'entités spatiales doit contenir les
identifiants de la liste de CRS pris en charge par le serveur pour cette collection.
B Cette liste doit inclure le(s) CRS par défaut défini(s) dans l'OGC API - OGC API - Features - Part 1:
Core.
La liste doit inclure le CRS par défaut — c'est-à-dire le CRS utilisé à moins que quelque chose d'autre ne soit
explicitement demandé — défini dans la norme ISO 19168--1, Information géographique — API géospatiale
pour les entités — Partie 1 : Profil minimal en tant que :
— http://www.opengis.net/def/crs/OGC/1.3/CRS84 (pour les coordonnées sans altitude) ;);
— http://www.opengis.net/def/crs/OGC/0/CRS84h (pour les coordonnées avec altitude ellipsoïdale).
6.2.2 CRS de stockage
Le CRS de stockage pour une collection d'entités spatiales est l'identifiant de CRS qui peut être utilisé pour
récupérer des entités de cette collection sans avoir à appliquer une transformation de CRS.
Il est à noter que les coordonnées qui se réfèrent à un système de coordonnées de référence dynamique sont
ambiguës si l'époque des coordonnées est inconnue. Il est donc recommandé de fournir également l'époque
des coordonnées lorsque le CRS de stockage est dynamique, par exemple une réalisation de l'ITRF ou le
WGS 84. Pour de plus amples informations sur les systèmes de coordonnées de référence dynamiques et
l'époque des coordonnées, consulter l'ISO 19111 Information géographique — Système de références par
coordonnées (identique à la spécification abstraite de l'OGC Sujet 2 : Système de références par coordonnées).
Exigence 3 /req/crs/fc-md-storageCrs
Si toutes les entités d'une collection d'entités spatiales sont stockées à l'aide d'un CRS particulier, alors la
propriété storageCrs doit être spécifiée dans l'objet collection de la collection d'entités spatiales pour indiquer
l'identifiant de ce CRS de stockage.
Recommandation 2 /rec/crs/fc-md-coordinateEpoch
Si le CRS de stockage de la collection d'entités spatiales est un système de coordonnées de référence dynamique, il
convient que la propriété storageCrsCoordinateEpoch dans l'objet collection de la collection d'entités
spatiales fournisse l'époque des coordonnées des coordonnées.
Le présent document ne fournit pas de mécanisme permettant d'associer différentes époques des
coordonnées à des géométries d'entité d'une collection. Si des données avec des époques des coordonnées
différentes sont fusionnées dans une collection, une option est d'effectuer des opérations liées aux
mouvements du point (PMO) pour convertir toutes les géométries à la même époque des coordonnées. Pour
de plus amples informations, voir l'ISO 19111, Information géographique — Système de références par
coordonnées (identique à la spécification abstraite de l'OGC Sujet 2 : Système de références par coordonnées).
4 © ISO 2022 – Tous droits réservés
---------------------- Page: 10 ----------------------
ISO 19168-2:2022(F)
Exigence 4 /req/crs/fc-md-storageCrs-valid-value
La valeur de la propriété storageCrs doit être l'un des identifiants de CRS de la liste d'identifiants de CRS pris en
charge disponible dans l'objet collection à l'aide de la propriété crs.
Le fragment de schéma suivant développe l'objet collection pour ajouter les propriétés storageCrs et
storageCrsCoordinateEpoch.
type: object
required:
- id
- links
properties:
id:
description: identifier of the collection used, for example, in URIs
type: string
example: address
title:
description: human readable title of the collection
type: string
example: address
description:
description: a description of the features in the collection
type: string
example: An address.
links:
type: array
items:
$ref: link.yaml
example:
- href: http://data.example.com/buildings
rel: item
- href: http://example.com/concepts/buildings.html
rel: describedby
type: text/html
extent:
$ref: extent.yaml
itemType:
description: indicator about the type of the items in the collection (the
default value is 'feature').
type: string
default: feature
crs:
description: the list of CRS identifiers supported by the service
type: array
items:
type: string
default:
- http://www.opengis.net/def/crs/OGC/1.3/CRS84
example:
- http://www.opengis.net/def/crs/OGC/1.3/CRS84
- http://www.opengis.net/def/crs/EPSG/0/4326
storageCrs:
© ISO 2022 – Tous droits réservés 5
---------------------- Page: 11 ----------------------
ISO 19168-2:2022(F)
description: the CRS identifier, from the list of supported CRS
identifiers, that may be used to retrieve features from a collection without
the need to apply a CRS transformation
type: string
format: uri
storageCrsCoordinateEpoch:
description: point in time at which coordinates in the spatial feature
collection are referenced to the dynamic coordinate reference system in
`storageCrs`, that may be used to retrieve features from a collection without
the need to apply a change of coordinate epoch. It is expressed as a decimal
year in the Gregorian calendar
type: number
example: '2017-03-25 in the Gregorian calendar is epoch 2017.23'
6.2.3 Liste globale des identifiants de CRS
Afin d'éviter la duplication inutile des listes d'identifiants de CRS pris en charge dans l'objet collection, une
liste globale d'identifiants de CRS pris en charge peut être fournie dans l'objet collections.
Cette liste globale d'identifiants de CRS n'est pas automatiquement héritée de chaque collection offerte par le
service. La liste globale des identifiants de CRS doit être explicitement référencée dans la propriété crs de
l'objet collection à l'aide d'un pointeur JSON (RFC 6901).
Exigence 5 /req/crs/fc-md-crs-list-global
Si la propriété crs dans l'objet collection d'une collection d'entités spatiales inclut un pointeur JSON à la liste globale
d'identifiants de CRS (#/crs), alors tous les identifiants de CRS dans la liste globale doivent être valides pour la
collection de référencement.
Il est à noter que seul un pointeur JSON local dans le même document est pris en charge.
Le fragment de schéma suivant développe l'objet collections pour ajouter la propriété crs qui contient la liste
globale des identifiants de CRS.
allOf:
- $ref:
'http://schemas.opengis.net/ogcapi/features/part1/1.0/openapi/schemas/collecti
ons.yaml'
- type: object
properties:
crs:
description: a global list of CRS identifiers that are supported by
spatial feature collections offered by the service
type: array
items:
type: string
format: uri
L'exemple suivant illustre l'utilisation d'une liste globale d'identifiants de CRS.
EXEMPLE Objet collections contenant une liste globale d'identifiants de CRS.
6 © ISO 2022 – Tous droits réservés
---------------------- Page: 12 ----------------------
ISO 19168-2:2022(F)
{
"links": [
{ "href": "http://data.example.org/collections.json",
"rel": "self", "type": "application/json", "title": "this document" },
{ "href": "http://data.example.org/collections.html",
"rel": "alternate", "type": "text/html", "title": "this document as
HTML" },
{ "href": "http://schemas.example.org/1.0/buildings.xsd",
"rel": "describedby", "type": "application/xml", "title": "GML
application schema for Acme Corporation building data" },
{ "href": "http://download.example.org/buildings.gpkg",
"rel": "enclosure", "type": "application/geopackage+sqlite3", "title":
"Bulk download (GeoPackage)", "length": 472546 }
],
"crs": [
"http://www.opengis.net/def/crs/OGC/1.3/CRS84",
"http://www.opengis.net/def/crs/EPSG/0/4326",
"http://www.ope
...
NORME ISO
INTERNATIONALE 19168-2
Première édition
2022-09
Information géographique — API
géospatiale pour les entités —
Partie 2:
Systèmes de coordonnées de référence
par référence
Geographic information – Geospatial API for features —
Part 2: Coordinate Reference Systems by Reference
Numéro de référence
ISO 19168-2:2022(F)
© ISO 2022
---------------------- Page: 1 ----------------------
ISO 19168-2:2022(F)
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2022
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii
© ISO 2022 – Tous droits réservés
---------------------- Page: 2 ----------------------
ISO 19168-2:2022(F)
Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d'application .1
2 Références normatives .1
3 Termes et définitions . 1
4 Conformité . 2
5 Conventions et contexte .3
6 Classe d'exigences Systèmes de coordonnées de référence par référence .3
6.1 Vue d'ensemble . 3
6.2 Découverte . 3
6.2.1 Liste des identifiants de CRS . 3
6.2.2 CRS de stockage . 4
6.2.3 Liste globale des identifiants de CRS . 5
6.3 Requête. 8
6.3.1 Paramètre bbox-crs . 8
6.3.2 Paramètre crs. 9
6.3.3 Considérations relatives au format de sortie . 10
6.3.4 Informations de systèmes de coordonnées de référence indépendants de
l'encodage des entités . 11
Annexe A (normative) Suite de tests abstraits.13
Bibliographie .17
iii
© ISO 2022 – Tous droits réservés
---------------------- Page: 3 ----------------------
ISO 19168-2:2022(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes
nationaux de normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est
en général confiée aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l'ISO, participent également aux travaux.
L'ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient en particulier de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO (voir www.iso.org/directives).
L'attention est attirée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l'élaboration du document sont indiqués dans l'Introduction et/ou dans la liste des déclarations de
brevets reçues par l'ISO (voir www.iso.org/brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l'intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion
de l'ISO aux principes de l'Organisation mondiale du commerce (OMC) concernant les obstacles
techniques au commerce (OTC), voir le lien suivant: www.iso.org/iso/fr/avant-propos.html.
Le présent document a été élaboré par l'Open Geospatial Consortium (sous le titre OGC API —
Features — Part 2: Coordinate Reference Systems by Reference) et rédigé conformément aux règles de
rédaction. Il a été assigné au comité technique ISO/TC 211, Information géographique/Géomatique, et
adopté dans le cadre de la «procédure rapide».
Les principales modifications sont les suivantes:
— ajout d'une introduction;
— harmonisation de l'orthographe selon les règles d'orthographes ISO;
— renumérotation et réorganisation des Articles 2-4 afin de correspondre à la structure fixe des
documents ISO;
— introduction de textes types aux Articles 2 et 3;
Une liste de toutes les parties de la série ISO 19168 se trouve sur le site web de l'ISO.
Il convient que l'utilisateur adresse tout retour d'information ou toute question concernant le présent
document à l'organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l'adresse www.iso.org/fr/members.html.
iv
© ISO 2022 – Tous droits réservés
---------------------- Page: 4 ----------------------
ISO 19168-2:2022(F)
Introduction
Les standards OGC API définissent les modules de construction de l'API pour activer spatialement les
API Web de façon cohérente. La spécification OpenAPI permet de définir les modules de construction de
l'API.
La famille de spécifications OGC API est organisée par type de ressource. Le présent document
développe les modules de construction fondamentaux de l'API en vue de l'interaction avec les entités. La
communauté des données spatiales utilise le terme «entité» pour désigner des objets du monde réel qui
présentent un intérêt.
Pour ceux qui ne connaîtraient pas le terme «entité», les explications concernant Spatial Things,
[6]
Features and Geometry dans le document Web Best Practice du W3C/OGC Spatial Data donnent de
plus amples informations.
OGC API Features fournit des modules de construction d'API pour créer, modifier et interroger les
entités sur le Web. OGC API Features est composé de plusieurs parties, dont chacune constitue un
standard distinct. Le présent document développe les capacités essentielles spécifiées dans l'OGC
API — Features — Part 1: Core (ISO 19168-1) avec la possibilité d'utiliser des identifiants de système de
coordonnées de référence autres que les identifiants par défaut définis dans le profil minimal.
Par défaut, chaque API mettant en œuvre le présent document donnera accès à un seul jeu de données.
Plutôt qu'un partage de données sous forme de jeu de données complet, les spécifications OGC API
Features offrent un accès direct et précis aux données au niveau entité (objet).
Les blocs de construction de l'API spécifiés dans le présent document sont en harmonie avec
l'architecture du Web. En particulier, la conception de l'API est gouvernée par les RFC IETF HTTP/
HTTPS, par les bonnes pratiques W3C pour publier des données sur le Web (W3C Data on the Web Best
Practices), par les bonnes pratiques W3C pour publier des données spatiales OGC sur le Web (W3C/
OGC Spatial Data on the Web Best Practices) et par les lignes directrices émergentes OGC Web API
Guidelines. Un exemple en particulier est l'utilisation des concepts de jeux de données et de distribution
des jeux de données tels que définis dans DCAT et utilisés dans schema.org.
La publication d'un sous-ensemble de la famille de standards OGC API par l'ISO est prévue. Par exemple,
le présent document est publié par l'ISO sous la référence ISO 19168-2. Pour indiquer que seul un sous-
ensemble des standards OGC API sera publié par l'ISO, et pour éviter d'utiliser des noms d'organismes
dans les titres des normes ISO, les normes de la série «OGC API» sont publiées par l'ISO sous forme
de «API géospatiale», c'est-à-dire que le titre du présent document dans l'OGC est «OGC API —
Features — Part 2: Coordinate Reference Systems by Reference» et le titre dans l'ISO est «Information
géographique — API géospatiale pour les entités — Partie 2: Systèmes de coordonnées de référence par
référence».
Pour des raisons de simplicité, le présent document utilise systématiquement:
— «OGC API» pour désigner la famille de normes pour les API Web géospatiales qui est publiée dans
l'ISO comme «API géospatiale»;
— «OGC API — Features» pour désigner la norme en plusieurs parties pour les entités qui est publiée
dans l'ISO comme ISO 19168 / «Information géographique — API géospatiale pour les entités»;
— «OGC API — Features — Part 1: Core» (profil minimal) pour faire référence au document qui est
publié dans l'ISO comme ISO 19168-1 / «Information géographique — API géospatiale pour les
entités — Partie 1: Profil minimal».
v
© ISO 2022 – Tous droits réservés
---------------------- Page: 5 ----------------------
NORME INTERNATIONALE ISO 19168-2:2022(F)
Information géographique — API géospatiale pour les
entités —
Partie 2:
Systèmes de coordonnées de référence par référence
1 Domaine d'application
Le présent document spécifie une extension à la norme «API géospatiale pour les entités —
Partie 1: Profil minimal» qui définit le comportement d'un serveur qui est en capacité de présenter
des propriétés associées à une valeur géométrique dans un document de réponse dans une liste de
Systèmes de coordonnées de référence (CRS) pris en charge.
Chaque CRS pris en charge est spécifié par référence à l'aide d'un identifiant de ressource universel
(URI).
Le présent document spécifie:
— comment, pour chaque collection d'entités proposée, un serveur publie la liste des identifiants de
CRS pris en charge;
— comment les coordonnées des propriétés d'entités associées à une valeur géométrique peuvent être
accessibles dans l'un des CRS pris en charge;
— comment les entités peuvent être accessibles depuis le serveur à l'aide d'un rectangle englobant
spécifié dans l'un des CRS pris en charge; et
— comment un serveur peut déclarer le système de CRS utilisé pour présenter des ressources d'entités.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l’édition citée s’applique.
Pour les références non datées, la dernière édition du document de référence s'applique (y compris les
éventuels amendements).
ISO 19168-1:2020, Information géographique — API géospatiale pour les entités — Partie 1: Profil minimal
3 Termes et définitions
Pour les besoins du présent document, les termes et les définitions de l'ISO 19168-1 ainsi que les
suivants s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l’adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l’adresse https:// www .electropedia .org/
NOTE Les termes entités (3.4) et collection d'entités (3.5) et l'acronyme CRS (3.2) sont dupliqués
de l'ISO 19168-1.
1
© ISO 2022 – Tous droits réservés
---------------------- Page: 6 ----------------------
ISO 19168-2:2022(F)
3.1
coordonnée
l'une des séquences de nombres désignant la position d'un point
Note 1 à l'article: Dans un système de coordonnées de référence spatial, les coordonnées sont établies par unités.
[SOURCE: ISO 19111:2019, 3.1.5]
3.2
système de référence de coordonnées
CRS
système de coordonnées (3.3) associé à un objet par une référence
Note 1 à l'article: Les référentiels géodésiques et verticaux sont appelés «repères de référence».
Note 2 à l'article: Pour les repères de référence géodésiques et verticaux, l'objet est la Terre. Dans les applications
planétaires, les repères de référence géodésiques et verticaux peuvent être appliqués à d'autres corps célestes.
[SOURCE: ISO 19111:2019, 3.1.9]
3.3
système de coordonnées
ensemble de règles mathématiques déterminant la façon dont les coordonnées (3.1) sont affectées à des
points
[SOURCE: ISO 19111:2019, 3.1.11]
3.4
entité
abstraction d'un phénomène du monde réel
Note 1 à l'article: Les explications concernant Spatial Things, Features and Geometry des W3C/OGC Spatial Data
[6]
dans le document Web Best Practice donnent de plus amples informations.
[SOURCE: ISO 19101-1:2014, 4.1.11, modifiée – La Note 1 à l'article a été ajoutée.]
3.5
collection d'entités
collection
ensemble d'entités (3.4) provenant d'un jeu de données (ISO 19168-1, 3.1.1)
3.6
collection d'entités spatiales
collection spatiale
collection d'entités (3.5) qui comprend une ou plusieurs entités (3.4) qui ont des propriétés associées à
une valeur géométrique
[SOURCE: ISO 19168-1:2020, 3.1.4]
4 Conformité
Le présent document définit une classe d'exigences, Systèmes de coordonnées de référence par
référence. La cible de normalisation est «API Web».
L'URI de la classe de conformité associée est http:// www .opengis .net/ spec/ ogcapi -features -2/ 1 .0/ conf/
crs.
La conformité avec la présente norme doit être vérifiée à l'aide de tous les essais concernés spécifiés
à l'Annexe A du présent document. La structure, les concepts et la méthodologie d'essai, ainsi que les
critères à remplir pour revendiquer la conformité sont spécifiés dans les OGC Compliance Testing
Policies and Procedures et sur le site Web OGC Compliance Testing.
2
© ISO 2022 – Tous droits réservés
---------------------- Page: 7 ----------------------
ISO 19168-2:2022(F)
5 Conventions et contexte
Voir l'ISO 19168-1:2020, Articles 5 et 6.
6 Classe d'exigences Systèmes de coordonnées de référence par référence
6.1 Vue d'ensemble
Classe d'exigences
http:// www .opengis .net/ spec/ ogcapi -features -2/ 1 .0/ req/ crs
Type de cible API Web
Dépendance OGC API - Features - Part 1: Core, Classe d'exigences «Profil minimal»
La norme OGC API - Features - Part 1: Core ne définit le support que pour deux systèmes de coordonnées
de référence:
— WGS 84 longitude, latitude;
— WGS 84 longitude, latitude, altitude ellipsoïdale.
Cette extension définit le comportement d'un serveur qui prend en charge des systèmes de coordonnées
de référence supplémentaires.
Exigence 1 /req/crs/crs-uri
Chaque CRS pris en charge par un serveur doit être référençable par un identifiant de ressource universel
(c'est-à-dire un URI).
Recommandation 1 /rec/crs/crs-format-model
Il convient que les serveurs qui implémentent cette extension soient capables de reconnaître et de générer des
identifiants de CRS avec le modèle de format suivant:
http://www.opengis.net/def/crs/authority/version/code
Dans ce modèle de format, le jeton {authority} est un paramètre fictif pour une valeur qui désigne l'autorité
responsable de la définition de ce CRS. Les valeurs typiques comprennent «EPSG» et «OGC».
Le jeton {version} est un paramètre fictif pour la version spécifique de la définition du CRS ou 0 pour les défini-
tions du CRS non versionnées.
Le jeton {code} est un paramètre fictif pour le code pour le CRS de l'autorité.
Pour de plus amples informations, voir le paragraphe 6.2 de l'OGC Name Type Specification, Partie 1.
Il est à noter que bien que le registre EPSG lui-même soit versionné, les éléments enregistrés ne sont pas
versionnés et la «version» est toujours «0» dans les URI de l'autorité «EPSG».
6.2 Découverte
6.2.1 Liste des identifiants de CRS
Exigence 2 /req/crs/fc-md-crs-list
A La propriété crs dans l'objet collection d'une collection d'entités spatiales doit contenir les
identifiants de la liste de CRS pris en charge par le serveur pour cette collection.
B Cette liste doit inclure le(s) CRS par défaut défini(s) dans l'OGC API - OGC API - Features -
Part 1: Core.
3
© ISO 2022 – Tous droits réservés
---------------------- Page: 8 ----------------------
ISO 19168-2:2022(F)
La liste doit inclure le CRS par défaut — c'est-à-dire le CRS utilisé à moins que quelque chose d'autre
ne soit explicitement demandé — défini dans la norme ISO 19168-1, Information géographique — API
géospatiale pour les entités — Partie 1: Profil minimal en tant que:
— http:// www .opengis .net/ def/ crs/ OGC/ 1 .3/ CRS84 (pour les coordonnées sans altitude);
— http:// www .opengis .net/ def/ crs/ OGC/ 0/ CRS84h (pour les coordonnées avec altitude ellipsoïdale).
6.2.2 CRS de stockage
Le CRS de stockage pour une collection d'entités spatiales est l'identifiant de CRS qui peut être utilisé
pour récupérer des entités de cette collection sans avoir à appliquer une transformation de CRS.
Il est à noter que les coordonnées qui se réfèrent à un système de coordonnées de référence dynamique
sont ambiguës si l'époque des coordonnées est inconnue. Il est donc recommandé de fournir également
l'époque des coordonnées lorsque le CRS de stockage est dynamique, par exemple une réalisation de
l'ITRF ou le WGS 84. Pour de plus amples informations sur les systèmes de coordonnées de référence
dynamiques et l'époque des coordonnées, consulter l'ISO 19111 Information géographique — Système de
références par coordonnées (identique à la spécification abstraite de l'OGC Sujet 2: Système de références
par coordonnées).
Exigence 3 /req/crs/fc-md-storageCrs
Si toutes les entités d'une collection d'entités spatiales sont stockées à l'aide d'un CRS particulier, alors la pro-
priété storageCrs doit être spécifiée dans l'objet collection de la collection d'entités spatiales pour indiquer
l'identifiant de ce CRS de stockage.
Recommandation 2 /rec/crs/fc-md-coordinateEpoch
Si le CRS de stockage de la collection d'entités spatiales est un système de coordonnées de référence dyna-
mique, il convient que la propriété storageCrsCoordinateEpoch dans l'objet collection de la collection d'enti-
tés spatiales fournisse l'époque des coordonnées des coordonnées.
Le présent document ne fournit pas de mécanisme permettant d'associer différentes époques
des coordonnées à des géométries d'entité d'une collection. Si des données avec des époques des
coordonnées différentes sont fusionnées dans une collection, une option est d'effectuer des opérations
liées aux mouvements du point (PMO) pour convertir toutes les géométries à la même époque des
coordonnées. Pour de plus amples informations, voir l'ISO 19111, Information géographique — Système
de références par coordonnées (identique à la spécification abstraite de l'OGC Sujet 2: Système de
références par coordonnées).
Exigence 4 /req/crs/fc-md-storageCrs-valid-value
La valeur de la propriété storageCrs doit être l'un des identifiants de CRS de la liste d'identifiants de CRS pris
en charge disponible dans l'objet collection à l'aide de la propriété crs.
Le fragment de schéma suivant développe l'objet collection pour ajouter les propriétés storageCrs et
storageCrsCoordinateEpoch.
type: object
required:
- id
- links
properties:
id:
description: identifier of the collection used, for example, in URIs
type: string
example: address
title:
description: human readable title of the collection
type: string
example: address
4
© ISO 2022 – Tous droits réservés
---------------------- Page: 9 ----------------------
ISO 19168-2:2022(F)
description:
description: a description of the features in the collection
type: string
example: An address.
links:
type: array
items:
$ref: link.yaml
example:
- href: http://data.example.com/buildings
rel: item
- href: http://example.com/concepts/buildings.html
rel: describedby
type: text/html
extent:
$ref: extent.yaml
itemType:
description: indicator about the type of the items in the collection (the default
value is 'feature').
type: string
default: feature
crs:
description: the list of CRS identifiers supported by the service
type: array
items:
type: string
default:
- http://www.opengis.net/def/crs/OGC/1.3/CRS84
example:
- http://www.opengis.net/def/crs/OGC/1.3/CRS84
- http://www.opengis.net/def/crs/EPSG/0/4326
storageCrs:
description: the CRS identifier, from the list of supported CRS identifiers, that
may be used to retrieve features from a collection without the need to apply a CRS
transformation
type: string
format: uri
storageCrsCoordinateEpoch:
description: point in time at which coordinates in the spatial feature
collection are referenced to the dynamic coordinate reference system in
`storageCrs`, that may be used to retrieve features from a collection without
the need to apply a change of coordinate epoch. It is expressed as a decimal
year in the Gregorian calendar
type: number
example: '2017-03-25 in the Gregorian calendar is epoch 2017.23'
6.2.3 Liste globale des identifiants de CRS
Afin d'éviter la duplication inutile des listes d'identifiants de CRS pris en charge dans l'objet collection,
une liste globale d'identifiants de CRS pris en charge peut être fournie dans l'objet collections.
Cette liste globale d'identifiants de CRS n'est pas automatiquement héritée de chaque collection
offerte par le service. La liste globale des identifiants de CRS doit être explicitement référencée dans la
propriété crs de l'objet collection à l'aide d'un pointeur JSON (RFC 6901).
Exigence 5 /req/crs/fc-md-crs-list-global
Si la propriété crs dans l'objet collection d'une collection d'entités spatiales inclut un pointeur JSON à la liste
globale d'identifiants de CRS (#/crs), alors tous les identifiants de CRS dans la liste globale doivent être
valides pour la collection de référencement.
Il est à noter que seul un pointeur JSON local dans le même document est pris en charge.
Le fragment de schéma suivant développe l'objet collections pour ajouter la propriété crs qui contient la
liste globale des identifiants de CRS.
5
© ISO 2022 – Tous droits réservés
---------------------- Page: 10 ----------------------
ISO 19168-2:2022(F)
allOf:
- $ref:
'http://schemas.opengis.net/ogcapi/features/part1/1.0/openapi/schemas/collections.yaml'
- type: object
properties:
crs:
description: a global list of CRS identifiers that are supported by spatial feature
collections offered by the service
type: array
items:
type: string
format: uri
L'exemple suivant illustre l'utilisation d'une liste globale d'identifiants de CRS.
EXEMPLE Objet collections contenant une liste globale d'identifiants de CRS.
{
"links": [
{ "href": "http://data.example.org/collections.json",
"rel": "self", "type": "application/json", "title": "this document" },
{ "href": "http://data.example.org/collections.html",
"rel": "alternate", "type": "text/html", "title": "this document as
HTML" },
{ "href": "http://schemas.example.org/1.0/buildings.xsd",
"rel": "describedby", "type": "application/xml", "title": "GML
application schema for Acme Corporation building data" },
{ "href": "http://download.example.org/buildings.gpkg",
"rel": "enclosure", "type": "application/geopackage+sqlite3", "title":
"Bulk download (GeoPackage)", "length": 472546 }
],
"crs": [
"http://www.opengis.net/def/crs/OGC/1.3/CRS84",
"http://www.opengis.net/def/crs/EPSG/0/4326",
"http://www.opengis.net/def/crs/EPSG/0/3857",
"http://www.opengis.net/def/crs/EPSG/0/3395"
],
"collections": [
{
"id": "bonn_buildings",
"title": "Bonn Buildings",
"description": "Buildings in the city of Bonn.",
"extent": {
"spatial": {
"bbox": [ [ 7.01, 50.63, 7.22, 50.78 ] ]
},
"temporal": {
"interval": [ [ "2010-02-15T12:34:56Z", null ] ]
}
},
"links": [
{ "href":
"http://data.example.org/collections/bonn_buildings/items",
"rel": "items", "type": "application/geo+json",
"title": "Bonn Buildings" },
{ "href": "https://creativecommons.org/publicdomain/zero/1.0/",
"rel": "license", "type": "text/html",
"title": "CC0-1.0" },
{ "href":
"https://creativecommons.org/publicdomain/zero/1.0/rdf",
"rel": "license", "type": "application/rdf+xml",
"title": "CC0-1.0" }
],
"crs": [
"#/crs",
"http://www.opengis.net/def/crs/EPSG/0/4258",
"http://www.opengis.net/def/crs/EPSG/0/25831",
"http://www.opengis.net/def/crs/EPSG/0/25832"
]
},
{
6
© ISO 2022 – Tous droits réservés
---------------------- Page: 11 ----------------------
ISO 19168-2:2022(F)
"id": "tor_buildings",
"title": "Toronto Buildings",
"description": "Buildings in the city of Toronto.",
"extent": {
"spatial": {
"bbox": [ [ −79.62, 43.58, −79.12, 43.87 ] ]
},
"temporal": {
"interval": [ [ "2010-02-15T12:34:56Z", null ] ]
}
},
"links": [
{ "href":
"http://data.example.org/collections/tor_buildings/items",
"rel": "items", "type": "application/geo+json",
"title": "Toronto Buildings" },
{ "href": "https://creativecommons.org/publicdomain/zero/1.0/",
"rel": "license", "type": "text/html",
"title": "CC0-1.0" },
{ "href":
"https://creativecommons.org/publicdomain/zero/1.0/rdf",
"rel": "license", "type": "application/rdf+xml",
"title": "CC0-1.0" }
],
"crs": [
"#/crs"
]
},
{
"id": "dc_buildings",
"title": "Washington DC Buildings",
"description": "Buildings in the city of Washington DC.",
"extent": {
"spatial": {
"bbox": [ [ −77.12, 38.80, −76.89, 39.01 ] ]
},
"temporal": {
"interval": [ [ "2010-02-15T12:34:56Z", null ] ]
}
},
"links": [
{ "href":
"http://data.example.org/collections/dc_buildings/items",
"rel": "items", "type": "application/geo+json",
"title": "DC Buildings" },
{ "href": "https://creativecommons.org/publicdomain/zero/1.0/",
"rel": "license", "type": "text/html",
"title": "CC0-1.0" },
{ "href":
"https://creativecommons.org/publicdomain/zero/1.0/rdf",
"rel": "license", "type": "application/rdf+xml",
"title": "CC0-1.0" }
],
"crs": [
"http://w
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.