Added sat:anx_start_offset and sat:anx_end_offset fields

[m-mohr]

Any thoughts?

Was discussed with ESA for Sentinel-1. I changed from "type integer, unit nanoseconds" to type floating point number, i.e. flexible unit. floating point numbers can also be added / subtracted more easily from unix timestamps etc.

[emmanuelmathot]

Those offsets represent the delays between crossing the time at crossing the ANX and the start/end of the acquisition, right? At that point those 2 values can be easily derived by substracting the sat:anx_datetime from start_datetime and end_datetime. That is why I did not put them initially in this extension.

[m-mohr]

I hope ESA can clarify, I'm not sure as I didn't follow the full length of the discussion. If that is the case though, we should probably not add them here, I agree.

Edit: ESA agreed to provide the usecase and an example query that requires such offsets.

[jolyonm]

The “old” requirement for many users of SAR was to find matching sets of data according to relative orbit and a known offset from the anx

Whilst the offset is certainly calculatable from the sensing time – anx crossing it may not be an easy query to manage via the catalogue
e.g. where relative_orbit = myOrbit AND sensing_start – anx_datetime < myInterestEnd AND senting_stop – anx_datetime > myInterestStart
or something similar, implying a date calculations on the server side

The query is of course equivalent to expressing an AOI, but now I’m not sure if all legacy missions reliably support AOI for the RAW data catalogues. Perhaps this “old” requirement should be retired, but it seems that if we want to report anx_datetime per item it makes equal sense to report the start_offset and end_offset as optional fields

[emmanuelmathot]

@jolyonm this use case can be covered using the existing sat:anx_datetime field.

[m-mohr]

The query is of course equivalent to expressing an AOI, but now I’m not sure if all legacy missions reliably support AOI for the RAW data catalogues.

This should be clarified first. All data needs to be on the table before we add something here.

Perhaps this “old” requirement should be retired, but it seems that if we want to report anx_datetime per item it makes equal sense to report the start_offset and end_offset as optional fields

This seems like very niche information that can be computed. Storing it in the database (with indexed for querying) seems like a lot of overhead for such a case. I think we should avoid this if possible.

Setting to draft until we have all information provided.