Publication Date: 2020-04-27

Approval Date: 2019-11-22

Posted Date: 2019-09-09

Reference number of this document: OGC 19-048

Reference URL for this document: http://www.opengis.net/doc/IP/userguide/19-048

Category: User Guide

Editor: Jacob Stephens, James Stephens, Robert Thomas, Terry Idol

Title: OGC Disasters Resilience Pilot User Guide: Image Matters GeoPlatform User Guide


COPYRIGHT

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

Important

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights. Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

Note

This document is a user guide created as a deliverable in an OGC Interoperability Initiative as a user guide to the work of that initiative and is not an official position of the OGC membership. There may be additional valid approaches beyond what is described in this user guide.


POINTS OF CONTACT

Name

Organization

Jacob Stephens

Image Matters LLC

James Stephens

Image Matters LLC


Table of Contents

1. Introduction

This User guide provides general directions for using the Federal Geospatial Data Committee’s National Geospatial Platform (GeoPlatform) for Disasters Resilience. The GeoPlatform is a key component of the United States' National Spatial Data Infrastructure (NSDI), and allows users and communities to post metadata about their critical geospatial assets, thus allowing discovery of those assets by a broad range of users, including the public. These assets include both data and services. The GeoPlatform also allows the creation of communities that can address various challenges and needs. In the case of this pilot, a Disasters Resilience community has been established.

The user guide addresses how a Spatial Data Infrastructure supports the interoperable architecture needed for managing the disaster lifecycle. Users will be shown how to properly support an SDI, the vision for an SDI’s contribution to national disaster lifecycle management, and the critical issues and challenges faced in the use case.

Section 2 presents a high-level architecture of the GeoPlatform and Image Matters SOF4D tool for using data obtained via the GeoPlatform to create GeoPackages for mobile users.

Section 3 will describe in detail the use cases developed for this project.

Section 4 addresses special topics including Right Data for the Right User, Augmented Reality InfoAids, GeoPackage capabilities, and data imagery for the three disasters.

Section 5 describes the three disaster resilience scenarios and the tools used to confront those scenarios.

Section 6 highlights critical data challenges and steps forward.

1.1. Use Case 1: Colombia Rural Wildfire

In 2014, Colombia’s interior and justice minister declared a wave of forest fires affecting a large swath of territory in 12 of the country’s 32 provinces to be a national disaster1. Recurring, widespread wildfires pose a logistical challenge to Colombia’s society and threatens the livelihoods of rural communities. The demo will focus on the rural town of Ciénaga, which supports both agriculture and a coal depot. An emergency response manager will be tasked with assessing information, identifying hazards, and quickly communicating a strategy to first responders.

1.2. Use Case 2: Ghana Suburban Flooding

In 2019, heavy rainfall had been affecting the central coast of Ghana, especially Accra, causing floods. According to media reports, as of 16 April at 8.00 UTC, seven people died in different parts of Accra, four in the suburb of Adjei-Kojo and three in the suburb of Sakaman2. In a simulated flooding event, an emergency response manager will be using topographic, social, and flood inundation data to chart paths for emergency responders to reach stranded civilians.

1.3. Use Case 3: Haiti Urban Hurricane Preparation

Haiti is frequently subjected to hazardous weather conditions that can cause critical damage to local infrastructure and cause loss of life during and after a disaster event. An emergency manager in Port-au-Prince will be using geospatial data to formulate a plan for mitigation and preparedness in the face of an impending hurricane disaster. This plan will be constructed in SOF4D, a fast-response mapping and operational planning web application with GeoPackage capabilities. The emergency manager will outline evacuation routes and triage centers for victims of the event and deploy to disaster preparation teams on the ground.

2. Simple Architecture

2.1. GeoPlatform Architecture

GeoPlatform’s architecture integrates external data gathering with a registry application and web applications for data and metadata visualization.

Fig. 1 visualized the GeoPlatform architecture.

GeoPlatform Architecture Diagram v2
Figure 1. GeoPlatform Architecture

2.2. Integrated Systems Architecture

The integrated systems architecture for disaster resilience brings together data providers, a Spatial Data Infrastructure, an interoperable web application for data deployment (as well as other applications and tools that analyze or package data), and data consumers. The Spatial Data Infrastructure is a central pillar around which all other activities revolve, with data providers registering and semantically tagging their asset metadata, which acts as an index and reference tool to help data consumers find relevant data for their missions.

