[HOT] Damage evaluation tagging schema

Fri Jan 23 03:56:34 UTC 2015

Hi Rafael,
There can be more then one step of evaluation and this both for evaluations based on imagery or field survey. 

For Haiyan we did1. Aerial imagery evaluation2. Aerial imagery revision (later revising objects already evaluated)3. Red Cross did some Field survey evaluations.

About the order of elements, I thought that this order would faciliate queries. 
For exampleselect key=damage:evaluation:select key=damage:evaluation:barrier:
Overpass Regex query can be used except I think adding a negation. 
see http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Key.2Fvalue_matches_regular_expression_.28.7E.22key_regex.22.7E.22value_regex.22.29

Would it be efficient to make efficient Regex queries with postgresql? Then,  I think that the order of the elements would be less a problem. 
 Pierre 

      De : Rafael Avila Coya <ravilacoya at gmail.com>
 À : hot at openstreetmap.org 
 Envoyé le : Jeudi 22 janvier 2015 21h24
 Objet : Re: [HOT] Damage evaluation tagging schema

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

_______________________________________________
HOT mailing list
HOT at openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/hot/attachments/20150123/22fa8ce1/attachment.html>