diff --git a/.gitignore b/.gitignore index e43b0f9..2890c09 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,3 @@ .DS_Store +*.pdf +*.html diff --git a/api_modules/README.md b/api_modules/README.md deleted file mode 100644 index e811a48..0000000 --- a/api_modules/README.md +++ /dev/null @@ -1 +0,0 @@ -This folder contains modules which can be used to construct an OGC API. At this time it only contains the CRS extension from WFS 3.0. This module will be generalized for common use if there is agreement on this approach for handling API elements. diff --git a/api_modules/bbox/requirements_module_bbox.adoc b/api_modules/bbox/requirements_module_bbox.adoc deleted file mode 100644 index b42c779..0000000 --- a/api_modules/bbox/requirements_module_bbox.adoc +++ /dev/null @@ -1,37 +0,0 @@ -[[rm_bbox]] -[cols="1,4",width="90%"] -|=== -2+|*Requirements Module* -2+|http://www.opengis.net/spec/ogcapi-common-2/1.0/rm/bbox -|Target type |Web API Query Parameter -|=== - -The `bbox` parameter is used to select resources based on the geospatial footprint or extent. - -The `bbox` parameter is defined as follows: - -include::./requirements/REQ_rc-bbox-definition.adoc[] - -While the processing of the `bbox` parameter is specific to the resource and operation for which it is applied, there is a general set of requirements which all implementations must address. - -include::./requirements/REQ_rc-bbox-response.adoc[] - -"Intersects" means that a coordinate that is part of the spatial geometry of the resource falls within the area specified in the parameter `bbox`. This includes the boundaries of the geometries. For curves the boundary includes the start and end position. For surfaces the boundary includes the outer and inner rings. - -In case of a degenerate bounding box, the resulting geometry is used. For example, if the lower left corner is the same as the upper right corner, all resources match where the geometry intersects with this point. - -This standard does not specify requirements for the parameter `bbox-crs`. Those requirements will be specified in a later version of this standard. - -The bounding box for WGS 84 longitude/latitude is, in most cases, the sequence of minimum longitude, minimum latitude, maximum longitude and maximum latitude. However, in cases where the box spans the anti-meridian (180th meridian) the first value (west-most box edge) is larger than the third value (east-most box edge). - -.The bounding box of the New Zealand Exclusive Economic Zone -================= -The bounding box of the New Zealand Exclusive Economic Zone in WGS84 (from 160.6°E to 170°W and from 55.95°S to 25.89°S) would be represented in JSON as `[ 160.6, -55.95, -170, -25.89 ]` and in a query as `bbox=160.6,-55.95,-170,-25.89`. -================= - -Note that the server will return an error if a latitude value of ``160.0`` is used. - -If the vertical axis is included, the third and the sixth number are the bottom and the top of the 3-dimensional bounding box. - -A template for the definition of the parameter in YAML according to OpenAPI 3.0 is available at link:http://beta.schemas.opengis.net/ogcapi/common/part2/0.1/collections/openapi/parameters/bbox.yaml[bbox.yaml]. - diff --git a/api_modules/collection/requirements_module_collection.adoc b/api_modules/collection/requirements_module_collection.adoc deleted file mode 100644 index 657fa4a..0000000 --- a/api_modules/collection/requirements_module_collection.adoc +++ /dev/null @@ -1,44 +0,0 @@ -[[rm_collection]] -[cols="1,4",width="90%"] -|=== -2+|*Requirements Module* -2+|http://www.opengis.net/spec/ogcapi-common-2/1.0/rm/collection -|Target type |Web Resource -|=== - -include::requirements/REQ_collection-definition.adoc[] - - -.Collection Resource Schema -[source, YAML] -include::./schemas/collectionDesc.yaml[] - -Most of the properties of the Collection resource are self-explanatory. However, a few properties require additional explanation. - -[[collection-attribution-section]] -===== Attribution - -The attribution element is a special type of string property. Specifically, the attribution element can contain markup text. Markup allows a text string to import images and format text. The capabilities are only limited by the markup language used. See the example <> for an example of the use of markup in the attribution element. - -[[collection-item-type-section]] -===== Item Type - -In some Geospatial collections, the members (`items`) that make up that collection can be individually accessed by a client. In this case, the `itemType` property in the Collection resource identifies the type of the `items` accessible from that collection. - -include::recommendations/REC_rc-md-item-type.adoc[] - -[collection-links-section]] -===== Links - -To support hypermedia navigation, the `links` property must be populated with sufficient hyperlinks to navigate through the whole dataset. - -include::requirements/REQ_rc-md-items-links.adoc[] - -Additional information may be available to assist in understanding and using this dataset. Links to those resources should be provided as well. - -include::recommendations/REC_rc-md-items-descriptions.adoc[] - -[[collection-extent-section]] -===== Extent - -include::../extent/requirements_module_extent.adoc[] diff --git a/api_modules/crs/18-058.html b/api_modules/crs/18-058.html deleted file mode 100644 index 3a22549..0000000 --- a/api_modules/crs/18-058.html +++ /dev/null @@ -1,2053 +0,0 @@ - - - - - - - -OGC Web Feature Service 3.0: Part 2 - Extension for Coordinate Reference Systems (by reference) - - - - - -
-
-
-
- --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Open Geospatial Consortium

Submission Date: <yyyy-mm-dd>

Approval Date:   <yyyy-mm-dd>

Publication Date:   <yyyy-mm-dd>

External identifier of this OGC® document: http://www.opengis.net/doc/IS/wfs-2/3.0

Internal reference number of this OGC® document:    18-058

Version: 3.0.0-draft.1 (2018-04-07)

Category: OGC® Implementation Specification

Editor:   Clemens Portele, Panagiotis (Peter) A. Vretanos

- --- - - - - - -

OGC Web Feature Service 3.0: Part 2 - Extension for Coordinate Reference Systems (by reference)

- --- - - - - - - - - - - - -

Copyright notice

Copyright © 2018 Open Geospatial Consortium

To obtain additional rights of use, visit http://www.opengeospatial.org/legal/

- --- - - - - - -

Warning

-
-

This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.

-
-
-

Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

-
- --- - - - - - - - - - - - - - - -

Document type:    OGC® Standard

Document subtype:    Interface

Document stage:    Draft

Document language:  English

-
-
-

License Agreement

-
-
-

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

-
-
-

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

-
-
-

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.

-
-
-

THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

-
-
-

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

-
-
-

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

-
-
- -
-
-

i. Abstract

-
-
-

The OGC Web Feature Service 3.0, Part 1 - Core standard defines the behaviour -of a server that can present geometry valued feature properties in a single -coordinate reference system, WGS84 (longitude, latitude). Part 1 includes -extension points for supporting multiple coordinate reference systems but does -not describe the behaviour of a server for this case.

-
-
-

This part of the WFS standard defines the behaviour of a server that supports -multiple coordinate reference systems. It describes mechanisms for:

-
-
-
    -
  • -

    discovering the list of supported coorindate reference systems

    -
    • -
  • -

    requesting that geometry valued feature properties be presented in one -of these supported coordinate reference systems

    -
    • -
  • -

    explicitly declaring the coordinates reference system begin used, and -optionally the coordinate axis order, in a response document

    -
    • -
-
-
-

It should be clarified that this standard only deals with single coordinate -reference system references that can be specified using an identifier (e.g. -a URL). Compound coordinate reference system references or explicitly specified -coordinate reference systems (i.e. those specified explicitly in a request -using some notation like WKT or GML) are not covered in this standard.

-
-
-

ii. Keywords

-
-
-

The following are keywords to be used by search engines and document catalogues.

-
-
-

ogcdoc, OGC document, web feature service, wfs, feature, property, geographic information, spatial data, spatial things, dataset, distribution, API, openapi, geojson, gml, html

-
-
-

iii. Preface

-
-
-

OGC Declaration

-
-
-

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium Inc. shall not be held responsible for identifying any or all such patent rights.

-
-
-

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

-
-
-

ISO Declaration

-
-
-

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.

-
-
-

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.

-
-
-

The main task of technical committees is to prepare International Standards. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.

-
-
-

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.

-
-
-

iv. Submitting organizations

-
-
-

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

-
-
-
    -
  • -

    CubeWerx Inc.

    -
    • -
  • -

    Hexagon

    -
    • -
  • -

    interactive instruments GmbH

    -
    • -
  • -

    Planet Labs

    -
    • -
-
-
-

v. Submitters

-
-
-

All questions regarding this submission should be directed to the editors or the submitters:

-
- ---- - - - - - - - - - - - - - - - - - - - - - - - - -
NameAffiliation

Chris Holmes

Planet Labs

Clemens Portele (editor)

interactive instruments GmbH

Frédéric Houbie

Hexagon

Panagiotis (Peter) A. Vretanos (editor)

CubeWerx Inc.

-
- - - - - -
-
Caution
-		 -A list of contributors will be added later. -
-
-
-
-
-

1. Scope

-
-
-

This International Standard specifies the behaviour of a server that supports -multiple coordinate reference systems.

-
-
-

This International Standard specifies how, for each offered feature collection, -a server advertises the list of supported coordinate reference systems.

-
-
-

This International Standard specifies how the coordinates of geometry valued -feature properties can be accessed in one of the supported coordinate -reference systems.

-
-
-

This International Standard specifies how features can be accesses from the -server using a bounding box specified in one of the supported coordinate -reference systems.

-
-
-

This International Standard specifies how a server can declare the coordinate -reference system, and optionally, the axis order of coordinates retrieved from -from a server.

-
-
-
-
-

2. Conformance

-
-
-

This standard defines 1 requirements / conformance classe.

-
-
- -
-
-

This conformance class specifies requirements that a WFS has to implement to -allow features to be accessed with geometry coordinates reprojected into one -of the coordinate reference systems that the service advertises it supports.

-
-
-

Conformance with this standard 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.

-
-
-
-
-

3. References

-
-
-

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

-
-
- -
-
-
-
-

4. Terms and Definitions

-
-
-

This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r8], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard.

-
-
-

For the purposes of this document, the following additional terms and definitions apply.

-
-
- - - - - -
-
Caution
-		 -Add link to the informative WFS Guide, once it is available. -
-
-
-

4.1. coordinate

-
-

one of a sequence of n numbers designating the position of a point in n-dimensional space [ISO 19111:2007, definition 4.5]

-
-
-
-

4.2. coordinate reference system

-
-

coordinate system (4.5) that is related to an object by a datum [ISO 19111:2007, definition 4.8]

-
-
-
-

4.3. coordinate system

-
-

set of mathematical rules for specifying how coordinates are to be assigned to points [ISO 19111:2007, definition 4.10]

-
-
-
-

4.4. feature

-
-

abstraction of real world phenomena [ISO 19101-1:2014]

-
-
- - - - - -
-
Note
-		 -If you are unfamiliar with the term 'feature', the explanations in -the W3C/OGC Spatial Data on the Web Best Practice document may help, -in particular the section on -Spatial Things, Features and Geometry. -
-
-
-
-

4.5. feature collection; collection

-
-

a set of features from a dataset

-
-
- - - - - -
-
Note
-		 -In this specification, 'collection' is used as a synonym for 'feature -collection'. This is done to make, for example, URI path expressions shorter -and easier to understand for those that are not geo-experts. -
-
-
-
-

4.6. spatial feature collection; spatial collection

-
-

a feature collection that includes one or more geometry-valued properties

-
-
-
-
-
-

5. Conventions

-
-
-

5.1. Open issues

-
-

This is a DRAFT version of WFS 3.0, Part 2. This draft is not complete and -there are open issues that are still under discussion. These discussion topics -are identified as "CAUTION" annotations with a link to the issue on GitHub and -a brief summary of the issue.

-
-
-

The current expectation is to have a stable version of the candidate WFS 3.0, -Part 2, standard in 2019. Criteria to move the candidate standard to the next -stage in the process are:

-
-
-
    -
  • -

    Multiple implementations of each conformance class,

    -
    • -
  • -

    A conformance test suite for each conformance class,

    -
    • -
  • -

    Multiple implementations of a generic WFS client,

    -
    • -
  • -

    Multiple implementations of clients using the OpenAPI definition of a WFS,

    -
    • -
  • -

    Multiple draft extensions to verify the extensibility, and

    -
    • -
  • -

    Resolution of comments received on GitHub or in formal reviews in OGC and ISO/TC 211.

    -
    • -
-
-
-
-

5.2. Identifiers

-
-

The normative provisions in this draft standard are denoted by the URI http://www.opengis.net/spec/wfs-2/3.0.

-
-
-

All requirements and conformance tests that appear in this document are -denoted by partial URIs which are relative to this base.

-
-
-
-

5.3. UML model

-
-

UML diagrams are included in this standard to illustrate the conceptual model that underpins Web Feature Service implementations. The UML model is not normative. The UML profile used is specified in ISO 19103:2015.

-
-
-

Resources are modelled as UML interfaces.

-
-
-
-

5.4. Link relations

-
-

To express relationships between resources, RFC 5988 (Web Linking) and registered link relation types are used.

-
-
-
-

5.5. 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 simply is a shorthand -notation for "HTTP or HTTPS". In fact, most servers are expected to use -HTTPS, not HTTP.

-
-
-
-

5.6. API definition

-
-

5.6.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 standard 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 standard - or other parts of the Web Feature Service -standard series - and will support additional operations, parameters, etc. -that are specific to the API or the software tool used to implement the API.

-
-
-
-

5.6.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 -this part of a WFS 3.0 server.

-
-
-
-

5.6.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 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.

    -
    • -
  • -

    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 should be interpreted in the context of the -API definition language used.

-
-
-
-

5.6.4. Paths in OpenAPI definitions

-
-

All paths in an OpenAPI definition are relative to a base URL of the server.

-
-
- - - - - -
-
Caution
-		 -ISSUE 98
-Server Ambiguity in OpenAPI -
-
-
-
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 WFS would be the -URL https://data.example.org/mypath for the production server.

-
-
-
-
-
-

5.6.5. Reusable OpenAPI components

-
-

Reusable components for OpenAPI definitions for a WFS 3.0 server are -referenced from this document.

-
-
- - - - - -
-
Caution
-		 -During the development phase, these components use a base URL of -"https://raw.githubusercontent.com/opengeospatial/WFS_FES/master/", -but eventually they are expected to be available under the base URL -"http://schemas.opengis.net/wfs/3.0/openapi/". -
-
-
-
-
-
-
-

6. Requirements Class "Coordinate Reference Systems (by reference)"

-
-
-

6.1. Overview

- -
-
-

6.2. Format model

- ---- - - - - - - -

Requirement 1

-

/req/crs/crs-format-model

-
-
-

Servers that implement this standard shall accept CRS references using the -identifiers with the following format model:

-
-
-

http://www.opengis.net/def/crs/{authority}/{version}/{code}

-
-
-

In this format model, the token {authority} is a placeholder for a code the -designates to authority responsible for the definition of this CRS. Typical -values include "epsg" and "ogc".

-
-
-

The token {version} is a placeholder for the specific version of the coordinate -reference system definition or 0 for the latest version or if the version -is unknown.

-
-
-

The token {code} is a placeholder for the authority’s code for the CRS.

-
-
-

Other formats may be supported as well but they are not described in this -standard.

-
-
-
-

6.3. Feature collections metadata (Discovery)

-
-

6.3.1. Response

-
-

The WFS core defines, but does not use, the crs property (see X.X) on the -collection metadata (i.e. /collections/{collectionId}). This extension makes -this property mandatory for spatial collections (i.e coolections with geometry -values properties).

-
- ---- - - - - - - -

Requirement 2

-

/req/crs/fc-md-crs-list

-
-
-

For each spatial feature collection, the 'crs' property shall contain the list -of coordinate reference system references supported by the service.

-
- ---- - - - - - - -

Requirement 3

-

/req/crs/fc-md-crs-list-storageCrs

-
-
-

The first item in the CRS list shall be the internal storage CRS of the -features in the collection.

-
- ---- - - - - - - -

Requirement 4

-

/req/crs/fc-md-crs-list-defaultCrs

-
-
-

The default crs — that is the CRS used unless something else is explicitly -requested — shall be as define in Part 1, WFS core (i.e. http://www.opengis.net/def/crs/OGC/1.3/CRS84).

-
-
-

The list of supported coordinate reference systems may also include the default -CRS but this is not a requirement.

-
-
-

This examples illustrates a list of supported coordinate reference systems.

-
-
-
-
  "collections": [
-    {
-      "id": "buildings",
-      "title": "Buildings",
-      "description": "Buildings in the city of Bonn.",
-      "links": [
-        { "href": "http://data.example.org/collections/buildings/items",
-          "rel": "items", "type": "application/geo+json",
-          "title": "Buildings" },
-        { "href": "http://example.org/concepts/building.html",
-          "rel": "describedBy", "type": "text/html",
-          "title": "Feature catalogue for buildings" }
-      ],
-      "extent": {
-        "spatial": [ 7.01, 50.63, 7.22, 50.78 ],
-        "temporal": [ "2010-02-15T12:34:56Z", "2018-03-18T12:11:00Z" ]
-      },
-      "crs": [
-        "http://www.opengis.net/def/crs/EPSG/0/4326",
-        "http://www.opengis.net/def/crs/EPSG/0/4269",
-        "http://www.opengis.net/def/crs/EPSG/0/3857",
-        "http://www.opengis.net/def/crs/EPSG/0/3395",
-        "http://www.opengis.net/def/crs/EPSG/0/4267",
-        "http://www.opengis.net/def/crs/EPSG/0/26703",
-        "http://www.opengis.net/def/crs/EPSG/0/26704",
-        "http://www.opengis.net/def/crs/EPSG/0/26705",
-        "http://www.opengis.net/def/crs/EPSG/0/26706",
-        "http://www.opengis.net/def/crs/EPSG/0/26707",
-        "http://www.opengis.net/def/crs/EPSG/0/26708"
-      ]
-    }
-  ]
-
-
-
-

To prevent unnecessary duplication of lists of supported coordinate reference -systems, a global list of supported coordinate reference systems may be -provided as part of the feature collections metadata.

-
- ---- - - - - - - -

Requirement 5

-

/rec/crs/fc-md-crs-list-global

-
-
-

All coordinate reference systems in the global list shall be valid for all -spatial feature collections offered by the service.

-
-
-

The schema of the feature collections metadata from the core is thus extended -as specified in the following OpenAPI 3.0 schema fragment:

-
-
-
-
type: object
-required:
-  - links
-  - collections
-properties:
-  links:
-    type: array
-    items:
-      $ref: link.yaml
-  crs:
-    description: the list of coordinate reference systems that are supported by the service; the coordinate reference systems in this list shall be valid for all spatial feature collections offered by the service
-    type: array
-    items:
-      type: string
-      format: uri
-  collections:
-    type: array
-    items:
-      $ref: collectionInfo.yaml
-
-
- ---- - - - - - - -

Requirement 6

-

/rec/crs/fc-md-crs-list-global-default

-
-
-

No special meaning shall be ascribed to the first item listed in the global -list of supported coordinate reference systems.

-
-
-
-
-

6.4. Feature collections (Query)

-
-

6.4.1. Parameter bbox-crs

-
-

Part 1, WFS Core mentions the bbox-crs parameter. Thie extension defines -this parameter as a means of asserting the CRS of the values used in the bbox -(see X.X) parameter.

-
- ---- - - - - - - -

Requirement 7

-

/req/core/fc-bbox-crs-definition

-
-
-

Each feature collection operation shall support a parameter bbox-crs with -the following characteristics (using an OpenAPI Specification 3.0 fragment):

-
-
-
-
name: bbox-crs
-in: query
-required: false
-schema:
-  type: string
-  format: uri
-style: form
-explode: false
-
-
- ---- - - - - - - -

Requirement 8

-

/req/core/fc-bbox-crs-valid-value

-
-
-

If specified, the value of the bbox-crs parameter shall be taken from the -list of supported list of coordinate reference systems values as declared in -the metadata for each spatial feature collection.

-
- ---- - - - - - - -

Requirement 9

-

/req/core/fc-bbox-crs-valid-defaultValue

-
-
-

If the bbox-crs parameter is not specified then the values of the bbox -parameter shall be assumed to be in the default WGS84 (lon,lat) coordinate -reference system (i.e. http://www.opengis.net/def/crs/OGC/1.3/CRS84).

-
- ---- - - - - - - -

Requirement 10

-

/req/core/fc-bbox-crs-action

-
-
-

If the bbox-crs parameter is specified then the values of the bbox parameter -shall be assumed to be in the specified CRS and the server shall perform the -necessary internal transformations to properly fetch data from within the -specified bounding box.

-
- ---- - - - - - - -

Requirement 11

-

/req/crs/crs-exception

-
-
-

In all cases, an invalid or unrecognized coordinate reference system value -shall trigger a 400 exception with an appropaite message.

-
-
-

The following fragment illustrates the use of the bbox-crs parmeter:

-
-
-
-
   ...&bbox=160.6,-155.95,-170,-25.89&bbox-crs=http://www.opengis.net/...
-
-
-
-
-

6.4.2. Parameter crs

-
-

This extension defines a parameter on the /collection/{collectionId}/items -resource that may be used to assert a specific WFS-supported CRS transformation -to be applied to the compatible (see X.X) geometries of the features returned -in a response document.

-
- ---- - - - - - - -

Requirement 12

-

/req/core/fc-crs-definition

-
-
-

Each spatial feature collection operation shall support a parameter named crs -with the following characteristics (using an OpenAPI Specification 3.0 -fragment):

-
-
-
-
name: crs
-in: query
-required: false
-schema:
-  type: string
-  format: uri
-style: form
-explode: false
-
-
- ---- - - - - - - -

Requirement 13

-

/req/core/fc-crs-valid-value

-
-
-

If specified, the value of the crs parameter shall be taken from the list of -supported list of coordinate reference systems as declared in the metadata -for each feature collection.

-
- ---- - - - - - - -

Requirement 14

-

/req/core/fc-crs-default-value

-
-
-

If the crs parameter is not specified the geometry coordinates shall be -presented in the default CRS specified in Part 1, WFS Core (i.e. -http://www.opengis.net/def/crs/OGC/1.3/CRS84).

-
- ---- - - - - - - -

Requirement 15

-

/req/core/fc-crs-action

-
-
-

If the crs parameter is specified then the coordinates of all geometry-valued -properties in the response document shall be presented in the requested CRS -subject to any limitations placed on the response based on the requested output -representation (e.g. the requested representation mandates a fixed CRS).

-
- ---- - - - - - - -

Requirement 16

-

/req/core/fc-crs-action-exception

-
-
-

If the requested crs parameter values violates some requirement of the -requested output format then the server shall raise an 400 exception with -an appropriate message.

-
- ---- - - - - - - -

Requirement 17

-

/req/crs/crs-exception

-
-
-

An invalid or unrecognized crs value shall trigger a 400 exception with an -appropriate message.

-
-
-

The following fragement illustrated the use of the crs parameter:

-
-
-
-
.../collections/buildings/items?crs=http://www.opengis.net/def/crs/epsg/0/26703&...
-
-
-
-
-

6.4.3. Output format considerations (TBD)

-
-

Part 1, WFS Core defines three conformance classes related to output formats:

-
-
-
    -
  • -

    GML

    -
    • -
  • -

    GeomJSON

    -
    • -
  • -

    HTML

    -
    • -
-
-
-

GML has full CRS support and no further requirements are imposed by this -standard.

-
-
-

GeoJSON normatively supports WGS84 (lon,lat) but the "prior arrangment" -provision allows other coordinate systems to be used.

-
- ---- - - - - - - -

Requirement 18

-

/req/crs/geojson

-
-
-

Servers that implement this extension and clients that use this extension shall -be subject to the prior arragements provision of the GeoJSON standard -(see https://tools.ietf.org/html/rfc7946#page-12).

-
-
- - - - - -
-
Note
-		 -Need to do more work on HTML! -
-
-
-

HTML only supports WGS84 based on schema.org dependency; not sure if this is -an issue but schema.org annotations seem to require WGS84 (lat,lon) yet WFS -core requires lon,lat by default.

-
-
-
-

6.4.4. Compatibility of coordinate reference systems (TBD)

-
-

Coordinate reference systems that differ in dimensionality or that have no -defined datum transformation between them may be incompatible for the purposes -of geometry coordinate conversion. Where the request srsName references a CRS -that is incompatible with the storage CRS of a geometry property, the service -shall encode that geometry property using some other CRS identified with an -srsName attribute on that property; there is no requirement that this srsName -attribute be wfs:DefaultCRS or one of those listed in wfs:OtherCRS.

-
-
-

If a filter predicate compares two geometries with incompatible CRS, the server -shall generate a 400 exception with an appropriate message.

-
-
-

EXAMPLE: A feature with both 2D and 3D geometry properties is requested with -srsName set to a 2D CRS; the 2D property is encoded in the requested CRS, and -the 3D property is encoded with some 3D CRS identified in the srsName of the -geometry.

-
-
-

EXAMPLE: A 1D geometry property whose coordinate is the path length along a -LineString (itself defined in 3D with some CRS) with gml:id="geom.123" in the -same response is encoded with srsName="#geom.123".

-
-
-

EXAMPLE: A 1D geometry property whose coordinate is defined in an external -resource is encoded with srsName set to an HTTP URI for that external resource.

-
-
-
-

6.4.5. Coordinate system and axis order (experimental)

-
-

Because of the inconsistent provision of coordinate reference system metadata -in geospatial encodings and the continued confusion caused by the axis order -of coordinates, this standard defines a mechanism for a server to clearly and -unambiguously assert the coordinate reference system and axis order being used -in a response document independent of the requested output format.

-
- ---- - - - - - - -

Requirement 19

-

/req/crs/ogc-crs-header

-
-
-

An HTTP header named OGC-CRS shall be used to assert the coordinate -reference system and, optionally, the coordinate axis order used in a -response document.

-
- ---- - - - - - - -

Requirement 20

-

/req/crs/ogc-crs-header-value

-
-
-

The value of the OGC-CRS header shall be a URI referencing the -coordinate reference system used in a response document with an -optional parameter named axisOrder.

-
- ---- - - - - - - -

Requirement 21

-

/req/crs/ogc-crs-axis-order-value

-
-
-

The value of the axisOrder parameter shall be an ordered list of axis -names indicating the order in which coordinates are presented in a response -document.

-
- ---- - - - - - - -

Requirement 22

-

/req/crs/ogc-crs-axis-names

-
-
-

The axis names shall be taken from the coordinate reference system definition.

-
- ---- - - - - - - -

Requirement 23

-

/req/crs/ogc-crs-header-axis-action

-
-
-

If the axisOrder parameter is not include with the OGC-CRS header, then -the order of coordinates shall be assumed to be generated according to the -requirements of the requested output format.

-
-
-

The following example illustrates the use of the OGC-CRS header.

-
-
-
-
   OGC-CRS: http://www.opengis.net/def/crs/OGC/1.3/CRS84; axisOrder=lon,lat
-
-
-
-
-
-
-
-
-

Annex A: Abstract Test Suite (Normative)

-
-
- - - - - -
-
Caution
-		 -ISSUE 112
-The Abstract Test Suite is work-in-progress. Currently, only a draft for the -Core conformance class is available. The other five conformance classes (HTML, -GeoJSON, GML-SF0, GML-SF2, OpenAPI 3.0) are not yet covered. -
-
-
-

A.1. Overview

- -
-
-

A.2. Conventions

-
-

A.2.1. Path Templates

- -
-
-

A.2.2. API

- -
-
-

A.2.3. Processing

- -
-
-

A.2.4. Parameters

-
-

The following observations apply for WFS 3.0 parameters:

-
-
-
    -
  1. -

    WFS 3.0 does not use cookies.

    -
    2. -
  2. -

    Query parameters follow common Web practice

    -
    3. -
  3. -

    Header parameters are restricted to custom headers

    -
    4. -
  4. -

    For path parameters, the name of the parameter must match the name of the variable in the path template in the path object

    -
    5. -
-
-
-

Parameters are defined at the Path Item and Operation level. Parameters defined at the Path Item level must apply to all operations under that Path item. These parameters may be modified at the Operation level but they may not be removed.

-
-
-
-
-

A.3. Abstract Test

-
-

The Test Approach used in the WFS 3.0 Abstract Test Suite includes four steps:

-
-
-
    -
  1. -

    Identify the test points

    -
    2. -
  2. -

    Verify that API descriptions of the test points comply with the WFS 3.0 standard

    -
    3. -
  3. -

    Verify that the micro-services at each test point behave in accordance with the WFS 3.0 standard.

    -
    4. -
  4. -

    Verify that the resources returned at each test point are in accordance with the WFS 3.0 standard and any referenced content standard.

    -
    5. -
-
-
-

Identification of test points is a new requirement with WFS 3.0. Since an API is not a Web Service, there may be RESTful endpoints advertised which are not intended to be targets of the compliance testing. Section A.4.2 describes the process for crawling the API Description document and extracting those URLs which should be tested as well as the path(s) they should be tested with. The concatenation of a Server URL with a path forms a test point.

-
-
-

Section A.4.3 describes how the test points are exercised to determine compliance with the WFS 3.0 standard.

-
-
-

A.3.1. General Tests

-
-
A.3.1.1. Coordinate Reference Systems
-
-
a) Test Purpose:
-
-

Validate that all spatial geometries provided through a WFS service are in the CRS84 spatial reference system unless otherwise requested by the client.

-
-
-
-
b) Pre-conditions:
-
-

none

-
-
-
-
c) Test Method:
-
-
    -
  1. -

    Do not specify a coordinate reference system in any request. All spatial data should be in the CRS84 reference system.

    -
    2. -
  2. -

    Validate retrieved spatial data using the CRS84 reference system.

    -
    3. -
-
-
-
-
d) References:
-
-

Requirement 8

-
-
-
-
-
-
-
-
-
-

Annex B: Revision History

-
- ------- - - - - - - - - - - - - - - - - - - -
DateReleaseEditorPrimary clauses modifiedDescription

2018-04-09

3.0

P. Vretanos

First draft

-
-
-
-
-

Annex C: Bibliography

