forked from radiantearth/stac-site
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathcore.html
135 lines (115 loc) · 12.6 KB
/
core.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
<!DOCTYPE HTML>
<!--
Stellar by HTML5 UP
html5up.net | @ajlkn
Free for personal and commercial use under the CCA 3.0 license (html5up.net/license)
-->
<html>
<head>
<title>SpatioTemporal Asset Catalog Core Specification</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<!--[if lte IE 8]><script src="assets/js/ie/html5shiv.js"></script><![endif]-->
<link rel="stylesheet" href="assets/css/main.css" />
<!--[if lte IE 9]><link rel="stylesheet" href="assets/css/ie9.css" /><![endif]-->
<!--[if lte IE 8]><link rel="stylesheet" href="assets/css/ie8.css" /><![endif]-->
<link rel="apple-touch-icon" sizes="180x180" href="images/logo/favicon/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="images/logo/favicon/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="images/logo/favicon/favicon-16x16.png">
<link rel="manifest" href="images/logo/favicon/site.webmanifest">
<link rel="mask-icon" href="images/logo/favicon/safari-pinned-tab.svg" color="#5bbad5">
<link rel="shortcut icon" href="images/logo/favicon/favicon.ico">
<meta name="msapplication-TileColor" content="#da532c">
<meta name="msapplication-config" content="images/logo/favicon/browserconfig.xml">
<meta name="theme-color" content="#ffffff">
</head>
<body>
<!-- Wrapper -->
<div id="wrapper">
<!-- Header -->
<header id="header">
<h1>SpatioTemporal Asset Catalog Core Specification</h1>
<p>The core components of STAC</p>
</header>
<!-- Main -->
<div id="main">
<!-- Content -->
<section id="content" class="main">
<h2>Overview</h2>
<p>The <a href="https://github.com/radiantearth/stac-spec">STAC Specification</a> lives as
easily readable markdown pages on github, as the community aspires to keep STAC very approachable. So while this page gives a slightly deeper overview, don't hesitate to dive directly into the spec.</p>
<p>One thing to emphasize is that the specification is designed to be flexible and extensible. So if it seems a bit 'light', that is by design, so that different domains and tools can easily make it their own. The <b>extensions</b> section of the spec, detailed below, is where the community collaborates on more detail about specific data types and new functionality. Key to the STAC approach is JSON's extensibility. While the spec does provide JSON Schemas for validation (easily usable with online tools like <a href="https://staclint.com/">STACLint.com</a>), JSON validation won’t complain if you have extra fields, adding more fields allows you to support a variety of data types and implementations. Flexibility and extensibility is a core tenant of STAC.</p>
<h2>STAC Item</h2>
<p>Fundamental to any STAC, a STAC Item represents an atomic collection of inseparable data and metadata. A <b><a href="https://github.com/radiantearth/stac-spec/blob/master/item-spec/item-spec.md">STAC Item</a></b> is a <b><a href="http://geojson.org">GeoJSON</a> feature</b> and can be easily read by any modern GIS or geospatial library. The <b>STAC Item</b> JSON specification includes additional fields for:<ul>
<li>the time the asset represents;</li>
<li>a thumbnail for quick browsing;</li>
<li>asset links, links to the described data;</li>
<li>relationship links, allowing users to traverse other related <b>STAC Item</b>s.</li>
</ul>A <b>STAC Item</b> can contain additional fields and JSON structures to enable data providers to expose rich metadata and software developers to create intuitive tools.</p>
<h2>STAC Catalog</h2>
<p>The <b><a href="https://github.com/radiantearth/stac-spec/blob/master/catalog-spec/catalog-spec.md">STAC Catalog</a></b> provides a flexible structure to link various STAC Items together to be crawled or browsed. The spec is quite simple, just a JSON that:<ul>
<li>contains a list of STAC Items;</li>
<li>contains a list of child STAC Catalogs - allowing a hierarchical grouping of STAC Items.</li>
</ul></p>
<p>There are no restrictions on the way catalogs are organized. Most implementations use
a set of 'sub-catalogs' (a catalog that is linked to from another catalog) to group the items in some sensible way. It can be easily extended, for example to include additional metadata to further describe its holdings, as the STAC Collection does.</p>
<h2>STAC Collection</h2>
<p>A <b><a href="https://github.com/radiantearth/stac-spec/blob/master/collection-spec/collection-spec.md">STAC Collection</a></b> provides additional information about a spatio-temporal collection of data. It extends Catalog directly, layering on additional fields to enable description of things like the spatial and temporal extent of the data, the license, keywords, providers, etc. It in turn can easily be extended for additional
collection level metadata. It is used standalone by parts of the STAC community, as a lightweight way to describe data holdings.
<h2>STAC API</h2>
<p>The <b><a href="https://github.com/radiantearth/stac-spec/tree/master/api-spec">STAC API</a></b> specification is a bit different from the others. Instead of just specifying JSON and links that could be implemented with no moving parts, it defines a RESTful service interface for search. It dynamically generates a GeoJSON FeatureCollection of STAC Items in response to a user query.</p>
<p>The core of the spec is a single endpoint:</p>
<pre><code>/stac/search
</code></pre>
<p>It takes a JSON object that can filter on date and time:</p>
<pre><code>{
<span class="pl-s"><span class="pl-pds">"</span>bbox<span class="pl-pds">"</span></span>: [<span class="pl-c1">5.5</span>, <span class="pl-c1">46</span>, <span class="pl-c1">8</span>, <span class="pl-c1">47.4</span>],
<span class="pl-s"><span class="pl-pds">"</span>time<span class="pl-pds">"</span></span>: <span class="pl-s"><span class="pl-pds">"</span>2018-02-12T00:00:00Z/2018-03-18T12:31:12Z<span class="pl-pds">"</span></span>
}</code></pre>
<p>This tells the server to return all the catalog items it has that are from the second half of March, 2018 and
that intersect with this area:</p>
<p><img src="https://user-images.githubusercontent.com/407017/38382405-b5e69344-38be-11e8-90dc-35738678356d.png" alt="swiss_bbox" style="max-width:100%;"><em> (Map © OpenStreetMap contributors)</em></p>
<p>The return format is a <a href="http://geojson.org/" rel="nofollow">GeoJSON</a> FeatureCollection with features compliant with the
<a href="/radiantearth/stac-spec/blob/master/item-spec/item-spec.md">Item spec</a> for STAC. It returns to a limit optionally requested by the client, and includes
pageable links to iterate through any results past that limit.</p>
<p>STAC API has worked to align with the <a href="https://opengeospatial.org">OGC</a>'s <a href="https://github.com/opengeospatial/WFS_FES">WFS 3</a> specification, and ideally it evolves so as much of the STAC API functionality as possible is in WFS. For more about this see the <a href="faq.html">FAQ</a>.</p>
<h2 id="extensions">Extensions</h2>
<p name="extensions" id="extensions">While the core specification says nothing about particular types of data, the <a href="https://github.com/radiantearth/stac-spec/tree/master/extensions">extensions folder</a> is where one can find domain-specific fields that can be easily added to any STAC Item.
It is a place where any implementor can propose fields that are potentially more widely applicable than just their data. Each extension is labeled with a ‘maturity classification’ that lets others know how likely the extension is to change in the future.</p>
<p><a href="http://ithub.com/radiantearth/stac-spec/tree/master/extensions"><img src="https://raw.githubusercontent.com/radiantearth/stac-site/master/images/stac-extensions.png" style='height: 100%; width: 75%; object-fit: contain'></a></p>
The goal is to enable specific communities to work together to find a ‘good enough’ set of common metadata. </p>
<h2 id="static">Dynamic and Static Catalogs</h2>
<p>The final bit to draw attention to is the two different types of catalogs - static and dynamic.</p>
<ul>
<li>A <i>static catalog</i> is one that is implemented as a set of flat files on a web server or an object store like S3 or Google Cloud Storage.</li>
<li>A <i>dynamic catalog</i> is one that generates its responses dynamically, generally backed by some sort of server. </li>
</ul>
<p>The core Item, Catalog and Collection specs can be fully implemented by either, and the spec is designed to be agnostic to how it is implemented. This decision was made to make the lowest possible barrier to exposing data as STAC. For
many the simplest thing to do is to simply create files and put them online. But large data
providers like Planet and DigitalGlobe have already invested significant effort and resources in generating dynamic API’s and indexes for their customers to query their imagery holdings. For them it is actually easier to implement a dynamic STAC instead of
trying to re-architect their core platforms. But static catalogs have an additional use cases for large providers, enabling a fail safe point of truth. A static catalog can be generated from the dynamic index and stored on the cloud, and then can easily be used for disaster recovery, due to their incredibly high reliability of AWS S3 and Google Cloud Storage.</p>
<p> Client libraries like <a href="https://github.com/radiantearth/stac-browser">STAC Browser</a> are able to treat dynamic and static catalogs the same, as they both expose the exact same information. The one thing dynamic catalogs can do that static ones can't is offer the <code>/search/</code> endpoint. Though as the ecosystem of dynamic STAC servers improves it will be quite easy to use an off the shelf server to ingest the static catalog and provide a dynamic version of it to enable search.</p>
</section>
</div>
<!-- Footer -->
<footer id="footer">
<section>
<h2>Pull Requests Accepted</h2>
<p>The SpatioTemporal Asset Catalog project and website is fully community driven. If you want to help with the project see our <a href="how-to-help.html">How To Help</a> page. If something is not right on the website, or you would like to add more information or help make it better, then please contribute on <a href="https://github.com/radiantearth/stac-site">GitHub</a>.</p>
<ul class="actions">
<li><a href="how-to-help.html" class="button">Contribute</a></li>
</ul>
</section>
<p class="copyright"><a rel="license" href="http://creativecommons.org/licenses/by/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by/4.0/88x31.png" /></a><br />This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International License</a>. Design: <a href="https://html5up.net" target="_blank">HTML5 UP</a>.</p>
</footer>
</div>
<!-- Scripts -->
<script src="assets/js/jquery.min.js"></script>
<script src="assets/js/jquery.scrollex.min.js"></script>
<script src="assets/js/jquery.scrolly.min.js"></script>
<script src="assets/js/skel.min.js"></script>
<script src="assets/js/util.js"></script>
<!--[if lte IE 8]><script src="assets/js/ie/respond.min.js"></script><![endif]-->
<script src="assets/js/main.js"></script>
</body>
</html>