[Requests] Comments on OGC API - Common (19-072)

Reini Jari (MML) jari.reini at nls.fi
Fri Mar 27 14:43:32 EDT 2020


PART A

1. Evaluator:
Jari Reini, Pekka Latvala, Teemu Sipilä
National Land Survey of Finland

2. Submission: [OpenGIS Project Document Number, Name]
OGC 19-072 OGC API - Common

PART B

1. Requirement: [General, #]
18/19D

2. Implementation Specification Section number: [General, #]
9.4.1

3. Criticality: [Major, Minor, Editorial, etc.]
Major

4. Comments/justifications for changes: [Comments]
A simple array of numeric values is a poor choice for a bounding box. Any time you have an array of numbers with non-obvious semantics, you run the risk of them being misinterpreted. We cannot assume that a developer will be looking at the standard to know the order. The worst case scenario is that a bounding box is accompanied by a bbox-crs like http://www.opengis.net/def/crs/EPSG/0/4326 which specifies a LAT/LONG coordinate order.

There is no reason to repeat the mistakes made in WMS and GeoJSON. Be explicit! I don't care how you do it (min x min y max x max y optional min/max z or lowerLeft and upperRight elements with x, y, and optional z elements inside them) but make it so that no one can possibly mess them up.

In WCS2, SUBSET has been defined explicitly, where axis-order works with multiple axes (x, y, elevation, time etc.) doesn't count order, e.g SUBSET=E(496000,496200)&SUBSET=N(7181000,7181200)

PART B

1. Requirement: [General, #]
19C2/D2

2. Implementation Specification Section number: [General, #]
9.4.1

3. Criticality: [Major, Minor, Editorial, etc.]
Editorial

4. Comments/justifications for changes: [Comments]
The numbering of the sub-requirements is wrong. Items C/D repeat.

Examples in 7.2 maybe not correct:
* Geometries that have to be represented in a coordinate reference system that is not based on WGS 84 longitude/latitude (e.g. an authoritative national reference system) -> support coming in CRS extension.
 * Features that have more than one geometric property -> other geometries can be embedded to JSON.

Chapter 8.2
Is it clear whether landing page ends with / or not:
The standard paths defined in this Standard for Foundation Resources are: 1. "/" - the landing page
2. "/api" - the API Definition document for this API

It looks like this is not intention as clarified in HTTP, but seems to make some confusion in some implementations where landing page url  has ended with  ".../" and app builds from the  url with "...//api"

9.4.2 parameter datetime
URL's could be without URL-encoding in order to understand without external URL-decoder..

PART B

1. Requirement: [General, #]
General

2. Implementation Specification Section number: [General, #]
Chapter 1. Introduction, section: i. Abstract
Chapter 3
Chapter 9.

3. Criticality: [Major, Minor, Editorial, etc.]
Major

4. Comments/justifications for changes: [Comments]
Chapter 1, introduction, states that /collections path is supported by all OGC APIs.
Is this requirement actually necessary for all OGC APIs?

In contrast, Chapter 3 states that the Collections requirements class is mandatory for all OGC APIs which expose spatial resources.

The current draft version of the TJS 2.0 specification does not define the
/collections path but defines:
/spatialdatasets path for obtaining metadata and key values on spatial datasets and
/joins path for accessing metadata and outputs on the created joins.

We suggest that the /collections path is stated to be optional in the OGC API-Common.

PART B

1. Requirement: [General, #]

2. Implementation Specification Section number: [General, #]

8.5.1

3. Criticality: [Major, Minor, Editorial, etc.]

Major

4. Comments/justifications for changes: [Comments]

8.5.1 requires that "The API SHALL conform to HTTP 1.1.". What is standard's relation to HTTP/2? Even if HTTP/2 has negotiation mechanism (whether to use HTTP 1.1, 2.0, or potentially other non-HTTP protocols) and it maintains high-level compatibility with HTTP 1.1, there is also new possibilities not possible in HTTP 1.1 like pipelining of requests or multiplexing multiple requests over a single TCP connection (https://en.wikipedia.org/wiki/HTTP/2) that might be useful in future OGC APIs too. Currently HTTP/1.1 is still very common for resource-oriented approaches, but it could be possible that in future some servers would implement only (or at least prefer) HTTP/2 or some successor version (like HTTP/3). So maybe relation between HTTP/1.1, HTTP/2 and future versions of HTTP should be clarified in the context of OGC API Commons?

Extent-property on collection metadata with schema referenced (https://raw.githubusercontent.com/opengeospatial/oapi_common/master/standard/openapi/schemas/extent.yaml) on the standard states that only CRS:80 is supported on the core. That's fine, but if some future standard extension would like to publish spatial extents in multiple coordinate reference systems, does schema allow that? Also the commons standard has an example (appendix B.4) like "spatial": [ 7.01, 50.63, 7.22, 50.78 ] but OGC API Features Part 2 has an example like "bbox": [ [ 7.01, 50.63, 7.22, 50.78 ] ] - are these examples compatible?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20200327/682293cb/attachment.html>


More information about the Requests mailing list