-
-
- -
-
-
-
- - - \ No newline at end of file diff --git a/api_modules/datetime/requirements_module_datetime.adoc b/api_modules/datetime/requirements_module_datetime.adoc deleted file mode 100644 index a0ce822..0000000 --- a/api_modules/datetime/requirements_module_datetime.adoc +++ /dev/null @@ -1,53 +0,0 @@ -[[rm_datetime]] -[cols="1,4",width="90%"] -|=== -2+|*Requirements Module* -2+|http://www.opengis.net/spec/ogcapi-common-2/1.0/rm/datetime -|Target type |Web API Query Parameter -|=== - -The `datetime` parameter selects resources based on their temporal extent. The definition of temporal extent is specific to the resource type being filtered. - -The `datetime` parameter is defined as follows: - -include::./requirements/REQ_rc-datetime-definition.adoc[] - -While the processing of the `datetime` parameter is specific to the resource and operation for which it is applied, there is a general set of requirements which all implementations must address. - -include::./requirements/REQ_rc-datetime-response.adoc[] - -"Intersects" means that the time (instant or period) specified in the parameter `datetime` includes a timestamp that is part of the temporal geometry of the resource (again, a time instant or period). For time periods this includes the start and end time. - -[width="90%",cols="2,6a"] -|==== -| Note | ISO 8601-2 distinguishes open start/end timestamps (double-dot) and unknown start/end timestamps (empty string). For queries, an unknown start/end has the same effect as an open start/end. -|==== - -.A date-time -================= -February 12, 2018, 23:20:52 GMT: - -`datetime=2018-02-12T23%3A20%3A52Z` -================= - -For resources with a temporal property that is a timestamp (such as `lastUpdate`), a date-time value would match all resources where the temporal property is identical. - -For resources with a temporal property that is a date or a time interval, a date-time value would match all resources where the timestamp is on that day or within the time interval. - -.Intervals -================= -February 12, 2018, 00:00:00 GMT to March 18, 2018, 12:31:12 GMT: - -`datetime=2018-02-12T00%3A00%3A00Z%2F2018-03-18T12%3A31%3A12Z` - -February 12, 2018, 00:00:00 UTC or later: - -`datetime=2018-02-12T00%3A00%3A00Z%2F..` - -March 18, 2018, 12:31:12 UTC or earlier: - -`datetime=..%2F2018-03-18T12%3A31%3A12Z` -================= - -A template for the definition of the parameter in YAML according to OpenAPI 3.0 is available at link:http://beta.schemas.opengis.net/ogcapi/common/part2/0.1/collections/openapi/parameters/datetime.yaml[datetime.yaml]. - diff --git a/api_modules/extent/requirements_module_extent.adoc b/api_modules/extent/requirements_module_extent.adoc deleted file mode 100644 index e284a7d..0000000 --- a/api_modules/extent/requirements_module_extent.adoc +++ /dev/null @@ -1,20 +0,0 @@ -[[rm_extent]] -[cols="1,4",width="90%"] -|=== -2+|*Requirements Module* -2+|http://www.opengis.net/spec/ogcapi-common-2/1.0/rm/extent -|Target type |Web Resource -|=== - -The extent property defines a spatial-temporal envelope that encompasses the geospatial data in the collection. Since not all collections are nicely clustered around a single place in space and time, the extent property provides flexibility in how that surface can be defined. - -* Spatial Bounding Box (Bbox) provides a set of rectangular bounding boxes which use geographic coordinates to envelope portions of the collection. Typically only the first element would be populated. Additional boxes may be useful, for example, when the collection is clustered in multiple, widely-separated locations. -* Temporal Interval provides a set of temporal periods. Typically only the first temporal period would be populated. However, like Bbox, additional periods can be added if the collection does not form a single temporal cluster. - -include::requirements/REQ_rc-md-extent.adoc[] - -include::recommendations/REC_rc-md-extent.adoc[] - -include::recommendations/REC_rc-md-extent-single.adoc[] - -include::recommendations/PER_rc-md-extent-extensions.adoc[] diff --git a/api_modules/limit/requirements_module_limit.adoc b/api_modules/limit/requirements_module_limit.adoc deleted file mode 100644 index c5cf828..0000000 --- a/api_modules/limit/requirements_module_limit.adoc +++ /dev/null @@ -1,37 +0,0 @@ -[[rm_limit]] -[cols="1,4",width="90%"] -|=== -2+|*Requirements Module* -2+|http://www.opengis.net/spec/ogcapi-common-2/1.0/rm/limit -|Target type |Web API Query Parameter -|=== - -The `limit` parameter limits the number of resources that can be returned in a single response. - -include::./requirements/REQ_rc-limit-definition.adoc[] - -While the processing of the `limit` parameter is specific to the resource and operation for which it is applied, there is a general set of requirements which all implementations must address. - -include::./requirements/REQ_rc-limit-response.adoc[] - -The number of resources returned depends on the server and the value of the `limit` parameter. - -* The client can request a limit to the number of resources returned. -* The server may have a default value for the limit, and a maximum limit. -* If the server has any more results available than it returns (the number it returns is less than or equal to the requested/default/maximum limit) then the server will include a link to the next set of results. - -include::./recommendations/PER_rc-server-limit.adoc[] - -Since many servers will place a limit on the size of their responses, clients should be prepared to handle a paged response even if they have not specified a `limit` parameter in their query. - -The effect of the limit parameter is to divide the response into a number of pages. Each page (except for the last) contains the specified number of entities. The response contains the first page. Additional pages can be accessed through hyperlink navigation. - -include::./recommendations/REC_rc-next-1.adoc[] - -include::./recommendations/REC_rc-next-2.adoc[] - -include::./recommendations/REC_rc-next-3.adoc[] - -Providing `prev` links supports navigating back and forth between pages, but depending on the implementation approach it may be too complex to implement. - -include::./recommendations/PER_rc-prev.adoc[] diff --git a/api_modules/template/README.md b/api_modules/template/README.md deleted file mode 100644 index 9b0c03b..0000000 --- a/api_modules/template/README.md +++ /dev/null @@ -1,11 +0,0 @@ -# Standard template - -This folder contains the content for the OGC API - Features - Part n: TBD standard. - -The repo is organized as follows: - -* standard - the main standard document content - - organized in multiple sections and directories -* openapi - normative OpenAPI components specified by the standard -* xml - normative XML/XSD components specified by the standard -* examples - JSON and XML examples diff --git a/api_modules/template/examples/json/README.md b/api_modules/template/examples/json/README.md deleted file mode 100644 index 1e628fd..0000000 --- a/api_modules/template/examples/json/README.md +++ /dev/null @@ -1 +0,0 @@ -Add JSON examples to this directory. If not used, delete the directory. diff --git a/api_modules/template/examples/xml/README.md b/api_modules/template/examples/xml/README.md deleted file mode 100644 index 49822f5..0000000 --- a/api_modules/template/examples/xml/README.md +++ /dev/null @@ -1 +0,0 @@ -Add XML examples to this directory. If not used, delete the directory. diff --git a/api_modules/template/openapi/examples/README.md b/api_modules/template/openapi/examples/README.md deleted file mode 100644 index 4bb548e..0000000 --- a/api_modules/template/openapi/examples/README.md +++ /dev/null @@ -1 +0,0 @@ -Add OpenAPI YAML examples to this directory. If not used, delete the directory. diff --git a/api_modules/template/openapi/parameters/README.md b/api_modules/template/openapi/parameters/README.md deleted file mode 100644 index 3a15ee4..0000000 --- a/api_modules/template/openapi/parameters/README.md +++ /dev/null @@ -1 +0,0 @@ -Add OpenAPI parameter components to this directory. If not used, delete the directory. diff --git a/api_modules/template/openapi/responses/README.md b/api_modules/template/openapi/responses/README.md deleted file mode 100644 index 470ddc2..0000000 --- a/api_modules/template/openapi/responses/README.md +++ /dev/null @@ -1 +0,0 @@ -Add OpenAPI response components to this directory. If not used, delete the directory. diff --git a/api_modules/template/openapi/schemas/README.md b/api_modules/template/openapi/schemas/README.md deleted file mode 100644 index 0c6787a..0000000 --- a/api_modules/template/openapi/schemas/README.md +++ /dev/null @@ -1 +0,0 @@ -Add OpenAPI schema components to this directory. If not used, delete the directory. diff --git a/api_modules/template/standard/19-xxx.adoc b/api_modules/template/standard/19-xxx.adoc deleted file mode 100644 index 9a4837e..0000000 --- a/api_modules/template/standard/19-xxx.adoc +++ /dev/null @@ -1,121 +0,0 @@ -:Title: OGC API - Features - Part n: TBD -:titletext: OGC API - Features - Part n: TBD -:doctype: book -:encoding: utf-8 -:lang: en -:toc: -:toc-placement!: -:toclevels: 3 -:sectnums: -:sectnumlevels: 4 -:sectanchors: -:source-highlighter: pygments -:figure-id: 0 -:table-id: 0 -:req-id: 0 -:rec-id: 0 -:per-id: 0 -:source-highlighter: pygments -:pygments-style: borland -:pygments-linenums-mode: table - -= {title} - -<<< -[cols = ">",frame = "none",grid = "none"] -|=== -|{set:cellbgcolor:#FFFFFF} -|[big]*Open Geospatial Consortium* -|Submission Date: -|Approval Date:   -|Publication Date:   -|External identifier of this OGC(R) document: http://www.opengis.net/doc/IS/ogcapi-features-n/1.0 -|Internal reference number of this OGC(R) document:    19-xxx -|Version: link:http://docs.opengeospatial.org/DRAFTS/19-xxx.html[1.0.0-SNAPSHOT (Editor's draft)] -|Latest Published Draft: n/a -|Category: OGC(R) Implementation Specification -|Editors: TBD -|=== - -[cols = "^", frame = "none"] -|=== -|[big]*{titletext}* -|=== - -[cols = "^", frame = "none", grid = "none"] -|=== -|*Copyright notice* -|Copyright (C) 2019 Open Geospatial Consortium -|To obtain additional rights of use, visit http://www.opengeospatial.org/legal/ -|=== - -[cols = "^", frame = "none"] -|=== -|*Warning* -|=== - -This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard. - -Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation. - -[width = "50%", grid = "none"] -|=== -|Document type:    OGC® Standard -|Document subtype:    Interface -|Document stage:    Draft -|Document language:  English -|=== - -<<< - License Agreement - -[small]#Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.# - -[small]#If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.# - -[small]#THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.# - -[small]#THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.# - -[small]#This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR's sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.# - -[small]#Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.# - -<<< -toc::[] - -<<< - -//// -Make sure to complete each included document -//// -include::clause_0_front_material.adoc[] - -include::clause_1_scope.adoc[] - -include::clause_2_conformance.adoc[] - -include::clause_3_references.adoc[] - -include::clause_4_terms_and_definitions.adoc[] - -include::clause_5_conventions.adoc[] - -include::clause_6_cc.adoc[] - -include::clause_7_media_types.adoc[] - -include::clause_8_security_considerations.adoc[] - -<<< -include::annex_ats.adoc[] - -<<< -//// -Revision History should be the last annex before the Bibliography -Bibliography should be the last annex -//// -include::annex_history.adoc[] - -<<< -include::annex_bibliography.adoc[] diff --git a/api_modules/template/standard/README.md b/api_modules/template/standard/README.md deleted file mode 100644 index 50d8ef0..0000000 --- a/api_modules/template/standard/README.md +++ /dev/null @@ -1 +0,0 @@ -This folder contains the text for part 1 of the OGC API Features standard. diff --git a/api_modules/template/standard/abstract_tests/README.md b/api_modules/template/standard/abstract_tests/README.md deleted file mode 100644 index ee9b6e6..0000000 --- a/api_modules/template/standard/abstract_tests/README.md +++ /dev/null @@ -1,27 +0,0 @@ -This folder contains the Abstract Test Suite. - -Each file describes a single test. The naming convention for these files is: - -"cc/TESTn.adoc" where "cc" corresponds to the identifier for the requirements class and "n" corresponds to the test number. Numbers should have preceeding zeros appropriate for the total number of tests in the conformance class (e.g., the first test could be TEST001 if less than 1000 tests are anticipated). - -The test is expressed according to this pattern: - -```` -===== Test case title - -(( additional discussion, if needed )) - -====== a) Test Purpose: -(( description )) - -====== b) Pre-conditions: -* (( list all preconditions )) - -====== c) Test Method: -* (( steps to execute and assertions to test )) - -====== d) References: -* <> -```` - -NOTE: for each test, there must be one or more requirements in the "requirements" folder. diff --git a/api_modules/template/standard/abstract_tests/cc/TEST001.adoc b/api_modules/template/standard/abstract_tests/cc/TEST001.adoc deleted file mode 100644 index 1c3db3b..0000000 --- a/api_modules/template/standard/abstract_tests/cc/TEST001.adoc +++ /dev/null @@ -1,15 +0,0 @@ -===== Test case title - -(( additional discussion, if needed )) - -====== a) Test Purpose: -(( description )) - -====== b) Pre-conditions: -* (( list all preconditions )) - -====== c) Test Method: -* (( steps to execute and assertions to test )) - -====== d) References: -* <> diff --git a/api_modules/template/standard/annex_ats.adoc b/api_modules/template/standard/annex_ats.adoc deleted file mode 100644 index 73471e1..0000000 --- a/api_modules/template/standard/annex_ats.adoc +++ /dev/null @@ -1,8 +0,0 @@ -[[ats]] -[appendix] -:appendix-caption: Annex -== Abstract Test Suite (Normative) - -(( add test cases )) - -include::abstract_tests/cc/TEST001.adoc[] diff --git a/api_modules/template/standard/annex_bibliography.adoc b/api_modules/template/standard/annex_bibliography.adoc deleted file mode 100644 index d5d7e21..0000000 --- a/api_modules/template/standard/annex_bibliography.adoc +++ /dev/null @@ -1,8 +0,0 @@ -[appendix] -:appendix-caption: Annex -[[Bibliography]] -= Bibliography - -* [[OAFeat-Guide]] Heazel, Ch.: *Guide to OGC API - Features*, https://example.org/fixme -* [[OpenAPI]] Open API Initiative: *OpenAPI Specification 3.0.2*, -https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md diff --git a/api_modules/template/standard/annex_history.adoc b/api_modules/template/standard/annex_history.adoc deleted file mode 100644 index 49b46da..0000000 --- a/api_modules/template/standard/annex_history.adoc +++ /dev/null @@ -1,9 +0,0 @@ -[appendix] -:appendix-caption: Annex -== Revision History - -[cols="12,18,12,12,46",options="header"] -|=== -|Date |Release |Editor | Primary clauses modified |Description -|2019-xx-xx |1.0.0-SNAPSHOT |J. Doe |all |initial version -|=== diff --git a/api_modules/template/standard/annex_n.adoc b/api_modules/template/standard/annex_n.adoc deleted file mode 100644 index c7e9116..0000000 --- a/api_modules/template/standard/annex_n.adoc +++ /dev/null @@ -1,6 +0,0 @@ -[appendix] -:appendix-caption: Annex -== Title ( {Normative/Informative} ) - -[NOTE] -Place other Annex material in sequential annexes beginning with "B" and leave final two annexes for the Revision History and Bibliography diff --git a/api_modules/template/standard/clause_0_front_material.adoc b/api_modules/template/standard/clause_0_front_material.adoc deleted file mode 100644 index 5ecd653..0000000 --- a/api_modules/template/standard/clause_0_front_material.adoc +++ /dev/null @@ -1,38 +0,0 @@ -[big]*i. Abstract* - -OGC API standards define modular API building blocks to spatially enable Web APIs in a consistent way. The <> is used to define the API building blocks. - -OGC API Features provides API building blocks to create, modify and query features on the Web. OGC API Features is comprised of multiple parts, each of them is a separate standard. - -This part extends the core capabilities specified in <> with ... - -(( add high-level description of the scope and text that provides an overview of the additional API building blocks )) - -CAUTION: This is a DRAFT version of the nth part of the OGC API - Features standards. This draft is not complete and there are open issues that are still under discussion. - -[big]*ii. Keywords* - -The following are keywords to be used by search engines and document catalogues. - -(( add comma-separated keywords )) - -[big]*iii. Preface* - -Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium Inc. shall not be held responsible for identifying any or all such patent rights. - -Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation. - -[big]*iv. Submitting organizations* - -The following organizations submitted this document to the Open Geospatial Consortium (OGC): - -* ... - -[big]*v. Submitters* - -All questions regarding this submission should be directed to the editors or the submitters: - -|=== -|*Name* |*Affiliation* -|NN _(editor)_ |NN -|=== diff --git a/api_modules/template/standard/clause_1_scope.adoc b/api_modules/template/standard/clause_1_scope.adoc deleted file mode 100644 index 5764800..0000000 --- a/api_modules/template/standard/clause_1_scope.adoc +++ /dev/null @@ -1,5 +0,0 @@ -== Scope - -This document specifies the behavior of Web APIs that provide access to features ... - -(( add scope statement )) diff --git a/api_modules/template/standard/clause_2_conformance.adoc b/api_modules/template/standard/clause_2_conformance.adoc deleted file mode 100644 index 6f54805..0000000 --- a/api_modules/template/standard/clause_2_conformance.adoc +++ /dev/null @@ -1,10 +0,0 @@ -== Conformance - -This standard defines one requirements / conformance class <>. -The standardization target is "Web APIs". - -Conformance with this standard shall be checked using all the relevant tests -specified in <> 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. diff --git a/api_modules/template/standard/clause_3_references.adoc b/api_modules/template/standard/clause_3_references.adoc deleted file mode 100644 index 19be4e4..0000000 --- a/api_modules/template/standard/clause_3_references.adoc +++ /dev/null @@ -1,4 +0,0 @@ -== References -The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies. - -* [[OAFeat-1]] Portele, C., Vretanos, P.: OGC 17-069r2, *OGC API - Features - Part 1: Core*, http://example.com/fixme diff --git a/api_modules/template/standard/clause_4_terms_and_definitions.adoc b/api_modules/template/standard/clause_4_terms_and_definitions.adoc deleted file mode 100644 index 135e16a..0000000 --- a/api_modules/template/standard/clause_4_terms_and_definitions.adoc +++ /dev/null @@ -1,11 +0,0 @@ -== Terms and Definitions -This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r9], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard. - -For the purposes of this document, the following additional terms and definitions apply in addition to the terms defined -in <>. - -=== term 1 -definition [source] - -=== term 2 -definition [source] diff --git a/api_modules/template/standard/clause_5_conventions.adoc b/api_modules/template/standard/clause_5_conventions.adoc deleted file mode 100644 index 75d3cb4..0000000 --- a/api_modules/template/standard/clause_5_conventions.adoc +++ /dev/null @@ -1,3 +0,0 @@ -== Conventions and background - -See <>, Clauses 5 and 6. diff --git a/api_modules/template/standard/clause_6_cc.adoc b/api_modules/template/standard/clause_6_cc.adoc deleted file mode 100644 index e83908d..0000000 --- a/api_modules/template/standard/clause_6_cc.adoc +++ /dev/null @@ -1,16 +0,0 @@ -== Requirements Class "CC" - -[[cc-overview]] -=== Overview - -include::requirements/requirements_class_cc.adoc[] - -(( add text how this part extends OGC API Features )) - -(( use the following as templates for normative statements: )) - -include::requirements/cc/REQ_req.adoc[] - -include::recommendations/cc/REC_rec.adoc[] - -include::recommendations/cc/PER_per.adoc[] diff --git a/api_modules/template/standard/clause_7_media_types.adoc b/api_modules/template/standard/clause_7_media_types.adoc deleted file mode 100644 index 63bb4da..0000000 --- a/api_modules/template/standard/clause_7_media_types.adoc +++ /dev/null @@ -1,6 +0,0 @@ -[[mediatypes]] -== Media Types - -See <>, Clause 10. - -(( add additional text as needed )) diff --git a/api_modules/template/standard/clause_8_security_considerations.adoc b/api_modules/template/standard/clause_8_security_considerations.adoc deleted file mode 100644 index c88dbec..0000000 --- a/api_modules/template/standard/clause_8_security_considerations.adoc +++ /dev/null @@ -1,5 +0,0 @@ -== Security Considerations - -See <>, Clause 11. - -(( add additional text as needed )) diff --git a/api_modules/template/standard/figures/README.md b/api_modules/template/standard/figures/README.md deleted file mode 100644 index e5d667f..0000000 --- a/api_modules/template/standard/figures/README.md +++ /dev/null @@ -1,5 +0,0 @@ -Figures go here. - -Each figure is a separate file with the naming convention: - -"PTm_FIGn.xxx" where "m" is a number with leading zeroes appropriate for the total number of parts, "n" is a number with leading zeroes appropriate for the total number of figures and "xxx" is the appropriate extension for the file type. \ No newline at end of file diff --git a/api_modules/template/standard/images/README.md b/api_modules/template/standard/images/README.md deleted file mode 100644 index c8f3404..0000000 --- a/api_modules/template/standard/images/README.md +++ /dev/null @@ -1,9 +0,0 @@ -Image files for graphics go here. - -Each graphic is a separate file with the naming convention: - -"FIGn.xxx" where "n" is a number with leading zeroes appropriate for the total number of figures and "xxx" is the appropriate extension for the file type. - -or, for other graphics not associated with figures: - -"GRPn.xxx" where "n" is a sequential number with leading zeroes appropriate for the total number of graphics and "xxx" is the appropriate extension for the file type. diff --git a/api_modules/template/standard/recommendations/cc/PER_per.adoc b/api_modules/template/standard/recommendations/cc/PER_per.adoc deleted file mode 100644 index b756551..0000000 --- a/api_modules/template/standard/recommendations/cc/PER_per.adoc +++ /dev/null @@ -1,6 +0,0 @@ -[[per_cc_per]] -[width="90%",cols="2,6a"] -|=== -^|*Permission {counter:per-id}* |*/per/cc/per* -^|A |Abc MAY .... -|=== diff --git a/api_modules/template/standard/recommendations/cc/REC_rec.adoc b/api_modules/template/standard/recommendations/cc/REC_rec.adoc deleted file mode 100644 index 7b4a72d..0000000 --- a/api_modules/template/standard/recommendations/cc/REC_rec.adoc +++ /dev/null @@ -1,6 +0,0 @@ -[[rec_cc_rec]] -[width="90%",cols="2,6a"] -|=== -^|*Recommendation {counter:rec-id}* |*/rec/cc/rec* -^|A |Xyz SHOULD ... -|=== diff --git a/api_modules/template/standard/requirements/README.md b/api_modules/template/standard/requirements/README.md deleted file mode 100644 index 52bbbe7..0000000 --- a/api_modules/template/standard/requirements/README.md +++ /dev/null @@ -1,24 +0,0 @@ -This folder contains requirements description. - -Each file is a single requirement. The naming convention for these files is: - -"cc/REQ_req.adoc" where "cc" corresponds to the identifier for the requirements class and "req" corresponds to the identifier for the requirement. Example: "core/REQ_f-op.adoc". - -The requirement files are integrated into the main document as links. - -The requirement is expressed according to this pattern: - -```` -[[req_cc_req]] -[width="90%",cols="2,6a"] -|=== -^|*Requirement {counter:req-id}* |*/req/cc/req* -^|A |... SHALL ... -^|B |... SHALL ... -|=== -```` - -Multiple statements should only be in a single requirement, if there is a direct -dependency. - -For each requirement, there should be a corresponding Abstract Test in the "abstract_tests" folder. diff --git a/api_modules/template/standard/requirements/cc/REQ_req.adoc b/api_modules/template/standard/requirements/cc/REQ_req.adoc deleted file mode 100644 index 9ed4685..0000000 --- a/api_modules/template/standard/requirements/cc/REQ_req.adoc +++ /dev/null @@ -1,7 +0,0 @@ -[[req_cc_req]] -[width="90%",cols="2,6a"] -|=== -^|*Requirement {counter:req-id}* |*/req/cc/req* -^|A |Xyz SHALL ... -^|B |Abc SHALL ... -|=== diff --git a/api_modules/template/standard/requirements/requirements_class_cc.adoc b/api_modules/template/standard/requirements/requirements_class_cc.adoc deleted file mode 100644 index ed31c2e..0000000 --- a/api_modules/template/standard/requirements/requirements_class_cc.adoc +++ /dev/null @@ -1,8 +0,0 @@ -[[rc_cc]] -[cols="1,4",width="90%"] -|=== -2+|*Requirements Class* -2+|http://www.opengis.net/spec/ogcapi-features-1/1.0/req/cc -|Target type |Web API -|Dependency |<> -|=== diff --git a/api_modules/template/standard/standard.css b/api_modules/template/standard/standard.css deleted file mode 100644 index 8271ec5..0000000 --- a/api_modules/template/standard/standard.css +++ /dev/null @@ -1,2134 +0,0 @@ -/*! normalize.css v2.1.2 | MIT License | git.io/normalize */ -/* ========================================================================== HTML5 display definitions ========================================================================== */ -/** Correct `block` display not defined in IE 8/9. */ -article, aside, details, figcaption, figure, footer, header, hgroup, main, nav, section, summary { - display: block; -} - -/** Correct `inline-block` display not defined in IE 8/9. */ -audio, canvas, video { - display: inline-block; -} - -/** Prevent modern browsers from displaying `audio` without controls. Remove excess height in iOS 5 devices. */ -audio:not([controls]) { - display: none; - height: 0; -} - -/** Address `[hidden]` styling not present in IE 8/9. Hide the `template` element in IE, Safari, and Firefox < 22. */ -[hidden], template { - display: none; -} - -script { - display: none !important; -} - -/* ========================================================================== Base ========================================================================== */ -/** 1. Set default font family to sans-serif. 2. Prevent iOS text size adjust after orientation change, without disabling user zoom. */ -html { - font-family: sans-serif; /* 1 */ - -ms-text-size-adjust: 100%; /* 2 */ - -webkit-text-size-adjust: 100%; /* 2 */ -} - -/** Remove default margin. */ -body { - margin: 0; -} - -/* ========================================================================== Links ========================================================================== */ -/** Remove the gray background color from active links in IE 10. */ -a { - background: transparent; -} - -/** Address `outline` inconsistency between Chrome and other browsers. */ -a:focus { - outline: thin dotted; -} - -/** Improve readability when focused and also mouse hovered in all browsers. */ -a:active, a:hover { - outline: 0; -} - -/* ========================================================================== Typography ========================================================================== */ -/** Address variable `h1` font-size and margin within `section` and `article` contexts in Firefox 4+, Safari 5, and Chrome. */ -h1 { - font-size: 2em; - margin: 0.67em 0; -} - -/** Address styling not present in IE 8/9, Safari 5, and Chrome. */ -abbr[title] { - border-bottom: 1px dotted; -} - -/** Address style set to `bolder` in Firefox 4+, Safari 5, and Chrome. */ -b, strong { - font-weight: bold; -} - -/** Address styling not present in Safari 5 and Chrome. */ -dfn { - font-style: italic; -} - -/** Address differences between Firefox and other browsers. */ -hr { - -moz-box-sizing: content-box; - box-sizing: content-box; - height: 0; -} - -/** Address styling not present in IE 8/9. */ -mark { - background: #ff0; - color: #000; -} - -/** Correct font family set oddly in Safari 5 and Chrome. */ -code, kbd, pre, samp { - font-family: monospace, serif; - font-size: 1em; -} - -/** Improve readability of pre-formatted text in all browsers. */ -pre { - white-space: pre-wrap; -} - -/** Set consistent quote types. */ -q { - quotes: "\201C" "\201D" "\2018" "\2019"; -} - -/** Address inconsistent and variable font size in all browsers. */ -small { - font-size: 80%; -} - -/** Address inconsistent and variable font size in all browsers. */ -big { - font-size: 160%; -} - -/** Prevent `sub` and `sup` affecting `line-height` in all browsers. */ -sub, sup { - font-size: 75%; - line-height: 0; - position: relative; - vertical-align: baseline; -} - -sup { - top: -0.5em; -} - -sub { - bottom: -0.25em; -} - -/* ========================================================================== Embedded content ========================================================================== */ -/** Remove border when inside `a` element in IE 8/9. */ -img { - border: 0; -} - -/** Correct overflow displayed oddly in IE 9. */ -svg:not(:root) { - overflow: hidden; -} - -/* ========================================================================== Figures ========================================================================== */ -/** Address margin not present in IE 8/9 and Safari 5. */ -figure { - margin: 0; -} - -/* ========================================================================== Forms ========================================================================== */ -/** Define consistent border, margin, and padding. */ -fieldset { - border: 1px solid #c0c0c0; - margin: 0 2px; - padding: 0.35em 0.625em 0.75em; -} - -/** 1. Correct `color` not being inherited in IE 8/9. 2. Remove padding so people aren't caught out if they zero out fieldsets. */ -legend { - border: 0; /* 1 */ - padding: 0; /* 2 */ -} - -/** 1. Correct font family not being inherited in all browsers. 2. Correct font size not being inherited in all browsers. 3. Address margins set differently in Firefox 4+, Safari 5, and Chrome. */ -button, input, select, textarea { - font-family: inherit; /* 1 */ - font-size: 100%; /* 2 */ - margin: 0; /* 3 */ -} - -/** Address Firefox 4+ setting `line-height` on `input` using `!important` in the UA stylesheet. */ -button, input { - line-height: normal; -} - -/** Address inconsistent `text-transform` inheritance for `button` and `select`. All other form control elements do not inherit `text-transform` values. Correct `button` style inheritance in Chrome, Safari 5+, and IE 8+. Correct `select` style inheritance in Firefox 4+ and Opera. */ -button, select { - text-transform: none; -} - -/** 1. Avoid the WebKit bug in Android 4.0.* where (2) destroys native `audio` and `video` controls. 2. Correct inability to style clickable `input` types in iOS. 3. Improve usability and consistency of cursor style between image-type `input` and others. */ -button, html input[type="button"], input[type="reset"], input[type="submit"] { - -webkit-appearance: button; /* 2 */ - cursor: pointer; /* 3 */ -} - -/** Re-set default cursor for disabled elements. */ -button[disabled], html input[disabled] { - cursor: default; -} - -/** 1. Address box sizing set to `content-box` in IE 8/9. 2. Remove excess padding in IE 8/9. */ -input[type="checkbox"], input[type="radio"] { - box-sizing: border-box; /* 1 */ - padding: 0; /* 2 */ -} - -/** 1. Address `appearance` set to `searchfield` in Safari 5 and Chrome. 2. Address `box-sizing` set to `border-box` in Safari 5 and Chrome (include `-moz` to future-proof). */ -input[type="search"] { - -webkit-appearance: textfield; /* 1 */ - -moz-box-sizing: content-box; - -webkit-box-sizing: content-box; /* 2 */ - box-sizing: content-box; -} - -/** Remove inner padding and search cancel button in Safari 5 and Chrome on OS X. */ -input[type="search"]::-webkit-search-cancel-button, input[type="search"]::-webkit-search-decoration { - -webkit-appearance: none; -} - -/** Remove inner padding and border in Firefox 4+. */ -button::-moz-focus-inner, input::-moz-focus-inner { - border: 0; - padding: 0; -} - -/** 1. Remove default vertical scrollbar in IE 8/9. 2. Improve readability and alignment in all browsers. */ -textarea { - overflow: auto; /* 1 */ - vertical-align: top; /* 2 */ -} - -/* ========================================================================== Tables ========================================================================== */ -/** Remove most spacing between table cells. */ -table { - border-collapse: collapse; - border-spacing: 0; -} - -meta.foundation-mq-small { - font-family: "only screen and (min-width: 768px)"; - width: 768px; -} - -meta.foundation-mq-medium { - font-family: "only screen and (min-width:1280px)"; - width: 1280px; -} - -meta.foundation-mq-large { - font-family: "only screen and (min-width:1440px)"; - width: 1440px; -} - -*, *:before, *:after { - -moz-box-sizing: border-box; - -webkit-box-sizing: border-box; - box-sizing: border-box; -} - -html, body { - font-size: 100%; -} - -body { - background: white; - color: rgba(0, 0, 0, 0.8); - padding: 0; - margin: 0; - font-family: "Noto Serif", "DejaVu Serif", serif; - font-weight: normal; - font-style: normal; - line-height: 1; - position: relative; - cursor: auto; -} - -a:hover { - cursor: pointer; -} - -img, object, embed { - max-width: 100%; - height: auto; -} - -object, embed { - height: 100%; -} - -img { - -ms-interpolation-mode: bicubic; -} - -#map_canvas img, #map_canvas embed, #map_canvas object, .map_canvas img, .map_canvas embed, .map_canvas object { - max-width: none !important; -} - -.left { - float: left !important; -} - -.right { - float: right !important; -} - -.text-left { - text-align: left !important; -} - -.text-right { - text-align: right !important; -} - -.text-center { - text-align: center !important; -} - -.text-justify { - text-align: justify !important; -} - -.hide { - display: none; -} - -.antialiased, body { - -webkit-font-smoothing: antialiased; -} - -img { - display: inline-block; - vertical-align: middle; -} - -textarea { - height: auto; - min-height: 50px; -} - -select { - width: 100%; -} - -p.lead, .paragraph.lead > p, #preamble > .sectionbody > .paragraph:first-of-type p { - font-size: 1.21875em; - line-height: 1.6; -} - -.subheader, .admonitionblock td.content > .title, .audioblock > .title, .exampleblock > .title, .imageblock > .title, .listingblock > .title, .literalblock > .title, .stemblock > .title, .openblock > .title, .paragraph > .title, .quoteblock > .title, table.tableblock > .title, .verseblock > .title, .videoblock > .title, .dlist > .title, .olist > .title, .ulist > .title, .qlist > .title, .hdlist > .title { - line-height: 1.45; - color: #000000; - font-weight: normal; - margin-top: 0; - margin-bottom: 0.25em; -} - -/* Typography resets */ -div, dl, dt, dd, ul, ol, li, h1, h2, h3, #toctitle, .sidebarblock > .content > .title, h4, h5, h6, pre, form, p, blockquote, th, td { - margin: 0; - padding: 0; - direction: ltr; -} - -/* Default Link Styles */ -a { - color: #2156a5; - text-decoration: underline; - line-height: inherit; -} - -a:hover, a:focus { - color: #1d4b8f; -} - -a img { - border: none; -} - -/* Default paragraph styles */ -p { - font-family: inherit; - font-weight: normal; - font-size: 1em; - line-height: 1.6; - margin-bottom: 1.25em; - text-rendering: optimizeLegibility; -} - -p aside { - font-size: 0.875em; - line-height: 1.35; - font-style: italic; -} - -/* Default header styles */ -h1, h2, h3, #toctitle, .sidebarblock > .content > .title, h4, h5, h6 { - font-family: "Noto Serif", "DejaVu Serif", serif; - font-weight: 300; - font-style: normal; - color: #000000; - text-rendering: optimizeLegibility; - margin-top: 1em; - margin-bottom: 0.5em; - line-height: 1.0125em; -} - -h1 small, h2 small, h3 small, #toctitle small, .sidebarblock > .content > .title small, h4 small, h5 small, h6 small { - font-size: 60%; - color: #000000; - line-height: 0; -} - -h1 { - font-size: 160%; -} - -h2 { - font-size: 160%; -} - -h3, #toctitle, .sidebarblock > .content > .title { - font-size: 140%; -} - -h4 { - font-size: 1em; -} - -h5 { - font-size: 1em; -} - -h6 { - font-size: 1em; -} - -hr { - border: solid #ddddd8; - border-width: 1px 0 0; - clear: both; - margin: 1.25em 0 1.1875em; - height: 0; -} - -/* Helpful Typography Defaults */ -em, i { - font-style: italic; - line-height: inherit; -} - -strong, b { - font-weight: bold; - line-height: inherit; -} - -small { - font-size: 60%; - line-height: inherit; -} - -code { - font-family: "Droid Sans Mono", "DejaVu Sans Mono", "Monospace", monospace; - font-weight: normal; - color: rgba(0, 0, 0, 0.9); -} - -/* Lists */ -ul, ol, dl { - font-size: 1em; - line-height: 1.6; - margin-bottom: 1.25em; - list-style-position: outside; - font-family: inherit; -} - -ul, ol { - margin-left: 1.5em; -} - -ul.no-bullet, ol.no-bullet { - margin-left: 1.5em; -} - -/* Unordered Lists */ -ul li ul, ul li ol { - margin-left: 1.25em; - margin-bottom: 0; - font-size: 1em; /* Override nested font-size change */ -} - -ul.square li ul, ul.circle li ul, ul.disc li ul { - list-style: inherit; -} - -ul.square { - list-style-type: square; -} - -ul.circle { - list-style-type: circle; -} - -ul.disc { - list-style-type: disc; -} - -ul.no-bullet { - list-style: none; -} - -/* Ordered Lists */ -ol li ul, ol li ol { - margin-left: 1.25em; - margin-bottom: 0; -} - -/* Definition Lists */ -dl dt { - margin-bottom: 0.3125em; - font-weight: bold; -} - -dl dd { - margin-bottom: 1.25em; -} - -/* Abbreviations */ -abbr, acronym { - text-transform: uppercase; - font-size: 90%; - color: rgba(0, 0, 0, 0.8); - border-bottom: 1px dotted #dddddd; - cursor: help; -} - -abbr { - text-transform: none; -} - -/* Blockquotes */ -blockquote { - margin: 0 0 1.25em; - padding: 0.5625em 1.25em 0 1.1875em; - border-left: 1px solid #dddddd; -} - -blockquote cite { - display: block; - font-size: 0.9375em; - color: rgba(0, 0, 0, 0.6); -} - -blockquote cite:before { - content: "\2014 \0020"; -} - -blockquote cite a, blockquote cite a:visited { - color: rgba(0, 0, 0, 0.6); -} - -blockquote, blockquote p { - line-height: 1.6; - color: rgba(0, 0, 0, 0.85); -} - -/* Microformats */ -.vcard { - display: inline-block; - margin: 0 0 1.25em 0; - border: 1px solid #dddddd; - padding: 0.625em 0.75em; -} - -.vcard li { - margin: 0; - display: block; -} - -.vcard .fn { - font-weight: bold; - font-size: 0.9375em; -} - -.vevent .summary { - font-weight: bold; -} - -.vevent abbr { - cursor: auto; - text-decoration: none; - font-weight: bold; - border: none; - padding: 0 0.0625em; -} - -@media only screen and (min-width: 768px) { - h1, h2, h3, #toctitle, .sidebarblock > .content > .title, h4, h5, h6 { - font-family: "Noto Serif", "DejaVu Serif", serif; - line-height: 1.2; - font-weight: 300; - font-style: normal; - color: #000000; - text-rendering: optimizeLegibility; - margin-top: 1em; - margin-bottom: 0.5em; - line-height: 1.0125em; - } - - h1 { - font-size: 160%; - font-weight: bold; - } - - h2 { - font-size: 160%; - font-weight: bold; - } - - h3, #toctitle, .sidebarblock > .content > .title { - font-size: 140%; - font-weight: bold; - } - - h4 { - font-size: 1em; - } -} - -/* Tables */ -table { - background: white; - margin-bottom: 1.25em; - border: solid 1px #dedede; -} - -table thead, table tfoot { - background: #f7f8f7; - font-weight: bold; -} - -table thead tr th, table thead tr td, table tfoot tr th, table tfoot tr td { - padding: 0.5em 0.625em 0.625em; - font-size: inherit; - color: rgba(0, 0, 0, 0.8); - text-align: left; -} - -table tr th, table tr td { - padding: 0.5625em 0.625em; - font-size: inherit; - color: rgba(0, 0, 0, 0.8); -} - -table tr.even, table tr.alt, table tr:nth-of-type(even) { - background: #f8f8f7; -} - -table thead tr th, table tfoot tr th, table tbody tr td, table tr td, table tfoot tr td { - display: table-cell; - line-height: 1.6; -} - -h1, h2, h3, #toctitle, .sidebarblock > .content > .title, h4, h5, h6 { - line-height: 1.2; - word-spacing: -0.05em; -} - -h1 strong, h2 strong, h3 strong, #toctitle strong, .sidebarblock > .content > .title strong, h4 strong, h5 strong, h6 strong { - font-weight: 400; -} - -.clearfix:before, .clearfix:after, .float-group:before, .float-group:after { - content: " "; - display: table; -} - -.clearfix:after, .float-group:after { - clear: both; -} - -*:not(pre) > code { - font-size: 0.9375em; - font-style: normal !important; - letter-spacing: 0; - padding: 0.1em 0.5ex; - word-spacing: -0.15em; - background-color: #f7f7f8; - -webkit-border-radius: 4px; - border-radius: 4px; - line-height: 1.45; - text-rendering: optimizeSpeed; -} - -pre, pre > code { - line-height: 1.45; - color: rgba(0, 0, 0, 0.9); - font-family: "Droid Sans Mono", "DejaVu Sans Mono", "Monospace", monospace; - font-weight: normal; - text-rendering: optimizeSpeed; -} - -.keyseq { - color: rgba(51, 51, 51, 0.8); -} - -kbd { - display: inline-block; - color: rgba(0, 0, 0, 0.8); - font-size: 0.75em; - line-height: 1.4; - background-color: #f7f7f7; - border: 1px solid #ccc; - -webkit-border-radius: 3px; - border-radius: 3px; - -webkit-box-shadow: 0 1px 0 rgba(0, 0, 0, 0.2), 0 0 0 0.1em white inset; - box-shadow: 0 1px 0 rgba(0, 0, 0, 0.2), 0 0 0 0.1em white inset; - margin: -0.15em 0.15em 0 0.15em; - padding: 0.2em 0.6em 0.2em 0.5em; - vertical-align: middle; - white-space: nowrap; -} - -.keyseq kbd:first-child { - margin-left: 0; -} - -.keyseq kbd:last-child { - margin-right: 0; -} - -.menuseq, .menu { - color: rgba(0, 0, 0, 0.8); -} - -b.button:before, b.button:after { - position: relative; - top: -1px; - font-weight: normal; -} - -b.button:before { - content: "["; - padding: 0 3px 0 2px; -} - -b.button:after { - content: "]"; - padding: 0 2px 0 3px; -} - -p a > code:hover { - color: rgba(0, 0, 0, 0.9); -} - -#header, #content, #footnotes, #footer { - width: 100%; - margin-left: auto; - margin-right: auto; - margin-top: 0; - margin-bottom: 0; - max-width: 62.5em; - *zoom: 1; - position: relative; - padding-left: 0.9375em; - padding-right: 0.9375em; -} - -#header:before, #header:after, #content:before, #content:after, #footnotes:before, #footnotes:after, #footer:before, #footer:after { - content: " "; - display: table; -} - -#header:after, #content:after, #footnotes:after, #footer:after { - clear: both; -} - -#content { - margin-top: 1.25em; -} - -#content:before { - content: none; -} - -#header > h1:first-child { - color: rgba(0, 0, 0, 0.85); - margin-top: 2.25rem; - margin-bottom: 0; -} - -#header > h1:first-child + #toc { - margin-top: 8px; - border-top: 1px solid #ddddd8; -} - -#header > h1:only-child, body.toc2 #header > h1:nth-last-child(2) { - border-bottom: 1px solid #ddddd8; - padding-bottom: 8px; -} - -#header .details { - border-bottom: 1px solid #ddddd8; - line-height: 1.45; - padding-top: 0.25em; - padding-bottom: 0.25em; - padding-left: 0.25em; - color: rgba(0, 0, 0, 0.6); - display: -ms-flexbox; - display: -webkit-flex; - display: flex; - -ms-flex-flow: row wrap; - -webkit-flex-flow: row wrap; - flex-flow: row wrap; -} - -#header .details span:first-child { - margin-left: -0.125em; -} - -#header .details span.email a { - color: rgba(0, 0, 0, 0.85); -} - -#header .details br { - display: none; -} - -#header .details br + span:before { - content: "\00a0\2013\00a0"; -} - -#header .details br + span.author:before { - content: "\00a0\22c5\00a0"; - color: rgba(0, 0, 0, 0.85); -} - -#header .details br + span#revremark:before { - content: "\00a0|\00a0"; -} - -#header #revnumber { - text-transform: capitalize; -} - -#header #revnumber:after { - content: "\00a0"; -} - -#content > h1:first-child:not([class]) { - color: rgba(0, 0, 0, 0.85); - border-bottom: 1px solid #ddddd8; - padding-bottom: 8px; - margin-top: 0; - padding-top: 1rem; - margin-bottom: 1.25rem; -} - -#toc { - border-bottom: 1px solid #efefed; - padding-bottom: 0.5em; -} - -#toc > ul { - margin-left: 0.125em; -} - -#toc ul.sectlevel0 > li > a { - font-style: italic; -} - -#toc ul.sectlevel0 ul.sectlevel1 { - margin: 0.5em 0; -} - -#toc ul { - font-family: "Open Sans", "DejaVu Sans", sans-serif; - list-style-type: none; -} - -#toc a { - text-decoration: none; -} - -#toc a:active { - text-decoration: underline; -} - -#toctitle { - color: #7a2518; - font-size: 1.2em; -} - -@media only screen and (min-width: 768px) { - #toctitle { - font-size: 1.375em; - } - - body.toc2 { - padding-left: 15em; - padding-right: 0; - } - - #toc.toc2 { - margin-top: 0 !important; - background-color: #f8f8f7; - position: fixed; - width: 15em; - left: 0; - top: 0; - border-right: 1px solid #efefed; - border-top-width: 0 !important; - border-bottom-width: 0 !important; - z-index: 1000; - padding: 1.25em 1em; - height: 100%; - overflow: auto; - } - - #toc.toc2 #toctitle { - margin-top: 0; - font-size: 1.2em; - } - - #toc.toc2 > ul { - font-size: 0.9em; - margin-bottom: 0; - } - - #toc.toc2 ul ul { - margin-left: 0; - padding-left: 1em; - } - - #toc.toc2 ul.sectlevel0 ul.sectlevel1 { - padding-left: 0; - margin-top: 0.5em; - margin-bottom: 0.5em; - } - - body.toc2.toc-right { - padding-left: 0; - padding-right: 15em; - } - - body.toc2.toc-right #toc.toc2 { - border-right-width: 0; - border-left: 1px solid #efefed; - left: auto; - right: 0; - } -} - -@media only screen and (min-width: 1280px) { - body.toc2 { - padding-left: 20em; - padding-right: 0; - } - - #toc.toc2 { - width: 20em; - } - - #toc.toc2 #toctitle { - font-size: 1.375em; - } - - #toc.toc2 > ul { - font-size: 0.95em; - } - - #toc.toc2 ul ul { - padding-left: 1.25em; - } - - body.toc2.toc-right { - padding-left: 0; - padding-right: 20em; - } -} - -#content #toc { - border-style: solid; - border-width: 1px; - border-color: #e0e0dc; - margin-bottom: 1.25em; - padding: 1.25em; - background: #f8f8f7; - -webkit-border-radius: 4px; - border-radius: 4px; -} - -#content #toc > :first-child { - margin-top: 0; -} - -#content #toc > :last-child { - margin-bottom: 0; -} - -#footer { - max-width: 100%; - background-color: rgba(0, 0, 0, 0.8); - padding: 1.25em; -} - -#footer-text { - color: rgba(255, 255, 255, 0.8); - line-height: 1.44; -} - -.sect1 { - padding-bottom: 0.625em; -} - -@media only screen and (min-width: 768px) { - .sect1 { - padding-bottom: 1.25em; - } -} - -.sect1 + .sect1 { - border-top: 1px solid #efefed; -} - -#content h1 > a.anchor, h2 > a.anchor, h3 > a.anchor, #toctitle > a.anchor, .sidebarblock > .content > .title > a.anchor, h4 > a.anchor, h5 > a.anchor, h6 > a.anchor { - position: absolute; - z-index: 1001; - width: 1.5ex; - margin-left: -1.5ex; - display: block; - text-decoration: none !important; - visibility: hidden; - text-align: center; - font-weight: normal; -} - -#content h1 > a.anchor:before, h2 > a.anchor:before, h3 > a.anchor:before, #toctitle > a.anchor:before, .sidebarblock > .content > .title > a.anchor:before, h4 > a.anchor:before, h5 > a.anchor:before, h6 > a.anchor:before { - content: "\00A7"; - font-size: 0.85em; - display: block; - padding-top: 0.1em; -} - -#content h1:hover > a.anchor, #content h1 > a.anchor:hover, h2:hover > a.anchor, h2 > a.anchor:hover, h3:hover > a.anchor, #toctitle:hover > a.anchor, .sidebarblock > .content > .title:hover > a.anchor, h3 > a.anchor:hover, #toctitle > a.anchor:hover, .sidebarblock > .content > .title > a.anchor:hover, h4:hover > a.anchor, h4 > a.anchor:hover, h5:hover > a.anchor, h5 > a.anchor:hover, h6:hover > a.anchor, h6 > a.anchor:hover { - visibility: visible; -} - -#content h1 > a.link, h2 > a.link, h3 > a.link, #toctitle > a.link, .sidebarblock > .content > .title > a.link, h4 > a.link, h5 > a.link, h6 > a.link { - color: #ba3925; - text-decoration: none; -} - -#content h1 > a.link:hover, h2 > a.link:hover, h3 > a.link:hover, #toctitle > a.link:hover, .sidebarblock > .content > .title > a.link:hover, h4 > a.link:hover, h5 > a.link:hover, h6 > a.link:hover { - color: #a53221; -} - -.audioblock, .imageblock, .literalblock, .listingblock, .stemblock, .videoblock { - margin-bottom: 1.25em; -} - -.admonitionblock td.content > .title, .audioblock > .title, .exampleblock > .title, .imageblock > .title, .listingblock > .title, .literalblock > .title, .stemblock > .title, .openblock > .title, .paragraph > .title, .quoteblock > .title, table.tableblock > .title, .verseblock > .title, .videoblock > .title, .dlist > .title, .olist > .title, .ulist > .title, .qlist > .title, .hdlist > .title { - text-rendering: optimizeLegibility; - text-align: left; - font-family: "Noto Serif", "DejaVu Serif", serif; - font-size: 1rem; - font-style: italic; -} - -table.tableblock > caption.title { - white-space: nowrap; - overflow: visible; - max-width: 0; -} - -.paragraph.lead > p, #preamble > .sectionbody > .paragraph:first-of-type p { - color: rgba(0, 0, 0, 0.85); -} - -table.tableblock #preamble > .sectionbody > .paragraph:first-of-type p { - font-size: inherit; -} - -.admonitionblock > table { - border-collapse: separate; - border: 0; - background: none; - width: 100%; -} - -.admonitionblock > table td.icon { - text-align: center; - width: 80px; -} - -.admonitionblock > table td.icon img { - max-width: none; -} - -.admonitionblock > table td.icon .title { - font-weight: bold; - font-family: "Open Sans", "DejaVu Sans", sans-serif; - text-transform: uppercase; -} - -.admonitionblock > table td.content { - padding-left: 1.125em; - padding-right: 1.25em; - border-left: 1px solid #ddddd8; - color: rgba(0, 0, 0, 0.6); -} - -.admonitionblock > table td.content > :last-child > :last-child { - margin-bottom: 0; -} - -.exampleblock > .content { - border-style: solid; - border-width: 1px; - border-color: #e6e6e6; - margin-bottom: 1.25em; - padding: 1.25em; - background: white; - -webkit-border-radius: 4px; - border-radius: 4px; -} - -.exampleblock > .content > :first-child { - margin-top: 0; -} - -.exampleblock > .content > :last-child { - margin-bottom: 0; -} - -.sidebarblock { - border-style: solid; - border-width: 1px; - border-color: #e0e0dc; - margin-bottom: 1.25em; - padding: 1.25em; - background: #f8f8f7; - -webkit-border-radius: 4px; - border-radius: 4px; -} - -.sidebarblock > :first-child { - margin-top: 0; -} - -.sidebarblock > :last-child { - margin-bottom: 0; -} - -.sidebarblock > .content > .title { - color: #7a2518; - margin-top: 0; - text-align: center; -} - -.exampleblock > .content > :last-child > :last-child, .exampleblock > .content .olist > ol > li:last-child > :last-child, .exampleblock > .content .ulist > ul > li:last-child > :last-child, .exampleblock > .content .qlist > ol > li:last-child > :last-child, .sidebarblock > .content > :last-child > :last-child, .sidebarblock > .content .olist > ol > li:last-child > :last-child, .sidebarblock > .content .ulist > ul > li:last-child > :last-child, .sidebarblock > .content .qlist > ol > li:last-child > :last-child { - margin-bottom: 0; -} - -.literalblock pre, .listingblock pre:not(.highlight), .listingblock pre[class="highlight"], .listingblock pre[class^="highlight "], .listingblock pre.CodeRay, .listingblock pre.prettyprint { - background: #f7f7f8; -} - -.sidebarblock .literalblock pre, .sidebarblock .listingblock pre:not(.highlight), .sidebarblock .listingblock pre[class="highlight"], .sidebarblock .listingblock pre[class^="highlight "], .sidebarblock .listingblock pre.CodeRay, .sidebarblock .listingblock pre.prettyprint { - background: #f2f1f1; -} - -.literalblock pre, .literalblock pre[class], .listingblock pre, .listingblock pre[class] { - -webkit-border-radius: 4px; - border-radius: 4px; - word-wrap: break-word; - padding: 1em; - font-size: 0.8125em; -} - -.literalblock pre.nowrap, .literalblock pre[class].nowrap, .listingblock pre.nowrap, .listingblock pre[class].nowrap { - overflow-x: auto; - white-space: pre; - word-wrap: normal; -} - -@media only screen and (min-width: 768px) { - .literalblock pre, .literalblock pre[class], .listingblock pre, .listingblock pre[class] { - font-size: 0.90625em; - } -} - -@media only screen and (min-width: 1280px) { - .literalblock pre, .literalblock pre[class], .listingblock pre, .listingblock pre[class] { - font-size: 1em; - } -} - -.literalblock.output pre { - color: #f7f7f8; - background-color: rgba(0, 0, 0, 0.9); -} - -.listingblock pre.highlightjs { - padding: 0; -} - -.listingblock pre.highlightjs > code { - padding: 1em; - -webkit-border-radius: 4px; - border-radius: 4px; -} - -.listingblock pre.prettyprint { - border-width: 0; -} - -.listingblock > .content { - position: relative; -} - -.listingblock code[data-lang]:before { - display: none; - content: attr(data-lang); - position: absolute; - font-size: 0.75em; - top: 0.425rem; - right: 0.5rem; - line-height: 1; - text-transform: uppercase; - color: #999; -} - -.listingblock:hover code[data-lang]:before { - display: block; -} - -.listingblock.terminal pre .command:before { - content: attr(data-prompt); - padding-right: 0.5em; - color: #999; -} - -.listingblock.terminal pre .command:not([data-prompt]):before { - content: "$"; -} - -table.pyhltable { - border-collapse: separate; - border: 0; - margin-bottom: 0; - background: none; -} - -table.pyhltable td { - vertical-align: top; - padding-top: 0; - padding-bottom: 0; -} - -table.pyhltable td.code { - padding-left: .75em; - padding-right: 0; -} - -pre.pygments .lineno, table.pyhltable td:not(.code) { - color: #999; - padding-left: 0; - padding-right: .5em; - border-right: 1px solid #ddddd8; -} - -pre.pygments .lineno { - display: inline-block; - margin-right: .25em; -} - -table.pyhltable .linenodiv { - background: none !important; - padding-right: 0 !important; -} - -.quoteblock { - margin: 0 1em 1.25em 1.5em; - display: table; -} - -.quoteblock > .title { - margin-left: -1.5em; - margin-bottom: 0.75em; -} - -.quoteblock blockquote, .quoteblock blockquote p { - color: rgba(0, 0, 0, 0.85); - font-size: 1.15rem; - line-height: 1.75; - word-spacing: 0.1em; - letter-spacing: 0; - font-style: italic; - text-align: justify; -} - -.quoteblock blockquote { - margin: 0; - padding: 0; - border: 0; -} - -.quoteblock blockquote:before { - content: "\201c"; - float: left; - font-size: 2.75em; - font-weight: bold; - line-height: 0.6em; - margin-left: -0.6em; - color: #7a2518; - text-shadow: 0 1px 2px rgba(0, 0, 0, 0.1); -} - -.quoteblock blockquote > .paragraph:last-child p { - margin-bottom: 0; -} - -.quoteblock .attribution { - margin-top: 0.5em; - margin-right: 0.5ex; - text-align: right; -} - -.quoteblock .quoteblock { - margin-left: 0; - margin-right: 0; - padding: 0.5em 0; - border-left: 3px solid rgba(0, 0, 0, 0.6); -} - -.quoteblock .quoteblock blockquote { - padding: 0 0 0 0.75em; -} - -.quoteblock .quoteblock blockquote:before { - display: none; -} - -.verseblock { - margin: 0 1em 1.25em 1em; -} - -.verseblock pre { - font-family: "Open Sans", "DejaVu Sans", sans; - font-size: 1.15rem; - color: rgba(0, 0, 0, 0.85); - font-weight: 300; - text-rendering: optimizeLegibility; -} - -.verseblock pre strong { - font-weight: 400; -} - -.verseblock .attribution { - margin-top: 1.25rem; - margin-left: 0.5ex; -} - -.quoteblock .attribution, .verseblock .attribution { - font-size: 0.9375em; - line-height: 1.45; - font-style: italic; -} - -.quoteblock .attribution br, .verseblock .attribution br { - display: none; -} - -.quoteblock .attribution cite, .verseblock .attribution cite { - display: block; - letter-spacing: -0.05em; - color: rgba(0, 0, 0, 0.6); -} - -.quoteblock.abstract { - margin: 0 0 1.25em 0; - display: block; -} - -.quoteblock.abstract blockquote, .quoteblock.abstract blockquote p { - text-align: left; - word-spacing: 0; -} - -.quoteblock.abstract blockquote:before, .quoteblock.abstract blockquote p:first-of-type:before { - display: none; -} - -table.tableblock { - max-width: 100%; - border-collapse: separate; -} - -table.tableblock td > .paragraph:last-child p > p:last-child, table.tableblock th > p:last-child, table.tableblock td > p:last-child { - margin-bottom: 0; -} - -table.spread { - width: 100%; -} - -table.tableblock, th.tableblock, td.tableblock { - border: 0 solid #dedede; -} - -table.grid-all th.tableblock, table.grid-all td.tableblock { - border-width: 0 1px 1px 0; -} - -table.grid-all tfoot > tr > th.tableblock, table.grid-all tfoot > tr > td.tableblock { - border-width: 1px 1px 0 0; -} - -table.grid-cols th.tableblock, table.grid-cols td.tableblock { - border-width: 0 1px 0 0; -} - -table.grid-all * > tr > .tableblock:last-child, table.grid-cols * > tr > .tableblock:last-child { - border-right-width: 0; -} - -table.grid-rows th.tableblock, table.grid-rows td.tableblock { - border-width: 0 0 1px 0; -} - -table.grid-all tbody > tr:last-child > th.tableblock, table.grid-all tbody > tr:last-child > td.tableblock, table.grid-all thead:last-child > tr > th.tableblock, table.grid-rows tbody > tr:last-child > th.tableblock, table.grid-rows tbody > tr:last-child > td.tableblock, table.grid-rows thead:last-child > tr > th.tableblock { - border-bottom-width: 0; -} - -table.grid-rows tfoot > tr > th.tableblock, table.grid-rows tfoot > tr > td.tableblock { - border-width: 1px 0 0 0; -} - -table.frame-all { - border-width: 1px; -} - -table.frame-sides { - border-width: 0 1px; -} - -table.frame-topbot { - border-width: 1px 0; -} - -th.halign-left, td.halign-left { - text-align: left; -} - -th.halign-right, td.halign-right { - text-align: right; -} - -th.halign-center, td.halign-center { - text-align: center; -} - -th.valign-top, td.valign-top { - vertical-align: top; -} - -th.valign-bottom, td.valign-bottom { - vertical-align: bottom; -} - -th.valign-middle, td.valign-middle { - vertical-align: middle; -} - -table thead th, table tfoot th { - font-weight: bold; -} - -tbody tr th { - display: table-cell; - line-height: 1.6; - background: #f7f8f7; -} - -tbody tr th, tbody tr th p, tfoot tr th, tfoot tr th p { - color: rgba(0, 0, 0, 0.8); - font-weight: bold; -} - -p.tableblock > code:only-child { - background: none; - padding: 0; -} - -p.tableblock { - font-size: 1em; -} - -td > div.verse { - white-space: pre; -} - -ol { - margin-left: 1.75em; -} - -ul li ol { - margin-left: 1.5em; -} - -dl dd { - margin-left: 1.125em; -} - -dl dd:last-child, dl dd:last-child > :last-child { - margin-bottom: 0; -} - -ol > li p, ul > li p, ul dd, ol dd, .olist .olist, .ulist .ulist, .ulist .olist, .olist .ulist { - margin-bottom: 0.625em; -} - -ul.unstyled, ol.unnumbered, ul.checklist, ul.none { - list-style-type: none; -} - -ul.unstyled, ol.unnumbered, ul.checklist { - margin-left: 0.625em; -} - -ul.checklist li > p:first-child > .fa-check-square-o:first-child, ul.checklist li > p:first-child > input[type="checkbox"]:first-child { - margin-right: 0.25em; -} - -ul.checklist li > p:first-child > input[type="checkbox"]:first-child { - position: relative; - top: 1px; -} - -ul.inline { - margin: 0 auto 0.625em auto; - margin-left: -1.375em; - margin-right: 0; - padding: 0; - list-style: none; - overflow: hidden; -} - -ul.inline > li { - list-style: none; - float: left; - margin-left: 1.375em; - display: block; -} - -ul.inline > li > * { - display: block; -} - -.unstyled dl dt { - font-weight: normal; - font-style: normal; -} - -ol.arabic { - list-style-type: decimal; -} - -ol.decimal { - list-style-type: decimal-leading-zero; -} - -ol.loweralpha { - list-style-type: lower-alpha; -} - -ol.upperalpha { - list-style-type: upper-alpha; -} - -ol.lowerroman { - list-style-type: lower-roman; -} - -ol.upperroman { - list-style-type: upper-roman; -} - -ol.lowergreek { - list-style-type: lower-greek; -} - -.hdlist > table, .colist > table { - border: 0; - background: none; -} - -.hdlist > table > tbody > tr, .colist > table > tbody > tr { - background: none; -} - -td.hdlist1 { - padding-right: .75em; - font-weight: bold; -} - -td.hdlist1, td.hdlist2 { - vertical-align: top; -} - -.literalblock + .colist, .listingblock + .colist { - margin-top: -0.5em; -} - -.colist > table tr > td:first-of-type { - padding: 0 0.75em; - line-height: 1; -} - -.colist > table tr > td:last-of-type { - padding: 0.25em 0; -} - -.thumb, .th { - line-height: 0; - display: inline-block; - border: solid 4px white; - -webkit-box-shadow: 0 0 0 1px #dddddd; - box-shadow: 0 0 0 1px #dddddd; -} - -.imageblock.left, .imageblock[style*="float: left"] { - margin: 0.25em 0.625em 1.25em 0; -} - -.imageblock.right, .imageblock[style*="float: right"] { - margin: 0.25em 0 1.25em 0.625em; -} - -.imageblock > .title { - margin-bottom: 0; -} - -.imageblock.thumb, .imageblock.th { - border-width: 6px; -} - -.imageblock.thumb > .title, .imageblock.th > .title { - padding: 0 0.125em; -} - -.image.left, .image.right { - margin-top: 0.25em; - margin-bottom: 0.25em; - display: inline-block; - line-height: 0; -} - -.image.left { - margin-right: 0.625em; -} - -.image.right { - margin-left: 0.625em; -} - -a.image { - text-decoration: none; -} - -span.footnote, span.footnoteref { - vertical-align: super; - font-size: 0.875em; -} - -span.footnote a, span.footnoteref a { - text-decoration: none; -} - -span.footnote a:active, span.footnoteref a:active { - text-decoration: underline; -} - -#footnotes { - padding-top: 0.75em; - padding-bottom: 0.75em; - margin-bottom: 0.625em; -} - -#footnotes hr { - width: 20%; - min-width: 6.25em; - margin: -.25em 0 .75em 0; - border-width: 1px 0 0 0; -} - -#footnotes .footnote { - padding: 0 0.375em; - line-height: 1.3; - font-size: 0.875em; - margin-left: 1.2em; - text-indent: -1.2em; - margin-bottom: .2em; -} - -#footnotes .footnote a:first-of-type { - font-weight: bold; - text-decoration: none; -} - -#footnotes .footnote:last-of-type { - margin-bottom: 0; -} - -#content #footnotes { - margin-top: -0.625em; - margin-bottom: 0; - padding: 0.75em 0; -} - -.gist .file-data > table { - border: 0; - background: #fff; - width: 100%; - margin-bottom: 0; -} - -.gist .file-data > table td.line-data { - width: 99%; -} - -div.unbreakable { - page-break-inside: avoid; -} - -.big { - font-size: x-large; -} - -.small { - font-size: smaller; -} - -.underline { - text-decoration: underline; -} - -.overline { - text-decoration: overline; -} - -.line-through { - text-decoration: line-through; -} - -.aqua { - color: #00bfbf; -} - -.aqua-background { - background-color: #00fafa; -} - -.black { - color: black; -} - -.black-background { - background-color: black; -} - -.blue { - color: #0000bf; -} - -.blue-background { - background-color: #0000fa; -} - -.fuchsia { - color: #bf00bf; -} - -.fuchsia-background { - background-color: #fa00fa; -} - -.gray { - color: #606060; -} - -.gray-background { - background-color: #7d7d7d; -} - -.green { - color: #006000; -} - -.green-background { - background-color: #007d00; -} - -.lime { - color: #00bf00; -} - -.lime-background { - background-color: #00fa00; -} - -.maroon { - color: #600000; -} - -.maroon-background { - background-color: #7d0000; -} - -.navy { - color: #000060; -} - -.navy-background { - background-color: #00007d; -} - -.olive { - color: #606000; -} - -.olive-background { - background-color: #7d7d00; -} - -.purple { - color: #600060; -} - -.purple-background { - background-color: #7d007d; -} - -.red { - color: #bf0000; -} - -.red-background { - background-color: #fa0000; -} - -.silver { - color: #909090; -} - -.silver-background { - background-color: #bcbcbc; -} - -.teal { - color: #006060; -} - -.teal-background { - background-color: #007d7d; -} - -.white { - color: #bfbfbf; -} - -.white-background { - background-color: #fafafa; -} - -.yellow { - color: #bfbf00; -} - -.yellow-background { - background-color: #fafa00; -} - -span.icon > .fa { - cursor: default; -} - -.admonitionblock td.icon [class^="fa icon-"] { - font-size: 2.5em; - text-shadow: 1px 1px 2px rgba(0, 0, 0, 0.5); - cursor: default; -} - -.admonitionblock td.icon .icon-note:before { - content: "\f05a"; - color: #19407c; -} - -.admonitionblock td.icon .icon-tip:before { - content: "\f0eb"; - text-shadow: 1px 1px 2px rgba(155, 155, 0, 0.8); - color: #111; -} - -.admonitionblock td.icon .icon-warning:before { - content: "\f071"; - color: #bf6900; -} - -.admonitionblock td.icon .icon-caution:before { - content: "\f06d"; - color: #bf3400; -} - -.admonitionblock td.icon .icon-important:before { - content: "\f06a"; - color: #bf0000; -} - -.conum[data-value] { - display: inline-block; - color: #fff !important; - background-color: rgba(0, 0, 0, 0.8); - -webkit-border-radius: 100px; - border-radius: 100px; - text-align: center; - font-size: 0.75em; - width: 1.67em; - height: 1.67em; - line-height: 1.67em; - font-family: "Open Sans", "DejaVu Sans", sans-serif; - font-style: normal; - font-weight: bold; -} - -.conum[data-value] * { - color: #fff !important; -} - -.conum[data-value] + b { - display: none; -} - -.conum[data-value]:after { - content: attr(data-value); -} - -pre .conum[data-value] { - position: relative; - top: -0.125em; -} - -b.conum * { - color: inherit !important; -} - -.conum:not([data-value]):empty { - display: none; -} - -h1, h2 { - letter-spacing: -0.01em; -} - -dt, th.tableblock, td.content { - text-rendering: optimizeLegibility; -} - -p, td.content { - letter-spacing: -0.01em; -} - -p strong, td.content strong { - letter-spacing: -0.005em; -} - -p, blockquote, dt, td.content { - font-size: 1.0625rem; -} - -p { - margin-bottom: 1.25rem; -} - -.sidebarblock p, .sidebarblock dt, .sidebarblock td.content, p.tableblock { - font-size: 1em; -} - -.exampleblock > .content { - background-color: #fffef7; - border-color: #e0e0dc; - -webkit-box-shadow: 0 1px 4px #e0e0dc; - box-shadow: 0 1px 4px #e0e0dc; -} - -.print-only { - display: none !important; -} - -@media print { - @page { - margin: 1.25cm 0.75cm; - } - - * { - -webkit-box-shadow: none !important; - box-shadow: none !important; - text-shadow: none !important; - } - - a { - color: inherit !important; - text-decoration: underline !important; - } - - a.bare, a[href^="#"], a[href^="mailto:"] { - text-decoration: none !important; - } - - a[href^="http:"]:not(.bare):after, a[href^="https:"]:not(.bare):after, a[href^="mailto:"]:not(.bare):after { - content: "(" attr(href) ")"; - display: inline-block; - font-size: 0.875em; - padding-left: 0.25em; - } - - abbr[title]:after { - content: " (" attr(title) ")"; - } - - pre, blockquote, tr, img { - page-break-inside: avoid; - } - - thead { - display: table-header-group; - } - - img { - max-width: 100% !important; - } - - p, blockquote, dt, td.content { - font-size: 1em; - orphans: 3; - widows: 3; - } - - h2, h3, #toctitle, .sidebarblock > .content > .title, #toctitle, .sidebarblock > .content > .title { - page-break-after: avoid; - } - - #toc, .sidebarblock, .exampleblock > .content { - background: none !important; - } - - #toc { - border-bottom: 1px solid #ddddd8 !important; - padding-bottom: 0 !important; - } - - .sect1 { - padding-bottom: 0 !important; - } - - .sect1 + .sect1 { - border: 0 !important; - } - - #header > h1:first-child { - margin-top: 1.25rem; - } - - body.book #header { - text-align: center; - } - - body.book #header > h1:first-child { - border: 0 !important; - margin: 2.5em 0 1em 0; - } - - body.book #header .details { - border: 0 !important; - display: block; - padding: 0 !important; - } - - body.book #header .details span:first-child { - margin-left: 0 !important; - } - - body.book #header .details br { - display: block; - } - - body.book #header .details br + span:before { - content: none !important; - } - - body.book #toc { - border: 0 !important; - text-align: left !important; - padding: 0 !important; - margin: 0 !important; - } - - body.book #toc, body.book #preamble, body.book h1.sect0, body.book .sect1 > h2 { - page-break-before: always; - } - - .listingblock code[data-lang]:before { - display: block; - } - - #footer { - background: none !important; - padding: 0 0.9375em; - } - - #footer-text { - color: rgba(0, 0, 0, 0.6) !important; - font-size: 0.9em; - } - - .hide-on-print { - display: none !important; - } - - .print-only { - display: block !important; - } - - .hide-for-print { - display: none !important; - } - - .show-for-print { - display: inherit !important; - } -} diff --git a/api_modules/template/xml/core.xsd b/api_modules/template/xml/core.xsd deleted file mode 100644 index 493db82..0000000 --- a/api_modules/template/xml/core.xsd +++ /dev/null @@ -1,326 +0,0 @@ - - - - This XML Schema Document includes and imports, - directly or indirectly, all the XML Schemas defined by the - OGC API - Features - Part 1: Core. - - Copyright (c) 2019 Open Geospatial Consortium. - To obtain additional rights of use, visit - http://www.opengeospatial.org/legal/ . - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If this attribute is not specified then the language used for the string can be determined using the usual HTTP language negotiation mechanisms. - - - - - - diff --git a/api_modules/template/xml/wsdl/README.md b/api_modules/template/xml/wsdl/README.md deleted file mode 100644 index d91a096..0000000 --- a/api_modules/template/xml/wsdl/README.md +++ /dev/null @@ -1,4 +0,0 @@ -# Standard template - -This folder is a placeholder for a WSDL 2.0 description that can be an -XML-encoded alternative for an OpenAPI 3.0 document. diff --git a/api_modules/crs/.gitignore b/bblocks/crs/.gitignore similarity index 100% rename from api_modules/crs/.gitignore rename to bblocks/crs/.gitignore diff --git a/api_modules/crs/README.md b/bblocks/crs/README.md similarity index 100% rename from api_modules/crs/README.md rename to bblocks/crs/README.md diff --git a/api_modules/crs/examples/json/README.md b/bblocks/crs/examples/json/README.md similarity index 100% rename from api_modules/crs/examples/json/README.md rename to bblocks/crs/examples/json/README.md diff --git a/api_modules/crs/examples/xml/README.md b/bblocks/crs/examples/xml/README.md similarity index 100% rename from api_modules/crs/examples/xml/README.md rename to bblocks/crs/examples/xml/README.md diff --git a/api_modules/crs/openapi/examples/README.md b/bblocks/crs/openapi/examples/README.md similarity index 100% rename from api_modules/crs/openapi/examples/README.md rename to bblocks/crs/openapi/examples/README.md diff --git a/api_modules/crs/openapi/parameters/README.md b/bblocks/crs/openapi/parameters/README.md similarity index 100% rename from api_modules/crs/openapi/parameters/README.md rename to bblocks/crs/openapi/parameters/README.md diff --git a/api_modules/crs/openapi/responses/README.md b/bblocks/crs/openapi/responses/README.md similarity index 100% rename from api_modules/crs/openapi/responses/README.md rename to bblocks/crs/openapi/responses/README.md diff --git a/api_modules/crs/openapi/schemas/README.md b/bblocks/crs/openapi/schemas/README.md similarity index 100% rename from api_modules/crs/openapi/schemas/README.md rename to bblocks/crs/openapi/schemas/README.md diff --git a/api_modules/crs/standard/18-058.adoc b/bblocks/crs/standard/18-058.adoc similarity index 100% rename from api_modules/crs/standard/18-058.adoc rename to bblocks/crs/standard/18-058.adoc diff --git a/api_modules/crs/standard/HTML_Gen.bat b/bblocks/crs/standard/HTML_Gen.bat similarity index 100% rename from api_modules/crs/standard/HTML_Gen.bat rename to bblocks/crs/standard/HTML_Gen.bat diff --git a/api_modules/crs/standard/PDF_Gen.bat b/bblocks/crs/standard/PDF_Gen.bat similarity index 100% rename from api_modules/crs/standard/PDF_Gen.bat rename to bblocks/crs/standard/PDF_Gen.bat diff --git a/api_modules/crs/standard/README.md b/bblocks/crs/standard/README.md similarity index 100% rename from api_modules/crs/standard/README.md rename to bblocks/crs/standard/README.md diff --git a/api_modules/crs/standard/SRSNAME.txt b/bblocks/crs/standard/SRSNAME.txt similarity index 100% rename from api_modules/crs/standard/SRSNAME.txt rename to bblocks/crs/standard/SRSNAME.txt diff --git a/api_modules/crs/standard/abstract_tests/README.md b/bblocks/crs/standard/abstract_tests/README.md similarity index 100% rename from api_modules/crs/standard/abstract_tests/README.md rename to bblocks/crs/standard/abstract_tests/README.md diff --git a/api_modules/crs/standard/abstract_tests/cc/TEST001.adoc b/bblocks/crs/standard/abstract_tests/cc/TEST001.adoc similarity index 100% rename from api_modules/crs/standard/abstract_tests/cc/TEST001.adoc rename to bblocks/crs/standard/abstract_tests/cc/TEST001.adoc diff --git a/api_modules/crs/standard/annex_ats.adoc b/bblocks/crs/standard/annex_ats.adoc similarity index 100% rename from api_modules/crs/standard/annex_ats.adoc rename to bblocks/crs/standard/annex_ats.adoc diff --git a/api_modules/crs/standard/annex_bibliography.adoc b/bblocks/crs/standard/annex_bibliography.adoc similarity index 100% rename from api_modules/crs/standard/annex_bibliography.adoc rename to bblocks/crs/standard/annex_bibliography.adoc diff --git a/api_modules/crs/standard/annex_history.adoc b/bblocks/crs/standard/annex_history.adoc similarity index 100% rename from api_modules/crs/standard/annex_history.adoc rename to bblocks/crs/standard/annex_history.adoc diff --git a/api_modules/crs/standard/annex_n.adoc b/bblocks/crs/standard/annex_n.adoc similarity index 100% rename from api_modules/crs/standard/annex_n.adoc rename to bblocks/crs/standard/annex_n.adoc diff --git a/api_modules/crs/standard/clause_0_front_material.adoc b/bblocks/crs/standard/clause_0_front_material.adoc similarity index 100% rename from api_modules/crs/standard/clause_0_front_material.adoc rename to bblocks/crs/standard/clause_0_front_material.adoc diff --git a/api_modules/crs/standard/clause_1_scope.adoc b/bblocks/crs/standard/clause_1_scope.adoc similarity index 100% rename from api_modules/crs/standard/clause_1_scope.adoc rename to bblocks/crs/standard/clause_1_scope.adoc diff --git a/api_modules/crs/standard/clause_2_conformance.adoc b/bblocks/crs/standard/clause_2_conformance.adoc similarity index 100% rename from api_modules/crs/standard/clause_2_conformance.adoc rename to bblocks/crs/standard/clause_2_conformance.adoc diff --git a/api_modules/crs/standard/clause_3_references.adoc b/bblocks/crs/standard/clause_3_references.adoc similarity index 100% rename from api_modules/crs/standard/clause_3_references.adoc rename to bblocks/crs/standard/clause_3_references.adoc diff --git a/api_modules/crs/standard/clause_4_terms_and_definitions.adoc b/bblocks/crs/standard/clause_4_terms_and_definitions.adoc similarity index 100% rename from api_modules/crs/standard/clause_4_terms_and_definitions.adoc rename to bblocks/crs/standard/clause_4_terms_and_definitions.adoc diff --git a/api_modules/crs/standard/clause_5_conventions.adoc b/bblocks/crs/standard/clause_5_conventions.adoc similarity index 100% rename from api_modules/crs/standard/clause_5_conventions.adoc rename to bblocks/crs/standard/clause_5_conventions.adoc diff --git a/api_modules/crs/standard/clause_6_crs.adoc b/bblocks/crs/standard/clause_6_crs.adoc similarity index 100% rename from api_modules/crs/standard/clause_6_crs.adoc rename to bblocks/crs/standard/clause_6_crs.adoc diff --git a/api_modules/crs/standard/figures/README.md b/bblocks/crs/standard/figures/README.md similarity index 100% rename from api_modules/crs/standard/figures/README.md rename to bblocks/crs/standard/figures/README.md diff --git a/api_modules/crs/standard/images/README.md b/bblocks/crs/standard/images/README.md similarity index 100% rename from api_modules/crs/standard/images/README.md rename to bblocks/crs/standard/images/README.md diff --git a/api_modules/crs/standard/recommendations/cc/PER_per.adoc b/bblocks/crs/standard/recommendations/cc/PER_per.adoc similarity index 100% rename from api_modules/crs/standard/recommendations/cc/PER_per.adoc rename to bblocks/crs/standard/recommendations/cc/PER_per.adoc diff --git a/api_modules/crs/standard/recommendations/cc/REC_rec.adoc b/bblocks/crs/standard/recommendations/cc/REC_rec.adoc similarity index 100% rename from api_modules/crs/standard/recommendations/cc/REC_rec.adoc rename to bblocks/crs/standard/recommendations/cc/REC_rec.adoc diff --git a/api_modules/crs/standard/requirements/README.md b/bblocks/crs/standard/requirements/README.md similarity index 100% rename from api_modules/crs/standard/requirements/README.md rename to bblocks/crs/standard/requirements/README.md diff --git a/api_modules/crs/standard/requirements/REQ_bbox-crs-exception.adoc b/bblocks/crs/standard/requirements/REQ_bbox-crs-exception.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_bbox-crs-exception.adoc rename to bblocks/crs/standard/requirements/REQ_bbox-crs-exception.adoc diff --git a/api_modules/crs/standard/requirements/REQ_crs-exception.adoc b/bblocks/crs/standard/requirements/REQ_crs-exception.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_crs-exception.adoc rename to bblocks/crs/standard/requirements/REQ_crs-exception.adoc diff --git a/api_modules/crs/standard/requirements/REQ_crs-format-model.adoc b/bblocks/crs/standard/requirements/REQ_crs-format-model.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_crs-format-model.adoc rename to bblocks/crs/standard/requirements/REQ_crs-format-model.adoc diff --git a/api_modules/crs/standard/requirements/REQ_fc-bbox-crs-action.adoc b/bblocks/crs/standard/requirements/REQ_fc-bbox-crs-action.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_fc-bbox-crs-action.adoc rename to bblocks/crs/standard/requirements/REQ_fc-bbox-crs-action.adoc diff --git a/api_modules/crs/standard/requirements/REQ_fc-bbox-crs-default-value.adoc b/bblocks/crs/standard/requirements/REQ_fc-bbox-crs-default-value.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_fc-bbox-crs-default-value.adoc rename to bblocks/crs/standard/requirements/REQ_fc-bbox-crs-default-value.adoc diff --git a/api_modules/crs/standard/requirements/REQ_fc-bbox-crs-definition.adoc b/bblocks/crs/standard/requirements/REQ_fc-bbox-crs-definition.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_fc-bbox-crs-definition.adoc rename to bblocks/crs/standard/requirements/REQ_fc-bbox-crs-definition.adoc diff --git a/api_modules/crs/standard/requirements/REQ_fc-bbox-crs-valid-values.adoc b/bblocks/crs/standard/requirements/REQ_fc-bbox-crs-valid-values.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_fc-bbox-crs-valid-values.adoc rename to bblocks/crs/standard/requirements/REQ_fc-bbox-crs-valid-values.adoc diff --git a/api_modules/crs/standard/requirements/REQ_fc-crs-action-exception.adoc b/bblocks/crs/standard/requirements/REQ_fc-crs-action-exception.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_fc-crs-action-exception.adoc rename to bblocks/crs/standard/requirements/REQ_fc-crs-action-exception.adoc diff --git a/api_modules/crs/standard/requirements/REQ_fc-crs-action.adoc b/bblocks/crs/standard/requirements/REQ_fc-crs-action.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_fc-crs-action.adoc rename to bblocks/crs/standard/requirements/REQ_fc-crs-action.adoc diff --git a/api_modules/crs/standard/requirements/REQ_fc-crs-default-value.adoc b/bblocks/crs/standard/requirements/REQ_fc-crs-default-value.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_fc-crs-default-value.adoc rename to bblocks/crs/standard/requirements/REQ_fc-crs-default-value.adoc diff --git a/api_modules/crs/standard/requirements/REQ_fc-crs-definition.adoc b/bblocks/crs/standard/requirements/REQ_fc-crs-definition.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_fc-crs-definition.adoc rename to bblocks/crs/standard/requirements/REQ_fc-crs-definition.adoc diff --git a/api_modules/crs/standard/requirements/REQ_fc-crs-valid-value.adoc b/bblocks/crs/standard/requirements/REQ_fc-crs-valid-value.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_fc-crs-valid-value.adoc rename to bblocks/crs/standard/requirements/REQ_fc-crs-valid-value.adoc diff --git a/api_modules/crs/standard/requirements/REQ_fc-md-crs-list-defaultCrs.adoc b/bblocks/crs/standard/requirements/REQ_fc-md-crs-list-defaultCrs.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_fc-md-crs-list-defaultCrs.adoc rename to bblocks/crs/standard/requirements/REQ_fc-md-crs-list-defaultCrs.adoc diff --git a/api_modules/crs/standard/requirements/REQ_fc-md-crs-list-global-default.adoc b/bblocks/crs/standard/requirements/REQ_fc-md-crs-list-global-default.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_fc-md-crs-list-global-default.adoc rename to bblocks/crs/standard/requirements/REQ_fc-md-crs-list-global-default.adoc diff --git a/api_modules/crs/standard/requirements/REQ_fc-md-crs-list-global.adoc b/bblocks/crs/standard/requirements/REQ_fc-md-crs-list-global.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_fc-md-crs-list-global.adoc rename to bblocks/crs/standard/requirements/REQ_fc-md-crs-list-global.adoc diff --git a/api_modules/crs/standard/requirements/REQ_fc-md-crs-list-storageCrs.adoc b/bblocks/crs/standard/requirements/REQ_fc-md-crs-list-storageCrs.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_fc-md-crs-list-storageCrs.adoc rename to bblocks/crs/standard/requirements/REQ_fc-md-crs-list-storageCrs.adoc diff --git a/api_modules/crs/standard/requirements/REQ_fc-md-crs-list.adoc b/bblocks/crs/standard/requirements/REQ_fc-md-crs-list.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_fc-md-crs-list.adoc rename to bblocks/crs/standard/requirements/REQ_fc-md-crs-list.adoc diff --git a/api_modules/crs/standard/requirements/REQ_geojson.adoc b/bblocks/crs/standard/requirements/REQ_geojson.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_geojson.adoc rename to bblocks/crs/standard/requirements/REQ_geojson.adoc diff --git a/api_modules/crs/standard/requirements/REQ_ogc-crs-header-axis-names.adoc b/bblocks/crs/standard/requirements/REQ_ogc-crs-header-axis-names.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_ogc-crs-header-axis-names.adoc rename to bblocks/crs/standard/requirements/REQ_ogc-crs-header-axis-names.adoc diff --git a/api_modules/crs/standard/requirements/REQ_ogc-crs-header-axis-order-action.adoc b/bblocks/crs/standard/requirements/REQ_ogc-crs-header-axis-order-action.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_ogc-crs-header-axis-order-action.adoc rename to bblocks/crs/standard/requirements/REQ_ogc-crs-header-axis-order-action.adoc diff --git a/api_modules/crs/standard/requirements/REQ_ogc-crs-header-axis-order-value.adoc b/bblocks/crs/standard/requirements/REQ_ogc-crs-header-axis-order-value.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_ogc-crs-header-axis-order-value.adoc rename to bblocks/crs/standard/requirements/REQ_ogc-crs-header-axis-order-value.adoc diff --git a/api_modules/crs/standard/requirements/REQ_ogc-crs-header-value-action.adoc b/bblocks/crs/standard/requirements/REQ_ogc-crs-header-value-action.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_ogc-crs-header-value-action.adoc rename to bblocks/crs/standard/requirements/REQ_ogc-crs-header-value-action.adoc diff --git a/api_modules/crs/standard/requirements/REQ_ogc-crs-header-value.adoc b/bblocks/crs/standard/requirements/REQ_ogc-crs-header-value.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_ogc-crs-header-value.adoc rename to bblocks/crs/standard/requirements/REQ_ogc-crs-header-value.adoc diff --git a/api_modules/crs/standard/requirements/REQ_ogc-crs-header.adoc b/bblocks/crs/standard/requirements/REQ_ogc-crs-header.adoc similarity index 100% rename from api_modules/crs/standard/requirements/REQ_ogc-crs-header.adoc rename to bblocks/crs/standard/requirements/REQ_ogc-crs-header.adoc diff --git a/api_modules/crs/standard/requirements/cc/REQ_req.adoc b/bblocks/crs/standard/requirements/cc/REQ_req.adoc similarity index 100% rename from api_modules/crs/standard/requirements/cc/REQ_req.adoc rename to bblocks/crs/standard/requirements/cc/REQ_req.adoc diff --git a/api_modules/crs/standard/requirements/requirements_class_cc.adoc b/bblocks/crs/standard/requirements/requirements_class_cc.adoc similarity index 100% rename from api_modules/crs/standard/requirements/requirements_class_cc.adoc rename to bblocks/crs/standard/requirements/requirements_class_cc.adoc diff --git a/api_modules/crs/standard/standard.css b/bblocks/crs/standard/standard.css similarity index 100% rename from api_modules/crs/standard/standard.css rename to bblocks/crs/standard/standard.css diff --git a/api_modules/crs/xml/core.xsd b/bblocks/crs/xml/core.xsd similarity index 100% rename from api_modules/crs/xml/core.xsd rename to bblocks/crs/xml/core.xsd diff --git a/api_modules/crs/xml/wsdl/README.md b/bblocks/crs/xml/wsdl/README.md similarity index 100% rename from api_modules/crs/xml/wsdl/README.md rename to bblocks/crs/xml/wsdl/README.md diff --git a/collections/clause_9_subset.adoc b/bblocks/subset/clause_9_subset.adoc similarity index 85% rename from collections/clause_9_subset.adoc rename to bblocks/subset/clause_9_subset.adoc index 6db20e7..a9cfc06 100644 --- a/collections/clause_9_subset.adoc +++ b/bblocks/subset/clause_9_subset.adoc @@ -2,7 +2,7 @@ == Subset Requirements Class :sectnums: -include::../api_modules/subset/requirements/requirements_class_subset.adoc[] +include::requirements/requirements_class_subset.adoc[] NOTE: This Requirements Class under construction @@ -13,9 +13,9 @@ This Requirements Class describes query parameters that can be used to discover Query parameters are used in URIs to limit the resources which are returned on a GET request. The <> Requirements Class defines two parameters for selecting resources based on simple geospatial and temporal geometries. However, not all spatial-temporal resources are so well behaved. The Subset Requirements Class enables selection of resources based on a domain-specific n-dimensional geometry. -include::../api_modules/subset/requirements/REQ_subset-definition.adoc[] +include::requirements/REQ_subset-definition.adoc[] -include::../api_modules/subset/requirements/REQ_subset-success.adoc[] +include::requirements/REQ_subset-success.adoc[] [[subset-target-resource]] === Target Resource @@ -26,5 +26,5 @@ The `collections` property of the Collections response provides a description of The requirements governing the processing of the `subset` parameter are: -include::requirements/subset/REQ_rc-subset-collection-response.adoc[] +include::requirements/REQ_rc-subset-collection-response.adoc[] diff --git a/api_modules/subset/examples/JSON/collection_example.json b/bblocks/subset/examples/JSON/collection_example.json similarity index 100% rename from api_modules/subset/examples/JSON/collection_example.json rename to bblocks/subset/examples/JSON/collection_example.json diff --git a/api_modules/subset/examples/JSON/collection_info_example.json b/bblocks/subset/examples/JSON/collection_info_example.json similarity index 100% rename from api_modules/subset/examples/JSON/collection_info_example.json rename to bblocks/subset/examples/JSON/collection_info_example.json diff --git a/api_modules/subset/examples/JSON/collections_example.json b/bblocks/subset/examples/JSON/collections_example.json similarity index 100% rename from api_modules/subset/examples/JSON/collections_example.json rename to bblocks/subset/examples/JSON/collections_example.json diff --git a/api_modules/subset/examples/JSON/conformance_example.json b/bblocks/subset/examples/JSON/conformance_example.json similarity index 100% rename from api_modules/subset/examples/JSON/conformance_example.json rename to bblocks/subset/examples/JSON/conformance_example.json diff --git a/api_modules/subset/examples/JSON/coverage_domainset_example.json b/bblocks/subset/examples/JSON/coverage_domainset_example.json similarity index 100% rename from api_modules/subset/examples/JSON/coverage_domainset_example.json rename to bblocks/subset/examples/JSON/coverage_domainset_example.json diff --git a/api_modules/subset/examples/JSON/coverage_example.json b/bblocks/subset/examples/JSON/coverage_example.json similarity index 100% rename from api_modules/subset/examples/JSON/coverage_example.json rename to bblocks/subset/examples/JSON/coverage_example.json diff --git a/api_modules/subset/examples/JSON/coverage_metadata_example.json b/bblocks/subset/examples/JSON/coverage_metadata_example.json similarity index 100% rename from api_modules/subset/examples/JSON/coverage_metadata_example.json rename to bblocks/subset/examples/JSON/coverage_metadata_example.json diff --git a/api_modules/subset/examples/JSON/coverage_rangeset_example.json b/bblocks/subset/examples/JSON/coverage_rangeset_example.json similarity index 100% rename from api_modules/subset/examples/JSON/coverage_rangeset_example.json rename to bblocks/subset/examples/JSON/coverage_rangeset_example.json diff --git a/api_modules/subset/examples/JSON/coverage_rangetype_example.json b/bblocks/subset/examples/JSON/coverage_rangetype_example.json similarity index 100% rename from api_modules/subset/examples/JSON/coverage_rangetype_example.json rename to bblocks/subset/examples/JSON/coverage_rangetype_example.json diff --git a/api_modules/subset/examples/JSON/examples_CIS_JSON.adoc b/bblocks/subset/examples/JSON/examples_CIS_JSON.adoc similarity index 100% rename from api_modules/subset/examples/JSON/examples_CIS_JSON.adoc rename to bblocks/subset/examples/JSON/examples_CIS_JSON.adoc diff --git a/api_modules/subset/examples/JSON/landingPage_example.json b/bblocks/subset/examples/JSON/landingPage_example.json similarity index 100% rename from api_modules/subset/examples/JSON/landingPage_example.json rename to bblocks/subset/examples/JSON/landingPage_example.json diff --git a/api_modules/subset/examples/examples.adoc b/bblocks/subset/examples/examples.adoc similarity index 100% rename from api_modules/subset/examples/examples.adoc rename to bblocks/subset/examples/examples.adoc diff --git a/api_modules/subset/examples/examples_subsetting.adoc b/bblocks/subset/examples/examples_subsetting.adoc similarity index 100% rename from api_modules/subset/examples/examples_subsetting.adoc rename to bblocks/subset/examples/examples_subsetting.adoc diff --git a/api_modules/subset/recommendations/PER_subset-slice-sparse-dimensions.adoc b/bblocks/subset/recommendations/PER_subset-slice-sparse-dimensions.adoc similarity index 100% rename from api_modules/subset/recommendations/PER_subset-slice-sparse-dimensions.adoc rename to bblocks/subset/recommendations/PER_subset-slice-sparse-dimensions.adoc diff --git a/collections/requirements/subset/REQ_rc-subset-collection-response.adoc b/bblocks/subset/requirements/REQ_rc-subset-collection-response.adoc similarity index 100% rename from collections/requirements/subset/REQ_rc-subset-collection-response.adoc rename to bblocks/subset/requirements/REQ_rc-subset-collection-response.adoc diff --git a/api_modules/subset/requirements/REQ_subset-definition.adoc b/bblocks/subset/requirements/REQ_subset-definition.adoc similarity index 100% rename from api_modules/subset/requirements/REQ_subset-definition.adoc rename to bblocks/subset/requirements/REQ_subset-definition.adoc diff --git a/api_modules/subset/requirements/REQ_subset-response.adoc b/bblocks/subset/requirements/REQ_subset-response.adoc similarity index 100% rename from api_modules/subset/requirements/REQ_subset-response.adoc rename to bblocks/subset/requirements/REQ_subset-response.adoc diff --git a/api_modules/subset/requirements/REQ_subset_conformance.adoc b/bblocks/subset/requirements/REQ_subset_conformance.adoc similarity index 100% rename from api_modules/subset/requirements/REQ_subset_conformance.adoc rename to bblocks/subset/requirements/REQ_subset_conformance.adoc diff --git a/api_modules/subset/requirements_module_subset.adoc b/bblocks/subset/subset_query_parameter.adoc similarity index 70% rename from api_modules/subset/requirements_module_subset.adoc rename to bblocks/subset/subset_query_parameter.adoc index fdae5ad..4a74d09 100644 --- a/api_modules/subset/requirements_module_subset.adoc +++ b/bblocks/subset/subset_query_parameter.adoc @@ -1,10 +1,4 @@ -[[rm_subset]] -[cols="1,4",width="90%"] -|=== -2+|*Requirements Module* -2+|http://www.opengis.net/spec/ogcapi-common-2/1.0/rm/subset -|Target type |Web API Query Parameter -|=== +*Web API Query Parameter* The `subset` parameter is used to select a subset of a geospatial resource. @@ -15,4 +9,3 @@ include::requirements/REQ_subset-definition.adoc[] While the processing of the `subset` parameter is specific to the resource and operation for which it is applied, there is a general set of requirements which all implementations must address. include::requirements/REQ_subset-response.adoc[] - diff --git a/collections/20-024.adoc b/collections/20-024.adoc index 0ac2c9b..74f803e 100644 --- a/collections/20-024.adoc +++ b/collections/20-024.adoc @@ -91,6 +91,8 @@ include::clause_7_overview.adoc[] include::clause_8_collections.adoc[] +include::clause_X_umd-collection.adoc[] + include::clause_9_simple_query.adoc[] include::clause_10_encodings.adoc[] diff --git a/collections/20-024.html b/collections/20-024.html deleted file mode 100644 index 75fcf8f..0000000 --- a/collections/20-024.html +++ /dev/null @@ -1,5624 +0,0 @@ - - - - - - - -OGC API - Common - Part 2: Geospatial Data - - - - - -
-
-
-
- --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Open Geospatial Consortium

