Skip to content

Latest commit

 

History

History
106 lines (84 loc) · 8.54 KB

sprint-background.md

File metadata and controls

106 lines (84 loc) · 8.54 KB
Raw

Introduction

This document serves as a summary of the background goals and work of the boulder sprint. It was a 3 day event, bringing together 24 people from 14 different organizations, aimed at collaboration around specifications that increase the interoperability of finding imagery and other captured geospatial information. See sprint-overview for more information on what happened at the sprint.

Background and goals

Many different software and data providers in the last few years have created RESTful JSON-based API's that enable searching of imagery and other geospatial assets - video, SAR, LiDAR, DEM's, etc. All enable searching by geography, time and at least a few other fields. And though they all do roughly the same thing each looks a bit different. And thus each requires specific code to be written to search its holdings - be it a javascript based GUI, a command line tool, or an integration in desktop software.

None of the providers saw the actual API as their core value proposition, but there was no good open standard that handled the search well. The OGC CS-W specification is built for online catalogs, but it does not handle tens of millions of records of imagery that well - it is more geared towards searching vector data layers in an SDI. The ebRIM profile of CS-W could handle more, but it's outdated and not accessible to modern web developers. The goal of most providers is to enable non-geo developers to sensible search the catalog.

Though the Open Geospatial Consortium is a logical place to collaborate on geospatial standards it has had a fairly out-dated way of collaborating - relying on word document editing and telecons, instead of github, markdown and OpenAPI specs (thankfully that has started to shift in a fairly major way, and the goal is to bring the work together). So it felt like the time was right to gather the developers who actually built the variety of services so they could share experiences and get to some solid specifications that everyone could implement. Radiant Earth emerged as a great neutral convener who was willing to sponsor an in-person meeting. Their goal is to help bring satellite imagery to NGO's and the developer world, and enabling all imagery holdings to be much more accessible through open standards is directly in line with their mission.

Having at least the initial meeting in person was essential, to enable high bandwidth exchange of information, and to also connect people to a community of others grappling with the same issues. The primary goal was to walk out of the meeting with a draft specification for searching imagery that every organization could implement over the next couple months. And to use that to attract more implementations, aiming to have a majority of the earth imagery assets in the world available through standardized search API's. But the goal is to not only develop one or two specifications, but to help build collaborative technological environment in the geospatial domain.

Prep

The first set of work for the sprint was to try to get everyone on the same page by sharing their implementations and experiences before meeting, so we could hit the ground running as much as possible. A number of organizations were already using Open API 2.0 as an internal tool to help document and design their API's for imagery search. So a repository was created for organizations to contribute their API specs (as OpenAPI 2.0) and an overview of their experience. See the implementations folder (from the state right before the sprint) to see the prep work done.

Early contributors included OpenAerialMap, RasterFoundry, Planet, Pixia and DigitalGlobe. There was also work to gather the various metadata that was in use by various providers. And a small group from Boundless andH exagon Geospatial also made a proposed draft based on WFS 3.0, as well as a functioning Java API for it from Boundless, and Hexagon got their internal system all ready to create a new API and connect to the same backend. There was also good discussion in Github issues for the metadata, with Matt Hanson raising a number of good points and spurring discussion.

Everyone participating was also divided in to workstreams, which each had a set of background reading and work to do. The other prep work that organizations did was to prepare a lightning talk, so that everyone could easily get a sense of what everyone else was working on and where they were coming from.

Organizations

There were 14 total organizations, representing a number of diverse perspectives:

  • Amazon hosts a number of Public Datasets of interest to the community including Landsat and Sentinel, that are ideal candidates for static catalog standards.
  • Azavea builds GeoTrellis, a high performancs scale-out raster processing engine, as well as RasterFoundry which builds UI and raster data storage on top of GeoTrellis.
  • BITS came, representing the NGA GEOINT Services perspective, particularly as a consumer of imagery catalogs, with a special emphasis on offline usage.
  • Boundless creates a full stack of open source geospatial software, and is interesting in both consuming imagery catalogs as well as adding the interface to their suite of tools.
  • DevSeed has been working on Sat-API to expose Landsat and Sentinel as a single API, leveraging Amazon technologies. Their Sat-search python client also consumes satellite imagery API's
  • DigitalGlobe is the largest company providing satellite imagery, and have built a number of imagery API's over the years. Their GBDX platform platform has the most modern API, and they also have teams consuming satellite imagery.
  • Element84 have built a bunch of NASA's imagery search API's, including a lot of work on CMR Search.
  • Google builds Earth Engine which has the largest repository of public earth observation data, and is exploring how to make it available to more than just Earth Engine users.
  • Harris's ENVI started life as a desktop imagery analysis tool, but now is a powerful set of cloud processing components. They build connectors to all the major imagery providers, bringing a great client-side perspective.
  • Hexagon Geospatial has a huge array of geospatial products. Their Erdas Apollo team was represented, which provides an imagery catalog API on top of any set of geospatial data holdings.
  • Humanitarian OpenStreetMap Team (HOT) builds Open Aerial Map which lets anyone host open imagery for disaster response and tracing in OSM, primarily from drones and satellites. They have a catalog API that powers their browser.
  • Planet has the most earth imagining satellites in space, and makes the data available through its Data API.
  • Pixia provides high performance video and imagery serving software, and has a catalog API for their users to search the holdings in the software.
  • Radiant Earth provides a geospatial and imagery technology platform built on RasterFoundry and other tools that aims to positively impact the developing world’s greatest social, economic and environmental challenges.