ISO 19168-1:2025

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 independently 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: 09-Jan-2025
• ICS: 35.240.70 - IT applications in science
• Technical Committee: ISO/TC 211 - Geographic information/Geomatics
• Drafting Committee: ISO/TC 211 - Geographic information/Geomatics
• Current Stage: 6060 - International Standard published
• Start Date: 10-Jan-2025
• Due Date: 08-Feb-2025
• Completion Date: 10-Jan-2025

Relations

• Consolidates: ISO 13680:2020 - Petroleum and natural gas industries - Corrosion-resistant alloy seamless tubular products for use as casing, tubing, coupling stock and accessory material - Technical delivery conditions
• Effective Date: 18-Feb-2023
• Revises: ISO 19168-1:2020 - Geographic information - Geospatial API for features - Part 1: Core
• Effective Date: 11-Feb-2023

ISO 19168-1:2025 - Geographic information - Geospatial API for features - Part 1: Core

Overview

ISO 19168-1:2025 defines a minimal, interoperable profile for Web APIs that expose geographic "features" from datasets regardless of the underlying data store. The standard specifies the behaviour of discovery and query operations so clients can:

• Discover API capabilities, metadata and available data distributions (API landing page and API definition).
• Query and retrieve features using simple selection criteria supplied by the client.

This second edition (2025) focuses on a core requirements class and references common encodings and API definition tools to promote consistent, discoverable feature APIs.

Key technical topics and requirements

The standard covers practical, implementation-focused topics including:

• API discovery and definition - a standardized landing page and machine-readable API definition (role of OpenAPI) to enable automated client interrogation.
• Query operations - endpoints for feature collections and individual features with parameters for selection (e.g., bounding box (bbox), datetime and property filters).
• Encodings - requirements classes for common encodings such as GeoJSON, HTML, and GML (Simple Features Profiles) to ensure interoperable content formats.
• OpenAPI 3.0 support - guidance and requirements for providing an OpenAPI definition that represents the API’s capabilities.
• HTTP behaviour and web best practices - HTTP/1.1 status codes, use of HTTPS, link headers, caching, cross-origin request support (CORS), and handling unknown/invalid query parameters.
• Conformance and testability - declaration of conformance classes (Core, encoding classes, OpenAPI) and an abstract test suite to verify compliance.
• Internationalization and CRS - provisions for string internationalization and coordinate reference system handling.
• Security considerations - guidance on risks from multiple access routes/servers and path manipulation for HTTP methods.

Practical applications and who should use it

ISO 19168-1:2025 is intended for organizations and professionals building or consuming web feature APIs:

• GIS developers and API designers implementing interoperable feature services.
• National mapping agencies, environmental and urban data providers exposing geospatial features.
• Spatial data infrastructures (SDI) and data portals requiring machine-discoverable APIs.
• Software vendors and integrators building clients, SDKs, or automated tooling based on OpenAPI and GeoJSON/GML.

By following ISO 19168-1, implementers can create consistent, discoverable, and testable geospatial feature APIs that integrate across platforms and toolchains.

Related standards and technologies

• OpenAPI 3.0 (for API definitions)
• GeoJSON and GML (Geography Markup Language) (encodings)
• ISO series on geographic information and web services (context for interoperability)

Standards Content (Sample)

International
Standard
ISO 19168-1
Second edition
Geographic information —
2025-01
Geospatial API for features —
Part 1:
Core
Information géographique — API géospatiale pour les entités —
Partie 1: Profil minimal
Reference number
© ISO 2025
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: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
3.1 Terms and definitions .2
3.2 Abbreviated terms .3
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 . 7
6.1 Design considerations .7
6.2 Encodings .7
6.3 Examples .8
7 Requirements class "Core" . 9
7.1 Overview .9
7.2 API landing page .10
7.2.1 Operation .10
7.2.2 Response . .10
7.2.3 Error situations .11
7.3 API definition .11
7.3.1 Operation .11
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 . 23
7.14 Feature collection .24
7.14.1 Operation .24