Submission Date: <yyyy-mm-dd>

Approval Date:   <yyyy-mm-dd>

Publication Date:   2022-06-16

External identifier of this OGC® document: http://www.opengis.net/doc/is/ogcapi-common-2/1.0

Internal reference number of this OGC® document:    20-024

Version: 0.0.9

Category: OGC® Implementation Standard

Editor:   Charles Heazel

- --- - - - - - -

OGC API - Common - Part 2: Geospatial Data

- --- - - - - - - - - - - - -

Copyright notice

Copyright © 2021 Open Geospatial Consortium

To obtain additional rights of use, visit http://www.opengeospatial.org/legal/

- --- - - - - - -

Warning

-
-

This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.

-
-
-

Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

-
- --- - - - - - - - - - - - -

Document type:    OGC® Implementation Standard

Document stage:    Draft

Document language:  English

-
-
-

License Agreement

-
-
-

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

-
-
-

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

-
-
-

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.

-
-
-

THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

-
-
-

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

-
-
-

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

-
-
-
-
Table of Contents
- -
-
-
-
-
-

1. Introduction

-
-
-

i. Abstract

-
-
-

The OGC standards baseline has been extended to include Resource Oriented Architectures and Web APIs. In the course of developing OGC Web API standards, some practices proved to be common across multiple OGC Web API standards. These common practices are documented in the OGC API - Common Multi-Part Standard. OGC API - Common standards serve as reusable building-blocks. Standards developers can use these building-blocks in the construction of OGC Web API Standards. The result is a modular suite of coherent API standards which can be adapted by a system designer for the unique requirements of their system.

