Open Geospatial Consortium
Submission Date: 2017-11-27
Approval Date: 2020-05-01
Publication Date: 2020-05-12
External identifier of this OGC® document: http://www.opengis.net/doc/per/FGDC-api-assessment
Internal reference number of this OGC® document: 17-061
Category: OGC® Engineering Report
Editor: Terry Idol

FGDC OGC Application Programming Interface Interoperability
Assessment

Copyright notice
Copyright © 2020 Open Geospatial Consortium
To obtain additional rights of use, visit http://www.opengeospatial.org/legal/.
Warning
This document is not an OGC Standard. This document presents a discussion of technology issues considered in an
initiative of the OGC Innovation Program. This document does not represent an official position of the OGC. It is
subject to change without notice and may not be referred to as an OGC Standard. However, the discussions in thisdocument could very well lead to the definition of an OGC Standard.

Document type:
Document subtype:
Document stage:
Document language:

OGC® Engineering Report
Approved for Public Release
English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 theIntellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on theintellectual 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, INCLUDINGBUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ANDNONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOTWARRANT 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 COPYRIGHTHOLDER 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 WHATSOEVERRESULTING 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, nosuch termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as ofthe 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 orinvalid, 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 andeffect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

3/53

i.

Abstract
The Federal Geographic Data Committee (FGDC) Application Programming Interface (API)assessment was conducted under the OGC Innovation Program with the goal to develop an
in-depth understanding of all the components necessary to enable increased coordination andeffectiveness of APIs as applied to geospatial information. FGDC customers have been
invited to share their experiences with the use of APIs. From those descriptions,recommendations have been derived that help FGDC to better understand how APIs are
currently being generated and if using a more standardized approach to APIs might enable amore robust and optimized service offering.

ii.

Keywords
ogcdoc, ogc documents, APIs, OGC Essentials, Web services, user experience, usability

4/53

1.

Introduction

1.1 Scope
Application Programming Interfaces (APIs) have been used for years in complex softwaresystems. Currently, APIs remain popular as organizations can publish their API for use byother organizations to access systems, data and applications. Per the ProgammableWeb
website, there are over 17,000 publicly available APIs available for different markets. Whensearching for “mapping” APIs, roughly 830 Public APIs are available.
The OGC has recently published an OGC Open Geospatial APIs White Paper, which createdadditional interest in the geospatial community on the state and status of GEO APIs. This
Concept Development Study (CDS) is built upon several of the concepts laid out in the White
Paper: See http://docs.opengeospatial.org/wp/16-019r4/16-019r4.html
The Concept Development Study (CDS) initiative is sponsored by:•Federal Geographic Data Committee (FGDC)•

United States Geologic Survey (USGS)

The pace of expansion in the geospatial world highlights the need for nurturing an ecosystembased approach by enabling the discovery, access and use of data and tools for many
applications across a wide variety of stakeholder groups (e.g., commerce, science anddecision making).
The question of how geospatial APIs might be developed in a consistent manner across theentire community is the focus of this Study. FGDC and USGS have elected to use the OGC
Geospatial APIs White Paper has identified by FGDC and USGS to serve as its foundation.
The project led to increased understanding of the requirements for enhanced interoperabilityof geospatial APIs, increased commonality of the semantic elements of APIs and reduced
effort by software developers who need to use multiple APIs for both the use of APIs andstandardized tools for the generation of APIs. In a longer-term goal after the completion of
the Concept Development Study, FGDC will embark upon a detailed roadmap that leads toefficient integration of data and information using standard APIs across applications, systems
and/or use.
The CDS can be broken down into three major parts. Each part has formed the basis for thisevaluation.
•

Examine existing geospatial APIs through the release of a Request for Information(RFI).

•

Support an FGDC-led API Plugfest and incorporate the major “Lessons Learned” into
this CDS results paper.

•

Lay the foundation and develop and define the scope of a multi-phase future APIinteroperability Pilot project to suggest future consensus activities and support
implementation.

5/53

The purpose of the study is to develop an in-depth understanding of all the components
necessary to enable increased coordination and effectiveness of APIs as applied to geospatial
information. The future API Pilot plans were also discussed at the FGDC led API Plugfest.
1.2 Document contributor contact points
All questions regarding this document should be directed to the editor or the contributors:
Name

Organization

Terry Idol

OGC

George Percivall

OGC

1.3 Notice to all
Attention is drawn to the possibility that some of the elements of this document may be thesubject 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 thatmight be infringed by any implementation of the standard set forth in this document, and toprovide supporting documentation.

2. References
The following documents are referenced in this document. For dated references, subsequent
amendments to, or revisions of, any of these publications do not apply. For undated
references, the latest edition of the normative document referred to applies.
OGC Open Geospatial APIs – White Paper (16-019),
http://docs.opengeospatial.org/wp/16-019r4/16-019r4.html, Published 2017-02-23
OGC Request for Information on Geospatial Application Programming Interfaces, Issued
March 8, 2017 http://www.opengeospatial.org/standards/requests/157
Programmableweb.com, API Directory (Mapping), 13 June 2017,https://www.programmableweb.com/category/mapping/apis?page=33&search_id=136385&c
ategory=19978

3. Conventions
3.1 Abbreviated terms
API

Application Programming Interface

BISON

Biodiversity Information Serving Our Nation

6/53

CDS

Concept Development Study

FEWS

Famine Early Warning System

FGDC

Federal Geographic Data Committee

IP

Innovation Program

NSDI

National Spatial Data Infrastructure

OGC

Open Geospatial Consortium

RFI

Request for Information

USGS

US Geological Survey

WFS

Web Feature Service

WMS

Web Map Service

WMSC

Web Map Service Context

4. Summary Conclusions from Open Call for Request for Information
4.1 The API Request for Information Message Background and Questions
The scope of the Request for Information portion of the Concept Development Study was todetermine how different software vendors and different infrastructure data consumers can/areusing APIs and improve interoperability while doing the below:•

Exchange data between systems without loss of information; and•Results using different APIs are predictive and similar.

An outcome of the project will be to enable connectivity and interoperability with different
distributed or complex systems.
This Concept Development Study and the Request for Information were governed by the
OGC Interoperability Program Policy and Procedures1. The RFI was open to the generalpublic and to all organizations with an interest in the use of geospatial APIs.
There were several areas of input requested from the community. The public was requested torespond to the following questions.

After following the link provided, see document OGC 05-127r8 for a summary of the OGC
Interoperability Program - recently renamed the OGC Innovation Program.

1

7/53

1) There are many who question whether there are issues achieving interoperability with
APIs. Please document why you and/or your organization believes there is or is not an
issue with interoperability in the geospatial community with the current use of APIs.
2) If you believe interoperability can indeed be improved, how do you think this can best be
achieved?
a) Is it by using a common set of semantics, such as the OGC Essentials as describedearlier (or in more detail in the OGC API White Paper)?
i) If so, would you use and modify the current set of OGC Essentials; orii) Suggest a different common set of semantics upon which to begin?
b) Please provide other suggestions to improve geospatial API interoperability. Pleaseprovide as much detail, including references to the White Paper, or other industry
publications, (per the instructions below) as possible.
3) Provide information about APIs that your organization manages or uses to discover,access, manipulate or use geospatial data.
4.2 Summary of the API RFI Results
A total of 19 organizations replied to the Request for Information. There are several major
points that were a common theme throughout the different responses. They are as follows.
•

The API RFI responses endorse the view that “The proliferation of diversely different
APIs degrades interoperability.”•

There is a great deal of support for the OGC Essentials. Many of the participants also
provided different recommendations on how to improve the initial set of OGC
Essentials2.

•

A need was identified for a Best Practice or similar type document that allows anorganization to use open standards while writing custom APIs.
o This subject is discussed later in the FGDC Plugfest section.

•

Many custom APIs were listed in the responses. Several of the APIs have been built
specific to certain programs. A number of the APIs were built on but then varied
from OGC Web Services, making then non-compliant.
o This subject is discussed later in the FGDC Plugfest section.

2•

A recurring theme was also the complexity of current specifications. As stated by one
Respondent, “WFS is too complex as are several other standards.”•

Another common criticism is the term “API”. The term APIs is applied at multiple
locations in the distributed computing environment. See for example the GEO
Secretariat response identifies three different APIs: Javascript API, Server side API,

After the completion of this study, the OGC Essentials were renamed as OGC Building Blocks

8/53

RESTful API. Any plan for APIs in OGC should recognize these different uses of the
API term.
Detailed information on the responses per organization can be found in Annex B.

5. FGDC Plugfest Overview
5.1 Introduction
The FGDC ran Plugfest with the specific objective of obtaining an increased understandingof the requirements for enhanced interoperability if geospatial APIs and how to reduce theeffort by software developers who need to use multiple APIs. The effort concentrated
primarily on web APIs, as described in the OGC API White Paper. The goals of the Plugfest
included:•Examining existing geospatial APIs;•

Identify how APIs are used effectively to exchange geospatial information;•

Support planning for increased use of protocols to enhance interoperability;•

Support increased use of essential elements of APIs that can enhance commonly
across diverse APIs; and•Suggest consensus activities that would improve the geospatial API ecosystem.

