Skip to content

Conversation

@abradley60
Copy link
Collaborator

  • Updating the storage and versioning for static layers to consider both the dem_type and static_layer_validity_start_date. This is required to future proof the pipeline if changes are ever made to the dem (e.g. consideration of timeseries) or the orbit / aquisition scenario of the sentinel-1 mission changes (for example, the orbit is lowered in late life or the orbit is no longer stable and the assumption of static layers is invalid).
  • The stucture of the S3 prefix for products is as follows:
    • RTC_S1_S3_PREFIX_FORMAT = "{s3_project_folder}/{odc_product_name}/{burst_id}/{burst_st_year}/{burst_st_month}/{burst_st_day}/{burst_st}"
    • RTC_S1_STATIC_S3_PREFIX_FORMAT = "{s3_project_folder}/{odc_product_name}/{burst_id}/{static_layer_validity_start_date}/{dem_type}"
    • Given a single config is used for a whole scene, the values are filled by the RTC software - opera-adt/RTC@ea92fc7
  • The product path times (e.g. burst_st) references the azimuth_time of the burst. This is different to the acquisition start time.
  • The STAC document has been updated to reflect this difference:
    • datetime = azimuth_time or zero_doppler_start_time
    • start_datetime = BeginningDateTime from CDSE API, this is consistent with the startTime from the ASF API
    • end_datetime = EndingDateTime from CDSE API, this is not consistent with the stopTime from the ASF API
    • sarard:azimuth_time
    • sarard:zero_doppler_start_time
    • sarard:zero_doppler_end_time
  • Simplified logic to link static layers in the stac document. It now works off the dataAccess links defined in the config.

Copy link
Collaborator

@caitlinadams caitlinadams left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, I think this is a big improvement in terms of how the logic works for managing the metadata, partcularly when it comes to S3 paths. Do you need to update the documentation in line with these changes at all?

f"DEM type URL map: {DEM_TYPE_URL}. Matches: {dem_type_matches}"
)
raise ValueError(
f"Expected exactly one DEM type match, found {len(dem_type_matches)}."
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth saying what the matches were? Or is it sufficient to be told there was an incorrect number of matches?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call, addressed - c55a79c

@abradley60
Copy link
Collaborator Author

Overall, I think this is a big improvement in terms of how the logic works for managing the metadata, partcularly when it comes to S3 paths. Do you need to update the documentation in line with these changes at all?

Yes I do. Thanks I missed that actually!

Copy link
Collaborator

@caitlinadams caitlinadams left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, thanks for making the changes!

@caitlinadams caitlinadams merged commit e2dabae into main Nov 28, 2025
2 checks passed
@caitlinadams caitlinadams deleted the update/static_layer_paths branch November 28, 2025 03:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants