1. Call to Order
\n2. Approval of Agenda
\n3. Approval of Minutes of previous mtg
\n4. IEEE Patent Policy
\n5. Discussion of Draft Standard
\n6. Other Business
\n7. Future Meetings
\n8. Adjourn<\/p>\n
Minutes of SAR Metadata Std Working Group Meeting
\nNov 19, 2020<\/p>\n
1. Call to order
\nattendees:
\nWade Schwartzkopf
\nMarc Trachy
\nMike Stewart
\nChuck Heazel<\/p>\n
===================================
\n2. Approval of agenda
\n===================================
\nNo voting<\/p>\n
===================================
\n3. Approval of minutes of previous meeting
\n===================================
\nNo voting<\/p>\n
===================================
\n4. IEEE Patent and Copyright Policy
\n===================================
\n1. slides 1-4 were shown and discussed by the chair
\n2. Chair provided an opportunity for participants to identify patent
\nclaim(s)\/patent application claim(s) and\/or the holder of patent
\nclaim(s)\/patent application claim(s) of which the participant is
\npersonally aware and that may be essential for the use of that
\nstandard.<\/p>\n
Wade announced that NGA and IEEE had come to an agreement on the use
\nof the SICD document as a starting point for the IEEE standard we are
\nworking on.<\/p>\n
===================================
\n5. Discussion of current draft standard
\n===================================
\nDiscuss details of what to do for some of the recent suggestions from Marc.<\/p>\n
All items are included, with those in red giving what was accomplished at the meeting.<\/p>\n
1. Replace \/SICD\/ImageCreation with a lineage
\ncurrent SICD image-creation metadata is limited, if change to
\nlineage can put more info there for humans.
\nneed exact details.
\nchuck has presented some ideas on this already.
\nchuck mentioned that error-popagation could also be added.
\nLeland: perhaps we need to survey other SAR formats for what they
\ninclude.
\n>> ACTION: Someone needs to make this more specific
\n>> Chuck volunteered
\nLooked at the XML that Chuck created for this.
\nSome felt this was nice, but too vague.
\nNo specific place for processing parameters.
\nGeneral agreement not to use it.<\/p>\n
2. Remove AMP8I_PHS8I (likely PixelType won\u2019t appear in the IEEE
\nversion anyway)
\nWade has seen it used, so wants to keep it.
\nthe ISO range-type could be used instead to describe the structure
\nof the data for each pixel.
\n>> ACTION: Someone needs to look at the ISO range-type and come up
\n>> with a way to use it instead of what is currently specified.
\n>> Chuck volunteered
\nAfter some discussion it was felt that we didn\u2019t 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.
\nDecided to make it be a choice between AMP_PHZ and RE_IM<\/p>\n
3. \/SICD\/ImageData\/ValidData:
\nMake required and to include no zero filled pixels,
\n(may discard some valid pixels for simplification)
\nChuck says that there is no ISO concept for this.
\n>> ACTION: make required.<\/p>\n
4. \/SICD\/ImageData\/SCPPixel: Allow to be non-integer
\nmake it real-valued
\ncenter of pixel in SICD
\nneed to look at implications to other metadata that uses line and
\ncolumn values
\nthe PHD std does this
\n>> ACTION: Someone needs to look at other metadata that is affected by
\n>> this change to make sure it works.<\/p>\n
-sees no problems<\/span> <\/p>\n 5. \/SICD\/GeoData\/EarthModel: Replace with an ITRF version? 6. \/SICD\/GeoData\/GeoInfo: Remove 7. \/SICD\/Grid\/ImagePlane: Remove 8. \/SICD\/Grid\/Type: Document which ones can go with which image formation algorithms 9. \/SICD\/Grid\/TimeCOAPoly: Document more precise definition of center 10. \/SICD\/Grid\/*\/ImpRespWid: Remove Removal of ImpRespWid<\/span> The ImpRespWid parameter found in both the Row and Col components of<\/span> Removal of the ImpRespWid should prevent this common misuse and<\/span> discussion:<\/span><\/p>\n — Wade: all agree reasonable.<\/span> <\/p>\n 11. \/SICD\/Grid\/*\/Sgn: Remove (force -1, producers must conjugate if they would have had +1) 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. 13. \/SICD\/Grid\/*\/DeltaK1 \/SICD\/Grid\/*\/DeltaK2: Remove 14. \/SICD\/Grid\/*\/DeltaKCOAPoly: Make required 15. \/SICD\/Grid\/*\/WgtFunct and \/SICD\/Grid\/*\/WgtType: WgtFunc (optional) Proposed: Need to come up with strategy for windowNames that have no parameters. Leland volunteered.<\/p>\n 16. Add slowtime and frequency 4d grid SCPGridIndex (4 numbers): Is the 4D grid index of the SCP and its Spectral General agreement that this was a good idea. 17. \/SICD\/Timeline\/CollectStart: Change to reference time 18. \/SICD\/Timeline\/CollectDuration: Remove 19. \/SICD\/IPP: Make required? Replacement of IPPPoly with PRF Poly<\/span> When working with a complex SAR image, the precise collection timing<\/span> discussion:<\/span> <\/p>\n 20. \/SICD\/Antenna\/TwoWay: Remove 21. ErrorStats 22. beamcomp PFA: Keep STdeskew flag, but remove polynomial. RMA\/INCA For 27, someone needs to explain in the text how to get this parameter using other parameters.<\/p>\n The processed (COA) Doppler Centroid can be calculated for any point<\/span> DopplerCentroid = -RangeRate * Fx_C * 2 \/ c<\/span><\/p>\n discussion:<\/span> <\/p>\n 31. decided to pick beta-0 as the provided data, with equations in bistatics: philosophical issues: Discussion about how to actually attach such a variable to the parameters that need it.<\/p>\n Nodes that could use a Data Quality Flag<\/span> \/SICD\/ImageFormation\/PolarizationCalibration\/Distortion<\/span> — Wade: we already decided to make the flag be:<\/span> <\/p>\n 37. segmentList depends on grid. 38. RadarCollection: 39,40,41: 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.<\/p>\n 42. matchinginfo: Atmosphere: CA_AtmosphericPropagationAndEarthMotion<\/p>\n attenuationModel string 0..1 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.<\/p>\n Grids: =================================== none<\/p>\n =================================== no decision<\/p>\n =================================== no voting<\/p>\n","protected":false},"excerpt":{"rendered":" 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 Nov 19, 2020 1. Call to order attendees: Wade Schwartzkopf Marc Trachy Mike […]<\/p>\n","protected":false},"author":87,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-581","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/sagroups.ieee.org\/sar\/wp-json\/wp\/v2\/posts\/581","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sagroups.ieee.org\/sar\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sagroups.ieee.org\/sar\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sagroups.ieee.org\/sar\/wp-json\/wp\/v2\/users\/87"}],"replies":[{"embeddable":true,"href":"https:\/\/sagroups.ieee.org\/sar\/wp-json\/wp\/v2\/comments?post=581"}],"version-history":[{"count":0,"href":"https:\/\/sagroups.ieee.org\/sar\/wp-json\/wp\/v2\/posts\/581\/revisions"}],"wp:attachment":[{"href":"https:\/\/sagroups.ieee.org\/sar\/wp-json\/wp\/v2\/media?parent=581"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sagroups.ieee.org\/sar\/wp-json\/wp\/v2\/categories?post=581"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sagroups.ieee.org\/sar\/wp-json\/wp\/v2\/tags?post=581"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n>> Wade volunteerd, and presented his analysis today:<\/span><\/p>\n
\n-most everything uses real numbers anyway.<\/span>
\n-irow\/icol uses it, but would work just fine with a real number<\/span><\/p>\n
\ncurrently required to be wgs84.
\nwgs84 is not precise enough in its definition for some applications
\nreplacing with a specific ITRF would be better
\n>> ACTION: Someone needs to look at what ITRF does and tell the group
\n>> what they think about using it. In particular, what \u201cstrings\u201d do we
\n>> allow for the value of this parameter?
\n>> Marc volunteered
\nAdd a new parameter: EarthModel_GPSWeekNumber, string
\nlike: G730<\/p>\n
\nthis is basically a list of \u201clat, lon, feature description\u201d
\nlargely NGA-specific
\neveryone agreed to remove it.
\n>> ACTION: remove it<\/p>\n
\nan enumeration: SLANT, GROUND, other
\nhistorically has been poorly-populated: inaccurate
\nhowever, may still be useful for some applications
\n>> ACTION: keep, but someone needs to provide better guidance in the document
\n>> concerning how to populate it in a variety of circumstances.
\n>> Leland volunteered
\nremoved cylindrical and nadir.
\nPossible additional language:
\n\u201cThis field is meant to be approximate, for humans rather than
\ncomputation. Hence, SLANT may mean the slant plane instantaneous at
\nthe center-of-aperture time, or an average across the aperture, or similar
\nideas.
\nAlso, 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.
\nUse OTHER if none of these comes close to what is used.\u201d<\/p>\n
\ninfo in V3. perhaps include in our std?
\n>> ACTION: Need to discuss again.
\n>> Marc volunteered
\nMarc documented this:
\nRGAZIM: PFA and RGAZCOMP
\nRGZERO: RMA\/INCA
\nXRGYCR: Any
\nXCTYAT: Any
\nPLANE: Any
\nDecided to limit the use of these to \u201cany image formation algorithm that natively produces this grid-type.\u201d<\/p>\n
\nof aperture time
\nOK
\n>> ACTION: Some one needs to write this definition.
\n>> \u201cTime which corresponds to the center of the spectral support.\u201d<\/p>\n
\nmost other stds have this, but not useful
\nmaybe just add more docs on how to use it?
\ncode exists on github.
\n>> ACTION: Need to discuss this again
\n>> really want to get rid of it, since it\u2019s imprecise and used in stupid ways.
\n>> perhaps write up how to use the correct param (the spectral BW) instead?<\/p>\n
\nMike volunteered to write up an explanation for this, and presented today:<\/span><\/p>\n
\n=====================<\/span><\/p>\n
\nthe Grid metadata have been removed. The motivation for this change is<\/span>
\nthe extensive misuse and misunderstanding of this SICD field. A<\/span>
\nfundamental limit on the utility of complex SAR imagery is the<\/span>
\nbandwidth of that imagery. This is conveyed by the ImpRespBW<\/span>
\nmetadata item. Many users of SICD data instead chose to use the<\/span>
\nImpRespWid over the ImpRespBW, even going so far as to compute the<\/span>
\nbandwidth from the stated width. Unfortunately, the ImpRespWid has a<\/span>
\nvariable relationship to the bandwidth. This relationship is dependent<\/span>
\non the weighting applied in the frequency domain. Despite this, many<\/span>
\nusers would use the ImpRespWid of two different complex images to<\/span>
\ncompare their bandwidth. This is obviously only valid if the data is<\/span>
\nidentically weighted. Furthermore, this parameter includes only one of<\/span>
\nthe many factors that can impact a point target’s impulse response<\/span>
\nwidth. Other effects not included in the ImpRespWid computation are<\/span>
\nphase errors, RF amplitude profiles, and uncompensated antenna<\/span>
\neffects. Ideally, these would all be removed in the image formation<\/span>
\nprocessing, but that is not required by the SICD standard. Despite<\/span>
\nthis, the ImpRespWid was frequently misused as the expected width of a<\/span>
\npoint target’s IPR and this misuse was both frequent and<\/span>
\nunderstandable.<\/span><\/p>\n
\nencourage the use of the fundamental ImpRespBW parameter. As the<\/span>
\nnominal resolution can be extracted by simply inverting the bandwidth,<\/span>
\nit should not be onerous.<\/span><\/p>\n
\n— Wade: do we want to add equation how to get imprespwid from a bw given a<\/span>
\nperfect ipr and some weighting factor?<\/span>
\n— Mike: which imprespwid do they want? We should carefully define it.<\/span>
\nantenna pattern, phase errors, other effects…<\/span>
\npeople may use incorrectly<\/span>
\n— Marc: “for example: for the uniform weighting case, your half-power width is blah.”<\/span><\/p>\n
\nSICD has 2: 1 for row, 1 for col
\nonly 1 would be better, none even better
\nall other phases need to be conjugated if need to change it
\nsome producers screwed this up
\nneed more docs
\n>> ACTION: I think we agreed that this would be good.
\n>> Someone needs to write it up so producers do it correctly.
\n>> decided to just remove +1 from the enum, so -1 is required.<\/p>\n
\npossible to make constant
\ncurrently specified as a constant, but it actually varies across the image
\nneed to describe the variation across the image
\ncosmo-skymed\/INCA: KCtr is const across the image,
\nbut delta-KCOA is not, in spotlight mode
\nPFA with slant deskew
\nperhaps rename to KOrigin so less confusing, or KZero. Give good defn.
\n>> ACTION: Need to discuss again.
\n>> rename to KOrigin and allow to make it variable across the image.
\n>> can bascially reuse the description of deltaKOA-poly for this.<\/p>\n
\nlimits of spectral support of image in each direction, or nyquist,
\nwhichever is smaller
\nnot helpful, especially if doing part of an image
\ncalculating by yourself is best
\n>> ACTION: remove<\/p>\n
\neveryone agreed to make it required.
\ncan be zero, but must be specified
\n>> ACTION: make required<\/p>\n
\nReplace with required consolidated structure where WindowName
\nand WgtFunct are required or force uniform weighting.
\nchange to have new class, including:
\nWgtFunct, WindowName, WtFunc
\nand make all required
\n>> ACTION: Someone needs to design this new structure, along with
\n>> corresponding documentation.
\n>> Leland volunteered
\ncurrently:
\n==========
\nWgtType (optional)
\nwindowName (1) (reqd) text
\nparameter (1..n) (optional) text (expect string: name=value)<\/p>\n
\nWgt (1..NW) (reqd) doubles, 1 for each index.<\/p>\n
\n==========
\nWeighting (required)
\nwindowName (reqd) (1) (reqd) text
\nparameter (reqd) (1..n) text (expect string: name=value)
\nWgt (reqd) (1..NW) doubles, 1 for each index.<\/p>\n
\ncould take an hour to discuss
\nall possible if know image formation algo.
\ndocs do not describe how to do it.
\nhave provider do it using their image-formation-algo
\ngeneral agreement, but need more details.
\n>> ACTION: Someone needs to come up with a plan to present to the group.<\/p>\n
\nOrigin (2 dimensional DC)
\nXRow spacing (1 number): The spacing in xrow (meters in the row dimension)
\nof the 4D grid
\nYCol spacing (1 number): The spacing in ycol (meters in the column
\ndimension) of the 4D grid
\nKRow spacing (1 number): The spacing in the Fourier space of the xrow
\ndimension (cycles\/meter in the krow dimension) of the 4D grid
\nKCol spacing (1 number): The spacing in the Fourier space of the ycol
\ndimension (cycles\/meter in the kcol dimension) of the 4D grid
\nSlowTimeGrid: A 4 dimensional raster of numbers that represent the slow-time
\nof that spectral point and image location
\nTxFrequency: A 4 dimensional raster of numbers that represent the transmit
\nfrequency of that spectral point and image location
\nI do not expect these grids to be large. 4x4x4x4 would be plenty for most
\napplications. Some producers may want to provide more.
\nIn terms of priorities, I think that the KOrigin polynomial or grid (whichever we
\ndecide) is the most important and the 4D grid would be mostly pointless
\nwithout it.
\nMarc wants these to be required.<\/p>\n
\nNeed to make more specific, with a text write-up as well.<\/p>\n
\neveryone agreed
\n>> ACTION: change the name.<\/p>\n
\neveryone agreed
\n>> ACTION: remove<\/p>\n
\ndifficult to generate from some providers
\nneed better docs so it will be populated correctly
\ngeneral agreement
\n>> ACTION: Someone needs to generate better documentation.
\n>> come back to\u2026.
\n
\nMike volunteered to work on, and he presented this today:<\/span><\/p>\n
\n====================================<\/span><\/p>\n
\nis often not available. This precise timing is also not necessary for<\/span>
\nmost exploitation of complex SAR imagery. The gross timing information<\/span>
\nin the form of an instantaneous PRF is, however, quite useful. For<\/span>
\nexample, this can be used to determine the PRF target aliasing<\/span>
\nparameters and also infer vibration rates for imaged targets<\/span>
\nexhibiting paired echoes. For this reason, the IPPPoly metadata<\/span>
\nspecified in some formats (such as the NGA SICD standard) is not<\/span>
\nsupported in the IEEE standard. A PRFPoly is instead supported and<\/span>
\nrequired. Specifying a PRF polynomial requires strictly less<\/span>
\ninformation then an IPP polynomial as it’s the reciprocal of the<\/span>
\nfirst-order derivative of the IPP polynomial.<\/span><\/p>\n
\n— Wade: I didnt associate precise timing with absolute timing<\/span>
\n— Mike: maybe “accurate” should be used instead of “precise”<\/span>
\n— Mike: when did pulse start? someimtes don’t know.<\/span>
\ninformation probably not needed in this std.<\/span>
\n— Wade: agrees<\/span>
\nDo we want vibration rates in here?<\/span>
\n— Mike: can remove it.<\/span><\/p>\n
\nagreed. just use 2 1-way\u2019s
\n>> ACTION: remove<\/p>\n
\ncurrently ecf posn uncertainty not required, but offset reqd for scp in image domain.
\nextend to radiometric and polarization params
\nneed a confidence measure: a string
\n>> ACTION: Someone needs to make this more detailed.
\n>> Chuck volunteered<\/p>\n
\nspecify how applied: for example avg or specific beam value
\n>> ACTION: Someone needs to make this more detailed.
\n>> need to discuss more
\nGet Wade to work on it.<\/p>\n
\n23. move under ImageFormation\u2026 no argument
\n24. Krg, etc
\noriginally interpolated spatial freq extents
\nnot useful to anybody.
\nno argument against removal
\n25. STdeskew
\ncurrently: a flag if applied or not, plus a polynomial
\ncan get from deltaKCOA
\nif a deskew has been applied that is not STdeskew, what then?
\n>> ACTIONS:
\n>> 23. move PFA under ImageFormation
\n>> 24. remove Krg
\n>> 25. Someone needs to make this more detailed.
\n>> Marc suggested we tell people to get this from KOrigin.<\/p>\n
\nmake KOrigin and deltaKCOAPoly required.
\nneed to modify text explanations.<\/p>\n
\n26. move under ImageFormation\u2026 no argument
\n27. R_CA_SCP
\nredundant, potentially incorrect
\nerror has been noted to be 0.5m for some formats that also provide
\ntie points.
\n28. FreqZero
\nnot needed if remove dopcentroidpoly
\n29. dopCentroidPoly
\nredundant
\nrange rate more relevant.
\nboth can be calculated from geometry
\n>> ACTIONS:
\n>> 26. move RMA\/INCA under ImageFormation
\n>> 27. Someone needs to make this more detailed.
\n>> 28. remove FreqZero
\n>> 29. remove dopCentroidPoly
\n>> Perhaps someone needs to write something explaining how to
\n>> calculate these from the geometry?
\n>> decided to just remove it. no explanation<\/p>\n
\nFor 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.
\nMarc volunteered to make a first draft of the text, and presented it today:<\/span><\/p>\n
\nin the image given the range-rate<\/span>
\n(see SICD Vol 3 to compute the range-rate).<\/span><\/p>\n
\n— Marc: many providers provide this as a polynomial vs. range at difft slow times<\/span>
\nwhich is not in SICD.<\/span>
\nit was in SICD as a func of image location.<\/span>
\n— Wade: do we want an eqn for dopplerCentroidRate?<\/span>
\n— Marc: can get from dopplerratescalefactorpoly, in vol 1 of SICD.<\/span>
\n(which is the 2nd deriv of range at COA)<\/span><\/p>\n
\nspec giving eqns to convert to others:
\nrcs, sigma0, gamma0
\n>> ACTION: Someone needs to write the part explaining that data is
\n>> provided as Beta0, giving the definition, and also explaining
\n>> how to convert to the others: rcs, sigma0, gamm0
\n>> Should already be there in the docs, maybe not the conversion part, as that
\n>> requires \u201cother\u201d information that is not part of the spec.<\/p>\n
\nsome discussion as to whether to make this part of the std or just
\nstick to monostatic. no decision.
\nissue is that one needs to know it\u2019s bistatic to process the metadata
\ncorrectly.
\ninstead: metadata should make it clear
\n(32-35)
\nbasically require that illuminator and receiver have names
\nthat way if the same, know its monostatic.
\nmake tx and rcv apc polynomials required and dump arp-poly since its
\nnot precise enough.
\nprobably need to add more params for this, including:
\nerror-stats,
\nredefine scpcoa
\nneeds further discussion
\n>> ACTION: Someone needs to make this more specific
\n>> decided that probably just having difft names for the
\n>> xmit and rcv antennas is good enough, as the other params are specific
\n>> enough that they work for mono- and bi-static.<\/p>\n
\n36. do we require the producer to make guesses when info is less than
\nperfect? Can we devise a reasonable set of possibilities for how the
\nguess was arrived at?
\nneed to do for params related to:
\nantenna
\ncal
\nerrors
\n\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2014\u2013
\nsome of the things we are considering making required are only
\nrequired for specific applications. keep optional?
\nan example: antenna pattern:
\nif only have 3db beamwidth, can provide a sampled pattern that
\nshows this, sampled sparsely.
\nor, knowing the kind of antenna, could provide a modeled version if
\nthe pattern has not been measured
\nor, have in-lab measured but not attached to platform
\nor, have in-lab measured and attached to platform
\nor, have a field-campaign that measured the pattern during the
\nmission: once or many times.
\netc.
\n\u2014\u2014\u2014\u2014\u2014
\nThis can potentially be an arbitrary process that was used to create
\nthe \u201cestimate\u201d. so how can we capture that?
\n\u2014\u2014\u2014\u2014\u2013
\nfor cal, for example, lets say there is an AGC somewhere, and it is
\nnot captured in the metadata, so there is no way to compare numbers
\nbetween different datatakes, only relative (agc is constant for a
\ndatatake). not likely an issue for modern sensors, but for conversion
\nof old data to this std.
\n>> ACTION: Someone needs to make this more specific
\n>> since this can be arbitrarily complex,
\n>> and hence not useful to a computer program,
\n>> we decided that it should be free-form text. Useful to a human at least.<\/p>\n
\nMarc volunteered to come up with a list of possible parameters that could need this, and presented it today:<\/span><\/p>\n
\n—————————————-<\/span><\/p>\n
\n\/SICD\/Radiometric\/NoiseLevel<\/span>
\n\/SICD\/Radiometric\/BetaZeroSFPoly<\/span>
\n\/SICD\/Antenna\/{Tx,Rcv}\/EB<\/span>
\n\/SICD\/Antenna\/{Tx,Rcv}\/{X,Y}AxisPoly<\/span>
\n\/SICD\/Antenna\/{Tx,Rcv}\/Array<\/span>
\n\/SICD\/Antenna\/{Tx,Rcv}\/Element<\/span>
\n\/SICD\/Antenna\/{Tx,Rcv}\/GainBSPoly<\/span>
\n\/SICD\/ErrorStatistics\/CompositeSCP<\/span>
\n\/SICD\/ErrorStatistics\/Components\/PosVelErr<\/span>
\n\/SICD\/ErrorStatistics\/Components\/RadarSensor<\/span>
\n\/SICD\/ErrorStatistics\/Components\/TropoError<\/span>
\n\/SICD\/ErrorStatistics\/Components\/IonoError<\/span><\/p>\n
\n“precise”, “wild guess”, human-readable string<\/span>
\ncould put a numerical description if want to.<\/span>
\nbut could put into “error stats” instead.<\/span>
\nflag: not the right term<\/span>
\ndescription: better<\/span>
\n— Marc: add this field within the structure for each of these.<\/span>
\nin xml could add as an attribute.<\/span>
\n— Chuck: must be clear what field this refers to.<\/span>
\nmust think about xml\/json encoding eventually<\/span>
\n— Wade: I’ll think about how\/where to include this for<\/span>
\neach of these terms.<\/span><\/p>\n
\nsince the segmentList is related to data that is not part of this
\nfile, it seems that the data catalog is the best place to find
\nrelated data instead of putting it here.
\nagreement to remove.
\n>> ACTION: Remove<\/p>\n
\nsome params are related to the collection and NOT this specific
\ndata-file.
\nsuch as collectDuration as opposed to processedDuration
\ngeneral agreement that this should be removed.
\nneed a more specific suggestion that goes into each param in
\nRadarCollection.
\n>> ACTION: remove entirely<\/p>\n
\nrequire 2 1-way patterns and dump the 2-way pattern
\nthis simplifies code that is using this
\n2 1-ways is also more useful for some applications where only one
\nof the patterns is relevant.
\nMike Stewart brought up a particular example with cosmoskymed
\nwhere only the 2-way is provided, and the pattern is quite messy
\ndue to the multiplication of 2 different 1-way patterns.
\nneed to explain why 2 1-way is better\/required in the spec.
\n>> ACTION: Someone needs to explain this in the spec.
\n>> already there. just look at it and make sure\u2026<\/p>\n
\nagreed to remove
\n>> ACTION: Remove<\/p>\n
\n43-45. add tropo\/iono corrections
\nnot relevant for older, low-res systems,
\nbut most new systems are doing this, and users need to know what
\nthey did so they can un-do\/re-do as needed.
\nneeds further effort
\n>> ACTION: Someone needs to make this more specific
\n>> use the ISO params for this for now:<\/p>\n
\nattenuationModelParameters real 0..*
\nionosphericDelayModel string 0..1
\nionosphericDelayModelParameters real 0..*
\ntroposphericDryDelayModel string 0..1
\ntroposphericDryDelayModelParameters real 0..*
\ntroposphericWetDelayModel string 0..1
\ntroposphericWetDelayModelParameters real 0..*
\nFaradayRotationModel string 0..1
\nFaradayRotationModelParameters real 0..*
\nearthMotionModel string 0..1
\nearthMotionModelParameters real 0..*<\/p>\n
\nLeland brought up 3 possible approaches to implementing grids:
\n1. separate arrays for coordinates and for values
\n2. single array that has coordinates and values together
\n3. coordinate spacings, where zero is, and array for values
\ngeneral agreement on choice 3.
\nLeland will come up with a more specific implementation.<\/p>\n
\n6. Other business?
\n===================================<\/p>\n
\n7. Next meeting
\n===================================<\/p>\n
\n8. Adjourn
\n===================================<\/p>\n