radiantearth / stac-spec

SpatioTemporal Asset Catalog specification - making geospatial assets openly searchable and crawlable
https://stacspec.org
Apache License 2.0
772 stars 177 forks source link

sar:absolute_orbit and sar:off_nadir more suitable for collections than items? #423

Closed m-mohr closed 5 years ago

m-mohr commented 5 years ago

After reading a comment from @walterggit in https://github.com/radiantearth/stac-spec/issues/405#issuecomment-470232131, I realized that I may was a bit too much influenced with my collection-level view when defining sar:absolute_orbit and sar:off_nadir. Currently, it allows quite complex ranges of numbers, but isn't the absolute_orbit and the off_nadir value exactly one value per item?

cholmes commented 5 years ago

Yes. Certainly for off_nadir. I just dug in a bit to absolute_orbit, as I don't understand that from my Planet satellite perspective. Looking at ALOS metadata it does look like yes, there's just one per record. Looking at sentinel 1 it seems like they use: Orbit number (start) and Orbit number (stop), but in the two records I saw they were the same value, so maybe it ends up at just one item per?

Definitely seems like it'd be a lot simpler to just have one value instead of the range thing.

cholmes commented 5 years ago

Hrm, though looking at what @walterggit wrote about incidence angle I wonder if off_nadir in SAR can be more of a range.

walterggit commented 5 years ago

For orbit number, I suppose the two numbers could potentially differ for products that cross the boundary between one orbit and the next (start could be in orbit N and end in orbit N+1). From page 29 of https://www.eorc.jaxa.jp/ALOS-2/en/doc/fdata/PALSAR-2_xx_Format_CEOS_E.pdf (if that is a current spec), it looks like the orbit number at scene center is used for ALOS. I think that one orbit number parameter is probably enough, so long as it is consistently derived for a given sensor (either start or stop or center, but not a mix).

I haven't used off-nadir for SAR, but for incidence angle it can be useful to have a two-value range even for a given scene, as it can vary quite a lot from near range to far range- e.g. for a single Sentinel-1 IW scene, it goes from 30.86 degrees at the start of IW1 to 46.00 degrees at the end of IW3 (see https://sentinel.esa.int/web/sentinel/user-guides/sentinel-1-sar/acquisition-modes/interferometric-wide-swath ). The off-nadir has a similarly large variation. Radarsat-2 can have a large or narrow range over a given scene depending on the beam mode, but the product metadata supplies both the near and far range incidence angles regardless.

cholmes commented 5 years ago

Cool, makes sense on the orbit number. We hit a similar thing with time, where we started with a range, but went to a single time, that implementors should pick in a consistent way.

Sounds like off-nadir are quite closely related and should be defined in the same way. The ALOS data I found seemed to use off-nadir, so seems like we should probably let implementors pick which one they want to use.

I was wondering if the center imporant? Like could we just specify near and far, and not worry about center? Or is center useful because it is one value?

Though looking at #405 it looks like you recommended having center, near and far. I think that may be the cleanest. This does make for a lot of fields in the SAR extension, but I think that's ok, as implementors don't have to use all of them, but it's good for us to assign the names and definitions to the common fields people want to use.

claxn commented 5 years ago

I agree with the latest status in #405 and to use one center off-nadir angle, instead of three.

Each S1 scene has one absolute orbit number (I am not sure what criteria they use if a scene covers the transition of n and n+1).

What about relative orbit numbers? S1 uses two orbit numbers, one is the relative orbit number and one is the absolute orbit number. The former ranges from 0-175 and repeats every 12 days and the second one is a unique id for each cycle (adding relative orbit numbers). It should be sufficient to have just one orbit number entry absolute_orbit, since you can derive the relative orbit number from it.

m-mohr commented 5 years ago

Thanks, @claxn. I was also thinking about absolute vs relative. Lately, I had more the impression that specifying the relative orbit number is more useful for searching. I guess it could be useful to query for "give me all images for rel. orbit 123", but it's probably rarely useful to query by absolute orbit number? Please correct me if I'm wrong, these are just assumptions by me. How are these two values (rel/abs orbit) work for other datasets than Sentinel 1? So I'm leaning towards removing absolute_orbit and adding relative_orbit. Opinions? cc @walterggit

claxn commented 5 years ago

I have never used the absolute orbit number before, only the relative orbit number. Because all scenes, which have the same relative orbit number, have the same viewing geometry. This enables the derivation of suitable, physically profound parameters (e.g. mean of images with rel. orbit 123). However the absolute orbit number is at least some kind of unique identifier.

walterggit commented 5 years ago

I have also not used the absolute orbit number in search, though I suppose it could be useful for some use cases (e.g. if there was a known anomaly during a particular orbit and you wanted to screen for it). I do use the relative orbit number and other parameters to get same-geometry image sets for sentinel-1.

ESA scihub searches return both the absolute and relative orbit numbers though (actually, they return four orbit numbers, to cover both relative and absolute orbits for the start and end of the product: orbitnumber, lastorbitnumber, relativeorbitnumber, lastrelativeorbitnumber: see https://scihub.copernicus.eu/twiki/do/view/SciHubUserGuide/FullTextSearch ).

m-mohr commented 5 years ago

@walterggit @claxn You can review the changes to off_nadir and orbits at #426

m-mohr commented 5 years ago

Merged into dev and will be released as part of the 0.7 release. Thanks everybody.