Merge branch 'dev' of https://github.com/radiantearth/stac-spec into …

…proposed_static_spec

README.md

@@ -1,13 +1,36 @@
 ## About
 
-The Spatio-Temporal Asset Catalog (STAC) specification aims to standardize the way geospatial assets are exposed online and queried. A 'spatio-temporal asset' is any file that represents information about the earth captured in a certain space and 
+The SpatioTemporal Asset Catalog (STAC) specification aims to standardize the way geospatial assets are exposed online and queried. A 'spatiotemporal asset' is any file that represents information about the earth captured in a certain space and 
 time. The initial focus is primarily remotely-sensed imagery (from satellites, but also planes, drones, balloons, etc), but 
 the core is designed to be extensible to SAR, full motion video, point clouds, hyperspectral, LiDAR and derived data like
 NDVI, Digital Elevation Models, mosaics, etc. 
 
-The goal is for all major providers of imagery and other earth data to expose their data as spatio-temporal asset catalogs,
+The goal is for all major providers of imagery and other earth data to expose their data as spatiotemporal asset catalogs,
 so that new code doesn't need to be written whenever a new JSON-based REST API comes out that makes its data available in a slightly different way. This will enable standard library components in many languages.
 
+## WARNING
+
+The specification is currently in a fairly incomplete state, as there were a few open questions from the 
+[boulder sprint](https://github.com/radiantearth/boulder-sprint) that need to be resolved, with the various related
+specifications moved over, updated and synchronized. 
+
+The top things to be done are:
+
+* Move static catalog work from [boulder sprint repo](https://github.com/radiantearth/boulder-sprint/tree/master/specs/flat_file) to this repo. - [#26](https://github.com/radiantearth/stac-spec/issues/26)
+* Compare [core-api-examples](https://github.com/radiantearth/boulder-sprint/tree/master/specs/core-api) with each other 
+to get to a final decision on Item & Asset JSON - [#24](https://github.com/radiantearth/stac-spec/issues/24)
+* Finalize link structure between assets & items - [#22](https://github.com/radiantearth/stac-spec/issues/22)
+* Decide how to describe "Product" level information for Assets and Items - [#23](https://github.com/radiantearth/stac-spec/issues/23)
+* Update specs & json examples to the 'Items'/'Item'/'Asset', as well as updates from previous items - [#27](https://github.com/radiantearth/stac-spec/issues/27)
+* Align catalog API swagger spec with static catalog / stam JSON and return types. - [#29](https://github.com/radiantearth/stac-spec/issues/29)
+
+Once the core things are done we can release a named version and then aim to get many more people to implement. 
+
+If you did not participate in the boulder sprint but want to help out with the above tasks then join us 
+on [our gitter](https://gitter.im/Imagery-Catalog-API-Team/Lobby)
+
+
+
 ## Design Overview
 
 An important core principle of the STAC design is to embrace best practices of making data available on the web (like 
@@ -23,17 +46,17 @@ no moving parts, no clusters or databases to maintain. The goal of STAC is to ex
 possible, so the static catalog offers a very lower barrier to entry for anyone with geospatial assets to make their data 
 searchable.
 
-#### Active Catalog
+#### Catalog API
 
-An active catalog is a RESTful API that responds to queries (like give me all imagery in Oahu gathered on January 15, 2017). 
+A catalog API is a RESTful API that responds to queries (like give me all imagery in Oahu gathered on January 15, 2017). 
 But its structure and responses are designed to mirror the static catalog, so the same client and crawler tools can consume
 it. It generally indexes data for efficient responses, and aims to be easy for existing API's to implement as a more standard
 interface for clients to consume. It is specified in OpenAPI 2.0 (swagger), and will move to OpenAPI 3.0 once the codegen
 tooling is stronger there. An active catalog will often be populated by a static catalog, or at least may have a 'backup' of
 
 #### Core Metadata and Profiles
 
-The Spatio-Temporal Asset Metadata specification defines the core fields that all assets must make available for searching
+The SpatioTemporal Asset Metadata specification defines the core fields that all assets must make available for searching
 in a catalog. Vendors can extend those core fields for the metadata they want to make available, and the community is 
 starting to define shared profiles, with 'earth observation' (satellite imagery) being the first one. This repo has the
 json profile of STAM, so it can evolve with the rest of the STAC spec more easily.
@@ -46,7 +69,7 @@ of key decisions.
 
 The best way to contribute is to try to implement the specification and give feedback on what worked well and what could be
 improved. Currently there are a few major things to still work out, so if you are interested in implementing you should
-jump on our [gitter channel](https://gitter.im/Imagery-Catalog-API-Team/Lobby#) (TODO: update this link?) and check in 
+jump on our [gitter channel](https://gitter.im/SpatioTemporal-Asset-Catalog/Lobby) (TODO: update this link?) and check in 
 on how ready the spec is and how you can support it. For the next bit of time you'll probably be encouraged to just do what
 feels best in some areas, so we can capture best practices and standardize.
 

implementations.md

@@ -0,0 +1,41 @@
+# Implementations
+
+This document lists the various implementations of the SpatioTemporal Asset Catalog specification. Contributions 
+to the spec should be based on experience building API's for imagery and other geo-asset catalogs, so suggested
+changes / improvements to the spec should be based on some software listed here. All listed implementations 
+should have a link to a live server or static catalog that indexes real data, though they do not have to 
+production ready or have any guarantee of uptime. If a live server is not possible then a link to open source code 
+is also acceptable. 
+
+## Catalog Links
+This section is links to live catalogs (both static and active) that have data.
+
+* None available yet - spec is too new.
+
+#### Proto-catalogs
+[Open Imagery Network](https://openimagerynetwork.github.io/) was the first attempt at a static catalog. The OpenAerialMap 
+bucket is in active use. It is planned to evolve OIN and OAM architectures to use static catalogs.
+
+[AWS Public Datasets](aws.amazon.com/public-datasets/), particularly [Landsat](aws.amazon.com/public-datasets/landsat/), 
+[NAIP](https://aws.amazon.com/public-datasets/naip/) and [Sentinel](http://sentinel-pds.s3-website.eu-central-1.amazonaws.com/) all
+get close to the ideas of STAC static catalogs, and hopefully will evolve to implement the standard.
+
+
+## Static Catalog Implementations
+
+These are pieces of software that can crawl and/or produce static catalogs.
+
+The [Catalog Crawler](https://github.com/radiantearth/boulder-sprint/tree/master/catalog-crawler) was done during the
+[Boulder Sprint](https://github.com/radiantearth/boulder-sprint/), as an early proof of concept.
+
+## Active Catalog Implementations
+
+Element84 made a [clojure implementation](https://github.com/Element84/catalog-api-spec/tree/dev/implementations/e84) of the spec
+that serves as a lightweight proxy to NASA's CMR, constrained to just data in USGS EROS. 
+
+Josh Fix's [open-catalog](https://github.com/joshfix/open-catalog) demonstrates generating code from the core swagger spec.
+
+### Proto-software
+
+Information about the software implementations that have been informing the evolution of the specification can be found at
+https://github.com/radiantearth/catalog-implementor-survey