User:Bgirardot/HOT Damage Tagging Proposal
|Status:||Proposals with undefined or invalid status (inactive)|
The tags in this proposal will be used to map on the ground damage information after a catastrophic events like earthquake, flood, hurricane, fires, conflict. Damage to buildings, roads and other infrastructure will be identified and tagged by both on the ground people (local and responding organizations) via verifiable on the ground reports (geo-located CC0 or CC-BY 4.0 pictures) and remote mapping via satellite imagery, and sUAS imagery as well as other Earth Observing (EO) products where appropriate (landslides for example).
The proposal allows for very simple and reliable damage grading that can be accomplished via satellite or aerial imagery: no visible damage, damaged, destroyed.
The proposal relies on a lifecycle tag for manual and/or automated review at appropriate intervals to determine if the damage is still visible on the ground and should be still tagged as such in OSM.
Building damage data will be used for disaster response and recovery phases of a damage event. Data will be used by humanitarian response organizations, civil authorities, and other parties for scenario modelling, logistics and planning during these phases.
Road damage data will be used to update routing in real time based on damage tags applied to highways. Road data is also used in scenario generating and of course response and recovery activities.
This damage assessment data is already reliably collected via the above mentioned methods, stored in OSM, was and is used in national level damage events for several specific stages of the Disaster Risk Management Cycle.
Adding damage event specific tags will ensure that any and all damage tagging is done under a consistent, well explained, easily accessible schema. Setting up and going through the tag approval process will ensure that we get the most sensible tags that cover the widest range of uses while still remaining appropriate, significant and helpful to OSM and to OSM data consumers.
The inclusion of lifecycle information will ensure that the tags are easy to maintain and stay relevant to OSM.
None of these are examples of the proposed schema, although their experience informed the creation of the current schema. The recent examples incorporated parts of the proposed schema, but not all of it.
- Typhoon Haiyan - http://wiki.openstreetmap.org/wiki/Damaged_buildings_crisis_mapping
- Sendai 2011 earthquake and tsunami - http://wiki.openstreetmap.org/wiki/2011_Sendai_earthquake_and_tsunami
- Haiti 2010 - http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/Humanitarian_Data_Background#OpenStreetMap:_Tags_in_Current_Usage
Recent examples include:
- Nepal Earthquake 2015
- Ecuador Earthquake 2016
- Vanuatu Hurricane 2015
- Separate feature/object from damage tag itself
- Identify event the damage tag is related to for analysis and easily removing them later
- Allow for assessed and revised indication
- Specify type/source of assessment
- Easy to enter, remember, understand for mappers
- Works well with overpass/overpass-turbo queries
- Relatively easy for routing software to work with
- Most similar to existing OSM tagging schemas, reuse where possible
- Allow for initial or revised damage assessment based on ground survey
For any area or node (buildings, amenities, landuse, natural, etc)
damage=[none | minor | major | destroyed] damage:event=event_name[;event_name2;etc] damage:type=[earthquake | typhoon | flood | fire] damage:assessment=[initial | revision] damage:review_date=yyyy-mm-dd ("today's date typically") damage:organization=organization_adding_damage_tags_name damage:building:material[cement_block| brick | wood | concrete | traditional | metal | stone] source:damage=[satellite | aerial | survey]
For ways (highways) These are the same as above, but we add a damage specific key damage:smoothness and use the values from the existing smoothness key values (http://wiki.openstreetmap.org/wiki/Key:smoothness). Routing software could look for the damage:smoothness=* key and if present use that value preferentially over the explicit or implicit smoothness=* value for routing calculations. When the damage tags are removed, routing would return to pre-event status automatically.
damage=[none | minor | major | destroyed] damage:smoothness=[excellent | good | bad | horrible | impassable] damage:event=event_name[;event_name2;etc] damage:type=[earthquake | typhoon | flood | fire | landslide] damage:assessment=[initial | revision] damage:review_date=yyyy-mm-dd ("today's date typically") damage:organization=organization_adding_damage_tags_name source:damage=[satellite | aerial | survey]
A subset of the damage:* tags could (should?) also be used on non damage related polygons such as IDP camps. It would be good to associate the causing event with the IDP camp.
Please comment on the discussion page.