STP above 1000 is set to 1000-STP?

[barryrowlingson]

STP values typically range around the 1000 milibars value, but it seems that values over around 1000 are wrapped back to zero. At least for the site data I've got. This might be because somewhere 999.9 is being used as a missing value, but when true values of 999.9 are possible these are instead set to 0, so that 999.9 = 0 and 1000 =0.1? That's a guess.... STP of 0 (anything below 800s) are physically impossible...

Example:

> s1 = get_GSOD(years =2013, station ="030020-99999")
> plot(s1$STP)

Shows a scatter plot with numbers up in the high 900s and some in the low tens...

> s1$STP
  [1] 988.0   1.7   8.2  16.9  20.4  19.6  12.8  11.9   7.0  15.5  15.8  19.0
 [13]  13.9   8.4  11.4  10.8  14.8  12.5  11.7   8.1  12.2  15.0  14.0  14.7
 [25]   0.5 989.5 970.5 976.0 975.9 964.4 992.7 998.0   9.4 989.3 974.8 980.6

Fix could be to add 1000 (or is it 999.9?) to any values below 500. Maybe some docs on the source web site about this, maybe I'll download the raw data later and see...

[barryrowlingson]

have just downloaded 2013.tar.gz from the source, it has STP code this way - ie with small values that look like they should be over 999.9, but then SLP (sea level pressure) seems to range freely over 999.9 so I'm not sure how (if?) missing values are encoded in SLP. Documetation is sparse...

[barryrowlingson]

Using GSODtools https://github.com/environmentalinformatics-marburg/GSODTools data values for STP that are eg 7.4 are returned as 1007.4 so it looks like a 1000 offset. The raw download that GSODtools uses returns a fixed-width column file, with STP correctly specified within.

GSODtools downloads a gzipped fixed-width file via ftp:

Link: ftp://ftp.ncdc.noaa.gov/pub/data/gsod/2013/032380-99999-2013.op.gz

STN--- WBAN   YEARMODA    TEMP       DEWP      SLP        STP       VISIB      WDSP     MXSPD   GUST    MAX     MIN   PRCP   SNDP   FRSHTT
032380 99999  20130101    39.3 24    35.2 24  1000.7 24   983.4 24   16.6 24   14.8 24   21.0  999.9    41.9    36.5*  0.02G 999.9  000000
032380 99999  20130102    44.7 24    42.8 24  1015.9 24   998.5 24   16.5 24    8.6 24   15.9  999.9    51.3*   36.5   0.00G 999.9  010000
032380 99999  20130103    50.6 23    47.9 23  1024.7 23  1007.4 23   19.0 23   13.3 23   22.0  999.9    51.8*   48.9*  0.10G 999.9  000000

whereas GSODR gets a CSV from an https address... I think its a processing fault at the GSOD end...

[adamhsparks]

Thanks for letting me know about this, @barryrowlingson.

[fdetsch]

@barryrowlingson Copying from the ISD format document:

That being said, I believe @adamhsparks is on it, see d8ea9fd169c9b40e99ccd0ea721e4dd38893b8bd and following 😉

[adamhsparks]

Thanks, @fdetsch. The GSOD README does not say anything about a scaling factor.

In the Overview it just says:

STP - Mean station pressure (.1 mb)

In the DETAILS/FORMAT it has:

FIELD            DESCRIPTION
STP - Mean station pressure for the day in millibars to tenths. Missing = 9999.9

STP_ATTRIBUTES - Number of observations used in calculating mean station pressure. 

So there's nothing about scaling in the data here. Something is up as @barryrowlingson suggests with the processing to create the CSV file.

[adamhsparks]

Directly from the CSV, they've somehow lopped off the "1" for values >1000 and just provided a text column with leading zeros. Note that the SLP is not affected by this.

"SLP", "SLP_ATTRIBUTES", "STP", "STP_ATTRIBUTES"
"1014.1","23","012.3","23"

[adamhsparks]

The new release, https://github.com/ropensci/GSODR/releases/tag/v4.1.0, should be on CRAN very shortly with this bug fix.