[HOT] Damage evaluation tagging schema
Rafael Avila Coya
ravilacoya at gmail.com
Fri Jan 23 02:24:36 UTC 2015
Hi Pierre:
I like this schema. Only two questions:
What do you mean with evaluation and revision?
Why not the event in 3rd and type of object at the end?
Cheers,
Rafael.
On 23/01/15 02:33, Pierre Béland wrote:
> From the discusssion about mapping North of Nigeria, I open a distinct
> thread about the Damage evaluation discussion about the more technical
> aspects related to Damage evaluation and tagging schema.
>
> This wiki page describes the schema used for the Haiyan typhoon.
> http://wiki.openstreetmap.org/wiki/Damaged_buildings_crisis_mapping
>
> As we discussed at the beginning of the Haiyan activation, while
> establishing a temporary schema, this was be revised later to not affect
> tags such as building or highway. Distinct tags should be added to
> reflect damages, road obstacles, debris or any other damage related
> objects. Any modifications will also have to be reflected in the
> humanitarian style to have the capacity to show damages on the map as we
> did for Haiyan.
>
> While the BaseMap is our priority, there might be some emergencies where
> we are asked to collaborate to Damage evaluation. For each of these
> events, we have to discuss among us and carefully evaluate if it is
> pertinent to do so.
>
> Methodology is an other aspect. As it was discussed after Haiyan, there
> are limits to what can be done with Imagery. We cannot have the same
> classification / hierarchy of damages from an aerial evaluation (often
> poor quality images in the context of climate related disasters) and
> field evaluation.
>
> While we might decide to not do these evaluations, it is important to
> establish a good tagging schema and be ready for our next such action.
>
> It dont think that this is a solution to have two attributes on the same
> key like *building="commercial; damaged"*. It would be more difficult to
> query and this would breaks the rules for the map renderer styles.
>
> There are also discussions about adding permanently tags to the database
> and later not revising it. More then a year after Haiyan, there are
> still a lot of damage related tags. I have started to analyze how to
> revise this. But not yet processed.
>
> There are various aspects to consider.
> - Use a map style to render damages (like the Humanitarian style for Haiyan)
> - Distinct methodology for aerial views or survey evaluations ->
> Specific role + limits of aerial views vs structure damages
> - Evaluation vs Revision (either imagery or field survey)
>
> The objects to evaluate can vary from one disaster to the other. From
> the Haiyan experience, below I present proposals for tagging schema
> specific to an event. In this example, in the context of the Haiyan
> typhoon damages. Tnis same logic could be extended to objects affected
> by other type of disasters.
>
> There are also various evaluation actions and status of actions that
> sometimes need to be registered.
> - Type of action: aerial evaluation and revision, field evaluation and
> revision
> - Status of the revision : cloud coverage limited the evaluation.
>
> The OSM key could be structured with various levels separated by
> semi-colons (ie damage:evaluation:building:haiyan).
>
> If both evaluation and revision key where present, the style renderer
> rules could give a priority of revision over evaluation tags.
>
> damage:evaluation:building:haiyan=no_damage
> would supersedeeffect of
> damage:revision:building:haiyan=collapsed
>
>
> Level
> ===========================
> 1 damage
> 2. evaluation, revision
> 3. type, building, barrier, debris
> 4. event (ie. haiyan)
>
>
> key value
> --------------------------------------------------------------------------------
> damage:evaluation:type:haiyan imagery, survey
> damage:revision:type:haiyan imagery, survey
>
> damage:evaluation:building:haiyan damaged, collapsed, no
> damage:revision:building:haiyan damage, collapsed, no
>
>
> Highway Barrier on nodes
>
> damage:evaluation:barrier:haiyan debris, no
> damage:revision:barrier:haiyan debris, no
>
> Impassable highway sections
>
> damage:evaluation:status:haiyan impassable, passable
>
> Area Debris
>
> damage:evaluation:landuse:haiyan brownfield, no
> damage:revision:landuse:haiyan brownfield, no
>
>
>
>
> Example
>
> <tag k='building' v='yes' />
> <tag k='damage:evaluation:type:haiyan' v='imagery' />
> <tag k='damage:evaluation:building:haiyan' v='damaged' />
> <tag k='damage:revision:type:haiyan' v='imagery' />
> <tag k='damage:revision:building:haiyan' v='collapsed' />
> <tag k='damage:revision:type:haiyan' v='survey' />
> <tag k='damage:revision:building:haiyan' v='collapsed' />
>
> <tag k='highway' v='trunk' />
> <tag k='damage:evaluation:haiyan' v='yes' />
> <tag k='damage:revision:haiyan' v='yes' />
> <tag k='damage:evaluation:barrier:haiyan' v='debris' />
> <tag k='damage:evaluation:type' v='imagery' />
> <tag k='damage:revision:debris:haiyan' v='no' />
> <tag k='damage:revision:type' v='survey' />
> <tag k=damage:haiyan' v='yes' />
>
>
> Pierre
>
>
> _______________________________________________
> HOT mailing list
> HOT at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot
>
--
Twitter: http://twitter.com/ravilacoya
--------------------------------
Por favor, non me envíe documentos con extensións .doc, .docx, .xls,
.xlsx, .ppt, .pptx, aínda podendoo facer, non os abro.
Atendendo á lexislación vixente, empregue formatos estándares e abertos.
http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros
More information about the HOT
mailing list