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
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.
- 1. Subject
- 2. Executive Summary
- 3. References
- 4. Terms and definitions
- 5. Introduction
- 6. Architecture
- 7. Results
- 8. Discussion
- 8.1. OGC API support for different approaches to organizing styles, layers and data sources
- 8.2. Support for legends
- 8.3. Changes to a style with multiple occurrences in an API
- 8.4. Multiple dimensions in OGC API - Maps
- 8.5. Styles, Tiles: Metadata review
- 8.6. Suggested styleId when creating a style
- 8.7. Summary of Code Sprint Outcomes
- 9. Conclusions
- Appendix A: Prototype Legend Support
- Appendix B: Revision History
- Appendix C: Bibliography
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:
-
specify a legend conformance class for the OGC API - Maps and OGC API - Tiles draft specifications.
-
specify an 'info' conformance class for the OGC API - Maps and OGC API - Tiles draft specifications.
-
implement an OGC API - Maps conformance class/extension to support time dependent maps (in a way similar to the OGC Best Practice for using Web Map Services (WMS) with Time-Dependent or Elevation-Dependent Data (1.0)) e.g. the
subset
anddatetime
parameters.
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.
-
OGC: OGC 06-042, OpenGIS Web Map Service (WMS) Implementation Specification 1.3.0 (2006)
-
OGC: OGC 05-078r4, Styled Layer Descriptor, Version 1.1 (2007)
-
OGC: OGC 19-072, draft OGC API - Common - Part 1: Core candidate standard, http://docs.ogc.org/DRAFTS/19-072.html
-
OGC: OGC 20-058, draft OGC API - Maps - Part 1: Core candidate standard, http://docs.ogc.org/DRAFTS/20-058.html
-
OGC: OGC 20-057, draft OGC API - Tiles - Part 1: Core candidate standard, http://docs.ogc.org/DRAFTS/20-057.html
-
OGC: OGC 20-009, draft OGC API - Styles - Part 1: Core candidate standard, http://docs.ogc.org/DRAFTS/20-009.html
-
IETF: RFC-7946 The GeoJSON Format (2016)
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]
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
-
OS Open Zoomstack data product: A comprehensive basemap of the United Kingdom showing coverage from national level right down to street detail.
-
OS Open Zoomstack stylesheets: These are OS Open Zoomstack stylesheets encoded in OGC SLD, Esri LYR, QGIS QML and Mapbox GL Styles formats.
NRCan datasets for the Sprint’s North America AOI
-
High Resolution Digital Elevation Model (HRDEM): Complete coverage of the Canadian territory in a Digital Terrain Model (DTM), a Digital Surface Model (DSM) and other derived data.
-
Canada Base Map Transportation (CBMT): Base map with a focus on transportation networks. Available as a tiled web map service.
-
National Hydrographic Network (NHN): Data about Canada’s inland surface waters.
-
RADARSAT-1: An operational radar satellite system, equipped with a Synthetic Aperture Radar (SAR) instrument, capable of acquiring images of the Earth day or night, in all weather and through cloud cover, smoke and haze.
-
Open Maps: Approximately 4600 open geospatial datasets for Canada.
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.
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.
Another screenshot of the CubeSERV instance, showing an HTML view of the API definition, is shown in Figure 3.