You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 14, 2024. It is now read-only.
I've used sweep_for_stations() to identify weather stations for which I wanted historical data and get_historical() to download the stations. However, the type of data is not standard for the station id values. sweep_for_stations() returns a character value with BOM's leading 0s, get_historical() returns a numeric value that strips the leading 0s, which is inconsistent across the package functions and makes it difficult to join tables where you may have the ID as a character value and numeric elsewhere.
@jonocarroll, was this your intended functionality? I'd prefer that the functions that share returned values follow a consistent approach if at all possible and @HughParsonage's handling of the station IDs makes more sense to me initially since the leading "0" and "00" have meaning, but I'm open to discussion.
The text was updated successfully, but these errors were encountered:
I'm not at a computer I can test with at the minute, but which output has the numeric value? Is that in the station attribute or the ncc_list$site attribute? The latter comes from e.g. http://www.bom.gov.au/climate/data/lists_by_element/alphaAUS_136.txt which are integer without padding, and that's my best guess at what's going on.
I've used
sweep_for_stations()
to identify weather stations for which I wanted historical data andget_historical()
to download the stations. However, the type of data is not standard for the station id values.sweep_for_stations()
returns a character value with BOM's leading 0s,get_historical()
returns a numeric value that strips the leading 0s, which is inconsistent across the package functions and makes it difficult to join tables where you may have the ID as a character value and numeric elsewhere.@jonocarroll, was this your intended functionality? I'd prefer that the functions that share returned values follow a consistent approach if at all possible and @HughParsonage's handling of the station IDs makes more sense to me initially since the leading "0" and "00" have meaning, but I'm open to discussion.
The text was updated successfully, but these errors were encountered: