Astro Dynamic STAC Blueprint 
An opinionated framework that extends the STAC Specification.
Overview
As Astro Dynamic has been building the Data Sphere platform, it has adopted the STAC Specification as the standard format for all meta data. It's a well made open specification, designed to be light weight, flexible, and extensible, able to adapt to the growing needs and applications of the geospatial sector. Additionally, it is in an easy to use format, that is being widely adopted by much of the industry. The benefits of STAC have been clear to see, but there are some areas where we feel there could be alterations, but arguably contradict some of ideals of the specification. Therefore, we decided to create our own optional "flavour" of the specification to use with Data Sphere.
Justification
With STAC's flexible and open nature, users are encouraged to structure their catalogs and collections as they see fit, as well as only being required to include some fields the specification identifies. Whilst this is beneficial in making STAC very flexible, it does make variance between different providers significant. For example, the structure of collections and catalogs can differ significantly, with some being grouped by instrument whilst others are grouped by year only. This works fine if a STAC catalog is only used internally and the method of organisation is well defined. However, for data discoverability and presenting data to end users, this can be confusing as there is no common user experience between providers.
This can also be applied to the fields of an item, collection or catalog. Since there are only a few fields required by the specification, the meta data content can vary greatly between items in different catalogs, sometimes from the same provider. Granted that sometimes this data is not always available to the provider, it still leaves users with ambiguity of whether the data they will be getting, contains the meta data they may require.
For Astro Dynamic specifically, while building Data Sphere, our biggest problem was missing fields (which we consider to be key), items not conforming to STAC Schemas, and the plethora of methods to organise catalogs. This led to it becoming increasingly more challenging to present a consistent user experience.
Goal
To address the challenges, we built a Blueprint for our items, collections and catalogs to follow. Our goal was to make introduce more rigidity to the specification, whilst maintaining some of its core benefits. We use the word Blueprint instead of Specification since we are bringing together elements from the STAC Core and STAC Extensions, rather than creating anything new. It was important to us that we don't use the word specification loosely and diminish the hard work of the creators of STAC.
With our goal of adding rigidity and structure in mind, the AD STAC Blueprint aims to provide :
- Stricter naming conventions
- Adherence to STAC best practices
- Common organisation structure to catalogs
- Extensions as requirements
We also want this Blueprint to be optional to follow. That is, to contribute data products to Data Sphere, you will not be required to comply with the Blueprint. It is still in its early stages and will be growing with our capabilities and with the feedback of the community. The Blueprint will be used across Data Sphere to help with decisions regarding quality assurance (see the Quality Award Standard), as well as providing a cohesive user experience when searching datasets. This will be done automatically, requiring you to do no work at all.
As such, this Blueprints serves as a reference point for contributors, to see how their products will be represented when included on Data Sphere, and what meta data is most important to our users.
Blueprint
The Blueprint directly references the STAC Specification, with us defining changes made rather than defining a complete list of fields. You MUST read the STAC Specification as well as the Blueprint for correct implementation.
Catalog Organisation
Note
The catalog organisation is still being developed and is very likely to change. We would appreciate any feedback on the catalog organisation as it is a key area for us.
Each organisations STAC Catalog will be organised by a common method to make traversal easier for people and machines. The root of every organisation will be a catalog containing sub-catalogs or collections. Collections will be sorted by common data amongst Items. The structure will differ by what fields an organisation has available to them, but it should follow this hierarchy.
- Constellation
- Mission
- Platform
- Gregorian Calendar Year
- Gregorian Calendar Month
A mission is flexible in it's definition, although it should follow the rough guide set out in the STAC specification. However, a mission MUST always be a collection of related tasks performed by one or more platforms. If a mission only has one platform, (and will only have one platform in future) then a sub-collection for the platform does not need to be made, and calendar month/year collections can be sub-catalogs of the mission collection.
This tree diagram shows how an organisation's catalog could be organised using the hierarchy provided above.
Item
The Item has been extended to include the Electro-Optical or SAR Extension, View Extension, and Projection Extension. We have also made many of the link relations requirements now instead of optional to clearly establish where the item belongs.
Link Structure
This defines the type a link relation should be as well of how it is grouped. For instance, an Item's parent MUST be a Collection and not a Catalog.
| Link Relation | Type |
|---|---|
| Parent | Collection |
| Child | None |
| Root | Catalog |
| Grouped By | Parent Collection |
Change Table
| Field | Change |
|---|---|
| Properties Object : title | Required |
| Links Object : rel : self | Required |
| Links Object : rel : root | Required |
| Links Object : rel : parent | Required |
| Links Object : rel : collection | Required |
| Links Object : rel : preview | Required. Must be PNG/JPEG. Can be Tiff if PNG/JPEG not available. |
| Assets Object : title | Required |
| Assets Object : type | Required |
| Assets Object : roles | Required. Must be a standard role. "overview" reserved for .tiff media types. |
| Extension : EO | Required if Optical Imagery. Version 1.1.0 or higher. |
| Extension : EO : cloud_cover | Required |
| Extension : EO : Band Object | Required |
| Extension : EO : name | Required |
| Extension : EO : common_name | Required. Must follow the list of common names given in EO extension. |
| Extension : View | Required. Version 1.0.0 or higher. |
| Extension : View : off_nadir | Required |
| Extension : View : azimuth | Required |
| Extension : View : incidence_angle | Required |
| Extension : Proj | Required. Version 1.1.0 or higher. |
| Extension : Proj : epsg / wkt2 / projjson | At least One Required. |
| Extension : Proj : shape | Required |
| Extension : Proj : transform | Required |
| Extension : SAR | Required if SAR Imagery. Version 1.0.0 or higher |
| Extension : SAR : instrument_mode | Required |
| Extension : SAR : frequency_band | Required |
| Extension : SAR : polarizations | Required |
| Extension : SAR : center_frequency | Required |
| Extension : SAR : resolution_range | Required |
| Extension : SAR : looks_range | Required |
Example
{
"stac_version": "1.0.0",
"stac_extensions": [
"https://stac-extensions.github.io/eo/v1.0.0/schema.json",
"https://stac-extensions.github.io/projection/v1.0.0/schema.json",
"https://stac-extensions.github.io/view/v1.0.0/schema.json",
"https://stac-extensions.github.io/sat/v1.0.0/schema.json"
],
"type": "Feature",
"id": "20201211_223832_CS2",
"bbox": [
172.91173669923782,
1.3438851951615003,
172.95469614953714,
1.3690476620161975
],
"geometry": {
"type": "Polygon",
"coordinates": [
[
[
172.91173669923782,
1.3438851951615003
],
[
172.95469614953714,
1.3438851951615003
],
[
172.95469614953714,
1.3690476620161975
],
[
172.91173669923782,
1.3690476620161975
],
[
172.91173669923782,
1.3438851951615003
]
]
]
},
"properties": {
"datetime": "2020-12-11T22:38:32.125000Z",
"created": "2020-12-12T01:48:13.725Z",
"updated": "2020-12-12T01:48:13.725Z",
"instruments": [
"cool_sensor_v1"
],
"view:off_nadir": 0,
"view:incidence_angle": 90,
"view:azimuth": 23.9,
"view:sun_elevation": 45.0,
"view:sun_azimuth": 56.4,
"gsd": 0.66,
"eo:cloud_cover": 1.2,
"eo:snow_cover": 0
"proj:epsg": 32659,
"proj:shape": [
5558,
9559
],
"proj:transform": [
0.5,
0,
712710,
0,
-0.5,
151406,
0,
0,
1
],
},
"collection": "simple-collection",
"links": [
{
"rel": "collection",
"href": "./collection.json",
"type": "application/json",
"title": "Simple Example Collection"
},
{
"rel": "root",
"href": "./Catalog.json",
"type": "application/json",
"title": "Organisation Catalog"
},
{
"rel": "parent",
"href": "./collection.json",
"type": "application/json",
"title": "Simple Example Collection"
}
],
"assets": {
"visual": {
"href": "https://storage.googleapis.com/open-cogs/stac-examples/20201211_223832_CS2.tif",
"type": "image/tiff; application=geotiff; profile=cloud-optimized",
"title": "3-Band Visual",
"roles": [
"visual"
],
"eo:bands": [
{
"name": "band1",
"common_name": "blue",
"center_wavelength": 0.47,
"full_width_half_max": 0.07,
"solar_illumination": 1959.66
},
{
"name": "band2",
"common_name": "green",
"center_wavelength": 0.56,
"full_width_half_max": 0.08,
"solar_illumination": 1823.24
},
{
"name": "band3",
"common_name": "red",
"center_wavelength": 0.645,
"full_width_half_max": 0.09,
"solar_illumination": 1512.06
},
{
"name": "band4",
"common_name": "nir",
"center_wavelength": 0.8,
"full_width_half_max": 0.152,
"solar_illumination": 1041.63
}
]
},
"thumbnail": {
"href": "https://storage.googleapis.com/open-cogs/stac-examples/20201211_223832_CS2.jpg",
"title": "Thumbnail",
"type": "image/jpeg",
"roles": [
"thumbnail"
]
}
}
}
Collection
Collections are encouraged to include extensions fields that are common amongst all the child items, such as the Projection EPSG, to remove the need to include them in every item.
Note
We are in the process of updating the collection to be compliant for real time data. We understand that the extent object will not be able to be completed whilst data is being added a collection in real time.
Link Structure
This defines the type a link relation should be as well of how it is grouped.
| Link Relation | Type |
|---|---|
| Parent | Catalog, Collection |
| Child | Collection, Item |
| Root | Catalog |
| Grouped By | Mission, Constellation, Platform, Month. |
Change Table
| Field | Change |
|---|---|
| Standalone Collections | Must Link to Child Collections |
| stac_version | Do not mix STAC versions within a collection. |
| stac_extensions | Required |
| license | Required |
| title | Required |
| providers | Required. Must have at least one provider in the "Provider Object". This provider can be any role. |
| providers : roles | Required. Must be one or more of the roles listed in Providers Object spec. |
| Extent Object : spatial | |
| Extent Object : temporal | |
| Extension : sat | Required on platform collection level of organisation. |
| Extension : EO | Only if common amongst all items |
| Extension : EO : name | Only if common amongst all items |
| Extension : EO : common_name | Only if common amongst all items. Must follow the list of common names given in EO extension. |
| Extension : View | Only if common amongst all items |
| Extension : Proj | Only if common amongst all items |
| Extension : Proj : epsg, wkt2, projjson | Only if common amongst all items. Required to have at least one the fields, epsg, wkt2, projjson, not Null. |
| Extension : SAR | Only if common amongst all items. Required if SAR Imagery |
Example
{
"id": "simple-collection",
"type": "Collection",
"stac_extensions": [
"https://stac-extensions.github.io/eo/v1.0.0/schema.json",
"https://stac-extensions.github.io/projection/v1.0.0/schema.json",
"https://stac-extensions.github.io/view/v1.0.0/schema.json",
"https://stac-extensions.github.io/sat/v1.0.0/schema.json"
],
"stac_version": "1.0.0",
"description": "A simple collection demonstrating core catalog fields with links to a couple of items",
"title": "Simple Example Collection",
"providers": [
{
"name": "Remote Data, Inc",
"description": "Producers of awesome spatiotemporal assets",
"roles": [
"producer",
"processor"
],
"url": "http://remotedata.io"
}
],
"extent": {
"spatial": {
"bbox": [
[
172.91173669923782,
1.3438851951615003,
172.95469614953714,
1.3690476620161975
]
]
},
"temporal": {
"interval": [
[
"2020-12-11T22:38:32.125Z",
"2020-12-14T18:02:31.437Z"
]
]
}
},
"license": "CC-BY-4.0",
"summaries": {
"platform": [
"cool_sat1",
"cool_sat2"
],
"constellation": [
"ion"
],
"instruments": [
"cool_sensor_v1",
"cool_sensor_v2"
],
"gsd": {
"minimum": 0.512,
"maximum": 0.66
},
"eo:cloud_cover": {
"minimum": 1.2,
"maximum": 1.2
},
"proj:epsg": {
"minimum": 32659,
"maximum": 32659
},
"view:sun_elevation": {
"minimum": 54.9,
"maximum": 54.9
},
"view:off_nadir": {
"minimum": 3.8,
"maximum": 3.8
},
"view:sun_azimuth": {
"minimum": 135.7,
"maximum": 135.7
},
},
"links": [
{
"rel": "root",
"href": "./catalog.json",
"type": "application/json",
"title": "Organisation Catalog"
},
{
"rel": "child",
"href": "./cool_sat1_collection/collection.json",
"type": "application/json",
"title": "Cool Sat 1 Collection"
},
{
"rel": "child",
"href": "./cool_sat2_collection/collection.json",
"type": "application/json",
"title": "Cool Sate 2 Collection"
},
{
"rel": "self",
"href": "https://raw.githubusercontent.com/radiantearth/stac-spec/v1.0.0/examples/collection.json",
"type": "application/json"
}
]
}
Catalog
Catalogs are now reserved for holding other collections. They can be used to hold extra meta data common amongst all collections.
Links Structure
This defines the type a link relation should be as well of how it is grouped.
| Link Relation | Type |
|---|---|
| Parent | None, Catalog |
| Child | Catalog, Collection |
| Root | Self, Catalog |
| Grouped By | Organisation |
Change Table
| Field | Change |
|---|---|
| title | Required |
| Link Object : rel : item | Not allowed. Catalogs are only allowed to link to collections or sub-catalogs. |
| Link Object : rel : self | Required |
| Link Object : rel : root | Required. This can be the same as self if the catalog is root. |
| Link Object : type | Must be application/json, as all catalogs link to collections/sub-catalogs |
| Owner | Required. The organisation that has curated the Catalog and all it's child elements. |
Example
{
"id": "examples",
"type": "Catalog",
"title": "Example Catalog",
"stac_version": "1.0.0",
"description": "This catalog is a simple demonstration of an example catalog that is used to organize a hierarchy of collections and their items.",
"links": [
{
"rel": "root",
"href": "./catalog.json",
"type": "application/json"
},
{
"rel": "child",
"href": "./mission_A_collection/collection.json",
"type": "application/json",
"title": "Collection For Mission A"
},
{
"rel": "child",
"href": "./mission_B_collection/collection.json",
"type": "application/json",
"title": "Collection For Mission B"
},
{
"rel": "self",
"href": "https://raw.githubusercontent.com/radiantearth/stac-spec/v1.0.0/examples/catalog.json",
"type": "application/json"
}
]
}