Query polish

CHANGELOG.md

@@ -6,6 +6,57 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
 
 ## Unreleased
 
+### Added
+- ItemCollection requires `stac_version` field, `stac_extensions` has also been added
+- A `description` field has been added to Item assets (also Asset definitions extension). 
+- Extensions:
+     - [Version Indicators extension](extensions/version/README.md), adds `version` and `deprecated` fields to STAC Items and Collections
+     - Instrument extension, adds fields: `platform`, `instruments`, `constellation` (all moved from EO and SAR extensions), and `mission`
+     - Data Cube extension can be used in Collections, added new field `description`
+     - Added `description` and `roles` fields to the Asset in the [Asset Extension](extensions/asset/README.md)
+- STAC API:
+     - Added the [Item and Collection API Version extension](api-spec/extensions/version/README.md) to support versioning in the API specification
+
+### Changed
+- Support for [CommonMark 0.29 instead of CommonMark 0.28](https://spec.commonmark.org/0.29/changes.html)
+- Collection field `property` and the merge ability moved to a new extension 'Commons'
+- Added attribute `roles` to Item assets (also Asset definitions extension), to be used similarly to Link `rel`.
+- Updated API yaml to clarify bbox filter should be implemented without brackets. Example: `bbox=160.6,-55.95,-170,-25.89`
+- Collection `summaries` merge array fields now.
+
+- Extensions:
+    - [datetime-range extension](extensions/datetime-range/README.md): Removed extension prefix from example and schema
+    - Data Cube extension: Changed allowed formats (removed PROJ string, added PROJJSON / WKT2) for reference systems
+    - [Checksum extension](extensions/checksum/README.md) is now using self-identifiable hashes ([Multihash](https://github.com/multiformats/multihash))
+    - Changed `sar:type` to `sar:product_type` and `sar:polarization` to `sar:polarizations` in the [SAR extension](extensions/sar/README.md)
+- STAC API:
+    - The endpoint `/stac` has been merged with `/`
+    - The endpoint `/stac/search` is now called `/search`
+    - Sort Extension - added non-JSON query/form parameter format
+    - Fields extension has a simplified format for GET parameters
+    - `search` extension renamed to `context` extension. JSON object renamed from `search:metadata` to `context`
+    - Removed "next" from the search metadata and query parameter, added POST body and headers to the links for paging support
+    - Query Extension - type restrictions on query predicates are more accurate, which may require additional implementation support. 
+
+### Removed
+- Removed `version` field in STAC Collections. Use [Version Extension](extensions/version/README.md) instead
+- Removed `summaries` field from Catalogs. Use Collections instead
+- Extensions:
+    - Removed `eo:platform`, `eo:instrument`, `eo:constellation` from EO extension, and `sar:platform`, `sar:instrument`, `sar:constellation` from the [SAR extension](extensions/sar/README.md)
+    - Removed `sar:absolute_orbit` and `sar:center_wavelength` fields from the [SAR extension](extensions/sar/README.md)
+    - Removed `data_type` and `unit` from the `sar:bands` object in the [SAR extension](extensions/sar/README.md)
+    - Removed `dtr` extension prefix from example and schema in [datetime-range extension](extensions/datetime-range/README.md)
+- Asset Types (pre-defined values for the keys of individual assets, *not* media types) in Items. Use the asset's `roles` instead.
+- `license` field doesn't allow SPDX expressions any longer. Use `various` and links instead.
+- STAC API:
+    - Removed "next" from the search metadata and query parameter, added POST body and headers to the links for paging support
+
+### Fixed
+
+- The `license` field in Item and Collection spec explicitly mentions that the value `proprietary` without a link means that the data is private.
+- Clarified how to fill `stac_extensions`.
+- More clarifications; typos fixed
+
 ## [v0.8.1] - 2019-11-01
 
 ### Changed
@@ -61,7 +112,6 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
     - moved label:overview to be a list of Overview Objects from a single Overview Object in spec markdown and json schema (matching previous example JSON).
     - Renamed fields to use plural forms (`label:property` -> `label:properties`, `label:task` -> `label:tasks`, `label:method` -> `label:methods` and `label:overview` -> `label:overviews`)
 
-
 ## [v0.7.0] - 2019-05-06
 
 ### Fixed

README.md

@@ -82,30 +82,40 @@ An important core principle of the STAC design is to embrace best practices of m
 to leverage the reliability of flat files on object stores like [AWS S3](https://aws.amazon.com/s3/) and [Google Cloud Storage](https://cloud.google.com/storage/).
 This lead to designing a static catalog at the core of the STAC spec.
 
+### Catalog Types
+
+STAC Catalogs generally fall into two different types: Static Catalogs and Dynamic Catalog APIs.
+
+The two catalog types both implement the same fields and links, and can be treated as the same by clients.
+For more details on the two types see the chapters below. Additionally, consider the [Static and Dynamic Catalogs](../best-practices.md#static-and-dynamic-catalogs)
+section of the best practices document on how you might use them best.
+
 #### Static Catalog
 
-A static catalog is an implementation of the STAC specification that does not respond dynamically to requests - it is simply
-a set of files on a web server that link to one another in a way that can be crawled. A static catalog can only really be
-crawled by search engines and active catalogs; it can not respond to queries. But it is incredibly reliable, as there are
-no moving parts, no clusters or databases to maintain. The goal of STAC is to expose as much asset metadata online as 
-possible, so the static catalog offers a very lower barrier to entry for anyone with geospatial assets to make their data 
-searchable.
+A static catalog is an implementation of the STAC specification that does not respond dynamically to requests. It is simply
+a set of files on a web server that link to one another in a way that can be crawled, often stored in an cloud storage
+service like [Amazon S3](https://aws.amazon.com/s3/) or [Google Cloud Storage](https://cloud.google.com/storage/).
+The core JSON documents and link structures are encoded in the file, and work as long as things are structured properly.
+A static catalog can only really be crawled by search engines and active catalogs; it can not respond to queries.
+But it is incredibly reliable, as there are no moving parts, no clusters or databases to maintain.
+The goal of STAC is to expose as much asset metadata online as possible, so the static catalog offers a very lower
+barrier to entry for anyone with geospatial assets to make their data searchable.
 
-#### Catalog API
+#### Dynamic Catalog API
 
-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
+A dynamic catalog API is implemented in software as a RESTful API that responds to queries (like give me all imagery in Oahu gathered on January 15, 2017). 
+Its structure and responses are usually generated dynamically and 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 APIs to implement as a more standard
 interface for clients to consume. It is specified in OpenAPI 3.0. An active catalog will often be populated by a static catalog,
 or at least may have a 'backup' of its fields stored as a cached static catalog.
 
-#### Core Metadata and Extensions
+### Core Metadata and Extensions
 
 The Item specification defines the core fields that all assets must make available for searching in a catalog.
 In addition there are some basic fields for describing collections of data.
 Vendors can extend those core fields for the metadata they want to make available, and the community has started to define shared extensions.
 
-#### UML Diagram
+### UML Diagram
 
 A UML diagram of the [STAC model](STAC-UML.pdf) is provided to help with navigating the specification.