rerddap: rerddap
In rerddap: General Purpose Client for 'ERDDAP' Servers
rerddap R Documentation
rerddap
Description
General purpose R client for ERDDAP servers
ERDDAP info
NOAA's ERDDAP service holds many datasets of interest. It's built on top of
OPenDAP. You can search for datasets via
ed_search(), list datasets via ed_datasets(),
get information on a single dataset via info(), then get
data you want for either tabledap type via tabledap(), or
for griddap type via griddap()
tabledap/griddap
tabledap and griddap have different interfaces to query for data, so
tabledap() and griddap() are separated out as
separate functions even though some of the internals are the same. In
particular, with tabledap you can query on/subset all variables, whereas
with gridddap, you can only query on/subset the dimension varibles (e.g.,
latitude, longitude, altitude).
Data size
With griddap data via griddap() you can get a lot of
data quickly. Try small searches of a dataset to start to get a sense for
the data, then you can increase the amount of data you get. See
griddap() for more details.
Caching
rerddap by default caches the requests you make, so that if you happen to
make the same request again, the data is restored from the cache, rather than
having to go out and retrieve it remotely. For most applications, this is good,
as it can speed things up when doing a lot of request in a script, and works
because in most cases an ERDDAP request is "idempotent". This means that the
the request will always return the same thing no matter what requests came
before - it doesn't depend on state. However this is not true if the
script uses either "last" in griddap() or "now" in tabledap() as these
will return different values as time elapses and data are added to the
datasets. While it is desirable to have ERDDAP purely idempotent, the
"last" and "now" constructs are very helpful for people using ERDDAP
in dashboards, webpages, regular input to models and the like, and the
benefits far outweigh the problems. However, if you are using either "last"
or "now" in an rerddap based script, you want to be very careful to
clear the rerddap cache, otherwise the request will be viewed as the
same, and the data from the last request, rather than the latest data,
will be returned.
Author(s)
Maintainer: Roy Mendelssohn roy.mendelssohn@noaa.gov [contributor]
Authors:
Scott Chamberlain
Other contributors:
Ben Tupper [contributor]
Salvador Jesús Fernández Bejarano [contributor]
See Also
Useful links:
rerddap documentation built on July 4, 2024, 9:07 a.m.
R Package Documentation
Browse R Packages
We want your feedback!
Note that we can't provide technical support on individual packages. You should contact the package authors for that.
| rerddap | R Documentation |
rerddap
Description
General purpose R client for ERDDAP servers
ERDDAP info
NOAA's ERDDAP service holds many datasets of interest. It's built on top of
OPenDAP. You can search for datasets via
ed_search(), list datasets via ed_datasets(),
get information on a single dataset via info(), then get
data you want for either tabledap type via tabledap(), or
for griddap type via griddap()
tabledap/griddap
tabledap and griddap have different interfaces to query for data, so
tabledap() and griddap() are separated out as
separate functions even though some of the internals are the same. In
particular, with tabledap you can query on/subset all variables, whereas
with gridddap, you can only query on/subset the dimension varibles (e.g.,
latitude, longitude, altitude).
Data size
With griddap data via griddap() you can get a lot of
data quickly. Try small searches of a dataset to start to get a sense for
the data, then you can increase the amount of data you get. See
griddap() for more details.
Caching
rerddap by default caches the requests you make, so that if you happen to
make the same request again, the data is restored from the cache, rather than
having to go out and retrieve it remotely. For most applications, this is good,
as it can speed things up when doing a lot of request in a script, and works
because in most cases an ERDDAP request is "idempotent". This means that the
the request will always return the same thing no matter what requests came
before - it doesn't depend on state. However this is not true if the
script uses either "last" in griddap() or "now" in tabledap() as these
will return different values as time elapses and data are added to the
datasets. While it is desirable to have ERDDAP purely idempotent, the
"last" and "now" constructs are very helpful for people using ERDDAP
in dashboards, webpages, regular input to models and the like, and the
benefits far outweigh the problems. However, if you are using either "last"
or "now" in an rerddap based script, you want to be very careful to
clear the rerddap cache, otherwise the request will be viewed as the
same, and the data from the last request, rather than the latest data,
will be returned.
Author(s)
Maintainer: Roy Mendelssohn roy.mendelssohn@noaa.gov [contributor]
Authors:
Scott Chamberlain
Other contributors:
Ben Tupper [contributor]
Salvador Jesús Fernández Bejarano [contributor]
See Also
Useful links:
R Package Documentation
Browse R Packages
We want your feedback!
Note that we can't provide technical support on individual packages. You should contact the package authors for that.
Embedding an R snippet on your website
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.