[HOT] Damage evaluation tagging schema
Dale Kunce
dale.kunce at gmail.com
Thu Mar 19 12:17:27 UTC 2015
The idea of damage specific tags is really important. I've said this
previously but it would be really good to take advantage of HOT Summit to
have a face to face discussion with HOT folks and humanitarian
organizations to derive what would be valuable and how best to map it. I
again encourage everyone who is interested in this topic and other similar
ones to come to the HOT Summit.
On Thu, Mar 19, 2015, 1:49 PM Jean-Guilhem Cailton <jgc at arkemie.com> wrote:
> Hi All,
>
> Coming back to this important and interesting thread, thanks to Pierre,
> Mark and Maning, after the question was raised again in the context of
> Cyclone Pam in Vanuatu.
>
> As a reminder, this is for recording data linked to an event, like a
> natural disaster or a disease outbreak. And several events can affect a
> same area, like for example in the Philippines with repeated typhoons.
> It is also desirable that the tagging scheme allow for efficient queries.
>
> We could simply use a fixed key to record as its value the name of the
> event, and then qualified keys that include the event name.
>
>
> For example, "context:event"="pam"
> (or "ruby", or "haiyan", or "floods201503" if the event doesn't have a
> name), where "context:event" is the fixed key.
>
> And then qualified keys including the name string "pam" as one of their
> component, for example:
> "damage:building:pam=destructed/damaged/..."
> "damage:source:pam=Pleiades/aerial mission/survey/..."
>
> This could even apply to other tags than damage that are also related to
> the event, like:
> "operational_status:pam=open/closed/limited"
>
>
> The fixed key is easy to search or query, and then the linked keys can
> be built based on it.
>
> If there are several events, things could be tagged, for example:
> "context:event"="haiyan;ruby"
> "damage:building:haiyan=damaged"
> "damage:building:ruby=destroyed"
>
>
> Note that this is related to the notion of lifecycle prefix
> (http://wiki.openstreetmap.org/wiki/Lifecycle_prefix), and before it to
> schemes such as "highway=construction"+"construction"="primary". I have
> no hard preference whether the event name should go as prefix or suffix. :)
>
> The important point to generalize previous schemes, from a data
> structure point of view, is that there be a key to define the name of
> the context event.
>
>
> (Sheltering, rebuilding, development or even data collection programs
> could later also become such context event name keys, if necessary for
> recording).
>
> What do you think?
>
> Best wishes,
>
> Jean-Guilhem
>
>
> Le 23/01/2015 05:35, Markware Software Services a écrit :
> > Hi Pierre
> >
> > Actually, another issue needs to be addressed as well, what if an area
> > experiences two (or more) disasters, Ruby could well of passed over
> > Tacloban, now we would have two sets of data to manage. I recall you
> > doing something about that during the Ruby Activation.
> >
> > Is it relevant that a building was subjected to damage from two events?
> >
> > I guess the question is, how long should crisis related data persist
> > and what data should persist.
> >
> > For example, if a building was initially mapped as a result of a HOT
> > activation, is that relevant information for future mappers?
> > Historically, is it relevant to know it entered the OSM database as a
> > result of that effort?
> >
> > On possibility is to use the data for later assessment on the
> > rehabilitation work that was done??
> >
> > Just some idle thoughts
> >
> >
> >
> >
> >
> > 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 12:17 PM, Markware Software Services
> > <markwaresoftware at gmail.com <mailto:markwaresoftware at gmail.com>> wrote:
> >
> > Hi Pierre
> >
> > Postgres Pattern Matching IS basically the same as Regex
> >
> > http://www.postgresql.org/docs/9.0/static/functions-matching.html
> >
> > It is more efficient to have the string you are searching for at
> > the beginning as an index can be utilized, but searching in the
> > middle of a string will trigger a sequential scan.
> >
> > Some kind of Lucerne Indexing may offer an option, but I have
> > never worked with that on Postgres.
> >
> > Cheers
> >
> > Mark
> >
> >
> > 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 11:56 AM, Pierre Béland <pierzenh at yahoo.fr
> > <mailto:pierzenh at yahoo.fr>> wrote:
> >
> > 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 did
> > 1. Aerial imagery evaluation
> > 2. 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 example
> > select 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 makeefficient 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
> > <mailto:ravilacoya at gmail.com>>
> > *À :* hot at openstreetmap.org <mailto: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/hot/attachments/20150319/c32754d8/attachment.html>
More information about the HOT
mailing list