search

ropensci / weathercan

R package for downloading weather data from Environment and Climate Change Canada
https://docs.ropensci.org/weathercan
GNU General Public License v3.0
102 stars 29 forks source link

Error in if (tz <= 0) tz <- paste0("+", abs(tz)) else tz <- paste0("-", : argument is of length zero #59

Closed durraniu closed 5 years ago

durraniu commented 6 years ago

First of, thank you for creating this package.

Now, about the error: I am trying to run the following code: 

library(weathercan)
> kam <- weather_dl(station_ids = 51423, start = "2016-01-01", end = "2016-02-15")
Error in if (tz <= 0) tz <- paste0("+", abs(tz)) else tz <- paste0("-",  : 
  argument is of length zero

Here's the traceback: 

Error in if (tz <= 0) tz <- paste0("+", abs(tz)) else tz <- paste0("-", : argument is of length zero
 3. tz_calc(coords = unique(preamble[, c("lat", "lon")]), etc = TRUE)
 2. weather_format(w = w, interval = interval, tz_disp = tz_disp, string_as = string_as, quiet = quiet, preamble = preamble)
 1. weather_dl(station_ids = 51423, start = "2016-01-01", end = "2016-02-15")

I have tried different station_ids and start & end but get the same error.

steffilazerte commented 6 years ago

Ugh, thanks for the bug report! We were calling on a Google API to infer the local timezone, but a) Google has stopped allowing keyless access and b) we didn't have a graceful catch for when the check with google failed.

I think the most elegant fix will be to use a timezone shapefile to grab the timezones and have a fallback to UTC. I'll see what I can do!

steffilazerte commented 6 years ago

Hmm, actually this problem just went away, perhaps it was a small blip with Google API? At any rate, I'll put in a fail safe and perhaps look into a self-contained solution for the future. Thanks for alerting us to this!

boshek commented 6 years ago

One option is to use the lutz package: https://cran.r-project.org/web/packages/lutz/index.html

steffilazerte commented 6 years ago

Hmm, that's not a bad idea either!

boshek commented 6 years ago

Possibly a less fragile solution.

durraniu commented 6 years ago

Thank you for your kind responses. I just checked, and yes, I no longer get any error. This is a great package, thank you!

ebourlon commented 6 years ago

Hi Umair, I'm getting the same error. How do you use the lutz package to solve the issue with the timezone? Thanks! E.

ebourlon commented 6 years ago

Good morning, tz_calc is returning timezone this morning. I've heard google might have set a quota for its api applications. But I am now getting another error: kam <- weather_dl(station_ids = 51423, start = "2016-01-01", end = "2016-02-15") Error in filter_impl(.data, quo) : Evaluation error: invalid argument type. Any idea? Thanks

ebourlon commented 6 years ago

Ok. I've reinstall the package using install.packages("weathercan") instead of devtools::install_github("ropensci/weathercan") and t's working good. Thanks for that package again. It saves me so much time in getting EC data.

steffilazerte commented 6 years ago

Glad it's working for you! the tz_calc error is an intermittent problem with accessing google timezones, if you run into again, the best you can do right now is just wait an hour or two and see if it clears up. However, we're definitely hoping to get that fixed on our end soon!

ebourlon commented 6 years ago

Thanks! The weathercan package is such a useful tool. Hopefully ECCC and google changes will not make it too hard to maintain. E.

On Thu, Sep 20, 2018, 12:04 Steffi LaZerte notifications@github.com wrote:

Glad it's working for you! the tz_calc error is an intermittent problem with accessing google timezones, if you run into again, the best you can do right now is just wait an hour or two and see if it clears up. However, we're definitely hoping to get that fixed on our end soon!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ropensci/weathercan/issues/59#issuecomment-423217565, or mute the thread https://github.com/notifications/unsubscribe-auth/AZoPHnvKFl-iau7Un3I3sGf7IA0o3GDgks5uc66EgaJpZM4V2CNj .

ebourlon commented 6 years ago

Thanks for reopening ! Behavior of the tz google app is very random. I'm using the Lutz package in some of my scripts and it's working nice. E.

On Fri, Oct 5, 2018, 10:10 Steffi LaZerte notifications@github.com wrote:

Reopened #59 https://github.com/ropensci/weathercan/issues/59.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ropensci/weathercan/issues/59#event-1887109839, or mute the thread https://github.com/notifications/unsubscribe-auth/AZoPHlLqPBKKuSysCh9dogH8f-2FZ4TZks5uh1pTgaJpZM4V2CNj .

steffilazerte commented 6 years ago

I agree, it's getting worse. I'm working on it right now. I'd love for you to take a look at it once I get it working, let me know how it goes for you! I'll let you know when the fix is posted :)

