Contents |
Proposed by: CUNY School of Professional Studies / New York City Office of Emergency Management
Contact (name, email, irc, skype): Chad Heuschober, chad.heuschober@mail.cuny.edu, chadheus@freenode, cunychad
Best way and times to contact during RHoK 2.0 Dec 4/5 2010: email, available most other means late mornings through evenings EST
At times, an emergency plan's resources become unavailable due to their proximity to the affected area. This problem definition supports drawing and storing a series of affected area shapes on a map, and using that geo-data to adapt the facility and staff resource plan by automatically offlining those resources that would be negatively affected.
In the event of an unexpectedly large coastal storm, a municipality's sheltering system may find that some of it's shelters are in an area that is now underwater. Currently, emergency managers would be required to get situational reports from each individual shelter, however, if administrators had the ability to simply draw the flood areas on a map, the system could use the geo-coded shelter addresses to automatically offline those shelters that are no longer usable, and instead activate some of the standby shelters.
An earthquake destroys a major bridge. Half of the earthquake response team cannot get to the staff just-in-time training camp at the base of the bridge because of the bridge's status. An administrator draws a polygon indicating that the bridge area and several others are affected and impassable. The system, now aware of the newly destroyed bridge, does not attempt to deploy those staff who live on the other side of the bridge. As a result, the response team is not short-staffed because the system was able to adjust its staff pool and draw upon the reserve team that lived further away but did not have to cross that bridge to get to the training camp.
However the geo-provider is handled, the assumption should be that up to 250,000 records might be queried against the polygon. This significantly limits geo-provider options since most have terms of service that dictate daily usage maximums well below that figure.
Mayon currently uses TIGER/Line data for its primary geo-source when it comes to matching addresses, but hasn't selected a source for generic polygons or map integration.
To participate:
The Agasti Mayon trunk can be found on Launchpad at: https://code.launchpad.net/~sahanaphp-committers/sahana-agasti/mayon
Documentation for Agasti Mayon can be found at: http://wiki.sahanafoundation.org/doku.php/agasti:mayon:start
More information about Agasti Mayon and links to other resources can be found at the official documentation wiki with special note given to the Mayon 911 page.[1]
Sahana Agasti is an open-source PHP-based disaster management software registered by the Sahana Software Foundation, first created in response to the 2004 Tsunami, and used by emergency management organizations and grassroots organizers alike to coordinate preparedness, response, and recovery tasks throughout disaster operations. Used by the New York City Office of Emergency Management (NYC OEM), and supported by development efforts from the City University of New York School of Professional Studies (CUNY SPS), the National Library of Medicine, Respere, and an international community of developers, Sahana Agasti is an internationally recognized platform for disaster operations management.
The Agasti Mayon (2.0) branch is currently being headed by the CUNY SPS team, a subset of whom will be actively participating in RHoK #2 to try to merge any solutions directly into the Mayon trunk. The CUNY SPS team is also supported by their partner, the New York City Office of Emergency Management who is slated to be the first active installation of the Agasti Mayon in 2011.
All Sahana Agasti projects are registered under the Sahana Software Foundation (SSF). For more information about the SSF, please see: http://sahanafoundation.org/
A basic database structure exists to support establishing points and drawing polygonal shapes but no frontend functionality has been created to use this. Currently, geo-data is used for staff deployment to ensure that staff are deployed to their closest facility. The address matching data is syndicated and consumed through GeoJSON from a secondary system that hosts Tiger/Line data.