There are holes in the IEM Mesonet plot, including April 10-11 2004.

I should be able to generate that plot for archived dates to fill in holes

The ISUAgClimate network computed a daily average relative humidity (whatever that physically means) and so it would be good to replicate this for ISU Soil Moisture network. I think a straight average of the hourly data is in order / sufficient.

From HH

• Winter recreation (snowmobiling and cross country skiing): Probability of
  exceeding a certain snow depth threshold for various times of the winter
  (6"+ probably the most common). Or a count of how many days this threshold
  is met each winter.
• Similarly, wildlife biologists like such statistics in evaluating potential
  impacts of excessive snow upon wildlife; in this case the number of days per
  winter where a deep snow cover exists (perhaps 10"+) that inhibits foraging
  for food.
• Along with either of the above applications a simple monthly average snow
  depth might be an easy thing to have (such as in ClimoDat, but I don't know
  if having only a partial historical record works for how ClimoData is set
  up.)
• Putting any of the above in a map form could have some value too.

(09:00:50 PM) BM: Good evening, Daryl. I have a question for you if you have a moment. I have been wanting our office to produce an auto-updating LSR map for 3 years now. Many WFOs show various options for doing such a plot/map - all with pros and cons. Preferably, I'd like one that plots the data and contours it. However, I haven't seen that done yet. But, I do like what the Boulder office does (BOU). For example: http://www.crh.noaa.gov/bou/precip/precip_map.php. I like the clean look of the plot and the ordered text table on the right. We have liked referring to your snowfall plot in recent events, and I understand you are working on another version that may resemble what the BOU office does. Of course, the BOU product may just be a post-storm summary. I have not verified that it updates with live reports. Anyway, I was wondering if you could share with me what you are working on?

Suggestion from FB:

The 18 is the number of unwarned events (not warned but observed). I am
wondering if your software can take distances between reports into
account in this number? What I am getting at is several of the reports
are most likely from the same storm. As an example two of the Mohave
County (Meadview) reports are only 3 minutes apart and are pretty much
are from the exact same location. Yes, they are missed, but it could be
looked at that we are getting dinged multiple times for the same event.

Request is for a WFS to be added with current NEXRAD attribute data included.

Can add a GeoJSON while I am at it.

Currently the road conditions file for GR does not include the limited vis...

The NEXRAD compsites page is missing details for the NET and EET products. Some folks actually use these!

http://mesonet.agron.iastate.edu/json/radar?operation=list&radar=USCOMP&product=N0Q&start=2005-08-29T08:30Z&end=2005-08-30T08:30:00Z

results in a timeout. NFS looks okay, this date has missing data, so perhaps my script is looping. Investigating!

The /GIS/sbw-history.php script arbitrarily uses CDT/CST instead of a local timezone. We can probably do better than that!

Request from Dr Taylor

As a start for Iowa it might be well to include a couple of options on
the "Links" page to sort of go with the "7 day high Low plot," the 7 day
precip plot, the monthly plots, etc.

perhaps 7day PET plot, 7 day PET accumulation plot, Monthly PET plot,
and a Monthly PET accumulation plot.

The daily accumulation total will seldom exceed 0.75 inch PET and
usually range from 0.1inch on a cloudy/rainy day to 0.5 inch on a warm/sunny
day.

Users of the NWS warning API may like to have verification info included with the warning metadata. The problem is that I would like to keep that dynamically computed. This is tricky to implement.

If a user provides an invalid date, like 31 September, the download form silently bombs out. We can and will do better!

http://sgillies.net/blog/2014/05/22/the-geojson-media-type.html

It’s official: application/vnd.geo+json is the media type for GeoJSON registered with the IANA.

http://www.iana.org/assignments/media-types/application/vnd.geo+json

Would be nice to replicate this table, but alas, I don't keep track of everything in that table.

Users do not always want to have the non-synop reports included in the METAR download. Adding such an option to the download page would be nice, but non-trivial.

The request is for the start and end time to represent a window of hours to use.

Currently IEM Cow only considers the initial tag when doing tag based verification. Perhaps we could dynamically update as the tags update with SVSs.

• include the updated SVS tags in the warning listing

Got this error this morning, will investigate and fix

Traceback (most recent call last):
  File "drive.py", line 138, in <module>
    caller(genMonthly.write, monthly_rows, out, out2, out3, out4, dbid)
  File "drive.py", line 42, in caller
    ret = func(*args)
  File "/mesonet/www/apps/iemwebsite/scripts/climodat/genMonthly.py", line
47, in write
    moTot[mo] += int(db[ts]["avg_high"])
ValueError: invalid literal for int() with base 10: 'M'

Since the ISU Soil Moisture stations are underneath some crop, we should log and make that information available on the website!

Allow download of RWIS data in local time zone

The light, medium, heavy on the default color ramp is lame. We can do better!

The current hard time bounds selection of IEM Cow can lead to ugliness with some LSRs being included in the verification, but their corresponding warning was outside of the time domain. We can probably add an option to dynamically compute the bounds of a SVR event by looking for windows of nothing happening.

Otherwise I will get questions wondering about if the winds are blowing toward or from the shown direction.

Have to investigate this one:

Oct  9 15:25:22 iemvs105 httpd[25989]: [error] [client 129.186.185.2] Traceback (most recent call last):, referer: http://mesonet.agron.iastate.edu/request/coop/fe.phtml
Oct  9 15:25:22 iemvs105 httpd[25989]: [error] [client 129.186.185.2]   File "/mesonet/www/apps/iemwebsite/cgi-bin/request/coop.py", line 587, in <module>, referer: http://mesonet.agron.iastate.edu/request/coop/fe.phtml
Oct  9 15:25:22 iemvs105 httpd[25989]: [error] [client 129.186.185.2]     main(), referer: http://mesonet.agron.iastate.edu/request/coop/fe.phtml
Oct  9 15:25:22 iemvs105 httpd[25989]: [error] [client 129.186.185.2]   File "/mesonet/www/apps/iemwebsite/cgi-bin/request/coop.py", line 578, in main, referer: http://mesonet.agron.iastate.edu/request/coop/fe.phtml
Oct  9 15:25:22 iemvs105 httpd[25989]: [error] [client 129.186.185.2]     do_apsim( ctx ), referer: http://mesonet.agron.iastate.edu/request/coop/fe.phtml
Oct  9 15:25:22 iemvs105 httpd[25989]: [error] [client 129.186.185.2]   File "/mesonet/www/apps/iemwebsite/cgi-bin/request/coop.py", line 99, in do_apsim, referer: http://mesonet.agron.iastate.edu/request/coop/fe.phtml
Oct  9 15:25:22 iemvs105 httpd[25989]: [error] [client 129.186.185.2]     extra[ ts ]['doy'] = int(ts.strftime("%j")), referer: http://mesonet.agron.iastate.edu/request/coop/fe.phtml
Oct  9 15:25:22 iemvs105 httpd[25989]: [error] [client 129.186.185.2]   File "/usr/lib64/python2.6/site-packages/psycopg2/extras.py", line 149, in __setitem__, referer: http://mesonet.agron.iastate.edu/request/coop/fe.phtml
Oct  9 15:25:22 iemvs105 httpd[25989]: [error] [client 129.186.185.2]     x = self._index[x], referer: http://mesonet.agron.iastate.edu/request/coop/fe.phtml
Oct  9 15:25:22 iemvs105 httpd[25989]: [error] [client 129.186.185.2] KeyError: 'doy', referer: http://mesonet.agron.iastate.edu/request/coop/fe.phtml

Allow a user to filter the grid panel to only show certain values, then have the map display only show those warnings as well. This would be for the LSR app.

scripts/ingestors/dotcams/process.py

don't hard code the ftp password on the deployment end!

Requested tool that allows a user to select a point and then present a listing of storm based warnings for that point.

If only AGR variables are requested, so not do the soil data plexing, which creates a lot of missing data entries.

Currently, the VTEC download page only offers per WFO selection and does not include all attributes that may be desired. The feature request includes:

• Search by state
• Search by VTEC phenomena + significance combination
• Include HVTEC attribute in the download

Look into the SHEF database for the multi-day precip reports and include them in the spreadsheet far columns.

Instead of the page that lists the number of event counts, list the number of days.

A user correctly pointed out that my international network identifiers are non-standard / invented by me. I would like to change this, but they would conflict with state identifiers I use. For example: CO_ASOS I have is Colorado, US ASOS sites, but it should be Colombia ASOS. Let us leave the state identifiers alone as changing them would be infinite pain and break too many others use of the website.

Let us instead go to this nomenclature <country>_<optionalstate>_ASOS , so for the Colombia ASOS example, it would migrate to CO__ASOS. Then for Canada, I still could use Providences and an example for British Columbia would be CA_BC_ASOS . One could use programic logic to split on the _ and assume 'US' when the split only results in token length of 2.

Use http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2 for country IDs going forward.

The page that lists features by tag does not include the generate button, when appropriate.

I got in trouble when I built matplotlib with GTK backend support as it wanted to default to that backend when even running web scripts. I should be a good citizen and specify AGG backend so not to hit this again in the future.

Meet with some folks on 19 November. They have a need for county level data, including

• hi/lo temperature
• precipitation
• some measure of heat index

Create a simple web API that emits FIPS code (19 for Iowa) with this information, so their DBA can import it once or twice per year. Initial implementation deadline is the start of the new year

Requested option for additional SBWs, like special marine warnings

Based on the IWT meeting and feedback from a sub-regional polygon team that
I'm a part of...here are some suggestions for improving the IEM Racoon PPTs
--- items that would be most beneficial:

• Add options to include other stats (e.g., county area vs polygon area)
• Add an option to create animated gifs
• Add an option to include velocity data
• Include high-resolution ('super res') radar data
• Plot motion vectors

Allow the setting of tags on posted news items. Instead of with features, will use an array type in the database.

Oct 12 22:09:58 iemvs105 httpd[30324]: [error] [client 63.230.56.243] PHP Warning: Cannot modify header information - headers already sent by (output started at /mesonet/www/apps/iemwebsite/include/templates/navbar.phtml:147) in /mesonet/www/apps/iemwebsite/include/templates/homepage.phtml on line 53, referer: http://mesonet.agron.iastate.edu/

Need to make the feature logic a function and not have it echo output while doing its thing.

User request:

A function that allows the user to generate a custom report based upon the data range he chooses. I find the "export to Microsoft Excel" function to be quite useful; however, I feel it would be more beneficial if there were an additional way of exporting the table data along with a photograph of the NEXRAD data. The Microsoft Office program could be used to provide such report. As it is widely known, photographs of an object (e.g. car, location, or severe storm cell) along with data often facilitates a better conceptual understanding than simply one or the other alone, especially for persons who are not familiar with a subject.

Currently, there is no way to specify an exact time that you want WWA products for. This would be useful to add.

http://mesonet.agron.iastate.edu/request/gis/watchwarn.phtml

We have folks that scrape the mesonet archive RIDGE image folders for data. When an individual RADAR goes offline for more than a day, the archive folder is not created for that day. (The folders are created on-demand as data arrives). We should add empty folders each day to hold whatever potential data comes, this will make the scrapers happy as they will see empty folders and not 404s.

When a year datasheet upstream is removed, the local database copy should get culled too

We should not store data in two places, so why am I having data stored in r_monthly tables? We can make these queries dynamic, eh?

requested: One of the things I'm always looking for is the average number of warnings (of various types) for each of the counties in our CWA. Is that something that falls out of your data?

Requested addition of summary information to the CLI Map application. This would be max/min type values over various intervals of time.

My lame Iowa RWIS data ingest scripts do not properly handle nor store the precipitation data provided. An email from Tina on 8 December had a lot of good details

PcIntens

Intensity of the precipitation as derived from the
precipitation rate.

PcType

Type of precipitation detected by a precipitation sensor, if one
is available. Certain types of precipitation sensors can only detect the
presence or absence of precipitation and will display Yes or No. Other types
of precipitation sensors, such as the Weather Identifier and Visibility
Sensor (WIVIS) or Optical Weather Identifier (OWI), can classify the type of
precipitation and will report a specific type of precipitation. The WIVIS
and OWI precipitation sensors may report Yes at the onset of precipitation
until sufficient time has elapsed to classify the precipitation type.

PcRate

Average precipitation rate computed every minute. Snowfall is
converted to water equivalent and the rate represents the rate of liquid
equivalent.

PcAccum

Rainfall amount or snowfall liquid equivalent for the period from
midnight GMT to the current time. At midnight GMT the total accumulation is
reset to zero.

NOUS41 KWBC 041431
PNSWSH

Technical Implementation Notice 14-24
National Weather Service Headquarters Washington DC
1030 AM EDT Wed June 4 2014

To: Subscribers:
Family of Services
NOAA Weather Wire Service
Emergency Managers Weather Information Network
NOAAPORT
Other NWS Partners, Users and Employees

From: Tim McClung
Science Plans Branch Chief
Office of Science and Technology

Subject: New North American Land Data Assimilation System
(NLDAS): Effective June 24, 2014

Effective on or about Tuesday, June 24, 2014, the National
Centers for Environmental Prediction (NCEP) will begin to run and
disseminate data from the North American Land Data Assimilation
System Version 2.0.0 (NLDAS-2).

NLDAS is a multi-model land modeling and assimilation system run
in an uncoupled mode on a common one-eighth degree grid covering
the Continental United States (CONUS) along with northern Mexico
and southern Canada, and driven by atmospheric forcing.

NLDAS provides retrospective and real-time high-resolution water
and energy cycle products, such as surface fluxes, soil moisture,
snow cover, and runoff/streamflow, along with the near-surface
atmospheric and precipitation data sets used as forcings for the
NLDAS land models. These products support drought monitoring,
seasonal hydrological prediction, weather and climate
forecasting, model evaluation, and land-hydrology research within
these communities.

NLDAS has become a mature system and is being implemented into
real-time National Centers for Environmental Prediction (NCEP)
operations in the near future. The retrospective component of
Phase 2 of NLDAS (NLDAS-2; Ek et al, 2011) was completed in 2008

http://www.emc.ncep.noaa`.gov/mmb/nldas

Since then, NLSDA has continued in near real time. NLDAS-2 was
developed at the National Oceanic and Atmospheric Administration
NCEP Environmental Modeling Center (EMC) in collaboration with
its NOAA Climate Program Office (CPO) Climate Prediction Program
of the Americas (CPPA) partners. These partners include the
National Aeronautics and Space Administration/Goddard Space
Flight Center (NASA/GSFC), Princeton University, the University
of Washington (UW), the NWS Office of Hydrologic Development
(OHD), and the NCEP Climate Prediction Center (CPC). It can be
considered as the follow-on to Phase 1 of NLDAS (Mitchell et al,
2004), which was supported through the NOAA Office of Global
Programs (now CPO) GEWEX Americas Prediction Project (GAPP) and
the NASA Terrestrial Hydrology Program.

Ek, M. B., and co-authors, 2011: North American Land Data
Assimilation System Phase 2 (NLDAS-2). Development and
Applications, GEWEX News, May, 21(2), 6-7, 20

www.gewex.org/gewexnews/May2011.pdf

Mitchell, K. E., and co-authors, 2004: The multi-institution
North American Land Data Assimilation System (NLDAS): Utilizing
multiple GCIP products and partners in a continental distributed
hydrological modeling system. J. Geophys. Res., 109, D07S90,
doi:10.1029/2003JD003823.

For references see NLDAS publications in NASA NLDAS-2 website

http://ldas.gsfc.nasa.gov/nldas/NLDASpublications.php

1. NLDAS-2 data and their distribution:

NLDAS Version 2 generates hourly surface forcing at standard
model boundary layers (e.g., 2m air temperature and specific
humidity, 10 m wind speed, surface pressure, downward shortwave
and longwave radiation, precipitation) and the NCEP RCDAS lowest
model layer. NLDAS also provides hourly simulation for energy
fluxes (e.g., sensible heat flux, latent heat flux, ground
heat flux, net radiation etc.), water fluxes (e.g.,
evapotranspiration, total runoff/streamflow, precipitation,
etc.), and state variables (e.g., soil moisture, soil
temperature, snow water equivalent, land surface temperature,
snow cover, etc.) listed below from the four land surface models,
once per day for the 12 UTC cycle.

The NLDAS-2 output will be available in GRIB2 format on a 1/8th x
1/8th degree output grid. The NLDAS output will be disseminated
via the ftp/http server:

http://www.ftp.ncep.noaa.gov/data/nccf/com/nldas/
ftp://ftp.ncep.noaa.gov/pub/data/nccf/com/nldas

NLDAS produces the forcing files with a 3.5-day lag and the
output from the four LSMs with a 4-day lag. Therefore, NLDAS
output generated today will be available in directories dated 3
and 4 days ago. Output files and their contents include:

1.1 NLDAS-2 forcing:

NLDAS produces "a" and "b" forcing files. The "a" files are the
primary NLDAS forcing files. The "b" files are directly
downscaled from the NARR/RCDAS reanalysis at the lowest
prognostic model level with a spatial variation for diverse
terrain.

File a: nldas.t12z.force-a.grb2f$HR, where HR = 00, 01,..., 23
2D products include:
(1) TMP at 2 m: 2-m air temperature (K),
(2) SPFH at 2 m: Specific Humidity (kg/kg),
(3) PRES on the surface: surface pressure (pa),
(4) UGRD at 10 m: 10 m u component (m/s),
(5) VGRD at 10 m: 10 m v component (m/s),
(6) DLWRF on the surface: downscaled RCDAS downward longwave
radiation (W/m^2),
(7) FRAIN on surface: convection precipitation fraction to total
precipitation (--),
(8) CAPE: Convective Available Potential Energy (J/kg),
(9) PEVAP Potential Evaporation (kg/m^2),
(10) APCPN: Gauge-based total precipitation (kg/m^2),
(11) DSWRF: Bias-corrected RCDAS Downward Short-Wave Radiation
Flux (W/m^2)

File b: nldas.t12z.force-b.grb2$HR, where HR=00, 01,..., 23
2D products include:
(1) DSWRF: downscaled RCDAS Downward Short-Wave Radiation Flux
[W/m^2],
(2) APCPN: Downscaled RCDAS Total precipitation [kg/m^2],
(3) ACPCP: Convective Precipitation [kg/m^2],
(4) ACOND: Aerodynamic conductance [m/s],
(5) TMP: The lowest model layer Temperature [K],
(6) SPFH: the lowest model layer Specific Humidity [kg/kg],
(7) PRES: The lowest model layer Pressure [Pa],
(8) UGRD: The lowest model layer U-Component of Wind [m/s],
(9) VGRD: The lowest model layer V-Component of Wind [m/s], and
HGT: Geopotential Height [gpm].

1.2 Output from the Four Land Surface Models:

$model.t12z.grbf$HR, where model=Mosaic, Noah, SAC, and VIC;
HR=00, 01.,02,..., 23

Model outputs include hourly energy fluxes, water fluxes, and
states variables. For details, see the Model Output tab on the
NCEP/EMC NLDAS website:

http://www.emc.ncep.noaa.gov/mmb/nldas

NASA NLDAS website:

http://ldas.gsfc.nasa.gov/faq/#NLDAS_NASAvsEMC

Details are also in NLDAS-2 publications (Xia et al., 2012a). It
should be noted that soil moisture in SAC model is not for any
specific soil layer rather than six components of two reservoirs
(shallow upper and deeper lower). A post-process algorithm can be
used to generate soil moisture for a specific soil layer (Xia et
al., 2012a, Xia et al., 2014). Soil moisture and temperature for
VIC model are not for a specific soil layers for the second and
third soil layer as soil layers for these two layers vary from
grid cell to grid cell. Similar to the SAC model, a post-process
algorithm developed by Princeton University can be used to
generate soil moisture and temperature for a given soil layer
(Xia et al., 2012a).

1.3 Routed Streamflow from the Four Land Surface Models:

The River Routing Model developed by Lohmann et al. (2004) was
used to generate gridded streamflow over the CONUS. The results
from NLDAS-2 have been comprehensively evaluated using long-term
observed streamflow from 961 USGS basins (Xia et al., 2012b). The
output data include routed streamflow:

$model.t12z.STRM.grbf$HR, where model=Mosaic, Noah, SAC, and VIC;
HR=00, 01, 02,..., 23; STRM: routed streamflow (m^3/s)

1. NLDAS-2 Operational Run:

A consistent parallel feed of data is currently available on the
NCEP server at:

ftp://ftp.ncep.noaa.gov/pub/data/nccf/com/nldas/para,
or
http://www.ftp.ncep.noaa.gov/data/nccf/com/nldas/para

Users please note that NLDAS-2 products are encoded in GRIB2
using a relatively-new GRIB template. Users should download the
latest versions of wgrib2 and the other NCEP GRIB utilities to
use the NLDAS-2 output products. Users can access the NCEP GRIB
utilities from this URL:

http://www.nco.ncep.noaa.gov/pmb/codes/nwprod/util/exec

A website containing more information about GRIB2 can find at:

http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc.shtml

For questions regarding the scientific content of the NLDAS
system please contact:

Michael B. Ek
NCEP/EMC
College Park, Maryland 20740
301-683-3957
[email protected]

Youlong Xia
IMSG at NOAA/NCEP/EMC
College Park, Maryland 20740
301-683-3696
[email protected]

For questions regarding the dataflow aspects of these data sets
please contact:

Rebecca Cosgrove
NCEP/NCO Dataflow Team
College Park , Maryland 20740
301-683-0567
[email protected]

NWS National Technical Implementation Notices are online at:

http://www.nws.noaa.gov/os/notif.htm

$$

User wants more than just the average daily value, let us add the high and low temperature as well.