Published

OGC Engineering Report

•
OGC Testbed-17: Attracting Developers: Lowering the entry barrier for implementing OGC Web APIs
Aleksandar Balaban Editor
Submission Date: 2021-11-19 Approval Date: 2021-12-17 Publication Date: 2022-01-21 External identifier of this OGC® document: http://www.opengis.net/doc/PER/t17-D040 Internal identifier of this OGC® document: 21-019
OGC Engineering Report

Published

Notice

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

Document number:21-019
Document type:OGC Engineering Report
Document subtype:
Document stage:Published
Document language:English

Copyright notice

Copyright © 2022 Open Geospatial Consortium
To obtain additional rights of use, visit http://www.ogc.org/legal/

Note

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.


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.



I.  Abstract

This OGC Testbed 17 Engineering Report (ER) documents the work completed in the “Attracting Developers: Lowering the entry hurdle for OGC Web API experiments” task.

OGC Web API Standards are being developed to make it easy to provide geospatial data over the web. These standards provide a certain level of formality to ensure high levels of interoperability. They rigorously define requirements and rules to reduce room for error during interpretation. This rigor sometimes makes the standard documents difficult to read and hence implement. Rather than direct examination of a standard, the majority of developers often prefer to start with implementation guidelines, sample code, and best practice documentation and then refer to the standards document for guidance and clarity.

The Testbed-17 (TB-17) API task served as a foundation for further development and exploration and delivers knowledge necessary for agile development, deployment, and executing OGC Standards-based applications following a “How-To” philosophy with hands-on experiments, examples, and instructions.

II.  Executive Summary

The Testbed-17 API work began with design and conduction of an online Clause 4 and then focused on the results derived from the answers given by the participants: The developers were mostly from the OGC community. The outcome of this survey is that a typical profile of a geospatial developer is generally comparable with the results of similar surveys, such as StackOverflow Developer Survey 2021, which have been done having considered much larger groups of developers with broader interests. The conclusion is that a typical developer from the OGC/geospatial community is an experienced person focused on stable, well-established technologies. Therefore, this ER focuses on newer technologies and approaches to fill the gap between “stable maturity” and “contemporary/emerging trends”.

The value of this ER to interoperability is the exploration of different options for OGC APIs in the context of contemporary development and deployment practices. For interoperability, cloud native services are often based on open source and standards based technology. This helps reduce vendor lock-in and results in increased portability. The ER establishes the repository of How To-examples (GitHub) enabling faster and more efficient geospatial data provision and consumption based on OGC APIs and modern/emerging technology stacks. The API experiments further advance location-based technologies by investigating the compatibility to OGC API Standards with, and the applicability to, technologies such as source code generation and cloud to OGC API Standards. The final result is more efficient development processes, which make building new tools cheaper, more efficient, and less stressful, as well as a broader developer audience attracted to OGC APIs.

The requirements addressed by the work documented in this ER were:

  1. Provide easy to understand documentation as a starting point for Web developers to explore OGC APIs standards.

  2. Establish and demonstrate a culture of continuous learning and experimentation in the OGC APIs context utilizing DevOps practices.

  3. Provide instructions/guidelines to get started with OGC APIs within cloud environments.

  4. Expose data sets from cloud storages for consumption using selected technology stacks and compatible OGC APIs.

  5. Explore the compatibility of client/server code generation approach in conjunction with OGC APIs.

An overview of recommendations on how to further proceed with the achievements documented in this ER is given in sections Clause 9 and Clause 10.

III.  Keywords

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

ogcdoc, OGC document, API


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

V.  Security considerations

No security considerations have been made for this document.

VI.  Submitting Organizations

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

VII.  Submitters

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

Name Organization Role
Aleksandar Balaban m-click.aero GmbH Editor
Arne Vogt 52°North GmbH Contributor
Ignacio Correas Skymantics Europe SL Contributor
Sam Lavender Pixalytics Ltd Contributor
Karri Ojala Solenix GmbH Contributor
Alexander Lais Solenix GmbH Contributor

OGC Testbed-17: Attracting Developers: Lowering the entry barrier for implementing OGC Web APIs

1.  Scope

The scope of this OGC Testbed 17 ER covers the following topics:

