[HOT] Damage evaluation tagging schema
Markware Software Services
markwaresoftware at gmail.com
Fri Jan 23 04:17:03 UTC 2015
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> 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 make efficient 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>
> *À :* 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
> >
>
> --
> Twitter: http://twitter.com/ravilacoya
>
> --------------------------------
>
> Por favor, non me envíe documentos con extensións .doc, .docx, .xls,
> .xlsx, .ppt, .pptx, aínda podendoo facer, non os abro.
>
> Atendendo á lexislación vixente, empregue formatos estándares e abertos.
>
> http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros
>
>
>
>
> _______________________________________________
> HOT mailing list
> HOT at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot
>
>
>
> _______________________________________________
> 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/2b1c980f/attachment.html>
More information about the HOT
mailing list