Publication Date: 2021-11-29

Approval Date: 2021-11-18

Submission Date: 2021-06-23

Reference number of this document: OGC 21-042

Reference URL for this document: http://www.opengis.net/doc/PER/202105APISprintER

Category: OGC Public Engineering Report

Editor: Gobe Hobona

Title: May 2021 OGC API Code Sprint Summary Engineering Report

OGC Public Engineering Report

COPYRIGHT

Copyright © 2021 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/

WARNING

This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Public Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.

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.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Table of Contents

1. Subject

The subject of this Engineering Report (ER) is a code sprint that was held from 26 to 28 May 2021 to advance the development of the OGC API - Maps draft standard, OGC API - Tiles draft standard, and the OGC API – Styles draft standard. An Application Programming Interface (API) is a standard set of documented and supported functions and procedures that expose the capabilities or data of an operating system, application or service to other applications (adapted from ISO/IEC TR 13066-2:2016). The code sprint was hosted online. The code sprint was sponsored by Ordnance Survey (OS) and Natural Resources Canada (NRCan).

2. Executive Summary

This Engineering Report (ER) summarizes the main achievements of the May 2021 OGC API Virtual Code Sprint, conducted between May 26 – 28, 2021. The goal of the code sprint was to progress the development of the draft OGC API standards for Maps, Tiles and Styles. The sprint also sought to help to identify issues and options for addressing those issues.

The objectives of the code sprint were to:

  • Develop prototype implementations of OGC API – Maps

  • Develop prototype implementations of OGC API – Tiles

  • Develop prototype implementations of OGC API – Styles

  • Test the prototype implementations

  • Provide feedback to the Editor about what worked and what did not work

  • Provide feedback about the specification document, especially what is missing from the document

Part of the motivation for holding the sprint was:

  • APIs have proven to be a popular and a very effective enabler of rapid software development

  • There is an increasing need for optimizing geospatial interoperability between Web APIs

  • There is phenomenal adoption of location-handling capabilities in software within and outside of geospatial developer communities

The draft OGC API – Maps specification describes an API that presents data as maps by applying a style. The draft specification enables a client application to request maps as images. This includes the ability to specify or change parameters such as the size of an image and coordinate reference systems at the time of request.

The draft OGC API – Tiles specification describes an API building block that can enable other OGC API implementations to serve maps or tiled feature data divided into individual tiles. The draft specification includes concepts such as tile matrix sets and tile schemes. The draft standard can be used to publish map tiles and tiled feature data (e.g. GeoJSON Vector Tiles and Mapbox Vector Tiles).

The draft OGC API – Styles specification defines a Web API that enables map servers, clients as well as visual style editors, to manage and fetch styles that consist of symbolizing instructions that can be applied by a rendering engine on features and/or coverages.

The code sprint facilitated the development and testing of prototype implementations of the OGC API - Maps draft standard, OGC API - Tiles draft standard, and the OGC API – Styles draft standard. The code sprint therefore successfully met all of its objectives and achieved its goal of progressing the development of the draft OGC API standards for Maps, Tiles and Styles.

2.1. Summary of Outcomes

The outcomes and findings of the sprint can be summarized as follows:

  • The Tiles API was found to be reasonably stable. However, there appears to be different interpretations of how to apply styles to maps collections and maps of datasets.

  • Evolution of the Well Known Scale Set (WKSS) concept into common Tile Matrix Set (TMS) concepts was another outcome. The sprint participants suggested that information provided by WKSS could be derived from a TMS. Further consultation with other OGC Working Groups will be needed to determine the future role of WKSS in the 2D TMS Standard.

  • Another key outcome is that interoperability of buildings blocks has been completely demonstrated. The three APIs have been successfully demonstrated together.

  • The sprint has shown that a lot that is common can be shared across the APIs i.e. how much OGC API - Common - Part 2 facilitates the client implementation.

  • The interaction between OGC APIs for Maps, Tiles, and Styles worked well. No major issues came up that could not be verified and/or resolved.

  • More work needs to be done on the Styles API in general e.g. to determine the impact on API resources when styles are used.

  • The code sprint focused on the API aspects of the styles but not on the formats of the styles. More work is needed on the format aspects of the styles (e.g. in relation to the Symbology Core standard).

  • While in the Tiles API a metadata model has been developed, in the Maps API there has been less interest in developing a specific metadata model.