The participants for the Plugfest came from a diverse group of geospatial users, both within
and outside of the USGS and FGDC. From within the USGS, there were representatives fromthe BISON (Biodiversity Information Serving Our Nation), Water, Earthquakes, FEWS
(Famine Early Warning System) and National Map Program. There was also representationfrom George Mason University as well as from Esri.
The method of engagement was elegant and simple. Three on-line web clients were used toattempt to access as many identified web based APIs as possible, and see what did and did
not work.
The first day of testing was through the GeoPlatform along with the GeoPlatform Map
Manager and GeoPlatform Map Viewer. ArcGIS Online was also used to create Story Maps.
The remaining time was to be dedicated to using the newly released National Map Viewer
with its 'Add Data' function was tested for its support of WMS.
The Geospatial Platform (GeoPlatform) is a strategic national resource that supports the
Administration's–Open Government, Open Data and Digital Government strategies toenhance transparency, collaboration and participation. The GeoPlatform provides a suite ofwell-managed, highly available, and trusted geospatial data, services, and applications for use
by Federal agencies—and their State, local, Tribal, and regional partners to meet their
mission needs and the broader needs of the Nation. The GeoPlatform was developed by themember agencies of the FGDC through collaboration with partners and stakeholders. The
GeoPlatform is being implemented to help agencies meet their mission needs, including
communicating with and publishing data and maps to the public. The GeoPlatform focuses on
9/53

web applications that facilitate participatory information sharing, interoperability,
user-centered design, and collaboration on the World Wide Web. The GeoPlatform is a key
component connecting many goals of the NSDI Strategic Plan in advancing the NSDI. The
portfolio of data, applications, and services provided on the GeoPlatform is stewarded
through the use of open licenses and careful review and hosted on cloud infrastructure thatmaximizes geospatial interoperability. The GeoPlatform provides streamlined access to
National Geospatial Data Assets and reduces data duplication. The collaborative GeoPlatform
Marketplace helps reduce data acquisition costs. GeoPlatform's many tools and dashboards
support the A-16 Portfolio Management process.
•

Data Services - The GeoPlatform delivers trusted, nationally consistent, authoritative
geographically enriched social, economic, environmental and other data forunderstanding and decision making.

•Applications and Tools - The GeoPlatform provides a suite of applications and tools
for integrating, synthesizing, analyzing, problem-solving and visualizing
geographically enriched data to accelerate understanding and decision-making.

•Shared Services - The GeoPlatform provides shared hosting infrastructure that allows
agencies to publish their geospatial data, applications, and tools in a secure cloudcomputing environment at a low cost.

(The preceding paragraphs description is from the FGDC’s website and completely describes
the purpose and methods of employing standards in the USGS GeoPlatform(https://www.fgdc.gov/initiatives/geospatial-platform. Full credit for the text is given to U.S.
Geological Survey Department of the Interior/USGS.).

Figure 1 GeoPlatform Map Viewer
As described above, the Plugfest also made use of the Esri ArcGIS Online for the first day.
Through GeoPlatform’s ArcGIS Online account, all GeoPlatform users have access throughtheir geoplatform.gov login to a suite of hosted ArcGIS applications and services, including
Map Viewer, StoryMap Builder, Web AppBuilder and other configurable tools. Any user can
upload their own data and map layers to explore in the Map Viewer, as well as quickly add
them to other hosted map services provided in OGC standard formats. Users at the Plugfest
used ArcGIS’s StoryMaps application to combine their authoritative maps with narrative text,
10/53

images, and multimedia content. Storymaps made it easy to harness the power of maps andgeography to tell their story. Further, using ArcGIS’s configurable Web AppBuilder, analysts
can build intuitive, focused web application that run anywhere, on any device, without
writing a single line of code. New maps and applications can be saved and shared for free on
the ArcGIS online portal section of the GeoPlatform. Saved maps are then also automaticallydiscoverable through the Geoplatform.gov’s Map Manager. (Credit: Esri)
5.2 Plugfest General Results
The first day of the Plugfest, the GeoPlatform portion of the Plugfest was successful inadding the different external geospatial layers. Several different types of data from sites bothwithin and outside USGS could be brought together and create successful maps (Figure 1 and
2). The calls were made via OGC’s web map services (WMS).

Figure 2 2008 Cropland Data Layer

Figure 3 Earthquakes, Crops and Water Layers

11/53

A wide range of data was successfully integrated. As shown in the figures, water, crop andearthquake, or hazard data was integrated. Other data sets included selected endangered
species using the USGS BISON site.
Unfortunately, the new deployment configuration of the National Map Viewer prevented theWMS capabilities of the Add Data tool from working. No login on to ArcGIS Online
required on the National Map viewer, and this also limited the capabilities of the 'Share Map'function.
USGS recently released the National Map Viewer as a standalone version hosted on USGS
servers. This switch apparently introduced an undetected configuration issue that prevented
adding non-USGS WMS services (or geospatial data layers) via the Add Data tool. It isbelieved this is a simple fix to add a list of trusted domains for CORS into the standalone
configuration.
Work continued with the Geoplatform and the associated Story Map efforts to merge in the
different data sources.
5.3 Plugfest Specific Lessons Learned
The following is a list of specific issues that were discussed by the participants during thewrap up sessions held each day. Some issues are large and others might be considered minor,
depending on the reader’s unique point of view. All are worthy of mentioning for future
discussion.
5.3.1 Use of Common Documentation tool
One area of universal agreement from all the participants was the need for all developers to
use a standardized method for creating and documenting APIs. All in attendance agreed that
Swagger, now named OpenAPI Sec 2.0, should be used to ensure consistency and well
documented APIs.
As noted in the OGC API White Paper, Swagger was used in the OGC WaterML2.0 part 2Interoperability Experiment (https://portal.opengeospatial.org/files/?artifact_id=61224) todocument the CSIRO RESTful API. The CSIRO API Report (Annex B) makes the following
observation:•

Observation 9: Make use of automated API documentation where possible. These canoften be synched directly with an implementation version, which helps to minimize
divergence. Some also provide interactive (e.g., Swagger) documentation that allows
inline requests to be made. This helps to lower the barrier of entry for developers andquickly builds understanding.

This directly agrees with the comments from the participants in the Plugfest.
5.3.2 Security Issues relating to the Plugfest
An important lesson learned is that security and data access needs to be carefully consideredwhen selecting the site of a Plugfest. Access to certain data layers for some participants was
an issue for several participants.

12/53

The Plugfest was held at a USGS site. USGS personnel were able to log in using their USGS
credentials. Non USGS personnel logged in to the USGS Visitor Network using guest
credentials. This is a common and well accepted security practice at many, if not all,government and private facilities that even allow guest access to networks.
The issue was that the guest network severely limited the access of the USGS guests. Most of
the internal USGS geospatial data sites, that are widely available to the general public, were
not available via the USGS guest network. This greatly limited the work of the non USGS
participants during the Plugfest.
5.3.3 Other Items Discovered during the Plugfest
The base map in the National Map gallery is from Esri. The Platform version is different for
3d version of Arc than the map that is supporting the background version. Somewhere there
is an issue. National Map is on 10.4 Esri server. On GeoPlatform when one adds it in, they
get an OLDER version. The two are no in sync.
Universally, there needs to be life cycle management plan with APIs, by the people hosting
the APIs and the data behind the APIs. It becomes obvious that in many cases APIs are build
and then languish with old versions. Many are not maintained.
In the case of a program such as the GeoPlatform, it would be very useful to know thedifferent users. Then the users can be notified when or if changes are to be made to the website. This could include organizations that feed data to the GeoPlatform.
A somewhat confusing point for those using the Esri client version is when adding what is a
WMS layer, you actually add a “service” versus the “WMS”. This can lead to confusion.
The BISON site had extremely rich endangered species data that is useful to a large section of
the scientific community. However, without the standard implementation of the OGC WMS
and the “get” capabilities it is difficult to add to a generic client. This nonconformance ofstandards is quite common and makes it very difficult to bring in several layers. This raises
the questions - How do we make sure the API itself is compliant? As opposed to the client?
Vendor parameters in get capabilities are allowed, and there is no easy way to really
document this clearly.
The above discussion led quickly to the next discussion: Are there compliance checkers for
APIs? 1 - How do we get APIs validated and 2 – how do we extend special parameters? In
some cases, such as Web APIs, there are OGC verification tests that can take place by thedeveloper. But what about all the other APIs?
Discoverability of geospatial data is still a major challenge. Geoplatform.gov might be able
to help. It might be able to be a tool that can register data services (or WMS) and ask certain
questions when registering services so the service can be well understood. This might be as
simple as displaying extra information when layers or data is pulled up in the viewer.
A similar issue is that, as novice, how does one make his or her geospatial data layers
discoverable? There’s no guidebook on how to expose your resources. For example,
Cropscape is hard to find. As validator, can’t this be registered via different catalogues
automatically?

13/53

A common issue that occurred what that when adding layers, the user couldn’t see some layer
automatically. The system should at least zoom to bounding box or area that has been added.
There needs to be a community discussion on creating a sandbox for testing APIs. FGDC isinterested in having this discussion with OGC members and Staff.

5.4 Plugfest Way Forward

There is a six-month target to get ready for a first run of a follow on Plugfest or to start acomplete Pilot. The Pilot will be covered in the following section.
The overall results of this initial Plugfest was a part of larger picture road map. The long-termgoal of FGDC is bringing standards and data together! FGDC will be developing a Roadmap
over the next few of months on how they intend to proceed.
There is also a recognition that a much greater effort needs to be made to publicize the FGDCSDI Cookbook. The FGDC Cookbook, first developed in the year 2000, provides guidelines
on how to develop a Spatial Data Infrastructure Platform, amongst other items. Also, FGDC
will consider adding a section to the cookbook on APIs.

6. Path Forward – Pilot Plans
It is the goal of a proposed OGC FGDC API Pilot to demonstrate the power and efficiency of
distributed online environments using Open APIs to exchange geospatial data. The Pilot as
outlined below will be able to address and begin to answer the issues that have been
identified in this API Concept Development Study. Its primary intent is to demonstrate that asoftware architecture using open APIs, based on the API Essentials as defined in the OGC
API White Paper Web, allows for an efficient and powerful working environment that
supports processing, visualization, and representation of geospatial data in distributed
systems. At the same time, this pilot helps gathering further insights into experienced
obstacles and difficulties when using available web based geospatial APIs and systems todevelop system-wide improvements and adaptations to specific users’ needs (Arctic Pilot
RFQ 2016).
An OGC pilot initiative orchestrates the activities of multiple agencies, researchers andsoftware implementers in an agile development process. There are three main outcomes of apilot.
1) Running software code from several organizations to be tested to ensure interoperabilityof the independently developed implementations based on open standards.
2) Demonstration of scientific and policy-oriented scenarios with the deployed code. These
scenarios show the previously unavailable capability from a non-technical point of view.
3) Engineering Reports that document the results of the development, testing anddemonstration. The reports then become the basis of procurement activities of theoperational system.
In order to achieve the objectives of scientific credibility and software modularity (“plug andplay”) the pilot will be based on open standards.

