Skip to content

Commit 6478ae4

Browse files
authored
Merge pull request #95 from radiantearth/dev
Merging Dev to master
2 parents c6ab7ec + ff82501 commit 6478ae4

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

43 files changed

+3714
-2307
lines changed

.gitignore

Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
1+
# Logs
2+
logs
3+
*.log
4+
npm-debug.log*
5+
yarn-debug.log*
6+
yarn-error.log*
7+
8+
# Runtime data
9+
pids
10+
*.pid
11+
*.seed
12+
*.pid.lock
13+
14+
# Directory for instrumented libs generated by jscoverage/JSCover
15+
lib-cov
16+
17+
# Coverage directory used by tools like istanbul
18+
coverage
19+
20+
# nyc test coverage
21+
.nyc_output
22+
23+
# Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files)
24+
.grunt
25+
26+
# Bower dependency directory (https://bower.io/)
27+
bower_components
28+
29+
# node-waf configuration
30+
.lock-wscript
31+
32+
# Compiled binary addons (https://nodejs.org/api/addons.html)
33+
build/Release
34+
35+
# Dependency directories
36+
node_modules/
37+
jspm_packages/
38+
39+
# Typescript v1 declaration files
40+
typings/
41+
42+
# Optional npm cache directory
43+
.npm
44+
45+
# Optional eslint cache
46+
.eslintcache
47+
48+
# Optional REPL history
49+
.node_repl_history
50+
51+
# Output of 'npm pack'
52+
*.tgz
53+
54+
# Yarn Integrity file
55+
.yarn-integrity
56+
57+
# dotenv environment variables file
58+
.env
59+
60+
# next.js build output
61+
.next

api-spec/README.md

Lines changed: 75 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1,19 +1,81 @@
11

2-
# Catalog API Specification
2+
# SpatioTemporal Asset Catalog API Specification
33

4-
This folder specifies the dynamic version of SpatioTemporal Asset Catalog - the Catalog API. For now the complete
5-
definition is contained in the [spec.yaml](spec.yaml) file, which is an [OpenAPI](http://openapis.org) 2.0 (swagger)
6-
yaml document. In time more narrative will be added describing the decisions and recommendations on implementing
7-
the STAC API.
4+
## Overview
85

9-
The easiest way to explore the specification in a more human readable way is to load the file up in to the
10-
[online swagger editor](http://editor.swagger.io). You can import the spec by just selectiong 'file' ->
11-
'import url' and enter <https://raw.githubusercontent.com/radiantearth/stac-spec/dev/api-spec/spec.yaml>.
6+
A STAC API is the dynamic version of a SpatioTemporal Asset Catalog. It returns [STAC Items](../json-spec/json-spec.md)
7+
(GeoJSON objects with required links time stamp and links to assets) from search queries on a RESTful endpoint.
8+
9+
The core of the spec is a single endpoint:
10+
11+
```
12+
/search/stac
13+
```
14+
15+
It takes a JSON object that can filter on date and time:
16+
17+
```
18+
19+
{
20+
"bbox": [ 5.5, 46, 8, 47.4 ],
21+
"time": {
22+
"gt": "2018-03-15T00:00:00.000Z",
23+
"lt": "2018-04-01T00:00:00.000Z"
24+
}
25+
}
26+
```
27+
28+
This tells the server to return all the catalog items it has that are from the second half of March, 2018 and
29+
that fall within this area:
30+
31+
![swiss_bbox](https://user-images.githubusercontent.com/407017/38382405-b5e69344-38be-11e8-90dc-35738678356d.png)
32+
33+
*map © OpenStreetMap contributors*
34+
35+
The return format is a [GeoJSON](http://geojson.org) feature collection with features compliant with the
36+
[json spec]((../json-spec/json-spec.md) for STAC. It returns to a limit optionally requested by the client, and includes
37+
pageable links to iterate through any results past that limit.
38+
39+
## Specification
40+
41+
The definitive specification for STAC is the [OpenAPI](http://openapis.org) 3.0 yaml document. This is available
42+
in several forms. The most straightforward for an implementor new to STAC is the [STAC-standalone.yaml](STAC-standalone.yaml).
43+
This gives a complete service with the main STAC endpoint. See the [online documentation](https://app.swaggerhub.com/apis/cholmesgeo/STAC-standalone/0.4.0) for the api rendered interactively.
44+
45+
An OpenAPI 2.0 (swagger) version will be available soon, which can be useful for autogenerating client and server code.
46+
47+
##### Warning
48+
49+
**The latest spec has not yet been fully validated by actual implementations. This will come soon, but if you
50+
are new to STAC and are trying to use the spec we recommend you jump on the [stac gitter](https://gitter.im/SpatioTemporal-Asset-Catalog/Lobby)
51+
to get help**
52+
53+
### Filtering
54+
55+
The core STAC API includes two filters - Bounding Box and time. All STAC Items require space and time, and thus any STAC
56+
client can expect to be able to filter on them. Most data will include additional data that users would like to query on,
57+
so there is a mechanism to also specify more filters. See the [Filtering](filters.md) document for additional information
58+
on the core filters as well as how to extend them. It is anticipated that 'profiles' for domains (like earth observation
59+
imagery) will require additional fields to query their common fields.
60+
61+
### WFS 3.0 Integration
62+
63+
At the [Ft Collins Sprint](https://github.com/radiantearth/community-sprints/tree/master/03072018-ft-collins-co) the
64+
decision was made to integrate STAC with the [WFS 3 specification](https://github.com/opengeospatial/WFS_FES), as
65+
they are quite similar in spirit and intention. It is anticipated that most STAC implementations will also implement
66+
WFS, and indeed most additional functionality that extends STAC will be done as WFS extensions.
67+
68+
This folder thus also provides an [openapi fragment](STAC-fragment.yaml), as well as an [example service](https://app.swaggerhub.com/apis/cholmesgeo/STAC_WFS-example/0.4.0) ([yaml](WFS3core+STAC.yaml))
69+
for those interested in what a server that implements both STAC and WFS would look like. Those interested in learning more
70+
can read the [deeper discussion of WFS integration](wfs-stac.md).
71+
72+
73+
### GET requests
74+
75+
The POST endpoint is required for all STAC API implementations. The fields of the JSON object can also be used
76+
for a GET endpoint, which are included in the openapi specifications. The GET requests are designed to reflect the same
77+
fields as the POST fields, and are based on WFS 3 requests. It is recommended for implementations to implement both, but
78+
only POST is required.
1279

13-
This will display the documentation and examples for the specification. You can also generate code for
14-
clients and servers in a variety of languages from the editor as well, so you can get a sense of how it
15-
will work.
1680

17-
You can also use the yaml spec for code generation in a variety of tools.
1881

19-
Once OpenAPI 3.0 has more tooling support this spec will be migrated to that version of OpenAPI.

0 commit comments

Comments
 (0)