Add sat:acquisition_station field and update dependencies#13
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.
There was a problem hiding this comment.
I understand the concern as a ground station is, by definition, on the ground and not in orbit. However, I'd argue that sat:acquisition_station is still correctly scoped under the sat extension.
A satellite system is not just the spacecraft: it is the combination of the space segment (the satellite itself) and the ground segment (the network of stations that command the satellite and receive its data). The acquisition/downlink station is an intrinsic part of that overall system and it only makes sense in the context of a satellite pass over a specific location at a specific time. You cannot conceive of sat:acquisition_station without the satellite.
By contrast, processing:facility is entirely sensor-agnostic as it applies equally to airborne, drone, or in-situ data. The acquisition station is not where data is processed; it is where the satellite downlinks its data, which is a fundamentally different and earlier step in the chain, driven entirely by the satellite's ground track and visibility windows.
There was a problem hiding this comment.
I guess then the remaining question is, whether an acquisition station is present for any other data than satellite data? If yes, it should be reusable. If not, go ahead.
There was a problem hiding this comment.
An acquisition station in this sense is by definition tied to satellite operations. The concept only exists because the satellite is in orbit, has a ground track, and has visibility windows over specific stations. No other sensor type (airborne, drone, in-situ) downlinks data to a ground station network in this way. They may have a processing:facility, but that is a different concept entirely.
So no, this is not reusable outside of satellite data, and sat:acquisition_station is the right home for it.
emmanuelmathot
force-pushed
the
acq_station
branch
from
01a880b to
2e6d73d
Compare
Co-authored-by: Copilot <copilot@github.com>
2 participants
Introduce the
sat:acquisition_stationfield to enhance data lineage and provenance tracking for satellite data.Fixes #12
Update dependencies