WS2M not accessible through AG community

[danielreispereira]

The code below works, but if I change WS10M for WS2M, it returns an error:

""Error:
You have entered an invalid value for community for the supplied pars. One or more pars are not, available for AG, please check.""

get_power(community = "AG",
                         lonlat = c(-49.554,-20.862, -48.562, -19.851),
                         pars = c("PRECTOT", "T2M_MAX", "T2M_MIN", "T2M", "ALLSKY_SFC_SW_DWN", "RH2M", "T2MDEW", "WS10M"), 
                         dates = c("2018-01-01", paste0(Sys.Date())),
                         temporal_average = "DAILY")

[adamhsparks]

Hi Daniel,
Thanks for your report.

Did you check the availability as provided by NASA? See community below. This looks like a bug with NASA as the data for checking availability come directly from NASA, https://github.com/ropensci/nasapower/tree/master/data-raw, not from nasapower. AG does not appear but it lists the AG and ICASA units.

> library(nasapower)

> parameters$WS2M
$AG_Units
[1] "m/s"

$ICASA
[1] "WIND"

$POWER
[1] "WS2M"

$SB_Units
[1] "m/s"

$SSE_Units
[1] "m/s"

$ascii_format
[1] "%8s"   "%8.2f"

$calculated
[1] FALSE

$climatology_definition
[1] "The monthly average of wind speed at 2 meters above the surface of the earth for a given month, averaged for that month over the 30-year period (Jan. 1984 - Dec. 2013)."

$community
[1] "SB"  "SSE"

$daily_definition
[1] "The daily average of wind speed at 2 meters above the surface of the earth."

$include
[1] "CLIMATOLOGY" "INTERANNUAL" "DAILY"

$inputs
list()

$interannual_definition
[1] "The monthly average of the wind speed at 2 meters above the surface of the earth."

$json_format
[1] "%.2f"

$longname
[1] "Wind Speed at 2 Meters"

$source
     temporal    type                                                                                            url xchart
1       daily opendap                  https://opendap.larc.nasa.gov/opendap/POWER/daily/power_801_daily_ws2m_lst.nc   NULL
2 interannual opendap                   https://opendap.larc.nasa.gov/opendap/POWER/monthly/power_801_monthly_lst.nc   NULL
3 climatology opendap https://opendap.larc.nasa.gov/opendap/POWER/climatology/power_801_climatology_1984-2013_lst.nc   NULL
  xidentifier
1        NULL
2        NULL
3        NULL

$standard_name
[1] "Wind Speed at 2 Meters"

$type
[1] "meteorology"

Unfortunately right now I don't think you'll get any response with the shutdown. But once NASA corrects it I can remove the wontfix and update the list.

[adamhsparks]

You could put this at the top of your script.

library(nasapower)
parameters$W2SM$community <- c("AG", "SB", "SSE")

That should overwrite the in-package list that says it's not available since they do offer AG and ICASA units, that should be OK until NASA fixes it.

[danielreispereira]

Thanks Adam!
I'm using the workaround until the API is fixed. I understand and support the wont fix tag.
I will make the NASA team aware of this inconsistency.

[adamhsparks]

Thanks for your understanding, @danielreispereira

I'll also contact them since I wrote the package that uses their JSON file.

Soon as NASA is back and they fix the issue (assuming they fix it) I can update it and push to CRAN.

[danielreispereira]

Hi Adam,
See response below from the POWER developer.
I double-checked and confirm that the APIs links (http) work and the Rnasapower translation fails for WS2M.

update:

Dear Daniel Pereira,

The POWER developer found that the bug is with your application.

The request based on the data in your Ticket 32:
https://power.larc.nasa.gov/cgi-bin/v1/DataAccess.py?&request=execute&identifier=SinglePoint&parameters=PRECTOT,T2M_MAX,T2M_MIN,T2M,ALLSKY_SFC_SW_DWN,RH2M,T2MDEW,WS10M&startDate=20150101&endDate=20150305&userCommunity=AG&tempAverage=DAILY&outputList=JSON&lat=40.2133&lon=-74.2852

Please let us know if you have additional questions or if you have more information that may be helpful in solving the problem.

Warm Regards,
Michelle

# this works:
get_power(community = "AG",
                           lonlat = c(-49.554,-20.862, -48.562, -19.851),
                           pars = c("PRECTOT", "T2M_MAX", "T2M_MIN", "T2M", "ALLSKY_SFC_SW_DWN", "RH2M", "T2MDEW", "WS10M"),
                           dates = c("1985-01-01", paste0(Sys.Date())),
                           temporal_average = "DAILY")
# this fails:
get_power(community = "AG",
                           lonlat = c(-49.554,-20.862, -48.562, -19.851),
                           pars = c("PRECTOT", "T2M_MAX", "T2M_MIN", "T2M", "ALLSKY_SFC_SW_DWN", "RH2M", "T2MDEW", "WS2M"),
                           dates = c("1985-01-01", paste0(Sys.Date())),
                           temporal_average = "DAILY")

[adamhsparks]

Sorry, what? The bug is with the application? Meaning is nasapower causing this issue?

Disagree, see line 5590 here:
https://power.larc.nasa.gov/RADAPP/GEODATA/powerWeb/POWER_Parameters_v110.json

"AG" does not appear in this JSON file. I use that file to validate their data. This came directly from them.

Obviously the API works if my suggestion, parameters$W2SM$community <- c("AG", "SB", "SSE"), works. But their own metadata is incorrect, which is causing the issue here. I check all requests before submitting them to the server using their metadata to validate the request.

[adamhsparks]

I'm communicating with the POWER team about this. Apparently they didn't intend for this file to actually be used externally. I'm trying to find out from them what the preferred method for validation before sending a request is if not using this file.

[adamhsparks]

I've released v1.0.5 with a "fix" for this. The POWER team apparently do not intend for this JSON file to be used externally. However, upon asking there is no clear guidance from the POWER team about how to validate queries before sending them. So I've implemented the "fix", parameters$W2SM$community <- c("AG", "SB", "SSE") to apply to the included list used for validation purposes. See https://github.com/ropensci/nasapower/tree/master/data-raw for more.

Hopefully the POWER team can get back to me with a more desirable way of validation if this is not the best way. Until then, this should work.

[danielreispereira]

Thanks for the fix, Adam!