Add sat:acquisition_station field and update dependencies#13
Add sat:acquisition_station field and update dependencies#13emmanuelmathot wants to merge 1 commit intomainfrom
Conversation
| | sat:orbit_cycle | integer | The number of repeat cycle done by the satellite at the time of the acquisition. [Repeat cycle](https://ltb.itc.utwente.nl/page/498/concept/81577) is the time between two successive identical orbits. | | ||
| | sat:orbit_state_vectors | Map<string, \[number]> | The state vectors of the satellite at the time of acquisition. | | ||
| | sat:anx_datetime | string | The [Ascending Node](https://en.wikipedia.org/wiki/Orbital_node) Crossing (ANX) time, in UTC. It is formatted according to [RFC 3339, section 5.6](https://tools.ietf.org/html/rfc3339#section-5.6). | | ||
| | sat:acquisition_station | string | The acquisition station (ground station) where the satellite data was downlinked. Equivalent to `eop:acquisition_station` in OGC 10-157r4 and OGC 17-003r2. | |
There was a problem hiding this comment.
Isn't this (for L0 data?) the same as processing:facility?
There was a problem hiding this comment.
The acquisition station and processing may be the same entity but not always. The purpose is different and such a field can allow the search of acquisitions downlinked to a specific station in some strict timeliness conditions, especially for RAW or level 0 product.
There was a problem hiding this comment.
Okay. Is this properly scoped in the sat extension though? I'm not really into all the details, but a ground station feels a bit disconnected to a sat as it's on the ground, not in orbit. It feels more closely related to processing:facility (and processing:lineage) in processing. So I think it might better fit in there or maybe even into a new extension if we expect more related metadata.
2 participants
Introduce the
sat:acquisition_stationfield to enhance data lineage and provenance tracking for satellite data.Fixes #12
Update dependencies