Merge pull request #150 from philvarner/pull-stac-spec-1.0.0

Pull stac spec 1.0.0

Author: philvarner

stac-spec/.circleci/config.yml

@@ -1,6 +1,6 @@
 version: 2
 jobs:
-  test_examples:
+  test_examples_node:
     working_directory: ~/stac
     docker:
       - image: circleci/node:12
@@ -12,6 +12,18 @@ jobs:
       - run:
           name: validate
           command: npm run check-examples
+  # test_examples_python:
+  #   working_directory: ~/stac
+  #   docker:
+  #     - image: circleci/python:3.8
+  #   steps:
+  #     - checkout
+  #     - run:
+  #         name: install
+  #         command: pip install stac-validator
+  #     - run:
+  #         name: validate
+  #         command: find ./examples -type f -name "*.json" | xargs -L1 stac_validator         
   test_docs:
     working_directory: ~/stac
     docker:
@@ -43,7 +55,8 @@ workflows:
   version: 2
   ci:
     jobs:
-      - test_examples
+      - test_examples_node
+      # - test_examples_python   
       - test_docs
       - publish_schemas:
           filters:

stac-spec/.circleci/rc.yaml

@@ -4,17 +4,15 @@ plugins:
 # Apply some recommended defaults for consistency
   - remark-preset-lint-consistent
   - remark-preset-lint-recommended
-# No HTML for security - can't activate yet due to STAC logo in README.md
-# - lint-no-html
+  - lint-no-html
 # General formatting
-#  - - remark-lint-emphasis-marker
-#    - '*'
+  - - remark-lint-emphasis-marker
+    - '*'
   - remark-lint-hard-break-spaces
   - remark-lint-blockquote-indentation
   - remark-lint-no-consecutive-blank-lines
-# Detect overly long lines - be liberal for now and don't restrict to 80 yet
-#  - - remark-lint-maximum-line-length
-#    - 150
+  - - remark-lint-maximum-line-length
+    - 150
 # Code
   - remark-lint-fenced-code-flag
   - remark-lint-fenced-code-marker
@@ -23,24 +21,23 @@ plugins:
     - 'fenced'
 # Headings
   - remark-lint-heading-increment
-  - remark-lint-no-duplicate-headings
   - remark-lint-no-multiple-toplevel-headings
   - remark-lint-no-heading-punctuation
   - - remark-lint-maximum-heading-length
     - 70
   - - remark-lint-heading-style
     - atx
+  - - remark-lint-no-shortcut-reference-link
+    - false
 # Lists
   - remark-lint-list-item-bullet-indent
   - remark-lint-ordered-list-marker-style
   - remark-lint-ordered-list-marker-value
   - remark-lint-checkbox-character-style
-#  - - remark-lint-unordered-list-marker-style
-#    - '-'
+  - - remark-lint-unordered-list-marker-style
+    - '-'
   - - remark-lint-list-item-indent
     - space 
 # Tables
   - remark-lint-table-pipes
-#  - remark-lint-table-pipe-alignment # Wait for https://github.com/remarkjs/remark-lint/issues/226  
-# Urls
   - remark-lint-no-literal-urls

stac-spec/.github/pull_request_template.md

@@ -10,5 +10,7 @@
 
 - [ ] This PR is made against the dev branch (all proposed changes except releases should be against dev, not master).
 - [ ] This PR has **no** breaking changes.