-
-
-

Spatial data is rarely considered as a single entity. Feature Collections, Coverages, Data Sets. They are all aggregations of Spatial or Temporal Resources. It stands to reason that an OGC Web API would also expose its' holdings as aggregates of spatial resources.

-
-
-

The purpose of the OGC API - Common - Part 2: Geospatial Data (API-GeoData) Standard is to provide a means of organizing these collections and to define operations for the discovery and selection of individual collections.

-
-
-

OGC API-GeoData does not specify the nature of the geospatial data that make up a collection. Rather, the standard specifies a basic capability which should be applicable to any geospatial resource type. Additional OGC Web API standards extend this foundation to define resource-specific capabilities.

-
-
-

ii. Keywords

-
-
-

The following are keywords to be used by search engines and document catalogues.

-
-
-

ogcdoc, OGC document, geographic information, spatial data, spatial things, dataset, distribution, API, json, html, OpenAPI, REST, Common

-
-
-

iii. Preface

-
-
-

OGC Declaration

-
-
-

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium Inc. shall not be held responsible for identifying any or all such patent rights.

-
-
-

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

-
-
-

iv. Submitting organizations

-
-
-

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

-
-
-
    -
  • -

    Heazeltech LLC

    -
    • -
  • -

    CubeWerx Inc.

    -
    • -
