P4002 - SAR Metadata Content Standard Working Group

SAR Metadata WG: Meeting 20 Agenda & Minutes

Meeting Agenda

1. Call to Order
2. Approval of Agenda
3. Approval of Minutes of previous mtg
4. IEEE Patent Policy
5. Discussion of Draft Standard
6. Other Business
7. Future Meetings
8. Adjourn

Minutes of SAR Metadata Std Working Group Meeting
August 27, 2020

1. Call to order
attendees:
Leland Pierce
Wade Schwartzkopf
Marc Trachy
Chuck Heazel
Mike Stewart
Craig Stringham
Vanessa Lalitte

we have a quorum

===================================
2. Approval of agenda
===================================
Marc moved, Mike seconded, no discussion, no opposition
approved.

===================================
3. Approval of minutes of previous meeting
===================================
Marc moved, Mike seconded, no discussion, no opposition
approved.

===================================
4. IEEE Patent and Copyright Policy
===================================
1. slides 1-4 were shown and discussed by the chair
2. Chair provided an opportunity for participants to identify patent
claim(s)/patent application claim(s) and/or the holder of patent
claim(s)/patent application claim(s) of which the participant is
personally aware and that may be essential for the use of that
standard.

===================================
5. Discussion of current draft standard
===================================

Continued discussion on Marc Trachy’s document giving ideas for changes to make
in SICD for this standard.

21. ErrorStats
currently ecf posn uncertainty not required, but offset reqd for
scp in image domain.
extend to radiometric and polarization params
need a confidence measure: a string

22. beamcomp
specify how applied: for example avg or specific beam value

PFA:
23. move under ImageFormation… no argument
24. Krg, etc
originally interpolated spatial freq extents
not useful to anybody.
no argument against removal
25. STdeskew
currently: a flag if applied or not, plus a polynomial
can get from deltaKCOA
if a deskew has been applied that is not STdeskew, what then?

RMA/INCA
26. move under ImageFormation… no argument
27. R_CA_SCP
redundant, potentially incorrect
error has been noted to be 0.5m for some formats that also provide
tie points.
28. FreqZero
not needed if remove dopcentroidpoly
29. dopCentroifPoly
redundant
range rate more relevant.
both can be calculated from geometry

31. decided to pick beta-0 as the provided data, with equations in
spec giving eqns to convert to others:
rcs, sigma0, gamma0

bistatics:
some discussion as to whether to make this part of the std or just
stick to monostatic. no decision.
issue is that one needs to know it’s bistatic to process the metadata
correctly.
instead: metadata should make it clear
(32-35)
basically require that illuminator and receiver have names
that way if the same, know its monostatic.
make tx and rcv apc polynomials required and dump arp-poly since its
not precise enough.
probably need to add more params for this, including:
error-stats,
redefine scpcoa
needs further discussion

philosophical issues:
36. do we require the producer to make guesses when info is less than
perfect? Can we devise a reasonable set of possibilities for how the
guess was arrived at?
need to do for params related to:
antenna
cal
errors

some of the things we are considering making required are only
required for specific applications. keep optional?
an example: antenna pattern:
if only have 3db beamwidth, can provide a sampled pattern that
shows this, sampled sparsely.
or, knowing the kind of antenna, could provide a modeled version if
the pattern has not been measured
or, have in-lab measured but not attached to platform
or, have in-lab measured and attached to platform
or, have a field-campaign that measured the pattern during the
mission: once or many times.
etc.

This can potentially be an arbitrary process that was used to create
the “estimate”. so how can we capture that?

for cal, for example, lets say there is an AGC somewhere, and it is
not captured in the metadata, so there is no way to compare numbers
between different datatakes, only relative (agc is constant for a
datatake). not likely an issue for modern sensors, but for conversion
of old data to this std.

37. segmentList depends on grid.
since the segmentList is related to data that is not part of this
file, it seems that the data catalog is the best place to find
related data instead of putting it here.
agreement to remove.

38. RadarCollection:
some params are related to the collection and NOT this specific
data-file.
such as collectDuration as opposed to processedDuration
general agreement that this should be removed.
need a more specific suggestion that goes into each param in
RadarCollection.

39,40,41:
require 2 1-way patterns and dump the 2-way pattern
this simplifies code that is using this
2 1-ways is also more useful for some applications where only one
of the patterns is relevant.
Mike Stewart brouhgt up a particular example with cosmoskymed
where only the 2-way is provided, and the pattern is quite messy
due to the multiplication of 2 different 1-way patterns.
need to explain why 2 1-way is better/required in the spec.

42. matchinginfo:
agreed to remove

Atmosphere:
43-45. add tropo/iono corrections
note relevant for older, low-res systems,
but most new systems are doing this, and users need to know what
they did so they can un-do/re-do as needed.
needs further effort

===================================
6. Other business?
===================================

none

===================================
7. Next meeting
===================================
the group wanted to have the next meeting in 2 weeks, at 11am.
Our next meeting will be on :
Thursday, Sept 10, 11AM Eastern time

===================================
8. Adjourn
===================================
Marc motioned, Mike seconded. no opposition. passed