<div dir="ltr">Hi Pierre<div><br></div><div>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.</div><div><br></div><div><div>Is it relevant that a building was subjected to damage from two events?</div></div><div><br></div><div>I guess the question is, how long should crisis related data persist and what data should persist.</div><div><br></div><div>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?</div><div><br></div><div>On possibility is to use the data for later assessment on the rehabilitation work that was done??<br></div><div><br></div><div>Just some idle thoughts</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><br></div><div>Regards</div><div><br></div><div>Mark Cupitt</div><div><br></div><div><div>"If we change the world, let it bear the mark of our intelligence"</div><div><br></div><div><a href="https://www.openstreetmap.org/user/Mark_Cupitt" target="_blank">See me on Open Street Map</a><br></div><div><a></a><div><br></div></div><div><a href="http://ph.linkedin.com/in/markcupitt" target="_blank">See me on LinkedIn</a><br><img src="http://s.c.lnkd.licdn.com/scds/common/u/img/webpromo/btn_myprofile_160x33.png"><br></div><span style="font-family:arial black,sans-serif"><div><span style="font-family:arial black,sans-serif"><br></span></div><b><a href="http://gis.stackexchange.com/users/17846/mark-c" target="_blank">See me on StackExchange</a><br></b></span><img src="http://gis.stackexchange.com/users/flair/17846.png"><br></div><div>===============================================================================================</div><div>The contents of this email are intended only for the individual(s) to whom it is addressed and may contain</div><div>confidential or privileged information.  If you are not the intended recipient, you must not disclose, copy, distribute,</div><div>or use the contents of this email.  If you have received this email in error, please notify the sender immediately and</div><div>delete the email and any attachments.<br></div><div>
===============================================================================================
</div></div></div></div>
<br><div class="gmail_quote">On Fri, Jan 23, 2015 at 12:17 PM, Markware Software Services <span dir="ltr"><<a href="mailto:markwaresoftware@gmail.com" target="_blank">markwaresoftware@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Pierre<div><br></div><div>Postgres Pattern Matching IS basically the same as Regex</div><div><br></div><div><a href="http://www.postgresql.org/docs/9.0/static/functions-matching.html" target="_blank">http://www.postgresql.org/docs/9.0/static/functions-matching.html</a> <br></div><div><br></div><div>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.</div><div><br></div><div>Some kind of Lucerne Indexing may offer an option, but I have never worked with that on Postgres.</div><div><br></div><div>Cheers</div><div><br></div><div>Mark</div></div><div class="gmail_extra"><span class=""><br clear="all"><div><div><div dir="ltr"><div><br></div><div>Regards</div><div><br></div><div>Mark Cupitt</div><div><br></div><div><div>"If we change the world, let it bear the mark of our intelligence"</div><div><br></div><div><a href="https://www.openstreetmap.org/user/Mark_Cupitt" target="_blank">See me on Open Street Map</a><br></div><div><a></a><div><br></div></div><div><a href="http://ph.linkedin.com/in/markcupitt" target="_blank">See me on LinkedIn</a><br><img src="http://s.c.lnkd.licdn.com/scds/common/u/img/webpromo/btn_myprofile_160x33.png"><br></div><span style="font-family:arial black,sans-serif"><div><span style="font-family:arial black,sans-serif"><br></span></div><b><a href="http://gis.stackexchange.com/users/17846/mark-c" target="_blank">See me on StackExchange</a><br></b></span><img src="http://gis.stackexchange.com/users/flair/17846.png"><br></div><div>===============================================================================================</div><div>The contents of this email are intended only for the individual(s) to whom it is addressed and may contain</div><div>confidential or privileged information.  If you are not the intended recipient, you must not disclose, copy, distribute,</div><div>or use the contents of this email.  If you have received this email in error, please notify the sender immediately and</div><div>delete the email and any attachments.<br></div><div>
===============================================================================================
</div></div></div></div>
<br></span><div><div class="h5"><div class="gmail_quote">On Fri, Jan 23, 2015 at 11:56 AM, Pierre Béland <span dir="ltr"><<a href="mailto:pierzenh@yahoo.fr" target="_blank">pierzenh@yahoo.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:13px"><div><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:13px"><div>Hi Rafael,</div><div><br clear="none"></div><div dir="ltr">There can be more then one step of evaluation and this both for evaluations based on imagery or field survey. <br clear="none"></div><div dir="ltr"><br clear="none"></div><div dir="ltr">For Haiyan we did</div><div dir="ltr">1. Aerial imagery evaluation</div><div dir="ltr">2. Aerial imagery revision (later revising objects already evaluated)</div><div dir="ltr">3. Red Cross did some Field survey evaluations.<br clear="none"></div><div><br clear="none"></div><div dir="ltr"><span>About the order of elements, I thought that this order would faciliate queries. <br clear="none"></span></div><div dir="ltr"><span>For example</span></div><div dir="ltr"><span>select key=</span>damage:evaluation:</div><div dir="ltr"><span>select key=</span>damage:evaluation:barrier:</div><div dir="ltr"><span><br clear="none"></span></div><div dir="ltr"><div><span>Overpass Regex query can be used except I think adding a negation. <br></span></div><div dir="ltr"><span>see <a href="http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Key.2Fvalue_matches_regular_expression_.28.7E.22key_regex.22.7E.22value_regex.22.29" target="_blank">http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Key.2Fvalue_matches_regular_expression_.28.7E.22key_regex.22.7E.22value_regex.22.29</a><br></span></div><div><span><br></span></div><div><span>Would it be efficient to make</span><span> efficient Regex queries with postgresql? Then,  </span><span>I think that the order of the elements would be less a problem.</span> </div></div><div><div dir="ltr"><br clear="none"></div><div dir="ltr"> </div></div><div><span style="font-style:italic;color:rgb(0,0,191);font-weight:bold">Pierre <br clear="none"></span></div><br clear="none">  <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:13px"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div dir="ltr"> <hr size="1">  <font face="Arial"> <b><span style="font-weight:bold">De :</span></b> Rafael Avila Coya <<a href="mailto:ravilacoya@gmail.com" target="_blank">ravilacoya@gmail.com</a>><br clear="none"> <b><span style="font-weight:bold">À :</span></b> <a href="mailto:hot@openstreetmap.org" target="_blank">hot@openstreetmap.org</a> <br clear="none"> <b><span style="font-weight:bold">Envoyé le :</span></b> Jeudi 22 janvier 2015 21h24<span><br clear="none"> <b><span style="font-weight:bold">Objet :</span></b> Re: [HOT] Damage evaluation tagging schema<br clear="none"> </span></font> </div> <div><br><br></div><div><div><div><div><br clear="none">Hi Pierre:<br clear="none"><br clear="none">I like this schema. Only two questions:<br clear="none"><br clear="none">What do you mean with evaluation and revision?<br clear="none">Why not the event in 3rd and type of object at the end?<br clear="none"><br clear="none">Cheers,<br clear="none"><br clear="none">Rafael.<br clear="none"><br clear="none">On 23/01/15 02:33, Pierre Béland wrote:<br clear="none">> From the discusssion about mapping North of Nigeria, I open a distinct<br clear="none">> thread about the Damage evaluation discussion about the more technical<br clear="none">> aspects related to Damage evaluation and tagging schema.<br clear="none">> <br clear="none">> This wiki page describes the schema used for the Haiyan typhoon.<br clear="none">> <a rel="nofollow" shape="rect" href="http://wiki.openstreetmap.org/wiki/Damaged_buildings_crisis_mapping" target="_blank">http://wiki.openstreetmap.org/wiki/Damaged_buildings_crisis_mapping</a><br clear="none">> <br clear="none">> As we discussed at the beginning of the Haiyan activation, while<br clear="none">> establishing a temporary schema, this was be revised later to not affect<br clear="none">> tags such as building or highway.  Distinct tags should be added to<br clear="none">> reflect damages, road obstacles, debris or any other damage related<br clear="none">> objects. Any modifications will also have to be reflected in the<br clear="none">> humanitarian style to have the capacity to show damages on the map as we<br clear="none">> did for Haiyan.<br clear="none">> <br clear="none">> While the BaseMap is our priority, there might be some emergencies where<br clear="none">> we are asked to collaborate to Damage evaluation. For each of these<br clear="none">> events, we have to discuss among us and carefully evaluate if it is<br clear="none">> pertinent to do so.<br clear="none">> <br clear="none">> Methodology is an other aspect. As it was discussed after Haiyan, there<br clear="none">> are limits to what can be done with Imagery. We cannot have the same<br clear="none">> classification / hierarchy of damages from an aerial evaluation (often<br clear="none">> poor quality images in the context of climate related disasters) and<br clear="none">> field evaluation.<br clear="none">> <br clear="none">> While we might decide to not do these evaluations, it is important to<br clear="none">> establish a good tagging schema and be ready for our next such action.<br clear="none">> <br clear="none">> It dont think that this is a solution to have two attributes on the same<br clear="none">> key like *building="commercial; damaged"*. It would be more difficult to<br clear="none">> query and this would breaks the rules for the map renderer styles. <br clear="none">> <br clear="none">> There are also discussions about adding permanently tags to the database<br clear="none">> and later not revising it.  More then a year after Haiyan, there are<br clear="none">> still a lot of damage related tags.  I have started to analyze how to<br clear="none">> revise this. But not yet processed.<br clear="none">> <br clear="none">> There are various aspects to consider.<br clear="none">> - Use a map style to render damages (like the Humanitarian style for Haiyan)<br clear="none">> - Distinct methodology for aerial views or survey evaluations  -> <br clear="none">> Specific role + limits of aerial views vs structure damages<br clear="none">> - Evaluation vs Revision (either imagery or field survey)<br clear="none">> <br clear="none">> The objects to evaluate can vary from one disaster to the other.  From<br clear="none">> the Haiyan experience, below I present proposals for tagging schema<br clear="none">> specific to an event. In this example, in the context of the Haiyan<br clear="none">> typhoon damages. Tnis same logic could be extended to  objects affected<br clear="none">> by other type of disasters. <br clear="none">> <br clear="none">> There are also various evaluation actions and status of actions  that<br clear="none">> sometimes need to be registered.<br clear="none">> - Type of action: aerial evaluation and revision, field evaluation and<br clear="none">> revision<br clear="none">> - Status of the revision : cloud coverage limited the evaluation.<br clear="none">> <br clear="none">> The OSM key could be structured with various levels separated by<br clear="none">> semi-colons (ie damage:evaluation:building:haiyan).<br clear="none">> <br clear="none">> If both evaluation and revision key where present, the style renderer<br clear="none">> rules could give a priority of revision over evaluation tags.<br clear="none">> <br clear="none">>     damage:evaluation:building:haiyan=no_damage<br clear="none">>     would supersedeeffect of<br clear="none">>     damage:revision:building:haiyan=collapsed<br clear="none">> <br clear="none">> <br clear="none">> Level<br clear="none">> ===========================<br clear="none">> 1 damage<br clear="none">> 2. evaluation, revision<br clear="none">> 3. type, building, barrier, debris<br clear="none">> 4. event (ie. haiyan)<br clear="none">> <br clear="none">> <br clear="none">> key                                                         value<br clear="none">> --------------------------------------------------------------------------------<br clear="none">> damage:evaluation:type:haiyan         imagery, survey<br clear="none">> damage:revision:type:haiyan             imagery, survey<br clear="none">> <br clear="none">> damage:evaluation:building:haiyan   damaged, collapsed, no<br clear="none">> damage:revision:building:haiyan       damage, collapsed, no<br clear="none">>  <br clear="none">> <br clear="none">> Highway Barrier on nodes<br clear="none">> <br clear="none">> damage:evaluation:barrier:haiyan     debris, no<br clear="none">> damage:revision:barrier:haiyan         debris, no<br clear="none">> <br clear="none">> Impassable highway sections<br clear="none">> <br clear="none">> damage:evaluation:status:haiyan      impassable, passable<br clear="none">> <br clear="none">> Area Debris<br clear="none">> <br clear="none">> damage:evaluation:landuse:haiyan    brownfield, no<br clear="none">> damage:revision:landuse:haiyan        brownfield, no<br clear="none">> <br clear="none">> <br clear="none">> <br clear="none">> <br clear="none">> Example<br clear="none">> <br clear="none">>     <tag k='building' v='yes' /><br clear="none">>     <tag k='damage:evaluation:type:haiyan' v='imagery' /><br clear="none">>     <tag k='damage:evaluation:building:haiyan' v='damaged' /><br clear="none">>     <tag k='damage:revision:type:haiyan' v='imagery' /><br clear="none">>     <tag k='damage:revision:building:haiyan' v='collapsed' /><br clear="none">>     <tag k='damage:revision:type:haiyan' v='survey' /><br clear="none">>     <tag k='damage:revision:building:haiyan' v='collapsed' /><br clear="none">> <br clear="none">>     <tag k='highway' v='trunk' /><br clear="none">>     <tag k='damage:evaluation:haiyan' v='yes' /><br clear="none">>     <tag k='damage:revision:haiyan' v='yes' /><br clear="none">>     <tag k='damage:evaluation:barrier:haiyan' v='debris' /><br clear="none">>     <tag k='damage:evaluation:type' v='imagery' /><br clear="none">>     <tag k='damage:revision:debris:haiyan' v='no' /><br clear="none">>     <tag k='damage:revision:type' v='survey' /><br clear="none">>     <tag k=damage:haiyan' v='yes' /><br clear="none">> <br clear="none">> <br clear="none">> Pierre<br clear="none">> <br clear="none">> <br clear="none">> _______________________________________________<br clear="none">> HOT mailing list<br clear="none">> <a rel="nofollow" shape="rect" href="mailto:HOT@openstreetmap.org" target="_blank">HOT@openstreetmap.org</a><br clear="none">> <a rel="nofollow" shape="rect" href="https://lists.openstreetmap.org/listinfo/hot" target="_blank">https://lists.openstreetmap.org/listinfo/hot</a><br clear="none">> <br clear="none"><br clear="none">-- <br clear="none">Twitter: <a rel="nofollow" shape="rect" href="http://twitter.com/ravilacoya" target="_blank">http://twitter.com/ravilacoya</a><br clear="none"><br clear="none">--------------------------------<br clear="none"><br clear="none">Por favor, non me envíe documentos con extensións .doc, .docx, .xls,<br clear="none">.xlsx, .ppt, .pptx, aínda podendoo facer,  non os abro.<br clear="none"><br clear="none">Atendendo á lexislación vixente, empregue formatos estándares e abertos.<br clear="none"><br clear="none"><a rel="nofollow" shape="rect" href="http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros" target="_blank">http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros</a><div><br clear="none"><br clear="none"></div><div><br clear="none"><br clear="none">_______________________________________________<br clear="none">HOT mailing list<br clear="none"><a rel="nofollow" shape="rect" href="mailto:HOT@openstreetmap.org" target="_blank">HOT@openstreetmap.org</a><br clear="none"><a rel="nofollow" shape="rect" href="https://lists.openstreetmap.org/listinfo/hot" target="_blank">https://lists.openstreetmap.org/listinfo/hot</a><br clear="none"></div><br clear="none"><br clear="none"></div></div> </div></div></div> </div>  </div></div></div></div></div><br>_______________________________________________<br>
HOT mailing list<br>
<a href="mailto:HOT@openstreetmap.org" target="_blank">HOT@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/hot" target="_blank">https://lists.openstreetmap.org/listinfo/hot</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div><br></div>