Mapping the Tohoku 2011 Tsunami event with a remote sensing satellite constellation
•Als PPT, PDF herunterladen•
1 gefällt mir•659 views
A reference case for emerging Early Warning System Dissemination Services
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Mapping the Tohoku 2011 Tsunami event with a remote sensing satellite constellation
Ähnlich wie Mapping the Tohoku 2011 Tsunami event with a remote sensing satellite constellation (20)
Mehr von Peter Löwe
Mehr von Peter Löwe (17)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Mapping the Tohoku 2011 Tsunami event with a remote sensing satellite constellation
- 1. ISOPE-2013 Anchorage Conference The 23rd International Ocean and Polar Engineering Conference Anchorage, Alaska, USA, June 30−July 5, 2013: www.isope.org; www.isope2013.org Mapping the Tohoku 2011 Tsunami event with a remote sensing satellite constellation – a reference case for emerging Early Warning System Dissemination Services Peter Löwe, Joachim Wächter Centre for GeoinformationTechnology (CeGIT), GFZ German Research Centre for Geosciences Potsdam, Germany
- 2. ISOPE-2013 Anchorage ISOPE-2013 Anchorage TRIDEC • New technologies for real time‐ intelligent information management in collaborative, complex critical decision processes • In TRIDEC new developments in Information and Communication Technology (ICT) are used to extend existing platforms with a component-based technology framework. • Demonstration in two scenarios: Tsunami Early Warning Systems (Natural Crisis Management) and Drilling Operations. 2
- 3. ISOPE-2013 Anchorage The potential of improved satellite crisis mapping •During a Tsunami early warning event, TRIDEC Natural Crisis Management (NCM) systems provide crucial information on when and where coastlines will be affected. •This critical information can be provided to the operators of satellite remote sensing systems for follow up actions. TRIDEC NCM GUI
- 4. ISOPE-2013 Anchorage Remote Sensing for Disaster Mitigation • 1999: International Charter "Space and Major Disasters“ founded by ESA and CNES. • Approach: „An authorized user can request the mobilization of the space and associated ground resources of the member agencies to obtain data and information on a disaster occurrence.“ • An Emergency On-Call Officer prepares an archive („before“) and acquisition („after“) plan. • Charter-Members handle data acquisition and delivery on an emergency basis.
- 5. ISOPE-2013 Anchorage Tohoku 2011 Earthquake and Tsunami • In the wake of the Tohoku Tsunami Disaster of March 11 2011, the International Charter for Space and Major Disasters was activated to coordinate both the imaging campaigns and the creation of crisis maps. • The affected areas were imaged by satellite-based remote sensing sensors. • Crisis map products were used by Search and Rescue to save lifes.
- 6. ISOPE-2013 Anchorage Charter Crisis Map Product Example This information is crucial for Search and Rescue operations
- 7. ISOPE-2013 Anchorage The Disaster Cycle, TRIDEC, and the Charter
- 8. ISOPE-2013 Anchorage ISOPE-2013 Anchorage Integrated Approach Decide & Act Downstream Warning
- 9. ISOPE-2013 Anchorage Benefits from a EO dissemination channel • Preparations for satellite imaging can begin before the tsunami devastates an Area of Interest, • reducing the time between tsunami landfall and first satellite image take, • speeding up production of crisis maps, • enabling earlier and better coordinated response by Search and Rescue (SAR), • potenially allowing for before/after coverage.
- 10. ISOPE-2013 Anchorage Workflow Integration: Status Disaster Strikes Recovery Reaction Phase Crisis Maps available Message to EO communities EO-Crisis Maps become available Downstream Warning
- 11. ISOPE-2013 Anchorage Workflow Integration: Capabilities Disaster Strikes Recovery Reaction Phase Crisis Maps available EO community: Heads Up ! EO-Crisis Maps become Available earlier Downstream Warning EO: Early Preparation Reaction Phase Crisis Maps available
- 12. ISOPE-2013 Anchorage Evolution of Earth Observation Systems Core parameters for satellite-based remote sensing: • Spatial/spectral resolution („Pixel size“ of sensor) • Temporal resolution (Revisit rate: „Number of satellites“) •Single satellite • Pace for image acquisition planning: Weeks / Days •Constellations of several satellites in one orbit plane • Pace: Day(s) / Hours •Multiple Constellations in multiple orbit planes (upcoming) • Pace: Hours / Minutes
- 13. ISOPE-2013 Anchorage Workflow Integration: Status •Currently, Tsunami Early Warning only considers bullets 2 and 3. •Tsunami Early Warning must provide Tsunami Information (bullet 1) to start the image acquisition process (orange) Satellite Image Data Save lives MappingTaskingOrderingTsunami Warning Imaging Satellite Image Map 1 2 3
- 14. ISOPE-2013 Anchorage Earth Observation: Planning and Tasking • Operators of remote sensing satellites operate a planning and tasking/commandeering cycle to control image acquisition. • Planning: Arrange and prioritize image orders by • Area of Interest (AOI) • Time of Interest (TOI) • Optical Sensors: Cloud Forecast Constraints • Other Factors: Urgency, on-board memory availability, power, etc. • Tasking: Setting of an imaging schedule. • Commandeering: Upload of imaging schedule to sensors + execution.
- 15. ISOPE-2013 Anchorage Case Study: Rapid Eye Constellation • Commercially operated constellation of five satellites • Charter Member • Disaster Mapping since 2009 Summer 2013; Flooding in Central Europe
- 16. ISOPE-2013 Anchorage Example: The RapidEye Satellite Constellation • Constellation operational since February 2009 • Five identical optical remote sensing satellites • ~ 630km above ground • ~ 90 minutes orbit period • Sun-synchronous (overpass 11:30 a.m. local time) Images: RapidEye
- 17. ISOPE-2013 Anchorage RapidEye: Optical Imaging Sensors •Five spectral bands: red / green / blue / red-edge / near-infrared •Resolution of data products: 5m*5m pixel. •Swath width: 77 km •Max. swath length: 1200 km Egypt 2010 Image: RapidEye AG Example: Anchorage
- 18. ISOPE-2013 Anchorage Example: Order Planning/Tasking/Execution The timeline reflects the RapidEye “Two plannings per day” scenario. 10h – 25h Daily Deadlines Order turnaround time Source: Hoja et al.: Optimised Near-Real Time Data Acquisition and Pre- processing of Satellite Data for Disaster Related Rapid Mapping : PFG2010/6,429-438
- 20. ISOPE-2013 Anchorage Daily Planning Sessions Europe, Asia, Oceania Americas March 11 2011: Tohoku EQ became news by 8:00 CET. RapidEye was immediately contacted by GFZ.
- 21. ISOPE-2013 Anchorage Image Product Processing Chain Worldwide Level3A grid of orthorectified tiles (25x25km). Level 1b image product: 2011-3-12, Japan. Crisis Mapping Product Level3A tiles
- 22. ISOPE-2013 Anchorage Daily Imaging by the RapidEye Constellation March 12 2011 March 13 2013 March 14 2011
- 23. ISOPE-2013 Anchorage Use of Volunteered Geographic Information by the EO Community • Gulf of Mexico Oilspill 2010 • Louisiana Bucket Brigade • Ushahidi Open Source Social Mapping Before Ushahidi/Bucket Brigade: Oil residue found on beach Confirmation by EO
- 24. ISOPE-2013 Anchorage TRIDEC Information Logistics NCM Control and Command User Interface DisseminationInterface(Text + Maps)
- 25. ISOPE-2013 Anchorage Components for an EO Dissemination Product EO Tile Grid Tsunami Simulation Isochrones
- 26. ISOPE-2013 Anchorage XML-based Message Format Candidates: CAP and EDXL • Common Alert Protocoll (CAP): Data format for exchanging public warnings and emergencies between alerting technologies. • Flexible geographic targeting using latitude/longitude “boxes”; • Facility for digital images, audio, and video. • Emergency Data Exchange Language (EDXL) - a suite of messaging standards, advanced by the OASIS Emergency Management Technical Committee, EDXL spatial tags
- 27. ISOPE-2013 Anchorage Outline of an automated heads-up process • Derivation of affected coastline segments from Tsunami- simulations and run-up modelling. • Prioritization by estimated time of arrival and severity estimates. • Mapping of affected areas to EO tile grids. • Tasking of EO constellations.
- 28. ISOPE-2013 Anchorage Conclusion: EO Operators Perspective Benefits from dedicated EO warning services: •Preparation for short term crisis mapping ahead of time •Image acquisition as early as possible •Larger data stock •Increased business opportunities
- 29. ISOPE-2013 Anchorage Conclusion: Tsunami Early Warning Systems (TEWS) •The earlier crisis maps become available after a Tsunami, the more lives can be saved. •Satellite-based crisis mapping for large areas is a valuable tool for disaster and crisis management. •TEWS dissemination components can provide customized message formats for EO communities including AOI/ETA . •A suitable dissemination channel for EO will speed up Crisis Mapping and will help to save lives. Satellite Image Data Save lives MappingTaskingOrderingTsunami Warning Imaging Satellite Image Map
- 30. ISOPE-2013 Anchorage Thank you very much
Hinweis der Redaktion
- Source !
- „ One Way“ -> OSM & co: Other way.
- [Wikipedia CAP] The Common Alerting Protocol (CAP) is an XML -based data format for exchanging public warnings and emergencies between alerting technologies . CAP allows a warning message to be consistently disseminated simultaneously over many warning systems to many applications. CAP increases warning effectiveness and simplifies the task of activating a warning for responsible officials. Individuals can receive standardized alerts from many sources and configure their applications to process and respond to the alerts as desired. Alerts from the Department of Homeland Security , the Department of the Interior's United States Geological Survey, and the Department of Commerce's National Oceanic and Atmospheric Administration (NOAA), and state and local government agencies can all be received in the same format, by the same application. That application can, for example, sound different alarms based on the information received. By normalizing alert data across threats, jurisdictions, and warning systems, CAP also can be used to detect trends and patterns in warning activity, such as trends that might indicate an undetected hazard or hostile act. From a procedural perspective, CAP reinforces a research-based template for effective warning message content and structure. The CAP data structure is backward-compatible with existing alert formats including the Specific Area Message Encoding (SAME) used in Weatheradio and the broadcast Emergency Alert System as well as new technology such as the Commercial Mobile Alert System (CMAS), while adding capabilities including: Flexible geographic targeting using latitude/longitude “boxes” and other geospatial representations in three dimensions; Multilingual and multi-audience messaging; Phased and delayed effective times and expirations; Enhanced message update and cancellation features; Template support for framing complete and effective warning messages; Digital encryption and signature capability; Facility for digital images, audio, and video. [Wikipedia EDXL] EDXL is advanced by the OASIS Emergency Management Technical Committee, [2] a group that was formed in 2003 and remains open to participation from organizations, agencies, and individuals from around the world. EDXL is based on detailed requirements and draft specifications provided to OASIS by emergency practitioners, with support from the Emergency Interoperability Consortium, [3] through a project sponsored by the United States Department of Homeland Security’s Disaster Management E-Gov Initiative. EDXL-DE was approved as an OASIS Standard in 2006; EDXL-RM and –HAVE were approved as OASIS Standards in 2008. Implementation of EDXL is promoted by the OASIS Emergency Management Adoption Committee, which was formed in 2009. Background The Disaster Management eGov Initiative of the Department of Homeland Security (DHS) determined in 2004 to launch a project to develop interagency emergency data communications standards. It called together a group of national emergency response practitioner leaders and sought their guidance on requirements for such standards. In June, 2004 the first such meeting identified the need for a common distribution element for all emergency messages. Subsequent meetings of a Standards Working Group developed detailed requirements and a draft specification for such a distribution element (DE). During the same period the DM Initiative was forming a partnership with industry members of the Emergency Interoperability Consortium (EIC) to cooperate in the development of emergency standards. EIC had been a leading sponsor of the Common Alerting Protocol (CAP). Both organizations desired to develop an expanded family of data formats for exchanging operational information beyond warning. EIC members participated in the development of the DE, and in the broader design of the design of a process for the development of additional standards. This was named Emergency Data Exchange Language (EDXL). The goal of the EDXL project is to facilitate emergency information sharing and data exchange across the local, state, tribal, national and non-governmental organizations of different professions that provide emergency response and management services. EDXL will accomplish this goal by focusing on the standardization of specific messages (messaging interfaces) to facilitate emergency communication and coordination particularly when more than one profession is involved. It is not just an "emergency management" domain exercise. It is a national effort including a diverse and representative group of local, state and federal emergency response organizations and professionals, following a multi-step process. Just as a data-focused effort targets shared data elements, the EDXL process looks for shared message needs, which are common across a broad number of organizations. The objective is to rapidly deliver implementable standard messages, in an incremental fashion, directly to emergency response agencies in the trenches, providing seamless communication and coordination supporting each particular process. The effort first addresses the most urgent needs and proceeds to subsequent message sets in a prioritized fashion. The goal is to incrementally develop and deliver standards. EDXL is intended as a suite of emergency data message types including resource queries and requests, situation status, message routing instructions and the like, needed in the context of cross-disciplinary, cross-jurisdictional communications related to emergency response. The priorities and requirements are created by the DM EDXL Standards Working Group (SWG) which is a formalized group of emergency response practitioners, technical experts, and industry. The draft DE specification was trialed by a number of EIC members starting in October, 2004. In November, 2004, EIC formally submitted the draft to the OASIS Emergency Management Technical Committee for standardization. EDXL-RM (Resource Messaging) Overview EDXL-RM (Resource Message) [5] OASIS Standard, which describes a suite of standard messages for sharing data among information systems that coordinate requests for emergency equipment, supplies, and people. Purpose The primary purpose of the Emergency Data Exchange Language Resource Messaging (EDXL-RM) Specification is to provide a set of standard formats for XML emergency response messages. These Resource Messages are specifically designed as payloads of Emergency Data Exchange Language Distribution Element- (EDXL-DE)-routed messages. Together EDXL-DE and EDXL-RM are intended to expedite all activities associated with resources needed to respond and adapt to emergency incidents. The Distribution Element may be thought of as a "container". It provides the information to route "payload" message sets (such as Alerts or Resource Messages), by including key routing information such as distribution type, geography, incident, and sender/recipient IDs. The Resource Message is constrained to the set of Resource Message Types contained in this specification. The Resource Message is intended to be the payload or one of the payloads of the Distribution Element which contains it. History Disaster Management (DM) is a communications program in the Department of Homeland Security’s (DHS) Office for Interoperability and Compatibility (OIC) and managed by the Science and Technology (S&T) Directorate. The program was initiated as one of the President’s e-government initiatives. DM’s mission is to serve as the program within the Federal Government to help local, tribal, state, and federal public safety and emergency response agencies improve public safety response through more effective and efficient interoperable data sharing. The DHS DM program sponsors a Practitioner Steering Group (PSG). The DM Practitioner Steering Group (PSG) governance was formalized following publication of the EDXL Distribution Element. It plays a key role in the direction, prioritization, definition, and execution of the DHS-DM program. The group is composed of representatives of major emergency response associations, setting priorities and providing recommendations regarding messaging standards development as well as the other facets of the DM program. The PSG specified messaging standards-based systems interoperability as the top priority for the DHS Disaster Management program. The EDXL Resource Messaging Specification effort was identified as the top priority standard by this group following the EDXL-DE. The requirements and specification effort was initiated by this group in partnership with industry members of the Emergency Interoperability Consortium (EIC) in a Standards Working Group (SWG). That group developed a draft specification which was submitted to the OASIS Emergency Management Technical Committee to begin work on this EDXL-RM specification. The process remained the same as with the EDXL-DE specification with the exception that the Technical Committee requested that the initial candidate specification submitted by the expert group be recast as a formal Requirements Document according to a template that the Technical Committee provided to the expert group. The candidate specification was then resubmitted along with this requested requirements document.