-- [ ] I have added my changes to the [CHANGELOG](https://github.com/radiantearth/stac-spec/blob/dev/CHANGELOG.md) **or** a CHANGELOG entry is not required.
-- [ ] This PR affects the [STAC API spec](https://github.com/radiantearth/stac-api-spec), and I have opened issue/PR #XXX to track the change.
+- [ ] I have added my changes to the [CHANGELOG](https://github.com/radiantearth/stac-spec/blob/dev/CHANGELOG.md)
+      **or** a CHANGELOG entry is not required.
+- [ ] This PR affects the [STAC API spec](https://github.com/radiantearth/stac-api-spec),
+      and I have opened issue/PR #XXX to track the change.

stac-spec/.remarkignore

@@ -14,21 +14,21 @@ appearance, race, religion, or sexual identity and orientation.
 Examples of behavior that contributes to creating a positive environment
 include:
 
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
 
 Examples of unacceptable behavior by participants include:
 
-* The use of sexualized language or imagery and unwelcome sexual attention or
+- The use of sexualized language or imagery and unwelcome sexual attention or
  advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic
  address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
+- Other conduct which could reasonably be considered inappropriate in a
  professional setting
 
 ## Our Responsibilities

stac-spec/CHANGELOG.md

@@ -24,28 +24,30 @@ require you to switch from the default of 'master', which we keep so it displays
 Creating a Pull Request will show our PR template, which includes checkbox reminders for a number
 of things.
 
-* Adding an entry the [CHANGELOG](CHANGELOG.md). If the change is more editorial and minor then this 
+- Adding an entry the [CHANGELOG](CHANGELOG.md). If the change is more editorial and minor then this 
 is not required, but any change to the actual specification should definitely have one.
-* Base the PR against dev, as mentioned above - even if the branch was made off of dev this reminds
+- Base the PR against dev, as mentioned above - even if the branch was made off of dev this reminds
 you to change the base in GitHub's PR creation page.
-* Make a ticket in the STAC API repo if anything here affects there.
-* Highlight if the PR makes breaking changes to the specification (in beta there can still be
+- Make a ticket in the STAC API repo if anything here affects there.
+- Highlight if the PR makes breaking changes to the specification (in beta there can still be
 select breaking changes, but after 1.0 this will change)
 
 All pull requests should submit clean markdown, which is checked by the continuous integration
 system. Please use `npm run check` locally, as described in the [next section](#check-files), 
 to ensure that the checks on the pull request succeed. If it does not then you can look at the
 mistakes online, which are the same as running `npm run check` locally would surface.
 
-All pull requests that modify or create JSON schema files or examples should use [JSON formatter](https://jsonformatter.org/) to keep files consistent across the repo. 
+All pull requests that modify or create JSON schema files or examples should use
+[JSON formatter](https://jsonformatter.org/) to keep files consistent across the repo. 
 
 All pull requests additionally require a review of two STAC core team members. Releases are cut
 from dev to master (and require 3 approvals), see the [process](process.md) document for more details.
 
 ### Check files
 
 The same check-markdown and check-examples programs that runs as a check on PR's is part of the repo and can be run locally. 
-To install you'll need npm, which is a standard part of any [node.js installation](https://nodejs.org/en/download/). Alternatively, you can also use [yarn](https://yarnpkg.com/) instead of npm. In this case replace all occurrences of `npm` with `yarn` below.
+To install you'll need npm, which is a standard part of any [node.js installation](https://nodejs.org/en/download/).
+Alternatively, you can also use [yarn](https://yarnpkg.com/) instead of npm. In this case replace all occurrences of `npm` with `yarn` below.
 
 First you'll need to install everything with npm once. Just navigate to the root of the stac-spec repo and on 
 your command line run:

stac-spec/CODE_OF_CONDUCT.md

@@ -1,3 +1,4 @@
+<!--lint disable no-html-->
 <img src="https://github.com/radiantearth/stac-site/raw/master/images/logo/stac-030-long.png" alt="stac-logo" width="700"/>
 
 [![CircleCI](https://circleci.com/gh/radiantearth/stac-spec.svg?style=svg)](https://circleci.com/gh/radiantearth/stac-spec)
@@ -13,7 +14,9 @@ including sources such as aircraft and drone and data such as hyperspectral opti
 synthetic aperture radar (SAR), video, point clouds, lidar, digital elevation 
 models (DEM), vector, machine learning labels, and composites like NDVI and 
 mosaics. STAC is intentionally designed with a minimal core and flexible 
-extension mechanism to support a broad set of use cases.
+extension mechanism to support a broad set of use cases. This specification 
+has matured over the past several years, and is used in [numerous production 
+deployments](https://stacindex.org/catalogs). 
 
 This is advantageous to providers of geospatial data, as they can simply use a
 well-designed, standard format and API without needing to design their own proprietary one.
@@ -42,22 +45,15 @@ with a well-defined set of additional attributes ("foreign members"). The **STAC
 extends the **[OGC API - Features - Part 1: Core](http://docs.opengeospatial.org/is/17-069r3/17-069r3.html)** 
 with additional web service endpoints and object attributes.
 
-## Stability Note
-
-This specification has matured over the past several years, and is used in 
-[numerous production deployments](https://stacindex.org/catalogs). 
-With the 1.0.0 release, implementors should expect that most definitions will remain 
-stable. Our goal
-is to maintain backwards-compatiblity within the core for a long time. 
-The STAC specification follows [Semantic Versioning](https://semver.org/), so once 
-1.0.0 is reached, any breaking change will require the spec to go to 2.0.0. 
-
 ## Current version and branches
 
 The [master branch](https://github.com/radiantearth/stac-spec/tree/master) is the 'stable' 
-version of the spec. It is currently version **1.0.0** of the specification. The 
-[dev](https://github.com/radiantearth/stac-spec/tree/dev) branch is where active development takes place, 
-and may have inconsistent examples. Whenever dev stabilizes, a release is cut and we 
+version of the spec. It is currently version **1.0.0** of the specification. The STAC specification 
+follows [Semantic Versioning](https://semver.org/), so any breaking change will require the spec to 
+go to 2.0.0. 
+
+The [dev](https://github.com/radiantearth/stac-spec/tree/dev) branch is where active development 
+takes place, and may have inconsistent examples. Whenever dev stabilizes, a release is cut and we 
 merge `dev` in to `master`. So `master` should be stable at any given time. 
 More information on how the STAC development process works can be found in 
 [process.md](process.md).
@@ -83,23 +79,24 @@ that enable clients to search for Item objects that match their filtering criter
 The **Item**, **Catalog**, **Collection**, and **STAC API** specifications are intended to be 
 used together, but are designed so each piece is small, self-contained, and reusable in other contexts.
 
-* **[Overview](overview.md)** describes the three core object type specifications and how they relate to one another.
-* **[Item Specification](item-spec/)** defines a STAC **Item**, which is a [GeoJSON](http://geojson.org) **Feature**
-with additional fields ("foreign members") for attributes like time and links to related entities and assets 
-(including thumbnails). This is the core entity that describes the data to be discovered.
-* **[Catalog Specification](catalog-spec/)** specifies a structure to link various STAC Items together to be crawled or browsed. It is a
-simple, flexible JSON file of links to Items, Catalogs or Collections that can be used in a variety of ways.
-* **[Collection Specification](collection-spec/)** provides additional information about a spatio-temporal collection of data.
-In the context of STAC it is most likely a related group of STAC Items that is made available by a data provider.
-It includes things like the spatial and temporal extent of the data, the license, keywords, etc.
-It enables discovery at a higher level than individual Item objects, providing a simple way to describe sets of data.
-* **[Examples](examples/):** The *[examples/](examples/)* folder contains examples for all three specifications, linked together to form two 
-complete examples. Each spec and extension links in to highlight particular files that demonstrate key concepts.
-* **[Extensions](extensions/README.md)** describe how STAC can use extensions that extend the functionality of the core spec or 
-add fields for specific domains. Extensions can be published anywhere, although the preferred location for public extensions is in the [GitHub `stac-extensions` organization](https://github.com/stac-extensions).
-* **Additional documents:** The supporting documents include a complementary [best practices](best-practices.md) 
-document, and information on contributing (links in the next section). We also maintain a [changelog](CHANGELOG.md) of
-what was modified in each version. 
+- **[Overview](overview.md)** describes the three core object type specifications and how they relate to one another.
+- **[Item Specification](item-spec/)** defines a STAC **Item**, which is a [GeoJSON](http://geojson.org) **Feature**
+  with additional fields ("foreign members") for attributes like time and links to related entities and assets 
+  (including thumbnails). This is the core entity that describes the data to be discovered.
+- **[Catalog Specification](catalog-spec/)** specifies a structure to link various STAC Items together to be crawled or browsed. It is a
+  simple, flexible JSON file of links to Items, Catalogs or Collections that can be used in a variety of ways.
+- **[Collection Specification](collection-spec/)** provides additional information about a spatio-temporal collection of data.
+  In the context of STAC it is most likely a related group of STAC Items that is made available by a data provider.
+  It includes things like the spatial and temporal extent of the data, the license, keywords, etc.
+  It enables discovery at a higher level than individual Item objects, providing a simple way to describe sets of data.
+- **[Examples](examples/):** The *[examples/](examples/)* folder contains examples for all three specifications, linked together to form two 
+  complete examples. Each spec and extension links in to highlight particular files that demonstrate key concepts.
+- **[Extensions](extensions/README.md)** describe how STAC can use extensions that extend the functionality of the core spec or 
+  add fields for specific domains. Extensions can be published anywhere,
+  although the preferred location for public extensions is in the [GitHub `stac-extensions` organization](https://github.com/stac-extensions).
+- **Additional documents:** The supporting documents include a complementary [best practices](best-practices.md) 
+  document, and information on contributing (links in the next section). We also maintain a [changelog](CHANGELOG.md) of
+  what was modified in each version. 
 
 ## Contributing