iii
7.14.2 Response . .24
7.14.3 Error situations .24
7.15 Features .24
7.15.1 Operation .24
7.15.2 Parameter limit. 25
7.15.3 Parameter bbox . 26
7.15.4 Parameter datetime.27
7.15.5 Parameters for filtering on feature properties . 29
7.15.6 Combinations of filter parameters . 29
7.15.7 Response . . 30
7.15.8 Error situations .32
7.16 Feature .32
7.16.1 Operation .32
7.16.2 Response . . 33
7.16.3 Error situations . 33
8 Requirements classes for encodings .33
8.1 Overview . 33
8.2 Requirements class "HTML" . 34
8.3 Requirements class "GeoJSON" . 34
8.4 Requirements class "Geography Markup Language (GML), Simple Features Profile,
Level 0" . 36
8.5 Requirements class "Geography Markup Language (GML), Simple Features Profile,
Level 2" . 38
9 Requirements class "OpenAPI 3.0" .39
9.1 Basic requirements . 39
9.2 Complete definition . 40
9.3 Exceptions. 40
9.4 Security . 40
9.5 Features . 40
10 Media types. 41
11 Security Considerations . 41
11.1 General .41
11.2 Multiple access routes .42
11.3 Multiple servers .42
11.4 Path manipulation on GET .42
11.5 Path manipulation on PUT and POST .42
Annex A (normative) Abstract test suite .43
Bibliography .59

iv
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 document 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).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
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, in
collaboration with the European Committee for Standardization (CEN) Technical Committee CEN/TC 287
Geographic Information, in accordance with the Agreement on technical cooperation between ISO and CEN
(Vienna Agreement), and in collaboration with the Open Geospatial Consortium (OGC).
This second edition cancels and replaces the first edition (ISO 19168-1:2020), which has been technically
revised.
The main changes are as follows:
— the link schema has been updated to make the "rel" attribute required to align with IETF RFC 8288;
— the bounding box schemas have been updated to require 4 or 6 numbers (2D or 3D);
— the XML Schema core.xsd has been aligned with the corresponding schema for the JSON representation;
— normative references have been updated to reference newer editions (HTTP and OpenAPI);
— the definition of "dataset" has been updated;
— the definitions of the terms "landing page" and "OGC Web API" have been added;
— the IANA link relation type has been corrected to "describedby", rather than "describedBy";
— requirement /req/core/fc-limit-response-1 has been updated to clarify the behaviour if the value of the
"limit" parameter is higher than the maximum value;
— recommendation /rec/core/fc-extent has been added to clarify that the bounding box of a feature collection
response should be the bounding box of a matched feature, not only the features in the current page;
— recommendations /rec/core/fc-md-self-links and /rec/core/sfc-md-links have been added to clarify that
"self" links should be added;
— the value of the "profile" attribute in the GML media type has been modified to be in quotation marks;

v
— a new requirement /req/core/fc-md-extent-multi has been added to clarify that the first bounding box in
a collection extent array contains all other bounding boxes in the array;
— the use of the attributes "spatial"/"temporal" in a collection extent has been clarified;
— it has been clarified that the "itemType" attribute should be included for each collection;
— the interpretation of a degenerated bounding box in the "bbox" parameter has been clarified;
— it has been clarified that a "next" link can return no additional features;
— it has been clarified that the feature identifier is mapped to the "id" attribute in GeoJSON and
"@gml:id" in GML;
— missing test cases have been added;
— some specification URIs have been updated;
— various editorial corrections and updates have been applied in the document.
[13]
NOTE For more details on the changes listed, see the OGC release notes.
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.

vi
Introduction
[10]
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.
ISO has published a subset of the OGC API family of standards. 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." For example, 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 of which certain parts are published
by ISO as the ISO 19168 series/"Geographic Information — Geospatial API for Features"; and
— "this document" to refer to "OGC API - Features - Part 1: Core", which is published by ISO as
ISO 19168-1/"Geographic Information — Geospatial API for Features — Part 1: Core".
OGC API is organized by resource type. OGC API - Features 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.
NOTE For those not familiar with the term "feature," the explanations on Spatial Things, Features and Geometry in
[7]
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. The
series is comprised of multiple parts, each of them a separate standard. This document (ISO 19168-1), which
corresponds to one such part, the "Core", specifies the core capabilities and is restricted to fetching features
where geometries are represented in the coordinate reference system (CRS) 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 CRS, 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, OGC API - Features offers 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
[8] [7]
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
[9]
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) is 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.
This document defines the resources listed in Table 1. For an overview of the resources, see 7.1.

