const COG_TYPES = [
"image/vnd.stac.geotiff; cloud-optimized=true",
"image/x.geotiff", // generated by sat-api
"image/tiff; application=geotiff; profile=cloud-optimized"
];
Slowly progressing with work to generate STAC files for our collection. In the process so far, two key questions have emerged from my team. We would greatly appreciate thoughts and opinions on the following:
Standalone Collections -
summariesattributes
When creating standalone collections, what is the recommendation for representing footprint geometry (I'm assumingproj:geometry)? I notice that when validating in STACLint it recommends that values for each attribute insummariesshould be surrounded by[]. In the scenario of a standalone collection, should this applied to all attributes insummariesor only for the attributes where multiple values are present?MultiPolygon Support
Is there any flexibility in the item spec / extensions for MultiPolygon (rather than Polygon) GeoJSON geometries? I'm currently generating STAC collections and items for orthorectified historic aerial photography data, and there are a limited number of instances where a project is split across two distinct polygons due to a missing flightline (or pilot error). All properties are identical, the data asset (e.g. mosaic) just has a gap in the middle.
- It's officialy not allowed, but I'd guess that most clients can handle it just fine as usually they just use GeoJSON libraries anyway... I'd just open an issue on GH and then see what others think about allowing more GeoJson types.
2 replies
I’m going to push on this some more, I think it’s a serious problem.
@cholmes @m-mohr During development of the Collection Spec, was there ever consideration of a Collection also being consumable as a GeoJSON (e.g. having geometry, feature and properties fields)?
I'm working through a scenario at the moment with a number of stand-alone collections that would greatly benefit from having their footprint/extent represented in a simple and consumable manner. The data is mainly linear captures with film / digital aerial photography, where a bounding box is a very poor representation of project extent. In a large number of instances we also don't have any mosaic assets that show the project's full extent. While we've tried to represent the data in the summaries object under proj:geometry, this resulting file is certainly not as usable to rapidly query or visualise as a GeoJSON.
While I can't find any mention in the STAC spec and OGC API - Features spec, I notice that in PySTAC there is support for a Properties object in the collections class. Is this from earlier iterations of the spec, or for collection level properties to be represented?
As always, your support and insights are greatly appreciated. I know our use cases can be a bit left of field sometimes.
1 reply
@JohnBTasker Yes, but we had the desire to align with OGC API - Features and they don't use GeoJSON for Collections.
If you use data and collections in a sentence, there's likely something wrong. I think what you want to do is an Item, not a standalone collection. The addition of the collection assets was not meant to replace single items, but to allow to link to assets that are common across all items. Also, your standalone collections would not be searchable via STAC API /search. So I'd recommend to make an item, with (optional, but I'd recommend it) a corresponding collection.
Properties in Collections is indeed from an earlier iteration of STAC. That will likely go away in implementations in the future. Collection level properties go in summaries (for standalone collections) or top-level, if the extension supports it.
@cholmes The general data model that we have established has four object types:
- Frame (STAC Item) => Atomic organisation of the data, includes metadata for position, time, and relationship Run, Film & Project
- Run (STAC Collection) => Collection of frames sharing common metadata (captured same day, sensor, film), can have a LineString geometry (flightline) + Polygon geometry (footprint)
- Project (STAC Collection) => Collection of runs sharing common metadata (e.g. provider, purpose), can have Polgyon/MultiPolygon geometry (footprint) [typical preference for search/discovery]
- Film (STAC Collection) => Collection of frames and runs based on source physical medium; basis of data storage structure
Only frames are directly related to data files, the remaining objects are semantic groupings of common search/discovery attributes. The main interest for proposing improved geometry details in collections is that more often than not for aerial datasets you will initially search for a project rather than individual data items, particularly over large areas. Once you've narrowed down the project(s), finding the specific data item / format is then the focus. A good example of this type of logic is the LINZ Data Service (https://data.linz.govt.nz/) where data is organised based on projects, with individual tiles subsequently downloadable.
geometry of a STAC Item should be resolved as due to small turbulences the sensor is constantly shaking and thus the footprint has a wobbly shape. Using only the bounding box would likely cover way too much of an area, but providing all the fine details would probably be far too much of nonsensical metadata.