Meeting Agenda
1. Call to Order
2. Approval of Agenda
3. Approval of Minutes of previous mtg
4. IEEE Patent Policy
5. Election results
6. Discussion of Draft Standard
7. Other Business
8. Future Meetings
9. Adjourn
Minutes of SAR Metadata Std Working Group Meeting
November 17, 2021
1. Call to order
attendees:
Leland Pierce
Wade Schwartzkopf
Marc Trachy
Nathan Bombaci
===================================
2. Approval of agenda
===================================
Wade moved, Marc seconded.
no discussion
approved.
===================================
3. Approval of minutes of previous meeting
===================================
Wade moved, Nathan seconded.
no discussion
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.
no discussion
===================================
5. Election Results
===================================
Wade was the only candidate.
Wade is the new Chair.
===================================
6. Discussion of current draft standard
===================================
Wade said that the contract for getting people paid to write the new standard is nearly approved.
Went over the current status of the revision document we’ve been working on.
A few pending issues were discussed:
backprojection: there is an exisint draft, will consider adding
beamcomp: Wade will look into
ImpRespWid: will add to contract
grid format details: will add to contract: use a modified version of similar format in the existing CPHD std.
What is included below is the current stsus of al lthe items in that document.
All items are included, with those in red giving what was accomplished at the meeting.
1. Replace /SICD/ImageCreation with a lineage
current SICD image-creation metadata is limited, if change to
lineage can put more info there for humans.
need exact details.
chuck has presented some ideas on this already.
chuck mentioned that error-propagation could also be added.
Leland: perhaps we need to survey other SAR formats for what they
include.
>> ACTION: Someone needs to make this more specific
>> Chuck volunteered
Looked at the XML that Chuck created for this.
Some felt this was nice, but too vague.
No specific place for processing parameters.
General agreement not to use it.
2. Remove AMP8I_PHS8I (likely PixelType won’t appear in the IEEE
version anyway)
Wade has seen it used, so wants to keep it.
the ISO range-type could be used instead to describe the structure
of the data for each pixel.
>> ACTION: Someone needs to look at the ISO range-type and come up
>> with a way to use it instead of what is currently specified.
>> Chuck volunteered
After some discussion it was felt that we didn’t really want to deal with bits and bytes related to the data encoding. Rather have the container of the data specify these. For metadata, make it clear that the data is re/im or amp/phz.
Decided to make it be a choice between AMP_PHZ and RE_IM
The idea is to have the metadata and data in the same container, hence no need for a field for a data-filename.
Wade questioned if we needed this, since we are trying to avoid having metadata related to bits and bytes,
resolved to discuss again later.
3. /SICD/ImageData/ValidData:
Make required and to include no zero filled pixels,
(may discard some valid pixels for simplification)
Chuck says that there is no ISO concept for this.
>> ACTION: make required.
4. /SICD/ImageData/SCPPixel: Allow to be non-integer
make it real-valued
center of pixel in SICD
need to look at implications to other metadata that uses line and
column values
the PHD std does this
>> ACTION: Someone needs to look at other metadata that is affected by
>> this change to make sure it works.
>> Wade:
-sees no problems
-most everything uses real numbers anyway.
-irow/icol uses it, but would work just fine with a real number
5. /SICD/GeoData/EarthModel: Replace with an ITRF version?
currently required to be wgs84.
wgs84 is not precise enough in its definition for some applications
replacing with a specific ITRF would be better
>> ACTION: Someone needs to look at what ITRF does and tell the group
>> what they think about using it. In particular, what “strings” do we
>> allow for the value of this parameter?
>> Marc volunteered
Add a new parameter: EarthModel_GPSWeekNumber, string
like: G730
6. /SICD/GeoData/GeoInfo: Remove
this is basically a list of “lat, lon, feature description”
largely NGA-specific
everyone agreed to remove it.
>> ACTION: remove it
7. /SICD/Grid/ImagePlane: Remove
an enumeration: SLANT, GROUND, other
historically has been poorly-populated: inaccurate
however, may still be useful for some applications
>> ACTION: keep, but someone needs to provide better guidance in the document
>> concerning how to populate it in a variety of circumstances.
>> Leland volunteered
removed cylindrical and nadir.
Possible additional language:
“This field is meant to be approximate, for humans rather than
computation. Hence, SLANT may mean the slant plane instantaneous at
the center-of-aperture time, or an average across the aperture, or similar
ideas.
Also, GROUND may mean projected onto a flat plane that is local-level, tangent to the ellipsoid at some point, or some kind of average elevation model value.
Use OTHER if none of these comes close to what is used.”
8. /SICD/Grid/Type: Document which ones can go with which image formation algorithms
info in V3. perhaps include in our std?
>> ACTION: Need to discuss again.
>> Marc volunteered
Marc documented this:
RGAZIM: PFA and RGAZCOMP
RGZERO: RMA/INCA
XRGYCR: Any
XCTYAT: Any
PLANE: Any
Decided to limit the use of these to “any image formation algorithm that natively produces this grid-type.”
Craig asked if we were considering making this work with backpropagation.
Wade said that SICD-B was working to add this, for special cases.
No decision was made,
9. /SICD/Grid/TimeCOAPoly: Document more precise definition of center
of aperture time
OK
>> ACTION: Some one needs to write this definition.
>> “Time which corresponds to the center of the spectral support.”
10. /SICD/Grid/*/ImpRespWid: Remove
most other stds have this, but not useful
maybe just add more docs on how to use it?
code exists on github.
>> ACTION: Need to discuss this again
>> really want to get rid of it, since it’s imprecise and used in stupid ways.
>> perhaps write up how to use the correct param (the spectral BW) instead?
Mike wrote up this explanation:
Removal of ImpRespWid
=====================
The ImpRespWid parameter found in both the Row and Col components of
the Grid metadata have been removed. The motivation for this change is
the extensive misuse and misunderstanding of this SICD field. A
fundamental limit on the utility of complex SAR imagery is the
bandwidth of that imagery. This is conveyed by the ImpRespBW
metadata item. Many users of SICD data instead chose to use the
ImpRespWid over the ImpRespBW, even going so far as to compute the
bandwidth from the stated width. Unfortunately, the ImpRespWid has a
variable relationship to the bandwidth. This relationship is dependent
on the weighting applied in the frequency domain. Despite this, many
users would use the ImpRespWid of two different complex images to
compare their bandwidth. This is obviously only valid if the data is
identically weighted. Furthermore, this parameter includes only one of
the many factors that can impact a point target’s impulse response
width. Other effects not included in the ImpRespWid computation are
phase errors, RF amplitude profiles, and uncompensated antenna
effects. Ideally, these would all be removed in the image formation
processing, but that is not required by the SICD standard. Despite
this, the ImpRespWid was frequently misused as the expected width of a
point target’s IPR and this misuse was both frequent and
understandable.
Removal of the ImpRespWid should prevent this common misuse and
encourage the use of the fundamental ImpRespBW parameter. As the
nominal resolution can be extracted by simply inverting the bandwidth,
it should not be onerous.
discussion:
— Wade: all agree reasonable.
— Wade: do we want to add equation how to get imprespwid from a bw given a
perfect ipr and some weighting factor?
— Mike: which imprespwid do they want? We should carefully define it.
antenna pattern, phase errors, other effects…
people may use incorrectly
— Marc: “for example: for the uniform weighting case, your half-power width is blah.”
There was lots of discussion about this, related to antenna patterns and weighting.
Eventually we decided that this param should be changed to be “bandwidth-limited-imprespwid”, or something like that, ie: 0.866/BW.
11. /SICD/Grid/*/Sgn: Remove (force -1, producers must conjugate if they would have had +1)
SICD has 2: 1 for row, 1 for col
only 1 would be better, none even better
all other phases need to be conjugated if need to change it
some producers screwed this up
need more docs
>> ACTION: I think we agreed that this would be good.
>> Someone needs to write it up so producers do it correctly.
>> decided to just remove +1 from the enum, so -1 is required.
12. /SICD/Grid/*/KCtr: Either rename to KOrigin (my preference) and force producers to make it constant across the image or make it variable across the image.
possible to make constant
currently specified as a constant, but it actually varies across the image
need to describe the variation across the image
cosmo-skymed/INCA: KCtr is const across the image,
but delta-KCOA is not, in spotlight mode
PFA with slant deskew
perhaps rename to KOrigin so less confusing, or KZero. Give good defn.
>> ACTION: Need to discuss again.
>> rename to KOrigin and allow to make it variable across the image.
>> can bascially reuse the description of deltaKOA-poly for this.
13. /SICD/Grid/*/DeltaK1 /SICD/Grid/*/DeltaK2: Remove
limits of spectral support of image in each direction, or nyquist,
whichever is smaller
not helpful, especially if doing part of an image
calculating by yourself is best
>> ACTION: remove
14. /SICD/Grid/*/DeltaKCOAPoly: Make required
everyone agreed to make it required.
can be zero, but must be specified
>> ACTION: make required
15. /SICD/Grid/*/WgtFunct and /SICD/Grid/*/WgtType:
Replace with required consolidated structure where WindowName
and WgtFunct are required or force uniform weighting.
change to have new class, including:
WgtFunct, WindowName, WtFunc
and make all required
>> ACTION: Someone needs to design this new structure, along with
>> corresponding documentation.
>> Leland volunteered
currently:
==========
WgtType (optional)
windowName (1) (reqd) text
parameter (1..n) (optional) text (expect string: name=value)
WgtFunc (optional)
Wgt (1..NW) (reqd) doubles, 1 for each index.
Proposed:
==========
Weighting (required)
windowName (reqd) (1) (reqd) text
parameter (reqd) (1..n) text (expect string: name=value)
Wgt (reqd) (1..NW) doubles, 1 for each index.
Need to come up with strategy for windowNames that have no parameters. Leland volunteered.
16. Add slowtime and frequency 4d grid
could take an hour to discuss
all possible if know image formation algo.
docs do not describe how to do it.
have provider do it using their image-formation-algo
general agreement, but need more details.
>> ACTION: Someone needs to come up with a plan to present to the group.
SCPGridIndex (4 numbers): Is the 4D grid index of the SCP and its Spectral
Origin (2 dimensional DC)
XRow spacing (1 number): The spacing in xrow (meters in the row dimension)
of the 4D grid
YCol spacing (1 number): The spacing in ycol (meters in the column
dimension) of the 4D grid
KRow spacing (1 number): The spacing in the Fourier space of the xrow
dimension (cycles/meter in the krow dimension) of the 4D grid
KCol spacing (1 number): The spacing in the Fourier space of the ycol
dimension (cycles/meter in the kcol dimension) of the 4D grid
SlowTimeGrid: A 4 dimensional raster of numbers that represent the slow-time
of that spectral point and image location
TxFrequency: A 4 dimensional raster of numbers that represent the transmit
frequency of that spectral point and image location
I do not expect these grids to be large. 4x4x4x4 would be plenty for most
applications. Some producers may want to provide more.
In terms of priorities, I think that the KOrigin polynomial or grid (whichever we
decide) is the most important and the 4D grid would be mostly pointless
without it.
Marc wants these to be required.
General agreement that this was a good idea.
Need to make more specific, with a text write-up as well.
17. /SICD/Timeline/CollectStart: Change to reference time
everyone agreed
>> ACTION: change the name.
18. /SICD/Timeline/CollectDuration: Remove
everyone agreed
>> ACTION: remove
19. /SICD/IPP: Make required?
difficult to generate from some providers
need better docs so it will be populated correctly
general agreement
>> ACTION: Someone needs to generate better documentation.
>> come back to….
Mike wrote this up:
Replacement of IPPPoly with PRF Poly
====================================
When working with a complex SAR image, the precise collection timing
is often not available. This accurate timing is also not necessary for
most exploitation of complex SAR imagery. The gross timing information
in the form of an instantaneous PRF is, however, quite useful. For
example, this can be used to determine the PRF target aliasing
parameters. For this reason, the IPPPoly metadata
specified in some formats (such as the NGA SICD standard) is not
supported in the IEEE standard. A PRFPoly is instead supported and
required. Specifying a PRF polynomial requires strictly less
information then an IPP polynomial as it’s the reciprocal of the
first-order derivative of the IPP polynomial.
20. /SICD/Antenna/TwoWay: Remove
agreed. just use 2 1-way’s
>> ACTION: remove
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
>> ACTION: Someone needs to make this more detailed.
>> Chuck volunteered
22. beamcomp
specify how applied: for example avg or specific beam value
>> ACTION: Someone needs to make this more detailed.
>> need to discuss more
Wade and Marc mentioned how current data products use different approaches and that they need harmonizing. In particular, dealing with the relationship between weighting and slow time beam comp.
Wade will work on.
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?
>> ACTIONS:
>> 23. move PFA under ImageFormation
>> 24. remove Krg
>> 25. Someone needs to make this more detailed.
>> Marc suggested we tell people to get this from KOrigin.
Keep STdeskew flag, but remove polynomial.
make KOrigin and deltaKCOAPoly required.
need to modify text explanations.
There was some discussion about these entries, and it was agreed that we should keep it as is.
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. dopCentroidPoly
redundant
range rate more relevant.
both can be calculated from geometry
>> ACTIONS:
>> 26. move RMA/INCA under ImageFormation
>> 27. Someone needs to make this more detailed.
>> 28. remove FreqZero
>> 29. remove dopCentroidPoly
>> Perhaps someone needs to write something explaining how to
>> calculate these from the geometry?
>> decided to just remove it. no explanation
For 27, someone needs to explain in the text how to get this parameter using other parameters.
For 29, there was agreement that it was redundant, possibly inconsistent, but so many people expect it that we need to explain how to generate it from other parameters.
Marc volunteered to make a first draft of the text, and presented it today:
The processed (COA) Doppler Centroid can be calculated for any point
in the image given the range-rate
(see SICD Vol 3 to compute the range-rate).
DopplerCentroid = -RangeRate * Fx_C * 2 / c
Leland: need to include in this text: where in the std to obtain RangeRate and Fx_C
discussion from last time:
— Marc: many providers provide this as a polynomial vs. range at difft slow times
which is not in SICD.
it was in SICD as a func of image location.
— Wade: do we want an eqn for dopplerCentroidRate?
— Marc: can get from dopplerratescalefactorpoly, in vol 1 of SICD.
(which is the 2nd deriv of range at COA)
we need to consider adding the ideas from this discussion.
31. decided to pick beta-0 as the provided data, with equations in
spec giving eqns to convert to others:
rcs, sigma0, gamma0
>> ACTION: Someone needs to write the part explaining that data is
>> provided as Beta0, giving the definition, and also explaining
>> how to convert to the others: rcs, sigma0, gamm0
>> Should already be there in the docs, maybe not the conversion part, as that
>> requires “other” information that is not part of the spec.
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
>> ACTION: Someone needs to make this more specific
>> decided that probably just having difft names for the
>> xmit and rcv antennas is good enough, as the other params are specific
>> enough that they work for mono- and bi-static.
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.
>> ACTION: Someone needs to make this more specific
>> since this can be arbitrarily complex,
>> and hence not useful to a computer program,
>> we decided that it should be free-form text. Useful to a human at least.
Discussion about how to actually attach such a variable to the parameters that need it.
Marc gave this list of possible parameters that could need this:
Nodes that could use a Data Quality Flag
—————————————-
/SICD/ImageFormation/PolarizationCalibration/Distortion
/SICD/Radiometric/NoiseLevel
/SICD/Radiometric/BetaZeroSFPoly
/SICD/Antenna/{Tx,Rcv}/EB
/SICD/Antenna/{Tx,Rcv}/{X,Y}AxisPoly
/SICD/Antenna/{Tx,Rcv}/Array
/SICD/Antenna/{Tx,Rcv}/Element
/SICD/Antenna/{Tx,Rcv}/GainBSPoly
/SICD/ErrorStatistics/CompositeSCP
/SICD/ErrorStatistics/Components/PosVelErr
/SICD/ErrorStatistics/Components/RadarSensor
/SICD/ErrorStatistics/Components/TropoError
/SICD/ErrorStatistics/Components/IonoError
— Wade: we already decided to make the flag be:
“precise”, “wild guess”, human-readable string
could put a numerical description if want to.
but could put into “error stats” instead.
flag: not the right term
description: better
— Marc: add this field within the structure for each of these.
in xml could add as an attribute.
— Chuck: must be clear what field this refers to.
must think about xml/json encoding eventually
— Wade: I’ll think about how/where to include this for
each of these terms.
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.
>> ACTION: 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.
>> ACTION: remove entirely
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 brought 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.
>> ACTION: Someone needs to explain this in the spec.
>> already there. just look at it and make sure…
Need to make sure that there is text for providers who ony have a 2-way that they need to split it into 2 1-ways.
42. matchinginfo:
agreed to remove
>> ACTION: Remove
Atmosphere:
43-45. add tropo/iono corrections
not 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
>> ACTION: Someone needs to make this more specific
>> use the ISO params for this for now:
CA_AtmosphericPropagationAndEarthMotion
attenuationModel string 0..1
attenuationModelParameters real 0..*
ionosphericDelayModel string 0..1
ionosphericDelayModelParameters real 0..*
troposphericDryDelayModel string 0..1
troposphericDryDelayModelParameters real 0..*
troposphericWetDelayModel string 0..1
troposphericWetDelayModelParameters real 0..*
FaradayRotationModel string 0..1
FaradayRotationModelParameters real 0..*
earthMotionModel string 0..1
earthMotionModelParameters real 0..*
Leland volunteered to look up these definitions, write text that describes each, and possibly decide on a subset of these that we would require. He would also find a place in the metadata structure to put these in.
Marc brought up the idea of making the models be a choice from a list, where the list is provided in some online registry of possible models. This would provide the opportunity to modify the registry when new models are proposed.
Grids:
Leland brought up 3 possible approaches to implementing grids:
1. separate arrays for coordinates and for values
2. single array that has coordinates and values together
3. coordinate spacings, where zero is, and array for values
general agreement on choice 3.
It was discussed that CPHD had an implementation of this that we could use.
Leland will look at that, and come up with an implementation, with a descriptive paragraph as to how to use it.
Marc also brought up the idea that we use direction-cosines, not angles, when we implement antenna patterns using the grid idea.
===================================
6. Elections
===================================
Leland brought up that we need to hold an election for the Chair.
He wants anyone that is interested to email him.
Wade volunteered to run.
Timeline: ballots emailed Nov 2. ballots returned to Marc by Nov 16. Results announced at next meeting.
===================================
7. Other business?
===================================
Wade asked about what he needs to be aware of for his transition to Chair.
Leland wrote a document which he sent to Wade, and briefly discussed.
Leland will send more files to Wade to help him get started.
===================================
8. Next meeting
===================================
Wednesday, January 19, 11AM
===================================
9. Adjourn
===================================
Wade moved, marc seconded.
no discussion.
passed,