The sprint participants considered what the APIs will do to help meet the needs of the National Mapping Agency (NMA) community. The following is a summary:

  • Providing the public with access to geospatial data and maps: The OGC APIs will make it easier for the general public to access maps through regular web browser technologies. For example, through OGC API - Maps it is now possible to access a complete map through a basic URL (i.e. no query parameters). OGC API - Tiles will make it easier to publish maps as tiled feature data (colloquially named 'vector tiles'), which are becoming increasingly popular in the NMA community. The APIs are able to provide data in a way that 2.5D and 3D visualization clients are able to handle.

  • Facilitating analytics: OGC API - Tiles is able to publish tiled coverage data in such a way that makes it easier to 'stream' coverages for analysis at the screen resolution. This makes it possible to create histograms, vegetation indices, and other analytical reports all at the screen resolution. The flexibility of specifying the origin of the tiles will make it easier to combine regular OGC tiles with other tiles.

  • Reducing barriers to accessing geospatial data: OGC APIs together make it easier to start with a dataset and then find a way to generate tiles and other resources. The OGC APIs are integrated in a very convenient way. The Styles API makes it possible for NMA’s to publish styles from a central location in a way that is consistent with how they publish data. The integrated environment makes it easier to manage things together.

2.2. Plan outlining how the sprint’s outcomes will be incorporated into future OGC activities

The following is a plan outlining how the sprint’s outcomes will be presented to the OGC Standards Program and Innovation Program for potential consideration for future activities.

2.2.1. Potential activities for the Innovation Program

For the OGC Innovation Program, the sprint participants identified a need to:

  • experiment with multidimensional data support in OGC APIs.

  • explore how to turn legends into real data (objects) that can be combined by the client (e.g. asking a client to provide the elements that are in a legend).

  • research how simple a structure needs to be to meet the needs for a legend while also being easily implementable.

  • experiment with coverage tiles, as they are becoming increasingly important (e.g. in support of rendering a Digital Surface Model (DSM)). Strategies for identifying suitable sizes of the tiles need to tested/researched.

  • experiment with non-grid coverages (e.g. point clouds).

  • explore the possibility of an 'info' capability that supports different data sources and query options (not just retrieval of the value at a point).

OGC Innovation Program activities rely on sponsorship to resource initiatives. Therefore, the potential activities listed above will be presented to the OGC Technical Committee through the Architecture Domain Working Group in order to raise interest from potential sponsors.

2.2.2. Potential activities for the Standards Program

For the OGC Standards Program, the sprint participants identified a need to:

The OGC API - Maps and OGC API - Tiles Standards Working Groups will be tasked with specifying requirements for the legend and info conformance classes. Once the requirements have been specified, there may be a need to conduct further experimentation focusing on implementations of the legend and info conformance classes.

2.3. Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:

Contacts

Name Organization Role

Gobe Hobona

Open Geospatial Consortium

Editor

Adrian Alvarez

APCO

Contributor

Pelle Arvinder

Carmenta AB

Contributor

Nelio Matos

Connected Places Catapult

Contributor

Gaj Bala

CRTC

Contributor

Panagiotis (Peter) Vretanos

CubeWerx Inc.

Contributor

Keith Pomakis

CubeWerx Inc.

Contributor

Tino Kastbjerg Stigsen

Danish Defense

Contributor

Yasser Othman

EAD

Contributor

Joana Simoes

EarthPulse

Contributor

Antonio Cerciello

EarthPulse

Contributor

Diego Caraffini

Ecere Corporation

Contributor

Patrick Dion

Ecere Corporation

Contributor

Jerome St-Louis

Ecere Corporation

Contributor

James Munroe

Elemental Earth Data Ltd.

Contributor

Hisham Massih

Esri

Contributor

Anne Fitz

Esri

Contributor

Richie Carmichael

Esri

Contributor

Adewale Shittu

Federal University of Technology Akure 

Contributor

Serge Lévesque

Fisheries and Oceans Canada

Contributor

Rowan Winsemius

FrontierSI

Contributor

Jeff McKenna

GatewayGeo

Contributor

Francesco Bartoli

Geobeyond Srl

Contributor