vii
Table 1 — Overview of resources, applicable HTTP methods and links to the document sections
Resource Path HTTP Subclause
method
Landing page / GET 7.2 API landing page
Conformance /conformance GET 7.4 Declaration of conformance
declaration classes
Feature collec- /collections GET 7.13 Feature collections
tions
Feature collec- /collections/{collectionId} GET 7.14 Feature collection
tion
Features /collections/{collectionId}/items GET 7.15 Features
Feature /collections/{collectionId}/items/{featureId} GET 7.16 Feature

viii
International Standard ISO 19168-1:2025(en)
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 independently
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.
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 https:// spec .openapis .org/ oas/ v3 .0 .3
Internet Engineering Task Force (IETF), RFC 2818: HTTP Over TLS [online]. Edited by E. Rescorla. 2000
[viewed 2020-03-16]. Available at https:// www .rfc -editor .org/ rfc/ rfc2818 .html
Internet Engineering Task Force (IETF), RFC 3339: Date and Time on the Internet: Timestamps [online].
Edited by G. Klyne, C. Newman. 2002 [viewed 2020-03-16]. Available at https:// www .rfc -editor .org/ rfc/
rfc3339 .html
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:// www .rfc -editor .org/
rfc/ rfc7230 .html, https:// www .rfc -editor .org/ rfc/ rfc7231 .html, https:// www .rfc -editor .org/ rfc/ rfc7232
.html, https:// www .rfc -editor .org/ rfc/ rfc7233 .html, https:// www .rfc -editor .org/ rfc/ rfc7234 .html,
and https:// www .rfc -editor .org/ rfc/ rfc7235 .html
Internet Engineering Task Force (IETF), RFC 8288: Web Linking [online]. Edited by M. Nottingham. 2017
[viewed 2020-03-16]. Available at https:// www .rfc -editor .org/ rfc/ rfc8288 .html
Open Geospatial Consortium (OGC), OGC 10-100r3: Geography Markup Language (GML) Simple Features
Profile [online]. Edited by L. van den Brink, C. Portele, P. Vretanos. 2012 [viewed 2020-03-16]. Available
at http:// portal .opengeospatial .org/ files/ ?artifact _id = 42729
Internet Engineering Task Force (IETF). RFC 7946: The GeoJSON Format [online]. Edited by H. Butler, M.
Daly, A. Doyle, S. Gillies, S. Hagen, T. Schaub. 2016 [viewed 2020-03-16]. Available at https:// www .rfc -editor
.org/ rfc/ rfc7946 .html
WHATWG. HTML, Living Standard [online, viewed 2020-03-16]. Available at https:// html .spec .whatwg .org/
schema.org. Schema.org [online, viewed 2020-03-16]. Available at https:// schema .org/ docs/ schemas .html