-
-
-

v. Submitters

-
-
-

All questions regarding this submission should be directed to the editors or the submitters:

-
- ---- - - - - - - - - - - - - - - - - - - - - - - - - - - -

Name

Affiliation

Chuck Heazel (editor)

Heazeltech

Chris Little

UK Met Office

Carl Reed

Self

Jerome St-Louis

Ecere Corporation

Panagiotis (Peter) A. Vretanos

CubeWerx Inc.

-
-
-
-

2. Scope

-
-
-

The OGC API - Common Standard is a multi-part standard which defines a set of modules which can be used to build resource and mission-specific Web API specifications. The OGC API - Common - Part 2: Geospatial Data Standard (API-GeoData) is one of those modules.

-
-
-

Geospatial resources are typically packaged into sets or collections of related resources. A single API may provide access to a large number of collections. This API-GeoData standard provides a means of organizing these collections and defines operations for the discovery and selection of individual collections.

-
-
-

API-GeoData does not specify the nature of the geospatial data that make up a collection. Rather, it provides a basic capability which should be applicable to any geospatial resource type. Additional OGC Web API standards extend this foundation to define resource-specific capabilities.

-
-
-
-
-

3. Conformance

-
-
-

Conformance with this standard shall be checked using the tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.

-
-
-

The one Standardization Target for this standard is Web APIs.

-
-
-

API-GeoData defines API modules intended for re-use by other OGC Web API standards. For the purpose of conformance, the applicable API modules are identified by Conformance Classes. Typically this standard will only be implemented through reference to these Conformance Classes by other standards.

-
-
-

This standard identifies four conformance classes. Each conformance class is defined by one requirements class. The tests in Annex A are organized by Requirements Class. Therefore, an implementation of the Collections conformance class must pass all tests specified in Annex A for the Collections requirements class.

-
-
-

The API-Geodata requirements classes are:

-
-
- -
-
-

The Collections Requirements Class defines a common means to describe and access collections of spatial resources.

-
-
-

The Simple Query Requirements Class defines basic query parameters for the selection of individual collections of spatial resources.

-
-
-

The Collections Requirements Class does not mandate a specific encoding or format for representing resources. The HTML and JSON requirements classes specify representations for these resources in commonly used encodings for spatial data on the web.

-
-
-

API-GeoData builds on API modules defined in the OGC API - Common - Part 1: Core (API-Core) Standard. Each requirements class in the API-GeoData Standard identifies any API-Core Conformance Classes upon which it depends.

-
-
-

Proof of conformance with a Conformance Class includes demonstration of conformance with all dependencies of that Conformance Class. The abstract tests in Annex A have been organized to facilitate validation of these dependencies. These tests have been organized by requirements class. A referencing standard only has to require conformance with a Conformance Class and all of the requirements and relevant tests are identified.

-
-
-

In addition, each requirements class is organized as one or more trees. Starting at a root test, a test script can traverse the tree to address all of the required tests, each in the appropriate context.

-
-
-
-
NOTE
-
-

The structure and organization of a collection of spatial resources is very much dependent on the nature of that resource and the expected access patterns. This is information which cannot be specified in a common manner. This Standard specifies the requirements necessary to discover and understand a generic collection and its' contents. Requirements governing a specific type of resource are specified in resource-specific OGC API standards.

-
-
-
-
-
-
-

4. References

-
-
-

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

-
-
- -
-
-
-
-

5. Terms, Definitions and Abbreviated Terms

-
-
-

5.1. Terms and Definitions

-
-

This document uses the terms defined in Sub-clause 5 of OGC API - Common - Part 1: Core (OGC 19-072), which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word "shall" (not "must") is the verb form used to indicate a requirement to be strictly followed to conform to this standard.

-
-
-

For the purposes of this document, the following additional terms and definitions apply.

-
-
-
    -
  • -

    Collection
    -A geospatial resource that may be available as one or more sub-resource distributions that conform to one or more OGC API standards. (OGC 20-024)

    -
    • -
-
-
-
    -
  • -

    Coverage
    -feature that acts as a function to return values from its range for any direct position within its spatiotemporal domain, as defined in OGC Abstract Topic 6 (OGC 09-146r6)

    -
    • -
-
-
-
    -
  • -

    Dataset
    -A collection of data, published or curated by a single agent, and available for access or download in one or more representations. (DCAT)

    -
    • -
-
-
-
    -
  • -

    Distribution
    -A specific representation of a dataset. A dataset might be available in multiple serializations that may differ in various ways, including natural language, media-type or format, schematic organization, temporal and spatial resolution, level of detail or profiles (which might specify any or all of the above). (DCAT)
    -
    -EXAMPLE: a downloadable file, an RSS feed or an API.

    -
    • -
-
-
- -
-
- -
-
-
    -
  • -

    Feature Collection
    -a set of Features from a dataset

    -
    • -
-
-
- -
-
- -
-
- -
-
-
    -
  • -

    Resource Type
    -the definition of a type of resource. Resource types are re-usable components which are independent of where the resource resides in the API.

    - ---- - - - - - - -

    NOTE:

    Resource types are re-usable components that are independent of where the resource resides in the API."

    -
    • -
-
-
- -
-
- -
-
-
    -
  • -

    Temporal Coordinate System
    -temporal reference system based on an interval scale on which distance is measured as a multiple of a single unit of time. (ISO 19108)

    -
    • -
-
-
-
    -
  • -

    Temporal Position
    -location relative to a temporal reference system (ISO 19108)

    -
    • -
-
-
-
    -
  • -

    Temporal Reference System
    -reference system against which time is measured (ISO 19108)

    -
    • -
-
-
- -
-
-
    -
  • -

    Temporal Thing
    -Anything with temporal extent, i.e. duration. Examples are: the taking of a photograph, a scheduled meeting, a GPS time-stamped track-point. (W3C Basic Geo)

    -
    • -
-
-
- -
-
-
    -
  • -

    Web Resource
    -a resource that is identified by an URI.

    -
    • -
-
-
-
-

5.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

-
-
OGC
-
-

Open Geospatial Consortium

-
-
TRS
-
-

Temporal Coordinate Reference System

-
-
URI
-
-

Uniform Resource Identifier

-
-
YAML
-
-

YAML Ain’t Markup Language

-
-
-
-
-
-
-
-

6. Conventions

-
-
-

All conventions described in the OGC API - Common Part 1: Core Standard are also applicable to this API-Common Part 2: Geospatial Data Standard except where modified in the following section.

-
-
-

6.1. Identifiers

-
-

The normative provisions in this standard are denoted by the URI http://www.opengis.net/spec/ogcapi-common-2/1.0.

-
-
-

All Requirements, Requirements Modules and Conformance Modules that appear in this document are denoted by partial URIs that are relative to this base.

-
-
-

Additional information about the use of Identifiers in API-Common is provided in the OGC API - Common Users Guide.

-
-
-
- -
-

RFC 8288 (Web Linking) is used by this standard to express relationships between resources. Link relation types from the IANA Link Relations Registry are used wherever possible. Additional link relation types are registered with the OGC Naming Authority.

-
-
-

The link relationships used in API-GeoData are described in Table 1. Additional relation types may be used if the implementation warrants it.

-
- - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

Additional information on the use of link relationships is provided in the OGC API - Common Users Guide.

-
-
-
-

6.3. Geometry

-
-

6.3.1. Geospatial Geometry

-
-

Standardized concepts for geospatial characteristics are needed in order to share geographic information between applications. Concepts for geometry are key. These concepts are standardized in ISO 19107.

-
-
-

The geospatial geometry used in the OGC API - Common Standards is documented in the GML Simple Features Profile Standard. This Profile defines a subset of the ISO 19107 geometry which is aligned with the OGC Simple Features for SQL Standard. That geometry includes: Point, Curve (LineString), Surface (Polygon), MultiPoint, MultiCurve, and MultiSurface.

-
-
-
-

6.3.2. Temporal Geometry

-
-

Standardized concepts for temporal characteristics are also needed in order to share date and time information between applications. OGC API Common adopts the Gregorian calendar and a 24 hour time keeping system for its temporal geometry. All representations of that geometry which are discussed in this document conform to RFC 3339.

-
-
-

An ABNF representation of the RFC 3339 format is provided in Annex F.

-
-
-
-
-

6.4. Coordinate Reference Systems

-
-

As discussed in Chapter 9 of the W3C/OGC Spatial Data on the Web Best Practices document, the ability to express and share location in a consistent way is one of the most fundamental aspects of publishing geographic data. To do so, it is important to be clear about the coordinate reference system (CRS) within which the coordinates are expressed.

-
-
-

This API-GeoData Standard does not mandate the use of a specific coordinate reference system. However, if no CRS is specified, the default coordinate reference systems for spatial geometries are:

-
-
-
    -
  • -

    CRS84 - WGS 84 longitude and latitude without height

    -
    • -
  • -

    CRS84h - WGS 84 longitude and latitude with ellipsoidal height

    -
    • -
-
-
-

Temporal geometry is measured relative to an underlying temporal reference system (TRS). This API-GeoData Standard does not mandate a specific temporal coordinate reference system. However, all dates or timestamps discussed in this document are in the Gregorian calendar and conform to RFC 3339. In data, other temporal reference systems may be used where appropriate.

-
-
-

OGC Topic Volume 2 – Referencing by Coordinates (ISO 19111) provides the conceptual model for Coordinate Reference Systems.

-
-
-
-

6.5. API definition

-
-

6.5.1. General remarks

-
-

This OGC Standard specifies requirements and recommendations for the development of APIs that share spatial resources using a standard way of doing so. In general, deployed APIs will go beyond the requirements and recommendations stated in this Standard. They will support additional operations, parameters, and so on that are specific to the API or the software tool used to implement the API.

-
-
-

So that developers can more easily learn how to use the API, good documentation is essential. In the best case, documentation would be available both in HTML for human consumption and in a machine readable format that can be processed by software for run-time binding. OpenAPI is one way to provide that machine readable documentation.

-
-
-
-

6.5.2. Role of OpenAPI

-
-

This OGC API Standard uses OpenAPI 3.0 fragments in examples and to formally state requirements. Using OpenAPI 3.0 is not required for implementing an OGC API. Other API definition languages may be used along with, or instead of, OpenAPI. However, any API definition language used should have an associated conformance class advertised through the /conformance path.

-
-
-

This standard includes a conformance class for API definitions that follow the OpenAPI specification 3.0. Alternative API definition languages are also allowed. Conformance classes for additional API definition languages will be added as the OGC API landscape continues to evolve.

-
-
-
-

6.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 (only a subset of all possible values is allowed). An example for a constrained range of values is to explicitly specify the supported values of a string parameter or property using an enum.

    -
    • -
  • -

    Additional properties may be added to the schema definition of a Response Object.

    -
    • -
  • -

    Informative text, such as comments or description properties, may be changed or added.

    -
    • -
-
-
-

For OGC 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.

-
-
-
-

6.5.4. Reusable OpenAPI components

-
-

Reusable components for OpenAPI definitions for an OGC API are referenced from this document. They are available from the OGC Schemas Registry at http://schemas.opengis.net/ogcapi/common/part1/1.0 and http://schemas.opengis.net/ogcapi/common/part2/1.0

-
-
-

Additional information on the use of OpenAPI as an API definition is provided in the OGC API - Common Users Guide.

-
-
-
-
-
-
-

7. Overview

-
-
-

This API - Common - Part 2: Geospatial Data Standard provides a starting point for the discovery and access of geospatial resources available via a Web API. While typically accessible through a landing page (see API - Common - Part 1), this is not required. The Requirements Classes defined in this Standard are designed to be re-usable modules. To be deployed in accordance with the requirements of the API developer.

-
-
-

7.1. Collections

-
-

Spatial data is rarely considered as a single entity. Feature Collections, Coverages, Data Sets - these are all aggregations of Spatial or Temporal Things. It stands to reason that an OGC Web API would also expose its holdings as aggregates of spatial/temporal resources.

-
-
-

The purpose of the API-GeoData Standard is to provide a common connection between the API and the set of Geospatial data collections that are accessible through that API. That connection includes metadata which describes the hosted resources, common parameters for selecting subsets of the hosted resources, and URI templates for identifying the above.

-
-
-

While collection is a common term, its specific meaning is often based on the context in which it is used. Given the focus on addressing geospatial data, a definition that reflects the unique characteristics of geospatial data collections is needed. Therefore, for purposes of this standard, a collection is defined as follows:

-
-
-
    -
  • -

    Collection: A geospatial resource that may be available as one or more sub-resource distributions that conform to one or more OGC API standards.

    -
    • -
-
-
-

OGC Web API standards should extend this definition to address the specific properties of the resources they describe.

-
-
-
-

7.2. Views

-
-

A collection of geospatial data may be represented in more than one way. For example, a point cloud may be represented as a collection of Features, as a coverage, or as a color-coded map. Each is a different representation of the same data. However, the access methods and returned data structures are very different. OGC Web API standards refer to these representations as views.

-
-
-

Views should not be confused with encodings. HTTP content negotiation allows a client to negotiate the encoding (XML, JSON, etc.) to be used for the returned data. Regardless of the encoding, the underlying data model is the same. A view, on the other hand, is both a data model and a set of access mechanisms. A view is an addressable resource in its own right and must be treated as such.

-
-
-

The API-GeoData Standard does not define any views. These are defined in separate OGC Web API Standards. What is important to understand is how these view-specific standards extend the API-Geodata Standard.

-
-
-

The URI for a view of a collection follows the URI template:

-
-
-
-
/collections/{collectionId}/{viewId}
-
-
-
-

Where:

-
-
-
    -
  • -

    collectionId = an identifier for the collection

    -
    • -
  • -

    viewId = an identifier for the type of view.

    -
    • -
-
-
-

So the URIs for the point cloud described above could be:

-
-
-
    -
  • -

    For Features: /collections/mycollection/items

    -
    • -
  • -

    For Coverages: /collections/mycollection/coverage

    -
    • -
  • -

    For Maps: /collections/mycollection/maps

    -
    • -
-
-
-

The view identifiers are maintained as a controlled vocabulary by the OGC.

-
-
-

Additional information on Views is provided in the OGC API - Common Users Guide.

-
-
-
-
-
-

8. Requirements Class "Collections"

-
- ---- - - - - - - - - - - - - - - - - -

Requirements Class

http://www.opengis.net/spec/ogcapi-common-2/1.0/req/collections

Target type

Web API

Dependency

IETF RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

- ---- - - - - - - - - - - - - - - -

Requirement 1

-

/req/collections/rc-dependency-http

-

A

-

An implementation of the /Collections Requirements Class SHALL conform to HTTP 1.1.

-

B

-

If the API supports HTTPS, then the implementation SHALL also conform to HTTP over TLS.

-
- ---- - - - - - - - - - - -

Recommendation 1

-

/rec/collections/rec-dependency-core

-

A

-

An implementation of the /Collections Requirements Class SHOULD also implement the Core Conformance Class defined in OGC API - Common Part 1.

-
- ---- - - - - - - - - - - -

Recommendation 2

-

/rec/collections/rec-dependency-landing-page

-

A

-

An implementation of the /Collections Requirements Class SHOULD also implement the Landing Page Conformance Class defined in OGC API - Common Part 1.

-
-
-

This Requirements Class describes the resources and operations used to describe and access resource collections exposed through an OGC Web API. This class does not include any requirements about how resources are aggregated into collections nor about the aggregated resources themselves. That detail is reserved for resource-specific OGC Web API standards (see Views Section).

-
-
-

The two resources and their operations are defined in this Requirements Class. They are summarized in Table 2.

-
- - ------ - - - - - - - - - - - - - - - - - - - - - - -
Table 2. Collection Resources
ResourceURIHTTP MethodDescription

Collections

/collections

GET

Information which describes the set of available Collections

Collection

/collections/{collectionId}

GET

Information about a specific collection of geospatial data with links to distribution

-
-

8.1. Collections

-
-

OGC APIs typically organize their Spatial Resources into collections. Information about those collections is accessed through the /collections path and the http://www.opengis.net/def/rel/ogc/1.0/data link relation.

-
-
-

8.1.1. Operation

- ---- - - - - - - - - - - - - - - -

Requirement 2

-

/req/collections/rc-md-op

-

A

-

The API SHALL support the HTTP GET operation at the path /collections

-

B

-

The API SHALL support the HTTP GET operation on all links to a Collections Resource that have the relation type http://www.opengis.net/def/rel/ogc/1.0/data.

-
-
-
-

8.1.2. Response

- ---- - - - - - - - - - - - - - - -

Requirement 3

-

/req/collections/rc-md-success

-

A

-

A successful execution of the operation SHALL be reported as a response with a HTTP status code 200.

-

B

-

The content of that response SHALL be based upon the JSON schema collections.yaml.

-
-
-

The collections response returned by this operation is based on the collections.yaml JSON schema. Examples of collections responses are provided in Collections Response Example.

-
-
-
collections.yaml
-
-
type: object
-required:
-  - links
-  - collections
-properties:
-  links:
-    type: array
-    items:
-      $ref: link.yaml
-  timeStamp:
-    type: string
-    format: date-time
-  numberMatched:
-    type: integer
-    minimum: 0
-  numberReturned:
-    type: integer
-    minimum: 0
-  collections:
-    type: array
-    items:
-      $ref: collectionDesc.yaml
-
-
-
-

This Collections schema is further constrained by the following requirements and recommendations.

-
-
-

To support hypermedia navigation, the links property must be populated with sufficient hyperlinks to navigate through the whole dataset.

-
- ---- - - - - - - - - - - - - - - - -
-

Additional information may be available to assist in understanding and using this dataset. Links to those resources should be provided as well.

-
- ---- - - - - - - - - - - - - - - -

Recommendation 3

-

/rec/collections/rc-md-descriptions

-

A

-

If external schemas or descriptions exist that provide additional information about the structure or semantics for the resource, a 200-response SHOULD include links to each of those resources in the links property of the response (relation: describedby).

-

B

-

The type link parameter SHOULD be provided for each link. This applies to resources that describe the whole dataset.

-
-
-

The timeStamp property of the Collections response indicates when the response was generated.

-
- ---- - - - - - - - - - - -

Requirement 5

-

/req/collections/rc-timeStamp

-

A

-

If a property timeStamp is included in the response, the value SHALL be set to the time stamp when the response was generated.

-
-
-

The collections property of the Collections response provides a description of each individual collection hosted by the API.

-
- ---- - - - - - - - - - - - - - - -

Requirement 6

-

/req/collections/rc-md-items

-

A

-

For each spatial resource collection accessible through this API, metadata describing that collection SHALL be provided in the collections property of the Collections response.

-

B

-

The content of that metadata SHALL comply with the http://www.opengis.net/spec/ogcapi-common-2/1.0/rm/collection Requirements Module described in the Collection Resource Definition section of this Standard.

-
-
-

The array items included in the collection property are described in the Collection Resource section of this Requirements Class.

-
-
-

This Requirements Class does not define any parameters for use against a collections resource. Implementers who wish to support filtering of the collections to be included in a result set should implement the Simple Query Conformance Class for that purpose.

-
-
-
-

8.1.3. Error situations

-
-

See HTTP Status Codes for general guidance.

-
-
-
-
-

8.2. Resource Collection

-
-

Each resource collection is described by a set of metadata. That metadata can be accessed directly using the /collections/{collectionId} path and as an entry in the collections property of the /Collections resource.

-
-
-

8.2.1. Operation

- ---- - - - - - - - - - - - - - - -

Requirement 7

-

/req/collections/src-md-op

-

A

-

The API SHALL support the HTTP GET operation at the path /collections/{collectionId}.

-

B

-

The parameter collectionId is each id property in the collections response (JSONPath: $.collections[*].id).

-
-
-
-

8.2.2. Response

- ---- - - - - - - - - - - - - - - -

Requirement 8

-

/req/collections/src-md-success

-

A

-

A successful execution of the operation SHALL be reported as a response with a HTTP status code 200.

-

B

-

The content of that response SHALL comply with the requirements in the http://www.opengis.net/spec/ogcapi-common-2/1.0/rm/collection Requirements Module described in section Collection Resource Definition of this Standard.

-
-
-
-

8.2.3. Error Situations

-
-

See HTTP Status Codes for general guidance.

-
-
-

If the parameter collectionId does not exist on the server, the status code of the response will be 404 (see Table 5).

-
-
-
-

8.2.4. Collection Resource Definition

- ---- - - - - - - - - - - - - -

Requirements Module

http://www.opengis.net/spec/ogcapi-common-2/1.0/rm/collection

Target type

Web Resource

- ---- - - - - - - - - - - -

Requirement 9

-

/req/collections/collection-definition

-

A

-

The content of a Collection resource SHALL be based upon the JSON schema collectionDesc.yaml.

-
-
-
Collection Resource Schema
-
-
type: object
-required:
-  - id
-  - links
-properties:
-  id:
-    type: string
-    example: address
-  title:
-    type: string
-    example: address
-  description:
-    type: string
-    example: An address
-  attribution:
-    type: string
-    title: attribution for the collection
-  links:
-    type: array
-    items:
-      $ref: link.yaml
-  extent:
-    $ref: extent.yaml
-  itemType:
-    description: An indicator about the type of the items in the collection
-    type: string
-  crs:
-    description: the list of coordinate reference systems supported by the API; the first item is the default coordinate reference system
-    type: array
-    items:
-      type: string
-    default:
-      - http://www.opengis.net/def/crs/OGC/1.3/CRS84
-    example:
-      - http://www.opengis.net/def/crs/OGC/1.3/CRS84
-      - http://www.opengis.net/def/crs/EPSG/0/4326
-
-
-
-

Most of the properties of the Collection resource are self-explanatory. However, a few properties require additional explanation.

-
-
-
Attribution
-
-

The attribution element is a special type of string property. Specifically, the attribution element can contain markup text. Markup allows a text string to import images and format text. The capabilities are only limited by the markup language used. See the example collection response for an example of the use of markup in the attribution element.

-
-
-
-
Item Type
-
-

In some Geospatial collections, the members (items) that make up that collection can be individually accessed by a client. In this case, the itemType property in the Collection resource identifies the type of the items accessible from that collection.

-
- ---- - - - - - - - - - - -

Recommendation 4

-

/rec/collections/rc-md-item-type

-

A

-

If the members (items) that make up a collection can be individually accessed by a client, then the itemType key SHOULD be included in the Collection resource to indicate the type of the items (e.g. feature or record).

-
-
-
-
Links
-
-

To support hypermedia navigation, the links property must be populated with sufficient hyperlinks to navigate through the whole dataset.

-
- ---- - - - - - - - - - - - - - - - -
-

Additional information may be available to assist in understanding and using this dataset. Links to those resources should be provided as well.

-
- ---- - - - - - - - - - - - - - - -

Recommendation 5

-

/rec/collections/rc-md-items-descriptions

-

A

-

If external schemas or descriptions exist that provide additional information about the structure or semantics of the collection, a 200-response SHOULD include links to each of those resources in the links property of the response (relation: describedby).

-

B

-

The type link parameter SHOULD be provided for each link.

-
-
-
-
Extent
- ---- - - - - - - - - - - - - -

Requirements Module

http://www.opengis.net/spec/ogcapi-common-2/1.0/rm/extent

Target type

Web Resource

-
-

The extent property defines a spatial-temporal envelope that encompasses the geospatial data in the collection. Since not all collections are nicely clustered around a single place in space and time, the extent property provides flexibility in how that surface can be defined.

-
-
-
    -
  • -

    Spatial Bounding Box (Bbox) provides a set of rectangular bounding boxes which use geographic coordinates to envelope portions of the collection. Typically only the first element would be populated. Additional boxes may be useful, for example, when the collection is clustered in multiple, widely-separated locations.

    -
    • -
  • -

    Temporal Interval provides a set of temporal periods. Typically only the first temporal period would be populated. However, like Bbox, additional periods can be added if the collection does not form a single temporal cluster.

    -
    • -
-
- ---- - - - - - - - - - - - - - - -

Requirement 11

-

/req/collections/rc-md-extent

-

A

-

For each spatial collection resource, the extent property, if provided, SHALL define boundaries that encompass the spatial and temporal properties of all of the resources in this collection. The temporal extent may use null values to indicate an open time interval.

-

B

-

If a spatial resource has multiple properties with spatial or temporal information, it is the decision of the API implementation whether only a single spatial or temporal geometry property is used to determine the extent or all relevant geometries.

-
- ---- - - - - - - - - - - - - - - -

Recommendation 6

-

/rec/collections/rc-md-extent

-

A

-

If an extent contains multiple spatial boundaries (multiple bbox, etc.), then the extent SHOULD include in the first bbox a boundary which represents the union of all of the other boundaries.

-

B

-

If an extent contains multiple temporal intervals, then the extent SHOULD include as the first interval an interval which represents the union of all of the other intervals.

-
- ---- - - - - - - - - - - -

Recommendation 7

-

/rec/collections/rc-md-extent-single

-

A

-

While the spatial and temporal extents support multiple bounding boxes (bbox array) and time intervals (interval array) for advanced use cases, implementations SHOULD provide only a single bounding box or time interval unless the use of multiple values is important for the use of the dataset and agents using the API are known to be support multiple bounding boxes or time intervals.

-
- ---- - - - - - - - - - - - - - - - - - - -

Permission 1

-

/per/collections/rc-md-extent-extensions

-

A

-

API-Common only specifies requirements for spatial and temporal extents. However, the extent object MAY be extended with additional members to represent other extents, such as thermal or pressure ranges.

-

B

-

API-Common only supports

-
-
-
    -
  • -

    Spatial extents in CRS84 or CRS84h and

    -
    • -
  • -

    Temporal extents in the Gregorian calendar

    -
    • -
-
-
-

These are the only enum values in extent.json).

-

C

-

Extensions MAY add additional reference systems to the extent object.

-
-
-
-
-
-
-
-

9. Requirements Class "Simple Query"

-
- ---- - - - - - - - - - - - - - - - - - - - - -

Requirements Class

http://www.opengis.net/spec/ogcapi-common-2/1.0/req/simple-query

Target type

Web API

Dependency

Collections Requirements Class

Dependency

RFC 3339 (Date and Time on the Internet: Timestamps)

-
-

This Requirements Class describes query parameters that can be used to discover and select resource collections exposed through an OGC Web API.

-
-
-