ebourlon commented 6 years ago

Sure. I'll test it. E.

On Fri, Oct 5, 2018, 10:50 Steffi LaZerte notifications@github.com wrote:

I agree, it's getting worse. I'm working on it right now. I'd love for you to take a look at it once I get it working, let me know how it goes for you! I'll let you know when the fix is posted :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ropensci/weathercan/issues/59#issuecomment-427372618, or mute the thread https://github.com/notifications/unsubscribe-auth/AZoPHj_8FHcvkQy2fAhgPnEWaQ7vq7Bxks5uh2OTgaJpZM4V2CNj .

steffilazerte commented 6 years ago

Alright! The stations data frame now includes a timezone column and I've added lutz to suggested dependencies, so that users who update the stations data frame will also get timezones. This way the weather_dl function doesn't have to calculate timezones each time, it can just look it up in the stations data frame. Hopefully this will keep things from slowing down.

If you have a moment, could you test a couple things for me?

# Update to the dev version:
library(devtools)
install_github("ropensci/weathercan", ref = "dev")

library(weathercan)

# 1. Test general download
w <- weather_dl(station_ids = 51423, start = "2014-01-01", end = "2014-01-31")

# 2. Test stations download
# (I don't expect that this function is often used, but may be relevant to some users)
s <- stations_dl()

The second task will take longer, and you might get a message asking you to install a package if you don't already have it.

Thank you!

ebourlon commented 6 years ago

So far it worked on not-so-recent but up-to-date macbooks pro under R version 3.4.1 (2017-06-30) -- "Single Candle". I've tested weather_dl, station_dl and stations_search (we use it a lot) for various coordinate and repeated commands 10 times in a row: no problem, always got an answer.

I have not been able to run it on our macMinis because devtools cannot be installed. I've tried on our ubuntu linux box but I'm getting trouble installing the lutz package on it (because of V8 install pb). I'm working on it. I know it can be installed on it because I've done it under our shiny R app server profile.

Thanks for your time on this package. We almost can't do anything without it ! We use it to evaluate stability of the atmosphere for plume modelisation. E.

Le ven. 5 oct. 2018 à 12:19, Steffi LaZerte notifications@github.com a écrit :

Alright! The stations data frame now includes a timezone column and I've added lutz to suggested dependencies, so that users who update the stations data frame will also get timezones. This way the weather_dl function doesn't have to calculate timezones each time, it can just look it up in the stations data frame. Hopefully this will keep things from slowing down.

If you have a moment, could you test a couple things for me?

Update to the dev version:

library(devtools) install_github("ropensci/weathercan", ref = "dev")

library(weathercan)

1. Test general download

w <- weather_dl(station_ids = 51423, start = "2014-01-01", end = "2014-01-31")

2. Test stations download

