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 <[email protected]> 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 > > <[email protected] <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]>> > > *À :* [email protected] <mailto:[email protected]> > > *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 > [email protected] > https://lists.openstreetmap.org/listinfo/hot >
_______________________________________________ HOT mailing list [email protected] https://lists.openstreetmap.org/listinfo/hot