14/53

There are three major areas upon which the Pilot will concentrate.
1) The OGC Open API White Paper will be one of the primary two areas of exploration for
Pilot, with the emphasis on exploring the use and possible expansion of the OGC API
Essentials. For the future generation of interoperable APIs, both the results from the
OGC RDGC API RFI respondents and the participants in the FGDC Plugfest identified
the maturation of the OGC API Essentials as one of the key areas. This section is what isnormally what is considered a traditional Pilot, like OGC’s Arctic SDP and other OGC
Pilots. There would be a minimum of two clients needed, and a minimum of two types ofscenarios. One scenario would be a predefined scenario where each of the Participants
would follow a script and ensure they could all retrieve certain data sets. The otherscenario would be more unscripted where each client would be given a minimum set of(lengthy) requirements for data collection to solve real world problems, and the analysis
would include analyzing the adequacy of the real-world data and data collection.
2) The second primary area of study for the Pilot will be how to better facilitate the use,
discovery, and currency of existing web-based APIs. This includes enabling helping
FGDC and USGS develop a long-term plan to allow GeoPlatform users a simple todiscover and use both internal USGS and external non USGS geospatial data sites.
3) This section will start addressing what might be done to ensure the sites referred to by the
GeoPlatform (or similar sites) are compliant to OGC API web specifications. In addition,an analysis will begin on how to best start looking at the issue of web site AND data
versioning for the different web sites. Finally, ideas for how to best review and make surethe web sites listed are up and running are to be discussed. This section is not expected tosolve these issues, but rather to create an approach and start generation both discussions
and ideas that may lead to solutions.
There are several benefits that can be derived from this Pilot. A few of the more prominent
ones are as follows.
•

Demonstrate that geospatial data can be integrated from multiple sources efficiently
into different clients using open API and other web standards developed by the OGC
and other standardization organizations.

•

Implement and document the implementation process of use cases addressing needsof the GeoPlatform using new and existing components .

•Demonstrate the value of metadata and how it can be used for Discovery bycomparing discovery and integration efforts for data and services with and without
metadata.

•

Investigate how metadata might be either used or enhanced to assist with versioning
issues.

•Demonstrate an approach to allow for easy discovery of data and data sets.

•

Start developing a plan to review and update the list of data sites to reduce users
frustrations.
15/53

•

Document the architecture that was developed and demonstrated in the pilot tosupport future procurements.

•

Develop video material and further best practice documentation and presentationmaterial that demonstrate all the functional requirements defined above.

The OGC FGDC API Pilot has three very distinct and different scopes as described above.
The overall size of a fully funded and staffed initiative can be made to FGDC and USGS in a
separate, nonpublic cover letter.
Upon confirmation from FGDC and USGS that the Pilot would be funded, OGC would
proceed to identify potential additional sponsors and identify common interests andrequirements for the pilot. Potential sponsors include government agencies, foundations andforward-looking companies.

16/53

Annex A Call for Participation
The call for participation for the OGC Application Development Interface Concept
Development Study is available online at
http://www.opengeospatial.org/pressroom/pressreleases/2557

17/53

Annex B API Request for Information Results
The detailed analysis of the Request for Information is below.
B.1 Major Issue(s) with Existing APIs:

Organization:

Response:

Ecere

Some organizations in the geospatial community surely arehaving interoperability issues with APIs, as that will arise assoon as you do something they were not meant to do, such as
using them together with different APIs, programming languages
or data formats they do not support.

FEMA

FEMA agrees with the conclusion that API proliferation adds tothe complexity for the user and publisher. Lack of consistency
with regard to standards in the documentation of capabilities,
formatting, and standards used to publish data through various
vendor APIs decrease usability between platforms.
Data API standards for geospatial data are not consistently
implemented across the various COTS and Open Source
products. This has resulted in the need to duplicate resources toprovide complete set of geospatial API functionality for the user.
For example it may be necessary to publish data through a
COTS and an Open Source software solution to achieveinteroperability. Additionally, inclusion of standards for attributetypes for date formatting, defining guidance for string andinteger formatting, and including projection and coordinate
systems for the data source are not always available. Assumed
projection and coordinate systems for most geospatial dataservices are that data is published in WGS84 format. This is notalways the case and metadata and API attribution are notenforced as part of the API reference. Data standards for date
and time attribution are not commonly understood or specified.

FGDC Service Status Checker•
resources discovered through our catalog systems often
reference non-existent or non-functioning services.
•
Even when services are discovered through a catalog, it
they are not reliable, a user often gets quickly frustrated with not
being able to find “healthy” and “usable” services.
•
The Status Checker is current testing the health andreliability of many OGC and ArcGIS REST services. We
should poll the user community for other known types ofservices that should also be tested by the Status Checker.

18/53

GeoScience Australia

1.1.
The biggest problem with WMS is how the minimum
specification is not fully featured enough to be usable for areasonably simple web mapping application. GeoServer and
ESRI implementations differ for GetFeatureInfo request.
Achieving interoperability is difficult.
1.2.
I would raise the point regarding the implementation of
the OGC standards and API implementations across different
vendors. Esri implements OGC in a certain way whereas
Geoserver does it in another. What we end up with is arequirement for vendor specific code in use of their API's (theopposite of interoperability). More needs to be done regarding
specification to remove this difference in implementation.

George Mason University

NOAA IOOSNOAA NOS CO-OPS

Natural Resources Canada

It is extremely laborious to prepare the incoming and data
information in right status from which analysts/decision-makers
can actually use in their analysis or decision. There are many
interoperation issues, such as format difference, projection
displacement, operation incompatibility, and semantic mismatch.
To achieve interoperability with API endpoints, they need to betested to ensure that they act as advertised and meet the API
specification. Non-standard enhancements need to be
encouraged to be included in future release of standards where
possible. Best practices need to be established when standards
are not sufficient to ensure interoperability. There are currently
many API issues that, if addressed, would enhanceinteroperability.
Overall, the implementation of geospatial API standards, if
widely adopted in the user community (vendors andorganizations), ultimately will aid in wider usage of anorganization’s data. However, at this time, CO-OPS’ user
community benefits from having both standards compliant
geospatial APIs and custom APIs serving data in simple formats
such as CSV.

For domain specific workflows, such as for decision support orcomplex use cases, interoperability can degrade where tools
implementing OGC standards are often seen as too complex tosustain by API developers. The tendency in complex use cases,is the closer the workflow gets to core business functions, themore rigid the infrastructure environments.

19/53

OMS Tech

Swedish NMA:
Lantmäteriet

USGS FEWSNOTE: ATTRIBUTION REQUESTED:
Some of the key issues that exist with respect to theachievability of interoperability are the inconsistent and variableapplication of the various dimensions of interoperability, theimpacts and burdens that API usage have on developers andusers, the incomplete or non-understandability of appropriate
documentation, and the lack of appropriate tools. A major
impediment to interoperability is that there are multiple
dimensions to interoperability and all are not being addressedwith the same level of importance. Some of these are datainteroperability, semantic interoperability, administrative or
institutional interoperability, legal interoperability, and security
interoperability.
WFS is too complex, we have experienced difficulties for thevendors to implement it, both on server and client side,
interoperability is poor.
The FEWS project has been using its own API for the timeseries data charting. The FEWS project would be interested
to know how many other users / communities are doing similar
activities and if anything has been standardized in this area.
Another area of interest is how to extend the FEWS WMS layers
for its satellite imagery. Since FEWS provides a new WMS
layer every 10 days for each dataset, there are more than
35,000+ layers. Even though they are publicly available, the
FEWS project adopted their own naming convention which isprobably difficult for other to adopt. FEWS is interested inlearning if standards or best practices exist for these time based
services and how FEWS could improve their sharing of theseresources.

USGS GHRC

