All Projects → radiantearth → Stac Spec

radiantearth / Stac Spec

Licence: apache-2.0
SpatioTemporal Asset Catalog specification - making geospatial assets openly searchable and crawlable

Programming Languages

javascript
184084 projects - #8 most used programming language

Projects that are alternatives of or similar to Stac Spec

SpaceEye
Live satellite imagery for your desktop background
Stars: ✭ 253 (-39.47%)
Mutual labels:  satellite-imagery
open-impact
To help quickstart impact work with Satellogic [hyperspectral] data
Stars: ✭ 21 (-94.98%)
Mutual labels:  satellite-imagery
Geospatial Machine Learning
A curated list of resources focused on Machine Learning in Geospatial Data Science.
Stars: ✭ 289 (-30.86%)
Mutual labels:  satellite-imagery
ResDepth
[ISPRS Journal of Photogrammetry and Remote Sensing, 2022] ResDepth: A Deep Residual Prior For 3D Reconstruction From High-resolution Satellite Images
Stars: ✭ 30 (-92.82%)
Mutual labels:  satellite-imagery
laika
Experiments with satellite image data
Stars: ✭ 97 (-76.79%)
Mutual labels:  satellite-imagery
geoblaze
Blazing Fast JavaScript Raster Processing Engine
Stars: ✭ 80 (-80.86%)
Mutual labels:  satellite-imagery
deep typhoon
Analysis satellite images of typhoons in deep-learning (CNN).
Stars: ✭ 26 (-93.78%)
Mutual labels:  satellite-imagery
Notebooks
interactive notebooks from Planet Engineering
Stars: ✭ 339 (-18.9%)
Mutual labels:  satellite-imagery
google-maps-at-88-mph
Google Maps keeps old satellite imagery around for a while – this tool collects what's available for a user-specified region in the form of a GIF.
Stars: ✭ 93 (-77.75%)
Mutual labels:  satellite-imagery
Torchsat
🔥TorchSat 🌏 is an open-source deep learning framework for satellite imagery analysis based on PyTorch.
Stars: ✭ 261 (-37.56%)
Mutual labels:  satellite-imagery
land-cover-to-land-use-classification
Satellite image processing pipeline to classify land-cover and land-use
Stars: ✭ 64 (-84.69%)
Mutual labels:  satellite-imagery
Landsat578
Very simple API to download Landsat [1-5, 7, 8] data from Google
Stars: ✭ 54 (-87.08%)
Mutual labels:  satellite-imagery
shipsnet-detector
Detect container ships in Planet imagery using machine learning
Stars: ✭ 30 (-92.82%)
Mutual labels:  satellite-imagery
rLandsat
R Package to make Landsat8 data accessible
Stars: ✭ 95 (-77.27%)
Mutual labels:  satellite-imagery
Open Solution Mapping Challenge
Open solution to the Mapping Challenge 🌎
Stars: ✭ 291 (-30.38%)
Mutual labels:  satellite-imagery
dea-coastlines
Extracting tidally-constrained annual shorelines and robust rates of coastal change from freely available Earth observation data at continental scale
Stars: ✭ 24 (-94.26%)
Mutual labels:  satellite-imagery
disasterwatch
Access satelite imagery where it is needed
Stars: ✭ 43 (-89.71%)
Mutual labels:  satellite-imagery
Label Maker
Data Preparation for Satellite Machine Learning
Stars: ✭ 377 (-9.81%)
Mutual labels:  satellite-imagery
Awesome Sentinel
curated list of awesome tools, tutorials and APIs for Copernicus Sentinel satellite data
Stars: ✭ 335 (-19.86%)
Mutual labels:  satellite-imagery
himawari-rx
📡 Receive images from weather satellite Himawari-8 via HimawariCast.
Stars: ✭ 21 (-94.98%)
Mutual labels:  satellite-imagery
stac-logo

CircleCI

About

The SpatioTemporal Asset Catalog (STAC) family of specifications aims 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 now covers 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 semantics to support a broad set of use cases.

The STAC specifications define JSON object types and hypermedia interface to be used by providers and consumers of geospatial data.
This is advantageous to providers, as they can simply use a well-designed, standard format without needing to design their own proprietary one. This is advantageous to consumers because 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.

Typically, several STAC specifications are composed together to create a catalog. 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.

Stability Note

This specification has matured over the past several years, and is used in numerous production deployments. With the 1.0 release, implementors should expect that most definitions will remain stable. Our goal is to not change the core in any backwards-incompatible way for a long time. The STAC specification follows Semantic Versioning, 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 is the 'stable' version of the spec. It is currently version 1.0.0 of the specification. 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.
  • 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: The extensions/ folder is where extensions live. Extensions can extend the functionality of the core spec or add fields for specific domains. Each extension has at least one owner. You can find extension owners in each extension's README or in the CODEOWNERS file.
  • 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

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].