GEOG 583 – Geospatial System Analysis And Design
Term Project
Designing a Location-Aware Smartphone
Application System to Transmit Storm Damage
Reports to the National Weather Service
Matthew Welshans
9/18/2012
This document is published in fulfillment of an assignment by a student enrolled in an educational offering of The
Pennsylvania State University. The student, named above, retains all rights to the document and responsibility for
its accuracy and originality.
M. Welshans, 1
Abstract
This project takes advantage of Tomlinson’s GIS Design Method in order to design a system that
takes advantage of mobile technology to gather and update geospatial data in real-time. The project
goal is to collect storm damage data from severe weather events using a smartphone application and
upload to an online geodatabase for analysis. With these data, local storm report products can be
supplemented with volunteered geographic data such as where the photo was taken and information on
the storm that caused the documented damage.
The community member could upload an image from their cell phone and comment on the
storm damage using a mobile application or potentially a web-based application and the dynamically
updated geodatabase could then be mashed up with an online mapping tool or using an API in order to
show the storm damage in near-real time, which could be useful to forecasters in evaluating storm
damage that occurred. If images appear during active weather, forecasters can tweak watch/warning
products knowing the history of the system.
The one caveat that must be addressed is the availability of cellular phone signals during storms.
Storm damage could occur in areas of weak or non-existent coverage and in some instances, cellular
phone towers may be damaged or not working due to storm damage, reducing the effectiveness of AGPS for geo-tagging images and timely uploading of images.
M. Welshans, 2
Introduction
The National Weather Service (NWS) defines a severe thunderstorm as “a thunderstorm that
produces a tornado, winds of at least 58 mph, and/or hail at least 1” in diameter (NWS, 2009b).” Local
NWS Weather Forecast Offices gather reports of thunderstorm damage and tornado sightings from
several sources including law enforcement, rescue personnel, trained storm spotters and
meteorologists, members of the media, and public reports (McCarthy 2002). These are compiled in a
text-based product called a Local Storm Report (NWS, 2009a). An example of a Local Storm Report
product is shown in Image 1. A 1992 report by the National Severe Storms Forecast Center (now the
Storm Prediction Center) stated that the National Weather Service has made a large push to train storm
spotters, increasing the overall number of severe storm reports (Anthony and Leftwich, 1992).
Image 1 – Preliminary Local Storm Report from the National Weather Service office in Lincoln, IL. The report contains
information on when and where the damage occurred, who reported the damage, what time of event caused the damage, and
remarks including if there were any injuries or fatalities. These reports are then sent to a centralized office that compiles all the
reports for a national severe storms database operated by the Storm Prediction Center and the National Climatic Data Center.
M. Welshans, 3
Storm reports serve an important role for NWS offices.
The local offices issue severe
thunderstorm and tornado warnings and use the reports for warning verification. Timely reports can
also be used with radar and satellite imagery to aid in the actual warning process at the local forecast
center which forecasters can extend or alter the warnings as needed for additional accuracy by using
these storm reports as ground-truth verification (McCarthy, 2002). The Storm Prediction Center, who is
responsible for severe weather and tornado watch areas, also use these reports for verification. The
increase in severe storm reports has helped reduce the number of “false alarm” issuances of watches
and warnings (Anthony and Leftwich, 1992).
The NWS is looking at ways to improve the issuance of Local Storm Reports in order to improve
report accuracy and reduce the time needed to process incoming reports. One solution is the creation
of a web-based application which would help to create reports on the fly using a street address, location
from the center of a city, or a known spotter location. This would create traditional storm report
products and export to other data formats (Davis and Walawender, 2010). One of the main issues with
the current product is that it is limited to a text-based description of the damage.
With approximately 110 million Americans owning smartphones with cameras (comScore,
2012), storm damage can be documented in several ways including still imagery and video. The NWS
currently uses smartphones as a tool for documenting storm damage on surveys. They note that often,
clean-up has begun by the time surveys take places, not allowing forecasters to properly document
storm damage evidence (Shea, 2012). Smartphone users could instantaneously send storm damage
imagery and information to NWS forecasters using a smartphone application.
This project will show a proposal for submitting storm reports to the NWS using a smartphone
application and allow submission of relevant images from storm spotters and community members that
would be geo-tagged from that application. The reports and images could then become part of the
M. Welshans, 4
storm report database maintained by branches of the NWS. By submitting reports electronically, it
changes the forecaster’s role from gathering data to verification. The project will use Tomlinson’s
methods for GIS Design to assess the current state of the Local Storm Reports process and end goals of
the mobile application, how to reconcile the community-submitted data with the current product
formats, and talk about the prototyping, implementation, and evaluation process.
Goals and Current State
The general scope of the project is to allow users to use a smart phone application to submit
storm-related information (both text and multimedia) to a system workflow that would then process
and publish data to appropriate formats. The project goal is to make the submission process as painless
as possible while gathering all required information for the storm report, submitting to a database, and
converting information to both a visual map interface with links to photographs of storm damage and a
text-based product for further usage.
Storm reports are gathered from a variety of different sources, including law enforcement, fire
and rescue personnel, trained storm spotters, members of the media, and the general public. It can
become cumbersome to gather and verify information from all sources in a timely manner. According to
a study from the NWS Central Region, “local experiences have shown a disconnect between searching
for sources of information…, accurately referencing the reports geographically, and correlating the
reports with ongoing weather events (Davis and Walawender, 2010).”
The NWS is currently implementing an internet-based storm-spotter reporting service, “ESpotter” to address this issue. The goal of the service is to speed up the time it takes to submit severe
weather reports and increase accuracy of these reports (NWS E-Spotter, n.d.), replacing the current
M. Welshans, 5
method of calling the local NWS Storm Spotter hotline and providing a verbal report to a forecaster. The
NWS has also been experimenting with other methods such as directly emailing reports and sending
reports via Twitter (NWS Binghamton, 2010).
A mobile application would follow the established
technology trends while allowing forecasters to concentrate on verifying reports rather than gathering
them.
Application Needs Assessment
The NWS has to take into consideration several factors when developing a mobile application.
A key to the development of a mobile storm report application is the reliability of cellular telephone
coverage in general and especially during severe weather events. Networks can fail in three primary
ways during severe weather events: Towers and other infrastructure such as data centers are destroyed
or hampered by lack of power during and after the storm, the backup support systems fail, and/or too
many people overload the network (Townsend and Moss, 2005). Therefore, the application would have
to include the ability to store information at a later time if a data connection were unavailable.
Likewise, since Assisted GPS (A-GPS) requires cellular telephone towers to quickly and accurately places
the smartphone within a set distance (Zahradnik, 2012), the geo-location may suffer in the same way.
Thus, the ability to manually select a reporting location is a requirement.
In order to make an application compatible with current and future mobile operating systems
and various form factors, a suggestion would be to use a web-based mobile application based on HTML5
rather than operating system-specific applications that would require additional development time and
testing (Warren, 2011).
M. Welshans, 6
Infrastructure Needs
In addition to the mobile application, dedicated infrastructure is needed to host the information
and process conversions from raw data to the appropriate formats needed to quickly access and
disseminate the information to the appropriate chain of command (Walawender and Davis, 2010). An
option for infrastructure is using cloud based servers to run instances of GIS software and increase
instances as demand increases (Chappell, 2010). While cloud services offer a more flexible and costeffective method of running data services such as GIS, concerns about continued funding for service
plans, security, and service availability may hinder the continued use of cloud-based services (Pratt,
2011).
The NWS Central Region has proposed using a hybrid system that plots data from local database
servers and stores them onto overlays for Google’s web-based maps using OpenLayers (Walawender
and Davis, 2010). The mobile application may be able to piggyback off these existing servers, allowing
for quick implementation without a lot of additional hardware costs. However, the success of the
mobile initiative may require additional hardware investments to keep up with demand, so a costbenefit analysis may be needed to choose the most suitable platform.
System Wireframe and Prototyping Interfaces
The next step after assessing needs and developing a concept is developing a system workflow.
As stated above, the workflow has to be compatible with the current method to get data into the
centralized storm database. Much of the work had been laid out by the NWS Central region test bed.
Image 2 shows the basic wireframe for the system. In the image, the mobile application would transmit
three pieces of data – report information, location data, and supporting imagery – to a database server,
starting the workflow.
M. Welshans, 7
Image 2 – Basic workflow from data submission to data posting online. After submitting a report from a smartphone, the
report information, location data, and image are uploaded to a database server running an open source database program.
When new information is found in the database, the back-end server processes the data and places it in the Intranet viewer so
forecasters can check the data against radar imagery and other information. Once the forecaster vets the data, it goes back
into the back-end server to output in various methods including placing on the web server for public information and creating a
storm report. Portions of process taken from Davis and Walawender (2010). Created using Balsamiq Mockups.
Davis and Walawender (2010) proposed a method for processing and storing storm report data from a
web-based application by using open-source GIS software. They stated:
Data from a relational database server would be processed in two ways. The
spatial data would be run through a web mapping server such as MapServer, while
non-spatial data such as remarks would be processed through a PHP script. Once
processed, storm report location data and radar data could be mapped on a web
portal using the OpenLayers JavaScript extension on top of a third-party map
background.
In this case, the web-based GIS portal would be first accessible to the meteorologists in the
office. They could layer the incoming storm report data from the mobile application with data such as
radar and satellite imagery to determine the report’s validity. Once meteorologists validate the report,
they could send the report data into further processing that would create the Local Storm Report and
other products and transmit those for further processing and data sharing with other NWS offices. This
trigger could also upload the data to a separate web server so data can be seen by the public.
M. Welshans, 8
Interface prototyping would involve both storm spotters and the meteorologists that would
work with the data. Two interfaces would be looked at in this step. One is the mobile interface that
would be used in the field to send reports. A sample prototype is shown in Image 3. The other would
be the web interface used internally that storm reports would be sent to before further data processing
occurs. This intermediate interface would allow forecasters to verify data and also ensure that any
images are relevant to the situation. The existing E-Spotter verification interface could be tweaked to
allow images to be uploaded with reports.
Implementation
As previously stated, NWS has already implemented hardware that could be used in concert
with the current web-based reporting application. One caveat is that if the program proves to be
successful, hardware may need to be scaled up to meet the demand. The challenge is determining who
should use the mobile application. NWS already has a network of storm spotters trained under their
Skywarn program that could beta-test the application and report issues with sending data from their
phones. Forecasters and law enforcement may also be good candidates for testing the application.
After beta-testing is completed, the application could be released to the general public through
a web link to the mobile NWS website. The application may require users to sign in, but this process can
be tedious on smartphones. One solution may be to use the OAuth 2.0 protocol to users to log into a
third-party account, such as their Google Account (Google Developers, 2012) or Facebook Account
(Facebook Developers, 2012). The third-party account could link to that storm spotter’s profile, giving a
summary of what reports had been previously sent and showing the spotter’s level of activity.
M. Welshans, 9
Image 3 – Prototype of Mobile Application. Users would log in with either an email/password combination or through thirdparty authentication using the OAuth protocol through Facebook, Google, or Twitter. After the location is selected either
through A-GPS, selecting a location on a map, or using a street address to geocode a location, the storm information data is
gathered. Users have the option to select an image from their gallery or take an image directly from their camera. After
confirming all information is correct, the report is then submitted into the workflow shown in Image 2. Created using Balsamiq
Mockups. Power line image is courtesy of Sam-Lehman on Flickr under Creative Commons License.
M. Welshans, 10
Feedback and System Evaluation
Feedback is an essential process to gain a better understanding of how to improve the system
over time. The US Government has regulations that require government agencies, including the NWS,
to gather public feedback and evaluate products from time to time (Executive Order No 12862, 1993).
To accomplish this, they could use government authorized forms available online to allow storm
spotters to give constructive feedback on how to improve the system. The mobile application could
also have a place to for users to give feedback. This would especially be helpful in the beta testing
phase.
Evaluation should also be done at the data supply chain level within the NWS office. One of the
big goals of the project was to speed up the process from obtaining reports to processing and
transmitting them to other entities. The evaluation process may consist of timing the original process
before implementation begins, then comparing the original processing time to the time it takes to
process in the new method. Another form of evaluation could come from in person and blind surveys to
identify bottlenecks in the system. Management, IT Staff, and forecasters would likely take part in this
part of the evaluation process to improve inter-office data flow.
Conclusions and Next Steps
The process shown in this paper showed that it is possible to use the technology currently found
in smartphones to send images and storm report information to the National Weather Service.
By
implementing this process, forecasters could receive storm damage information in a timely manner to
gain a better understanding of what damage may have been caused and update the public accordingly.
The process requires experimental testing and evaluation before releasing a public version.
M. Welshans, 11
One next step may be to tap into social media for storm reports. NWS already has started
experimenting with Twitter to submit storm reports (NWS Binghamton, 2010), but mapping the geotagged Twitter messages could give an idea of where severe storms are coming from. An example of
this is an experimental product from ESRI, which shows how social service APIs could be implemented to
illustrate geo-tagged posts with key phrases on a map. In the experimental product, the word Hurricane
was used to show relevant posts, pictures and YouTube videos (ESRI, 2011). While information could
not be vetted for validity, it could be used as a secondary tool for tracking severe weather responses.
M. Welshans, 12
Works Cited
Anthony R. and Leftwich, P. (1992). “Trends in Severe Local Storm Watch Verification at the National
Severe Storms Forecast Center.” Weather and Forecasting, 7, 613-22.
comScore, Inc. (2012). “comScore Reports June 2012 U.S. Mobile Subscriber Market Share.” [press
release]. Retrieved from
http://www.comscore.com/Press_Events/Press_Releases/2012/8/comScore_Reports_June_201
2_U.S._Mobile_Subscriber_Market_Share
Corfidi, S. (1999). “The Birth and Early Years of the Storm Prediction Center.” Weather and Forecasting,
14, 507-25.
Davis, M. and Walawender, B. (2010). “An Advanced Web Application for Issuing Storm Reports.” 26th
Conference on Interactive Information and Processing Systems (IIPS) for Meteorology,
Oceanography, and Hydrology, Atlanta, GA. [extended abstract] Retrieved from
https://ams.confex.com/ams/pdfpapers/159937.pdf
ESRI (2011). US Tropical Storm Map. Retrieved from http://tmappsevents.esri.com/website/hurricane/.
Executive Order No 12862. 58 Federal Register 176 (1993).
Facebook Developers (2012). Authentication. Retrieved from
https://developers.facebook.com/docs/authentication/
Google Developers (2012). Using OAuth 2.0 to Access Google APIs. Retrieved from
https://developers.google.com/accounts/docs/OAuth2
McCarthy, D.W. (2002). “The Role of Ground-Truth Reports in the Warning Decision-Making Process
during the 3 May 1999 Oklahoma Tornado Outbreak.” Weather and Forecasting, 17, 647-49
McCarthy, D.W. (2003). NWS Tornado Surveys and the Impact on the National Tornado
Database. Preprints, 1st Symp. F-Scale and Severe-Weather Damage Assessment, Long Beach,
CA. Retrieved from: http://www.spc.noaa.gov/publications/mccarthy/f-scale.pdf
National Weather Service (2009a). “LSR.” Glossary – NOAA’s National Weather Service. Retrieved from
http://w1.weather.gov/glossary/index.php?letter=l
National Weather Service (2009b). “Severe Thunderstorm.” Glossary – NOAA’s National Weather
Service. Retrieved from http://w1.weather.gov/glossary/index.php?letter=s
National Weather Service Forecast Office - Binghamton, NY (2010). “Storm Reports.” Retrieved from
http://www.erh.noaa.gov/bgm/stormreport.shtml
M. Welshans, 13
Pratt, Mary (2011). “Feds Trek to the Cloud” ComputerWorld. Retrieved from
http://www.computerworld.com/s/article/357878/Feds_Begin_Race_to_the_Cloud
Schaefer, J.T. and R. Edwards (1999). “The SPC tornado/severe thunderstorm database”. Preprints,
11th Conference of Applied Climatology, American Meteorological Society, 215-220. Retrieved
from: http://www.spc.noaa.gov/publications/schaefer/database.htm
Shea, Todd (2012). “Severe Local Storm Damage Assessment.” National Weather Service Forecast
Office – La Crosse, WI. Retrieved from http://www.crh.noaa.gov/arx/?n=stormdamage
Townsend, A. and Moss, M. (2005). “Telecommunications Infrastructure In Disasters: Preparing Cities
for Crisis Communications.” Retrieved from http://www.nyu.edu/ccpr/pubs/NYUDisasterCommunications1-Final.pdf
Walawender, B. and Davis, M. (2010). “Development of Web-Based GIS Applications for Decision
Support and Situational Awareness.” 26th Conference on Interactive Information and Processing
Systems (IIPS) for Meteorology, Oceanography, and Hydrology, Atlanta, GA. [extended abstract]
Retrieved from https://ams.confex.com/ams/pdfpapers/158951.pdf
Warren, C. (2011) “How HTML5 Is Aiding In Cross-Platform Development.” Mashable. Retrieved from
http://mashable.com/2011/02/22/html-mobile-development/
Zahradnik, F. (2012). “Assisted GPS, A-GPS, AGPS” About.com GPS. Retrieved from
http://gps.about.com/od/glossary/g/A-GPS.htm
Acknowledgements
The power line image used in the mobile application prototype was courtesy of user SamLehman on Flickr (http://www.flickr.com/photos/66752285@N08/6151258469) and was used under
the Creative Commons License for educational purposes.