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:
-
Provide easy to understand documentation as a starting point for Web developers to explore OGC APIs standards.
-
Establish and demonstrate a culture of continuous learning and experimentation in the OGC APIs context utilizing DevOps practices.
-
Provide instructions/guidelines to get started with OGC APIs within cloud environments.
-
Expose data sets from cloud storages for consumption using selected technology stacks and compatible OGC APIs.
-
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):
- m-click.aero GmbH
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:
-
Clause 3 introduces the problem that appears when starting with OGC APIs development. The overview describes the current situation and discusses the requirements set by the testbed Sponsors.
-
Clause 4 presents the results of developer survey.
-
Clause 5 illustrates the scenarios and experiments of this task.
-
Clause 6 describes the task architecture and the services/components.
-
Clause 8 explains the concept of code generation for OGC API.
-
Clause 9 summarizes the results of this API experiments.
-
Clause 10 provides conclusions and gives recommendations for future Work.
-
Clause 11 covers the Technology Integration Experiments between the DCS Server and DCS Client.
-
Annex A lists the questions used in the developer survey.
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:
-
Client developers
-
Server developers
-
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.