(I don't expect that this function is often used, but may be relevant to some users)

s <- stations_dl()

The second task will take longer, and you might get a message asking you to install a package if you don't already have it.

Thank you!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ropensci/weathercan/issues/59#issuecomment-427402174, or mute the thread https://github.com/notifications/unsubscribe-auth/AZoPHiSE3hKZ54zCx9nYw-iVYveRtGqsks5uh3iOgaJpZM4V2CNj .

boshek commented 6 years ago

Works for me @steffilazerte

What is the thinking behind not using the standard name and rather the offset?

> lutz::tz_lookup_coords(52.2, -112., method = "accurate")
[1] "America/Edmonton"
steffilazerte commented 6 years ago

@ebourlon I'm glad to hear it works and that you're finding it so helpful! It seems to be passing most tests, just some problems with systems that can't install the sf and lutz.

Remember that you should be able to run both windows_dl() and stations_search() without having to install lutz and sf. You only need to extra packages if you're going to use stations_dl().

@boshek Glad to hear it's working! I use the offset rather than the Olson names because the Olson names include daylight savings (where it exists), whereas the offset does not. This matches the data from ECCC which is in the local timezone without daylight savings.

ebourlon commented 6 years ago

It worked also on our ubunto box under R version 3.4.2 (2017-09-28) -- "Short Summer".

Thanks! E.

Le ven. 5 oct. 2018 à 13:07, Evelise B evelise.bourlon@gmail.com a écrit :

So far it worked on not-so-recent but up-to-date macbooks pro under R version 3.4.1 (2017-06-30) -- "Single Candle". I've tested weather_dl, station_dl and stations_search (we use it a lot) for various coordinate and repeated commands 10 times in a row: no problem, always got an answer.

I have not been able to run it on our macMinis because devtools cannot be installed. I've tried on our ubuntu linux box but I'm getting trouble installing the lutz package on it (because of V8 install pb). I'm working on it. I know it can be installed on it because I've done it under our shiny R app server profile.

Thanks for your time on this package. We almost can't do anything without it ! We use it to evaluate stability of the atmosphere for plume modelisation. E.

Le ven. 5 oct. 2018 à 12:19, Steffi LaZerte notifications@github.com a écrit :

Alright! The stations data frame now includes a timezone column and I've added lutz to suggested dependencies, so that users who update the stations data frame will also get timezones. This way the weather_dl function doesn't have to calculate timezones each time, it can just look it up in the stations data frame. Hopefully this will keep things from slowing down.

If you have a moment, could you test a couple things for me?

Update to the dev version:

library(devtools) install_github("ropensci/weathercan", ref = "dev")

library(weathercan)

1. Test general download

w <- weather_dl(station_ids = 51423, start = "2014-01-01", end = "2014-01-31")

2. Test stations download

(I don't expect that this function is often used, but may be relevant to some users)

s <- stations_dl()

The second task will take longer, and you might get a message asking you to install a package if you don't already have it.

Thank you!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ropensci/weathercan/issues/59#issuecomment-427402174, or mute the thread https://github.com/notifications/unsubscribe-auth/AZoPHiSE3hKZ54zCx9nYw-iVYveRtGqsks5uh3iOgaJpZM4V2CNj .

ebourlon commented 6 years ago

For people who might have trouble with the install of lutz: I've installed libv8-dev on our server first (sudo apt-get install libv8-dev). Then the lutz package got installed smoothly.

boshek commented 6 years ago

@steffilazerte got it. Should we then use UTC and not GMT?

steffilazerte commented 6 years ago

No, it's has to be a recognized timezone name under OlsonNames(), which means it has to be in the format of Etc/GMT+-XX:

> grep("Etc", OlsonNames(), value = TRUE)
 [1] "Etc/GMT"       "Etc/GMT0"      "Etc/GMT-0"     "Etc/GMT+0"     "Etc/GMT-1"     "Etc/GMT+1"    
 [7] "Etc/GMT-10"    "Etc/GMT+10"    "Etc/GMT-11"    "Etc/GMT+11"    "Etc/GMT-12"    "Etc/GMT+12"   
[13] "Etc/GMT-13"    "Etc/GMT-14"    "Etc/GMT-2"     "Etc/GMT+2"     "Etc/GMT-3"     "Etc/GMT+3"    
[19] "Etc/GMT-4"     "Etc/GMT+4"     "Etc/GMT-5"     "Etc/GMT+5"     "Etc/GMT-6"     "Etc/GMT+6"    
[25] "Etc/GMT-7"     "Etc/GMT+7"     "Etc/GMT-8"     "Etc/GMT+8"     "Etc/GMT-9"     "Etc/GMT+9"    
[31] "Etc/Greenwich" "Etc/UCT"       "Etc/Universal" "Etc/UTC"       "Etc/Zulu"

Also note that the offset (i.e. -10 or +10) is actually counter-intuitive (the number is the opposite sign than what you'd expect).

E.g., from https://en.wikipedia.org/wiki/Tz_database#Area:

The special area of "Etc" is used for some administrative zones, particularly for "Etc/UTC" which represents Coordinated Universal Time. In order to conform with the POSIX style, those zone names beginning with "Etc/GMT" have their sign reversed from the standard ISO 8601 convention. In the "Etc" area, zones west of GMT have a positive sign and those east have a negative sign in their name (e.g "Etc/GMT-14" is 14 hours ahead of GMT.)

boshek commented 5 years ago

@steffilazerte Given the unique status of Newfoundland, do you anticipate any issues with this?

"Etc/GMT+3.5" %in% OlsonNames()
#> [1] FALSE
steffilazerte commented 5 years ago

Ugh, that is a problem because although there are no errors (with POSIXct), it's treated as UTC, which is fine, generally speaking but misleading if you don't know that:

library(lubridate)

t <- as.POSIXct("2011-01-01 12:00:00", tz = "Etc/GMT+3.5")
t
# [1] "2011-01-01 12:00:00 Etc"

with_tz(t, tz = "Etc/GMT+4")
# [1] "2011-01-01 08:00:00 -04"
with_tz(t, tz = "Etc/GMT+3")
# [1] "2011-01-01 09:00:00 -03"
with_tz(t, tz = "Etc/GMT+2")
# [1] "2011-01-01 10:00:00 -02"

t <- as.POSIXct("2011-01-01 12:00:00", tz = "UTC")
t
# [1] "2011-01-01 12:00:00 UTC"

with_tz(t, tz = "Etc/GMT+4")
# [1] "2011-01-01 08:00:00 -04"
with_tz(t, tz = "Etc/GMT+3")
# [1] "2011-01-01 09:00:00 -03"
with_tz(t, tz = "Etc/GMT+2")
# [1] "2011-01-01 10:00:00 -02"

In the end this probably means that we'll have to change everything to just use UTC. I can't think of another way to introduce timezones without daylight savings.

ebourlon commented 5 years ago

Hi Steffi, I keep getting this message: Error in 1:grep("Date/Time", preamble$V1) : argument of length 0 when using weather_dl. It was still working ok yesterday. I've updated the package this morning but it did not fix the issue. Any idea? Thanks! E.

Le jeu. 20 sept. 2018 à 12:04, Steffi LaZerte notifications@github.com a écrit :

Glad it's working for you! the tz_calc error is an intermittent problem with accessing google timezones, if you run into again, the best you can do right now is just wait an hour or two and see if it clears up. However, we're definitely hoping to get that fixed on our end soon!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ropensci/weathercan/issues/59#issuecomment-423217565, or mute the thread https://github.com/notifications/unsubscribe-auth/AZoPHnvKFl-iau7Un3I3sGf7IA0o3GDgks5uc66EgaJpZM4V2CNj .

steffilazerte commented 5 years ago

Hi @ebourlon, this error is actually related to another issue (see #83). I'm hoping to have a fix posted soon.

ebourlon commented 5 years ago

Thanks. Yes sorry it is a new issue. Thanks for the package again! E.

On Fri, Sep 27, 2019, 10:36 Steffi LaZerte notifications@github.com wrote:

Hi @ebourlon https://github.com/ebourlon, this error is actually unrelated to this issue (see #83 https://github.com/ropensci/weathercan/issues/83). I'm hoping to have a fix posted soon.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ropensci/weathercan/issues/59?email_source=notifications&email_token=AGNA6HUOBYFQXC5QRVMPXZLQLYD7HA5CNFSM4FOYENR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7Y5KTQ#issuecomment-535942478, or mute the thread https://github.com/notifications/unsubscribe-auth/AGNA6HVK7BZVNEHZTW5TPQDQLYD7HANCNFSM4FOYENRQ .

steffilazerte commented 5 years ago

@ebourlon, if you get the chance, the fix has been posted to the master branch:

install.packages("remotes")
remotes::install_github("ropensci/weathercan")

Then test as you would normally:

library(weathercan)
kam <- weather_dl(station_ids = 51423, start = "2016-01-01", end = "2016-02-15")
kam
ebourlon commented 5 years ago

Thanks! You're fast. I'll try it asap.

I've been using the riem package lately that deliver airport metar reports. I have noticed that since at least a year many ECCC airport stations only report bad weather in the weather description. These stations are Navcan stations as well and complete weather is provided in metar reports. Unfortunately the riem package is not as nice as yours. No station search by distance or data mining tools. I've made my own functions to work around but I did not have your skills!

Thanks again for the quick response. E.

On Fri, Sep 27, 2019, 21:23 Steffi LaZerte notifications@github.com wrote:

@ebourlon https://github.com/ebourlon, if you get the chance, the fix has been posted to the master branch:

install.packages("remotes") remotes::install_github("ropensci/weathercan")

Then test as you would normally:

library(weathercan) kam <- weather_dl(station_ids = 51423, start = "2016-01-01", end = "2016-02-15") kam

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ropensci/weathercan/issues/59?email_source=notifications&email_token=AGNA6HTRX5QZZ5JLVZMGG43QL2PZBA5CNFSM4FOYENR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD72MAAI#issuecomment-536133633, or mute the thread https://github.com/notifications/unsubscribe-auth/AGNA6HU24OK6SPT2A7PF4LTQL2PZBANCNFSM4FOYENRQ .

steffilazerte commented 5 years ago

We're on CRAN now, you can update with install.packages("weathercan"). Good luck!

ebourlon commented 5 years ago

Thank you. It's working now.

They messed up the metadata.... stations_search("ESTEVAN A") return 3 stations ID which is correct, but station id 54261 has a wrong start year for the hourly record. This station only contains hourly data from 2018, not 2015. This lead to no data when querying that station. Probably not the only typo in the database.

E.

Le dim. 29 sept. 2019 à 14:44, Steffi LaZerte notifications@github.com a écrit :

We're on CRAN now, you can update with install.packages("weathercan"). Good luck!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ropensci/weathercan/issues/59?email_source=notifications&email_token=AGNA6HTE4TL35C4KP7VMHFDQMDSQZA5CNFSM4FOYENR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD732QIA#issuecomment-536324128, or mute the thread https://github.com/notifications/unsubscribe-auth/AGNA6HRPKXKTF5NZDSD47WLQMDSQZANCNFSM4FOYENRQ .

steffilazerte commented 5 years ago

Are you sure? It starts late, but I got data from November 2015:

w <- weather_dl(54261)
summary(w$date)

##         Min.      1st Qu.       Median         Mean      3rd Qu.         Max. 
## "2015-11-27" "2016-11-11" "2017-10-28" "2017-10-28" "2018-10-14" "2019-09-29"
ebourlon commented 5 years ago

I was looking for hourly data in the summer to late October 2015. It is available from station 53520 and not 54261. When I do a search of station, I am getting 4 stations with data in 2015. I use to subset for end and start date, non NA WMO and shortest distance. Only one is returned. And when I look for data, there are none. This works most of the time so far with the updated ECCC database.

station <- stations_search(coords = c(49.21,-102.97), dist = 10, interval="hour") station

A tibble: 4 x 15

prov station_name station_id climate_id WMO_id TC_id lat lon elev tz interval start end normals distance

1 SK ESTEVAN A 53520 4012401 NA YEN 49.2 -103. 580. Etc/GMT+6 hour 2015 2018 FALSE 0 2 SK ESTEVAN A 54261 4012403 71862 YEN 49.2 -103. 580. Etc/GMT+6 hour 2015 2019 FALSE 0 3 SK ESTEVAN 49728 4012410 71559 PJM 49.2 -103. 581. Etc/GMT+6 hour 2011 2019 FALSE 1.11 4 SK ESTEVAN A 2896 4012400 NA NA 49.2 -103. 580. Etc/GMT+6 hour 1953 2015 FALSE 1.11 station <- subset(station,start <=2015 & end >=2015 & WMO_id !="NA" &distance ==min(station$distance)) station # A tibble: 1 x 15 prov station_name station_id climate_id WMO_id TC_id lat lon elev tz interval start end normals distance 1 SK ESTEVAN A 54261 4012403 71862 YEN 49.2 -103. 580. Etc/GMT+6 hour 2015 2019 FALSE 0 weather_dl(station$station_id, start= "2015-08-17", end="2015-09-05") There are no data for station 54261, in this time range (2015-08-17 to 2015-09-05), for this interval (hour), Available Station Data: # A tibble: 2 x 14 prov station_name station_id climate_id WMO_id TC_id lat lon elev tz interval start end normals 1 SK ESTEVAN A 54261 4012403 71862 YEN 49.2 -103. 580. Etc/GMT+6 day 2018 2019 FALSE 2 SK ESTEVAN A 54261 4012403 71862 YEN 49.2 -103. 580. Etc/GMT+6 hour 2015 2019 FALSE # A tibble: 0 x 0

On Mon, Sep 30, 2019, 11:50 Steffi LaZerte notifications@github.com wrote:

Are you sure? It starts late, but I got data from November 2015:

w <- weather_dl(54261) summary(w$date)

Min. 1st Qu. Median Mean 3rd Qu. Max.

"2015-11-27" "2016-11-11" "2017-10-28" "2017-10-28" "2018-10-14" "2019-09-29"

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ropensci/weathercan/issues/59?email_source=notifications&email_token=AGNA6HVD7PB7R3TW4IWJRPDQMIGZ5A5CNFSM4FOYENR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD755JRA#issuecomment-536597700, or mute the thread https://github.com/notifications/unsubscribe-auth/AGNA6HW3JW2JAD6AKDGUX7LQMIGZ5ANCNFSM4FOYENRQ .

steffilazerte commented 5 years ago

Right, the data doesn't start until November 27th 2015. The start year of 2015 is technically correct (i.e. not a typo), the problem is that 2015 isn't a complete year and the data you're looking for is earlier in the year. Unfortunately this level of detail isn't available in the stations data frame. So you won't know the exact start date until you download the data yourself :(

ebourlon commented 5 years ago

It's the exact same location, ECCC could maybe merge the data carefully. The weird thing is that it was not causing trouble until they change the time format. E.

Le lun. 30 sept. 2019 à 13:03, Steffi LaZerte notifications@github.com a écrit :

Right, the data doesn't start until November 27th 2015. The start year of 2015 is technically correct (i.e. not a typo), the problem is that 2015 isn't a complete year and the data you're looking for is earlier in the year. Unfortunately this level of detail isn't available in the stations data frame. So you won't know the exact start date until you download the data yourself :(

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ropensci/weathercan/issues/59?email_source=notifications&email_token=AGNA6HW25DTW5FHW3MPMWMTQMIPMTA5CNFSM4FOYENR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD76FRBY#issuecomment-536631431, or mute the thread https://github.com/notifications/unsubscribe-auth/AGNA6HTIJ6DJ3S2S3OVU2DTQMIPMTANCNFSM4FOYENRQ .

steffilazerte commented 5 years ago

Ahh, I see your problem. Well, I'm glad the package is working for you at least! Any specific questions regarding the data itself are best sent to ECCC, good luck!

ebourlon commented 5 years ago

another question: we're not able to use both function weather_dl and station_dl on our linux server. We are getting that message:

kam <- weather_dl(station_ids = 51423,

  • start = "2016-01-01", end = "2016-02-15") Error: Evaluation error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none.

s <- stations_dl() Error: Evaluation error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none.

It's working on all the windows and mac computers on the same network. Other packages that get remote data are still working. Have you ever seen this? Any idea?

Thanks, E.

Le lun. 30 sept. 2019 à 13:11, Steffi LaZerte notifications@github.com a écrit :

Ahh, I see your problem. Well, I'm glad the package is working for you at least! Any specific questions regarding the data itself are best sent to ECCC, good luck!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ropensci/weathercan/issues/59?email_source=notifications&email_token=AGNA6HQ6V5YMCHJ4TMCQRN3QMIQMPA5CNFSM4FOYENR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD76GL7Y#issuecomment-536634879, or mute the thread https://github.com/notifications/unsubscribe-auth/AGNA6HVPNMM7APMEHOPX3O3QMIQMPANCNFSM4FOYENRQ .

ebourlon commented 5 years ago

Maybe some clues: I can download the data using http but there is a certificate pb when using https. Both are working fine on mac R version.

t <- fread(" http://climate.weather.gc.ca/climate_data/bulk_data_e.html?format=csv&stationID=1706&Year=2018&Month=10&Day=14&timeframe=1", fill=TRUE) trying URL ' http://climate.weather.gc.ca/climate_data/bulk_data_e.html?format=csv&stationID=1706&Year=2018&Month=10&Day=14&timeframe=1 ' downloaded 65 KB

Warning message: In download.file(input, tmpFile, method = method, mode = "wb", quiet = !showProgress) : downloaded length 66620 != reported length 0

t <- fread(" https://climate.weather.gc.ca/climate_data/bulk_data_e.html?format=csv&stationID=1706&Year=2018&Month=10&Day=14&timeframe=1", fill=TRUE) Error in curl::curl_download(input, tmpFile, mode = "wb", quiet = !showProgress) : server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

E.

Le mar. 1 oct. 2019 à 10:01, Evelise B evelise.bourlon@gmail.com a écrit :

another question: we're not able to use both function weather_dl and station_dl on our linux server. We are getting that message:

kam <- weather_dl(station_ids = 51423,

  • start = "2016-01-01", end = "2016-02-15") Error: Evaluation error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none.

s <- stations_dl() Error: Evaluation error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none.

It's working on all the windows and mac computers on the same network. Other packages that get remote data are still working. Have you ever seen this? Any idea?

Thanks, E.

Le lun. 30 sept. 2019 à 13:11, Steffi LaZerte notifications@github.com a écrit :

Ahh, I see your problem. Well, I'm glad the package is working for you at least! Any specific questions regarding the data itself are best sent to ECCC, good luck!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ropensci/weathercan/issues/59?email_source=notifications&email_token=AGNA6HQ6V5YMCHJ4TMCQRN3QMIQMPA5CNFSM4FOYENR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD76GL7Y#issuecomment-536634879, or mute the thread https://github.com/notifications/unsubscribe-auth/AGNA6HVPNMM7APMEHOPX3O3QMIQMPANCNFSM4FOYENRQ .

steffilazerte commented 5 years ago

I suspect it isn't a weathercan issue but rather a problem with the certificates on your server. For example: https://stackoverflow.com/questions/21181231/server-certificate-verification-failed-cafile-etc-ssl-certs-ca-certificates-c. If you want to pursue this further as a weathercan problem, open a new issue and we can troubleshoot from there.

ebourlon commented 5 years ago

Thanks Steffi. I'll work on it. I have already done all what is on that page. I guess our server is messed up..... To many users with admin priviledges.

Waethercan works perfect. Thanks for keeping it updated.

E.

On Wed, Oct 2, 2019, 17:35 Steffi LaZerte notifications@github.com wrote:

I suspect it isn't a weathercan issue but rather a problem with the certificates on your server. For example: https://stackoverflow.com/questions/21181231/server-certificate-verification-failed-cafile-etc-ssl-certs-ca-certificates-c. If you want to pursue this further as a weathercan problem, open a new issue and we can troubleshoot from there.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ropensci/weathercan/issues/59?email_source=notifications&email_token=AGNA6HTIWIZRVUIU4PGRFBDQMUAX7A5CNFSM4FOYENR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAGC4AY#issuecomment-537669123, or mute the thread https://github.com/notifications/unsubscribe-auth/AGNA6HXCV4VHEGTLUNPRRGDQMUAX7ANCNFSM4FOYENRQ .

ebourlon commented 5 years ago

Package is working again on our ubuntu servers. Adding climate.weather.gc.ca security certificate to our ca-certificates file fixed the "Error: Evaluation error: server certificate verification failed" issue.

steffilazerte commented 5 years ago

Great, glad to hear it worked out! I'm going to reference this conversation in a new issue to make it easier for people to find if they're searching for a similar problem.

ebourlon commented 5 years ago

I'll will post the recipe for Ubuntu server. E.

On Thu, Oct 3, 2019, 16:31 Steffi LaZerte notifications@github.com wrote:

Great, glad to hear it worked out! I'm going to reference this conversation in a new issue to make it easier for people to find if they're searching for a similar problem.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ropensci/weathercan/issues/59?email_source=notifications&email_token=AGNA6HRZ25AQICEKG2PLAJ3QMZCBVA5CNFSM4FOYENR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAJKAPA#issuecomment-538091580, or mute the thread https://github.com/notifications/unsubscribe-auth/AGNA6HUU2V33CAJZJW25HSLQMZCBVANCNFSM4FOYENRQ .