require_qc parameter using /observations/latest

[paulnadler]

I am seeing inconsistent and confusing results using the quality control parameter and I can't find much documentation to reference how it is suppose to work.

For the following query's
https://api.weather.gov/stations/C3224/observations/latest
https://api.weather.gov/stations/C3224/observations/latest?require_qc=true
https://api.weather.gov/stations/C3224/observations/latest?require_qc=false

I sometimes get an error response when using the require_qc param, and no error when its omitted.

Other times require_qc=true or require_qc=false both return good data while omitting the param returns null values.

Or, all 3 return identical results.

I would have expected requrie_qc=false to be equivalent to omitting the param, which seems not to be the case. And when using requrie_qc=true, quality control should be more restrictive, but this also appears not to be the case.

Anyone know how this works or should work?

[dwhitemv25]

Hm, seems this parameter has problems only with non-ham CWOP stations. I tried it with an ASOS, RAWS, a ham CWOP station, and a couple of transportation stations and they come up OK, but the non-ham CWOP stations (both yours and mine) result in a 404. Might be something in the metadata in MADIS.

That said, if this is the MADIS QC data, it has to be taken with a grain of salt. MADIS uses a buddy check for one of the QC checks which depends on nearby stations being fairly homogenous (good siting and generally equivalent exposures). This works fine for AWOS/ASOS, but CWOP stations can represent a variety of microclimates which the buddy check doesn't understand and it will flag the station when nothing is actually wrong. For instance, I live in a wind-sheltered valley next to a creek, so the dewpoint is always higher here than at the nearby airport, and MADIS regularly flags it as suspect when it is not.

There's also an unmaintained CWOP station nearby that is dying a slow death, and sometimes MADIS thinks it is right and I am wrong ... but that is a story for another day.

[paulnadler]

Thanks for this info!

However, I still don't know what I should be doing to ignore QC and return all data. Sounds like omitting the QC flag is probably the right approach even though at times it causes all null values (while including QC returns valid results).

Perhaps the null values is an API bug since it seems the data IS returnable by the API.

[dwhitemv25]

Might just have to try it with the parameter and if you get a 404 then try again without.

The observations endpoint needs some dev time, that's for sure. On top of the known conversion issues and the unexpected NULL values, there's some issues in the METAR parser (it gets confused if wind gusts are reported). Hopefully it can get some attention.

[paulnadler]

I'm marking your response as the answer but I hope that doesn't cause the issue to be overlooked. Obviously this is a workaround which is the best we can do until it is fixed.