Term Project - Matt Welshans



GEOG 583 – Geospatial System Analysis And DesignTerm ProjectDesigning a Location-Aware Smartphone Application System to Transmit Storm Damage Reports to the National Weather ServiceMatthew Welshans9/18/2012AbstractThis 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 A-GPS for geo-tagging images and timely uploading of images. IntroductionThe 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. 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 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 StateThe 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, “E-Spotter” 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 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). Infrastructure NeedsIn 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 cost-effective 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 cost-benefit analysis may be needed to choose the most suitable platform.System Wireframe and Prototyping InterfacesThe 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.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.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. ImplementationAs 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.Image 3 – Prototype of Mobile Application. Users would log in with either an email/password combination or through third-party 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. Feedback and System EvaluationFeedback 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 StepsThe 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.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 geo-tagged 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. Works CitedAnthony R. and Leftwich, P. (1992). “Trends in Severe Local Storm Watch Verification at the National Severe Storms Forecast Center.” Weather and Forecasting, 7, 613-Score, Inc. (2012). “comScore Reports June 2012 U.S. Mobile Subscriber Market Share.” [press release]. Retrieved from , 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 (2011). US Tropical Storm Map. Retrieved from Order No 12862. 58 Federal Register 176 (1993).Facebook Developers (2012). Authentication. Retrieved from Developers (2012). Using OAuth 2.0 to Access Google APIs. Retrieved from , 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-49McCarthy, 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: Weather Service (2009a). “LSR.” Glossary – NOAA’s National Weather Service. Retrieved from National Weather Service (2009b). “Severe Thunderstorm.” Glossary – NOAA’s National Weather Service. Retrieved from National Weather Service Forecast Office - Binghamton, NY (2010). “Storm Reports.” Retrieved from Pratt, Mary (2011). “Feds Trek to the Cloud” ComputerWorld. Retrieved from 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: , Todd (2012). “Severe Local Storm Damage Assessment.” National Weather Service Forecast Office – La Crosse, WI. Retrieved from Townsend, A. and Moss, M. (2005). “Telecommunications Infrastructure In Disasters: Preparing Cities for Crisis Communications.” Retrieved from , 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 Warren, C. (2011) “How HTML5 Is Aiding In Cross-Platform Development.” Mashable. Retrieved from Zahradnik, F. (2012). “Assisted GPS, A-GPS, AGPS” GPS. Retrieved from power line image used in the mobile application prototype was courtesy of user Sam-Lehman on Flickr () and was used under the Creative Commons License for educational purposes. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download