Paul van Genuchten

GeoCat BV

Contributor

Gérald Fenoy

GeoLabs

Contributor

Andrea Aime

GeoSolutions

Contributor

Oscar Díaz

GeoSolutions

Contributor

Susie Mielby

Geus

Contributor

Nazih Fino

Global Nomad GIS Services

Contributor

Sara Gholamian

Gozar_e No

Contributor

Charles Heazel

Heazeltech

Contributor

Clemens Portele

interactive instruments GmbH

Contributor

Muhammed Mete

İstanbul Technical University

Contributor

Berke Şentürk

ITU

Contributor

Zack Zhang

JLL

Contributor

Lorena Hernández

European Commission - Joint Research Centre

Contributor

Bryan Evans

Kinder Institute at Rice University

Contributor

Chris Gagnon

Kongsberg Geospatial

Contributor

Eric Tse

Lexco Limited

Contributor

Philippe Pinheiro

Luxembourg Institute of Science and Technology

Contributor

Rajveer Shekhawat

Manipal University Jaipur

Contributor

Tom Kralidis

Meteorological Service of Canada

Contributor

Gonzalo Nogueras

MetOffice

Contributor

Ali Chettih

Montefiore IT

Contributor

Cameron Wilson

Natural Resources Canada

Contributor

Ryan Ahola

Natural Resources Canada

Contributor

Ahmed Ragab

Natural Resources Canada

Contributor

Azadeh Ashoori

Natural Resources Canada

Contributor

Pradeep Alva

National University of Singapore

Contributor

Bruno Kinoshita

NIWA

Contributor

Scott Simmons

Open Geospatial Consortium

Contributor

Scott Serich

Open Geospatial Consortium

Contributor

Angelos Tzotsos

Open Source Geospatial Foundation

Contributor

Michael Gordon

Ordnance Survey

Contributor

Chris Holmes

Planet

Contributor

Tim Schaub

Planet

Contributor

Basile Goussard

Promethee

Contributor

Tarron Newman

Red Helmet Technology

Contributor

Senthil Rajrndran

RMSI Pvt Ltd 

Contributor

Yohann Hazan

SDIS33

Contributor

Darrel Ronald

Spatiomatics

Contributor

Davince Koyo

Synergetic systems

Contributor

Núria Julià Selvas

Universitat Autònoma de Barcelona (CREAF)

Contributor

Joan Maso

Universitat Autònoma de Barcelona (CREAF)

Contributor

Ingrid Santana

UFMG

Contributor

Matthew Walker

UK Defence Science and Technology Laboratory

Contributor

Paul Walsh

UK Defence Science and Technology Laboratory

Contributor

Nick Bennett

UK Defence Science and Technology Laboratory

Contributor

Jonathan Lewis

UK Hydrographic Office

Contributor

Pablo Zader

UNC

Contributor

Andres Herrera

Univalle

Contributor

Joseph Olusina

University of Lagos

Contributor

Amy Youmans

US Army Geospatial Center

Contributor

Jeff Harrison

US Army Geospatial Center

Contributor

Huajun Zhang

US Census

Contributor

Ujjwal Yadav

Uttar Pradesh Remote Sensing Application Center 

Contributor

2.4. Foreword

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

3. References

The following normative documents are referenced in this document.

4. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.

● API

An Application Programming Interface (API) is a standard set of documented and supported functions and procedures that expose the capabilities or data of an operating system, application, or service to other applications (adapted from ISO/IEC TR 13066-2:2016).

● coordinate reference system

A coordinate system that is related to the real world by a datum term name (source: ISO 19111)

● OpenAPI Document

