Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SAR Content Extension #155

Closed
hgs-msmith opened this issue Aug 14, 2018 · 8 comments
Closed

SAR Content Extension #155

hgs-msmith opened this issue Aug 14, 2018 · 8 comments
Labels
prio: should-have would be very good to have in the release
Milestone

Comments

@hgs-msmith
Copy link
Contributor

Define metadata extension for SAR data.

@hgs-msmith
Copy link
Contributor Author

Consider adding the following as SAR-specific metadata:

  • Pass direction | ascending vs. descending orbit
  • Polarization | HH, VV, HV, VH
  • Instrument mode | IW, stripmap, etc.
  • Product class | RAW, SLC, GDR, etc. – different levels of processing
  • Range resolution | eo:gsd as array?
  • Azimuth resolution | eo:gsd as array?

@jeffnaus
Copy link
Contributor

I'll, jnaus, will own this and give an example and kick off for comment

Questions: What is the relationship between this and the EO extension. can they/ should they have the same parent.

@matthewhanson
Copy link
Collaborator

matthewhanson commented Aug 16, 2018

There is a lot of fields in the EO extension that apply here. The whole bands mechanism can be used as in EO extension - SAR bands can be specific with wavelength, FWHM, and even common_name can be used to refer to standard radar wavelength bands (e.g., x-band).

Regarding sharing a parent, inheritance isn't something that has been discussed yet, unless you guys talked about this meeting. I'm not sure we want to go down that path.

@jeffnaus
Copy link
Contributor

In my experience the bands are different then EO in that they are magnitude, phase, or SLC (single look complex, which is the response time and strength combined). The wavelength information usually is set for the sensor and this is then combined with beam mode (like wide or fine...) to determine spatial and spectral resolution. Multi-look data is different from this also and I don't have direct experience with those datasets. I'll do more research around this, I may make an initial spec proposal for just single look derived products.

@cholmes cholmes changed the title SAR Profile SAR Content Extension Aug 23, 2018
@cholmes cholmes added prio: should-have would be very good to have in the release and removed new extension labels Aug 23, 2018
@cholmes cholmes added this to the 0.6.0-RC1 milestone Aug 24, 2018
@m-mohr m-mohr modified the milestones: 0.6.0-RC1, future Oct 9, 2018
@m-mohr
Copy link
Collaborator

m-mohr commented Nov 8, 2018

As we need it for openEO soon, we'll write a proposal in the next weeks and post it for discussions. I'll take this issue as a basis.

@m-mohr m-mohr modified the milestones: future, 0.7.0 Nov 8, 2018
@m-mohr
Copy link
Collaborator

m-mohr commented Nov 12, 2018

I made a first proposal for the SAR extension, please review #347. Thanks!

cholmes added a commit that referenced this issue Jan 2, 2019
@m-mohr
Copy link
Collaborator

m-mohr commented Jan 2, 2019

It has been merged to dev. There were still two comments by @mrepse (see comment) and @AlenaDostalova (see comment) with open points for discussion. It would be great if you could propose your changes as PR for discussion.

Other than that, I still need to add a JSON Schema.

@m-mohr
Copy link
Collaborator

m-mohr commented Feb 22, 2019

Is complete now, I think.

@m-mohr m-mohr closed this as completed Feb 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
prio: should-have would be very good to have in the release
Projects
None yet
Development

No branches or pull requests

5 participants