[HOT] Damage evaluation tagging schema

Markware Software Services markwaresoftware at gmail.com
Fri Jan 23 02:21:12 UTC 2015


Hi Pierre

Excellent Thoughts. Interestingly, I am working on a 3D rendering of
buildings project now, and was planning on extending this to HOT's work
when done with the commercial project.

Having everything in one tag "k=" as you propose helps the query and
rendering scenario a lot. The only downside from a database perspective
would be if you ever needed to query for data within the key data itself.
This would be very slow.

For Example:  if someone wanted to display all Haiyan related data the
query would be something like *WHERE k is Not Null and lower(k) LIKE
"haiyan%"* which would trigger a sequential Pattern Match Scan. *k* would
need to be indexed, which would help somewhat.

One option would be to consider a couple of specific tags to help any
searches on columns that can be indexed, like

*hot:damage*=type of damage string (as per your proposal)
*hot:crisis*=Haiyan

This would allow rapid extraction of all Haiyan related data using indexes
with a query like *WHERE hot:damage is not null and
lower(hot:crisis)="haiyan";*

Also, consider adding "hot:" to the tag as this makes it very clear where
the data source is.

Just some thoughts for you to consider


Also, Do you have a summary of what tagging schemes were actually used
during Haiyan, I seem to recall building=damaged, or building=yes, damage=*



Regards

Mark Cupitt

"If we change the world, let it bear the mark of our intelligence"

See me on Open Street Map <https://www.openstreetmap.org/user/Mark_Cupitt>

See me on LinkedIn <http://ph.linkedin.com/in/markcupitt>



*See me on StackExchange <http://gis.stackexchange.com/users/17846/mark-c>*
===============================================================================================
The contents of this email are intended only for the individual(s) to whom
it is addressed and may contain
confidential or privileged information. If you are not the intended
recipient, you must not disclose, copy, distribute,
or use the contents of this email. If you have received this email in
error, please notify the sender immediately and
delete the email and any attachments.
===============================================================================================


On Fri, Jan 23, 2015 at 9:33 AM, Pierre BĂ©land <pierzenh at yahoo.fr> 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 supersede effect 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/hot/attachments/20150123/f3031825/attachment.html>


More information about the HOT mailing list