The integrated systems architecture combines the native capabilities of two web-based applications: The GeoPlatform serves as a national SDI that pulls together metadata for registration and discovery by users. SOF4D serves as a GeoPackaging webtool that allows the user to combine data layers found in the GeoPlatform with Augmented Reality (AR) InfoAids and deploy them to the emergency responder in the field.

Fig. 2 visualizes the integrated architecture of SOF4D and GeoPlatform.
GeoPlatform SOF4D Architecture Diagram v2
Figure 2. Overall Architecture

2.3. Data Provider

The GeoPlatform indexes metadata from a wide variety of data providers. Disaster-related data and layers also spans a large range of topics and audiences, from land cover, to precipitation, to fire alerts, flood inundation, housing data, mineral resources, and more. For the purpose of this pilot, data has been used from governmental providers such as USGS, NOAA, HIFLD, and NASA. Data was also gathered from NGOs such as AmeriGEOSS and Esri. For all web-based activities, open web services were required, specifically OGC standard open web services (e.g. WMS, WFS, WCS, etc.).

2.4. Data Consumers

Data Consumers in this architecture are primarily emergency response managers and secondarily emergency first responders. Emergency response managers are tasked with assessing data relevant to a disaster event and identifying hazards and other important information to be communicated to first responders. First responders must react to contextualized data and rely on data accuracy and quality in the middle of a disaster. Both parties rely on an interoperable architecture where data is easily accessible and the flow of information back and forth is facilitated by the capabilities shown in applications such as SOF4D.

3. General Use Cases by User Activity

The integrated system architecture was used to address one key use case: an emergency response manager finding the right data and getting it to the right users at the right time. This use case was demonstrated in three scenarios, focusing on disaster preparedness and response the most, when an emergency response manager is on a limited timeline to find the right data and deploy it to the right users in a chaotic situation.

3.1. Publication of data

Emergency Response Manager use case involving data discovery and integration for disaster response in a timely manner. 3 major data sets to address 3 scenarios 1) Colombia Wildfire 2) Ghana flood 3) Haiti hurricane

3.2. Registration of data

Data was registered in the GeoPlatform and SOF4D during the "operational phase". There are two primary methods for data to be quickly registered in GeoPlatform. GeoPlatform aggregates available relevant data for cross-agency access and sharing. This guide helps GeoPlatform users with best practices and procedures for discovering, accessing, and re-using resources registered to the GeoPlatform. This is best achieved through a suite of tools in the GeoPlatform for registering, curating, and publishing geospatial resources. Both GeoPlatform’s Object Editor and Register Resource Plugin can import metadata from an open web service’s getcapabilities document as long as the service has robust and properly formatted metadata.

3.2.1. GeoPlatform ObjectEditor

ObjectEditor is GeoPlatform’s standard registration tool, with capabilities that allow the user to register a wide variety of asset types including, but not limited to, Web Services, Layers, Datasets, Maps, Web Applications, Websites, Topics, Concept Schemes, Users, and more. It has more in-depth metadata requirements than the Register Resources Plugin, making ObjectEditor a better tool for non-disaster periods when speedy registration and guided metadata requirements are not a situational requirement. As seen below, a service URL can be used to harvest metadata into the GeoPlatform registry.

Fig. 1 shows how an asset is registered in the GeoPlatform via ObjectEditor.

Screen Shot 2019 09 06 at 11.30.16 AM
Figure 3. Registering a Service in ObjectEditor

3.2.2. GeoPlatform Register Resource Plugin

GeoPlatform utilizes the Resource Registration Plugin to quickly register resources to the platform with a reduced metadata requirement. This plugin can be installed on any dynamic community and given customized URL parameters to streamline the registration process. As seen in the image below, the plugin guides the user through the metadata registration of an asset, seeking key pieces of information describing the data.

Fig. 2 shows how an asset is registered in GeoPlatform via the Resource Registration Plugin.

Screen Shot 2019 09 06 at 11.39.05 AM
Figure 4. Registering a Web Application with the Register Resource Plugin

The Resource Registration Plugin is accessible from the GeoPlatform home page. It currently supports the registration of six asset types: Datasets, Web Services, Web Maps, Web Applications, Topics, and Websites. The process is designed to point users towards the most important metadata requirements that help support good metadata practices.

3.2.3. SOF4D

