5-02-01 Methods (atmosphere) - Radar

[joergklausen]

should be called differently, e.g., Radar (general), as only the endpoint is shown in OSCAR/Surface.

[toakley76]

I agree. I assume we already have unspecified under 'observing methods'. The observing method should just be RADAR. The Method details can be used to capture whether it is a Klystron or Magnetron.

[joergklausen]

WMDS_Validation_Report_158_Radar_Method_v0.1.docx
Review requested from Urs Germann, Daniel Michelson and Mustafa Sert (contacted by e-mail).

[toakley76]

The report implies that I said that this sub-group of metadata could be dropped but not exactly correct. For other observing methods (i.e. radiosonde manufacture model) we use the Method Details to capture the additional metadata on the 'type' of instrument and I can't see why radar does not do the same.

[IgorZahumensky]

I agree with Tim that the same/consistent approach/methodology be used in all cases; otherwise there will be just an additional "issue" to deal with later on.

[DanielMichelson]

I don't see a clear motive for characterizing radar type according to transmitter type. Intuitively, when looking at the hierarchy illustrated by the Select method, radar could stand alone without further sub-typing. But ...
There are assumptions in doing so, like we are only focussed on operational systems. Even so, it's unclear to me whether sub-typing by basic capability, e.g. whether it is a scanning or vertically profiling radar, is relevant in this context.
Generally, however, if some form of sub-typing is desired, and the typing is linked with technical capabilities, I would think that knowing whether a radar has Doppler or polarimetric (which includes Doppler) capabilities is more valuable than knowing what kind of transmitter it has. Also, I think wavelength (X,C,S) is more useful information than transmitter type.
Ideally, radars would be typed according to what primary information they provide, ie. what the driver for acquiring them is and who their priority users are. I'm thinking of "types" like weather surveillance, severe weather applications, hydrology, disaster risk reduction. This is easier said than done, and probably not what you're asking for.

[joergklausen]

WMDS_Validation_Report_158_Radar_Method_v0.2.docx
@DanielMichelson please approve or suggest further changes.

[toakley76]

Looks good to me. I concur with this report.

[toakley76]

Sorry not my role to close the issue.

[steingod]

This solution makes sense to me.

[joergklausen]

Email comment Mustafa Sert: I requested to add to "Solid State" as sub-type of Radar Transmitter type a few months ago, because in WMO Radar Database, some Focal Points defined their Radars transmitter type as "Solid state". Also, some of them don't define their radar, so that I need "unspecified". According to WRD records, 10 radars defined as Solid State. (310 Klystron, 558 Magnetron, 135 Undefined). I'm not a radar expert. I don't know who offered "Transmitter Type" entry in WRD in 2011 while developping the WRD project in the begining, but I think IPET-OWR and related experts were aware it.
As a chair of IPET-OWR, if Daniel thinks this information is unnecessary, you can remove it from OSCAR Table, and I change or remove it from the WRD portal. Another option is doesn't mapping this field from WRD to OSCAR table. I respect your decision.

[joergklausen]

Validation report accepted by peers

[joergklausen]

Comment from Marco Gabella: "I write you on behalf of Urs, after having read your word file WMDS_Validation_Report_158_Radar_Method_v0.2.docx dated 5.5.20
and having discussed with Dr. M. Sartori, who reads us in cc.

To the best of my understanding, if associated to the code “RADAR”

• A)There was only 1 type of sub-entry, namely 325 magnetron, 326 klystron and 341 unspecified, you could drop such single level of sub-entry;
• B) There were several sub-entries, then one of these sub-entries could carry the info regarding the type of transmitter (magnetron, klystron, solid state, TR- cells of a Phased Array RADAR, … , unspecified, … )"

[amilan17]

Correct branch: https://github.com/wmo-im/wmds/tree/issue-158

[amilan17]

Conclusion and Recommendation (copied from WMDS_Validation_Report_158_Radar_Method_v0.2.docx)