2.  Terms, definitions and abbreviated terms

This document uses the terms defined in OGC Policy Directive 49, 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 document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

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

2.1.  Terms and definitions

2.1.1. Application Programming Interface

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

2.1.2. CI/CD

Continuous Integration, Continuous Delivery is a method to frequently deliver apps to customers by introducing automation into the stages of app development. (source: RedHat)

2.1.3. DevOps

a set of practices that combines software development (Dev) and IT operations (Ops).

2.1.4. Cloud

a network of computing resources, such as storage, servers, applications and services, that can be used on-demand anywhere and anytime via the Internet NIST.

2.1.5. Cloud-native

The concept of building and running applications to take advantage of the distributed computing offered by the cloud delivery model. Cloud native apps are designed and built to exploit the scale, elasticity, resiliency, and flexibility the cloud provides, Oracle.

2.1.6. Code Generation

Source code generation is the process of creating programming code from a model such as one of OGC APIs data schemas.

2.1.7. Containerization

the packaging of software code with just the operating system (OS) libraries and dependencies required to run the code to create a single lightweight executable—called a container—that runs consistently on any infrastructure, IBM.

2.1.8. CRUD

In computer programming, create, read (aka retrieve), update, and delete are the four basic functions of persistent storage.

2.1.9. OGC APIs

Family of OGC standards developed to make it easy for anyone to provide geospatial data to the web.

2.1.10. Technology Stack

A technology stack or tech stack refers to a set of technologies, software, and tools that are used in the development of applications.

2.2.  Abbreviated terms

API

Application Programming Interface

CI/CD

Continuous Integration / Continuous Delivery

CNCF

Cloud Native Computing Foundation

COTS

Commercial Off The Shelf

DevOps

Software development (Dev) and IT operations (Ops)

EDR

Environmental Data Retrieval

IDL

Interface Definition Language

JSON

JavaScript Object Notation

OGC

Open Geospatial Consortium

OWS

OGC Web Services

STAC

Spatio temporal Asset Catalog

3.  Introduction

This OGC Testbed 17 ER documents the experiments performed with OGC API Standards for lowering the entry barrier for developers implementing OGC API Standards. The ER describes all developed services and components, the results of Technology Integration Experiments (TIE), provides an executive summary, and describes recommended future work.

4.  Developer Survey

A pivotal activity within the TB-17 API experiments task was to design and conduct an online survey. The target survey universe was developers from the geospatial community. The survey objective was to collect information about their profile and behaviors, as well as their needs and their satisfaction with current and emerging OGC API Standards. The survey received responses from 125 participants. Answers from the survey helped the testbed participants understand the current situation, design the API experiments, recommend improvements for OGC APIs documentation, and provide useful tutorials with code examples for the community.

The answers were evaluated graphically and are available in Annex A. The following sections provide a detailed summary of survey’s findings:

4.1.  Who are our developers?

More than 80% of the respondents reside in Europe and the United States of America; and many of the respondents were experienced developers.

Figure 1

  • Almost 75% of developers are older than 35!

  • More than 70% of the respondents have Masters degrees or/and doctorates.

  • Almost 80% are full-time employed, 20% work for public agencies, 30% for small businesses.

  • 53% of the respondents currently reside in Europe and almost 29% in North America

  • 60% of them stated that they spend 21 hours or more per week on tasks related to geospatial technologies (Q19).

  • 71% of the respondents have been coding for more than 8 years.

4.2.  Technology Stack

As expected, Python and JavaScript are the most popular programming languages.

Figure 2

  • Regarding programming languages preferences (Q11), developers are most familiar with Python (about 80%) followed by JavaScript (58%). Many of them are also fluent in more traditional C/C++ programming languages (about 38%). Java is still well presented in their technology stacks.

  • Developers are very familiar with the mainstream open-source geospatial projects. The most popular is the QGIS framework (for 90.40% of survey participants) followed by PostGIS 82.40%, GeoServer 65.60%, and MapServer 48.80%. This also reflects the fact that features and maps are the most significant and prominent geospatial data formats.

Figure 3