The SOF4D web application was developed to support timely operational planning and fuses geospatial data with augmented reality Information Aids (InfoAids) for maps contextualized to mission needs. Layers and InfoAids can be arranged in task-specific Mission Specific Operating Pictures, which can then be exported as a GeoPackage that can be shared on the web or deployed to SOF4D’s mobile application.

SOF4D currently only supports OGC standard open web services (e.g. WMS, WFS, WCS) and GeoJSON files for generating layers in its system. It relies heavily on existing online geospatial assets, diminishing the importance of KMLs, Shapefiles, GeoDatabases, and CSVs as acceptable formats for dissemination.

Like GeoPlatform, SOF4D will harvest existing metadata from the getcapabilities document as long as the metadata is properly formatted. SOF4D’s service harvesting capabilities are shown below.

Fig. 3 shows how Open Web Services are registered to SOF4D.

jS2h1Nk
Figure 5. Registering Services in SOF4D

3.3. Discovering of data

In-Scenario, data discovery is being accomplished using GeoPlatform’s Semantic Search capabilities. Where normal search queries reference a database using a keyword, Semantic Search functions off of searching for assets tagged with semantic concepts that exist in a authoritative vocabulary. Authoritative vocabularies allow for agencies to differentiate technical terms and connect those terms with a broader semantic context. When the user searches for a semantic concept, they can search within the target vocabulary, which searches not only for the semantic concept, but also any other concepts semantically linked to that original concept. This casts a wider net for assets, but only within a certain curated knowledgespace.

3.4. Downloading of data

The data used in this use case was contained primarily in OGC standard open web services obtainable from government and NGO sources. These can be registered to the GeoPlatform and SOF4D easily by using the URL of the getcapabilities document and plugging it into the registration page of either application. The layers are accessible over the web and can be loaded into either application’s map viewer tool.

3.5. Data Integration

Data integration takes place at the SOF4D stage. Once data has been found in GeoPlatform, it can be integrated by registering it to SOF4D and creating a new mission in the system. A user can then create Mission Specific Operation Pictures (MSOPs) which are tailored to specific objectives, themes, or domains. At this point a user can load their layers into an MSOP, which can be seen below.

Fig. 4 shows how users interact with data and AR InfoAids in a SOF4D Mission Specific Operating Picture.

6sCJV2b
Figure 6. SOF4D Mission Specific Operating Picture

3.6. Republication of data

Once a user has completed a Mission Specific Operation Pictures, it can be deployed as a GeoPackage from the SOF4D system. This GeoPackage can be downloaded onto the user’s computer and shared, or deployed to the SOF4D mobile application for use by other clients. All the layers that were in the MSOP will be contained in the GeoPackage.

3.7. Displaying of the data with proper symbology

Currently SOF4D does not support custom symbology in its infoaids. While this is planned for a future release, current limitations required demoing only the native symbols in the SOF4D system. In the future, users will be able to import their own custom symbol libraries and use them as InfoAids, augmenting the ability of the end user to communicate effectively with first responders on the scene.

4. Special Topics

4.1. Right Data for the Right User

The disaster resilience lifecycle sometimes allows only a small window of time for data discovery and deployment. Finding the relevant data to the mission, analyzing it, packaging it, and deploying it to a client can be an onerous task in the midst of a disaster event, when a response center might be inundated with various data requests. The web applications in this integrated systems architecture provide features which help mitigate the challenges that emergency response managers may face in a disaster event.

Data discovery and accessibility can be critical issues in a disaster event. Sifting through incomplete or vague metadata is already difficult without the added burden of having to access offline datasets such as KMLs, shapefiles, CSVs, and GeoDatabases. GeoPlatform encourages data providers to carefully consider these metadata concerns, but to also tag their geospatial assets with semantic concepts. Semantic search is an evolution beyond simple keyword search queries, finding relevant resources that have been tagged within the same common vocabulary, ontology, or taxonomy. GeoPlatform’s Semantic Search capabilities ensures that users are looking for data within the parameters of these approved vocabularies. This organizational tool allows data consumers to find the data they need faster. In the case of open web services, data consumers can also quickly assess whether or not the data is useful for their mission by visualizing the layers in GeoPlatform’s MapViewer application. This capability emphasizes the importance of open web services in the disaster resilience lifecycle, due to their ease of use over individual files such as KMLs, Shapefiles, CSVs, and GeoDatabases.