3 Terms and definitions
For the purposes of this document, the following terms and definitions 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/
3.1 Terms and definitions
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
serializations or formats.
Note 2 to entry: The use of "collection" in this definition is broader than the use of the term collection throughout the
rest of this document. See the definition of "feature collection."
[9]
[SOURCE: DCAT, 6.6, modified — Definition has been 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.
[9]
[SOURCE: DCAT, 6.7, modified — Definition has been shortened.]
3.1.3
feature
abstraction of real-world phenomena
Note 1 to entry: Further details about the term "feature" can be found in Reference [7].
[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
resource
entity that might be identified
Note 1 to entry: The term "resource", when used in the context of an OGC API standard, means a web resource (3.1.7)
unless otherwise indicated.
[SOURCE: ISO 15836-2:2019, 3.1.10, modified — Notes 1 and 2 have been removed and replaced with a new
Note 1 to entry.]
3.1.6
Web API
API using an architectural style that is founded on the technologies of the Web
Note 1 to entry: See Reference [8] for further detail.
Note 2 to entry: Definition adapted from Reference [8], 8.10.1. Modified by being rephrased for clarity.

3.1.7
web resource
resource (3.1.5) that is identified by a HTTP URI
3.2 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
IRI internationalized resource identifier
OGC Open Geospatial Consortium
RFC request for comment
TRS temporal coordinate reference system
URI uniform resource identifier
WSDL web service description language
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 requirements class specifies requirements that all Web APIs have to implement.
The Core requirements class does not mandate a specific encoding or format for representing features
or feature collections. Four requirements classes depend on the Core requirements class 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 requirements class can 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 includes a discussion about the recommended
encodings.
The Core requirements class does not mandate any encoding or format for the formal definition of the API.
One option is the OpenAPI 3.0 specification and a requirements class has been specified for OpenAPI 3.0,
which depends on the Core requirements class:
— OpenAPI Specification 3.0.
As with the feature encodings, an implementation of the Core requirements class can decide to use other API
definition representations in addition or instead of an OpenAPI 3.0 definition. Examples for alternative API
definitions include: OpenAPI 2.0 (Swagger), future versions of the OpenAPI specification, an OWS Common
2.0 capabilities document or WSDL.
The Core requirements class is intended to be a minimal useful API for fine-grained read-access to a spatial
dataset where geometries are represented in the CRS WGS 84 with axis order longitude/latitude.
Additional capabilities such as support for transactions, complex data structures, rich queries, other CRS,
subscription/notification, returning aggregated results, etc. can be specified in future parts of OGC API -
Features or as vendor-specific extensions.
Conformance with this document 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.
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.

— licence: Refers to a licence 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.
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 to which the link’s context conforms.
— 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 and is simply 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, 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. Ideally, 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 OGC API) 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 is 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.
[1]
In this document, fragments of OpenAPI definitions are shown in YAML (YAML Ain’t Markup Language)
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 has to be "based upon" a schema or parameter component in
the OGC schema repository.
In such a 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 are 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, like comments or description properties.
For API definitions that do not conform to the OpenAPI Specification 3.0, the normative statement has to 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/
descripti
...

Norme
internationale
ISO 19168-1
Deuxième édition
Information géographique — API
2025-01
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
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2025
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.: [phone]
E-mail: [e-mail]
Web: www.iso.org
Publié en Suisse
ii
Sommaire Page
Avant-propos .v
Introduction .vii
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 2
3.1 Termes et définitions .2
3.2 Abréviations.3
4 Conformité . 3
5 Conventions . 4
5.1 Identifiants .4
5.2 Relations de lien .5
5.3 Utilisation de HTTPS .5
5.4 URI HTTP .5
5.5 Définition de l’API .6
5.5.1 Remarques générales .6
5.5.2 Rôle d’OpenAPI .6
5.5.3 Références aux composants OpenAPI dans les déclarations normatives .6
5.5.4 Chemins des définitions d’OpenAPI .7
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 .11
7.2.3 Situations d’erreur . 12
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 . 13
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 .14
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 .16
7.9 Encodages .16
7.10 Internationalisation des chaînes .17
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 .24
7.14 Collection d’entités . 25
7.14.1 Fonctionnement . 25

iii
7.14.2 Réponse . 25
7.14.3 Situations d’erreur . 25
7.15 Entités . 25
7.15.1 Fonctionnement . 25
7.15.2 Paramètre limit . 26
7.15.3 Paramètre bbox .27
7.15.4 Paramètre datetime . 28
7.15.5 Paramètres de filtrage des propriétés d’entités . 30
7.15.6 Combinaisons de paramètres de filtrage . 30
7.15.7 Réponse .31
7.15.8 Situations d’erreur . 33
7.16 Entité . 34
7.16.1 Fonctionnement . 34
7.16.2 Réponse . 34
7.16.3 Situations d’erreur . 34
8 Classes d’exigences pour encodages .35
8.1 Vue d’ensemble . 35
8.2 Classe d’exigences «HTML» . 35
8.3 Classe d’exigences «GeoJSON» . 36
8.4 Classe d’exigences «Geography Markup Language (GML), Simple Features Profile,
Level 0» . 38
8.5 Classe d’exigences «Geography Markup Language (GML), Simple Features Profile,
Level 2». 39
9 Classe d’exigences «OpenAPI 3.0» .40
9.1 Exigences de base. 40
9.2 Définition complète .41
9.3 Exceptions.41
9.4 Sécurité .41
9.5 Entités .42
10 Types de supports .42
11 Considérations relatives à la sécurité .42
11.1 Généralités .42
11.2 Routes à accès multiples .43
11.3 Serveurs multiples .43
11.4 Manipulation de chemins sur GET .43
11.5 Manipulation de chemins sur PUT et POST. 44
Annexe A (normative) Suite de tests abstraits .45
Bibliographie . 61

iv
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’ISO attire l’attention sur le fait que la mise en application du présent document peut entraîner l’utilisation
d’un ou de plusieurs brevets. L’ISO ne prend pas position quant à la preuve, à la validité et à l’applicabilité de
tout droit de propriété revendiqué à cet égard. À la date de publication du présent document, l’ISO n’avait pas
reçu notification qu’un ou plusieurs brevets pouvaient être nécessaires à sa mise en application. Toutefois,
il y a lieu d’avertir les responsables de la mise en application du présent document que des informations
plus récentes sont susceptibles de figurer dans la base de données de brevets, disponible à l’adresse
www.iso.org/brevets. L’ISO ne saurait être tenue pour responsable de ne pas avoir identifié de tels droits de
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, en collaboration avec le comité technique CEN/TC 287, Information géographique, du Comité
européen de normalisation (CEN), conformément à l’Accord sur la coopération technique entre l’ISO et le
CEN (Accord de Vienne) et en collaboration avec l’Open Geospatial Consortium (OGC).
Cette deuxième édition annule et remplace la première édition (ISO 19168-1:2020), qui a fait l’objet d’une
révision technique.
Les principales modifications sont les suivantes:
— le schéma de liens a été modifié pour que l’attribut «rel» requis soit aligné sur l’IETF RFC 8288;
— les schémas de rectangle englobant ont été mis à jour pour nécessiter 4 chiffres ou 6 chiffres (2D ou 3D);
— le schéma XML core.xsd a été aligné sur le schéma correspondant de la représentation JSON;
— les références normatives ont été mises à jour afin de faire référence aux éditions les plus récentes (HTTP
et OpenAPI);
— la définition de «jeu de données» a été mise à jour;
— les définitions des termes «page de destination» et «OGC Web API» ont été ajoutées;
— le type de relation de lien IANA a été corrigé en «describedby» plutôt que «describedBy»;
— l’exigence /req/core/fc-limit-response-1 a été mise à jour pour clarifier le comportement si la valeur du
paramètre «limit» est supérieure à la valeur maximale;

v
— la recommandation /rec/core/fc-extent a été ajoutée pour préciser qu’il convient que le rectangle
englobant d’une réponse de collection d’entités soit le rectangle englobant d’entités correspondantes,
et pas seulement des entités de la page actuelle;
— les recommandations /rec/core/fc-md-self-links et /rec/core/sfc-md-links ont été ajoutées pour préciser
qu’il convient d’ajouter les liens «self»;
— la valeur de l’attribut «profile» a été modifiée dans le type de média GMI pour apparaître entre guillemets;
— une nouvelle exigence /req/core/fc-md-extent-multi a été ajoutée pour préciser que le premier rectangle
englobant dans un tableau d’étendue de collection contient également tous les autres rectangles
englobants du tableau;
— l’utilisation des attributs «spatial» et «temporal» dans une étendue de collection a été clarifiée;
— il a été précisé qu’il convient d’inclure l’attribut «itemType» pour chaque collection;
— l’interprétation d’un rectangle englobant dégénéré dans le paramètre «bbox» a été clarifiée;
— il a été précisé qu’un lien «next» peut ne pas renvoyer d’entité supplémentaire;
— il a été clarifié que l’identifiant d’identité est mis en correspondance avec l’attribut «id» dans GeoJSON et
«@gml:id» dans GML;
— les cas de test manquants ont été ajoutés;
— certaines URI de spécification ont été mises à jour;
— diverses mises à jour et corrections rédactionnelles ont été apportées au document.
NOTE Pour de plus amples détails concernant les modifications répertoriées, voir les notes de publication de
[13]
l’OGC.
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.

vi
Introduction
[10]
Les normes 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.
L’ISO a publié un sous-ensemble de la famille de normes API de l’OGC. Pour indiquer que seul un sous-ensemble
des normes 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». Par
exemple, 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éospatiale 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é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 dont certaines
parties sont publiées par l’ISO en tant que série de normes ISO 19168 / «Information géographique —
API géospatiale pour les entités»;
— «le présent document» pour désigner la norme «OGC API — Features — Part 1: Core» qui est publiée par
l’ISO comme ISO 19168-1 / «Information géographique — API géospatiale pour les entités — Partie 1:
Profil minimal».
La norme OGC API est organisée par type de ressource. La norme OGC API — Features 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.
NOTE Pour ceux qui ne connaîtraient pas le terme «entité», les explications concernant Spatial Things,
[7]
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. La série de normes est constituée de parties multiples, chacune d’entre elles étant une norme
distincte. Dans le présent document (ISO 19168-1), qui correspond à l’une de ces parties, 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
(CRS), des jeux de données multiples et des hiérarchies de collections.
Par défaut, chaque API exécutant 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, la norme OGC API — Features offre 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 cohérence avec l’architecture
du Web. En particulier, la conception de l’API est gouvernée par les RFC HTTP/HTTPS de l’IETF, Data on
[8] [7]
the Web Best Practices du W3C , Spatial Data on the Web Best Practices des W3C/OGC et les lignes
directrices émergentes OGC Web API Guidelines. Un exemple en particulier est l’utilisation des concepts
[9]
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) est 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.