A document (or set of documents) that defines or describes an API. An OpenAPI definition uses and conforms to the OpenAPI Specification (https://www.openapis.org)

● Web API

API using an architectural style that is founded on the technologies of the Web [source: OGC API - Features - Part 1: Core]

4.1. Abbreviated terms

  • API Application Programming Interface

  • CRS Coordinate Reference System

  • OGC Open Geospatial Consortium

  • SLD Styled Layer Descriptor

  • WMS Web Map Service

  • WMTS Web Map Tile Service

5. Introduction

This Engineering Report (ER) summarizes the main achievements of the May 2021 OGC API Virtual Code Sprint, conducted between May 26 – 28, 2021. The sprint had been organized to advance the development of the draft OGC API - Maps, OGC API - Tiles and OGC API - Styles standards. Sprint participants prototyped implementations of the draft standards, validating the requirements and providing feedback so that the draft standards could be improved.

An OGC Code Sprint is a collaborative and inclusive event driven by innovative and rapid programming with minimal process and organization constraints to support the development of new applications and open standards. OGC Code Sprints experiment with emerging ideas in the context of geospatial standards, help improve interoperability of existing standards by experimenting with new extensions or profiles, and are used as a proof of concept for other OGC Innovation Program initiatives, or support OGC Standards Program activities.

The code sprint was sponsored by Ordnance Survey (OS) and Natural Resources Canada (NRCan).

5.1. User Needs and Use Cases

To help the sprint participants prioritize their efforts, the sprint organizers invited NRCan to outline User Needs from NRCan’s perspective as a National Mapping Agency (NMA). This section summarizes the user needs.

5.1.1. Introduction to Natural Resources Canada

NRCan is a part of the Federal Government of Canada. NRCan is mandated to ensure the sustainable development of Canada’s natural resources, allowing the department’s work to explore energy, minerals and metals, forests, earth sciences, mapping, and remote sensing. Geospatial data plays a key role in all of the aforementioned areas, hence NRCan’s interest in the development of OGC APIs. As the NMA of Canada, NRCan plays a critical nation-wide role in the distribution of authoritative geospatial data products, including cartographic products such as maps.

5.1.2. The Priorities that drive the Need for APIs

There are specific priorities that drive what NRCan would like to see from OGC APIs. These include for example: climate change, response to disasters/extreme events, the Arctic, trade, sovereignty, and Indigenous reconciliation. The government has a strong desire to have collaboration and innovation within government processes in order to benefit Canadian society broadly. Innovation provides a bridge between the government’s internal focus areas and how these will apply within Canada and its position in the world. So, indeed, all the OGC APIs that are being developed through this sprint will, in the future, help to benefit society.

5.1.3. Specific Needs

OGC APIs have a substantial role to play in the future of NMAs. At NRCan, this role is likely to involve the development and provision of microservices in order to support the delivery of geospatial data, maps and analytics. This role can be described in terms of the following needs:

  • Providing the public with access to geospatial data and maps: This is a key function of an NMA. OGC APIs have the potential to help NMAs to provide open data in a way that conforms to FAIR principles (Findable, Accessible, Interoperable, and Reusable). This enables the members of the public to make use of the geospatial data and maps as they see fit (e.g. in support of other parts of the community or economy).

  • Facilitating analytics: Making geospatial a fundamental part of national decision making requires consideration of how to optimize the use of location information. By focusing firstly on analytics, geospatial experts can be enabled to help others, then those experts can make better decisions through geospatial information analytics.

  • Reducing barriers to accessing geospatial data: Geospatial data has become more accessible over the past decade. However, there has also been a significant increase in the demand for knowledge and expertise in all sorts of development to use geospatial information. Significant need also exists to extend geospatial information accessibility to individuals with disabilities to ensure everyone can benefit from geospatial data.

5.1.4. Sprint Areas of Interest

For demonstration purposes, Sprint participants were encouraged to publish specific data and maps through OGC APIs for the following Areas of Interest (AOI):

Europe: The area around Bournemouth, England, within the extent specified by this GeoJSON file or this WKT string in EPSG:4326 coordinates POLYGON -2.13384466616954 50.5343261657655,-2.14712951953212 50.822458640394,-1.77636133932212 50.8243659606517,-1.75884948716236 50.539699354356,-2.13384466616954 50.5343261657655.

North America: Red River of the North, within the extent specified by this GeoJSON file or this WKT string in EPSG:4326 coordinates POLYGON -97.8656275465241 50.1994331527875,-97.8290574091464 48.9215621457706,-96.475962326173 48.9305725567791,-96.4851048605174 50.2082107872824,-97.8656275465241 50.1994331527875.

The datasets that were recommended for the code sprint included:

Ordnance Survey datasets for the Sprint’s Europe AOI
NRCan datasets for the Sprint’s North America AOI

5.2. Participants

Software developers and solutions architects from the following organizations registered to participate in the code sprint:

  • APCO

  • Carmenta AB

  • Connected places catapult

  • CRTC

  • CubeWerx Inc.

  • Danish Defense

  • EAD

  • EarthPulse

  • Ecere Corporation

  • Elemental Earth Data Ltd.

  • Esri

  • Federal University of Technology Akure

  • Fisheries and Oceans Canada

  • FrontierSI

  • GatewayGeo

  • Geobeyond Srl

  • GeoCat BV

  • GeoLabs

  • GeoSolutions

  • Geus

  • Global Nomad GIS Services

  • Heazeltech

  • interactive instruments GmbH

  • İstanbul Technical University

  • ITU

  • JLL

  • European Commission - Joint Research Centre

  • Kinder Institute at Rice University

  • Kongsberg Geospatial

  • Lexco Limited

  • Luxembourg Institute of Science and Technology

  • Manipal University Jaipur

  • Meteorological Service of Canada

  • Met Office

  • Montefiore IT

  • Natural Resources Canada

  • NIWA

  • National University of Singapore

  • Open Source Geospatial Foundation

  • Ordnance Survey

  • Planet

  • Promethee

  • Red Helmet Technology

  • RMSI Pvt Ltd

  • SDIS33

  • Spatiomatics

  • Synergetic systems

  • UAB-CREAF

  • UFMG

  • UK Defence Science and Technology Laboratory

  • UK Hydrographic Office

  • Unc

  • Univalle

  • University of Lagos

  • US Army Geospatial Center

  • US Census

  • uttar pradesh remote sensing application center

6. Architecture

6.1. High Level Overview

The focus of the sprint was on support of the development of the draft OGC API - Maps, OGC API - Tiles and OGC API - Styles standards. Implementations of these draft standards were deployed in participants' own infrastructure in order to build a solution with the architecture shown below in Figure 1.

architecture
Figure 1. High level overview of the architecture implemented during the sprint

As illustrated, the sprint architecture was designed with the view of enabling client applications to connect to different servers that implement OGC APIs. The servers were provisioned with maps, tiled feature data (colloquially named 'vector tiles'), map tiles, tiled coverage data, and styles.

6.2. Candidate Standards

6.2.1. OGC API - Maps

The draft OGC API - Maps standard describes an API that presents maps portraying data that has been rendered according to a style. The maps served by implementations of the draft OGC API - Maps standard are retrieved as images of any size, generated on-the-fly, and with the styling determined by the client application. The draft standard can be considered the successor to the widely implemented WMS standard. The draft OGC API – Maps standard is a multipart standard that includes a Core (Part 1) and extensions that are planned to be developed in the future.

6.2.2. OGC API - Tiles

The draft OGC API - Tiles standard describes an API that implements the OGC Two Dimensional Tile Matrix Set (TMS) standard to enable access to tiled resources on the Web. The TMS standard defines the rules and requirements for a tile matrix set as a way to index space based on a set of regular grids defining a domain (tile matrix) for a limited list of scales in a CRS. The draft OGC API – Tiles standard is a multipart standard that includes a Core (Part 1) and extensions that are planned to be developed in the future.

6.2.3. OGC API - Styles

OGC API - Styles describes the interface and exchange of styling parameters and instructions. The construction of symbology components of styles is addressed in the OGC Symbology Conceptual Model: Core Part standard and multiple OGC and other style encoding standards.

7. Results

Multiple organizations provided servers, API implementations, and capabilities during the event. The rest of this section describes each of the implementations.

7.1. Implementations

7.1.1. CubeWerx Inc.

The CubeWerx server ("cubeserv") supports a wide variety of back ends including Oracle, MariaDB, SHAPE files, etc. It also supports a wide array of service-dependent output formats (e.g. GML, GeoJSON, Mapbox Vector Tiles, MapMP, etc.) and coordinate reference systems. At the time of publishing this engineering report, the CubeSERV OGC API - Features Server product is certified OGC compliant to the OGC API - Features - Part 1: Core standard. A screenshot of the landing page of a CubeSERV instance from a demonstration of the product during the code sprint is shown in Figure 2.

cubeserv1
Figure 2. Screenshot from a demonstration of CubeSERV

Another screenshot of the CubeSERV instance, showing an HTML view of the API definition, is shown in Figure 3.