Once the right data has been discovered, how will it be deployed to the right user? SOF4D’s MSOP capability allows the user to package different sets of layers and InfoAids for different recipients, with clear metadata that describes each MSOP and its intended audience. These MSOPs are deployed as GeoPackages that can be specified to their particular user group, who are able to pull them onto their mobile platform as packaged data with augmented reality InfoAids. This process can potentially reduce the amount of time needed to find and deploy data by hours or more.

4.2. Augmented Reality Info Aids

Image Matter’s augmented reality tool, SOF4D, takes strides forwards in providing data to the right user in a timely manner by creating an augmented reality experience for mission-specific tasking. In SOF4D a user can create a mission and assign layers and other data to that mission’s specific operation pictures that can be then deployed as a GeoPackage to a mobile device such as a smartphone. The mobile user can then pull those MSOPs onto the mobile platform and interact with tthem in an augmented reality experience. InfoAids are an essential part of this architecture, capturing information in an augmented reality view to enhance the mobile user’s understanding of their geography.

4.3. GeoPackage

SOF4D supports GeoPackage capability as part of an ongoing effort to work within standardized geospatial data practices. It is suited to the 4D aspect of the tool’s workflow, addressing the problem of timely geospatial data being shared within a short response time to a hazardous situation. In a disaster scenario, there may not be a lot of time to compile information and make it available to first responders on the ground. The GeoPackage capability allows users to send out concise packets of timely information to the right user in a simple format that can be unboxed and plugged into the mobile application immediately. The value of GeoPackage is its ability to be generated from authoritative and curated sources for dissemination to a variety platforms, including web, desktop, and mobile devices. This ease of use empowers field operators with current information, even in disconnected environments. GeoPackage provides access to a wide variety of geographic data types such as both raster and vector; points, lines, and polygons; and now, even 3-D information such as information aids. This flexibility is eminently suitable for the Disaster Response community.

5. Scenarios and Tools Demonstration

The demonstrations for the integrated architecture revolve around activities seen in the preparation and response phases of disasters. They focus on international events with a mix of rural, suburban, and urban settings. Originally there was a plan to access a mix of international, national, governmental, and NGO resources, but constraints on data discovery curtailed that original plan. Each scenario follows the same basic workflow of the user searching for their data, visualizing it in GeoPlatform’s MapViewer application, importing the data to SOF4D, and then deploying the data as a GeoPackage.

5.1. Audience

The scenarios' intended audience is emergency response managers and first responders such as firefighters, EMS workers, and other rescue-oriented workers. The goal is to illustrate how a national Spatial Data Infrastructure can make data discovery easier in the midst of a chaotic disaster scenario, and how that data can be deployed to responders on the ground quickly to answer the tough questions.

5.2. Registration of data

SOF4D currently only supports OGC standard open web services (e.g. WMS, WFS, WCS) and GeoJSON files for generating layers in its system. It relies heavily on existing online geospatial assets, diminishing the importance of KMLs, Shapefiles, GeoDatabases, and CSVs as acceptable formats for dissemination.

Like GeoPlatform, SOF4D will harvest existing metadata from the getcapabilities document as long as the metadata is properly formatted.

5.3. Downloading of data

The downloading process does not differ enough amongst the scenarios to differentiate the approach taken by the user. Once relevant web services have been found in the GeoPlatform, it is imported into SOF4D through its registration function. Metadata is harvested from the service’s getcapabilities xml document, which populate the newly registered asset.

Once the user has completed integrating the data in Mission Specific Operation Pictures, it is then deployed in a GeoPackage

5.4. Displaying of the data with proper symbology

Currently SOF4D does not support custom symbology in its InfoAids. While this is planned for a future release, current limitations required demoing only the native symbols in the SOF4D system. In the future, users will be able to import their own custom symbol libraries and use them as InfoAids, augmenting the ability of the end user to communicate effectively with first responders on the scene.

SOF4D has three standard military symbols for designating Information, Navigation, and Objectives.

5.5. Rural Wildfire

The first scenario is based on the challenges faced by the Colombian government in combatting wildfires across the country. In 2014, Colombia’s interior and justice minister declared a wave of forest fires affecting a large swath of territory in 12 of the country’s 32 provinces to be a national disaster. Particularly the scenario be focuses on the rural town of Ciénaga, which supports both agriculture and a coal depot.

5.5.1. Publication of data

Assets were gathered from US-based governmental and NGO resources such as NASA, USGS, MODI, and AmeriGEOSS. National data from Colombia proved too difficult to collect in the span of time available, prompting a reliance on global data. While these global resources are useful, they lack the nuance of localized datasets and cannot be efficiently utilized in a community-level disaster event response.