Implementers of this Requirements Class must also implement the /Collections Requirements Class.

-
- ---- - - - - - - - - - - -

Requirement 12

-

/req/simple-query/rc-dependency-collections

-

A

-

An implementation of the Simple-Query Requirements Class SHALL demonstrate conformance with the /collections Conformance Class.

-
-
-

9.1. Parameter Requirements

-
-

Query parameters are used in URIs to limit the resources which are returned on a GET request. The OGC API - Common - Part 2: Geospatial Data Standard identifies three query parameters for use in OGC API standards:

-
-
-
    -
  • -

    bbox: Bounding Box

    -
    • -
  • -

    datetime: Date and Time

    -
    • -
  • -

    limit: Response resource count limit

    -
    • -
-
-
-

The behavior generated by these parameters is specific to the operation and resource upon which they are applied. Those behaviors are described for each resource type and operation in the Target Resource Requirements section.

-
-
-

Use of these query parameters with any specific operation is optional. Developers of OGC API-Geospatial Data servers should document their supported parameters in the API definition as describe in API-Core.

-
-
-

9.1.1. Parameter bbox

- ---- - - - - - - - - - - - - -

Requirements Module

http://www.opengis.net/spec/ogcapi-common-2/1.0/rm/bbox

Target type

Web API Query Parameter

-
-

The bbox parameter is used to select resources based on the geospatial footprint or extent.

-
-
-

The bbox parameter is defined as follows:

-
- ---- - - - - - - - - - - - - - - - - - - - - - - -

Requirement 13

-

/req/collections/rc-bbox-definition

-

A

-

The bbox parameter SHALL possess the following characteristics (using an OpenAPI Specification 3.0 fragment):

-
-
-
-
name: bbox
-in: query
-required: false
-schema:
-  type: array
-  oneOf:
-  - minItems: 4
-    maxItems: 4
-  - minItems: 6
-    maxItems: 6
-  items:
-    type: number
-style: form
-explode: false
-
-

B

-

The bounding box SHALL be provided as four or six numbers, depending on whether the coordinate reference system includes a vertical axis (height or depth):

-
-
-
    -
  • -

    Lower left corner, coordinate axis 1

    -
    • -
  • -

    Lower left corner, coordinate axis 2

    -
    • -
  • -

    Minimum value, coordinate axis 3 (optional)

    -
    • -
  • -

    Upper right corner, coordinate axis 1

    -
    • -
  • -

    Upper right corner, coordinate axis 2

    -
    • -
  • -

    Maximum value, coordinate axis 3 (optional)

    -
    • -
-

C

-

