stac-spec
SpatioTemporal Asset Catalog specification - making geospatial assets openly searchable and crawlable
Science Score: 54.0%
This score indicates how likely this project is to be science-related based on various indicators:
-
✓CITATION.cff file
Found CITATION.cff file -
✓codemeta.json file
Found codemeta.json file -
✓.zenodo.json file
Found .zenodo.json file -
○DOI references
-
○Academic publication links
-
✓Committers with academic emails
1 of 71 committers (1.4%) from academic institutions -
○Institutional organization owner
-
○JOSS paper metadata
-
○Scientific vocabulary similarity
Low similarity (15.3%) to scientific vocabulary
Keywords
Keywords from Contributors
Repository
SpatioTemporal Asset Catalog specification - making geospatial assets openly searchable and crawlable
Basic Info
- Host: GitHub
- Owner: radiantearth
- License: apache-2.0
- Language: JavaScript
- Default Branch: master
- Homepage: https://stacspec.org
- Size: 7.91 MB
Statistics
- Stars: 849
- Watchers: 73
- Forks: 183
- Open Issues: 35
- Releases: 26
Topics
Metadata Files
README.md
About
The SpatioTemporal Asset Catalog (STAC) family of specifications aim to standardize the way geospatial asset metadata is structured and queried. A "spatiotemporal asset" is any file that represents information about the Earth at a certain place and time. The original focus was on scenes of satellite imagery, but the specifications now cover a broad variety of uses, including sources such as aircraft and drone and data such as hyperspectral optical, 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. This specification has matured over the past several years, and is used in numerous production deployments.
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. This is advantageous to consumers of geospatial data, as they can use existing libraries and tools to access metadata, instead of needing to write new code to interact with each data provider's proprietary formats and APIs.
The STAC specifications define related JSON object types connected by link relations to support a HATEOAS-style traversable interface and a RESTful API providing additional browse and search interfaces. Typically, several STAC specifications are composed together to create an implementation. The Item, Catalog, and Collection specifications define a minimal core of the most frequently used JSON object types. Because of the hierarchical structure between these objects, a STAC catalog can be implemented in a completely 'static' manner as a group of hyperlinked Catalog, Collection, and Item URLs, enabling data publishers to expose their data as a browsable set of files. If more complex query abilities are desired, such as spatial or temporal predicates, the STAC API specification can be implemented as a web service interface to query over a group of STAC objects, usually held in a database.
To the greatest extent possible, STAC uses and extends existing specifications. The most important object in STAC is an Item, which is simply a GeoJSON Feature with a well-defined set of additional attributes ("foreign members"). The STAC API extends the OGC API - Features - Part 1: Core with additional web service endpoints and object attributes.
Current version and branches
The master branch is the 'stable' version of the spec. It is currently version 1.1.0 of the specification. The STAC specification follows Semantic Versioning, so any breaking change will require the spec to go to 2.0.0.
The 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.
Communication
Our gitter channel is the best place to ask questions or provide feedback. The majority of communication about the evolution of the specification takes place in the issue tracker and in pull requests.
In this Repository
This repository contains the core object type specifications, examples, validation schemas, and documentation about the context and plans for the evolution of the specification. Each folder contains a README explaining the layout of the folder, the main specification document, examples, and validating schemas.
Additionally, the STAC API specification provides API endpoints, based on the OGC API - Features standard, that enable clients to search for Item objects that match their filtering criteria.
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 describes the three core object type specifications and how they relate to one another.
- Item Specification defines a STAC Item, which is a GeoJSON 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 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 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.
- Commons describes parts of the specification that are shared across the specifications listed above. This includes assets, links and common metadata.
- Examples: The 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 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-extensionsorganization. - Additional documents: The supporting documents include a complementary best practices document, and information on contributing (links in the next section). We also maintain a changelog of what was modified in each version.
Contributing
Anyone building software that catalogs imagery or other geospatial assets is welcome to collaborate. Beforehand, please review our guidelines for contributions and code of conduct. You may also be interested in our overall process, and the principles that guide our collaboration
Owner
- Name: Radiant Earth
- Login: radiantearth
- Kind: organization
- Email: support@radiant.earth
- Website: https://www.radiant.earth
- Twitter: OurRadiantEarth
- Repositories: 57
- Profile: https://github.com/radiantearth
Increasing shared understanding of our world through community-led initiatives that make data easier to access and use.
Citation (CITATION.cff)
cff-version: 1.2.0
message: "If you are referring to the STAC specification in your publications, please cite it as below."
type: software
title: "SpatioTemporal Asset Catalog (STAC) specification"
authors:
- name: "STAC Contributors"
preferred-citation:
type: standard
title: "SpatioTemporal Asset Catalog (STAC) specification"
abstract: "Making geospatial assets openly searchable and crawlable."
version: 1.1.0
year: 2024
date-released: 2024-09-10
license: Apache-2.0
url: https://stacspec.org
repository: https://github.com/radiantearth/stac-spec
authors:
- name: "STAC Contributors"
email: stac-psc@radiant.earth
GitHub Events
Total
- Create event: 3
- Issues event: 14
- Watch event: 65
- Delete event: 2
- Member event: 1
- Issue comment event: 56
- Push event: 7
- Pull request review comment event: 4
- Pull request review event: 13
- Pull request event: 6
- Fork event: 5
Last Year
- Create event: 3
- Issues event: 14
- Watch event: 65
- Delete event: 2
- Member event: 1
- Issue comment event: 56
- Push event: 7
- Pull request review comment event: 4
- Pull request review event: 13
- Pull request event: 6
- Fork event: 5
Committers
Last synced: 9 months ago
Top Committers
| Name | Commits | |
|---|---|---|
| Chris Holmes | c****e@g****m | 547 |
| Matthias Mohr | m****r@u****e | 510 |
| Matthew Hanson | m****n@g****m | 234 |
| Phil Varner | p****r@a****o | 135 |
| Emmanuel Mathot | e****t@t****m | 83 |
| James Banting | j****g@s****m | 37 |
| Michael Smith | a****5@h****m | 36 |
| James Santucci | j****i@g****m | 35 |
| Seth Fitzsimmons | s****h@m****t | 29 |
| Frederico Liporace | l****e@a****m | 29 |
| Josh Fix | j****x@b****m | 29 |
| Fabian Schindler | f****s@g****m | 28 |
| Josh Fix | j****h@f****m | 28 |
| Phil Varner | p****r@g****m | 23 |
| Rob Emanuele | r****e@g****m | 23 |
| Alexandra Kirk | a****k@c****m | 22 |
| Tim Ruthersby | t****1@h****m | 19 |
| Scisco | me@s****o | 18 |
| jeffnaus | j****s@g****m | 16 |
| David Raleigh | d****h@g****m | 16 |
| Alex Leith | a****h@g****m | 15 |
| nrweir | n****r | 11 |
| Volker Mische | v****e@g****m | 7 |
| Aaron Su | x****u@o****m | 7 |
| David Hemphill | d****l@g****m | 6 |
| Pete Gadomski | p****i@g****m | 6 |
| Ryan McCarthy | r****y@w****m | 5 |
| Dave | d****m@g****m | 5 |
| Howard Butler | h****d@h****o | 5 |
| Kevin Booth | k****n@k****g | 5 |
| and 41 more... | ||
Committer Domains (Top 20 + Academic)
Issues and Pull Requests
Last synced: 6 months ago
All Time
- Total issues: 122
- Total pull requests: 67
- Average time to close issues: over 1 year
- Average time to close pull requests: 2 months
- Total issue authors: 48
- Total pull request authors: 18
- Average comments per issue: 4.16
- Average comments per pull request: 1.19
- Merged pull requests: 54
- Bot issues: 0
- Bot pull requests: 0
Past Year
- Issues: 14
- Pull requests: 9
- Average time to close issues: N/A
- Average time to close pull requests: about 1 month
- Issue authors: 7
- Pull request authors: 4
- Average comments per issue: 1.36
- Average comments per pull request: 0.89
- Merged pull requests: 7
- Bot issues: 0
- Bot pull requests: 0
Top Authors
Issue Authors
- m-mohr (37)
- philvarner (10)
- cholmes (9)
- schwehr (7)
- fmigneault (4)
- matthewhanson (4)
- mojodna (4)
- drnextgis (3)
- mhogeweg (3)
- emmanuelmathot (2)
- chiarch84 (2)
- lossyrob (2)
- simonff (2)
- aznan2 (2)
- LiamBindle (1)
Pull Request Authors
- m-mohr (45)
- emmanuelmathot (24)
- gadomski (5)
- philvarner (4)
- fmigneault (3)
- ircwaves (2)
- kurtmckee (2)
- jo-chemla (2)
- vincentsarago (2)
- jedsundwall (1)
- jbants (1)
- sankichi92 (1)
- nkleinbaer (1)
- romeokienzler (1)
- TomAugspurger (1)
Top Labels
Issue Labels
Pull Request Labels
Packages
- Total packages: 1
- Total downloads: unknown
- Total dependent packages: 0
- Total dependent repositories: 0
- Total versions: 26
proxy.golang.org: github.com/radiantearth/stac-spec
- Documentation: https://pkg.go.dev/github.com/radiantearth/stac-spec#section-documentation
- License: apache-2.0
-
Latest release: v1.1.0
published over 1 year ago
Rankings
Dependencies
- gh-pages ^3.0.0
- klaw-sync ^6.0.0
- remark-cli ^8.0.0
- remark-lint ^7.0.0
- remark-lint-no-html ^2.0.0
- remark-preset-lint-consistent ^3.0.0
- remark-preset-lint-markdown-style-guide ^3.0.0
- remark-preset-lint-recommended ^4.0.0
- remark-validate-links ^10.0.0
- stac-node-validator ^1.1.0