Skip to content

Added ImportPrecipitationRadarData.R#2

Open
LaMargna wants to merge 4 commits intomasterfrom
work_on_ImportPrecipitationRadarData
Open

Added ImportPrecipitationRadarData.R#2
LaMargna wants to merge 4 commits intomasterfrom
work_on_ImportPrecipitationRadarData

Conversation

@LaMargna
Copy link
Collaborator

This program imports precipitation data from a tree containg NetCDF files. The program assumes all NetCDF files relevant (no other types should be in the path). The program is designed to read from and save to a share pointed to by the environment variable ProjectData

LaMargna added 2 commits July 11, 2017 11:11
Commented out some code I blieve not yet needed
Made projection strings global (for now)
Closed open netcdf files when no more needed
added a function “makeCellfunction” that as a function of a netcdf file creates a function mapping the Dutch grid (global SOURCE string) to the polar stereographic coordinate in the TARGET string (not yet obtained from the netcdf)
This program imports precipitation data from a tree containg NetCDF files. The program assumes all NetCDF files relevant (no other types should be in the path). The program is designed to read from and save to a share pointed to by the environment variable ProjectData
@LaMargna
Copy link
Collaborator Author

ImportPrecipitationRadarData.R

The following R script is used to create a key value table tables
"Time", "X", "Y", "Precipitation"
from KNMI provided NetCDF files:
Product description of the KNMI precipitation radar

This program assumes the NetCDF files already to be downloaded (for instance from here) and decompressed into the directory pointed to by the environment variable "ProjectData" pointing to a share (part of a path at least), and from there in
directories "KNMI", "PrecipitationRadar", and "NetCDF", for instance ProjectData equals
"/Volumes/ProjectData", combined it would make /Volumes/ProjectData/KNMI/PrecipitationRadar/NetCDF/.
If the environment variable is not set, the data is assumed to be decompressed into
the path ProjectData/KNMI/PrecipitationRadar/ relative to where the program starts.
The envirionment variable also controls the output location. If not set
the path is KNMI/PrecipitationRadar/RData/ relative to where the program starts.

Currently, the zip files offered by KNMI are organized per year and month (and [ignored here] per hour).
This structure is assumed by the program: the program first determines a list of all
directories one level up from "NetCDF", and iterates over each of them.
Assuming these directories represent data for separate years, the program first checks
for the presence of a output dataset associated with that year. If it finds one, it
assumes that year is already processed and skips to the next directory (more about this below).
If the program assumes the year is not yet processed, it lists all subdirectories one
level up which it assumes to represent months of the year. In principle, the program
processes each month in turn, saves the monthly data in a separate file and concatenates
all per-month data and saves the annual aggregate data as well. If the program finds a
per-month data file, it loads the data just for concatenation, so in the end, the complete
aggregate annual data can be saved. This way it is relatively easy to add extra data once
new data becomes available (could be done more efficiently though).
If data needs to be replaced, either the output datasets can be deleted, or the function
check.file.exists below can be changed to return FALSE.

Currently the program uses the Parallel package to load the monthly NetCDF files in
parallel using the forking mechanism, so this might not work on windows machines.

It is unclear to me whether the time used in the file name is the beginning of the
5-minute interval or the end. This may not matter much, but anyway.

@LaMargna
Copy link
Collaborator Author

Yet another bug? I thought in "payload" (the matrix) in NetCDF files was in integer values. I suspect the ncvar_get already applies "_FillValue" (Most values returned by "ncvar_get" are NA, none are the _FillValue). As in our example the scale_factor equals 0.01, I was surprised to see values of 0.001.

Probably did not read the documentation properly, or mixed-up packages...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant