Orthophoto Extension Specification

• Title: Orthophoto
• Identifier: https://stac-extensions.github.io/ortho/v0.1.0/schema.json
• Field Name Prefix: ortho
• Scope: Collection, Item
• Extension Maturity Classification: Proposal
• Owner: @m-mohr

This document explains the Orthophoto Extension to the SpatioTemporal Asset Catalog (STAC) specification.

It describes orthophotos (orthoimages), i.e. aerial or satellite images that are rectified to a map projection, with the elevation model used for the rectification and the leaf state of the vegetation.

• Examples:
  • Item example: A true orthophoto tile, acquired leaf-off
  • Collection example: A collection of orthophotos with summaries
• JSON Schema
• Changelog

Fields

The fields in the table below can be used in these parts of STAC documents:

• Catalogs
• Collections
• Item Properties (incl. Summaries in Collections)
• Assets (for both Collections and Items, incl. Item Asset Definitions in Collections)
• Links

Field Name	Type	Description
ortho:elevation_model	[string]	The types of elevation model that the image was rectified on: surface (true orthophoto) and/or terrain (classic orthophoto).
ortho:leaf_state	[string]	The leaf states of the vegetation at the time of the acquisition: leaf-off, partial and/or leaf-on, or unknown.

Both fields are arrays with at least one value and no duplicates. They usually have one value. They have several values if the image combines parts of different kinds, e.g. a mosaic of tiles of which some are true and some are classic orthophotos. Arrays are used even for a single value, so that clients and queries can rely on one data type, e.g. a_contains(ortho:elevation_model, 'surface') in CQL2.

The fields are usually provided in the Item Properties. They can be provided in Assets if an Item has, for example, a true and a classic orthophoto as separate assets.

Additional Field Information

ortho:elevation_model

Value	Description
surface	Rectified on a digital surface model (DSM) that includes buildings and vegetation, e.g. an image-based surface model. Also known as true orthophoto: roofs lie on their footprints and buildings don't lean over streets.
terrain	Rectified on a digital terrain model (DTM) of the bare earth. Also known as classic orthophoto: elevated objects lean away from the image centre.

If the elevation model is not known, the field is omitted. It is never an empty array. The elevation model itself can be linked with the relation types surface-model and elevation-model of the Accuracy extension.

ortho:leaf_state

Value	Description
leaf-off	Deciduous vegetation without leaves, usually acquired in early spring.
partial	Deciduous vegetation partially in leaf.
leaf-on	Deciduous vegetation in full leaf, usually acquired in summer.
unknown	The leaf state was not recorded.

The value unknown makes the absence of the information explicit, so that clients can tell it apart from data that doesn't use this field. It can't be combined with other values: ["unknown"] is valid, ["leaf-off", "unknown"] is not.

Mapping from other standards

AdV product standard for digital orthophotos (Germany)

The AdV product and quality standard for digital orthophotos (DOP) defines per-tile metadata that the German state survey offices publish with their orthophotos:

AdV field	AdV value	Field	Value
Bezugsflaeche	bDOM	ortho:elevation_model	surface
Bezugsflaeche	ATKIS-DGM	ortho:elevation_model	terrain
Belaubungszustand	0 (no information)	ortho:leaf_state	unknown
Belaubungszustand	1	ortho:leaf_state	leaf-off
Belaubungszustand	2	ortho:leaf_state	partial
Belaubungszustand	3	ortho:leaf_state	leaf-on
Bildflugnummer	e.g. 1428/24 Höxter	mission	as is

Best Practices

Other information that is commonly recorded for orthophotos is provided in existing fields:

Information	Field
Acquisition (flight) date	datetime, start_datetime and end_datetime (Common Metadata)
Flight campaign or project	mission (Common Metadata), e.g. the flight number of the campaign
Camera	instruments (Common Metadata)
Ground sample distance	gsd (Common Metadata)
Positional accuracy	accuracy:geometric_x_stddev and accuracy:geometric_y_stddev (Accuracy extension)
Spectral bands	bands with eo:common_name, e.g. red, green, blue and nir (EO extension)

Contributing

All contributions are subject to the STAC Specification Code of Conduct. For contributions, please follow the STAC specification contributing guide Instructions for running tests are copied here for convenience.

Running tests

The same checks that run as checks on PRs are part of the repository and can be run locally to verify that changes are valid. To run tests locally, you'll need npm, which is a standard part of any node.js installation.

First you'll need to install everything with npm once. Just navigate to the root of this repository and on your command line run:

npm install

Then to check markdown formatting and test the examples against the JSON schema, you can run:

npm test

This will spit out the same texts that you see online, and you can then go and fix your markdown or examples.

If the tests reveal formatting problems with the examples, you can fix them with:

npm run format-examples