New Extension: Topographic 4D Specification (topo4d)

[Wjppppp]

Hi STAC community,

we’re excited to propose a new STAC extension: Topographic 4D (topo4d), which introduces a standardized way to handle time-dependent metadata for 4D datasets, specifically, time series of 3D geospatial data.

We recognize the value of existing extensions like: 1) pointcloud describes items, like schemas and statistics, of individual point cloud; 2) processing is for capturing data lineage and workflow metadata; 3) timeseries describes time series data but it is deprecated now.

The topo4d extension is complementary to these. While pointcloud and processing are highly useful at the item level, topo4d focuses on temporal dependency and metadata of 3D observations across entire time, enabling better management of datasets that include hundreds or thousands of epochs, including transformations, timestamps, and processing chains.

This extension supports consistent metadata handling for a wide variety of 4D datasets, for example:

• Multi-sensor point clouds (e.g., LiDAR, Photogrammetry, Satellite Imagery)
• Near-continuous 3D time series with high temporal frequency

By introducing topo4d, we aim to improve interoperability, accessibility, and reusability of 4D datasets across disciplines, such as geomorphology, hydrology and ecology, where the time series of 3D data is critical.

The spec is available at a github repository generated from template of the extension: https://github.com/tum-rsa/topo4d

After following the guideline of Proposing new extensions, we now welcome feedback, suggestions, and collaboration to bring this as a new STAC community extension into alignment with community needs and best practices. We're looking forward to your response and hints for next steps.

Best regards,
4D-Works Team,
Professorship of Remote Sensing Applications
Technical University of Munich
Lise-Meitner-Str. 9, 85521 Ottobrunn

[gadomski]

Thanks for opening this! I'll provide some feedback here just on the extension itself:

• topo4d:native_crs is duplicative of proj:code
• topo4d:sensor is duplicative of instruments
• Data structures like topo4d:trajectory aren't well suited to STAC metadata — they can be very large, leading to poor search performance from many backends. I'd recommend storing the trajectory as a separate file, and linking to it via an asset
• topo4d:point_count is duplicative of pc:count
• ...

I didn't do a complete audit, but it seems as though the extension could benefit from "composition" of existing extensions and STAC common metadata, only adding new fields when an appropriate field doesn't already exist.

[Wjppppp]

@gadomski Thanks so much for the quick feedback. We appreciated it!
We’ve made several corresponding updates in the topo4d repo:

• Fields that were duplicative (like topo4d:native_crs, topo4d:sensor, and topo4d:point_count) have been removed or replaced with references to the corresponding fields in existing STAC extension or common metadata (see CHANGELOG)
• We've added best practices guidance to help users integrate the Topo4D Extension alongside other common extensions to avoid redundancy.
• To handle larger metadata information like topo4d:trajectory and also topo4d:scan_positions, external assets were introduced. These allow such data to be stored as separate files and linked via assets.
• Examples have been updated to reflect these changes.

Thanks again, and looking forward to continued feedback!

Additionally, we’ve developed some customized code to support the implementation of the Topo4DExtension. We'd love to hear your thoughts on the best way to share this with the Pystac development team.

[gadomski]

Appreciate the changes. I'll try to take another review pass in the near future.

the best way to share this with the Pystac development team.

Pull requests are always welcome! We don't have an official policy around which extensions we support in pystac, but we generally try to accept anything that's maintainable and widely used (i.e. more than one implementer). We use extension maturity as a measure of how much an extension is used, and generally try to support any stable and candidate extensions, with some pilot. Any new extensions increase the maintinance burden of the pystac codebase, so we try to consider that utility vs. maintenance cost balance when deciding whether to include a new extension.