USGS Masaki• Many interoperable data formats are not practical for large
volumes of data; and sacrifice efficiency for interoperability. For
example OMJSON https://github.com/peterataylor/omjson/blob/master/examples/timeseries-points.json does nothandle large sample volumes efficiently (1 day of 1Hz timeseries
data, for multiple channels).
• Quakeml (https://quake.ethz.ch/quakeml) creators explicitly
avoided standards like GML because it was considered too
verbose, and not relevant to seismology data.
• From a geospatial point of view, interoperability can be anissue with some mapping tools and API’s. This is becoming lessof a problem however with tool’s more standardized use ofinterchange formats like JSON and XML.
We believe that OGC provides excellent guidance fordevelopment of geospatial APIs. Our problem has been
incomplete compliance with existing standards due to resource
constraints and limited ability to enforce standards complianceduring development.

20/53

USGS Science Base

There are several issues with API interoperability:• Esri APIs vs OGC APIs -- Esri users expect Esri map services.
Delivery of OGC map services (WMS) to this subset of users is
not useful, so data portals are forced to generate Esri and OGC
map services to serve a broad user base.
• Versions -- There are many versions of WMS, WFS and WCS
to keep track of, and many are not backwards compatible. Some
API changes between version cause significant user concern,
include reversing the order of coordinates and alteringparameters (‘layer’ changed to ‘coverage’).
• Common APIs -- Many data stores deliver WMS, but few
actually provide data (WFS, WCS, OPeNDAP, GeoJSON). It isvery difficult to convince data portals to actually provide data.
Without data services users are left with non-API options(downloads).
• Bundled information -- Even within WMS the information you
need is often bundled with information that you do not careabout. It is not easy to pick out the data you need from somemap service offerings.
• Abstraction layers -- Many APIs work against internallyreferenced keys, requiring users to build multiple calls into theirimplementations. A common set of semantics that are supported
by major data stores would let users reduce the number andcomplexity of calls.

6.1 What is RIGHT with APIs and Interoperability:
Organization:
CEOS WGISS Integrated Catalog(CWIC) Team

Ecere

Esri

Response:
The CWIC API leverages OGC and other geospatial API
standards to facilitate the granule-level EO data search. To theclients, the standards-based API hides the complexities ofheterogeneous data discovery API from different data
providers. To the data providers, the common API facilitates
broader access to distributed EO data assets.
We believe in the interest of flexibility and innovation the API
developers should not be imposed how to structure their APIs.
Still, we do believe interoperability could be improved.

Using the ArcGIS API for JavaScript you can deploy your app
anywhere a compatible web browser runs. Solutions can bebuilt with no code for non-developers, and minimal coding fordevelopers (Web AppBuilder, AppStudio), and SDKs that allow
developers to build one codebase and deploy it to multiple
platforms (Qt, .NET, Java, JavaScript).

FEMA
FGDC Service Status Checker

The OGC Web Service (OWS) Standards have made thediscovery and sharing of spatial data standardized and easy.

21/53

GeoScience Australia
OGC standards are used extensively at Geoscience Australia
to provide interoperable access to its geospatial andgeoscience data holdings, in accordance with AustralianGovernment Public Data Policy Statement requirements. OGC
web services have been effective in enabling
intergovernmental data sharing and collaboration, and haveensured the lowest common denominators within thecommunity can access the services. OGC standards provide
open access to data for all without proprietary limitations, andafford the consistency and stability of standards developed byan international standards body using a consensus process.

Natural Resources Canada

Swedish NMA:
Lantmäteriet

USGS Masaki

From the perspective of public APIs, there are numerous
applications that demonstrate interoperability.

The use of existing standards have been a strategy in thedevelopment, primarily those with geo-focus. But if thesestandards doesn't fulfill our requirements, we have usedgeneral IT standards and de-facto standards. OGC
standards are often supported out of the box in GIS clients,
so a non-developer can get easy access toservices/APIs.Our experience is that WMS and WMTS havegood interoperability, they are easy to understand andimplement both on server side and in the clients. WCS havealso worked well, but there may be an issue with the later
version due to added complexity that will makeinteroperability harder.

We need to find ways to increase the rewards to developers
and product owners for compliance with existing
interoperability standards and for using supported
interoperable platforms.

22/53

6.2 How can interoperability be improved (General - Specific details in Examples below):
CEOS WGISS Integrated Catalog (CWIC)
Team

example a

To improve the interoperability of granule-level EO data
search, CWIC provides federated search of the granule-level
EO data to WGISS agency catalog systems through standardbased query APIs (i.e., CSW 2.0.2, OpenSearch) along withstandard metadata information models (i.e., Dublin Core,
ISO19115-2).

Ecere
2. We have our own ideas on how geospatial APIs could be
improved:• Facilitating support for multiple programming languages• Supporting the development of highly modular and light opensource libraries to handle core aspects used all across thecommunity (native libraries with C API)• Suggesting efficient & flexible data structures to represent
geospatial data and concepts
API Bindings Generator.

At Ecere, we are currently developing a bindings generator
which will be capable of automatically generating bindings fora number of programming languages from any given eC
example a library. The list currently includes C, C++, C#, Java and Python.
eC Object Notation

We have developed an object notation defined as a supersetof JSON: ECON (http://ec-lang.org/econ/). ECON includes
some additional features, and some identifiers naming
restrictions to be respected in order to be used with the ECON
example b profile.
Defining and handling projection definitions

If one thing needs to be standardized for geospatial APIs, we
believe it is how to define projection and datum.
A stand alone C API library, or additional support in libproj4,
example c would be very beneficial here
JSON (or our ECON super-set of it) is in our opinion a much
example d better choice to structure data in a text- based format.

23/53

Esri
When choosing an approach for creating applications withArcGIS capabilities, it's helpful to understand the generaldifferences between native and web apps as well as
differences in ArcGIS capabilities.
•
Native strategies offer the best device integration and themost out-of-the-box functionality for connected and offline
workflows, but they require native development skills. You can
use ArcGIS Runtime SDKs to create native apps.
•
Web strategies use HTML, JavaScript, and CSS hosted
on a web server and delivered to the user's device or desktop
using its web browser. This strategy is best if you don't know
the devices your users have and you need to reach a wide
audience. You can use ArcGIS API for JavaScript to create
web client solutions.
FEMA

FEMA has some basic perspectives that can be used toevaluate the utility of interoperability APIs.
Utility, as used in this discussion, is a measure of how muchthe use of an individual API makes things simpler, easier, or
useful.

example a

Data Publisher: This perspective seeks to transmit information
to others with minimal loss of semantic or contextual
information. It seeks to minimize the burden on itself whenproviding such information. It seeks to minimize the effect otherIT system changes, including upgrades, will have on the
publishing process. It seeks to reuse as much as possible
existing software, software libraries, and standards known byboth the publisher and the consumer.

example b

Data Consumer: This perspective seeks to receive informationfrom others with minimal loss of semantic or contextual
information. It seeks to expend minimal effort to ingest received
information. It seeks to minimize disruptions due to IT systems
changes on either the consumer’s or producer’s side.

example c

Solution Builder: This perspective seeks to build systems andsolutions that are resilient, secure, well known, well tested andeasily maintained. It seeks to reuse components as much as
possible and to de-couple IT system upgrades from publish or
consumed data.

example dData quality and documentation (metadata) are critical to theutility of any published data set. It is especially important that
documentation of the coordinate or projection are always
included as a standard data element. Understanding of thedefined coordinate system allows the user to properlytransform the data specific to their use case. It would be
beneficial to have broader support for API requests to returndata within defined parameters for projection and coordinate
system within the data set itself.

24/53

FGDC Service Status Checker
Some work has begun in this area related to quality of service
information in the OGC Quality of Service and Experience
DWG (QoSE DWG). This working group will provide a forum
for discussing issues related to Quality of Service and Qualityof Experience of Spatial Data Services and applications relying
on these services for delivering timely and accurate spatial
information to the end users.
We hope that the QoS will be able to define how quality ofservice can be well defined by this group, as well as initiative
discussions on the standardization of API’s for this information
sharing.
GeoScience Australia
3.3. Geoscience Australia utilises (web) APIs other than OGC
web services. Experience from GovHack events, wheredevelopers are typically non-experts in geospatial data andneed to rapidly develop mashup applications that integrate
disparate data sources in new and innovative ways, has shownthat the traditional OGC OWS APIs can be cumbersome andtime consuming for developers to learn and write code against.
The expectation from this section of the user community is forlightweight, semantically less rich RESTful APIs that typicallyuse JSON rather than XML as a data exchange format.
Typical examples (that have been used at Geoscience
Australia) include the Google Maps API, OpenStreetMap API
and Esri’s ArcGIS Server REST API. The trade off withadopting these APIs is a lack of formal standardisation(advantages of which described in previous paragraph).

example a

2.1. Technology moves faster than the standards review
process and the requirement for ‘agile innovation’ sometimes
gets mixed up with the concept of ‘bespoke’. OGC
documentation is seen as complex and difficult to navigate forshort-term project based developers.

example b

2.2. Vendors interpret the standard differently; it may bepossible to ‘lock-down’ (standardise) the implementation of an
API within a specification but perhaps not possible acrossdifferent specifications.[examples given in Appendix]

example c

2.3. Improvement in the OGC documentation needed to makethe core requirements clear; perhaps an appendix showing
examples of core requirements as ‘best practice’.

25/53

George Mason University

1. Multiple levels of compliance: The interoperability relies oncompliance to standards with specifications while different use
cases may vary on levels of compliance due to the availabilityof details. This applies to data encoding, metadata encoding,and operations. Explicit declaration of compliance levels would
help users to have an understanding of what to expect.
2. Semantic interoperation: An essential set of common
vocabularies are necessary to achieve a common ground of
defining and describing data, metadata, and operations. This
would help in eliminating the semantic confusion of displacing
terms out of its original context.
3. Provenance: All geospatial processes should enforce thegeneration and recording of provenance. Users need to know
the quality of the data before they can perform the evaluationof quality. Tracking back to the origin is often necessary forfully understanding the quality of data and service.
NOAA IOOS
One general feeling we share about OGC standards is that theprocess could be improved to shorten feedback loops and theamount of time it takes to develop new standards or revise
existing standards. Bringing the standards discussions andissue tracking into the public and the modern era via tools like
Github or Bitbucket would be very valuable.
There are also many small issues that negatively impact
interoperability among APIs. An excellent way to uncoverthese issues is to try to use APIs programmatically in end-toend workflows. As part of the IOOS Program, for example, we
generated a number of Jupyter Notebooks as part of a systemtest to see if we could discover datasets and extract data via
web services automatically. In nearly every case, we
encountered issues that were easy to overcome, and once
fixed, fixed not just the specific workflow, but for everyone in
the community. See this paper on Dynamic Reusable
Workflows for Ocean Science for more details.

26/53

CSW
Different CSW implementations represent service endpoints indifferent ways, for example:
a geoportal server instance might represent an OPeNDAP
endpoint as: urn:x-esri:specification:ServiceType:odp:url
while a pycsw server instance might represent an OPeNDAP
endpoint as:
OPeNDAP:OPeNDAPWe started a community effort on github to address this but thismight be better as an OGC effort. This is an analogous
problem to the issue raised in Section 2.2 of the white paper,
where different popular mapping APIs define ‘center’ and‘zoomLevel’ in similar but slightly incompatible ways. The
CSW issue however is more related to ensuring consistent
vocabularies are applied within certain sections of the ISO
19115-* metadata standards for content served via CSW.

example a

Not all CSW providers honor the bounding box specifications ofOGC. Thus we need to use workarounds to ensure thatrequests to CSW services such as geoportal server and pycsw
give the same results. This sorts of interoperability issues
could be helped by developing test suites that evaluate andscore CSW responses.

WMS

example b

WMS extensions provided by ncWMS are critical for working
effectively with data with a large dynamic range, where theWMS images are created on the fly with specified color scale
limits. Although these features have been embedded in the
popular Unidata THREDDS Data Server for more than five
years, they have not yet been proposed as part of a WMS
specification. If the developers in situations like this wereapproached with a roadmap for how to proceed, perhaps
adoption into the standard could be improved?
UGRID

example c

Unstructured grids (e.g. triangular, hex meshes) are being
used in next-generation atmospheric, oceanic and groundwatermodels, and community standards for UGRID have beendeveloped. We have no APIs for efficient extraction of data or
mapping of UGRID data.
SOS

example d

IOOS had to invest significant resources in order to get SOS
schemas for the data responses and metadata mappings toreally work for the IOOS community. More complete test
suites might have uncovered some of the problems.

27/53

NOAA NOS CO-OPS

Interoperability can be improved by having vendors andorganizations support a subset of common standards that are
open, similar to what is discussed in the OGC Essentials. For
example, an organization may choose to implement OGC
compliant WMS or WFS services.
From CO-OPS perspective, we try to support various users via
both common formats (standards) such as OGC WMS andWFS via ESRI REST services, as well as serve up data insimpler formats such as CSV or tab delimited. Not all users
wish to make use of “heavier” standards and appreciate thesimplicity of simple formats such as CSV. CO-OPS supports
various user needs as appropriate.
If ESRI Server supports the OGC API essentials, then COOPS may use and support the set of OGC Essentials.

OMS TechSpecifics given for all the bullets above I entire paragraphs

Semantic Interoperability Improvements
Semantic interoperability improvements include atransition away from lookup tables to a more generalized
semantic environment that utilizes formal vocabularies,
taxonomies, and ontologies, and a set of mappings
between them. In order for this to work, there must either
be a central semantic component that mediates between
the semantic resources needed by APIs or a federated
solution that decentralizes this and allows for multiple
semantic components that understand how to use eachother and update each other. In addition, the semantic
environment must allow for the curation of the semantic
resources by the experts involved. This needs to bedone in an open setting so that all APIs can benefit
equally. The use of SKOS terms can still be utilized, but
may be more meaningful when applied to a moregeneralized semantic environment as discussed. OGC
Essentials can be used, but extension and eitheralignment or mapping of the OGC Essentials will likely benecessary.
Dr. Browdy, in his work with Eye on Earth GNoN, defineda general federation mechanism for components; inparticular, semantic components. He also defined asemantic management dashboard that would allow
semantic resource managers to openly and properly
curate their semantic resources, and have thoseresources populate the federation of semantic
example a components to ensure semantic interoperability.

28/53

Legal Interoperability Improvements
The improvements for legal interoperability are based
upon the creation of a reusable legal interoperability
component that will calculate the proper legal result for a
submitted set of resources, and a set of methods toproperly associate the correct license or waiver with aresource. The legal interoperability component caneither be central or federated as discussed earlier in
Section 3.2.1. A federated solution is more scalable andmore open. There would also need to be a legal
interoperability dashboard for the curation of license
types and how their calculus is defined as licenses are
updated or new ones defined.
Another important improvement for legal interoperability
is the proper use of metadata so that resources can be
identified with respect to their access and use
constraints, meaning licenses and waivers, so APIs canunderstand what to do. Certain metadata standards,
such as ISO 19115, have fields defined for access anduse constraints, but the population of these fields is rare.
Resource managers need appropriate metadata tools to
encourage the proper population of metadata fields
without imposing too much of a burden on resource
example c managers.
Security Interoperability The improvements for security
interoperability are centered about a security broker.
This broker would serve many primary functions. One
would be a mediator between the API and the resource
provider in terms of the authentication and accessprotocol used. Another function would be to provide atrust relationship with resource providers in order toauthenticate and access the protected resources. Thesetrust relationships can be persistent or temporary, andcan be provided dynamically or on a deferred basis. A
third function would allow organization or federation
security managers to update requirements for trust
relationships and protocols to be used. The security
example d broker can be centralized or federated.

Swedish NMA:
Lantmäteriet

To increase interoperability and ease the implementation forrequest-response APIs, it would be useful to standardize a very
simple REST API for requests data (features) by geometry(bbox, point, line, polygon...) or by identifier.

29/53

• Consider the balance between efficiency and explicitness
when defining new exchange formats (sometimes the best way
to be efficient is to leave little room for interpretation/errors).
• Building tools to better leverage efficient data trends more
quickly is an area that needs to improve with API
interoperability. The adaptation process for many mapping
API’s is too slow.

USGS GHRC

The reference (http://docs.opengeospatial.org/wp/16-019r4/16019r4.html) lists the OGC Essentials (OGC Simple Features for
SQL, OGC Well Known Text for CRS, Well Known Text forGeometry, Well Known Binary for Geometry, GML Simple
Features, OGC Common Query Language, OGC Filter
Encoding, OGC WMTS Simple, OGC GeoSPARQL,
GeoPackage Features, Simplified GeoPackage Tiles,
GeoJSON, GeoRSS Simple, OWS Context) but not analytics
on these. How much usage do any of these get, and what
locales use specific essential the most? We try to support a
number of OGC standards, but cannot afford to support
standards that are not being widely used.
Ease of use is also a concern. OGC documentation is dense,
lacks ready-to-use information, and is often missing usefulexamples (actual code snippets showing how to use the API).
While we are sure there are OGC resources that could addressthese user’s concerns, these materials are not readily available
through http://www.opengeospatial.org/.

USGS Science BaseB.2 Does OGC Essentials play a role in improving API interoperability:
CEOS WGISS Integrated Catalog (CWIC)TeamCWIC utilizes the following OGC API Essentials:- OGC Filter Encoding,- GeoRSS Simple

Why or why not?

30/53

George Mason University
The OGC essentials (described at
http://docs.opengeospatial.org/wp/16-019r4/16019r4.html#_ogc_api_essentials) provide a valuable set ofcommon grounds for the interoperability to be enabled. The
Center has used many of these in supporting open access of
geospatial data. GML is used to deliver vector-features through
OGC WFS. OGC Filter Encoding is used to formulating queries
and constraints for different services. OGC Common Query
Language (CQL) is used in catalogue services to support userdefined queries. OWS Context is used in keeping userconfiguration of views in GeOnAS(http://geobrain.laits.gmu.edu/OnAS/).

Why or why not?

There are gaps identified for the OGC Essentials to function as
a common set of consensus for geospatial APIs. It is
recommended to expand the Essentials in: (1) common
specification for raster features, (2) metadata specifications, (3)multiple levels of explicit compliance declarations, (4)construction of common semantic vocabularies, and (5)enforcement of quality and provenance.

NOAA IOOS
OGC Essentials seems one useful component to improve
interoperability. For example, representing CRS in NetCDF as
WKT would be very useful. CovJSON (https://covjson.org)
should be explored in addition to GeoJSON, which attempts tomatch the scientific feature types or Discrete Sampling
Geometry (DSG) of the Climate and Forecast (CF)conventions, such as point, timeSeries, profile, trajectory.
Common representation of these feature types across APIs sothat you could round trip a timeSeries through OGC SOS,
OPeNDAP with CF Conventions, CovJSON, netCDF-Javalibrary, would be very useful.

Why or why not?
NOAA NOS CO-OPS
While CO-OPS has not reviewed the OGC API Essentials
document in detail, a set of common standards and formats (ifimplemented by a wide variety of vendors and organizations)can facilitate greater interoperability and simplify dataexchange. This does not replace completely the potential needfor custom implementations (i.e. simple formats such as CSV);
however, it may aid in simplifying access for an organization's
data for many users who may be familiar with standards
defined in the OGC Essentials.

Why or why not?

31/53

Natural Resources Canada
In general, OGC Essentials will likely improve interoperability
especially outside of the traditional geospatial community (e.g.
web community) where geospatial tooling and standards are
not yet well understood. Empirical evidence gathered throughinteractions with web developers at Government of Canadasponsored hackathons showed that common geospatial toolingand standards were largely unknown to participants, and insome cases presented barriers to access. The result was
minimal re-use of public sector geospatial data at two such
events.

Why or why not?

Common semantics are essential, but OGC Essentials
potentially go beyond what can be readily achieved by every
developer. Interoperability can be hampered by excessive‘degrees of freedom’, or complexity, in what is expected to be
implemented by platform developers. Furthermore, excessive
complexity reduces usability by developers, especially among
beginners. In order to target the Web platform as thetechnology environment, and Web users, authors, anddevelopers as the target audience efforts to minimize
complexity should be considered, but to add extensibility where
necessary and possible.

B.3 Other (non-OGC essentials) standards used in the organization's APIsCEOS WGISS Integrated Catalog (CWIC)TeamOGC OpenSearch Geo and Time Extensions (OGC 10-032r8)

George Mason University
To enable the management of geospatial workflows, Business
Process Execution Language (BPEL) is used to compose andmanage complex processes.
SOAP API is used to better facilitate the BPEL-based workflow
management system.

32/53

B.4 Other comments concerning semantics and APIs?
Ecere

USGS Masaki

Latitude, Longitude
Really, latitude should always go first!

We would be more likely to use guidance provided by
OGC in the form of an API white paper.

We would really like to see OGC track analytics on API use, sosystems like ScienceBase can refocus attention on widely used
protocols. We also would like OGC to post example
implementations (code included) from real-life users that could
help communities see the value of these standards.
A big challenge with the forward progress and standardizationof OGC is the fact that most GIS desktop users only use Esri
products. Most everything done in Esri cannot be transferredover to OGC format. One prime example is styling. Thereneeds to be a less steep learning curve for open-source GIS.
For example, the SLD(http://www.opengeospatial.org/standards/sld) is supposed tobe the authoritative source for OGC styling, but the
documentation does not provide a best way to actually create auseable, portable SLD.

USGS Science Base

Many OGC data formats are outdated. Developers prefer the
JSON format for content, as opposed to XML (WMC, SLD,
etc).

33/53

B.5 Information about APIs that the company/agency uses to access...use geospatial data
(General - Specific details in Examples below):

CEOS WGISSIntegrated
Catalog (CWIC)
Team

3.3.3.1
CWIC OpenSearch Description Document: Dataset specific OSDD request
URL example:
http://cwic.wgiss.ceos.org/opensearch/datasets/Landsat_8/osdd.xml?clientId=cwicClient

example aexample b 3.3.3.2

example c

CWIC OpenSearch request.

3.3.3.3 CWIC OpenSearch response
A CWIC OpenSearch response is an ATOM feed with zero or more ATOM entries.
Each entry represents metadata pertaining to single granule with submitted query.

Esri
GeoServices REST API

example a https://github.com/Esri/ArcRESTFile Geodatabase API

example b https://github.com/Esri/file-geodatabase-api
geometry-api-java

example c https://github.com/Esri/geometry-api-java

example d

ArcGIS API for JavaScript
https://developers.arcgis.com/javascript/latest/guide/index.html
https://github.com/Esri/jsapi-resources/tree/master/4.x/bower
ArcGIS API for Python
http://esri.github.io/arcgis-python-api/apidoc/html/

example e

ArcGIS Open Data API API
http://mjuniper.github.io/presentations/opendata-api.html - /https://github.com/ArcGIS/composer-api

Esri
GeoServices REST API

example a https://github.com/Esri/ArcRESTFile Geodatabase API

example b https://github.com/Esri/file-geodatabase-api
geometry-api-java

example c https://github.com/Esri/geometry-api-java
34/53

example d

ArcGIS API for JavaScript
https://developers.arcgis.com/javascript/latest/guide/index.html
https://github.com/Esri/jsapi-resources/tree/master/4.x/bower
ArcGIS API for Python
http://esri.github.io/arcgis-python-api/apidoc/html/

example e

ArcGIS Open Data API API
http://mjuniper.github.io/presentations/opendata-api.html - /https://github.com/ArcGIS/composer-api

FEMA

OpenFEMA API is a representative API FEMA publishes, though it is notprimarily geospatial in nature. Additional Geospatial capabilities could be includedin the OpenFEMA API but the work necessary to include the geospatial APIs has
only been started. FEMA does publish geospatial data in an API format using thenative API included within GeoServer. Documentation on use and capabilities are
dependent on software version and supporting documentation provided by thesoftware vendor.
Examples of each of the APIs documentation can be found at: OpenFEMA
example https://www.fema.gov/openfema-api-documentation GeoServera http://docs.geoserver.org/stable/en/user/
exampleb

FEMA APIs:
OpenFEMA https://www.fema.gov/data-feeds#APIs GeoServer:
https://gis.fema.gov/geoserver/web/?wicket:bookmarkablePage=:org.geoserver.web.demo.
MapPreview Page

FGDC Service
Status Checker
FGDC Service Status Checker (SSC) provides an API that returns a set of summary
and test diagnostic information about the tests performed on each service.
SCC API documentation: https://statuschecker.fgdc.gov/documentation#rest-api

example a

Request the latest WMS service test results:
https://statuschecker.fgdc.gov/api/v2/results?auth=<API-KEY>&type=wms&limit=1
This URL returns the following JSON response:

example b

Request a live test:
https://statuschecker.fgdc.gov/api/v2/liveTest?auth=<APIKEY>&type=wms&url=http://gisweb.unr.edu/ArcGIS/Services/Quaternary_Faults2/
MapServer/WMSServer?request=GetCapabilities&service=WMS
This URL returns the following JSON response:
35/53

GeoScience Australia

3.4. Geoscience Australia also employs the OpenDAP protocol
to access its geoscience data holdings, used by in-housescientists and the broader research community to undertake
scientific analysis. OGC WCS provides spatial coverages andcan provide much of the functionality provided by OpenDAP foraccessing georeferenced gridded datasets, but OpenDAP is alower level protocol than WCS and exposes the complete
structure of the underlying netCDF data. This can beadvantageous to the scientist (e.g. ability to access all of themetadata and variables in NetCDF files), which can make
OpenDAP the preferred method for programmatic data access,especially when accessing complex multidimensional datasets.
3.5. Geoscience Australia uses a number of APIs toprogrammatically access and manipulate spatial data, including
GDAL/OGR, Esri ArcPy and GeoTools.
3.6. Geoscience Australia is a user of FME, and employs the
FME API to access FME resources.

Geo Secretariat

The GEO DAB APIs can be used to discover and access
GEOSS resources via the GEOSS Common Infrastructure(GCI). The APIs offer simplified means for the development ofapplications and clients leveraging GEO DAB functionalities fordiscovery and access.
The GEO DAB APIs are addressed to a variety ofusers/developers. As a matter of fact, not all developers own
the same knowledge: they can have different levels of
expertise, even in the use of geospatial data and technologies.
Standard Web Services: the GEO DAB publishes interfaces
for the discovery and access of geospatial data in compliancewith de-iure and de-facto standards such as OGC CSW, WCS,
WMS, WFS, OAI-PMH, etc. These interfaces allow to interact
with the GEO DAB as if it were a single data system, compliant
with that particular standard. This type of interaction is usefulfor advanced users, experts in the use of geospatial data andexample a technologies.

36/53

Client-side APIs: high level client-side library, designed anddeveloped to facilitate the development of web and mobile
applications. These APIs aim to hide the complexity and the
low-level interaction with the GEO DAB, enabling developers
to work with simple objects representing GEO DAB content.
Presently, these APIs are available as a Javascript library;
supporting other programming/scripting languages is inscheduling. This solution is indicated for developers with good
example b knowledge HTML5+Javascript+CSS technologies.
Server-side APIs: the GEO DAB exposes the mainfunctionalities for geospatial open data discovery and accessthrough a set of server-side APIs, including OpenSearch and
RESTful APIs. These allow an easy interaction with the GEO
DAB through any programming environment that supports theexample c HTTP protocol and the JSON or XML message encoding.

George Mason University

37/53

example a

3.3.1

APIs for Discovering Geospatial Data

GEOSS Registries
http://geossregistries.info/geonetwork/srv/en/csw
It serves a community catalogue for registering all resources
for GEOSS.
OGC Filter Encoding, OGC Common Query Language, GML
Simple Features
Catalogue service libraries used at CSISS CKAN:
https://ckan.org/
PurposeMetadata management.
Use of OGC Essentials
Not applicable. It has its own set of
API for harvesting and searching. Plugins can enable OGC
catalogue services to be communicated with.
GeoNetwork http://geonetwork-opensource.org/
PurposeMetadata management.
Use of OGC Essentials
OGC Filter Encoding, OGC Common
Query Language, GML Simple Features
THREDDS
http://www.unidata.ucar.edu/software/thredds/current/tds/
PurposeDiscover and harvest data from communities ofclimate and environmental science.
Use of OGC Essentials
Not applicable. It can be harvested
into OGC catalogue services through traversing its
hierarchical metadata management and description
structures.

38/53

example b

3.3.2
APIs for Accessing Geospatial Data
GMUWCS-os
https://github.com/CSISS/GMUWCS-os
Purpose
Implementation of OGC WCS.
Use of OGC Essentials
OGC Filter Encoding.
CropScape API
https://ws.csiss.gmu.edu/axis2/services/CDLService?wsdl
PurposeQuery and report on analysis of CDL data.
Use of OGC Essentials
GML Simple FeaturesName
GMUWCS-os URI
https://github.com/CSISS/GMUWCS-os
PurposeOpen source implementation of OGC WCS andWFS.
Use of OGC Essentials
OGC Filter Encoding, OGC Common
Query Language, Well Known Text (WKT) for CRS, GML
Simple Features
Name
GeoServer URI
http://geoserver.org/
PurposeOpen source implementation of OGC WCS andWFS.
Use of OGC Essentials
OGC Filter Encoding, OGC Common
Query Language, Well Known Text (WKT) for CRS, GML
Simple Features
Name
OpenDAP URI
http://www.opendap.org/
PurposeAccess and disseminate data for the communityof climate and environmental science.
Use of OGC Essentials
Not applicable. It has special
capabilities in dealing with data in NetCDF.

example c

3.3.3

APIs for Manipulating or Using Geospatial DataName
GMU GRASS SOAP API URI
http://cube.csiss.gmu.edu/grassweb/manuals/
PurposeComplete Web service implementation of GRASS
functions in the Web environment. They are published as w3c
Web service, i.e. WSDL-described, SOAP-wrapped message,and UDDI-based discovery.
Use of OGC Essentials
Not applicable.
Name
BPELPower URI
http://geobrain.laits.gmu.edu:8099/bpelasync/
Purpose
Implementation of BPEL execution engine.
Use of OGC Essentials
Not applicable.
Name
52°North WPS URI
https://www.openhub.net/p/n52-wps
PurposeOpen source implementation of OGC WPS 1.0
and 2.0.
Use of OGC Essentials
GML Simple Features

39/53

6.3
NOAA IOOSIOOS relies on:● OGC Catalog Service for the Web (CSW)● OGC Web Map Service (WMS)● OGC Sensor Observation Service (SOS)/Sensor Web Enablement (SWE)● NetCDF-Java API and OPeNDAP API with
○ Climate and Forecast (CF) conventions for structured grids○ CF-Discrete Sampling Geometry (DSG) for observational data
○ CF-UGRID for unstructured (e.g. triangular, hex mesh) grids○ CF-SGRID for staggered structured grids● ERDDAP GridDAP and TableDAP services
Reference:● IOOS GitHub Organization and Software Repositories

6.4
NOAA NOS COOPS

example a ESRI FeatureServer

ESRI Map Service (OGC WMS and WFS support)
ESRI FeatureServer
ESRI Map Service (OGC WMS and WFS support)

example b Custom API (JSON, XML)

Custom API (CSV, JSON, XML)
Custom API (CSV, TSV, XML, KML)
Custom API (XML, HTML, TextERDDAP installation configured to return CO-OPS data (variety of formats,including ASCII, CSV, NetCDF, JSON, etc.)

Swedish NMA:
Lantmäteriet

example a 1. View Services (WMS, WMTS)
2. Services for Direct Access and consumption (Webexample b services SOAP - GML and REST - GML/GeoJSON)
example c 3. Download Services (FTP, Atom, WCS, REST)

USGS
GHRC

40/53

examplea

ArcGIS Web Map Link: 30 Day Significant Event Data Feeds; This map displays
seismic data products that are contained in near real-time GIS services from the
USGS Geologic Hazards Science Center in Golden, CO. Specifically event,
ShakeMap, and “Did You Feel It?” data for significant earthquakes over the last 30
days. The services within the map are updated every 15 minutes to display datafrom recent significant earthquakes. More information on the 3 data products
found in this map can be found at: Event:
http://earthquake.usgs.gov/earthquakes/; Did You Feel It?:
http://earthquake.usgs.gov/data/dyfi/; ShakeMap:
http://earthquake.usgs.gov/data/shakemap/ Metadata for these feeds can bereferenced at: https://github.com/usgs/hazdevgis/blob/master/LiveFeedMetadata.zip;
http://usgs.maps.arcgis.com/home/webmap/viewer.html?webmap=5555eabe9d
65418d8e0b5677b3fe59b5

exampleb• Advanced National Seismic System (ANSS) Comprehensive Earthquake Catalog(Comcat) API: https://earthquake.usgs.gov/earthquakes/search/ . The ANSS
Comprehensive Earthquake Catalog (ComCat) contains earthquake source
parameters (e.g. hypocenters, magnitudes, phase picks and amplitudes) and otherproducts (e.g. moment tensor solutions, macroseismic information, tectonic
summaries, maps) produced by contributing seismic networks. ComCat
Documentation is available at https://earthquake.usgs.gov/data/comcat/. The API
for ComCat is documented at https://earthquake.usgs.gov/fdsnws/event/1/. The
ComCat API follows the FDSN Event Web Service Specification(http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.0.pdf).

examplec• LibComcat is a project designed to provide command line equivalents to the
ANSS ComCat search API (as previously noted) and is publically available on
github. https://github.com/usgs/libcomcat.

exampled

GeoServe - https://earthquake.usgs.gov/ws/geoserve/;

exampleeLeaflet API - https://github.com/usgs/hazdev-leaflet; General utilities for working
with Leaflet, an open-source JavaScript library for mobile-friendly interactive
maps.

41/53

NaturalResources
CanadaOverview data from Natural Earth, place data from GeoNames and baseline data
OpenStreetMap are just some examples of APIs that demonstrate interoperability

example a Federal Geospatial Platform (gcgeo.gc.ca)
http://csw.open.canada.ca/geonetwork/srv/csw?service=CSW&request=GetRecords&
constraintLanguage=FILTER&version=2.0.2&ResultType=results&maxrecords=1000
http://webservices.maps.canada.ca/arcgis/rest/services/
https://github.com/fgpv-vpgf
https://github.com/fgpv-vpgf/geoApi

example b Open.canada.ca (open.canada.ca and open.canada.ca/open-maps) uses a feature-richregistry system called CKAN. CKAN can be accessed via machine-to-machine through theApplication Programming Interface (API). While not a geospatial specific API, users canaccess and manipulate geospatial metadata harvested by Open Canada from the FGP via
OGC CSW protocol. CKAN's Action API is a powerful, RPC-style API that exposes all of
CKAN's core features to API clients. All of a CKAN website's core functionality (everything you
can do with the web interface and more) can be used by external code that calls the CKAN
API. Each dataset has a “Link to JSON format” button that uses the API to download thecomplete metadata record for that dataset, delivering it to the end user in JSON format(JavaScript Object Notation). For example: • Use the API to automate search results:
http://open.canada.ca/data/en/api/3/action/package_search?q=geospatial will return all the
results with the search term “geospatial”.

example c Open.canada.ca (open.canada.ca and open.canada.ca/open-maps) uses a feature-richregistry system called CKAN. CKAN can be accessed via machine-to-machine through theApplication Programming Interface (API). While not a geospatial specific API, users canaccess and manipulate geospatial metadata harvested by Open Canada from the FGP via
OGC CSW protocol. CKAN's Action API is a powerful, RPC-style API that exposes all of
CKAN's core features to API clients. All of a CKAN website's core functionality (everything you
can do with the web interface and more) can be used by external code that calls the CKAN
API. Each dataset has a “Link to JSON format” button that uses the API to download thecomplete metadata record for that dataset, delivering it to the end user in JSON format(JavaScript Object Notation). For example: • Use the API to automate search results:
http://open.canada.ca/data/en/api/3/action/package_search?q=geospatial will return all the
results with the search term “geospatial”.

42/53

example d GeoGratis is a web portal that provides access to a wide collection of Canadian geospatial
data, maps, images, and publications at no cost and without restrictions. All distributed data
accessed via GeoGratis comes with an Unrestricted Use Licence Agreement that grants users
a non-exclusive, royalty-free right and licence to exercise all intellectual property rights in thedata including the right to use, incorporate, sub-license, modify, further develop, anddistribute the data. At it’s core GeoGratis is a RESTful HTTP API that serves geospatial
metadata as web resources. Multiple resource representations are supported including
JSON, KML, RSS, and CSV making the API easy to consume using lightweight programming
models. (http://geogratis.gc.ca/site/eng/api/documentation/sguide)

example e WET is an open source code library for building innovative websites that are accessible,usable, interoperable, mobile-friendly and multilingual. This collaborative open source projectis led by the Government of Canada. It includes an API based on OpenLayers that allows for
integration of geospatial data via standards (e.g. OGC WMS, WMTS, GeoJSON, KML,
TopoJSON etc.), allowing web developers to easily incorporate geospatial data visualization
into a Government of Canada web presence.
http://wet-boew.github.io/wet-boew/index-en.html

6.5
USGS Masaki
National Map API Services

example a https://viewer.nationalmap.gov/help/HowTo.htm
BISON API Services

example b https://bison.usgs.gov/doc/api.jsp

6.6
USGS National Nap

43/53

example a

ScienceBase API
ScienceBase is a collaborative environment for communities todocument and host their own scientific content. The ScienceBase
Catalog provides a fast and flexible data cataloging and discovery
mechanism for over 8 million records. It is backed by a REST API
for search and update activities.
The National Map uses the ScienceBase Catalog to store
metadata for all of it's publically available data products. This
FGDC metadata includes thesaurus-driven keywords defined by
the National Map to aid query and filtering based on: dataset,product extent and product format. By leveraging the existing
ScienceBase API , search and filtering capabilities were realized
without the need to duplicate these capabilities for the National
Map.
ScienceBase:- Catalog: https://www.sciencebase.gov/catalog/- API Documentation:
https://my.usgs.gov/confluence/display/sciencebase/ScienceBase

44/53

example b

TNMAccess API
Interestingly, even though it was adequate for our needs, the
ScienceBase API was a non-standard, custom API and we decided
to create our own API to address the following issues:● Simplification - the ScienceBase API handled a much larger
problem-set than required by the National Map. This meant thatcreating anything but the simplest of text queries could require afairly complex JSON filter construct. The idea of simplifying the
API around our much smaller set of use cases had the advantage
of making our API more accessible to less technical users.
● Abstraction - The risk of The National map changing backend
implementations raised concerns on the impact to users who may
have built a dependence on the API. By abstracting our core use
cases into a documented API, we could be more assured thateven if we changed our backend implementation we could still
maintain the same front-end interfaces - greatly minimizing thisrisk.
● Effectiveness - having an abstraction layer also allows us to add
and extend capabilities to enhance the effectiveness of the API
without the need to wait for these changes to be adopted by thebackend provider which in our case was still managed by USGS
but often driven by a different set of priorities.
National Map API:
- Datasets- Products- Services- Notifications
https://viewer.nationalmap.gov/tnmaccess/

USGS
Water
Example a

Web APIs
This is a list of the main water Web APIs USGS provides the public, with hyperlinks totheir documentation. The list it drawn from materials in [2] and [3], among otherplaces.
1. Water Data for the Nation (WDFN) Site Service [4] - Provides access to a catalog ofmonitoring locations and important metadata related to the observed parameters,
period of data availability, site ownership, and available statistical summaries ofobserved data.
2. WDFN Instantaneous Values Service [5] - Provides access to high-temporal
resolution (15 minute or finer) observational data at sites that can be identified
through the Site Service.
3. WDFN Daily Values Services [6] - Provides access to archives of daily statistics and45/53

observations related to sites and instantaneous values from 1 and 2.
4. WDFN Groundwater Services [7] - Provides access to groundwater level
observations for sites found with the site service. These are discrete observations, as
opposed to continuously recorded observations which are available from 2 and 3.
5. WDFN Statistics Service [8] - Provides summary statistics for time series data fromother services.
6. Water Quality Web Services [9] - Provides unified access to water quality (sample)
data from the USGS, US EPA, and USDA. Has sub services for stations, results (data),
activities (sampling acts / total field visits), and summaries of activities to provide
metrics about the place being sampled.
Example b

7. National Ground-Water Monitoring Network Web Services [10] - Provides an SOS
2.0.0 web service API for groundwater observations available in WaterML2.0 and a
WFS 1.1.0 web service API for monitoring features (well lithology and construction).
8. Geo Data Portal Processing Services [11] - Provides a WPS 1.0.0 web service API
with processes capable of calculating spatial statistics for large gridded time series
datasets.
9. Geo Data Portal data archives - A collection of gridded time series data with
OPeNDAP services available via THREDDS. Contents summarized at [12] and [13].
10. Network Linked Data Index - A system that indexes river-network-attached dataand provides a search interface with network navigation capabilities. [14]11. Publications Data Warehouse [22] - Provides a set of web services to access USGS
publications and related metadata. While this project is sponsored by the USGS
Libraries, WMA has been the lead for the project for some time.
As mentioned, this list is not exhaustive, rather it is a reasonably representative
selection of USGS water data APIs. (Links listed bel

Example cLanguage Specific APIs
The WMA maintains numerous applications that can be used in scientific workflows
or as components to construct larger applications. Many of these are written for the R
programming language and are maintained at the USGS-R github repository [14] andsummarized in [15]. Others are created and hosted as javascript libraries such as in[17], [18], and [19]. There is also a good diversity of python libraries that implement
APIs designed for reuse such as [20] and [21].
While these are all intended to support re-use in their respective languages, none ofthem attempt to implement a pre-existing API specification or have been developed
using explicitly Open API development practices. In this context of this RFI response,
they are for information only. It is the opinion of the author that APIs with such adomain-specific focus are not good targets for standardization because the use cases
addressed are so unique that the number of APIs with similar purpose

Example d[1] https://waterservices.usgs.gov/[2] http://onlinelibrary.wiley.com/doi/10.1111/j.1936704X.2014.03175.x/abstract;jsessionid=4DF93191BACAE24F48E258887291D1C7.f04t
02[3] https://www.researchgate.net/publication/
287107560_Progress_on_water_data_integration_and_distribution_A_summary_of_

46/53

select_US_Geological_Survey_data_systems[4] https://waterservices.usgs.gov/rest/Site-Service.html[5] https://waterservices.usgs.gov/rest/IV-Service.html[6] https://waterservices.usgs.gov/rest/DV-Service.html[7] https://waterservices.usgs.gov/rest/GW-Levels-Service.html[8] https://waterservices.usgs.gov/rest/Statistics-Service.html[9] https://www.waterqualitydata.us/webservices_documentation/[10] https://cida.usgs.gov/ngwmn/web-services.jsp[11] https://github.com/USGS-CIDA/geo-data-portal/wiki[12]
https://www.sciencebase.gov/catalog/items?parentId=54dd2326e4b08de9379b2fb1[13] https://cida.usgs.gov/thredds/catalog.html[14] https://cida.usgs.gov/nldi/about[15] https://github.com/USGS-R[16] https://owi.usgs.gov/R/[17] https://www.usgs.gov/news/usgs-releases-new-javascript-library-plotting-waterdata-nation[18] https://txpub.usgs.gov/DSS/streamer/api/3.14/web/index.html#tab1?top[19] https://txpub.usgs.gov/dss/search_api/1.1/doc/index.html#tab1?top[20] https://github.com/USGS-CIDA/pyGDP[21] https://water.usgs.gov/ogw/flopy/[22] https://pubs.er.usgs.gov/documentation/web_service_documentation[23] http://onlinelibrary.wiley.com/doi/10.1111/jawr.2016.52.issue-4/issuetoc[24] http://onlinelibrary.wiley.com/doi/10.1111/1752-1688.12417/abstract[25] http://docs.opengeospatial.org/wp/16-019r4/16-019r4.html

47/53

B.6 General comments not captured above

Organization: Response:
CEOS WGISSIntegrated
Catalog(CWIC) TeamCWIC Client Guide for OpenSearch(http://ceos.org/document_management/Working_Groups/WGISS/Projects/CWIC/OpenSearch/

Esri

SDG API
https://github.com/Esri/sdg-api

Geo
Secretariat

Useful Links
Online documentation and examples:
http://www.geodab.net/apis (alternatively, http://api.eurogeoss-broker.eu)

CWIC_OpenSearch_Client-Guide.doc)

Online GEO DAB View Test:
http://www.geodab.net/test-apis

NaturalResources
CanadaAPI developments should address the needs of Northerners and Indigenous communities,
including responding to priorities of Northerners and Indigenous Communities, working inzero/low bandwidth regions and considering the realities of frontier economies.
Arctic SDI is leading a user needs assessment activity, which is supporting Arctic SDI Strategic
Plan objectives 1,2,3,4 and 5.1 (Arctic-SDI.org).

B.7 Other APIs from Natural Resources Canada:

Environment and Climate Change Canada- MSC GeoMet (https://ec.gc.ca/meteo-weather/default.asp?lang=En&n=C0D9B3D8-1)- WMO World Ozone and Ultraviolet Radiation Data Centre (http://woudc.org)

48/53

- http://woudc.org/about/standards.php- http://woudc.org/about/data-access.php?lang=en#web-services- https://github.com/woudc (public)
Provincial-Open Alberta API
The Government of Alberta is committed to publishing open data to third parties via data
feeds through an application programming interface (API). The Government of Alberta
encourages developers to deliver and innovate using open data.

The base URL for the API is: http://open.alberta.ca/api.
https://github.com/abgov
British Columbia Data Catalogue API
Published by the Ministry of Jobs, Tourism and Skills Training - DataBC
Licensed under Open Government License - British Columbia
The live published metadata content of the BC Data Catalogue is accessible through anapplication programming interface (API) available here http://catalogue.data.gov.bc.ca/api/ .

Documentation on the use of the API is available http://docs.ckan.org/en/ckan2.5.3/api/index.html .
Catalogue content is also available via this record
http://catalogue.data.gov.bc.ca/dataset/bc-data-catalogue-content

49/53

- British Columbia Geomark Web Service
The Geomark Web Service is a free web service for public and government users to store anarea of interest or shape, called a 'geomark'.

https://catalogue.data.gov.bc.ca/dataset/geomark-web-service- British Columbia Physical Address Geocoding Web Service
The Physical Address Geocoder can be used to resolve physical locations from place names
and addresses in British Columbia. This RESTful web service, and corresponding, web
application interface can also be used to correct and standardize addresses in British
Columbia.

-New Brunswick GeoNB API
Map Viewer:http://geonb.snb.ca/geonb/
Operating under the mandate: find it, map it, share it, GeoNB aims to provide standardized
geospatial land data. The repository provides data from multiple sources and uses a REST
architectural style to serve users.

http://geonb.snb.ca/arcgis/rest/services-Nova Scotia Open Data Portal
Portal: https://data.novascotia.ca/browse
GitHub: https://github.com/socrata?page=1

50/53

Uses Socrata Open Data API to compile a catalogue from various sources that provide open
data sets to the end-user.
-YukonMap Viewer: http://mapservices.gov.yk.ca/GeoYukon/
GitHub: https://github.com/Esri/geoportal-server/wiki#welcome-to-the-esri-geoportalserver
Users can use a map viewer feature to preview layers or search data via the catalogue(http://geoweb.gov.yk.ca/geoportal/catalog/main/home.page#). The application makes useof ESRI server REST API.
Municipal
Municipal APIs built around interoperable data management platforms (i.e. CKAN)-Edmonton (https://data.edmonton.ca/)-Ottawa (http://data.ottawa.ca/)-Montreal (http://donnees.ville.montreal.qc.ca/)-Sherbrooke (https://www.donneesquebec.ca/fr/)-Surrey (http://data.surrey.ca/)
Public Domain-OpenStreetMap
OpenStreetMap API provides read and write operations on the raw map data of the
OpenStreetMap database.
(http://wiki.openstreetmap.org/wiki/API)
Academic-Nunaliit

51/53

The Nunaliit Atlas Framework aims to make it easy to tell stories and highlight relationships
between many different forms of information from a variety of sources, using maps as acentral way to connect and interact with the data.
The Nunaliit Atlas Framework was born out of a multi-disciplinary research project led by Dr.
Fraser Taylor, a Distinguished Research Professor in the department of Geography andEnvironmental Studies and director of the Geomatics and Cartographic Research Centre atCarleton University in Ottawa, Canada.
https://github.com/GCRC/nunaliit/wiki/Atlas-Builder-Documentation-Polar Data Catalogue of the Canadian Cryospheric Information Network
As a pilot project, GeoNetwork is being configured to serve the Polar Data Catalogue
Metadata collection as a Catalogue Service for the Web (CSW), to provide additional
flexibility and options for metadata interoperability.
http://polardata.ca/geonetwork

52/53

Annex C Revision history

Revision
Date

Revision
NumberAuthor

6/18/2017

0.1

T. IdolChangesnoted
Major
version53/53