Labels: archives, disaster management
The Sahana Software Foundation needs a developer for disaster relief software used in Haiti. They can be anywhere in the world, as long as they are contactable during Haiti business hours:The Sahana Software Foundation is looking for a developer to support its Food Request Portal deployed to support the Food Cluster and the World Food Programme in Haiti. This is a full-time position and requires
full-time availability (8 hours per day of work Monday through Friday,
and ability to be reachable during working hours in Haiti which is 1300
UTC until 0100 UTC). The main responsibility will be to support the
evolving requirements of the Food Cluster and the production, test and
development environments of this deployment. But one of the goals of
this effort will also be to move the FRP branch back into the trunk such
that the enhancements and features will become regular components of the
core SahanaPy project.
Skills/Experience required: python/web2py with good UI/UX skills, an
understanding of MySql, OpenLayers, KML approaches, experience with release management, coordinating QA & UAT testing, systems administration. Knowledge of SahanaPy a plus.
Candidates must be available to start no later than 15 March (the earlier is better). The full-time effort will run through the end of May 2010, followed by an additional part-time support effort of 40 hours (5 days) for the month of June 2010.
Interested persons should send a current CV to mark at sahanafoundation dot org as soon as possible.
Labels: disaster management, Haiti 2010 Earthquake, Sahana
Sahana Software Foundation
FOR IMMEDIATE RELEASE
SAHANA SOFTWARE FOUNDATION ANNOUNCES INITIAL MEMBERSHIP
LOS ANGELES, CALIFORNIA, 10 February 2010: The Sahana Software Foundation announced today its initial membership. Membership invitations were extended in December 2009 to current and past board and project management committee members. Those who accepted this invitation and form the initial membership of the Sahana Software Foundation are:
David Bitner, USA
Fran Boon, UK
Ravith Botejue, Sri Lanka
Don Cameron, Australia
Mifan Careem, Sri Lanka
Trishan de Lanerolle, USA
Chamindra de Silva, Sri Lanka
Ravindra de Silva, Canada
Sudheera Fernando, Sri Lanka
Mahesh Kaluarachchi, Sri Lanka
Dominic König, Sweden
Ishan Liyanage, Sri Lanka
Greg Miernicki, USA
Darmendra Pradeeper, Sri Lanka
Mark Prutsalis, USA
Louiqa Raschid, USA
Eric Rasmussen, USA
Martin Thomsen, Denmark
Gavin Treadgold, New Zealand
Nuwan Waidyanatha, Sri Lanka
Sanjiva Weerawarana, Sri Lanka
Brent Woodworth, USA
Tom Worthington, Australia
Members of the Sahana Software Foundation are eligible to nominate new members and to vote for the composition of the Board of Directors and other issues at the annual meeting of members. The first meeting of the members of the Sahana Software Foundation is scheduled for May 2010 at which the first elected board will be voted on, followed by a board meeting.
The current board is composed of Mifan Careem, Chamindra de Silva, Darmendra Pradeeper, Mark Prutsalis, Louiqa Raschid, Martin Thomsen, Gavin Treadgold, Sanjiva Weerawarana and Brent
Woodworth.
The officers of the Sahana Software Foundation are:
Brent Woodworth (Chair), Mark Prutsalis (President & CEO), Chamindra de Silva (Secretary & CTO), and Dale Zuehls (CFO/Accountant).
The governing bylaws of the Sahana Software Foundation can be reviewed at: http://wiki.sahana.lk/doku.php/foundation:home#bylaws
About the Sahana Software Foundation:
The Sahana Software Foundation was established in June 2009 as a non-profit membership-based organization, and governs the free and open source software Sahana disaster management system.
For more information, contact:
Mark Prutsalis, President & CEO
Sahana Software Foundation
Tel +1-860-499-0332
mark@sahanafoundation.org
http://www.sahanafoundation.org
###Sahana Software Foundation
900 Wilshire Blvd, Ste 1500
Los Angeles, CA 90017
http://www.sahanafoundation.org
Labels: disaster management, emergency management, open source, Sahana
The Sahana Open Source Disaster Management System is being prepared for use in the 2010 Haiti earthquake by a group of volunteers. Relief organisations needing computer support and IT organisations or individuals wishing to offer assistance, can get details at the Haiti Quake 2010 wiki.Labels: disaster management, Haiti Quake 2010, Sahana
Labels: Australian Emergency Alert System, disaster management, em2au, Emergency Alert System, emergency management, gov2taskforce, Government 2.0 Taskforce
So here’s a summary of our major accomplishments:
From: Brain dump by Mark Prutsalis on November 12th 2009
- We were able to integrate with a local Google fusion server that was used to process imagery of the Camp Roberts area through OpenLayers. Very cool. Very bleeding edge.
- We were able to integrate with a local Open Street Maps tile server that produced data collected through Walking Papers and was available to Sahana through OpenLayers again. Again, very cool. Very bleeding edge. Do read Mikel Maron’s blog post on this.
- We were able to set up two-way integration with InSTEDD’s GeoChat application through GeoRSS feeds.
- We tested the ability of OLPCs and Netbooks to collect data in both networks and disconnected environments, connected by WIMAX and powered by a combination of solar and wind at a remote Forward Operating Base.
- We developed procedures for synchronizing and importing data collected through portable applet instances.
Labels: disaster management, Sahana
The People's Verdict on Tsunami Recovery in Sri Lanka by Muttukrishna Sarvananthan (International Centre for Ethnic Studies, Colombo, 2007, ISBN: 978-955-580-114-0) provides an useful analysis of the recovery operations after the 2004 Indian Ocean Tsunami. The emotive title of "people's verdict" is unfortunate, as it may make the reader think this is some sort of left wing political propaganda, rather than the careful empirical research it is. The book is based on an extensive survey of tsunami survivors and provides useful lessons for future disaster recovery operations,. Unfortunately even so long after the events of 2004 it also notes where the recovery operation is still lacking, particularly with housing and schooling. Some surprising findings were that there was little corruption or discrimination in the distribution of aid. The provision of employment and schooling were identified as important issues. I acme across this book by accident in the new arrivals at the Australian National University Library. The International Centre for Ethnic Studies might wish to consider distributing excepts from this book online for free, so as to make the information more widely available.Labels: disaster management, Tsunami
Regional Security - Deployable Civilian Capacity
Establish a deployable public service that will be able to more rapidly and effectively deliver development assistance.
Agree. The Government has agreed to develop a policy framework to enable rapid deployment of civilian experts to assist in international disaster relief, stabilisation and post conflict reconstruction efforts. An inter-agency task force is being led by AusAID to Undertake this work. Once established, a national deployable civilian capacity will allow more rapid and early delivery of stabilisation and recovery assistance to countries that experience conflict or natural disaster. The program reflects many of the ideas discussed at 2020, and also at the Youth Summit, and will be sufficiently adaptable to allow Australia to tailor our response to a particular event or emergency. It will also improve Australia's integration into multilateral reconstruction and stabilisation operations.
From: "Responding to the Australia 2020 Summit", Australian Government, 22 April 2009
AusAID is leading a whole-of-government taskforce to develop a Deployable Civilian Capacity, an idea raised at the Australia 2020 Summit. Once established, a national deployable civilian capacity will enable rapid deployment of civilian experts to provide stabilisation and recovery assistance to countries experiencing conflict, post-conflict situations or natural disaster. In cooperation with other government agencies, AusAID will pre‑identify, train, deploy rapidly and sustain civilian technical expertise. The program will build on Australia's experience of deploying civilian experts in post‑conflict situations, for example in East Timor and Solomon Islands, and improve Australia's integration into multilateral reconstruction and stabilisation operations.As part of this I suggest the expansion of the Sahana open source disaster management system and online training.
From: Australia's International Development Assistance Program: A Good International Citizen, Budget 2009-10, Australian Government
Sahana was developed for the Boxing Day Tsunami and has been used in several subsequent disasters in Asia. A demonstration of Sahana available online.
Recently two New Zealand councils of issued a request for Expression of Interest for a Information and Communications System for a joint Emergency Operations Centre (EOC) for emergency and disaster coordination. In response I suggested that a deployable system housed in a an airline carry-on size wheeled bag. Also I suggest that the Sahana system could be expanded from its disaster management role to cover coordination as well. The Sahana community saw this of interest, but not their core function. However, if the Australian Government provided some modest funding, this could be done.
The Deployable Civilian Capability Group could be equipped with low cost portable computer equipment allowing much more efficient coordinated relief operations. This would also take a load off the military communicators who are usually relied on during disaster operations, but are heavily committed elsewhere.
In addition I suggest using Mentored and Collaborative e-Learning to help train the group. The group members will rarely meet and have little time for face to face training. Using training in online groups will allow an esprit de corps to form, as well as make maximum use of limited resources.
Labels: accessibility, Australian Government, disaster management, ICT Governance, ICT Policy, web design
Requirements
1.80. The EOC may need to operate under three general scenarios:
a. A local emergency with normal power and telecommunications
b. A local emergency with local interruptions to power and
telecommunications (in this scenario the EOC has its own power supply so ICT within the building can operate)
c. Significant emergency, could be Local, Regional or even a National Emergency with limited or no power supply or telecommunications, EOC could be running from one or two stand alone PCs or possibly have reverted to analogue (plus paper-based) systems 1.81. The EOC, when fully operational could be operating 24 hours a day for several days with 30-40 staff in three revolving eight hour shifts (see image below for an overall impression of what an EOC looks like).
1.82. The above image is of a mature EOC i.e. an EOC well into an emergency. When first activated, particularly in a declared emergency, the situation can be quite chaotic. EOC staff may start to arrive over the course of an hour or more and it might take some time for the EOC to reach ‘critical mass’.
Messaging
1.83. Once activated, several different personnel, though typically designated telephonists within the EOC will need to be able to simultaneously record incoming information. This will include messages from: members of the public phoning in, emergency services communications, reports via radio telephone and/or mobile phone from emergency management personnel on the
ground, emergency management personnel reporting face to face. The EOC personnel having those conversations need to be able to quickly record details of the conversation in a structured way.
1.84. Ideally the person taking the call will be able to choose from different situation choices based on what the caller is saying i.e. flooding, blocked road (and blocked by: slip, fallen tree, vehicle incident), call-taker is prompted by
the system about what questions to ask (possibly in a descending order of importance). Where applicable, responses can be tic-boxes.
1.85. Ideally the system will automatically assign metadata where appropriate i.e. date, time, user ID, machine ID
1.86. The use of geospatial aids (maps) is usual in EOC to aid visual representation of an emergency and as an aid to analysis of the situation. Emergency situations suit such analysis because typically incidents within a wider emergency occur at some location. To facilitate display and analysis within a
geographical information system (GIS) (during and subsequent to an emergency), in capturing those locations, the call-taker should be able to choose from managed lists the location that fits the description from the caller i.e. Address (18 Hampden Street, Murchison), Road Intersections (cnr Motueka Quay and Glenaven Drive, Motueka), Road (waimea Road, Nelson), Place or Places (Broadgreen House or Appleby School), River Segments (Washbourn Stream between Hill Street and Washbourn Drive or Motueka River between Woodstock and Stanleybrook).
1.87. Assigning criteria to calls: The person taking the call will need to be able to assign a range of different criteria to an individual message.
• Validation: Who was the caller? How reliable is their information? Was the caller ‘Joe Bloggs’, untrained and unqualified member of the public or a trained and experienced member of Emergency Services or an Emergency Management Field Operative? The information supplied by the latter would be rated higher than the former.
• Urgency: i.e. ‘routine’ through to ‘requires immediate attention’
• Importance: i.e. ‘routine’ through to ‘highest’
1.88. The system would be able to ‘flag’ or highlight individual messages based on a criteria i.e. ‘Red-Flag’ for urgent or important or ‘Blue-Flag’ for routine.
1.89. Have the capability to link or group one or more messages together.
1.90. Often in an emergency situation the EOC will receive multiple calls in a short span of times about the same situation. Rather than record this multiple times, it would be more efficient if you could record the same base information e.g. “Appleby Bridge approaches washed out”, then note the number of calls
received about that. Explain how the system might achieve this.
Request for Expressions of Interest to Supply
Workflow
1.91. Once the EOC call taker or team member has captured all the information regards a particular message, they need to be able to:
• Assign the message to an individual EOC team member
• Assign the message to an EOC team e.g. Planning and Intelligence
• Assign a message to multiple individuals and/or teams
1.92. The system routes a particular message via some form of workflow function to the assigned individual/s and/or team/s
1.93. In the event no individual/s or team/s are assigned to a particular message, the message can be configured to rout particular messages, based on a userdefined criteria to an individual or team based on one of the captured criteria
e.g. all messaged tagged ‘highest’ importance go to the Controller
1.94. Individuals and team can quickly and easily see/be alerted to/find messages assigned to them
1.95. Individuals and/or groups need to be able to add to a message. This may include adding additional information and/or comments. Assigning or reassigning status e.g. under action, closed, validation required, or assigning to an additional individual or team
1.96. Explain how the workflow function works.
1.97. Once messages have been processed have the ability to check or tag them in some way as ‘complete’ or ‘actioned’ etc. and they disappear from the ‘active’ list/screen but stay in the system.
Scalability/Portability
1.98. Could have the capability to be installed, stand alone within Councils smaller EOCs; Motueka, Takaka, Murchison but with the capability to communicate (integrate) with the main EOC
1.99. System can be scaled to monitor and/or manage the range response levels (from Introduction): Level 3 – Local Coordination; Level 4 – Regional Coordination i.e. the system may start off monitoring/managing a single incident which eventually escalates into a full emergency.
1.100. While for most emergencies it would be envisaged the system would operate within Councils existing ICT infrastructure (refer ‘Existing System & Environment section) because of the nature of emergencies it would also need the capability to run in a stand alone situation i.e. be network independent. How would that work?
Integration
1.101. External communication is an important component of an emergency response i.e. letting interested parties know about the status of the emergency; where evacuation points might be; what areas have been evacuated etc. The system would be able to communicate, preferably via standards-based protocols to external agencies/sites i.e. make available data/information feeds in standard formats e.g. Really Simple Syndication (RSS) or Extensible Mark-up Language (XML) or Keyhole Markup Language (KML). Consumers of such feeds could include: Nelson City and Tasman District Offices, Emergency Services (Fire, Police, Ambulance), National Crisis Management Centre,
National Health Coordination Centre. Explain capability for this.
1.102. The system might want the capability to utilise real-time data feeds using standard protocols from TDC and NCC core systems. How could that happen?
1.103. System would have the potential to integrate with Councils geographical information systems (GIS), specifically Environmental Systems Research Institute (ESRI) ArcGIS Server, through web services or other standardsbased integration methods.
How might that work?
Architecture
1.104. Please supply details of the systems architecture.
1.105. Explain how server/PC images, versions and upgrades could be managed particularly at satellite locations such as Murchison.
1.106. How is your system be licensed including those costs.
1.107. Would any changes be required to Councils existing architecture?
Setup and operation
1.108. The system would need to be relatively straightforward and quick to setup/activate/get going once the EOC is activated. Please explain how this might happen.
1.109. Any system should follow established keyboard quick-key functions e.g. Ctrl>C for copy etc.
1.110. Though some system training would be anticipated, graphical user interfaces (GUI) and functional methods would need to be intuitive. Give us some examples if available.
1.111. Please explain how your system creates and manages the message objects it creates?
1.112. In the event of a situation where power supply to the building is affected or the nature of the emergency requires the EOC to relocate, it may be required to fail-over to a manual system. How would/could the system report the current status of the emergency, elements of which the system manages such
that this could be replicated and then managed on-going in an analogue (hardcopy) environment.
Reporting/Display
1.113. The system will need to be able to report on of individual or groups or types of messages based on different user-defined criteria
• Status of messages tagged with a specific urgency rating
• Show messages not actions after a certain length of time
• Show all messages of a certain type e.g. flooding
• or number of messages logged over this time frame
• all messages to a specific user or group
• Please detail reporting functionality.
1.114. Describe any central administration tools you can offer or how you propose council would monitor and support the solution;
1.115. Is there any software that can automatically inform council of problems?
1.116. Is there a central management console and what functions does it support?
Status/Message Board
1.117. The system will need a ‘status board’ functionality to display the latest key data in relation to an emergency event the EOC is managing. This might be thought of as key performance indicator (KPI) reporting and be based on a number of ‘indicators’. The status board will give a ‘snapshot’ of the
situation.
1.118. The status board would also provide key information such as if a state of emergency is declared, and when.
Knowledge Base
1.119. Some kind of knowledgebase would be useful. This could include standard information generic to a general or type of emergency i.e. key contacts, designated assembly points etc. It could also include information about the specific emergency at hand i.e. evacuation centres established, status of individual towns etc. If a knowledgebase was to be utilised in this way it
would need the capability to evolve as the emergency evolved. ...
From: Request for Expressions of Interest to Supply
INFORMATION AND COMMUNICATIONS SYSTEMS FOR COUNCIL’S EMERGENCY OPERATIONS CENTRE (EOC), NELSON CITY COUNCIL and TASMAN DISTRICT COUNCIL, New Zealand, 14 September 2009.
Labels: disaster management, Emergency Alert System, emergency management
Labels: disaster management, Emergency Alert System, emergency management
The Information and Communication Technology Agency of Sri Lanka (ICTA) is the implementing Agency for the e-Sri Lanka initiative. The Re-engineering Government is one of the main programme areas of ICTA, which aims to improve the efficiency of delivery and access mechanisms of the government. The objectives of the Re-engineering Government Programme are mainly to be achieved by re-engineering the government business processes and enabling those processes with Information and Communication Technologies.
The National Disaster Relief Services Centre (NDRSC) which functions under the purview of the Ministry of Resettlement & Disaster Relief Services is responsible for post disaster management and relief in Sri Lanka. The main functions of the NDRSC are Search and Rescue, Disaster Relief and Resettlement & Rehabilitation. The NDRSC functions through the responsible government operatives in district and divisional secretariat levels. It has been identified that the Information and Communication Technology (ICT) can be further deployed to improve the efficiency of NDRSC significantly.
„Sahana‟ is an internationally award winning web based disaster management system which has been successfully deployed to manage various recent large scale disasters by the Government of Sri Lanka, Pakistan, Philippines, Peru, Bangladesh and China. Sahana is a free and open disaster management system and, it has been envisioned that the Sahana would be the perfect solution which could be easily customized and enhanced to cater the requirements of NDRSC.
ICTA now invites Expressions of Interest (EOIs) from eligible Software Service Providers (Firms) to take up this project. Interested consultants must provide information indicating that they are qualified to perform the services (core business and years in business, qualifications in the field of the assignment, technical and managerial organization of the firm, general qualifications and number of key staff, experience in similar conditions etc). The “Scope of Services” and “EOI Information Form” documents are now available at ICTA for further information. Interested parties may download above documents from the website www.icta.lk.
Interested eligible parties may obtain further information from Mr. Christy Perera - Procurement Advisor, ICTA by contacting via Phone: +94 11 2369099, Fax: +94 11 2369091) and E-mail: procurement@icta.lk; christy@icta.lk. Expressions of Interest including all requested information must be delivered no later than 1500 hrs on 10th August 2009 either: (i) electronically to; procurement@icta.lk or (ii) hand delivered or (iii) by post to the address; Procurement Division, ICT Agency of Sri Lanka, 2nd Floor, 160/24, Kirimandala Mawatha, Colombo 05, Sri Lanka.
Please mark clearly on the envelope and subject field of e-mail “Expressions of Interest - Deployment of the Sahana Disaster Management System for the National Disaster Relief Services Centre - ICTA/CON/GOSL/QCBS/38”. ...
From: Request for Expressions of Interest (EOI), Presidential Secretariat, e-SRI LANKA DEVELOPMENT PROJECT, Deployment of the Sahana Disaster Management System for the National Disaster Relief Services Centre - ICTA/CON, GOSL/QCBS/38, 17 July 2009
Labels: disaster management, open source, Sahana
2.2. Construction, content of warnings
Key findings ...
(e) CFA bushfire warnings are assigned three “levels”: Awareness, Alert and Urgent Threat. Ideally, each such warning is posted (in a timely fashion) to the CFA website, read aloud on ABC radio and provided to the VBIL. The evidence before the Royal Commission is that on 7 February 2009 this did not always occur in a timely fashion. ...
2.3. Specific methods of delivering warnings.
2.3.1. Single, multi‐agency bushfire information website for Victoria.
Key findings
(a) The public rely on fire agency websites for accurate and up to date information about fires in their area. ...
(b) Currently CFA and DSE maintain separate websites. CFA and DSE are working to present bushfire information on a single website. ...
Proposed recommendations
(a) A single, multi‐agency bushfire information website for Victoria be established and operational for the 2009‐2010 fire season.
(b) The website must provide timely, accurate and up to date bushfire information posted by the fire agencies, that is consistent with the bushfire information being delivered through other modes, including the VBIL and ABC radio. The website must be designed to communicate information quickly and simply, using visual as well as text based information and have the capacity to function during periods of extreme demand.
(c) The website be designed to allow Incident Control Centres (ICCs) to post bushfire information directly to the website.
2.3.2. Standard Emergency Warning Signal
Key findings
(a) The Standard Emergency Warning Signal (SEWS) is not itself a ”warning”. Rather, it is a distinctive alert tone or signal broadcast prior to warnings for major emergencies. It is designed to “alert listeners/viewers of radio/television that an official emergency announcement is about to be made concerning an actual or potential emergency which has the potential to affect them”. ...
(b) The current protocol for the use of SEWS requires the control agency to request the police to authorise its use. Victoria Police (via the Divisional Emergency Response Coordinator) then sends an “Emergency Warning Notice” to the media. On receipt of that formal request to issue a warning, the media are expected to broadcast the warning message, preceded by the distinctive “SEWS tone” for 15 seconds.
(c) SEWS was not used on 7 February 2009 in Victoria. Its use is not referred to in the Emergency Management Manual. Indeed, SEWS has not been regularly used in Victoria, because of concerns that it can be overused and thereby become ineffective and the possibility that it might cause “confusion”. ...
(d) There is no research to suggest that use or “overuse” of SEWS has caused any significant confusion or inconvenience in the community. ...
(e) The Commonwealth has been considering a “relaunch” of SEWS, however it ceased that work in anticipation of the findings of this Royal Commission. ...
(f) SEWS is useful in alerting people to the content of a warning message to follow, and it has been used in South Australia (since 2005) for that very purpose. ...
Proposed recommendations
(a) The Standard Emergency Warning Signal (SEWS) must be used in Victoria to precede each Urgent Threat message in relation to a bushfire and in all circumstances where lives are at risk by reason of bushfire.
(b) The Emergency Management Manual Victoria should be amended to provide that:
(i) the use of SEWS is to precede each urgent threat message issued in relation to a bushfire;
(ii) the use of SEWS is required in all circumstances when lives are at risk; and
(iii) the use of SEWS may be authorised during bushfires by the Chief Officer of the CFA or the Chief Officer of DSE.
(c) The State Government to commence an intensive education campaign to inform the Victorian community that the distinctive SEWS signal will be used before each Urgent Threat message for bushfires and in all circumstances where lives are at risk by reason of bushfire.
(d) The ABC, CFA and DSE to implement a streamlined process for the use of SEWS on ABC radio and television.
(e) The CFA and DSE to invite commercial operators to enter into a Memoranda of Understanding in relation to the dissemination of bushfire warning messages and a process for the use of SEWS by those operators.
2.3.3. Community Information and Warning Systems and Dissemination of Warnings
Key findings
(a) In 2005, the Office of the Emergency Services Commissioner (OESC), in partnership with Telstra, ran a successful trial of an opt in land line telephony based community warning system in two communities in Victoria. ...
(b) Since the 2005 trial, Victoria’s position has been that a national community information and warning system should be implemented. Victoria has advocated this position forcefully at the highest levels, including in communications between the Premier and the Minister for Police and the Commonwealth. ...
(c) The use of a nationally consistent community information warning system drawing on such technology is supported in an AFAC Discussion Paper: “A National Systems Approach to Community Warnings”, 3 June 2009. ...
(d) On 2 October 2008, COAG formally noted that “A nationally – consistent community emergency warning system will enhance the current capability to provide timely and accurate warnings in the event of emergencies and provide useful information and advice on individual and community responses. COAG has requested that all remaining tasks, including a cost – benefit analysis, be completed by the end of 2008”. ...
(e) But the period between 2006 and 2009 was largely characterised by delay. There was extended debate between Commonwealth departments about the need for legislative amendment to facilitate access to the Integrated Public Numbers Database (IPND). ...
(f) On 3 December 2008, the Attorney General wrote to the Minister for Broadband, Communications and the Digital Economy stating: “As noted by COAG, a telephony based warning system has the potential to save lives”. ...
(g) During the period 2004 to 2009, the Department of Broadband Communications and the Digital Economy maintained the view that changes to the Telecommunications Act 1997 (Cth) were necessary to permit access by emergency services to the IPND. ...
(h) The delay was also in part due to the fact that until after the 2009 fires, the States and the Commonwealth had not agreed on the appropriate model for a national system. ...
(i) In March 2009, the necessary amendments to the Telecommunications Act 1997 (Cth) were made. ...
(j) On 2 March 2009, after the February 2009 fires, and before the Telecommunications Act 1997 (Cth) amendments were made, Victoria Police and the OESC determined to issue a mass warning message via SMS in order to warn of predicted severe weather.
Telstra was instrumental in the arrangements for the dissemination of the message. A review conducted in relation to this event revealed a high rate of recall by recipients and “success” in terms of the message delivery. ...
(k) The SMS message was able to be sent by Telstra because access to the IPND was not required, as Telstra simply sent the message to its customers using their billing addresses. Out of "an abundance of caution", Telstra was also supplied with a certificate from Victoria Police which stated that the message was necessary to be sent by reason of a "serious and imminent threat" to life. Although this certificate echoes the wording of the exception in s287 of the Telecommunications Act 1997 (Cth), Telstra did not in fact purport to rely on that section. Indeed, Mr Consolo accepted in evidence that Telstra has always possessed the capacity to send such an SMS message to its customers, though this message offers no "geo‐coding" function. Mr Esplin, in his evidence, noted that the agreement of carriers to take such a step was, in his view, unlikely to have been obtained prior to the events of 7 February 2009. ...
(l) On 30 April 2009, following a COAG meeting, the Commonwealth announced that COAG had agreed to implement a national telephone emergency warning system. The first stage (which COAG said would be in place by October 2009) will provide warnings in the form of recorded voice messages and SMS messages to the billing addresses of landline and mobile phones. A second stage of the system that would permit sending of
phone messages based on the location of the telephone handset is to be investigated. ...
(m) Despite the development of this new technology, it is clear that multiple methods of dissemination of warnings should continue to be used for the following reasons:
(i) members of the community may obtain information in a variety of ways including websites, telecommunications, radio and informal networks – and tend to like to confirm information received with other sources; and
(ii) it is advisable to preserve multiple modes of disseminating warnings (including old technology such as sirens, door to door visits, radio and new technology such as SMS, official websites, informal websites, Twitter, Facebook) to reach the broadest possible audience and to guard against failure of any single mode of communication. ...
(a) The Commonwealth and COAG should ensure that implementation of stage one of the new national emergency warning system prior to bushfire season 2009‐2010.
(b) The State of Victoria should be an active participant in the development, implementation and operation of the new national emergency warning system.
(c) The State of Victoria should immediately commence a program of community education in order to ensure that Victorians are well informed about the proper use of and response to the use of the new national emergency warning system, particularly in the event of bushfire, prior to the 2009‐2010 season. Such community education program to draw on the experiences of the “Community Information and Warning System: The Report of The Trial and Evaluation”, OESC (2006) ...
(d) If by September 2009, it appears unlikely that the first phase of the national system will be operational, the State of Victoria to make representations to the Commonwealth Government with a view to securing a commitment that the system will be available at least in Victoria’s Bushfire Risk Zones by bushfire season 2009‐2010.
(e) Multiple means of disseminating warning message should be retained including the continued use of ABC broadcasts, a single multi agency website (see proposed recommendation 2.3.1) and sirens where adopted by particular communities (see proposed recommendation 2.3.4).
2.3.5. Publication of Fire Danger Index forecasts
Key findings
(a) The Bureau of Meteorology routinely forecasts the Forest Fire Danger Index and the Grass Fire Danger Index (collectively the Fire Danger Index or FDI) and provides these forecasts to the fire agencies. ...
(b) The FDI forecasts are not included in the general weather forecasts posted on the Bureau’s website or distributed to the media. They are made available to the public only in the fire weather forecasts posted on the Bureau’s website on the afternoon before the day in question. ...
(c) A number of lay witnesses wanted to see the FDI forecasts published more widely. ...
Proposed recommendations
(a) The Bureau of Meteorology include the Forest Fire Danger Index and Grass Fire Danger Index in its fire weather warnings and general weather forecasts posted on its website and distributed to the media. ...
4.9. Application to those in places other than homes – e.g. schools, nursing homes, hospitals
Proposed Recommendations – stay or go (key findings 4.1‐4.9)
(ii) that before the commencement of the 2009 ‐ 2010 fire season they be revised and enhanced to clearly convey the following ...
(M) Advice about when to leave, incorporating a cascading series of triggers
(noting that a warning may not be received and should not be relied upon)
namely ...
• When you are advised to be on alert in relation to a fire that has
commenced. This requires that you pay attention to fire information sources (ABC, fire agency website) on days of total fire ban and extreme fire risk. ...
8. Detection of fires
8.1. Early detection, mapping and prediction of fire spread
Key findings ...
(n) Threat messages issued concerning the Kilmore East fire prior to 18.00 on 7 February 2009 made no reference to the anticipated frontal change. ...
(p) Kilmore ICC authorised at 16.10 on 7 February 2009 release of threat message warning communities from Kinglake to Strath Creek of fire. That message did not appear on the CFA website. ...
(r) Narbethong was the subject of a threat message on the DSE website at 16.45 on 7 February 2009 and Marysville was the subject of a threat message on the DSE website at 17.15 on 7 February 2009. ...
19.2. Communications infrastructure
Key findings
(a) Warnings, both formal and informal, are communicated by a range of means including mobile and fixed line telephones, radio, television and the internet. Members of the public need to be able to contact emergency services in an emergency.
Communications within and between emergency services agencies are vital to an effective and co‐ordinated emergency response. A reliable and robust communications infrastructure is therefore essential.
(b) The Commission has heard evidence that indicates that Victoria’s communications infrastructure was placed under great stress on 7 February, and that there were difficulties in communicating with and within emergency services, and generally. ...
(c) To date the Commission has heard evidence from the ABC, ACE Radio Broadcasters, Telstra, ESTA, DSE, CFA and Victoria Police in respect of public radio and television, fixed and mobile telephone networks, managed radio networks and the operation of emergency call services. Some of these communications media performed well on 7 February, others less so. ...
(d) The Commission has also heard evidence that indicates that communications in some parts of Victoria are less than optimal under normal conditions. ...
Proposed recommendations
(a) No further recommendation is proposed. Victoria’s communications infrastructure will be the subject of evidence in future hearings. ...
From: Proposed Interim Report of the 2009 Victorian Bushfires Royal Commission, Counsel Assisting, 2 July 2009.
Labels: 2009 Victorian Bushfires Royal Commission, Australian Emergency Alert System, bushfire, disaster management, Emergency Alert System, emergency management, mobile web, web design
Sahana Free and Open Source Disaster Management System | New Zealand Cluster
Have a Play
Get Involved
http://tinyurl.com/nz-sahana-cluster
Turn Up
5:30pm, 30 July 2009, Level 6, Willis Street, Wellington, New Zealand
(RSVP via http://tinyurl.com/nz-sahana-cluster)
What is this anyway?
The New Zealand Sahana Cluster is being formed to bring together technology experts, translators, emergency managers, researchers to bring forward widespread adoption of Sahana in New Zealand.Sahana is Sinhalese for 'Relief' and signifies the history of the project from its development to reconnect families displaced due to the Boxing Day Tsunami. The New Zealand Cluster seeks to have the same positive impact for Kiwi communities.
Some deployments:
- Asian Tsunami in Sri Lanka (2005)
- Kashmir Earthquake in Pakistan (2005)
- Landslide disaster in Philippines (2005)
- Sarvodaya and Terre des Hommes, Sri Lankan NGOs (2005-)
- Yogjakarta Earthquake, Indonesia (2006)
- Earthquake in Peru (2007)
- Cyclone Sidr in Bangladesh (2007)
- Coastal Storm Plan in New York City (2007-)
- Ica Earthquake, Peru (2007)
- Chendu-Sitzuan Earthquake, China (2008)
- National Disaster Management Center &
- Ministry of Resettlement & Disaster Relief Services, Sri Lanka (2009)
International Sponsors:
Labels: disaster management, emergency management, New Zealand, open source, Sahana
In my analysis of the Australian Government's Swine Flu web site I suggested the instructions for handwashing could be improved. The instructions are contained in a 24 kbyte GIF file on the "Individuals and households" page. Here I have separated the four steps into individual images, reduced to 32 colours, and removed text from the images. The result is four files, each of 4 kbytes.Wet your hands, then apply soap.
Lather vigorously for 15 to 20 seconds.
Rinse with water.
Dry your hands afterwards with a clean towel.
Labels: disaster management, emergency management, Swine Influenza, web design
You note in paragraph 16 that the audience for a warning may be hugely variable and towards the end of that paragraph you note that, "People go to different sources. Some community members may be habitual uses of the internet, others might be more likely to turn to the radio, others might use personal networks. There are different preferred modes of receiving information." How does that then impact on the way that one should take care to disseminate warnings?---Ideally - I mean the community at risk is infinitely diverse. Each individual, we could argue, has a unique preferred way of receiving a warning, but at some level we have to stop, I suppose. But ideally the modes that are the preferred ways for that community at risk to receive their information should be the modes that are used, given whatever is practical, and that means, almost always it means that there would be several modes.
So it would be preferable in your view to use the internet as well as ABC Radio and perhaps even give consideration to other modes like phone calls or Twitter sites?---Yes, that's right. They are all reasonably technological means. One could argue that in many communities to ensure that the more vulnerable people - it depends on the community - are reached, we would probably need to get into the local networks, the personal networks or the community networks to try to activate, if you like, the neighbourhood to make sure that people who may not receive warnings via those modes receive them either by direct personal contact or some other way, and that they make sure that they are in a position to take what sort of protective action is needed. But this is tapping into what we call the informal warning system. Is there another benefit to disseminating by more than one means, namely in case of failure of one means or imperfect delivery of one means during a crisis?---That's right. We would argue that reliance on any single mode of dissemination is pretty risky, partly because it is not going to get to everybody no matter what it is and, secondly, any single mode is subject to failure or congestion or interruption.
The next aspect you turn to in your statement is timeliness and you note in paragraph 17, "A warning should be delivered in a timely manner so as to allow people to confirm what they have to do and take action in time." Is that a feature you have noticed in your research, that people usually seek confirmation from further sources before they act?---There are two things that come out of the research, main things. One is what you have just said, that people will almost always seek confirmation. Officials will, too. But people at risk will seek confirmation usually by mobilising their personal networks or if they hear something, read something on the web, listen to the radio or TV or ring somebody or vice versa. This is pretty normal and we have found often people - they also might want to ascertain the location of other household members. There are a number of things go on typically before people take action. The other thing we have noticed is that very frequently people receive the warning or at least understand that the warning is important to them too late to do anything useful. ...
Websites. Can we go to question 5, which starts at page 0018, and you note in paragraph 67 that web-based material has really become the primary source of information in our society. In paragraph 69 you make some points about who uses the internet. You say that even though it seems ubiquitous, in 2006 about a quarter of Victorians didn't have internet access. So, although that is a declining proportion, that needs to be kept in mind. That comes from the census data, is that right?---That's right. So it remains the case that the web is not a fix all. One would need to keep in mind promoting messages through ABC Radio and other means?---That's right. The point there is that a proportion of households, and they are likely to be people who are more vulnerable, elderly people and so on, do not have web access. It is also an interesting thing that people who promote the web as a vehicle for warnings have an implicit assumption that people are out there actively seeking their warnings on the web. We don't have evidence for that.
That's an important point you make at point 3: "Websites offer a passive form of warning. That is, they don't alert you to come and read them, although you will find the message if you go and look for it"?---That's true. There are a variety of ways of overcoming that and making websites active through all kinds of tools that can send the messages to you now, Widgets, Twitter and so on. But, nevertheless, the basic principle is that a website is a passive form of warning.
It could be used in conjunction, though, couldn't it, with those other tools you mentioned. If there was a SEWS signal played on the radio or an automated phone call or a text message, part of which suggested looking at a website, that might combine the call to action with finding more information on the website?---It could, or it could simply be that the material on the website is sent to your mobile phone or whatever by one of these devices and there are several possibilities with that.
You note over the page on 0019 some issues about currency and reliability and the issues which may arise when a website is under heavy demand. We touched on this when you spoke of your own experience on 7 February. Is there a way to address the situation when websites are under heavy demand and therefore slow down or even become inaccessible?---They tend to slow right down, that's right. There are a number of ways of addressing it.
Probably the simplest way is for people to take the information off the site automatically and feed it onto other sites or other systems. In the fires on February 7th the material from the CFA site was re-posted, if you like, via Twitter. There was an unofficial site, CFA updates, which was a Twitter site, and that is still active, actually. That was one of a number of sites that on the day took material unofficially from the site. There is a way of doing it which is quite legitimate and CFA encourage it. So, that's one way. What that does is take the load off the site. Another way is to ask people not to use it or to restrict access, but that doesn't seem very promising to me, given that we actually want people to use it, but that's a standard response. Otherwise, there are a number of technical ways of doing this which I outline in the paper. They are basically about reducing the degree of interactivity with the site, so that when you go into the site you don't actually - what you get is just sitting there. The amount of processing power that site needs to use is limited one way or another. Things like graphics, logos and so on, which we have more and more of them on our sites, are pretty hungry for memory.
The idea is not to use them in these emergency situations. In one sense it is an argument for moving to a different website mode in a major emergency when you know the demand is going to be great. I don't know whether I mention it here, but after the tsunami the British Commonwealth and Foreign Office or Foreign and Commonwealth Office website on travel advisories and so on switched to a text only mode for precisely this reason.
And that reduces the memory use?---That's right. It can handle a lot more inquiries.
I note in paragraph 72 you suggest, if we just deal with websites bit by bit, you suggest first of all that it would be useful for there to be one website rather than the DSE and the CFA websites?---A lot of people are arguing this, that there should be one website, but it is a trade-off, I want to say, as well, because if there is one website, all the problems we are talking about in terms of website overload and so on are exacerbated. The solution of course is that there are two sites but they mirror each other's content.
So two sites with the same content or multiple sites with the same content may help?---Yes. I think a single site in terms of content is the ideal, but if we look at the practicalities and the reliability, we are much better off having a number of sites.
Is there also potential to enable information within a website to be hived off, namely to enable people to look at particular messages pertaining to particular parts of Victoria so that they are using different pages or different information at the one time?---Yes, there are a range of devices and so on that can be embedded in sites to do that, and even to send them to the people concerned. You set out all these matters working through to paragraph 80 in the statement. Paragraph 77 is where you deal with the RSS feed. This is the capacity you spoke of for the material on an internet site to be mirrored, if you like, over on a Twitter site?---Yes, but not quite. The RSS feeds really just take key information. They don't take the whole information of the site. That is one reason why they can actually feed information on to sites like
Twitter or even mobile phones if the system is enabled. They take headliners, basically.
Dealing with sirens, which is question 6 - - -
COMMISSIONER PASCOE: Before we leave the websites, a question about the Bureau of Meteorology site which had, we are told, 70 million hits on the day and is used to having a massive - - -?---It is the most popular in Australia, I think, the most popular government site.
I don't know whether you have looked at the features of that site and what enables that site to cope with the heavy demand vis-a-vis the sites that we have just been talking about and whether there are any lessons we can learn from the bureau website?---I'm sure there are, but I haven't personally investigated them, but a lot of the bureau's material is in very basic text form and I think that's probably one of the key features of enabling that site to handle such loads. But I think that would be a worthwhile. I think it is the fourth most popular site in the country. ...
Turning to new technology, question 7, this is a matter you discuss in paragraphs 91 onwards and you refer to the new technologies which have emerged. You make the point in paragraph 93 it is important not to overlook our longstanding communication technologies, including radio. In paragraph 95 you say that it is important to distinguish between new technologies that deal with the centralised systems, such as CAP, and those that relate to individualised information. I take it from what you say here there is certainly a role for new technologies to play and it is a field that continues to develop?---I think the new technologies, in terms of delivering a message, as we were discussing, to the people at risk, have only very recently started to play a major role, but it has been quite quick and now most people in our society, I would say the majority of people by far use either a mobile phone, text, are very familiar with texting and the internet as their normal means of gaining and sending information or whatever. So we have to use them if we want to reach particular audiences and there are many variations of those modes.
Because you mention in paragraph 98 Facebook sites that are mostly post-fire, but Facebook sites, MySpace sites and in paragraph 99 the Twitter site as new technologies being used by portions of the community that ought not be overlooked?---That's right. Some of these played a role, like Twitter sites, in warnings. There is anecdotal evidence that people got warnings on Facebook because they were looking at some aspect of Facebook and suddenly some message came across. But people weren't using Facebook, as far as I can see, for warning purposes but it fulfilled that role.
At paragraph 100 you refer to phones and mobile phones and you make the point obviously they are very familiar. For landline phones, about halfway through paragraph 100, you note the technology which enables locations connected to landlines to be selected which could be used to delimit areas. That might be useful, for example, in any automated phone warning system?---Yes. That's the idea, yes.
You point out the advantages, but also the disadvantages. There may be lack of mobile phone coverage, there may be issues with phone traffic?---And there is a privacy issue with unlisted numbers and so on. But, yes.
Are you familiar with the recent announcement by the Commonwealth government to now establish a national phone automated warning system?---Yes, I am familiar with that. You refer to the common alerting protocol. It, as you mention there, is really a mode of standardising the content of warnings to ensure that it is the same over different modes of dissemination?---Yes. The common alerting protocol relates to what we were discussing a while ago, the write-it-once concept. As you say, it is a standardised message, it has a standardised format and then the idea is that this message can then be disseminated over any number of digital modes. So it has that advantage of speed and also has advantages in being able to go on multiple modes that perhaps would have to be manually uploaded in the past. ...
From: Transcript of Proceedings , 2009 Victorian Brushfires Royal Commission , TUESDAY 16 JUNE 2009, 24th day of hearing
Labels: 2009 Victorian Bushfires Royal Commission, bushfire, disaster management, e-documents, emergency management, Victoria
There are some technical faults in the Australian Government's "Swine Flu Outbreak" web page. Below are some suggestions to fix the faults, improve the site and a general approach to improve the provision of such information online."The character encoding specified in the HTTP header (utf-8) is different from the value in the <meta> element (iso-8859-1). I will use the value from the HTTP header (utf-8) for this validation. "The missing ALT should be added and the character set mismatch corrected. Consideration should be given for using a later version of HTML than HTML 4.01 Transitional, for the document.
Labels: disaster management, emergency management, Swine Influenza, web design
The multimedia documentary "A June to Remember" was produced by
Record Id: 43215401 (Australian Library Collections) permalink Title: 1233 ABC Newcastle presents a June to remember [videorecording] Also Titled: June to remember Published: Newcastle, N.S.W. : 1233 ABC Newcastle, [2008] Description: 1 videodisc (DVD) (ca. 48 mins.) : sd., col. ; 4 3/4 in. Summary: In the lead up to the June long weekend in 2007, most people in Newcastle were looking forward to a few days off work. What eventuated was far from a relaxing long weekend. On the June long weekend in 2007 two low pressure cells brought gale force winds that battered Newcastle and caused fatal flash flooding. Massive seas and cyclonic winds pushed the coal freighter Pasha Bulker aground on Nobbys Beach while the region was left stunned by widespread storm damage worth an estimated billion dollars. Nine people died and hundreds of people were forced out of their homes because of flooding and storm damage. For three days, 1233 continued an around-the-clock emergency broadcast. This coverage was only possible thanks to dedicated staff and passionate listeners. This is the story of the June long weekend storm. The voices are yours and the images are the ones you shared with us. Credits: Original music by Bruce Mathiske ; produced by Geoff Overmyer ; concept: Philip Ashley-Brown Performer: Narrated by Carol Duncan. Subjects: Pasha Bulker (Ship)
Storms -- New South Wales -- Newcastle.
Storms -- New South Wales -- Hunter River Region.
Floods -- New South Wales -- Newcastle.
Floods -- New South Wales -- Hunter River Region.
Stranding of ships -- New South Wales -- Newcastle.
Nobbys Beach (Newcastle, N.S.W.)Other Authors: Duncan, Carol.
Mathiske, Bruce.
Overmyer, Geoff.
Ashley-Brown, Philip.
1233 ABC Newcastle (Radio station)Want to contact your library about this item?: Find contact details Libraries that have this item: Lake Macquarie City Library (NLMPL) held
Newcastle Region Libraries. Newcastle Region Library (NNPL) HELD
From: Catalogue Entry, National Library of Australia, 2008
Labels: ABC, Australian Emergency Alert System, disaster management, emergency management, multimedia
Labels: disaster management, emergency management, Istanbul, Train, Turkey
Labels: disaster management, Google, Sahana
Joint Media Release
Attorney-General
The Hon Robert McClelland MPMinister for Broadband, Communications and the Digital Economy
Senator the Hon Stephen Conroy23 February 2009
RUDD GOVERNMENT IMPLEMENTS COAG AGREEMENT ON TELEPHONE-BASED EMERGENCY WARNING SYSTEMS
The Rudd Government will today introduce into Parliament amendments to the Telecommunications Act 1997 to enable access to the Integrated Public Number Database (IPND) for telephone-based emergency warning systems established by the States and Territories.
Access to the IPND will be provided through a new secure database which provides real-time access to up-to-date telephone numbers while protecting the identity of individuals. The Government will provide $11.3 million for this purpose. A request for tender to build the database will be issued shortly.
Telephone-based emergency warning systems have been the subject of discussions between the Commonwealth, States and Territories since 2004. Until 2008, no agreement was reached.
In 2008, the Rudd Government placed the issue on the COAG agenda. COAG agreed it was a priority and commissioned the work necessary to reach agreement by the end of 2008. This work was completed, and agreement was achieved in November 2008.
This agreement was necessary to address important concerns such as ensuring telephone-based emergency warning systems do not overload and disable the telecommunications network (including access to the 000 emergency hotline) and the security of individuals’ personal information.
In accordance with the agreement, the Government immediately commenced drafting legislation to authorise access to the IPND. The necessary legislation and database the Government is putting in place will enable the States and Territories to access the data needed to develop their own warning systems as soon as possible.
The historical advice to the Commonwealth has been that any plan to allow the States and Territories access to the IPND as part of any emergency warning system would be best secured by a legislative amendment. Nevertheless, in light of the bushfire emergency in Victoria the Government has also sought advice from the Solicitor-General on an interim measure to allow access.
Based on this advice, the Government will today also make a regulation under the Telecommunications Act 1997 enabling interim access to the IPND.
This will enable immediate access to the IPND by individual States and Territories who wish to implement a more limited system as soon as possible. It should be emphasized that this is not a long-term solution and not a substitute for amendments to the Telecommunications Act 1997 and the planned future access arrangements for the IPND.
Under the COAG agreement, States and Territories retain autonomy about the warning systems they choose to implement.
The Commonwealth has today written to the States and Territories advising that if they are able to agree to a national system at the next possible COAG meeting the Commonwealth will make a further financial contribution to establish such a system, to be owned and operated by the States and Territories.
Whether or not a national system is established, there remain technological challenges to overcome to enable any system to communicate with all telephones in a threatened area. Advice to the Government is that current technology is limited to communicating with fixed landlines, and mobile telephones on the basis of billing address only (rather than the location of the handset). This can mean individuals in a threatened area do not receive a warning on their phones, and individuals outside a threatened area receive irrelevant warnings.
To help address this gap, at the next COAG meeting the Commonwealth will offer the States and Territories financial assistance for them to conduct collaborative research on the viability of a location-based emergency warning system.
It should also be remembered that telephone-based emergency warning systems are only a supplement to, and not a replacement for, the range of measures currently used to warn the public of emergencies, such as television and radio, public address systems, doorknocking, sirens, signage and the internet.
The steps announced by the Rudd Government today will help make telephone-based emergency warning systems one part of Australia’s disaster response capability. ...
Labels: bushfire, disaster management, emergency management, Telecommunications, Tsunami
