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 > <markwaresoftw...@gmail.com <mailto:markwaresoftw...@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 <pierz...@yahoo.fr > <mailto:pierz...@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 <ravilac...@gmail.com > <mailto:ravilac...@gmail.com>> > *À :* hot@openstreetmap.org <mailto:hot@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@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