4.3.  Learning Habits

  • The preferable way to learn a technology seems to be to “follow a documented how-to/tutorial” (30%) and “to read a tutorial” (20%).

  • When learning about a new topic from the internet, “full written descriptions” are the most preferable sources.

  • Portal Stack Overflow (Q29) seems to be the most important tool for getting support from the community (80%).

4.4.  Familiarity with OGC (API) Standards

  • About 20% of the respondents have contributed to the development of OGC API Standards on GitHub. Still, these standards are not yet widely used in the community because, although 75% of respondents have either used an OGC Standard or read one of the documentations (Q24), a high percentage (30%) answered that they don’t have any experience involving OGC API Standards (Q25).

    Figure 4

  • Features, Maps and Tiles are the most important geospatial standards and therefore the corresponding OGC APIs are of equal importance (Q27).

  • Some of the respondents believe OGC API Standards are not easy to learn. On the question of whether OGC API Standards are easy to learn (Q30) almost 30% answered that “Mastering the first API is hard, but then it becomes easier to learn” while 40% thinks that “Some are very easy and others are extremely difficult to learn”.

  • About 57% believes that there is a lack of best-practice guides that help differentiate the dos and don’ts”, as well as 38% that technical documentation is hard to read or understand (Q32)!

4.5.  Summary

The survey results suggest that a typical developer from the OGC/geospatial domain is an experienced, well-educated individual focused on stable, well-established technologies. Traditional and new technologies are equally used. For example they follow the recent trends regarding scripting programming languages as they are predominant today.

Considering the results, the API experiments focused on developing examples and how-to documentation as well as newer technologies and approaches to fill the gap between “stable maturity” and “contemporary/emerging trends”.

Annex A lists the questions used to conduct developers survey.

5.  API Experiments Scenarios Overview

The following figure illustrates the work items and deliverables of this task.

Figure 5 — Deliverables and Packages

5.1.  Participants

To test all components and guidance material, the work in this task was shared by participants acting as:

  1. Client developers

  2. Server developers

  3. Data providers

Client developers: Organization O1 implemented and delivered a client-side software library in Python for both OGC API Features and OGC API Environmental Data Retrieval (EDR). Organization O2 delivered a similar library in JavaScript and TypeScript. Both organizations demonstrated their library in a client application.

Server developers: Organization O3 implemented and delivered a server-side software library in Python for both OGC API — Features and OGC API — EDR. The library supported access and exploration of both OGC API — Feature and OGC API — EDR resources and supported data hosted on cloud object storage, cloud databases, and OGC Web Feature Service (WFS) instances (with constraint functionality). O3 provided a deployable instance together with deployment and execution documentation that allows third parties to test the deliverable(s) as a microservice in different cloud environments. Organization O4 delivered a similar library in JavaScript (alternatively TypeScript).

Data providers: Organization O5 deployed a microservice based on deliverables provided by O3 and O4 in at least two different cloud environments (to the extent possible, as some data backends are cloud specific, others work across cloud environments or are fully cloud independent). In addition, O5 provided data in a database, cloud object storage, and as a Web Feature Service instance to test data access (reuse of existing WFS and/or Web Coverage Service (WCS) instances, even outside of the target cloud environment, is admitted). All of the data sources were available to all organizations in this task and are freely accessible (i.e. object storage and WFS/WCS endpoints are fully accessible, together with cloud native databases as much as possible). Organization O6 performed similarly to O5.

Participants:

  • Data providers:

    • Skymantics: D167 Data Backend and Deployment 1

    • Pixalytics: D168 Data Backend and Deployment 2

  • Services (server developers):

    • 52N: D165 API Experiments Server (Python)

    • GMU: D166 API Experiments Server (JavaScript)

  • Client developers:

    • Skymantics: D175 API Experiments Client (Python)

    • Solenix: D176 API Experiments Client (TypeScript)

5.2.  API experiment scenarios

The figure below illustrates a generic Testbed-17 OGC APIs experiment component diagram with interactions. A client with a dedicated OGC API software library (1) interacts with a data service that implements one of the OGC APIs (2) at the front-end and includes a cloud native data storage software library (3) at the backend that interacts with cloud native storage, such as cloud databases, cloud object storage, or existing OGC Web Service instances such as WFS.