ISO 19168-1:2020
(Main)Geographic information - Geospatial API for features - Part 1: Core
Geographic information - Geospatial API for features - Part 1: Core
This document specifies the behaviour of Web APIs that provide access to features in a dataset in a manner independent of the underlying data store. This document defines discovery and query operations. Discovery operations enable clients to interrogate the API, including the API definition and metadata about the feature collections provided by the API, to determine the capabilities of the API and retrieve information about available distributions of the dataset. Query operations enable clients to retrieve features from the underlying data store based upon simple selection criteria, defined by the client.
Information géographique — API géospatiale pour les entités — Partie 1: Profil minimal
Le présent document spécifie le comportement des API Web donnant accès aux entités d'un jeu de données indépendamment du système sous-jacent de stockage de données. Le présent document définit les opérations de découverte et d'interrogation. Les opérations de découverte permettent aux clients d'interroger l'API, y compris la définition et les métadonnées de l'API concernant les collections d'entités fournies par l'API, pour déterminer les capacités de l'API et extraire des informations relatives aux distributions disponibles de jeux de données. Les opérations d'interrogation permettent aux clients d'extraire des entités du système sous-jacent de stockage de données sur la base de critères de sélection simples définis par le client.
General Information
- Status
- Published
- Publication Date
- 13-Sep-2020
- Technical Committee
- ISO/TC 211 - Geographic information/Geomatics
- Drafting Committee
- ISO/TC 211/WG 4 - Geospatial services
- Current Stage
- 9599 - Withdrawal of International Standard
- Start Date
- 10-Jan-2025
- Completion Date
- 13-Dec-2025
Relations
- Effective Date
- 11-Feb-2023
Overview
ISO 19168-1:2020 - Geographic information: Geospatial API for features - Part 1: Core defines a minimal, implementation‑independent profile for Web APIs that provide access to geospatial features (vector data). The standard specifies the expected behaviour of discovery and query operations so clients can discover API capabilities, retrieve API definitions and metadata about feature collections, and query features using simple, well‑defined selection criteria - regardless of the underlying data store.
Key topics and technical requirements
- Discovery operations: endpoints for API landing page, API definition (often expressed with OpenAPI), and manifest of feature collections and available distributions.
- Query operations: feature collection and feature endpoints to retrieve collections or individual features based on client‑supplied parameters.
- Conformance classes: a Core requirements class plus encoding classes (examples in the standard include HTML, GeoJSON, and GML profiles) and an OpenAPI 3.0 class for machine‑readable API definitions.
- Filtering and parameters: support for spatial and temporal filters (e.g., bbox, datetime) and property filters; rules for parameter combinations and limits.
- HTTP semantics: required use of HTTPS, HTTP/1.1 status codes, handling of unknown/invalid parameters, caching, and link headers for pagination or related resources.
- Encodings and media types: guidance for response formats, character internationalization, and coordinate reference system handling.
- Security and robustness: recommendations and considerations for multiple access routes, multiple servers, and safe handling of path manipulation for GET/POST/PUT.
- Testing and conformance: an abstract test suite (Annex A) to support validation of implementations and declared conformance.
Practical applications and target users
ISO 19168-1:2020 is intended for:
- GIS software developers building RESTful geospatial feature APIs
- Data publishers and national mapping agencies exposing vector datasets as web services
- Platform and cloud providers implementing interoperable feature endpoints
- QA teams and integrators validating API conformance and interoperability Practical benefits include consistent discovery of datasets, interoperable client access (e.g., web apps, analytics pipelines), standardized query behaviour (bbox, datetime, property filters), and improved reusability of geospatial feature services.
Related standards
This Core part sits in a family of geospatial API specifications and complements other geospatial metadata, feature and service standards. Implementers commonly pair ISO 19168‑1 APIs with machine‑readable OpenAPI 3.0 definitions and encoding profiles (GeoJSON, GML) described in the standard.
Keywords: ISO 19168-1:2020, Geospatial API, feature collections, GeoJSON, GML, OpenAPI, bbox, datetime, Web API, geospatial features, API conformance.
ISO 19168-1:2020 - Geographic information — Geospatial API for features — Part 1: Core Released:9/14/2020
ISO 19168-1:2020 - Information géographique — API géospatiale pour les entités — Partie 1: Profil minimal Released:7/12/2021
REDLINE ISO 19168-1:2020 - Geographic information — Geospatial API for features — Part 1: Core Released:7/12/2021
Frequently Asked Questions
ISO 19168-1:2020 is a standard published by the International Organization for Standardization (ISO). Its full title is "Geographic information - Geospatial API for features - Part 1: Core". This standard covers: This document specifies the behaviour of Web APIs that provide access to features in a dataset in a manner independent of the underlying data store. This document defines discovery and query operations. Discovery operations enable clients to interrogate the API, including the API definition and metadata about the feature collections provided by the API, to determine the capabilities of the API and retrieve information about available distributions of the dataset. Query operations enable clients to retrieve features from the underlying data store based upon simple selection criteria, defined by the client.
This document specifies the behaviour of Web APIs that provide access to features in a dataset in a manner independent of the underlying data store. This document defines discovery and query operations. Discovery operations enable clients to interrogate the API, including the API definition and metadata about the feature collections provided by the API, to determine the capabilities of the API and retrieve information about available distributions of the dataset. Query operations enable clients to retrieve features from the underlying data store based upon simple selection criteria, defined by the client.
ISO 19168-1:2020 is classified under the following ICS (International Classification for Standards) categories: 35.240.70 - IT applications in science. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 19168-1:2020 has the following relationships with other standards: It is inter standard links to ISO 19168-1:2025. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 19168-1:2020 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 19168-1
First edition
2020-09
Geographic information — Geospatial
API for features —
Part 1:
Core
Information géographique — API géospatiale pour les entités —
Partie 1: Profil minimal
Reference number
©
ISO 2020
© ISO 2020
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 2020 – All rights reserved
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Abbreviated terms . 2
4 Conformance . 3
5 Conventions . 4
5.1 Identifiers . 4
5.2 Link relations. 4
5.3 Use of HTTPS . 5
5.4 HTTP URIs . 5
5.5 API definition. 5
5.5.1 General remarks . 5
5.5.2 Role of OpenAPI . 5
5.5.3 References to OpenAPI components in normative statements . 6
5.5.4 Paths in OpenAPI definitions . 6
5.5.5 Reusable OpenAPI components . 6
6 Overview . 6
6.1 Design considerations. 6
6.2 Encodings . 7
6.3 Examples . 8
7 Requirements class "Core" . 8
7.1 Overview . 8
7.2 API landing page .10
7.2.1 Operation .10
7.2.2 Response .11
7.2.3 Error situations .11
7.3 API definition.12
7.3.1 Operation .12
7.3.2 Response .12
7.3.3 Error situations .12
7.4 Declaration of conformance classes .12
7.4.1 Operation .12
7.4.2 Response .13
7.4.3 Error situations .13
7.5 HTTP 1.1 .13
7.5.1 HTTP status codes .13
7.6 Unknown or invalid query parameters .14
7.7 Web caching .15
7.8 Support for cross-origin requests.15
7.9 Encodings .15
7.10 String internationalization .16
7.11 Coordinate reference systems .16
7.12 Link headers .17
7.13 Feature collections .17
7.13.1 Operation .17
7.13.2 Response .17
7.13.3 Error situations .22
7.14 Feature collection .22
7.14.1 Operation .22
7.14.2 Response .22
7.14.3 Error situations .22
7.15 Features .23
7.15.1 Operation .23
7.15.2 Parameter limit .23
7.15.3 Parameter bbox .24
7.15.4 Parameter datetime . .25
7.15.5 Parameters for filtering on feature properties .26
7.15.6 Combinations of filter parameters .27
7.15.7 Response .27
7.15.8 Error situations .29
7.16 Feature .30
7.16.1 Operation .30
7.16.2 Response .30
7.16.3 Error situations .30
8 Requirements classes for encodings .31
8.1 Overview .31
8.2 Requirements Class "HTML" .31
8.3 Requirements Class "GeoJSON" .32
8.4 Requirements Class "Geography Markup Language (GML), Simple Features Profile,
Level 0" .33
8.5 Requirements class "Geography Markup Language (GML), Simple Features Profile,
Level 2" .35
9 Requirements class "OpenAPI 3.0" .36
9.1 Basic requirements .36
9.2 Complete definition .36
9.3 Exceptions .37
9.4 Security .37
9.5 Features .37
10 Media types .37
11 Security considerations.38
11.1 General .38
11.2 Multiple access routes .38
11.3 Multiple servers .39
11.4 Path manipulation on GET .39
11.5 Path manipulation on PUT and POST .39
Annex A (normative) Abstract test suite .40
Bibliography .54
iv © ISO 2020 – All rights reserved
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. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (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 Technical Committee ISO/TC 211, Geographic information/Geomatics.
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.
Introduction
[9]
OGC API standards define modular API building blocks to spatially enable Web APIs in a consistent
manner. The OpenAPI specification is used to define the API building blocks.
The OGC API family of standards is organized by resource type. This document specifies 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
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 a separate standard. This document,
the "Core", specifies the core capabilities and is restricted to fetching features where geometries are
represented in the coordinate reference system, WGS 84, with axis order longitude/latitude. Additional
capabilities that address more advanced needs will be specified in additional parts. Examples include
support for creating and modifying features, more complex data models, richer queries, additional
coordinate reference systems, multiple datasets and collection hierarchies.
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.
This document specifies discovery and query operations that are implemented using the HTTP GET
method. Support for additional methods (in particular POST, PUT, DELETE, PATCH) will be specified in
additional parts.
Discovery operations enable clients to interrogate the API, including the API definition and metadata
about the feature collections provided by the API, to determine the capabilities of the API and retrieve
information about available distributions of the dataset.
Query operations enable clients to retrieve features from the underlying data store based upon simple
selection criteria, defined by the client.
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-1. 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 1: Core" and the title in ISO is "Geographic Information — Geospatial
API for features — Part 1: Core."
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 this document that in ISO is published as ISO 19168-1
/ "Geographic Information - Geospatial API for features — Part 1: Core."
This document defines the resources listed in Table 1. For an overview of the resources, see 7.1.
vi © ISO 2020 – All rights reserved
Table 1 — Overview of resources, applicable HTTP methods and links to the document sections
HTTP
Resource Path method Document reference
Landing page / GET 7.2 API landing page
Conformance /conformance GET 7.4 Declaration of conformance
declaration classes
Feature collections /collections GET 7.13 Feature collections
Feature collection /collections/{collectionId} GET 7.14 Feature collection
Features /collections/{collectionId}/items GET 7.15 Features
Feature /collections/{collectionId}/items/{featureId} GET 7.16 Feature
Implementations of OGC API Features are intended to support two different approaches for how clients
can use the API. For further information, see 6.1.
INTERNATIONAL STANDARD ISO 19168-1:2020(E)
Geographic information — Geospatial API for features —
Part 1:
Core
1 Scope
This document specifies the behaviour of Web APIs that provide access to features in a dataset in a
manner independent of the underlying data store. This document defines discovery and query
operations.
Discovery operations enable clients to interrogate the API, including the API definition and metadata
about the feature collections provided by the API, to determine the capabilities of the API and retrieve
information about available distributions of the dataset.
Query operations enable clients to retrieve features from the underlying data store based upon simple
selection criteria, defined by the client.
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.
Internet Engineering Task Force (IETF), RFC 2818: HTTP Over TLS [online]. Edited by E. Rescorla.
2000 [viewed 2020-03-16]. Available at https:// tools .ietf .org/ rfc/ rfc2818 .txt
Internet Engineering Task Force (IETF), RFC 3339:2002: Date and Time on the Internet:
Timestamps [online]. Edited by G. Klyne, C. Newman. 2002 [viewed 2020-03-16]. Available at https://
tools .ietf .org/ rfc/ rfc3339 .txt
Internet Engineering Task Force (IETF), RFC 7230 to RFC 7235: HTTP/1.1 [online]. Edited by R.
Fielding, J. Reschke, Y. Lafon, M. Nottingham. 2014 [viewed 2020-04-28]. Available at https:// tools
.ietf .org/ rfc/ rfc7230 .txt, https:// tools .ietf .org/ rfc/ rfc7231 .txt, https:// tools .ietf .org/ rfc/ rfc7232 .txt,
https:// tools .ietf .org/ rfc/ rfc7233 .txt, https:// tools .ietf .org/ rfc/ rfc7234 .txt, and https:// tools .ietf .org/
rfc/ rfc7235 .txt
Internet Engineering Task Force (IETF), RFC 8288:2017: Web Linking [online]. Edited by M.
Nottingham. 2017 [viewed 2020-03-16]. Available at https:// tools .ietf .org/ rfc/ rfc8288 .txt
OpenAPI Initiative (OAI), OpenAPI Specification 3.0 [online]. 2020 [viewed 2020-03-16]. The latest
patch version at the time of publication of this standard was 3.0.3, available at http:// spec .openapis
.org/ oas/ v3 .0 .3
3 Terms, definitions and abbreviated terms
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
3.1.1
dataset
collection of data
Note 1 to entry: Published or curated by a single agent, and available for access or download in one or more
formats.
Note 2 to entry: The use of ‘collection’ in the definition from DCAT is broader than the use of the term collection
in this document. See the definition of feature collection (3.1.4).
[8]
[SOURCE: DCAT , 6.6, modified — Definition split into definition and Note 1 to entry; Note 2 to entry
has been added]
3.1.2
distribution
specific representation of a dataset (3.1.1)
EXAMPLE A downloadable file, an RSS feed or an API.
[8]
[SOURCE: DCAT , 6.7, modified — Definition has been shortened]
3.1.3
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.1.4
feature collection
collection
set of features (3.1.3) from a dataset (3.1.1)
3.1.5
Web API
API using an architectural style that is founded on the technologies of the Web
Note 1 to entry: Best Practice 24: Use Web Standards as the foundation of APIs in the W3C Data on the Web Best
[7]
Practices provides more detail.
[7]
[SOURCE: DWBP , 8.10.1, modified — Rephrased for clarity]
3.1 Abbreviated terms
API Application Programming Interface
CORS Cross-Origin Resource Sharing
CRS Coordinate Reference System
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IANA Internet Assigned Numbers Authority
OGC Open Geospatial Consortium
2 © ISO 2020 – All rights reserved
TRS Temporal Coordinate Reference System
URI Uniform Resource Identifier
YAML YAML Ain’t Markup Language
4 Conformance
This document defines six requirements/conformance classes.
The standardization targets of all conformance classes are "Web APIs."
The main requirements class is:
— Core.
The Core specifies requirements that all Web APIs have to implement.
The Core does not mandate a specific encoding or format for representing features or feature collections.
Four requirements classes depend on the Core and specify representations for these resources in
commonly used encodings for spatial data on the web:
— HTML,
— GeoJSON,
— Geography Markup Language (GML), Simple Features Profile, Level 0, and
— Geography Markup Language (GML), Simple Features Profile, Level 2.
None of these encodings are mandatory and an implementation of the Core may also decide to implement
none of them, but to implement another encoding instead.
That said, the Core requirements class includes recommendations to support, where practical,
HTML and GeoJSON as encodings. Clause 6 (Overview) includes a discussion about the recommended
encodings.
The Core does not mandate any encoding or format for the formal definition of the API either. One
option is the OpenAPI 3.0 specification and a requirements class has been specified for OpenAPI 3.0,
which depends on the Core:
— OpenAPI specification 3.0.
As with the feature encodings, an implementation of the Core requirements class may also decide to
use other API definition representations in addition or instead of an OpenAPI 3.0 definition. Examples
for alternative API definitions: OpenAPI 2.0 (Swagger), future versions of the OpenAPI specification, an
OWS Common 2.0 capabilities document or WSDL.
The Core is intended to be a minimal useful API for fine-grained read-access to a spatial dataset where
geometries are represented in the coordinate reference system WGS 84 with axis order longitude/
latitude.
Additional capabilities, e.g. support for transactions, complex data structures, rich queries, other
coordinate reference systems, subscription/notification, and returning aggregated results, may be
specified in future parts of the OGC API Features series or as vendor-specific extensions.
Conformance with this document shall be checked using all the relevant tests specified in Annex A
(normative) 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. Table 2 provides conformance class URIs
Table 2 — Conformance class URIs
Conformance class URI
Core http:// www .opengis .net/ spec/ ogcapi -features -1/ 1 .0/ conf/ core
HTML http:// www .opengis .net/ spec/ ogcapi -features -1/ 1 .0/ conf/ html
GeoJSON http:// www .opengis .net/ spec/ ogcapi -features -1/ 1 .0/ conf/ geojson
GML, Simple Features Profile, Level 0 http:// www .opengis .net/ spec/ ogcapi -features -1/ 1 .0/ conf/ gmlsf0
GML, Simple Features Profile, Level 2 http:// www .opengis .net/ spec/ ogcapi -features -1/ 1 .0/ conf/ gmlsf2
OpenAPI Specification 3.0 http:// www .opengis .net/ spec/ ogcapi -features -1/ 1 .0/ conf/ oas30
5 Conventions
5.1 Identifiers
The normative provisions in this document are denoted by the URI http://www.opengis.net/spec/
ogcapi-features-1/1.0.
All requirements and conformance tests that appear in this document are denoted by partial URIs
which are relative to this base.
5.2 Link relations
To express relationships between resources, RFC 8288 (Web Linking) is used.
[3]
The following registered link relation types are used in this document.
— alternate: Refers to a substitute for this context.
— collection: The target IRI points to a resource which represents the collection resource for the
context IRI.
— describedby: Refers to a resource providing information about the link’s context.
— item: The target IRI points to a resource that is a member of the collection represented by the
context IRI.
— next: Indicates that the link’s context is a part of a series, and that the next in the series is the
link target.
— license: Refers to a license associated with this context.
— prev: Indicates that the link’s context is a part of a series, and that the previous in the series is the
link target.
— This relation is only used in examples.
— self: Conveys an identifier for the link’s context.
— service-desc: Identifies service description for the context that is primarily intended for
consumption by machines.
— API definitions are considered service descriptions.
— service-doc: Identifies service documentation for the context that is primarily intended for human
consumption.
4 © ISO 2020 – All rights reserved
In addition, the following link relation types are used for which no applicable registered link relation
type could be identified.
— items: Refers to a resource that is comprised of members of the collection represented by the link’s
context.
— conformance: Refers to a resource that identifies the specifications that the link’s context
conforms to.
— data: Refers to the root resource of a dataset in an API.
Each resource representation includes an array of links. Implementations are free to add additional
links for all resources provided by the API. For example, an enclosure link could reference a bulk
download of a collection. Or a related link on a feature could reference a related feature.
5.3 Use of HTTPS
For simplicity, this document in general only refers to the HTTP protocol. This is not meant to exclude
the use of HTTPS but is a shorthand notation for "HTTP or HTTPS." In fact, most servers are expected to
use HTTPS, not HTTP.
5.4 HTTP URIs
This document does not restrict the lexical space of URIs used in the API beyond the requirements of
the HTTP and URI Syntax IETF RFCs. If URIs include reserved characters that are delimiters in the URI
[2]
subcomponent, these have to be percent-encoded. See RFC 3986:2005, Clause 2 for details.
5.5 API definition
5.5.1 General remarks
Good documentation is essential for every API so that developers can more easily learn how to use the
API. In the best case, documentation will be available in HTML and in a format that can be processed by
software to connect to the API.
This document specifies requirements and recommendations for APIs that share feature data and
that want to follow a standard way of doing so. In general, APIs will go beyond the requirements and
recommendations stated in this document, or other parts of the OGC API series of standards, and will
support additional operations, parameters, etc. that are specific to the API or the software tool used to
implement the API.
5.5.2 Role of OpenAPI
This document uses OpenAPI 3.0 fragments as examples and to formally state requirements. However,
using OpenAPI 3.0 is not required for implementing a server.
Therefore, the Core requirements class only requires that an API definition be provided and linked
from the landing page.
A separate requirements class is specified for API definitions that follow the OpenAPI specification
3.0. This does not preclude that in the future or in parallel, other versions of OpenAPI or other API
descriptions are provided by a server.
NOTE This approach is used to avoid lock-in to a specific approach to defining an API as it is expected that
the API landscape will continue to evolve.
In this document, fragments of OpenAPI definitions are shown in YAML (YAML Ain’t Markup Language)
[1]
since YAML is easier to read than JSON and is typically used in OpenAPI editors. YAML is described
by its authors as a human friendly data serialization standard for all programming languages.
5.5.3 References to OpenAPI components in normative statements
Some normative statements (requirements, recommendations and permissions) use a phrase that a
component in the API definition of the server must be "based upon" a schema or parameter component
in the OGC schema repository.
In this case, the following changes to the pre-defined OpenAPI component are permitted.
— If the server supports an XML encoding, xml properties may be added to the relevant OpenAPI
schema components.
— The range of values of a parameter or property may be extended (additional values) or constrained
(if a subset of all possible values is applicable to the server). An example for a constrained range of
values is to explicitly specify the supported values of a string parameter or property using an enum.
— The default value of a parameter may be changed or added unless a requirement explicitly
prohibits this.
— Additional properties may be added to the schema definition of a Response Object.
— Informative text may be changed or added, e.g. comments or description properties.
For API definitions that do not conform to the OpenAPI Specification 3.0, the normative statement
should be interpreted in the context of the API definition language used.
5.5.4 Paths in OpenAPI definitions
All paths in an OpenAPI definition are relative to a base URL of the server.
EXAMPLE 1 URL of the OpenAPI definition.
If the OpenAPI Server Object looks like this:
servers:
- url: https://dev.example.org/
description: Development server
- url: https://data.example.org/
description: Production server
The path "/mypath" in the OpenAPI definition of a Web API would be the URL https://data.example.
org/mypath for the production server.
5.5.5 Reusable OpenAPI components
Reusable components for OpenAPI definitions for implementations of OGC API Features are referenced
from this document.
6 Overview
6.1 Design considerations
While this is the first version of the OGC API Features series, the fine-grained access to features over
the Web has been supported by the OGC Web Feature Service (WFS) standard (in ISO: ISO 19142) and
many implementations of that standard for many years. WFS uses a Remote-Procedure-Call-over-HTTP
architectural style using XML for any payloads. When the WFS standard was originally designed in the
late 1990s and early 2000s this was the state-of-the-art.
OGC API Features supports similar capabilities, but uses a modernized approach that follows the
current Web architecture and in particular the W3C/OGC best practices for sharing Spatial Data on the
Web as well as the W3C best practices for sharing Data on the Web.
6 © ISO 2020 – All rights reserved
Beside the general alignment with the architecture of the Web (e.g., consistency with HTTP/HTTPS,
hypermedia controls), another goal for OGC API Features is modularization. This goal has several facets,
as described below.
— Clear separation between core requirements and more advanced capabilities. This document
specifies the core requirements that are relevant for almost everyone who wants to share or use
feature data on a fine-grained level. Additional capabilities that several communities are using
today will be specified as extensions in additional parts of the OGC API Features series.
— Technologies that change more frequently are decoupled and specified in separate modules
("requirements classes" in OGC terminology). This enables, for example, the use/re-use of new
encodings for spatial data or API descriptions.
— Modularization is not just about features or resources, but about providing building blocks for fine-
grained access to spatial data that can be used in Web APIs in general. In other words, a server
supporting OGC API Features is not intended to implement just a standalone Features API. A
corollary of this is that the same Web API may also implement other standards of the OGC API
family that support additional resource types; for example, tile resources could provide access to
the same features, but organized in a spatial partitioning system; or map resources could process
the features and render them as map images.
Implementations of OGC API Features are intended to support two different approaches for how clients
can use the API.
In the first approach, clients are implemented with knowledge about this document and its resource
types. The clients navigate the resources based on this knowledge and based on the responses provided
by the API. The API definition may be used to determine details, e.g., on filter parameters, but this may
not be necessary depending on the needs of the client. These are clients that are in general able to use
multiple APIs as long as they implement OGC API Features.
The other approach targets developers that are not familiar with the OGC API standards, but want to
interact with spatial data provided by an API that happens to implement OGC API Features. In this case
the developer studies and uses the API definition, typically an OpenAPI document, to understand the
API and implement the code to interact with the API. This assumes familiarity with the API definition
language and the related tooling, but it should not be necessary to study the OGC API standards.
6.2 Encodings
This document does not mandate any encoding or format for representing features or feature
collections. In addition to rules for HTML, the standard encoding for Web content, rules for commonly
used encodings for spatial data on the Web are provided (GeoJSON, GML).
None of these encodings is mandatory and an implementation of the Core requirements class may
implement none of them but implement another encoding instead.
Support for HTML is recommended as HTML is the core language of the World Wide Web. A server that
supports HTML will support browsing the data with a web browser and will enable search engines to
crawl and index the dataset.
GeoJSON is a commonly used format that is simple to understand and well supported by tools and
software libraries. Since most Web developers are comfortable with using a JSON-based format, this
version of OGC API Features recommends supporting GeoJSON for encoding feature data, if the feature
data can be represented in GeoJSON for the intended use.
Some examples for cases that are out-of-scope of GeoJSON are:
— when solids are used for geometries (e.g., in a 3D city model),
— geometries that include non-linear curve interpolations that cannot be simplified (e.g., use of arcs in
authoritative geometries),
— geometries that have
...
NORME ISO
INTERNATIONALE 19168-1
Première édition
2020-09
Information géographique — API
géospatiale pour les entités —
Partie 1:
Profil minimal
Geographic information — Geospatial API for features —
Part 1: Core
Numéro de référence
©
ISO 2020
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2020
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 2020 – Tous droits réservés
Sommaire Page
Avant-propos .v
Introduction .vi
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes, définitions et abréviations . 1
3.1 Abréviations . 2
4 Conformité . 3
5 Conventions . 4
5.1 Identifiants . 4
5.2 Relations de lien . 4
5.3 Utilisation d’HTTPS . 5
5.4 URI HTTP . 5
5.5 Définition de l'API . 5
5.5.1 Remarques générales . 5
5.5.2 Rôle d'OpenAPI . 5
5.5.3 Références aux composants OpenAPI dans les déclarations normatives . 6
5.5.4 Chemins des définitions d'OpenAPI . 6
5.5.5 Composants OpenAPI réutilisables . 6
6 Vue d'ensemble . 6
6.1 Considérations relatives à la conception . 6
6.2 Encodages. 7
6.3 Exemples . 8
7 Classe d'exigences «Profil minimal» . 9
7.1 Vue d'ensemble . 9
7.2 Page de destination API .10
7.2.1 Fonctionnement.10
7.2.2 Réponse .11
7.2.3 Situations d'erreur .11
7.3 Définition de l'API .12
7.3.1 Fonctionnement.12
7.3.2 Réponse .12
7.3.3 Situations d'erreur .12
7.4 Déclaration de classes de conformité .13
7.4.1 Fonctionnement.13
7.4.2 Réponse .13
7.4.3 Situations d'erreur .13
7.5 HTTP 1.1 .13
7.5.1 Codes de statut HTTP .14
7.6 Paramètres d'interrogation inconnus ou non valides .15
7.7 Mise en cache sur le Web .15
7.8 Prise en charge des requêtes entre origines multiples .15
7.9 Encodages.16
7.10 Internationalisation des chaînes .16
7.11 Systèmes de référence par coordonnées .17
7.12 En-têtes de liens .18
7.13 Collections d'entités .18
7.13.1 Fonctionnement.18
7.13.2 Réponse .18
7.13.3 Situations d'erreur .23
7.14 Collection d'entités .23
7.14.1 Fonctionnement.23
7.14.2 Réponse .23
7.14.3 Situations d'erreur .23
7.15 Entités .23
7.15.1 Fonctionnement.23
7.15.2 Paramètre limit .24
7.15.3 Paramètre bbox .24
7.15.4 Paramètre datetime . .26
7.15.5 Paramètres de filtrage des propriétés d'entités . .27
7.15.6 Combinaisons de paramètres de filtrage .28
7.15.7 Réponse .28
7.15.8 Situations d'erreur .30
7.16 Entité .31
7.16.1 Fonctionnement.31
7.16.2 Réponse .31
7.16.3 Situations d'erreur .31
8 Classes d'exigences pour encodages .32
8.1 Vue d'ensemble .32
8.2 Classe d'exigences «HTML» .32
8.3 Classe d'exigences «GeoJSON».33
8.4 Classe d'exigences «Geography Markup Language (GML), Simple Features Profile,
Level 0» .35
8.5 Classe d'exigences «Geography Markup Language (GML), Simple Features Profile,
Level 2» .36
9 Classe d'exigences "OpenAPI 3.0" .37
9.1 Exigences de base .37
9.2 Définition complète .37
9.3 Exceptions .38
9.4 Sécurité .38
9.5 Entités .38
10 Types de support .38
11 Considérations relatives à la sécurité .39
11.1 Généralités .39
11.2 Routes à accès multiples .40
11.3 Serveurs multiples .40
11.4 Manipulation de chemins sur GET .40
11.5 Manipulation de chemins sur PUT et POST.40
Annexe A (normative) Suite d'essais abstraits .42
Bibliographie .56
iv © ISO 2020 – Tous droits réservés
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. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (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 présent 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 www .iso .org/ avant -propos.
Le présent document a été élaboré par le comité technique ISO/TC 211, Information géographique/
Géomatique.
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.
Introduction
[9]
Les standards OGC API définissent les modules de construction de l'API pour activer spatialement les
API Web de manière cohérente. La spécification OpenAPI permet de définir les modules de construction
de l'API.
La famille de spécifications OpenAPI est organisée par type de ressource. Le présent document spécifie
les modules de construction fondamentaux de l'API pour 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 and Geometry des W3C/OGC Spatial Data dans le document Web Best Practice donnent de
plus amples informations.
OGC API Features donne des modules de construction de l'API pour créer, modifier et interroger les
entités sur le Web. OGC API Features est constitué de parties multiples, chacune d'entre elles étant
un standard distinct. Ce document, le «Profil minimal», spécifie les capacités essentielles et se limite
à la récupération d'entités où les géométries sont représentées dans le système de référence de
coordonnées, WGS 84, avec l'ordre des axes longitude/latitude. Des capacités supplémentaires couvrant
des besoins plus complexes seront spécifiées dans des parties supplémentaires. À titre d'exemple, on
peut citer les aides à la création et à la modification d'entités, des modèles de données plus complexes,
des interrogations plus riches, des systèmes de référence de coordonnées supplémentaires, des jeux de
données multiples et des hiérarchies de collections.
Par défaut, chaque API exécutant ce 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 modules 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 l'IETF HTTP/HTTPS RFCs,
W3C Data on the Web Best Practices, W3C/OGC Spatial Data on the Web Best Practices et 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.
Le présent document définit les opérations de découverte et d'interrogation implémentées au moyen
de la méthode HTTP GET. Un soutien pour des méthodes supplémentaires (en particulier POST, PUT,
DELETE, PATCH) sera spécifié dans des parties supplémentaires.
Les opérations de découverte permettent aux clients d'interroger l'API, y compris la définition et
les métadonnées de l'API concernant les collections d'entités fournies par l'API, pour déterminer
les capacités de l'API et extraire des informations relatives aux distributions disponibles de jeux de
données.
Les opérations d'interrogation permettent aux clients d'extraire des entités du système sous-jacent de
stockage de données sur la base de critères de sélection simples définis par le client.
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-1. 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 standards de la série «OGC API» sont publiées par l'ISO sous forme
de «API géo-spatiale» c'est-à-dire que le titre de ce document dans l'OGC est «OGC API — Features —
Part 1: Core» et le titre dans l'ISO est «Information géographique — API géo-spatiale pour les entités —
Partie 1: Profil minimal».
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éo-spatiales qui est publié dans
l'ISO comme «API géo-spatiale»;
vi © ISO 2020 – Tous droits réservés
— «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éo-spatiale pour entités»;
— «OGC API — Features — Part 1: Core» (profil minimal) pour faire référence au présent document
qui est publié dans l'ISO comme ISO 19168-1 / «Information géographique — API géo-spatiale pour
les entités — Partie 1: Profil minimal».
Le présent document définit les ressources répertoriées dans le Tableau 1. Pour une vue d'ensemble des
ressources, voir 7.1.
Tableau 1 — Vue d'ensemble des ressources, méthodes HTTP applicables et liens vers
les sections du document
méthode
Ressource Chemin Référence du document
HTTP
Page de destination / GET 7.2 Page de destination API
Déclaration de /conformance GET 7.4 Déclaration de classes de
conformité conformité
Collections d'entités /collections GET 7.13 Collections d'entités
Collection d'entités /collections/{collectionId} GET 7.14 Collection d'entités
Entités /collections/{collectionId}/items GET 7.15 Entités
Entité /collections/{collectionId}/items/ GET 7.16 Entité
{featureId}
L'implémentation d'OGC API Features est destinée à guider deux démarches différentes d'utilisation de
l'API par les clients. Voir 6.1 pour plus d'informations.
NORME INTERNATIONALE ISO 19168-1:2020(F)
Information géographique — API géospatiale pour les
entités —
Partie 1:
Profil minimal
1 Domaine d'application
Le présent document spécifie le comportement des API Web donnant accès aux entités d'un jeu de
données indépendamment du système sous-jacent de stockage de données. Le présent document définit
les opérations de découverte et d'interrogation.
Les opérations de découverte permettent aux clients d'interroger l'API, y compris la définition et
les métadonnées de l'API concernant les collections d'entités fournies par l'API, pour déterminer
les capacités de l'API et extraire des informations relatives aux distributions disponibles de jeux de
données.
Les opérations d'interrogation permettent aux clients d'extraire des entités du système sous-jacent de
stockage de données sur la base de critères de sélection simples définis par le client.
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).
Internet Engineering Task Force (IETF). RFC 2818: HTTP Over TLS [en ligne]. Edited by E. Rescorla.
2000 [consulté le 16/03/2020]. Disponible à l'adresse https:// tools .ietf .org/ rfc/ rfc2818 .txt
Internet Engineering Task Force (IETF). RFC 3339:2002: Date et heure sur Internet:
Timestamps [en ligne]. Edited by G. Klyne, C. Newman. 2002 [consulté le 16/03/2020]. Disponible à
l'adresse https:// tools .ietf .org/ rfc/ rfc3339 .txt
Internet Engineering Task Force (IETF). RFC 7230 à RFC 7235: HTTP/1.1 [en ligne]. Edited by R.
Fielding, J. Reschke, Y. Lafon, M. Nottingham. 2014 [consulté le 28/04/2020]. Disponible aux adresses
https:// tools .ietf .org/ rfc/ rfc7230 .txt, https:// tools .ietf .org/ rfc/ rfc7231 .txt, https:// tools .ietf .org/ rfc/
rfc7232 .txt, https:// tools .ietf .org/ rfc/ rfc7233 .txt, https:// tools .ietf .org/ rfc/ rfc7234 .txt, et https:// tools
.ietf .org/ rfc/ rfc7235 .txt
Internet Engineering Task Force (IETF). RFC 8288:2017: Web Linking [en ligne]. Edited by M.
Nottingham. 2017 [consulté le 16/03/2020]. Disponible à l'adresse https:// tools .ietf .org/ rfc/ rfc8288 .txt
OpenAPI Initiative (OAI). OpenAPI Specification 3.0 [en ligne]. 2020 [consulté le 16/03/2020]. La
dernière version de correctif au moment de la publication de la présente norme était 3.0.3, disponible à
l'adresse https:// spec .openapis .org/ oas/ v3 .0 .3
3 Termes, définitions et abréviations
Pour les besoins du présent document, les termes et définitions 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 http:// www .electropedia .org/
3.1.1
jeu de données
collection de données
Note 1 à l'article: Publié ou édité par un agent unique, et disponible pour accès ou téléchargement dans un ou
plusieurs formats.
Note 2 à l'article: Le terme «collection» dans la définition de DCAT est utilisé dans un sens plus large que dans le
présent document. Voir la définition de collection d'entités (3.1.4).
[8]
[SOURCE: DCAT , 6.6, modifié — Définition partagée entre la définition et la Note 1 à l'article; la Note 2
à l'article a été ajoutée]
3.1.2
distribution
représentation spécifique d'un jeu de données (3.1.1)
EXEMPLE Fichier téléchargeable, fil RSS ou API.
[8]
[SOURCE: DCAT , 6.7, modifiée — La définition a été abrégée]
3.1.3
entité
abstraction d'un phénomène du monde réel
Note 1 à l'article: les explications concernant Spatial Things, Features et 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.1.4
collection d'entités
collection
ensemble d'entités (3.1.3) provenant d'un jeu de données (3.1.1)
3.1.5
API Web
API utilisant un style d'architecture basé sur les technologies du Web
Note 1 à l'article: Bonne pratique 24: Utiliser des normes du Web comme base d'API dans les Données W3C; Web
[7]
Best Practices donne de plus amples informations.
[7]
[SOURCE: DWBP , 8.10.1, modifié — Reformulé par souci de clarté]
3.1 Abréviations
API Interface de programmation d'applications (Application Programming Interface)
CORS Partage de ressources entre origines multiples (Cross-Origin Resource Sharing)
CRS Système de coordonnées de référence (Coordinate Reference System)
HTTP Protocole de transfert hypertexte (Hypertext Transfer Protocol)
HTTPS Protocole de transfert hypertexte sécurisé (Hypertext Transfer Protocol (Secure))
IANA Internet Assigned Numbers Authority
OGC Open Geospatial Consortium
2 © ISO 2020 – Tous droits réservés
TRS Système de référence de coordonnées temporel (Temporal Coordinate Reference System)
URI Identificateur de ressource uniforme (Uniform Resource Identifier)
YAML YAML Ain't Markup Language
4 Conformité
Le présent document définit six classes d'exigences/de conformité.
Les cibles de normalisation de toutes les classes de conformité sont les «API Web».
La classe d'exigences principale est:
— Profil minimal.
Le Profil minimal spécifie les exigences que toutes les API Web doivent respecter.
Le Profil minimal n'impose pas d'encodage ou de format spécifique pour représenter les entités
ou collections d'entités. Quatre classes d'exigences dépendent du Profil minimal et spécifient des
représentations pour ces ressources dans des encodages couramment utilisés pour les données
spatiales sur le Web:
— HTML,
— GeoJSON,
— Geography Markup Language (GML), Simple Features Profile, Level 0, et
— Geography Markup Language (GML), Simple Features Profile, Level 2.
Aucun de ces encodages n'est obligatoire, et il peut également être décidé lors de l'implémentation du
Profil minimal de n'en utiliser aucun, mais d'appliquer un encodage différent à la place.
Ceci étant, la classe d'exigences du Profil minimal comprend des recommandations afin de prendre en
charge, dans la mesure du possible, HTML et GeoJSON comme encodages. L'Article 6 (Vue d'ensemble)
comprend un examen des encodages recommandés.
Le Profil minimal n'impose pas d'encodage ou de format pour la définition formelle de l'API non plus.
Une possibilité est offerte par la spécification OpenAPI 3.0 et une classe d'exigences qui a été spécifiée
pour OpenAPI 3.0, qui dépend du Profil minimal:
— spécification OpenAPI 3.0.
De même qu'avec les encodages d'entités, il peut être également décidé lors de l'implémentation d'une
classe d'exigences du Profil minimal d'utiliser d'autres représentations de définition d'API en plus de ou
à la place d'une définition OpenAPI 3.0. Exemples pour définitions d'API de remplacement: OpenAPI 2.0
(Swagger), versions futures de la spécification OpenAPI, un document Capabilities OWS Common 2.0 ou
WSDL.
Le Profil minimal est conçu pour être une API minimale utile pour accès précis en lecture seule à un jeu
de données spatiales où les géométries sont représentées dans le système de référence de coordonnées
WGS 84 avec l'ordre des axes longitude/latitude.
Des capacités supplémentaires, par exemple la prise en charge de transactions, de structures de
données complexes, de requêtes riches, d'autres systèmes de référence de coordonnées, d'abonnement/
notification, et qui renvoient des résultats agrégés, peuvent être spécifiées dans des parties futures de
la série OGC API Features ou sous la forme d’extensions spécifiques du vendeur.
La conformité avec le présent document doit être vérifiée à l'aide de tous les essais concernés spécifiés
à l'Annexe A (normative) du présent document. La structure, les concepts et la méthodologie d'essai, et
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. Le Tableau 2 donne les URL de
classes de conformité.
Tableau 2 — URL de classes de conformité
Classe de conformité URI
Profil minimal http:// www .opengis .net/ spec/ ogcapi -features -1/ 1 .0/ conf/ core
HTML http:// www .opengis .net/ spec/ ogcapi -features -1/ 1 .0/ conf/ html
GeoJSON http:// www .opengis .net/ spec/ ogcapi -features -1/ 1 .0/ conf/ geojson
GML, Simple Features Profile, Level 0 http:// www .opengis .net/ spec/ ogcapi -features -1/ 1 .0/ conf/ gmlsf0
GML, Simple Features Profile, Level 2 http:// www .opengis .net/ spec/ ogcapi -features -1/ 1 .0/ conf/ gmlsf2
OpenAPI Specification 3.0 http:// www .opengis .net/ spec/ ogcapi -features -1/ 1 .0/ conf/ oas30
5 Conventions
5.1 Identifiants
Les dispositions normatives du présent document sont indiquées par l‘URI http://www.opengis.net/
spec/ogcapi-features-1/1.0.
Toutes les exigences et tous les essais de conformité qui apparaissent dans le présent document sont
désignés par des URI partiels qui se réfèrent à cette base.
5.2 Relations de lien
La RFC 8288 (Web Linking) est utilisé pour exprimer les relations entre les ressources.
[3]
Les types suivants de relation de lien enregistrés sont utilisés dans le présent document.
— alternate: Désigne un remplacement pour ce contexte.
— collection: L'IRI cible mène à une ressource qui représente la ressource de collection pour l'IRI de
contexte.
— describedby: Désigne une ressource donnant des informations à propos du contexte du lien.
— item: L'IRI cible mène à une ressource qui est un membre de la collection représentée par l'IRI de
contexte.
— next: Indique que le contexte du lien fait partie d'une série, et que le suivant dans la série est la cible
du lien.
— license: Désigne une licence associée à ce contexte.
— prev: Indique que le contexte du lien fait partie d'une série, et que le précédent dans la série est la
cible du lien.
— Cette relation n'est utilisée que dans les exemples.
— self: Précise un identifiant pour le contexte du lien.
— service-desc: Identifie une description de service pour le contexte qui est principalement destinée
à la consommation par des machines.
— Les définitions des API sont considérées comme des descriptions de service.
— service-doc: Identifie la documentation de service pour le contexte qui est principalement destinée
à la consommation par des êtres humains.
4 © ISO 2020 – Tous droits réservés
En outre, les types de relation de lien suivants sont utilisés dans les cas où aucun type de relation de
lien enregistré applicable n'a pu être identifié.
— items: Désigne une ressource constituée de membres de la collection représentée par le contexte du
lien.
— conformance: Désigne une ressource qui identifie les spécifications auxquelles le contexte du lien
est conforme.
— data: Désigne la ressource racine d'un jeu de données dans une API.
Chaque représentation de ressource comprend un tableau de liens. Les implémentations ont la faculté
d'ajouter des liens supplémentaires pour toutes les ressources fournies par l'API. Par exemple, un lien
enclosure pourrait désigner le téléchargement en vrac d'une collection. Ou un lien related sur une
entité pourrait désigner une entité associée.
5.3 Utilisation d’HTTPS
Pour des raisons de simplicité, le présent document ne fait généralement référence qu'au protocole
HTTP. Ceci ne revient pas à exclure l'utilisation d’HTTPS, mais n'est qu'une manière abrégée de désigner
«HTTP ou HTTPS». En fait, la plupart des serveurs sont censés utiliser HTTPS, et non HTTP.
5.4 URI HTTP
Le présent document ne limite pas l'espace lexical des URI utilisés dans l'API au-delà des exigences
de lu HTTP et de la Syntaxe URI IETF RFC. Si les URI comprennent des caractères réservés qui sont
des délimiteurs dans le sous-composant URI, ceux-ci doivent être codés par encodage-pourcent. Voir
[2]
RFC 3986:2005, Article 2 pour plus de détails.
5.5 Définition de l'API
5.5.1 Remarques générales
Une documentation de qualité est essentielle pour chaque API afin que les développeurs puissent
apprendre plus facilement à utiliser l'API. Dans le meilleur des cas, la documentation sera disponible en
HTML et dans un format pouvant être traité par un logiciel pour se connecter à l'API.
Le présent document spécifie des exigences et des recommandations pour les API ayant des données
d'entités en commun et qui désirent suivre une démarche normalisée dans ce but. En général, les API
s'étendront au-delà des exigences et des recommandations stipulées dans le présent document, ou
d'autres parties de la série de standards OGC API, et prendront en charge des opérations, paramètres,
etc. supplémentaires spécifiques à l'API ou à l'outil logiciel utilisé pour implémenter l'API.
5.5.2 Rôle d'OpenAPI
Le présent document utilise des fragments d'OpenAPI 3.0 comme exemples, et pour énoncer formellement
les exigences. L'utilisation d'OpenAPI 3.0 n'est toutefois pas nécessaire pour l'implémentation d'un
serveur.
En conséquence, pour la classe d'exigences de Profil minimal, il suffit qu'une définition d'API soit fournie
avec un lien à partir de la page de destination.
Une classe d'exigences séparée est spécifiée pour les définitions d'API conformes à la spécification
OpenAPI 3.0. Ceci n'empêche pas qu'à l'avenir, ou en parallèle, d'autres versions d'OpenAPI ou autres
descriptions d'API soient fournies par un serveur.
NOTE Cette démarche est utilisée pour éviter la dépendance vis-à-vis d'une démarche spécifique de
définition d'une API, étant donné qu'il est prévu que le paysage API continuera à évoluer.
Dans le présent document, des fragments des définitions OpenAPI sont présentés en YAML (YAML Ain't
[1]
Markup Language) , puisque YAML est plus facile à lire que JSON et est généralement utilisé dans les
éditeurs OpenAPI. YAML est décrit par ses auteurs comme une norme de sérialisation de données facile
à utiliser pour tous les langages de programmation.
5.5.3 Références aux composants OpenAPI dans les déclarations normatives
Certaines déclarations normatives (exigences, recommandations et permissions) utilisent une phrase
selon laquelle un composant dans la définition de l'API du serveur doit être «basé sur» un schéma ou un
composant de paramètre dans l'entrepôt de schéma de l'OGC.
Dans ce cas, il est permis d'apporter les modifications suivantes au composant OpenAPI prédéfini.
— Si le serveur prend en charge un encodage XML, les propriétés xml peuvent être ajoutées aux
composants de schéma OpenAPI concerné.
— La plage de valeur d'un paramètre ou d'une propriété peut être étendue (valeurs supplémentaires)
ou restreinte (si un sous-ensemble de toutes les valeurs possible est applicable au serveur). Un
exemple pour une plage de valeurs restreinte est de spécifier explicitement les valeurs prises en
compte d'un paramètre chaîne ou d'une propriété à l'aide d'une énumération électronique.
— La valeur par défaut d'un paramètre peut être modifiée ou ajoutée, sauf interdiction expresse dans
une exigence.
— Des propriétés supplémentaires peuvent être ajoutées à la définition de schéma d'un Objet Réponse.
— Un texte informatif peut être modifié ou ajouté, par exemple avec des propriétés de commentaires
ou description.
Pour les définitions non conformes à la Spécification OpenAPI 3.0, il convient que la déclaration
normative soit interprétée dans le contexte du langage de la définition API utilisée.
5.5.4 Chemins des définitions d'OpenAPI
Tous les chemins d'une définition d'OpenAPI se réfèrent à l'URL de base du serveur.
EXEMPLE 1 URL de la définition d'OpenAPI.
Si l'élément OpenAPI Serverest semblable à:
servers:
- url: https://dev.example.org/
description: Development server
- url: https://data.example.org/
description: Production server
Le chemin «/mypath» dans la définition d'OpenAPI d'une API Web serait l'URL https://data.example.
org/mypath pour le serveur de production.
5.5.5 Composants OpenAPI réutilisables
Les composants réutilisables pour les définitions d'OpenAPI d'implémentation de OGC API Features
sont référencés à partir de ce document.
6 Vue d'ensemble
6.1 Considérations relatives à la conception
Même s'il s'agit de la première version de la série OGC API Features, l'accès précis à des entités sur le
Web a été pris en compte par le standardWeb Feature Service (WFS) de l'OGC (dans l'ISO: ISO 19142)
et plusieurs applications de cette norme pendant de nombreuses années. Le WFS utilise un style
6 © ISO 2020 – Tous droits réservés
d'architecture Remote-Procedure-Call-over-HTTP (appel de procédure à distance sur HTTP) au
moyen de XML pour tout le contenu de la réponse. Lorsque le standardWFS a été élaborée à la fin des
années 1990 et au début des années 2000, il s'agissait d'une technologie de pointe.
L'OGC API Features est compatible avec des capacités similaires, mais utilise une démarche modernisée
conforme à l'architecture Web actuelle, et en particulier les bonnes pratiques W3C/OGC pour le partage
de données spatiales sur le Web, ainsi que les bonnes pratiques W3C pour le partage de données sur le
Web.
Outre l'alignement général sur l'architecture du Web (par exemple cohérence avec HTTP/HTTPS,
commandes hypermédia), un autre but de OGC API Features est la modularisation. Ce but comporte
plusieurs aspects, décrits ci-dessous.
— Une séparation nette entre les classes d'exigences de Profil minimal et des capacités plus avancées.
Le présent document spécifie les exigences de Profil minimal qui s'appliquent à presque tous ceux qui
veulent partager ou utiliser les données d'entités finement définies. Des capacités supplémentaires
actuellement utilisées par plusieurs communautés seront spéc
...
2020-09
ISO/TC 211
Date : 2020-09
ISO/TC 211
Secrétariat : SIS
Information géographique — API géo-spatialegéospatiale pour les entités —
Partie 1 : : Profil minimal
Geographic Information — Geospatial API for features — Part 1: Core
ICS : 35.240.70
Type du document: Norme internationale
Sous-type du document:
Stade du document: (60) Publication
Langue du document: F
Type du document: Norme internationale
Sous-type du document:
Stade du document: (60) Publication
Langue du document: F
DOCUMENT PROTÉGÉ PAR COPYRIGHT
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, 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
CP 401 •• Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél. :.: + 41 22 749 01 11
Fax : + 41 22 749 09 47
E-mail : copyright@iso.org
Web : www.iso.org
www.iso.org
Publié en Suisse
iv
Sommaire Page
v
Sommaire Page
Avant-propos . 10
Introduction . 11
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes, définitions et abréviations . 1
3.1 Abréviations . 2
4 Conformité . 2
5 Conventions . 4
5.1 Identifiants . 4
5.2 Relations de lien . 4
5.3 Utilisation d’HTTPS . 5
5.4 URI HTTP . 5
5.5 Définition de l'API . 5
5.5.1 Remarques générales . 5
5.5.2 Rôle d'OpenAPI . 5
5.5.3 Références aux composants OpenAPI dans les déclarations normatives . 6
5.5.4 Chemins des définitions d'OpenAPI . 6
5.5.5 Composants OpenAPI réutilisables . 7
6 Vue d'ensemble . 7
6.1 Considérations relatives à la conception . 7
6.2 Encodages . 8
6.3 Exemples . 9
7 Classe d'exigences « Profil minimal » . 9
7.1 Vue d'ensemble . 9
7.2 Page de destination API . 11
7.2.1 Fonctionnement . 11
7.2.2 Réponse . 12
7.2.3 Situations d'erreur . 12
7.3 Définition de l'API . 13
7.3.1 Fonctionnement . 13
7.3.2 Réponse . 13
7.3.3 Situations d'erreur . 13
7.4 Déclaration de classes de conformité . 14
7.4.1 Fonctionnement . 14
7.4.2 Réponse . 14
7.4.3 Situations d'erreur . 15
7.5 HTTP 1.1 . 15
7.5.1 Codes de statut HTTP . 15
7.6 Paramètres d'interrogation inconnus ou non valides . 16
7.7 Mise en cache sur le Web . 17
7.8 Prise en charge des requêtes entre origines multiples . 17
7.9 Encodages . 17
7.10 Internationalisation des chaînes . 18
vi
7.11 Systèmes de référence par coordonnées . 19
7.12 En-têtes de liens . 20
7.13 Collections d'entités . 20
7.13.1 Fonctionnement . 20
7.13.2 Réponse . 20
7.13.3 Situations d'erreur . 26
7.14 Collection d'entités . 26
7.14.1 Fonctionnement . 26
7.14.2 Réponse . 26
7.14.3 Situations d'erreur . 27
7.15 Entités . 27
7.15.1 Fonctionnement . 27
7.15.2 Paramètre limit . 27
7.15.3 Paramètre bbox . 28
7.15.4 Paramètre datetime . 30
7.15.5 Paramètres de filtrage des propriétés d'entités . 32
7.15.6 Combinaisons de paramètres de filtrage . 34
7.15.7 Réponse . 34
7.15.8 Situations d'erreur . 38
7.16 Entité . 38
7.16.1 Fonctionnement . 38
7.16.2 Réponse . 38
7.16.3 Situations d'erreur . 39
8 Classes d'exigences pour encodages . 39
8.1 Vue d'ensemble . 39
8.2 Classe d'exigences « HTML » . 40
8.3 Classe d'exigences « GeoJSON » . 41
8.4 Classe d'exigences « Geography Markup Language (GML), Simple Features Profile,
Level 0 » . 43
8.5 Classe d'exigences « Geography Markup Language (GML), Simple Features Profile,
Level 2 » . 45
9 Classe d'exigences "OpenAPI 3.0" . 46
9.1 Exigences de base . 46
9.2 Définition complète . 47
9.3 Exceptions . 47
9.4 Sécurité . 48
9.5 Entités . 48
10 Types de support . 48
11 Considérations relatives à la sécurité . 49
11.1 Généralités . 49
11.2 Routes à accès multiples . 50
11.3 Serveurs multiples . 50
11.4 Manipulation de chemins sur GET . 50
11.5 Manipulation de chemins sur PUT et POST . 51
Annexe A (normative) Suite d'essais abstraits . 52
Bibliographie . 70
Avant-propos . 10
Introduction . 11
1 Domaine d'application . 1
vii
2 Références normatives . 1
3 Termes, définitions et abréviations . 1
3.1 Abréviations . 2
4 Conformité . 2
5 Conventions . 4
5.1 Identifiants . 4
5.2 Relations de lien . 4
5.3 Utilisation d’HTTPS . 5
5.4 URI HTTP . 5
5.5 Définition de l'API . 5
5.5.1 Remarques générales . 5
5.5.2 Rôle d'OpenAPI . 5
5.5.3 Références aux composants OpenAPI dans les déclarations normatives . 6
5.5.4 Chemins des définitions d'OpenAPI . 6
5.5.5 Composants OpenAPI réutilisables . 7
6 Vue d'ensemble . 7
6.1 Considérations relatives à la conception . 7
6.2 Encodages . 8
6.3 Exemples . 9
7 Classe d'exigences «Profil minimal» . 9
7.1 Vue d'ensemble . 9
7.2 Page de destination API . 11
7.2.1 Fonctionnement . 11
7.2.2 Réponse . 12
7.2.3 Situations d'erreur . 12
7.3 Définition de l'API . 13
7.3.1 Fonctionnement . 13
7.3.2 Réponse . 13
7.3.3 Situations d'erreur . 13
7.4 Déclaration de classes de conformité . 14
7.4.1 Fonctionnement . 14
7.4.2 Réponse . 14
7.4.3 Situations d'erreur . 15
7.5 HTTP 1.1 . 15
7.5.1 Codes de statut HTTP . 15
7.6 Paramètres d'interrogation inconnus ou non valides . 16
7.7 Mise en cache sur le Web . 17
7.8 Prise en charge des requêtes entre origines multiples . 17
7.9 Encodages . 17
7.10 Internationalisation des chaînes . 18
7.11 Systèmes de référence par coordonnées . 19
7.12 En-têtes de liens . 20
7.13 Collections d'entités . 20
7.13.1 Fonctionnement . 20
7.13.2 Réponse . 20
7.13.3 Situations d'erreur . 26
7.14 Collection d'entités . 26
7.14.1 Fonctionnement . 26
7.14.2 Réponse . 26
7.14.3 Situations d'erreur . 27
viii
7.15 Entités . 27
7.15.1 Fonctionnement . 27
7.15.2 Paramètre limit . 27
7.15.3 Paramètre bbox . 28
7.15.4 Paramètre datetime . 30
7.15.5 Paramètres de filtrage des propriétés d'entités . 32
7.15.6 Combinaisons de paramètres de filtrage . 34
7.15.7 Réponse . 34
7.15.8 Situations d'erreur . 38
7.16 Entité . 38
7.16.1 Fonctionnement . 38
7.16.2 Réponse . 38
7.16.3 Situations d'erreur . 39
8 Classes d'exigences pour encodages . 39
8.1 Vue d'ensemble . 39
8.2 Classe d'exigences «HTML» . 40
8.3 Classe d'exigences «GeoJSON» . 41
8.4 Classe d'exigences «Geography Markup Language (GML), Simple Features Profile,
Level 0» . 43
8.5 Classe d'exigences «Geography Markup Language (GML), Simple Features Profile,
Level 2» . 45
9 Classe d'exigences "OpenAPI 3.0" . 46
9.1 Exigences de base . 46
9.2 Définition complète . 47
9.3 Exceptions . 47
9.4 Sécurité . 48
9.5 Entités . 48
10 Types de support . 48
11 Considérations relatives à la sécurité . 49
11.1 Généralités . 49
11.2 Routes à accès multiples . 50
11.3 Serveurs multiples . 50
11.4 Manipulation de chemins sur GET . 50
11.5 Manipulation de chemins sur PUT et POST . 51
Annexe A (normative) Suite d'essais abstraits . 52
Bibliographie . 70
ix
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. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2
(voir www.iso.org/directiveswww.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 présent 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 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-
proposwww.iso.org/avant-propos.
Le présent document a été élaboré par le comité technique ISO/TC 211, Information
géographique/Géomatique.
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.htmlwww.iso.org/fr/members.html.
x
Introduction
[9]
Les standards OGC API définissent les modules de construction de l'API pour activer spatialement les
API Web de manière cohérente. La spécification OpenAPI permet de définir les modules de construction
de l'API.
La famille de spécifications OpenAPI est organisée par type de ressource. Le présent document spécifie
les modules de construction fondamentaux de l'API pour 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 and Geometry des W3C/OGC Spatial Data dans le document Web Best Practice donnent de
plus amples informations.
OGC API Features donne des modules de construction de l'API pour créer, modifier et interroger les
entités sur le Web. OGC API Features est constitué de parties multiples, chacune d'entre elles étant un
standard distinct. Ce document, le « Profil minimal », spécifie les capacités essentielles et se limite à la
récupération d'entités où les géométries sont représentées dans le système de référence de
coordonnées, WGS 84, avec l'ordre des axes longitude/latitude. Des capacités supplémentaires couvrant
des besoins plus complexes seront spécifiées dans des parties supplémentaires. À titre d'exemple, on
peut citer les aides à la création et à la modification d'entités, des modèles de données plus complexes,
des interrogations plus riches, des systèmes de référence de coordonnées supplémentaires, des jeux de
données multiples et des hiérarchies de collections.
Par défaut, chaque API exécutant ce 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 modules 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 l'IETF HTTP/HTTPS
RFCs, W3C Data on the Web Best Practices, W3C/OGC Spatial Data on the Web Best Practices et 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.
Le présent document définit les opérations de découverte et d'interrogation implémentées au moyen de
la méthode HTTP GET. Un soutien pour des méthodes supplémentaires (en particulier POST, PUT,
DELETE, PATCH) sera spécifié dans des parties supplémentaires.
Les opérations de découverte permettent aux clients d'interroger l'API, y compris la définition et les
métadonnées de l'API concernant les collections d'entités fournies par l'API, pour déterminer les
capacités de l'API et extraire des informations relatives aux distributions disponibles de jeux de
données.
Les opérations d'interrogation permettent aux clients d'extraire des entités du système sous-jacent de
stockage de données sur la base de critères de sélection simples définis par le client.
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-1. 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
xi
dans les titres des normes ISO, les standards de la série « OGC API » sont publiées par l'ISO sous forme
de « API géo-spatiale » c'est-à-dire que le titre de ce document dans l'OGC est « OGC API — Features —
Part 1: Core » et le titre dans l'ISO est « Information géographique — API géo-spatiale pour les
entités — Partie 1 : Profil minimal ».
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éo-spatiales qui est publié dans
l'ISO comme « API géo-spatiale » ;»;
— « 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éo-spatiale pour entités » ;»;
— « OGC API — Features — Part 1: Core » (profil minimal) pour faire référence au présent document
qui est publié dans l'ISO comme ISO 19168-1 / « Information géographique — API géo-spatiale
pour les entités — Partie 1 : Profil minimal ».
Le présent document définit les ressources répertoriées dans le Tableau 1. Pour une vue d'ensemble
des ressources, voir 7.1.
Tableau 1 — Vue d'ensemble des ressources, méthodes HTTP applicables et liens vers
les sections du document
méthode
Ressource Chemin Référence du document
HTTP
Page de destination / GET 7.2 Page de destination API
Déclaration de /conformance GET 7.4 Déclaration de classes de
conformité conformité
Collections d'entités /collections GET 7.13 Collections d'entités
Collection d'entités /collections/{collectionId} GET 7.14 Collection d'entités
Entités /collections/{collectionId}/items GET 7.15 Entités
Entité /collections/{collectionId}/items/{featureId GET 7.16 Entité
}
L'implémentation d'OGC API Features est destinée à guider deux démarches différentes d'utilisation de
l'API par les clients. Voir 6.1 pour plus d'informations.
xii
NORME INTERNATIONALE ISO 19168-1:2020(F)
Information géographique — API géo-spatialegéospatiale pour
les entités — Partie 1 : : Profil minimal
1 Domaine d'application
Le présent document spécifie le comportement des API Web donnant accès aux entités d'un jeu de
données indépendamment du système sous-jacent de stockage de données. Le présent document définit
les opérations de découverte et d'interrogation.
Les opérations de découverte permettent aux clients d'interroger l'API, y compris la définition et les
métadonnées de l'API concernant les collections d'entités fournies par l'API, pour déterminer les
capacités de l'API et extraire des informations relatives aux distributions disponibles de jeux de
données.
Les opérations d'interrogation permettent aux clients d'extraire des entités du système sous-jacent de
stockage de données sur la base de critères de sélection simples définis par le client.
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).
INTERNET ENGINEERING TASK FORCE (IETF). RFC 2818 : HTTP Over TLS [en ligne]. Edited by E. Rescorla.
2000 [consulté le 16/03/2020]. Disponible à
l'adresse https://tools.ietf.org/rfc/rfc2818.txthttps://tools.ietf.org/rfc/rfc2818.txt
INTERNET ENGINEERING TASK FORCE (IETF). RFC 3339:2002 : Date et heure sur Internet :
Timestamps [en ligne]. Edited by G. Klyne, C. Newman. 2002 [consulté le 16/03/2020]. Disponible à
l'adresse https://tools.ietf.org/rfc/rfc3339.txthttps://tools.ietf.org/rfc/rfc3339.txt
INTERNET ENGINEERING TASK FORCE (IETF). RFC 7230 à RFC 7235: HTTP/1.1 [en ligne]. Edited by R.
Fielding, J. Reschke, Y. Lafon, M. Nottingham. 2014 [consulté le 28/04/2020]. Disponible aux adresses
https://tools.ietf.org/rfc/rfc7230.txt, https://tools.ietf.org/rfc/rfc7231.txt,
https://tools.ietf.org/rfc/rfc7232.txt, https://tools.ietf.org/rfc/rfc7233.txt,
https://tools.ietf.org/rfc/rfc7234.txt, et
https://tools.ietf.org/rfc/rfc7235.txthttps://tools.ietf.org/rfc/rfc7230.txt,
https://tools.ietf.org/rfc/rfc7231.txt, https://tools.ietf.org/rfc/rfc7232.txt,
https://tools.ietf.org/rfc/rfc7233.txt, https://tools.ietf.org/rfc/rfc7234.txt, et
https://tools.ietf.org/rfc/rfc7235.txt
INTERNET ENGINEERING TASK FORCE (IETF). RFC 8288:2017 : Web Linking [en ligne]. Edited by M.
Nottingham. 2017 [consulté le 16/03/2020]. Disponible à
l'adresse https://tools.ietf.org/rfc/rfc8288.txthttps://tools.ietf.org/rfc/rfc8288.txt
OPENAPI INITIATIVE (OAI). OpenAPI Specification 3.0 [en ligne]. 2020 [consulté le 16/03/2020]. La
dernière version de correctif au moment de la publication de la présente norme était 3.0.3, disponible à
l'adresse http://spec.openapis.org/oas/v3.0.3https://spec.openapis.org/oas/v3.0.3
2 © ISO 2020 – Tous droits réservés
NORME INTERNATIONALE ISO 19168-1:2020(F)
3 Termes, définitions et abréviations
Pour les besoins du présent document, les termes et définitions 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/obphttps://www.iso.org/obp
— IEC Electropedia : disponible à l'adresse
http://www.electropedia.org/http://www.electropedia.org/
3.1.1
jeu de données
collection de données
Note 1 à l'article : Publié ou édité par un agent unique, et disponible pour accès ou téléchargement dans un ou
plusieurs formats.
Note 2 à l'article : Le terme « collection » dans la définition de DCAT est utilisé dans un sens plus large que dans le
présent document. Voir la définition de collection d'entités (3.1.4).
[8]
[SOURCE : DCAT , 6.6, modifié — Définition partagée entre la définition et la Note 1 à l'article ; la
Note 2 à l'article a été ajoutée]
3.1.2
distribution
représentation spécifique d'un jeu de données (3.1.1)
EXEMPLE Fichier téléchargeable, fil RSS ou API.
[8]
[SOURCE : DCAT , 6.7, modifiée — La définition a été abrégée]
3.1.3
entité
abstraction d'un phénomène du monde réel
Note 1 à l'article : les explications concernant Spatial Things, Features et 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.1.4
collection d'entités
collection
ensemble d'entités (3.1.3) provenant d'un jeu de données (3.1.1)
3.1.5
API Web
API utilisant un style d'architecture basé sur les technologies du Web
Note 1 à l'article : Bonne pratique 24 : Utiliser des normes du Web comme base d'API dans les Données W3C ; Web
[7]
Best Practices donne de plus amples informations.
[7]
[SOURCE : DWBP , 8.10.1, modifié — Reformulé par souci de clarté]
3.1 Abréviations
API Interface de programmation d'applications (Application Programming Interface))
CORS Partage de ressources entre origines multiples (Cross-Origin Resource Sharing)
CRS Système de coordonnées d
...
記事タイトル：ISO 19168-1:2020 - 地理情報-フィーチャのためのジオスペーシャルAPI-パート1：コア 記事内容：この文書は、基礎となるデータストアに依存せずにデータセットのフィーチャにアクセスするためのウェブAPIの振る舞いを規定しています。この文書では、ディスカバリー操作とクエリ操作が定義されています。ディスカバリー操作では、クライアントがAPIに関する情報や提供されるフィーチャコレクションに関するメタデータを取得し、APIの機能やデータセットの利用可能な配布に関する情報を特定することができます。クエリ操作では、クライアントが定義した単純な選択基準に基づいて基礎となるデータストアからフィーチャを取得することができます。
The article discusses ISO 19168-1:2020, which is a specification for geospatial APIs that allow access to features in a dataset. It explains that the document outlines the behavior of these APIs, which are designed to work independently of the underlying data store. The specification covers discovery operations, which allow users to query the API and retrieve information about the API definition and the feature collections it provides. It also includes query operations, which enable users to retrieve features from the dataset based on specific criteria defined by the user.
기사 제목: ISO 19168-1:2020-지리 정보-기능을 위한 지리공간 API-제 1부: 핵심 기사 내용: 이 문서는 기본 데이터 저장소와는 독립적으로 데이터셋의 기능에 접근할 수 있는 웹 API의 동작을 명시합니다. 이 문서는 검색 및 조회 작업을 정의합니다. 검색 작업은 API 정의 및 API가 제공하는 기능 컬렉션에 대한 메타데이터와 함께 API를 조사하여 API의 기능 및 데이터셋의 사용 가능한 분포에 대한 정보를 받아올 수 있게 해줍니다. 조회 작업은 클라이언트가 정의한 간단한 선택 기준에 따라 기본 데이터 저장소에서 기능을 검색할 수 있도록 해줍니다.
이 문서는 기하학적 정보의 특징에 대한 지리 API의 동작을 명시합니다. 이 문서는 API 기능의 파악 및 API에 의해 제공되는 특징 컬렉션에 대한 메타데이터 및 API 정의에 대한 정보를 가져와 사용 가능한 데이터셋 배포에 대한 정보를 얻기 위해 고객이 API를 조사할 수 있는 발견 작업을 정의합니다. 또한, 쿼리 작업을 통해 고객은 클라이언트가 정의한 간단한 선택 기준을 기반으로 기본 데이터 저장소에서 특징을 검색할 수 있습니다.
The article discusses ISO 19168-1:2020, which is a standard that specifies the behavior of Web APIs for accessing geospatial features in a dataset. The standard covers discovery and query operations. Discovery operations allow clients to gather information about the API and the feature collections it provides, while query operations enable clients to retrieve specific features from the dataset based on their selection criteria. The standard aims to create a consistent and independent way of accessing geospatial data.
제목: ISO 19168-1:2020 - 지리정보 - 피처를 위한 지리적 API - 제1부: 핵심 내용: 이 문서는 기반 데이터 저장소와 독립적인 방식으로 데이터셋의 피처에 대한 접근을 제공하는 웹 API의 동작을 명시합니다. 이 문서는 발견(discovery)과 쿼리(query) 작업을 정의합니다. 발견 작업은 클라이언트가 API 정의와 피처 컬렉션에 대한 메타데이터를 포함하여 API를 조회하여 API의 기능과 데이터셋의 이용 가능한 배포에 대한 정보를 얻을 수 있게 합니다. 쿼리 작업은 클라이언트가 정의한 간단한 선택 기준에 따라 기반 데이터 저장소로부터 피처를 검색할 수 있게 합니다.
この記事では、ISO 19168-1:2020について説明しています。これは、データセット内のフィーチャにアクセスするための地理情報APIの動作を指定したものです。この文書では、基礎となるデータストアに依存せずに動作するAPIの機能を定義しています。発見操作により、顧客はAPIとその提供するフィーチャコレクションに関するAPIの定義やメタデータ、データセットの利用可能な分布についての情報を取得できます。クエリ操作により、顧客はクライアントが定義した単純な選択基準に基づいて、基礎データストアからフィーチャを取得することができます。
The article talks about ISO 19168-1:2020, which is a standard that specifies the behavior of Web APIs that allow access to features in a dataset regardless of the underlying data store. It defines two types of operations: discovery operations, which allow clients to gather information about the API and the feature collections it provides, and query operations, which allow clients to retrieve features from the data store based on specific criteria set by the client.
記事のタイトル：ISO 19168-1:2020 - 地理情報 - フィーチャ向けのジオスペーシャルAPI - パート1：コア 記事の内容：この文書は、基礎となるデータストアに依存せずにデータセットのフィーチャにアクセスするためのWeb APIの振る舞いを指定しています。この文書では、発見(discovery)操作とクエリ(query)操作を定義しています。発見操作では、クライアントはAPIの定義やAPIが提供するフィーチャコレクションに関するメタデータを含めてAPIに関する情報やデータセットの利用可能な配布に関する情報を取得できます。クエリ操作では、クライアントは単純な選択基準に基づいてデータストアからフィーチャを取得できます。
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...