If the bounding box consists of four numbers, the coordinate reference system of the values SHALL be interpreted as WGS 84 longitude/latitude (http://www.opengis.net/def/crs/OGC/1.3/CRS84) unless a different coordinate reference system is specified in a parameter bbox-crs.

-

D

-

If the bounding box consists of six numbers, the coordinate reference system of the values SHALL be interpreted as WGS 84 longitude/latitude/ellipsoidal height (http://www.opengis.net/def/crs/OGC/0/CRS84h) unless a different coordinate reference system is specified in a parameter bbox-crs.

-
-
-

While the processing of the bbox parameter is specific to the resource and operation for which it is applied, there is a general set of requirements which all implementations must address.

-
- ---- - - - - - - - - - - - - - - - - - - -

Requirement 14

-

/req/collections/rc-bbox-response

-

A

-

If the bbox parameter is provided by the client and supported by the server, then only resources that have a spatial geometry that intersects the bounding box SHALL be part of the result set.

-

B

-

If a resource has multiple spatial geometry properties, it is the decision of the server whether only a single spatial geometry property is used to determine the extent or all relevant geometries.

-

C

-

The bbox parameter SHALL also match all resources in the collection that are not associated with a spatial geometry.

-
-
-

"Intersects" means that a coordinate that is part of the spatial geometry of the resource falls within the area specified in the parameter bbox. This includes the boundaries of the geometries. For curves the boundary includes the start and end position. For surfaces the boundary includes the outer and inner rings.

-
-
-

In case of a degenerate bounding box, the resulting geometry is used. For example, if the lower left corner is the same as the upper right corner, all resources match where the geometry intersects with this point.

-
-
-

This standard does not specify requirements for the parameter bbox-crs. Those requirements will be specified in a later version of this standard.

-
-
-

The bounding box for WGS 84 longitude/latitude is, in most cases, the sequence of minimum longitude, minimum latitude, maximum longitude and maximum latitude. However, in cases where the box spans the anti-meridian (180th meridian) the first value (west-most box edge) is larger than the third value (east-most box edge).

-
-
-
Example 1. The bounding box of the New Zealand Exclusive Economic Zone
-
-
-

The bounding box of the New Zealand Exclusive Economic Zone in WGS84 (from 160.6°E to 170°W and from 55.95°S to 25.89°S) would be represented in JSON as [ 160.6, -55.95, -170, -25.89 ] and in a query as bbox=160.6,-55.95,-170,-25.89.

-
-
-
-
-

Note that the server will return an error if a latitude value of 160.0 is used.

-
-
-

If the vertical axis is included, the third and the sixth number are the bottom and the top of the 3-dimensional bounding box.

-
-
-

A template for the definition of the parameter in YAML according to OpenAPI 3.0 is available at bbox.yaml.

-
-
-
-

9.1.2. Parameter datetime

- ---- - - - - - - - - - - - - -

Requirements Module

http://www.opengis.net/spec/ogcapi-common-2/1.0/rm/datetime

Target type

Web API Query Parameter

-
-

The datetime parameter selects resources based on their temporal extent. The definition of temporal extent is specific to the resource type being filtered.

-
-
-

The datetime parameter is defined as follows:

-
- ---- - - - - - - - - - - - - - - - - - - - - - - -

Requirement 15

-

/req/collections/rc-datetime-definition

-

A

-

The datetime parameter SHALL have the following characteristics (using an OpenAPI Specification 3.0 fragment):

-
-
-
-
name: datetime
-in: query
-required: false
-schema:
-  type: string
-style: form
-explode: false
-
-

B

-

Temporal geometries are either a date-time value or a time interval. The parameter value SHALL conform to the following syntax (using ABNF):

-
-
-
-
interval-bounded            = date-time "/" date-time
-interval-half-bounded-start = [".."] "/" date-time
-interval-half-bounded-end   = date-time "/" [".."]
-interval                    = interval-bounded / interval-half-bounded-start / interval-half-bounded-end
-datetime                    = date-time / interval
-
-

C

-

The syntax of date-time is specified by RFC 3339, 5.6.

-

D

-

Open ranges in time intervals at the start or end are supported using a double-dot (..) or an empty string for the start/end..

-
-
-

While the processing of the datetime parameter is specific to the resource and operation for which it is applied, there is a general set of requirements which all implementations must address.

-
- ---- - - - - - - - - - - - - - - -

Requirement 16

-

/req/collections/rc-datetime-response

-

A

-

If the datetime parameter is provided by the client and supported by the server, then only resources that have a temporal geometry that intersects the temporal information in the datetime parameter SHALL be part of the result set. If a resource has multiple temporal properties, it is the decision of the server whether only a single temporal property is used to determine the extent or all relevant temporal properties.

-

B

-

The datetime parameter SHALL match all resources in the collection that are not associated with a temporal geometry.

-
-
-

"Intersects" means that the time (instant or period) specified in the parameter datetime includes a timestamp that is part of the temporal geometry of the resource (again, a time instant or period). For time periods this includes the start and end time.

-
- ---- - - - - - - -

Note

-

ISO 8601-2 distinguishes open start/end timestamps (double-dot) and unknown start/end timestamps (empty string). For queries, an unknown start/end has the same effect as an open start/end.

-
-
-
Example 2. A date-time
-
-
-

February 12, 2018, 23:20:52 GMT:

-
-
-

datetime=2018-02-12T23%3A20%3A52Z

-
-
-
-
-

For resources with a temporal property that is a timestamp (such as lastUpdate), a date-time value would match all resources where the temporal property is identical.

-
-
-

For resources with a temporal property that is a date or a time interval, a date-time value would match all resources where the timestamp is on that day or within the time interval.

-
-
-
Example 3. Intervals
-
-
-

February 12, 2018, 00:00:00 GMT to March 18, 2018, 12:31:12 GMT:

-
-
-

datetime=2018-02-12T00%3A00%3A00Z%2F2018-03-18T12%3A31%3A12Z

-
-
-

February 12, 2018, 00:00:00 UTC or later:

-
-
-

datetime=2018-02-12T00%3A00%3A00Z%2F..

-
-
-

March 18, 2018, 12:31:12 UTC or earlier:

-
-
-

datetime=..%2F2018-03-18T12%3A31%3A12Z

-
-
-
-
-

A template for the definition of the parameter in YAML according to OpenAPI 3.0 is available at datetime.yaml.

-
-
-
-

9.1.3. Parameter limit

- ---- - - - - - - - - - - - - -

Requirements Module

http://www.opengis.net/spec/ogcapi-common-2/1.0/rm/limit

Target type

Web API Query Parameter

-
-

The limit parameter limits the number of resources that can be returned in a single response.

-
- ---- - - - - - - - - - - - - - - -

Requirement 17

-

/req/collections/rc-limit-definition

-

A

-

The limit parameter SHALL possess the following characteristics (using an OpenAPI Specification 3.0 fragment):

-
-
-
-
name: limit
-in: query
-required: false
-schema:
-  type: integer
-  minimum: 1
-  maximum: 10000
-  default: 10
-style: form
-explode: false
-
-

Note:

-

The values for minimum, maximum and default are only examples and MAY be changed.

-
-
-

While the processing of the limit parameter is specific to the resource and operation for which it is applied, there is a general set of requirements which all implementations must address.

-
- ---- - - - - - - - - - - - - - - - - - - -

Requirement 18

-

/req/collections/rc-limit-response

-

A

-

If the limit parameter is provided by the client and supported by the server, then the response SHALL not contain more resources than specified by the limit parameter.

-

B

-

If the API definition specifies a maximum value for the limit parameter, the response SHALL not contain more resources than this maximum value.

-

C

-

Only items are counted that are on the first level of the collection. Any nested objects contained within the explicitly requested items SHALL not be counted.

-
-
-

The number of resources returned depends on the server and the value of the limit parameter.

-
-
-
    -
  • -

    The client can request a limit to the number of resources returned.

    -
    • -
  • -

    The server may have a default value for the limit, and a maximum limit.

    -
    • -
  • -

    If the server has any more results available than it returns (the number it returns is less than or equal to the requested/default/maximum limit) then the server will include a link to the next set of results.

    -
    • -
-
- ---- - - - - - - - - - - -

Permission 2

-

/per/collections/rc-server-limit

-

A

-

If a server is configured with a maximum response size, then the server MAY page responses which exceed that threshold.

-
-
-

Since many servers will place a limit on the size of their responses, clients should be prepared to handle a paged response even if they have not specified a limit parameter in their query.

-
-
-

The effect of the limit parameter is to divide the response into a number of pages. Each page (except for the last) contains the specified number of entities. The response contains the first page. Additional pages can be accessed through hyperlink navigation.

-
- ---- - - - - - - - - - - -

Recommendation 8

-

/rec/collections/rc-next-1

-

A

-

A 200-response SHOULD include a link to the next "page" (relation: next), if more resources have been selected than returned in the response.

-
- ---- - - - - - - - - - - -

Recommendation 9

-

/rec/collections/rc-next-2

-

A

-

Dereferencing a next link SHOULD return additional resources from the set of selected resources that have not yet been returned.

-
- ---- - - - - - - - - - - -

Recommendation 10

-

/rec/collections/rc-next-3

-

A

-

The number of resources in a response to a next link SHOULD follow the same rules as for the response to the original query and again include a next link, if there are more resources in the selection that have not yet been returned.

-
-
-

Providing prev links supports navigating back and forth between pages, but depending on the implementation approach it may be too complex to implement.

-
- ---- - - - - - - - - - - -

Permission 3

-

/per/collections/rc-prev

-

A

-

A response to a next link MAY include a prev link to the resource that included the next link.

-
-
-
-
-

9.2. Target Resource Requirements

-
-

The target of the parameters defined in this conformance class is the Collection resource described in the Collections Requirements Class. The purpose of these parameters is to select a subset of Collection resources to be included in the response to a /collections request.

-
-
-

Three parameters are defined for use with the Collections resource. These parameters subset the set of Collection entries returned based on spatial, temporal, and volumetric filters. These parameters are documented in the Parameter Requirements section.

-
-
-

The collections property of the Collections response provides a description of each individual collection hosted by the API. These descriptions are based on the Resource Collection Schema. This schema is described in detail in the Resource Collection Description section of this Standard.

-
-
-

9.2.1. Spatial and Temporal Filtering

-
-

A client may select a subset of the hosted collections using the bbox and the datetime parameter. These parameters are evaluated against the extent element of each Collection item in the Collections response.

-
-
-

The requirements governing the processing of these parameters are:

-
- ---- - - - - - - - - - - - - - - -

Requirement 19

-

/req/collections/rc-bbox-collection-response

-

A

-

The API server SHALL process the bbox parameter against the Collection resources (/collections/{collectionId}) accessible through that API.

-

B

-

The bbox parameter SHALL be evaluated against the geometry defined by the bbox element of the extent property of the Collection resource.

-
- ---- - - - - - - - - - - - - - - -

Requirement 20

-

/req/collections/rc-datetime-collection-response

-

A

-

The API server SHALL process the datetime parameter against the Collection resources (/collections/{collectionId}) accessible through that API.

-

B

-

The datetime parameter SHALL be evaluated against the temporal geometry defined by the interval element of the extent property of the Collection resource.

-
-
- - - - - -
-
Note
-		 -The interval notation is taken from ISO 8601-2:2019. ISO 8601-2 distinguishes open start/end timestamps (double-dot) and unknown start/end timestamps (empty string). For queries, an unknown start/end has the same effect as an unbounded start/end. -
-
-
-
-

9.2.2. Volumetric Filtering

-
-

The client may limit the number of collections returned in a response by using the limit parameter. When applied against the /collections resource, the limit parameter indicates the maximum number of collections which should be included in a single response.

-
- ---- - - - - - - - - - - - - - - -

Requirement 21

-

/req/collections/rc-limit-collection-response

-

A

-

If the limit parameter is provided by the client, then the collections element of the collections response SHALL not contain more items than specified by the limit parameter.

-

B

-

If the API definition specifies a maximum value for the limit parameter, the collections element of the collections response SHALL not contain more items than this maximum value.

-
-
-

The server also has the option of limiting the size of the Collections response.

-
- ---- - - - - - - - - - - -

Permission 4

-

/per/collections/rc-md-items

-

A

-

To support servers with many collections, servers MAY limit the number of items included in the collections property.

-
-
-
-

9.2.3. Paged Response

-
-

If the collections response does not contain all of the collection resources available from this server, then the client should be informed of that fact.

-
- ---- - - - - - - - - - - -

Recommendation 11

-

/rec/collections/rc-paged-response

-

A

-

If the number of items in the collections element is less than the number available through the API, then the numberMatched and numberReurned properties SHOULD be included in the Collections response.

-
-
-

The numberMatched property of the Collections response indicates the number of Collection items included in the Collections response. This may be a subset of the total set of collections hosted by the API. Selection of which collections to include in a subset is controlled through the bbox, datetime and other selection parameters provided by the client.

-
- ---- - - - - - - - - - - - - - - -

Requirement 22

-

/req/collections/rc-numberMatched

-

A

-

If a property numberMatched is included in the response, the value SHALL be identical to the number of hosted collections that meet the selection parameters provided by the client.

-

B

-

A server MAY omit this information in a response, if the information about the number of matching resources is not known or difficult to compute.

-
-
-

The number of collection items included in a Collections response may be a subset of the number matched. In that case, the numberReturned property of the Collections response indicates the number of collection items returned in this "page" of the Collections response.

-
- ---- - - - - - - - - - - - - - - -

Requirement 23

-

/req/collections/rc-numberReturned

-

A

-

If a property numberReturned is included in the response, the value SHALL be identical to the number of items in the collections array in the Collections document.

-

B

-

A server MAY omit this information in a response, if the information about the number of resources in the response is not known or difficult to compute.

-
-
-

If the Collections response contains a subset of the selected collection items (numberReturned is less than numberMatched) then the Collections response should contain links for navigating to the rest of the collection items as described in the limit parameter section.

-
-
-
-
-
-
-

10. Encoding Requirements Classes

-
-
-

10.1. Overview

-
-

This clause specifies two requirements classes for encodings to be used with the Collections and Collection resources. These encodings are commonly used encodings for spatial data on the web:

-
-
- -
-
-

Neither of these encodings is mandatory. An implementation of the Collections requirements class may implement either, both, or neither of them.

-
-
-
-

10.2. Requirement Class "HTML"

-
-

Geographic information that is only accessible in formats like GeoJSON or GML has two issues:

-
-
-
    -
  • -

    The data is not discoverable using the most common mechanism for discovering information: Web search engines,

    -
    • -
  • -

    The data can not be viewed directly in a browser. Additional tools are required to view the data.

    -
    • -
-
-
-

Therefore, sharing data on the Web should include publication in HTML. To be consistent with the Web, this should be done in a way that enables users and search engines to access all of the data they are authorized to access.

-
-
-

This is discussed in detail in the W3C Best Practice. This standard therefore recommends supporting HTML as an encoding.

-
- ---- - - - - - - - - - - - - - - - - - - - - -

Requirements Class

http://www.opengis.net/spec/ogcapi-common-2/1.0/req/html

Target type

Web API

Dependency

HTML5

Dependency

Schema.org

- ---- - - - - - - - - - - -

Requirement 24

-

/req/html/definition

-

A

-

200-responses of the server SHALL support the text/html media type for the Collections and Collection resources.

-
- ---- - - - - - - - - - - -

Requirement 25

-

/req/html/content

-

A

-

Every 200-response of the API with the media type "text/html" SHALL be a HTML 5 document that includes the following information in the HTML body:

-
-
-
    -
  • -

    All information identified in the schemas of the -Response Object in the HTML <body/>, and

    -
    • -
  • -

    All links in HTML <a/> elements in the HTML <body/>.

    -
    • -
-
- ---- - - - - - - - - - - -

Recommendation 12

-

/rec/html/schema-org

-

A

-

A 200-response with the media type text/html, SHOULD include Schema.org annotations.

-
-
-
-

10.3. Requirement Class "JSON"

-
-

JSON is a text syntax that facilitates structured data interchange between programming languages. JSON is commonly used for Web-based software-to-software interchanges. Most Web developers are comfortable with using a JSON-based format, so supporting JSON is recommended for machine-to-machine interactions.

-
- ---- - - - - - - - - - - - - - - - - - - - - -

Requirements Class

http://www.opengis.net/spec/ogcapi-common-2/1.0/req/json

Target type

Web API

Dependency

IETF RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format

Dependency

JSON Schema

- ---- - - - - - - - - - - -

Requirement 26

-

/req/json/definition

-

A

-

200-responses of the server SHALL support the application/json media type for the Collections and Collection resources.

-
- ---- - - - - - - - - - - - - - - -

Requirement 27

-

/req/json/content

-

A

-

Every 200-response with the media type application/json SHALL include, or link to, a payload encoded according to the JSON Interchange Format.

-

B

-

The schema of all responses with the media type application/json SHALL conform with the JSON Schema specified for that resource.

-
-
-

JSON Schema for the Collections and Collection responses are available at collections.yaml and collectionDesc.yaml.

-
-
-

These are generic schemas that do not include any application schema information about specific resource types or their properties.

-
-
-
-
-
-

11. Media Types

-
-
-

JSON media types that would typically be supported by a server that supports JSON are:

-
-
-
    -
  • -

    application/geo+json for feature collections and features, and

    -
    • -
  • -

    application/json for all other resources.

    -
    • -
-
-
-

XML media types that would typically be supported by a server that supports XML are:

-
-
-
    -
  • -

    application/gml+xml;version=3.2 for any GML 3.2 feature collections and features,

    -
    • -
  • -

    application/gml+xml;version=3.2;profile=http://www.opengis.net/def/profile/ogc/2.0/gml-sf0 for GML 3.2 feature collections and features conforming to the GML Simple Feature Level 0 profile,

    -
    • -
  • -

    application/gml+xml;version=3.2;profile=http://www.opengis.net/def/profile/ogc/2.0/gml-sf2 for GML 3.2 feature collections and features conforming to the GML Simple Feature Level 2 profile, and

    -
    • -
  • -

    application/xml for all other resources.

    -
    • -
-
-
-

The typical HTML media type for all "web pages" in a server would be text/html.

-
-
-
-
-

12. Security Considerations

-
-
-

See OGC API - Common - Part 1: Core, Clause 11.

-
-
-
-
-

Annex A: Abstract Test Suite (Normative)

-
-
-

A.1. Introduction

-
-

OGC Web APIs are not a Web Services in the traditional sense. Rather, they define the behavior and content of a set of Resources exposed through a Web Application Programing Interface (Web API). Therefore, an API may expose resources in addition to those defined by the standard. A test engine must be able to traverse the API, identify and validate test points, and ignore resource paths which are not to be tested.

-
-
-

The Conformance Classes addressed by this Abstract Test Suite are the:

-
-
- -
-
-
-

A.2. Conformance Class Collections

- ---- - - - - - - - - - - - - - - - - - - - - -

Conformance Class

http://www.opengis.net/spec/ogcapi-common-2/1.0/conf/collections

Target type

Web API

Requirements Class

http://www.opengis.net/spec/ogcapi-common-2/1.0/req/collections

Dependency

IETF RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

-
-

The Collections Conformance Class has a dependency on the HTTP and optionally HTTPS protocols.

-
- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 1

-

/conf/collections/http

-

Test Purpose

-

Validate that all resources accessible through the /Collections Requirements Class can be accessed using the HTTP 1.1 protocol and, where approprate, TLS.

-

Requirement

-

/req/collections/rc-dependency-http

-

Test Method

-
    -
  1. -

    All compliance tests shall be configured to use the HTTP 1.1 protocol exclusively.

    -
    2. -
  2. -

    For APIs which support HTTPS, all compliance tests shall be configured to use HTTP over TLS (RFC 2818) with their HTTP 1.1 protocol.

    -
    3. -
-
-
-

Conformance with the Collections Conformance Class is demonstrated by execution, in order, of the following tests:

-
-
-
    -
  1. -

    /conf/collections/rc-md-op

    -
    2. -
  2. -

    /conf/collections/src-md-op

    -
    3. -
-
-
-

A.2.1. Collections {root}/collections Tests

- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 2

-

/conf/collections/rc-md-op

-

Test Purpose

-

Validate that information about the Collections can be retrieved from the expected location.

-

Requirement

-

/req/collections/rc-md-op
-/req/collections/rc-md-success

-

Test Method

-
    -
  1. -

    Issue an HTTP GET request without query parameters to the URL {root}/collections

    -
    2. -
  2. -

    Validate that a document was returned with a status code 200

    -
    3. -
  3. -

    Validate the contents of the returned document using test /conf/collections/rc-md-success.

    -
    4. -
-
- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 3

-

/conf/collections_rc-md-success

-

Test Purpose

-

Validate that the Collections content complies with the required structure and contents.

-

Requirement

-

/req/collections/rc-md-success
-/req/collections/rc-md-links
-/req/collections/rc-timestamp
-/req/collections/rc-md-items

-

Test Method

-
    -
  1. -

    Validate that the response document complies with /conf/collections/rc-md-links

    -
    2. -
  2. -

    Validate that the response document complies with /conf/collections/rc-timestamp

    -
    3. -
  3. -

    Validate that the response document complies with /conf/collections/rc-md-items

    -
    4. -
  4. -

    Validate the Collections resource for all supported media types using the resources and tests identified in Table 3

    -
    5. -
-
-
-

The Collections content may be retrieved in a number of different formats. The following table identifies the applicable schema document for each format and the test to be used to validate against that schema. All supported formats should be exercised.

-
- - ----- - - - - - - - - - - - - - - - - - - - -
Table 3. Schema and Tests for Collections content
FormatSchema DocumentTest ID

HTML

collections.json

/conf/html/content

JSON

collections.json

/conf/json/content

- ---- - - - - - - - - - - - - - - - - - - - - ---- - - - - - - - - - - - - - - - - - - - - - - -

Abstract Test 5

-

/conf/collections/rc-timestamp

-

Test Purpose

-

If a timeStamp property is included in the Collections document, then validate that the value of that property equates to the time that the response was generated.

-

Requirement

-

/req/collections/rc-timestamp

-

Test Method

-

IF the Collections document contains a timeStamp property, THEN

-
-
-
    -
  1. -

    Get the current date and time

    -
    2. -
  2. -

    Verify that the value of that property is within two minutes of the current date and time.

    -
    3. -
-

Note:

-

The two minute threshold was chosen to allow for test script processing time and clock synchronization issues.

-
- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 6

-

/conf/collections/rc-md-items

-

Test Purpose

-

Validate that each collection accessible through the API is described in the Collections document.

-

Requirement

-

/req/collections/rc-md-items

-

Test Method

-
    -
  1. -

    Verify that the Collections document includes a collections property.

    -
    2. -
  2. -

    Verify that the collections property is an array.

    -
    3. -
  3. -

    Verify that there is an entry in the collections property for each resource collection accessible through the API.

    -
    4. -
  4. -

    Verify that each entry in the collections array is valid according to /conf/collections/rc-md-collection-content.

    -
    5. -
-
-
-
-

A.2.2. Collection {root}/collections/{collectionId} Tests

- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 7

-

/conf/collections/src-md-op

-

Test Purpose

-

Validate that the Collection content can be retrieved from the expected location.

-

Requirement

-

/req/collections/src-md-op
-/conf/collections/req-md-success

-

Test Method

-

For every Collection described in the Collections content, issue an HTTP GET request to the URL /collections/{collectionId} where {collectionId} is the id property for the collection.

-
-
-
    -
  1. -

    Validate that a Collection was returned with a status code 200

    -
    2. -
  2. -

    Validate the contents of the returned document using test /conf/collections/src-md-success.

    -
    3. -
-
- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 8

-

/conf/collections/src-md-success

-

Test Purpose

-

Validate that the Collection content complies with the required structure and contents.

-

Requirement

-

/req/collections/src-md-success

-

Test Method

-
    -
  1. -

    Validate the structure and content of the response document using /conf/collections/rc-md-items-collection-content

    -
    2. -
  2. -

    Verify that the content of the response is consistent with the content for this Resource Collection in the /collections response. That is, the values for id, title, description and extent are identical.

    -
    3. -
-
- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 9

-

/conf/collections/rc-md-collection-content

-

Test Purpose

-

Validate that a Collection document complies with the required structure and values.

-

Requirement

-

/req/collections/collection-definition
-/req/collections/rc-md-items-links
-/req/collections/rc-md-extent

-

Test Method

-

FOR a each Collection document, validate:

-
-
-
    -
  1. -

    That the Collection document includes an id property.

    -
    2. -
  2. -

    That the Collection document complies with /conf/collections/rc-md-items-links

    -
    3. -
  3. -

    That any extent properties included in the Collection document comply with /conf/collections/rc-md-extent

    -
    4. -
  4. -

    Validate the content of the Collection document for all supported media types using the resources and tests identified in Table 4

    -
    5. -
-
-
-

The Collection content may be retrieved in a number of different formats. The following table identifies the applicable schema document for each format and the test to be used to validate against that schema. All supported formats should be exercised.

-
- - ----- - - - - - - - - - - - - - - - - - - - -
Table 4. Schema and Tests for Collection content
FormatSchema DocumentTest ID

HTML

collectionDesc.json

/conf/html/content

JSON

collectionDesc.json

/conf/json/content

- ---- - - - - - - - - - - - - - - - - - - - - ---- - - - - - - - - - - - - - - - - - - - - - - -

Abstract Test 11

-

/conf/collections/rc-md-extent

-

Test Purpose

-

Validate the extent property if it is present

-

Requirement

-

/req/collections/rc-md-extent

-

Test Method

-

IF the extent property is present, THEN:

-
-
-
    -
  1. -

    Verify that the extent provides bounding boxes that include all spatial geometries in this resource.

    -
    2. -
  2. -

    Verify that the extent provides time intervals that include all temporal geometries in this resource.

    -
    3. -
-

Note:

-

A temporal extent of null indicates an open time interval.

-
-
-
-
-

A.3. Conformance Class Simple query

- ---- - - - - - - - - - - - - - - - - - - - - -

Conformance Class

http://www.opengis.net/spec/ogcapi-common-2/1.0/conf/simple-query

Target type

Web API

Requirements Class

http://www.opengis.net/spec/ogcapi-common-2/1.0/req/simple-query

Dependency

http://www.opengis.net/spec/ogcapi-common-2/1.0/conf/collections

-
-

The Simple Query Conformance Class has a dependency on the Collections Conformance Class.

-
- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 12

-

/conf/simple-query/dependency-collections

-

Test Purpose

-

Validate that Collections Conformance Class has been implemented

-

Requirement

-

/req/simple-query/rc-dependency-collections

-

Test Method

-

Validate that the conformance test for the Collections Conformance Class has been pased.

-
-
-

Conformance with the Simple Query Conformance Class is demonstrated by execution of the following tests:

-
-
-
    -
  1. -

    /conf/collections/rc-op-bbox

    -
    2. -
  2. -

    /conf/collections/rc-op-datetime

    -
    3. -
  3. -

    /conf/collections/rc-op-limit

    -
    4. -
-
-
-

A.3.1. Bounding Box Tests

- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 13

-

/conf/collections/rc-op-bbox

-

Test Purpose

-

Validate that resources can be identified and extracted from an API server using the bbox query parameter.

-

Requirement

-

/req/collections/rc-bbox-definition
-/req/collections/rc-bbox-response

-

Test Method

-
    -
  1. -

    Select a valid bbox value which intersects a subset of the resource collections available through the API implementation.

    -
    2. -
  2. -

    Construct a bbox query parameter using the selected value.

    -
    3. -
  3. -

    Validate the bbox query parameter using /conf/collections/rc-bbox-definition

    -
    4. -
  4. -

    Issue an HTTP GET request to the URL {root}/collections. Include the validated bbox query parameter.

    -
    5. -
  5. -

    Validate that a document was returned with a status code 200

    -
    6. -
  6. -

    Validate the contents of the returned document using:

    -
    -
      -
    1. -

      /conf/collections_rc-md-success and

      -
      2. -
    2. -

      /conf/collections/rc-bbox-response and

      -
      3. -
    3. -

      /conf/collections/rc-paged-response.

      -
      4. -
    -
    -
    7. -
-
- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 14

-

/conf/collections/rc-bbox-definition

-

Test Purpose

-

Validate that the bounding box query parameter is constructed correctly.

-

Requirement

-

/req/collections/rc-bbox-definition

-

Test Method

-

Verify that the bbox query parameter complies with the following definition (using an OpenAPI Specification 3.0 fragment):

-
-
-
-
name: bbox
-in: query
-required: false
-schema:
-  type: array
-  minItems: 4
-  maxItems: 6
-  items:
-    type: number
-style: form
-explode: false
-
-
-
-

Use a bounding box with four numbers in all requests where the collection has spatial geometries in 2D:

-
-
-
    -
  • -

    Lower left corner, WGS 84 longitude

    -
    • -
  • -

    Lower left corner, WGS 84 latitude

    -
    • -
  • -

    Upper right corner, WGS 84 longitude

    -
    • -
  • -

    Upper right corner, WGS 84 latitude

    -
    • -
-
-
-

Use a bounding box with six numbers in all requests where the collection has spatial geometries in 3D:

-
-
-
    -
  • -

    Lower left corner, WGS 84 longitude

    -
    • -
  • -

    Lower left corner, WGS 84 latitude

    -
    • -
  • -

    Minimum value, WGS 84 ellipsoidal height

    -
    • -
  • -

    Upper right corner, WGS 84 longitude

    -
    • -
  • -

    Upper right corner, WGS 84 latitude

    -
    • -
  • -

    Maximum value, WGS 84 ellipsoidal height

    -
    • -
-
- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 15

-

/conf/collections/rc-bbox-response

-

Test Purpose

-

Validate that the bbox query parameter is processed correctly.

-

Requirement

-

/req/collections/rc-bbox-response
-/req/collections/rc-bbox-collection-response

-

Test Method

-

DO FOR each Collection in the collections element of the response:

-
-
-
    -
  1. -

    Extract the spatial geometry from the bbox element of the extent property of the Collection resource.

    -
    2. -
  2. -

    IF there is a spatial geometry, verify that the coordinate reference system of the spatial geometry is WGS 84 longitude/latitude (http://www.opengis.net/def/crs/OGC/1.3/CRS84 or http://www.opengis.net/def/crs/OGC/0/CRS84h.

    -
    3. -
  3. -

    IF there is a spatial geometry, verify that the spatial geometry intersects the bounding box defined by the bbox parameter.

    -
    4. -
-
-
-
-

A.3.2. Date-Time Tests

- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 16

-

/conf/collections/rc-op-datetime

-

Test Purpose

-

Validate that resources can be identified and extracted from an API server using the datetime query parameter.

-

Requirement

-

/req/collections/rc-datetime-definition
-/req/collections/rc-datetime-response

-

Test Method

-
    -
  1. -

    Select a valid datetime value which intersects a subset of the resource collections available through the API implementation.

    -
    2. -
  2. -

    Construct a datetime query parameter using the selected value.

    -
    3. -
  3. -

    Validate the datetime query parameter using /conf/collections/rc-datetime-definition

    -
    4. -
  4. -

    Issue an HTTP GET request to the URL {root}/collections. Include the validated datetime query parameter.

    -
    5. -
  5. -

    Validate that a document was returned with a status code 200

    -
    6. -
  6. -

    Validate the contents of the returned document using:

    -
    -
      -
    1. -

      /conf/collections_rc-md-success and

      -
      2. -
    2. -

      /conf/collections/rc-datetime-response and

      -
      3. -
    3. -

      /conf/collections/rc-paged-response.

      -
      4. -
    -
    -
    7. -
-
- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 17

-

/conf/collections/rc-datetime-definition

-

Test Purpose

-

Validate that the dateTime query parameter is constructed correctly.

-

Requirement

-

/req/collections/rc-datetime-definition

-

Test Method

-

Verify that the datetime query parameter complies with the following definition (using an OpenAPI Specification 3.0 fragment):

-
-
-
-
name: datetime
-in: query
-required: false
-schema:
-  type: string
-style: form
-explode: false
-
-
- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 18

-

/conf/collections/rc-datetime-response

-

Test Purpose

-

Validate that the datetime query parameter is processed correctly.

-

Requirement

-

/req/collections/rc-datetime-definition
-/req/collections/rc-datetime-response
-/req/collections/rc-datetime-collection-response

-

Test Method

-

DO FOR each Collection in the collections element of the response:

-
-
-
    -
  1. -

    Extract the temporal geometry from the interval element of the extent property of the Collection resource.

    -
    2. -
  2. -

    IF there is a temporal geometry, verify that the temporal geometry intersects the temporal period defined by the datetime parameter.

    -
    3. -
  3. -

    IF there is a temporal geometry, validate that the processing of the datetime parameter complies with the syntax described in /req/collections/rc-datetime-definition (B, C, and D).

    -
    4. -
-
-
-
-

A.3.3. Limit Tests

- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 19

-

/conf/collections/rc-op-limit

-

Test Purpose

-

Validate that the client can place a limit on the number of resources returned.

-

Requirement

-

/req/collections/rc-limit-definition
-/req/collections/rc-limit-response

-

Test Method

-
    -
  1. -

    Select a valid limit value which is less than the number of resource collections available through the API implementation and less than any limits advertised for the server.

    -
    2. -
  2. -

    Construct a limit query parameter using the selected value.

    -
    3. -
  3. -

    Validate the limit query parameter using /conf/collections/rc-limit-definition

    -
    4. -
  4. -

    Issue an HTTP GET request to the URL {root}/collections. Include the validated limit query parameter.

    -
    5. -
  5. -

    Validate that a document was returned with a status code 200

    -
    6. -
  6. -

    Validate the contents of the returned document using:

    -
    -
      -
    1. -

      /conf/collections_rc-md-success and

      -
      2. -
    2. -

      /conf/collections/rc-limit-response and

      -
      3. -
    3. -

      /conf/collections/rc-paged-response.

      -
      4. -
    -
    -
    7. -
-
- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 20

-

/conf/collections/rc-limit-definition

-

Test Purpose

-

Validate that the limit query parameter is constructed correctly.

-

Requirement

-

/req/collections/rc-limit-definition

-

Test Method

-

Verify that the limit query parameter complies with the following definition (using an OpenAPI Specification 3.0 fragment):

-
-
-
-
name: datetime
-in: query
-required: false
-schema:
-  type: string
-style: form
-explode: false
-
-
- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 21

-

/conf/collections/rc-limit-response

-

Test Purpose

-

Validate that the limit query parameters are processed correctly.

-

Requirement

-

/req/collections/rc-limit-response
-/req/collections/rc-limit-collection-response

-

Test Method

-
    -
  1. -

    Count the items in the collections element of the response:

    -
    2. -
  2. -

    Verify that this count is not greater than the value specified for the limit parameter.

    -
    3. -
  3. -

    If the API definition specifies a maximum value for limit parameter, verify that the count does not exceed this maximum value.

    -
    4. -
-
- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 22

-

/conf/collections/rc-paged-response

-

Test Purpose

-

Validate that the numberMatched and numberReturned parameters, if present, are populated correctly..

-

Requirement

-

/req/collections/rc-numberMatched
-/req/collections/rc-numberReturned

-

Test Method

-
    -
  1. -

    IF the numerMatched property is included in the response, THEN verify that the value of the numberMatched parameter is identical to the number of hosted resources that meet the selection parameters provided by the client.

    -
    2. -
  2. -

    IF the numberReturned property is included in the response, THEN verify that the value of the numberReturned parameter is identical to the number of resources returned in the response.

    -
    3. -
-
-
-
-
-

A.4. Conformance Class JSON

- ---- - - - - - - - - - - - - - - - - - - - - -

Conformance Class

http://www.opengis.net/spec/ogcapi-common-2/1.0/conf/json

Target type

Web API

Requirements Class

http://www.opengis.net/spec/ogcapi-common-2/1.0/req/json

Dependency

http://www.opengis.net/spec/ogcapi-common-2/1.0/conf/collections

-
-

A.4.1. JSON Definition

- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 23

-

/conf/json/definition

-

Test Purpose

-

Verify support for JSON

-

Requirement

-

/req/json/definition

-

Test Method

-
    -
  1. -

    A resource is requested with response media type of application/json

    -
    2. -
  2. -

    All 200-responses SHALL support the media type application/json.

    -
    3. -
-
-
-
-

A.4.2. JSON Content

- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 24

-

/conf/json/content

-

Test Purpose

-

Verify the content of a JSON document given an input document and schema.

-

Requirement

-

/req/json/content

-

Test Method

-
    -
  1. -

    Validate that the document is a JSON document.

    -
    2. -
  2. -

    Validate the document against the schema using a JSON Schema validator.

    -
    3. -
-
-
-
-
-

A.5. Conformance Class HTML

- ---- - - - - - - - - - - - - - - - - - - - - -

Conformance Class

http://www.opengis.net/spec/ogcapi-common-2/1.0/conf/html

Target type

Web API

Requirements Class

http://www.opengis.net/spec/ogcapi-common-2/1.0/req/html

Dependency

http://www.opengis.net/spec/ogcapi-common-2/1.0/conf/collections

-
-

A.5.1. HTML Definition

- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 25

-

/conf/html/definition

-

Test Purpose

-

Verify support for HTML

-

Requirement

-

/req/html/definition

-

Test Method

-

Verify that every 200-response of every operation of the API where HTML was requested is of media type text/html

-
-
-
-

A.5.2. HTML Content

- ---- - - - - - - - - - - - - - - - - - - -

Abstract Test 26

-

/conf/html/content

-

Test Purpose

-

Verify the content of an HTML document given an input document and schema.

-

Requirement

-

/req/html/content

-

Test Method

-
    -
  1. -

    Validate that the document is an HTML 5 document

    -
    2. -
  2. -

    Manually inspect the document against the schema.

    -
    3. -
-
-
-
-
-
-
-

Annex B: Examples (Informative)

-
-
-

B.1. Collections Response Example

-
-

This collections example response in JSON is for a dataset with a single "buildings" feature collection.

-
-
-

There is a link to the collections response itself (link relation type: "self").

-
-
-

Representations of this resource in other formats are referenced (link relation type: "alternate").

-
-
-

An additional link is to a GML application schema for the collection (link relation type: "describedby").

-
-
-
-
{
-  "links": [
-    { "href": "http://data.example.org/collections.json",
-      "rel": "self", "type": "application/json", "title": "this document" },
-    { "href": "http://data.example.org/collections.html",
-      "rel": "alternate", "type": "text/html", "title": "this document as HTML" },
-    { "href": "http://schemas.example.org/1.0/foobar.xsd",
-      "rel": "describedby", "type": "application/xml", "title": "XML schema for Acme Corporation data" }
-  ],
-  "collections": [
-    {
-      "id": "buildings",
-      "title": "Buildings",
-      "description": "Buildings in the city of Bonn.",
-      "extent": {
-        "spatial": [ 7.01, 50.63, 7.22, 50.78 ],
-        "temporal": [ "2010-02-15T12:34:56Z", "2018-03-18T12:11:00Z" ]
-      },
-      "links": [
-        { "href": "http://example.org/concepts/building.html",
-          "rel": "describedby", "type": "text/html",
-          "title": "Feature catalogue for buildings" }
-      ]
-    }
-  ]
-}
-
-
-
-
-

B.2. Collection Object Examples

-
-

B.2.1. Building Collection

-
-

This Collection Description example response in JSON is for a single "buildings" collection.

-
-
-

The basic descriptive information includes:

-
-
-
    -
  • -

    "id": an identifier for this collection

    -
    • -
  • -

    "title": the title of this collection

    -
    • -
  • -

    "description": self evident

    -
    • -
  • -

    "attribution": markup providing attribution (owner, producer, logo, etc.) of this collection

    -
    • -
-
-
-

The response includes links to:

-
-
-
    -
  • -

    There is a link to the response itself (link relation type: "self").

    -
    • -
  • -

    Representations of this response in other formats are referenced using link relation type "alternate".

    -
    • -
  • -

    An additional link is to a GML application schema for the collection - using:https://www.iana.org/assignments/link-relations/link-relations.xhtml[link relation type] "describedby".

    -
    • -
-
-
-

Finally, this response includes both spatial and temporal extents.

-
-
-

Reference system information is not provided as the service provides geometries only in the default system (spatial: WGS 84 longitude/latitude; temporal: Gregorian calendar).

-
-
-
-
{
-  "id": "1234567890",
-  "title": "Example Collection Description Response",
-  "description": "This is an example of a Collection Description in JSON format",
-  "attribution": "<a href='www.ign.es' rel=' '>IGN</a> <a href='www.govdata.de/dl-de/by-2-0'>(c)</a>",
-  "links": [
-    { "href": "http://data.example.org/collections.json",
-      "rel": "self", "type": "application/json", "title": "this document" },
-    { "href": "http://data.example.org/collections.html",
-      "rel": "alternate", "type": "text/html", "title": "this document as HTML" },
-    { "href": "http://schemas.example.org/1.0/foobar.xsd",
-      "rel": "describedby", "type": "application/xml", "title": "XML schema for Acme Corporation data" }
-  ],
-  "extent": {
-    "spatial": [ 7.01, 50.63, 7.22, 50.78 ],
-    "temporal": [ "2010-02-15T12:34:56Z", "2018-03-18T12:11:00Z" ]
-    }
-}
-
-
-
-
-
-
-
-

Annex C: Revision History

-
- ------- - - - - - - - - - - - - - - - - - - -
DateReleaseEditorPrimary clauses modifiedDescription

2021-10-06

0.0.9

Charles Heazel

all

SWG review draft.

-
-
-
-

Annex D: Glossary

-
-
-
    -
  • -

    Conformance Test Module
    -set of related tests, all within a single conformance test class (OGC 08-131r3)

    -
    • -
-
- ---- - - - - - - -

NOTE:

When no ambiguity is possible, the word test may be omitted. i.e. conformance test module is the same as conformance module. Conformance modules may be nested in a hierarchical way.
-This term and those associated to it are included here for consistency with ISO 19105.

-
- -
- ---- - - - - - - -

NOTE:

When no ambiguity is possible, the word test may be left out, so conformance test class may be called a conformance class.

-
-
    -
  • -

    Executable Test Suite (ETS)
    -A set of code (e.g. Java and CTL) that provides runtime tests for the assertions defined by the ATS. Test data required to do the tests are part of the ETS (OGC 08-134)

    -
    • -
-
-
-
    -
  • -

    Recommendation
    -expression in the content of a document conveying that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited (OGC 08-131r3)

    -
    • -
-
- ---- - - - - - - -

NOTE:

"Although using normative language, a recommendation is not a requirement. The usual form replaces the shall (imperative or command) of a requirement with a should (suggestive or conditional)." (ISO Directives Part 2)

-
-
    -
  • -

    Requirement
    -expression in the content of a document conveying criteria to be fulfilled if compliance with the document is to be claimed and from which no deviation is permitted (OGC 08-131r3)

    -
    • -
-
-
-
    -
  • -

    Requirements Class
    -aggregate of all requirement modules that must all be satisfied to satisfy a conformance test class (OGC 08-131r3)

    -
    • -
-
-
- -
-
-
    -
  • -

    Standardization Target
    -entity to which some requirements of a standard apply (OGC 08-131r3)

    -
    • -
-
- ---- - - - - - - -

NOTE:

The standardization target is the entity which may receive a certificate of conformance for a requirements class.

-
-
-
-

Annex E: Bibliography

-
-
- -
-
-
-
-

Annex F: Backus-Naur Forms

-
-
-

F.1. BNF for URI

-
-

The following Augmented Backus-Naur Form (ABNF) is from Appendix A of IETF RFC 3986.

-
-
-
-
URI           = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
-
-
-
-
-
hier-part     = "//" authority path-abempty
-             / path-absolute
-             / path-rootless
-             / path-empty
-
-
-
-
-
URI-reference = URI / relative-ref
-
-
-
-
-
absolute-URI  = scheme ":" hier-part [ "?" query ]
-
-
-
-
-
relative-ref  = relative-part [ "?" query ] [ "#" fragment ]
-
-
-
-
-
relative-part = "//" authority path-abempty
-                 / path-absolute
-                 / path-noscheme
-                 / path-empty
-
-
-
-
-
scheme        = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
-
-
-
-
-
authority     = [ userinfo "@" ] host [ ":" port ]
-userinfo      = *( unreserved / pct-encoded / sub-delims / ":" )
-host          = IP-literal / IPv4address / reg-name
-port          = *DIGIT
-
-
-
-
-
IP-literal    = "[" ( IPv6address / IPvFuture  ) "]"
-
-
-
-
-
IPvFuture     = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
-
-
-
-
-
IPv6address   =                             6( h16 ":" ) ls32
-              /                       "::" 5( h16 ":" ) ls32
-              / [               h16 ] "::" 4( h16 ":" ) ls32
-              / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
-              / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
-              / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
-              / [ *4( h16 ":" ) h16 ] "::"              ls32
-              / [ *5( h16 ":" ) h16 ] "::"              h16
-              / [ *6( h16 ":" ) h16 ] "::"
-
-
-
-
-
h16           = 1*4HEXDIG
-ls32          = ( h16 ":" h16 ) / IPv4address
-IPv4address   = dec-octet "." dec-octet "." dec-octet "."
-
-
-
-
-
dec-octet     = DIGIT                 ; 0-9
-              / %x31-39 DIGIT         ; 10-99
-              / "1" 2DIGIT            ; 100-199
-              / "2" %x30-34 DIGIT     ; 200-249
-              / "25" %x30-35          ; 250-255
-
-
-
-
-
reg-name      = *( unreserved / pct-encoded / sub-delims )
-
-
-
-
-
path          = path-abempty    ; begins with "/" or is empty
-              / path-absolute   ; begins with "/" but not "//"
-              / path-noscheme   ; begins with a non-colon segment
-              / path-rootless   ; begins with a segment
-              / path-empty      ; zero characters
-
-
-
-
-
path-abempty  = *( "/" segment )
-path-absolute = "/" [ segment-nz *( "/" segment ) ]
-path-noscheme = segment-nz-nc *( "/" segment )
-path-rootless = segment-nz *( "/" segment )
-path-empty    = 0<pchar>
-
-
-
-
-
segment       = *pchar
-segment-nz    = 1*pchar
-segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
-              ; non-zero-length segment without any colon ":"
-
-
-
-
-
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
-
-
-
-
-
query         = *( pchar / "/" / "?" )
-
-
-
-
-
fragment      = *( pchar / "/" / "?" )
-
-
-
-
-
pct-encoded   = "%" HEXDIG HEXDIG
-
-
-
-
-
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
-reserved      = gen-delims / sub-delims
-gen-delims    = ":" / "/" / "?" / "#" / "[" / "]" / "@"
-sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
-              / "*" / "+" / "," / ";" / "="
-
-
-
-
-

F.2. BNF for Date-Time

-
-

The following Augmented Backus-Naur Form (ABNF) is from IETF RFC 3339.

-
-
-
-
date-fullyear  = 4DIGIT
-date-month     = 2DIGIT  ; 01-12
-date-mday      = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on month/year
-time-hour      = 2DIGIT  ; 00-23
-time-minute    = 2DIGIT  ; 00-59
-time-second    = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second rules
-time-secfrac   = "." 1*DIGIT
-time-numoffset = ("+" / "-") time-hour ":" time-minute
-time-offset    = "Z" / time-numoffset
-partial-time   = time-hour ":" time-minute ":" time-second [time-secfrac]
-full-date      = date-fullyear "-" date-month "-" date-mday
-full-time      = partial-time time-offset
-date-time      = full-date "T" full-time
-
-
-
-

Note that unlike ISO 8601, the local time zone offset is required by RFC 3339.

-
-
-
-
-
-

Annex G: HTTP Status Codes

-
-
-

Table 5 lists the main HTTP status codes that clients should be prepared to receive. This includes support for specific security schemes or URI redirection. In addition, other error situations may occur in the transport layer outside of the server.

-
- - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 5. Typical HTTP status codes
Status codeDescription

200

A successful request.

302

The target resource was found but resides temporarily under a different URI. A 302 response is not evidence that the operation has been successfully completed.

303

The server is redirecting the user agent to a different resource. A 303 response is not evidence that the operation has been successfully completed.

304

An entity tag was provided in the request and the resource has not changed since the previous request.

307

The target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.

308

Indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs.

400

The server cannot or will not process the request due to an apparent client error. For example, a query parameter had an incorrect value.

401

The request requires user authentication. The response includes a WWW-Authenticate header field containing a challenge applicable to the requested resource.

403

The server understood the request, but is refusing to fulfill it. While status code 401 indicates missing or bad authentication, status code 403 indicates that authentication is not the issue, but the client is not authorized to perform the requested operation on the resource.

404

The requested resource does not exist on the server. For example, a path parameter had an incorrect value.

405

The request method is not supported. For example, a POST request was submitted, but the resource only supports GET requests.

406

Content negotiation failed. For example, the Accept header submitted in the request did not support any of the media types supported by the server for the requested resource.

500

An internal error occurred in the server.

-
-

The status codes described in Table 5 do not cover all possible conditions. See IETF RFC 7231 for a complete list of HTTP status codes.

-
-
-
-
-

Annex H: OGC Web API Guidelines

-
-
-

The following table discusses how this standard addresses the design principles documented in the OGC Web API Guidelines.

-
- ----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

#

Principle

Discussion

1

Don’t reinvent

This standard doesn’t define any new concepts. It generalizes concepts defined in other standards so that they can serve as re-usable modules for almost any API standard.

2

Keep it simple and intuitive

OGC Web APIs are developed using a building block approach. Conformance Classes are defined that encompase requirements sufficient to create a usable software module and no more. Complex APIs are constructed by assembling the applicable Conformance Classes.

3

Use well-known resource types

Except where unique to a specific Conformance Class, all resources types are IANA or OGC registered types.
-OGC Web API standards do not mandate an encoding. The encodings supported by an API are specified by the corresponding encoding Conformance Classes. All encodings used to-date are IANA registered media types.

4

Construct consistent URIs

OGC Web APIs are built from standardized modules using standardized patterns. This modular approach assures that the URIs are consistent across OGC Web APIs.
-OGC Web API Common defines stylistic conventions for query parameters, query values, identifiers, and path elements used to create OGC Web API URIs.

5

Use HTTP methods consistent with RFC 7231

OGC web APIs are restricted to the HTTP methods defined in IETF RFC 7231.

6

Put selection criteria behind the ‘?’

The conventions described in OGC API - Common Part 1 are also applicable to OGC API - Common Part 2. This includes the use of the "?" to deliminate query parameters from the rest of the URI.

7

Error handling and use of HTTP status codes

This standard identifies the applicable HTTP status codes and under what conditions they should be returned. Status codes and supporting information are returned in the HTTP response using a reporting structure based on RFC 7807.

8

Use explicit list of HTTP status codes

Annex G: HTTP Status Codes provides a list of the HTTP status codes that implementers of this standard should be prepared to generate and accept. This list is not exhaustive (see guideline #1).

9

Use of HTTP header

OGC API Common does not preclude use of HTTP headers where it is appropriate to do so.
-Only standard HTTP headers are used.
-Due to the common use of the HATEOAS pattern in OGC Web APIs, HTTP headers are not always accessible. The use of query parameter overrides is allowed.

10

Allow flexible content negotiation

IETF RFC 7231 content negotiation is avalable on all transactions.
-Since the HTTP headers are not always accessible, content negotiation may be performed through a query parameter (see #9).

11

Pagination

Of the resources defined in API-Common Part 2, only the /collections resource has "listable" content. Paging of this content can be requested by the client if the Simple Query Requirements Class is implemented. Server implementations have the option to implement paging based on internal parameters.

12

Processing resources

Processing resources are not addressed by this Standard.

13

Support metadata

Support for metadata is provided through metadata resource links. Specifically the data-meta relationship.

14

Consider your security needs

While not mandated, use of HTTPS vs. HTTP is encouraged throughout this standard.
-Authentication is not precluded by this standard, but in keeping with guideline #1, this standard does not presume to dictate what authentication methods can be used.
-API-Common - Part 2 only defines GET requests. The security issues associated with CRUD are not applicable to this standard.

15

API description

The API definition is provided by API-Common Part 1. It is out of scope for this standard.
-OpenAPI is the only API definition type currently supported.

16

Use well-known identifiers

IANA identifiers are used where they are available. Where no IANA identifiers are appropriate, OGC registered identifiers are used.
-OGC identifiers are only used after they have been reviewed and approved by the OGC Naming Authority.

17

Use explicit relations

All relations in this standard are typed using relation types registered in the IANA or the OGC relation type registers.

18

Support W3C cross-origin resource sharing

This guideline is addressed in OGC API - Common Part 1.

19

Resource encodings

Conformance classes for both HTML and JSON have been defined. Implementation of both the HTML and JSON Conformance Classes is recommended.

20

Good APIs are testable from the beginning

The Abstract Test Suite (ATS) for this standard is provided in Annex A.
-The ATS is defined to sufficient level of detail to validate that it is implementable and comprehensive

21

Specify whether operations are safe and/or idempotent

According to IETF RFC 7231 "the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe." and the "PUT, DELETE, and safe request methods are idempotent". All request methods in this standard (GET) are both safe and idempotent.

22

Make resources discoverable

All resouces defined in this standard can be navigated to through resource links and optional standard paths. All resource links are typed using registered relation types. These links are encoded using a standard link structure that includes the media type, language, and title of the resource.

23

Make default behavior explicit

This Standard defines the proper and allowed responses for any valid or invalid request.

-
-
-
-
- - - \ No newline at end of file diff --git a/collections/20-024.pdf b/collections/20-024.pdf deleted file mode 100644 index 79884f5..0000000 Binary files a/collections/20-024.pdf and /dev/null differ diff --git a/collections/abstract_tests/ATS_class_collections.adoc b/collections/abstract_tests/ATS_class_collections.adoc index d50bcab..fe2c441 100644 --- a/collections/abstract_tests/ATS_class_collections.adoc +++ b/collections/abstract_tests/ATS_class_collections.adoc @@ -35,8 +35,8 @@ include::collections/ATS_src-md-op.adoc[] include::collections/ATS_src-md-success.adoc[] -include::../../api_modules/collection/ATS/ATS_rc-md-collection-content.adoc[] +include::collections/ATS_rc-md-collection-content.adoc[] -include::../../api_modules/collection/ATS/ATS_rc-md-items-links.adoc[] +include::collections/ATS_rc-md-items-links.adoc[] -include::../../api_modules/extent/ATS/ATS_rc-md-extent.adoc[] +include::extent/ATS_rc-md-extent.adoc[] diff --git a/collections/abstract_tests/ATS_class_simple-query.adoc b/collections/abstract_tests/ATS_class_simple-query.adoc index 222e105..270c9ab 100644 --- a/collections/abstract_tests/ATS_class_simple-query.adoc +++ b/collections/abstract_tests/ATS_class_simple-query.adoc @@ -20,28 +20,26 @@ Conformance with the <> Conformance Class is demon ==== Bounding Box Tests -include::../../api_modules/bbox/ATS/ATS_rc-op-bbox.adoc[] +include::bbox/ATS_rc-op-bbox.adoc[] -include::../../api_modules/bbox/ATS/ATS_rc-bbox-definition.adoc[] +include::bbox/ATS_rc-bbox-definition.adoc[] -include::../../api_modules/bbox/ATS/ATS_rc-bbox-response.adoc[] +include::bbox/ATS_rc-bbox-response.adoc[] ==== Date-Time Tests -include::../../api_modules/datetime/ATS/ATS_rc-op-datetime.adoc[] +include::datetime/ATS_rc-op-datetime.adoc[] -include::../../api_modules/datetime/ATS/ATS_rc-datetime-definition.adoc[] +include::datetime/ATS_rc-datetime-definition.adoc[] -include::../../api_modules/datetime/ATS/ATS_rc-datetime-response.adoc[] +include::datetime/ATS_rc-datetime-response.adoc[] ==== Limit Tests -include::../../api_modules/limit/ATS/ATS_rc-op-limit.adoc[] +include::limit/ATS_rc-op-limit.adoc[] -include::../../api_modules/limit/ATS/ATS_rc-limit-definition.adoc[] - -include::../../api_modules/limit/ATS/ATS_rc-limit-response.adoc[] - -include::../../api_modules/limit/ATS/ATS_rc-paged-response.adoc[] +include::limit/ATS_rc-limit-definition.adoc[] +include::limit/ATS_rc-limit-response.adoc[] +include::limit/ATS_rc-paged-response.adoc[] diff --git a/api_modules/bbox/ATS/ATS_rc-bbox-definition.adoc b/collections/abstract_tests/bbox/ATS_rc-bbox-definition.adoc similarity index 100% rename from api_modules/bbox/ATS/ATS_rc-bbox-definition.adoc rename to collections/abstract_tests/bbox/ATS_rc-bbox-definition.adoc diff --git a/api_modules/bbox/ATS/ATS_rc-bbox-response.adoc b/collections/abstract_tests/bbox/ATS_rc-bbox-response.adoc similarity index 100% rename from api_modules/bbox/ATS/ATS_rc-bbox-response.adoc rename to collections/abstract_tests/bbox/ATS_rc-bbox-response.adoc diff --git a/api_modules/bbox/ATS/ATS_rc-op-bbox.adoc b/collections/abstract_tests/bbox/ATS_rc-op-bbox.adoc similarity index 100% rename from api_modules/bbox/ATS/ATS_rc-op-bbox.adoc rename to collections/abstract_tests/bbox/ATS_rc-op-bbox.adoc diff --git a/api_modules/collection/ATS/ATS_rc-md-collection-content.adoc b/collections/abstract_tests/collections/ATS_rc-md-collection-content.adoc similarity index 100% rename from api_modules/collection/ATS/ATS_rc-md-collection-content.adoc rename to collections/abstract_tests/collections/ATS_rc-md-collection-content.adoc diff --git a/api_modules/collection/ATS/ATS_rc-md-items-links.adoc b/collections/abstract_tests/collections/ATS_rc-md-items-links.adoc similarity index 100% rename from api_modules/collection/ATS/ATS_rc-md-items-links.adoc rename to collections/abstract_tests/collections/ATS_rc-md-items-links.adoc diff --git a/api_modules/datetime/ATS/ATS_rc-datetime-definition.adoc b/collections/abstract_tests/datetime/ATS_rc-datetime-definition.adoc similarity index 100% rename from api_modules/datetime/ATS/ATS_rc-datetime-definition.adoc rename to collections/abstract_tests/datetime/ATS_rc-datetime-definition.adoc diff --git a/api_modules/datetime/ATS/ATS_rc-datetime-response.adoc b/collections/abstract_tests/datetime/ATS_rc-datetime-response.adoc similarity index 100% rename from api_modules/datetime/ATS/ATS_rc-datetime-response.adoc rename to collections/abstract_tests/datetime/ATS_rc-datetime-response.adoc diff --git a/api_modules/datetime/ATS/ATS_rc-op-datetime.adoc b/collections/abstract_tests/datetime/ATS_rc-op-datetime.adoc similarity index 100% rename from api_modules/datetime/ATS/ATS_rc-op-datetime.adoc rename to collections/abstract_tests/datetime/ATS_rc-op-datetime.adoc diff --git a/api_modules/extent/ATS/ATS_rc-md-extent.adoc b/collections/abstract_tests/extent/ATS_rc-md-extent.adoc similarity index 100% rename from api_modules/extent/ATS/ATS_rc-md-extent.adoc rename to collections/abstract_tests/extent/ATS_rc-md-extent.adoc diff --git a/api_modules/limit/ATS/ATS_rc-limit-definition.adoc b/collections/abstract_tests/limit/ATS_rc-limit-definition.adoc similarity index 100% rename from api_modules/limit/ATS/ATS_rc-limit-definition.adoc rename to collections/abstract_tests/limit/ATS_rc-limit-definition.adoc diff --git a/api_modules/limit/ATS/ATS_rc-limit-response.adoc b/collections/abstract_tests/limit/ATS_rc-limit-response.adoc similarity index 100% rename from api_modules/limit/ATS/ATS_rc-limit-response.adoc rename to collections/abstract_tests/limit/ATS_rc-limit-response.adoc diff --git a/api_modules/limit/ATS/ATS_rc-op-limit.adoc b/collections/abstract_tests/limit/ATS_rc-op-limit.adoc similarity index 100% rename from api_modules/limit/ATS/ATS_rc-op-limit.adoc rename to collections/abstract_tests/limit/ATS_rc-op-limit.adoc diff --git a/api_modules/limit/ATS/ATS_rc-paged-response.adoc b/collections/abstract_tests/limit/ATS_rc-paged-response.adoc similarity index 100% rename from api_modules/limit/ATS/ATS_rc-paged-response.adoc rename to collections/abstract_tests/limit/ATS_rc-paged-response.adoc diff --git a/collections/clause_8_collections.adoc b/collections/clause_8_collections.adoc index e93ee1f..3fe48aa 100644 --- a/collections/clause_8_collections.adoc +++ b/collections/clause_8_collections.adoc @@ -12,14 +12,14 @@ include::recommendations/collections/REC_dependency-landing-page.adoc[] This Requirements Class describes the resources and operations used to describe and access resource collections exposed through an OGC Web API. This class does not include any requirements about how resources are aggregated into collections nor about the aggregated resources themselves. That detail is reserved for resource-specific OGC Web API standards (see <>). -The two resources and their operations are defined in this Requirements Class. They are summarized in <>. +The two resources and their operations are defined in this Requirements Class. They are summarized in <>. [#collection-resources,reftext='{table-caption} {counter:table-num}'] .Collection Resources [width="90%",cols="10,10,5,20",options="header"] |=== ^|Resource ^|URI ^|HTTP Method ^|Description -|<> |/collections ^|GET |Information which describes the set of available Collections +|<> |/collections ^|GET |Information which describes the set of available Collections |<> |/collections/{collectionId} ^|GET |Information about a specific collection of geospatial data with links to distribution |=== @@ -36,11 +36,13 @@ include::requirements/collections/REQ_rc-md-op.adoc[] include::requirements/collections/REQ_rc-md-success.adoc[] -The collections response returned by this operation is based on the link:http://beta.schemas.opengis.net/ogcapi/common/part2/0.1/collections/openapi/schemas/collections.yaml[collections.yaml] JSON schema. Examples of collections responses are provided in <>. +The collections response returned by this operation is based on the link:https://github.com/opengeospatial/ogcapi-common/tree/master/collections/openapi/schemas/common-geodata/collections.yaml[collections.yaml] JSON schema. Examples of collections responses are provided in <>. + +#TODO: Update to schemas.opengis.net for publication# .collections.yaml [source, YAML] -include::openapi/schemas/collections.yaml[] +include::openapi/schemas/common-geodata/collections.yaml[] This Collections schema is further constrained by the following requirements and recommendations. @@ -56,7 +58,7 @@ The `timeStamp` property of the Collections response indicates when the response include::requirements/collections/REQ_rc-timeStamp.adoc[] -The `collections` property of the Collections response provides a description of each individual collection hosted by the API. +The `collections` property of the Collections response provides a description of each individual collection hosted by the API. include::requirements/collections/REQ_rc-md-items.adoc[] @@ -90,5 +92,50 @@ If the parameter `collectionId` does not exist on the server, the status code of [[collection-resource-definition-section]] ==== Collection Resource Definition -include::../api_modules/collection/requirements_module_collection.adoc[] +include::requirements/collections/REQ_collection-definition.adoc[] + + +.Collection Resource Schema +[source, YAML] +include::openapi/schemas/common-geodata/collectionDesc.yaml[] + +Most of the properties of the Collection resource are self-explanatory. However, a few properties require additional explanation. + +[[collection-attribution-section]] +===== Attribution + +The attribution element is a special type of string property. Specifically, the attribution element can contain markup text. Markup allows a text string to import images and format text. The capabilities are only limited by the markup language used. See the example <> for an example of the use of markup in the attribution element. + +[[collection-item-type-section]] +===== Item Type + +In some Geospatial collections, the members (`items`) that make up that collection can be individually accessed by a client. In this case, the `itemType` property in the Collection resource identifies the type of the `items` accessible from that collection. + +include::recommendations/collections/REC_rc-md-item-type.adoc[] + +[collection-links-section]] +===== Links + +To support hypermedia navigation, the `links` property must be populated with sufficient hyperlinks to navigate through the whole dataset. + +include::requirements/collections/REQ_rc-md-items-links.adoc[] + +Additional information may be available to assist in understanding and using this dataset. Links to those resources should be provided as well. + +include::recommendations/collections/REC_rc-md-items-descriptions.adoc[] + +[[collection-extent-section]] +===== Extent + +The extent property defines a spatial-temporal envelope that encompasses the geospatial data in the collection. Since not all collections are nicely clustered around a single place in space and time, the extent property provides flexibility in how that surface can be defined. + +* Spatial Bounding Box (Bbox) provides a set of rectangular bounding boxes which use geographic coordinates to envelope portions of the collection. Typically only the first element would be populated. Additional boxes may be useful, for example, when the collection is clustered in multiple, widely-separated locations. +* Temporal Interval provides a set of temporal periods. Typically only the first temporal period would be populated. However, like Bbox, additional periods can be added if the collection does not form a single temporal cluster. + +include::requirements/extent/REQ_rc-md-extent.adoc[] + +include::recommendations/extent/REC_rc-md-extent.adoc[] + +include::recommendations/extent/REC_rc-md-extent-single.adoc[] +include::recommendations/extent/PER_rc-md-extent-extensions.adoc[] diff --git a/collections/clause_9_simple_query.adoc b/collections/clause_9_simple_query.adoc index 734715d..aa32013 100644 --- a/collections/clause_9_simple_query.adoc +++ b/collections/clause_9_simple_query.adoc @@ -1,5 +1,5 @@ [[rc-simple-query-section]] -== Requirements Class "Simple Query" +== Requirements Class "Searchable Collections" :sectnums: include::requirements/requirements_class_simple_query.adoc[] @@ -26,26 +26,125 @@ Use of these query parameters with any specific operation is optional. Developer [[bbox-parameter-requirements]] ==== Parameter bbox -include::../api_modules/bbox/requirements_module_bbox.adoc[] +The `bbox` parameter is used to select resources based on the geospatial footprint or extent. + +The `bbox` parameter is defined as follows: + +include::./requirements/bbox/REQ_rc-bbox-definition.adoc[] + +While the processing of the `bbox` parameter is specific to the resource and operation for which it is applied, there is a general set of requirements which all implementations must address. + +include::./requirements/bbox/REQ_rc-bbox-response.adoc[] + +"Intersects" means that a coordinate that is part of the spatial geometry of the resource falls within the area specified in the parameter `bbox`. This includes the boundaries of the geometries. For curves the boundary includes the start and end position. For surfaces the boundary includes the outer and inner rings. + +In case of a degenerate bounding box, the resulting geometry is used. For example, if the lower left corner is the same as the upper right corner, all resources match where the geometry intersects with this point. + +This standard does not specify requirements for the parameter `bbox-crs`. Those requirements will be specified in a later version of this standard. + +The bounding box for WGS 84 longitude/latitude is, in most cases, the sequence of minimum longitude, minimum latitude, maximum longitude and maximum latitude. However, in cases where the box spans the anti-meridian (180th meridian) the first value (west-most box edge) is larger than the third value (east-most box edge). + +.The bounding box of the New Zealand Exclusive Economic Zone +================= +The bounding box of the New Zealand Exclusive Economic Zone in WGS84 (from 160.6°E to 170°W and from 55.95°S to 25.89°S) would be represented in JSON as `[ 160.6, -55.95, -170, -25.89 ]` and in a query as `bbox=160.6,-55.95,-170,-25.89`. +================= + +Note that the server will return an error if a latitude value of ``160.0`` is used. + +If the vertical axis is included, the third and the sixth number are the bottom and the top of the 3-dimensional bounding box. + +A template for the definition of the parameter in YAML according to OpenAPI 3.0 is available at link:http://beta.schemas.opengis.net/ogcapi/common/part2/0.1/collections/openapi/parameters/bbox.yaml[bbox.yaml]. [[datetime-parameter-requirements]] ==== Parameter datetime -include::../api_modules/datetime/requirements_module_datetime.adoc[] +The `datetime` parameter selects resources based on their temporal extent. The definition of temporal extent is specific to the resource type being filtered. + +The `datetime` parameter is defined as follows: + +include::./requirements/datetime/REQ_rc-datetime-definition.adoc[] + +While the processing of the `datetime` parameter is specific to the resource and operation for which it is applied, there is a general set of requirements which all implementations must address. + +include::./requirements/datetime/REQ_rc-datetime-response.adoc[] + +"Intersects" means that the time (instant or period) specified in the parameter `datetime` includes a timestamp that is part of the temporal geometry of the resource (again, a time instant or period). For time periods this includes the start and end time. + +[width="90%",cols="2,6a"] +|==== +| Note | ISO 8601-2 distinguishes open start/end timestamps (double-dot) and unknown start/end timestamps (empty string). For queries, an unknown start/end has the same effect as an open start/end. +|==== + +.A date-time +================= +February 12, 2018, 23:20:52 GMT: + +`datetime=2018-02-12T23%3A20%3A52Z` +================= + +For resources with a temporal property that is a timestamp (such as `lastUpdate`), a date-time value would match all resources where the temporal property is identical. + +For resources with a temporal property that is a date or a time interval, a date-time value would match all resources where the timestamp is on that day or within the time interval. + +.Intervals +================= +February 12, 2018, 00:00:00 GMT to March 18, 2018, 12:31:12 GMT: + +`datetime=2018-02-12T00%3A00%3A00Z%2F2018-03-18T12%3A31%3A12Z` + +February 12, 2018, 00:00:00 UTC or later: + +`datetime=2018-02-12T00%3A00%3A00Z%2F..` + +March 18, 2018, 12:31:12 UTC or earlier: + +`datetime=..%2F2018-03-18T12%3A31%3A12Z` +================= + +A template for the definition of the parameter in YAML according to OpenAPI 3.0 is available at link:http://beta.schemas.opengis.net/ogcapi/common/part2/0.1/collections/openapi/parameters/datetime.yaml[datetime.yaml]. + [[limit-parameter-requirements]] ==== Parameter limit -include::../api_modules/limit/requirements_module_limit.adoc[] +The `limit` parameter limits the number of resources that can be returned in a single response. + +include::./requirements/limit/REQ_rc-limit-definition.adoc[] + +While the processing of the `limit` parameter is specific to the resource and operation for which it is applied, there is a general set of requirements which all implementations must address. + +include::./requirements/limit/REQ_rc-limit-response.adoc[] + +The number of resources returned depends on the server and the value of the `limit` parameter. + +* The client can request a limit to the number of resources returned. +* The server may have a default value for the limit, and a maximum limit. +* If the server has any more results available than it returns (the number it returns is less than or equal to the requested/default/maximum limit) then the server will include a link to the next set of results. + +include::./recommendations/limit/PER_rc-server-limit.adoc[] + +Since many servers will place a limit on the size of their responses, clients should be prepared to handle a paged response even if they have not specified a `limit` parameter in their query. + +The effect of the limit parameter is to divide the response into a number of pages. Each page (except for the last) contains the specified number of entities. The response contains the first page. Additional pages can be accessed through hyperlink navigation. + +include::./recommendations/limit/REC_rc-next-1.adoc[] + +include::./recommendations/limit/REC_rc-next-2.adoc[] + +include::./recommendations/limit/REC_rc-next-3.adoc[] + +Providing `prev` links supports navigating back and forth between pages, but depending on the implementation approach it may be too complex to implement. + +include::./recommendations/limit/PER_rc-prev.adoc[] [[target-resource-requirements]] === Target Resource Requirements The target of the parameters defined in this conformance class is the <> resource described in the <> Requirements Class. The purpose of these parameters is to select a subset of <> resources to be included in the response to a <> request. -Three parameters are defined for use with the <> resource. These parameters subset the set of <> entries returned based on spatial, temporal, and volumetric filters. These parameters are documented in the <> section. +Three parameters are defined for use with the <> resource. These parameters subset the set of <> entries returned based on spatial, temporal, and volumetric filters. These parameters are documented in the <> section. -The `collections` property of the Collections response provides a description of each individual collection hosted by the API. These descriptions are based on the link:http://beta.schemas.opengis.net/ogcapi/common/part2/0.1/collections/openapi/schemas/collectionDesc.yaml[Resource Collection Schema]. This schema is described in detail in the <> section of this Standard. +The `collections` property of the Collections response provides a description of each individual collection hosted by the API. These descriptions are based on the link:http://beta.schemas.opengis.net/ogcapi/common/part2/0.1/collections/openapi/schemas/collectionDesc.yaml[Resource Collection Schema]. This schema is described in detail in the <> section of this Standard. ==== Spatial and Temporal Filtering @@ -63,7 +162,7 @@ The client may limit the number of collections returned in a response by using t include::requirements/simple_query/REQ_rc-limit-collection-response.adoc[] -The server also has the option of limiting the size of the Collections response. +The server also has the option of limiting the size of the Collections response. include::recommendations/simple_query/PER_rc-md-items.adoc[] @@ -77,7 +176,7 @@ The `numberMatched` property of the Collections response indicates the number of include::requirements/simple_query/REQ_rc-numberMatched.adoc[] -The number of collection items included in a Collections response may be a subset of the number matched. In that case, the `numberReturned` property of the Collections response indicates the number of collection items returned in this "page" of the Collections response. +The number of collection items included in a Collections response may be a subset of the number matched. In that case, the `numberReturned` property of the Collections response indicates the number of collection items returned in this "page" of the Collections response. include::requirements/simple_query/REQ_rc-numberReturned.adoc[] diff --git a/collections/clause_9_umd-collection.adoc b/collections/clause_9_umd-collection.adoc deleted file mode 100644 index 9d7b2fb..0000000 --- a/collections/clause_9_umd-collection.adoc +++ /dev/null @@ -1,25 +0,0 @@ -[[rc-umd-collection-section]] -== Requirements Class "Uniform Multi-Dimension Collection" -:sectnums: - -include::requirements/requirements_class_umd-collection.adoc[] - -include::requirements/umd_collection/REQ_dependency-collections.adoc[] - -include::recommendations/umd_collection/REC_dependency-collections.adoc[] - -The <> Requirements Class defines a <> resource which supports both <> and <> geometries. However, some resources cannot be fully described with just these two geometries. The <> Requirements Class extends the <> resource to support geometries with an unlimited number of uniform, domain-specific axis. - -[[umd-collection-definition]] -=== Uniform Multi-Dimension Collection Definition - -The Uniform Multi-Dimension Collection is an extension of the <> resource. So all of the requirements defined in <> Requirements Class are required. - -Support for domain-specific Collections is supplied by the `Extent with Uniform Additional Dimensions` requirements module. - -include::../api_modules/extent-uad/requirements_module_extent-uad.adoc[] - -[[umd-selection-parameter]] -=== Multi-Dimension Collection Selection - -Selection and access of a Uniform Multi-Dimension Collection is similar to that of a <> resource. All of the requirements defined in the <> Requirements Class also apply to this Requirements Class. So all of the requirements defined in <> Requirements Class are required. diff --git a/api_modules/extent-uad/requirements_module_extent-uad.adoc b/collections/clause_X_umd-collection.adoc similarity index 61% rename from api_modules/extent-uad/requirements_module_extent-uad.adoc rename to collections/clause_X_umd-collection.adoc index 318ed3c..cbd69f4 100644 --- a/api_modules/extent-uad/requirements_module_extent-uad.adoc +++ b/collections/clause_X_umd-collection.adoc @@ -1,17 +1,28 @@ -[[rm_extent-uniform-additional-dimensions]] -[cols="1,4",width="90%"] -|=== -2+|*Requirements Module* -2+|http://www.opengis.net/spec/ogcapi-common-2/1.0/rm/extent-uad -|Target type |Web API Resource -|Dependencies |<> Requirements Module -|=== +[[rc-umd-collection-section]] +== Requirements Class "Uniform Multi-Dimension Collection" +:sectnums: -The `Extent with Uniform Additional Dimensions` (Extent-uad) resource extends the <> element to support domain-specific geometries. +include::requirements/requirements_class_umd-collection.adoc[] + +include::requirements/umd_collection/REQ_dependency-collections.adoc[] + +include::recommendations/umd_collection/REC_dependency-collections.adoc[] + +The <> Requirements Class defines a <> resource which supports both <> and <> geometries. However, some resources cannot be fully described with just these two geometries. The <> Requirements Class extends the <> resource to support geometries with an unlimited number of uniform, domain-specific axis. + +[[umd-collection-definition]] +=== Uniform Multi-Dimension Collection Definition + +The Uniform Multi-Dimension Collection is an extension of the <> resource. So all of the requirements defined in <> Requirements Class are required. + +Support for domain-specific Collections is supplied by the `Extent with Uniform Additional Dimensions` requirements module. + + +The `Extent with Uniform Additional Dimensions` (Extent-uad) resource extends the <> element to support domain-specific geometries. The `Extent-uad` resource is defined as follows: -include::requirements/REQ_extent-uad-definition.adoc[] +include::requirements/extent-uad/REQ_extent-uad-definition.adoc[] `Extent-uad` allows definition of additional axis through the use of the Coordinate Reference System (`crs`, `trs` or `vrs`) property and one of more Intervals properties. @@ -74,3 +85,7 @@ allOf: description: vertical coordinate reference system (e.g. as defined in EDR for 'vertical') ---- +[[umd-selection-parameter]] +=== Multi-Dimension Collection Selection + +Selection and access of a Uniform Multi-Dimension Collection is similar to that of a <> resource. All of the requirements defined in the <> Requirements Class also apply to this Requirements Class. So all of the requirements defined in <> Requirements Class are required. diff --git a/collections/openapi/openapi.json b/collections/openapi/ogcapi-common-2.bundled.json similarity index 100% rename from collections/openapi/openapi.json rename to collections/openapi/ogcapi-common-2.bundled.json diff --git a/collections/openapi/parameters/bbox.yaml b/collections/openapi/parameters/common-geodata/bbox.yaml similarity index 100% rename from collections/openapi/parameters/bbox.yaml rename to collections/openapi/parameters/common-geodata/bbox.yaml diff --git a/collections/openapi/parameters/datetime.yaml b/collections/openapi/parameters/common-geodata/datetime.yaml similarity index 100% rename from collections/openapi/parameters/datetime.yaml rename to collections/openapi/parameters/common-geodata/datetime.yaml diff --git a/collections/openapi/responses/exception.json b/collections/openapi/responses/common-core/exception.json similarity index 100% rename from collections/openapi/responses/exception.json rename to collections/openapi/responses/common-core/exception.json diff --git a/collections/openapi/responses/exception.yaml b/collections/openapi/responses/common-core/exception.yaml similarity index 100% rename from collections/openapi/responses/exception.yaml rename to collections/openapi/responses/common-core/exception.yaml diff --git a/collections/openapi/schemas/exception.json b/collections/openapi/schemas/common-core/exception.json similarity index 100% rename from collections/openapi/schemas/exception.json rename to collections/openapi/schemas/common-core/exception.json diff --git a/collections/openapi/schemas/exception.yaml b/collections/openapi/schemas/common-core/exception.yaml similarity index 100% rename from collections/openapi/schemas/exception.yaml rename to collections/openapi/schemas/common-core/exception.yaml diff --git a/collections/openapi/schemas/link.json b/collections/openapi/schemas/common-core/link.json similarity index 100% rename from collections/openapi/schemas/link.json rename to collections/openapi/schemas/common-core/link.json diff --git a/collections/openapi/schemas/link.yaml b/collections/openapi/schemas/common-core/link.yaml similarity index 100% rename from collections/openapi/schemas/link.yaml rename to collections/openapi/schemas/common-core/link.yaml diff --git a/api_modules/collection/schemas/collectionDesc.json b/collections/openapi/schemas/common-geodata/collectionDesc.json similarity index 100% rename from api_modules/collection/schemas/collectionDesc.json rename to collections/openapi/schemas/common-geodata/collectionDesc.json diff --git a/api_modules/collection/schemas/collectionDesc.yaml b/collections/openapi/schemas/common-geodata/collectionDesc.yaml similarity index 100% rename from api_modules/collection/schemas/collectionDesc.yaml rename to collections/openapi/schemas/common-geodata/collectionDesc.yaml diff --git a/collections/openapi/schemas/collections.json b/collections/openapi/schemas/common-geodata/collections.json similarity index 100% rename from collections/openapi/schemas/collections.json rename to collections/openapi/schemas/common-geodata/collections.json diff --git a/collections/openapi/schemas/collections.yaml b/collections/openapi/schemas/common-geodata/collections.yaml similarity index 100% rename from collections/openapi/schemas/collections.yaml rename to collections/openapi/schemas/common-geodata/collections.yaml diff --git a/api_modules/extent-uad/schemas/extent-uad.json b/collections/openapi/schemas/common-geodata/extent-uad.json similarity index 100% rename from api_modules/extent-uad/schemas/extent-uad.json rename to collections/openapi/schemas/common-geodata/extent-uad.json diff --git a/api_modules/extent-uad/schemas/extent-uad.yaml b/collections/openapi/schemas/common-geodata/extent-uad.yaml similarity index 100% rename from api_modules/extent-uad/schemas/extent-uad.yaml rename to collections/openapi/schemas/common-geodata/extent-uad.yaml diff --git a/api_modules/extent/schemas/extent.json b/collections/openapi/schemas/common-geodata/extent.json similarity index 100% rename from api_modules/extent/schemas/extent.json rename to collections/openapi/schemas/common-geodata/extent.json diff --git a/api_modules/extent/schemas/extent.yaml b/collections/openapi/schemas/common-geodata/extent.yaml similarity index 100% rename from api_modules/extent/schemas/extent.yaml rename to collections/openapi/schemas/common-geodata/extent.yaml diff --git a/collections/openapi/schemas/numberMatched.json b/collections/openapi/schemas/common-geodata/numberMatched.json similarity index 100% rename from collections/openapi/schemas/numberMatched.json rename to collections/openapi/schemas/common-geodata/numberMatched.json diff --git a/collections/openapi/schemas/numberMatched.yaml b/collections/openapi/schemas/common-geodata/numberMatched.yaml similarity index 100% rename from collections/openapi/schemas/numberMatched.yaml rename to collections/openapi/schemas/common-geodata/numberMatched.yaml diff --git a/collections/openapi/schemas/numberReturned.json b/collections/openapi/schemas/common-geodata/numberReturned.json similarity index 100% rename from collections/openapi/schemas/numberReturned.json rename to collections/openapi/schemas/common-geodata/numberReturned.json diff --git a/collections/openapi/schemas/numberReturned.yaml b/collections/openapi/schemas/common-geodata/numberReturned.yaml similarity index 100% rename from collections/openapi/schemas/numberReturned.yaml rename to collections/openapi/schemas/common-geodata/numberReturned.yaml diff --git a/api_modules/collection/recommendations/REC_rc-md-item-type.adoc b/collections/recommendations/collections/REC_rc-md-item-type.adoc similarity index 100% rename from api_modules/collection/recommendations/REC_rc-md-item-type.adoc rename to collections/recommendations/collections/REC_rc-md-item-type.adoc diff --git a/api_modules/collection/recommendations/REC_rc-md-items-descriptions.adoc b/collections/recommendations/collections/REC_rc-md-items-descriptions.adoc similarity index 100% rename from api_modules/collection/recommendations/REC_rc-md-items-descriptions.adoc rename to collections/recommendations/collections/REC_rc-md-items-descriptions.adoc diff --git a/api_modules/extent/recommendations/PER_rc-md-extent-extensions.adoc b/collections/recommendations/extent/PER_rc-md-extent-extensions.adoc similarity index 100% rename from api_modules/extent/recommendations/PER_rc-md-extent-extensions.adoc rename to collections/recommendations/extent/PER_rc-md-extent-extensions.adoc diff --git a/api_modules/extent/recommendations/REC_rc-md-extent-single.adoc b/collections/recommendations/extent/REC_rc-md-extent-single.adoc similarity index 100% rename from api_modules/extent/recommendations/REC_rc-md-extent-single.adoc rename to collections/recommendations/extent/REC_rc-md-extent-single.adoc diff --git a/api_modules/extent/recommendations/REC_rc-md-extent.adoc b/collections/recommendations/extent/REC_rc-md-extent.adoc similarity index 100% rename from api_modules/extent/recommendations/REC_rc-md-extent.adoc rename to collections/recommendations/extent/REC_rc-md-extent.adoc diff --git a/api_modules/limit/recommendations/PER_rc-prev.adoc b/collections/recommendations/limit/PER_rc-prev.adoc similarity index 100% rename from api_modules/limit/recommendations/PER_rc-prev.adoc rename to collections/recommendations/limit/PER_rc-prev.adoc diff --git a/api_modules/limit/recommendations/PER_rc-server-limit.adoc b/collections/recommendations/limit/PER_rc-server-limit.adoc similarity index 100% rename from api_modules/limit/recommendations/PER_rc-server-limit.adoc rename to collections/recommendations/limit/PER_rc-server-limit.adoc diff --git a/api_modules/limit/recommendations/REC_rc-next-1.adoc b/collections/recommendations/limit/REC_rc-next-1.adoc similarity index 100% rename from api_modules/limit/recommendations/REC_rc-next-1.adoc rename to collections/recommendations/limit/REC_rc-next-1.adoc diff --git a/api_modules/limit/recommendations/REC_rc-next-2.adoc b/collections/recommendations/limit/REC_rc-next-2.adoc similarity index 100% rename from api_modules/limit/recommendations/REC_rc-next-2.adoc rename to collections/recommendations/limit/REC_rc-next-2.adoc diff --git a/api_modules/limit/recommendations/REC_rc-next-3.adoc b/collections/recommendations/limit/REC_rc-next-3.adoc similarity index 100% rename from api_modules/limit/recommendations/REC_rc-next-3.adoc rename to collections/recommendations/limit/REC_rc-next-3.adoc diff --git a/api_modules/limit/recommendations/REC_rc-server-limit.adoc b/collections/recommendations/limit/REC_rc-server-limit.adoc similarity index 100% rename from api_modules/limit/recommendations/REC_rc-server-limit.adoc rename to collections/recommendations/limit/REC_rc-server-limit.adoc diff --git a/api_modules/bbox/requirements/REQ_rc-bbox-definition.adoc b/collections/requirements/bbox/REQ_rc-bbox-definition.adoc similarity index 100% rename from api_modules/bbox/requirements/REQ_rc-bbox-definition.adoc rename to collections/requirements/bbox/REQ_rc-bbox-definition.adoc diff --git a/api_modules/bbox/requirements/REQ_rc-bbox-response.adoc b/collections/requirements/bbox/REQ_rc-bbox-response.adoc similarity index 100% rename from api_modules/bbox/requirements/REQ_rc-bbox-response.adoc rename to collections/requirements/bbox/REQ_rc-bbox-response.adoc diff --git a/api_modules/collection/requirements/REQ_collection-definition.adoc b/collections/requirements/collections/REQ_collection-definition.adoc similarity index 100% rename from api_modules/collection/requirements/REQ_collection-definition.adoc rename to collections/requirements/collections/REQ_collection-definition.adoc diff --git a/api_modules/collection/requirements/REQ_rc-md-items-links.adoc b/collections/requirements/collections/REQ_rc-md-items-links.adoc similarity index 100% rename from api_modules/collection/requirements/REQ_rc-md-items-links.adoc rename to collections/requirements/collections/REQ_rc-md-items-links.adoc diff --git a/collections/requirements/collections/requirements_module_collection.adoc b/collections/requirements/collections/requirements_module_collection.adoc deleted file mode 100644 index 4e6d0d2..0000000 --- a/collections/requirements/collections/requirements_module_collection.adoc +++ /dev/null @@ -1,16 +0,0 @@ -[[rm_collection]] -[cols="1,4",width="90%"] -|=== -2+|*Requirements Module* -2+|http://www.opengis.net/spec/ogcapi-common-2/1.0/rm/collection -|Target type |Web API -|Description |The Collection resource provides clients with a basic understanding of a single collection. It also serves as a starting point for further navigation through the collection. -|Requirements |<> + -<> + -<> -|Recommendations and Permissions|<> + -<> + -<> + -<> + -<> -|=== diff --git a/api_modules/datetime/requirements/REQ_rc-datetime-definition.adoc b/collections/requirements/datetime/REQ_rc-datetime-definition.adoc similarity index 100% rename from api_modules/datetime/requirements/REQ_rc-datetime-definition.adoc rename to collections/requirements/datetime/REQ_rc-datetime-definition.adoc diff --git a/api_modules/datetime/requirements/REQ_rc-datetime-response.adoc b/collections/requirements/datetime/REQ_rc-datetime-response.adoc similarity index 100% rename from api_modules/datetime/requirements/REQ_rc-datetime-response.adoc rename to collections/requirements/datetime/REQ_rc-datetime-response.adoc diff --git a/api_modules/extent-uad/requirements/REQ_extent-uad-definition.adoc b/collections/requirements/extent-uad/REQ_extent-uad-definition.adoc similarity index 98% rename from api_modules/extent-uad/requirements/REQ_extent-uad-definition.adoc rename to collections/requirements/extent-uad/REQ_extent-uad-definition.adoc index 918afb8..78d5d91 100644 --- a/api_modules/extent-uad/requirements/REQ_extent-uad-definition.adoc +++ b/collections/requirements/extent-uad/REQ_extent-uad-definition.adoc @@ -1,6 +1,6 @@ [[req_extent-uad-definition]] [width="90%",cols="2,6a"] |=== -^|*Requirement {counter:req-id}* |*/req/common/extent-uad-definition* +^|*Requirement {counter:req-id}* |*/req/common/extent-uad-definition* ^|A |The content of an `Extent with Uniform Additional Dimensions` (Extent-uad) resource SHALL be based upon the OpenAPI segment link:https://github.com/opengeospatial/ogcapi-common/tree/master/api_modules/extent-uad/schemas/extent-uad.json[extent-uad.oas]. |=== diff --git a/api_modules/extent/requirements/REQ_rc-md-extent-multi.adoc b/collections/requirements/extent/REQ_rc-md-extent-multi.adoc similarity index 100% rename from api_modules/extent/requirements/REQ_rc-md-extent-multi.adoc rename to collections/requirements/extent/REQ_rc-md-extent-multi.adoc diff --git a/api_modules/extent/requirements/REQ_rc-md-extent.adoc b/collections/requirements/extent/REQ_rc-md-extent.adoc similarity index 100% rename from api_modules/extent/requirements/REQ_rc-md-extent.adoc rename to collections/requirements/extent/REQ_rc-md-extent.adoc diff --git a/api_modules/limit/requirements/REQ_rc-limit-definition.adoc b/collections/requirements/limit/REQ_rc-limit-definition.adoc similarity index 100% rename from api_modules/limit/requirements/REQ_rc-limit-definition.adoc rename to collections/requirements/limit/REQ_rc-limit-definition.adoc diff --git a/api_modules/limit/requirements/REQ_rc-limit-response.adoc b/collections/requirements/limit/REQ_rc-limit-response.adoc similarity index 100% rename from api_modules/limit/requirements/REQ_rc-limit-response.adoc rename to collections/requirements/limit/REQ_rc-limit-response.adoc