5.5.1.1. In-situ Data
  • USGS Mineral Resources

Fig. 1 shows USGS Mineral Resources layer in Colombia.

Screen Shot 2019 09 06 at 2.56.17 PM
Figure 7. USGS Mineral Resources in Colombia
5.5.1.2. Model Data
  • NOAA Precipitation Prediction

5.5.1.3. Remote Sensing Data
  • MODIS 24 Hour Fire Alert

  • USGS Land Cover

5.5.2. Discovering of data

Using semantic search, the user’s going to focus on some key terms contained in the FEMA Model and Data Inventory (MODI) vocabulary and GeoNames: Response, Fire Hazard, Emergency Support Function 4: Firefighting, and Colombia. Any items semantically linked to these concepts will show up in the query.

5.5.3. Data Integration

The user integrates the data in SOF4D’s Mission Specific Operating Pictures (MSOP), which provide objective-oriented bundles of layers and InfoAids to be deployed as a GeoPackage. The data was integrated to answer several questions: Fire extents, risk assessments, hazardous materials, and local firefighting resources.

5.5.4. Republication of data

Once an MSOP is finished, it is deployed as a GeoPackage which can be pulled down to a mobile platform or downloaded and disseminated in other ways.

5.6. Suburban Flood

The second demonstration is based on the challenges faced by the government of Ghana. Frequent flooding can be devastating to local infrastructure and bring society to a standstill, while also inflicting civilian deaths. In 2016, heavy rainfall had been affecting the central coast of Ghana, especially Accra, causing floods. According to media reports, as of 16 April at 8.00 UTC, seven people died in different parts of Accra, four in the suburb of Adjei-Kojo and three in the suburb of Sakaman. Based on this, the demonstration will outline the locations of stranded families in a flooded area, with instructions for first responders on how to rescue the civilians.

Fig. 2 shows Water Extents data in Accra.

Screen Shot 2019 09 06 at 3.04.28 PM
Figure 8. Accra Water Extents

5.6.1. Publication of data

Assets were gathered from US-based governmental and NGO resources such as NASA, USGS, MODI, and AmeriGEOSS. National data from Ghana proved too difficult to collect in the span of time available, prompting a reliance on global data, which had sparse coverage of the target area. While these global resources are useful, they lack the nuance of localized datasets and cannot be efficiently utilized in a community-level disaster event response.

5.6.1.1. In-situ Data
  • Road Infrastructure Data

5.6.1.2. Model Data
  • NOAA Precipitation Data

5.6.1.3. Remote Sensing Data
  • Land Cover

  • Esri World Imagery

  • Esri World Topography

5.6.2. Discovering of data

Using semantic search, the user’s going to focus on some key terms contained in the vocabulary: Response, Flood Hazard, and Ghana. Any items that are tagged with these concepts or semantically linked to these concepts will show up in the query.

5.6.3. Data Integration

The user integrates the data in SOF4D’s Mission Specific Operating Pictures, which provide objective-oriented bundles of layers and InfoAids to be deployed as a GeoPackage. The data was integrated to determine where flood waters would be too high for rescuers to reach without the aid of boats, as well as identifying potential hazards on the route to rescue the civilians.

5.6.4. Republication of data

Once an MSOP is finished, it is deployed as a GeoPackage which can be pulled down to a mobile platform or downloaded and disseminated in other ways.

5.7. Urban Hurricane Preparation

Haiti is frequently subjected to hazardous weather conditions that can cause critical damage to local infrastructure and cause loss of life during and after a disaster event. An emergency manager in Port-au-Prince will be using geospatial data to formulate a plan for mitigation and preparedness in the face of an impending hurricane disaster. This plan will be constructed in SOF4D, outlining evacuation routes and triage centers for victims of the event, and deployed to disaster preparation teams on the ground.

Fig. 3 shows Weather Radar Service data over Haiti.

Screen Shot 2019 09 06 at 2.59.09 PM
Figure 9. Smoothed Weather Radar Service

5.7.1. Publication of data

Assets were gathered from US-based governmental and NGO resources such as NASA, USGS, MODI, and AmeriGEOSS. While data from Haiti could be found, much of it was in offline resources that would take too long to verify and stand up in a service. While these global resources are useful, they lack the nuance of localized datasets and cannot be efficiently utilized in a community-level disaster event response.