vii
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.
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
Ressource Chemin Méthode Paragraphe
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é

viii
Norme internationale ISO 19168-1:2025(fr)
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).
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
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:// www .rfc-editor .org/ rfc/ rfc2818 .html
Internet Engineering Task Force (IETF), RFC 3339: Date et heure sur Internet: Timestamps [en ligne].
Edited by G. Klyne, C. Newman. 2002 [consulté le 16/03/2020]. Disponible à l’adresse https:// www .rfc-editor
.org/ rfc/ rfc3339 .html
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:// www
.rfc-editor .org/ rfc/ rfc7230 .html, https:// www .rfc-editor .org/ rfc/ rfc7231 .html, https:// www .rfc-editor .org/
rfc/ rfc7232 .html, https:// www .rfc-editor .org/ rfc/ rfc7233 .html, https:// www .rfc-editor .org/ rfc/ rfc7234
.html et https:// www .rfc-editor .org/ rfc/ rfc7235 .html
Internet Engineering Task Force (IETF), RFC 8288: Web Linking [en ligne]. Edited by M. Nottingham.
2017 [consulté le 16/03/2020]. Disponible à l’adresse https:// www .rfc-editor .org/ rfc/ rfc8288 .html
Open Geospatial Consortium (OGC), OGC 10-100r3: Geography Markup Language (GML) Simple
Features Profile [en ligne]. Edited by L. van den Brink, C. Portele, P. Vretanos. 2012 [consulté le 16/03/2020].
Disponible à l’adresse http:// portal .opengeospatial .org/ files/ ?artifact _id = 42729
Internet Engineering Task Force (IETF). RFC 7946: The GeoJSON Format [en ligne]. Edited by H. Butler,
M. Daly, A. Doyle, S. Gillies, S. Hagen, T. Schaub. 2016 [consulté le 16/03/2020]. Disponible à l’adresse https://
www .rfc-editor .org/ rfc/ rfc7946 .html