Notation	Name	Path	Definition
325	Magnetron	\Atmosphere\Precipitation\Remote-sensing, active\Radio detection and ranging (Radar)\Magnetron
326	Klystron	\Atmosphere\Precipitation\Remote-sensing, active\Radio detection and ranging (Radar)\Klystron
341	unspecified	\Atmosphere\Precipitation\Remote-sensing, active\Radio detection and ranging (Radar)\ unspecified

Removal (rather than obsoleting) is considered acceptable in this case.
Existing entries for METHOD_ID 325 or 326 in OSCAR/Surface should be changed to 183 (Radar). The information on the type of transmitter (Klystron vs Magnetron) should be migrated to the METHOD_DETAILS_USER_TX field in OSCAR/Surface that is presently not populated. For future submissions of the Turkish WMO Radar database (WRD), appropriate arrangements should be agreed to be able to map information correctly in OSCAR/Surface.

[amilan17]

@joergklausen The branch changes may/may not be consistent with decision. Please review.

https://github.com/wmo-im/wmds/blob/issue-158/tables_en/5-02-01.csv

deleted

325 | \Atmosphere\Precipitation\Remote-sensing, active\Radio detection and ranging (Radar)\Magnetron | Magnetron
326 | \Atmosphere\Precipitation\Remote-sensing, active\Radio detection and ranging (Radar)\Klystron | Klystron

added

183, \Atmosphere\Precipitation\Remote-sensing, active\Radio detection and ranging (Radar) profiler, Radio detection and ranging (Radar) profiler

[toakley76]

The final statement above makes sense to me, and was what we agreed. Just Radar (under Remote-sensing, active) is defined as the observing method. Additional information on the type of transmitter can be added (if known) into the method_details_user_tx field.

[amilan17]

This issue needs clarification. We cannot delete terms without following a deprecation process.
This is what I think makes the most sense:

1. keep the following terms and add descriptions
   325,\Atmosphere\Precipitation\Remote-sensing, active\Radio detection and ranging (Radar)\Magnetron,Magnetron
   326,\Atmosphere\Precipitation\Remote-sensing, active\Radio detection and ranging (Radar)\Klystron,Klystron

2. add
   183, \Atmosphere\Precipitation\Remote-sensing, active\Radio detection and ranging (Radar) profiler, Radio detection and ranging (Radar) profiler

[joergklausen]

Element 183 in https://github.com/wmo-im/wmds/blob/issue-158/tables_en/5-02-01.csv must be called 'Radio detection and ranging (Radar)'. This element used to be a parent (of 325 and 326), but is now to become an endpoint.
@amilan17 Tables 1-01-x and 5-02-x are implemented in OSCAR/Surface as tables with self-referencing entries. That is why you didn't find 183 before, even though it existed. Only elements without children (aka, endpoints) can be assigned as observed variables; however, any (intermediate) parent can be selected in a search. For the codes registry, only the endpoints matter, as these are the individual elements with a notation and a name. That is why these tables 1-01-x and 5-02-x contain an additional column 'path', which gives the context.

The recommendation by the domain experts was to eliminate 325 and 326, as well as of course 341. I think this should be respected. If you need to deprecate them, then please do it.

[amilan17]

removed "profiler" from 183

[amilan17]

@joergklausen @KarlBureau -- please review the branch to verify that it's ready for fast-track.

https://github.com/wmo-im/wmds/blob/issue-158/tables_en/5-02-01.csv

deleted
325 | \Atmosphere\Precipitation\Remote-sensing, active\Radio detection and ranging (Radar)\Magnetron | Magnetron
326 | \Atmosphere\Precipitation\Remote-sensing, active\Radio detection and ranging (Radar)\Klystron | Klystron

added
183, \Atmosphere\Precipitation\Remote-sensing, active\Radio detection and ranging (Radar), Radio detection and ranging (Radar)

In the codes registry, 183 will supersede 325 and 326. There was no term with the notation of 341 to delete.

[joergklausen]

Thank you @amilan17 This is ready for FT.

[amilan17]

Approved by FT 2020-2