5.7.1.1. In-situ Data
  • Open Road Map Layer

  • Healthcare Facility Layer

5.7.1.2. Model Data
  • Hurricane Path Projection

5.7.1.3. Remote Sensing Data
  • Hurricane Satellite Imagery

  • Esri World Topography

  • Esri World Imagery

5.7.2. Discovering of data

Using semantic search, the user’s going to focus on some key terms contained in the FEMA MODI vocabulary and GeoNames: Mitigation, Hurricane Hazard, and Haiti. Any items that are tagged with these concepts or semantically linked to these concepts will show up in the query.

5.7.3. Data Integration

The user integrates the data in SOF4D’s Mission Specific Operating Pictures, which provide objective-oriented bundles of layers and InfoAids to be deployed as a GeoPackage. The data was integrated to determine where the hurricane could pose risk to civilians evacuating Port-au-Prince. It was also pertinent to determine where relief stations and medical triage booths could be placed where they wouldn’t be destroyed by the storm.

5.7.4. Republication of data

Once an MSOP is finished, it is deployed as a GeoPackage which can be pulled down to a mobile platform or downloaded and disseminated in other ways.

6. Conclusion and Way Forward

An exciting architecture is growing quickly for an interoperable system for handling emergency response. Through the use of a National Spatial Data Infrastructure, semantic search, and a GeoPackaging tool the user is able to quickly discover the resources they need and send it out to the clients who need it most. By maintaining resources and assets while managing data with robust metadata, the speed at which users can answer questions in the disasters domain can be increased exponentially.

However, many challenges remain that impede the ability for users to find the data they need in a disaster.

  1. There is a clear need for Spatial Data Infrastructures such as the GeoPlatform. The amount of resources available across the web is staggering, but spread out across multiple websites, including sites for sub-agencies that bury their data or do not provide adequate means to deploy the data over the web. NASA in particular exemplified this challenge: Both Nasa Earthdata and NASA SEDAC had a tendency to bury their open web services under multiple pages. NASA EARTHDATA relies on regularly updating the getcapabilities document with a map key that will expire after less than an hour. This renders the service a liability when the layer automatically generates a layer of text blanketing the map with a warning that the key has expired. In a rapid response situation, the concept of expiring data is an oxymoron. Data discovery in AmeriGEOSS was hampered by its extensive list of tags and filters which make it difficult to determine where data resides. Tags for WMS, WFS, and other open web service formats rarely led to a deployable open web service.

  2. International data is particularly hard to find. While it may exist in AmeriGEOSS or similar sites, the metadata standards are lax and rarely clarify the actual purpose of the data. The process of downloading, assessing, and identifying relevant layers in an application is too long and laborious for a disaster scenario when data needs to be ready to "plug in and go".

  3. Data Standards and Quality challenges loomed over the whole project, especially in international datasets. The future of geospatial data lies in open web services that can be reliably maintained and deployed to web applications. Many "WMS Services" on AmeriGEOSS do not support getcapabilities documents, which is a vital function for open accessibility. This problem also persisted in NASA SEDAC when trying to obtain global agricultural data. Many datasets on AmeriGEOSS also had WMS services which pointed back to GeoNode, limiting the user’s ability to harvest the data for more open mapping applications or registering the data in SDIs like GeoPlatform. GeoNode is a private application and the formatting required for using their product precludes the data from being used in applications like GeoPlatform’s MapViewer. The NOAA Precipitation model did not support any actual layers - checking the xml document showed the service was basically empty. If a resource is not available, it needs to be deprecated from customer-facing platforms until it can be made available again.

  4. There is a persistent misuse of KML files in general and AmeriGEOSS in particular as an interchange format for sharing data, which is not their intended purpose and makes data-sharing more difficult. KMLs are not meant to handle the sort of data-sharing that GeoPackages, Shapefiles, CSVs, and other data formats were designed to handle. It is more efficient and more effective to replace the widespread misuse of KMLs with a shift to adopting GeoPackages as an industry-standard data-sharing format. OGC’s roadmap for GeoPackage development will continue to contribute value to an industry-wide push to standardize GeoPackages as an interchange format.

There were diamonds in the rough, though. Landfire.gov showed excellent tables that broke down the services by their title, purpose, and location, making it clear to the user what services they might need. Fao.org also had excellent metadata support in their online datasets, showing a clear dedication to metadata standards. However, they did not support accessible open web services, making their data unusable in a rapid response situation.