WHATWG. HTML, Living Standard [en ligne, consulté le 16/03/2020]. Disponible à l’adresse https:// html
.spec .whatwg .org/
schema.org. Schema.org [en ligne, consulté le 16/03/2020]. Disponible à l’adresse https:// schema .org/
docs/ schemas .html
3 Termes et définitions
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 https:// www .electropedia .org/
3.1 Termes et définitions
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 ou sérialisations.
Note 2 à l'article: Le terme «collection» dans cette définition est utilisé dans un sens plus large que dans l’ensemble du
présent document. Voir la définition de «collection d’entités».
[9]
[SOURCE: DCAT, 6.6, modifié — La définition a été 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.
[9]
[SOURCE: DCAT, 6.7, modifié — 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: Des informations complémentaires concernant le terme «entité» sont disponibles dans la
Référence [7].
[SOURCE: ISO 19101-1:2014, 4.1.11, modifié — 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
ressource
entité qui peut être identifiée
Note 1 à l'article: Le terme «ressource», lorsqu’il est utilisé dans le contexte d’une norme OGC API, signifie une ressource
Web (3.1.7), sauf spécification contraire.

[SOURCE: ISO 15836-2:2019, 3.1.10 modifié — Les Notes 1 et 2 ont été supprimées et remplacées par une
nouvelle Note 1 à l’article.]
3.1.6
API Web
API utilisant un style d’architecture basé sur les technologies du Web
Note 1 à l'article: Voir la Référence [8] pour des informations plus détaillées.
Note 2 à l'article: La définition a été adaptée de la Référence [8], 8.10.1 . Elle a été modifiée en la reformulant pour
davantage de clarté.
3.1.7
ressource Web
ressource (3.1.5) identifiée par une URI HTTP
3.2 Abréviations
API interface de programmation d’applications (Application Programming Interface)
CORS partage de ressources entre origines multiples (Cross-Origin Resource Sharing)
CRS ^systèmes de référence par coordonnées (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
IRI identificateur de ressource internationalisé (Internationalized Resource Identifier)
OGC Open Geospatial Consortium
RFC demande de commentaire (Request For Comment)
TRS système de référence de coordonnées temporel (Temporal Coordinate Reference System)
URI identificateur de ressource uniforme (Uniform Resource Identifier)
WSDL Web Service Description Language
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.
La classe d’exigences de Profil minimal spécifie les exigences que toutes les API Web doivent respecter.
La classe d’exigences de 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 de la classe d’exigences de 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 de la
classe d’exigences de 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 comprend un examen
des encodages recommandés.
La classe d’exigences de Profil minimal n’impose pas d’encodage ou de format pour la définition formelle de
l’API. 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 de la classe d’exigences de Profil minimal:
— Spécification OpenAPI 3.0.
De même qu’avec les encodages d’entités, il peut être 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.
La classe d’exigences de Profil minimal est conçue 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 CRS WGS 84 avec
l’ordre des axes longitude/latitude.
Des capacités supplémentaires, telles que la prise en charge de transactions, de structures de données
complexes, de requêtes riches, d’autres CRS, d’abonnement/notification, qui renvoient des résultats agrégés,
etc., peuvent être spécifiées dans des parties futures de la norme 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 tests concernés spécifiés à
l’Annexe A du présent document. La structure, les concepts et la méthodologie de test 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.
Tableau 2 — URL de classes de conformité
Classe de conformité URI
Profil minimal ht t p:// w w w . op en g i s . ne t / s p e c/ o g c api -f e a t u r e s -1/ 1 . 0/ c on f/ c or e
HTML ht t p:// w w w . op en g i s . ne t / s p e c/ o g c api -f e a t u r e s -1/ 1 . 0/ c on f/ ht m l
GeoJSON ht t p:// w w w . op en g i s . ne t / s p e c/ o g c api -f e a t u r e s -1/ 1 . 0/ c on f/ g e oj s on
GML, Simple Features Profile, Level 0 ht t p:// w w w . op en g i s . ne t / s p e c/ o g c api -f e a t u r e s -1/ 1 . 0/ c on f/ g m l s f 0
GML, Simple Features Profile, Level 2 ht t p:// w w w . op en g i s . ne t / s p e c/ o g c api -f e a t u r e s -1/ 1 . 0/ c on f/ g m l s f 2
OpenAPI Specification 3.0 ht t p:// w w w . op en g i s . ne t / s p e c/ o g c api -f e a t u r e s -1/ 1 . 0/ c on f/ o a s 30
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 tests 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ée pour exprimer les relations entre les ressources.
[3]
Les types de relations de lien enregistrés suivants 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 élément 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;
— licence: 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.
En outre, les types de relations 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 d’éléments 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 peut désigner le téléchargement en vrac d’une collection ou un lien related sur une entité peut
désigner une entité associée.
5.3 Utilisation de HTTPS
Pour des raisons de simplicité, le présent document ne fait généralement référence qu’au protocole HTTP.
Cela ne revient pas à exclure l’utilisation de 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 HTTP
et de la Syntaxe URI IETF RFC. Si les URI comprennent des caractères réservés qui sont des délimiteurs dans
[2]
le sous-composant URI, ceux-ci doivent être codés par encodage-pourcent. Voir l’Article 2 de la RFC 3986
pour plus de détails.
-------------
...