subject:"\[HOT\] Damage evaluation tagging schema"

Re: [HOT] Damage evaluation tagging schema

2015-03-19 Thread Jean-Guilhem Cailton

, 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

Re: [HOT] Damage evaluation tagging schema

2015-01-25 Thread Mark Cupitt

Hi Althio

Thanks, good info

These would have to be dealt with in HStore in Postgres, it would blow the
column count out dramatically in Postgres, with an infinite number of
tag/key combinations (everything left of the first '=' would get its own
column or is considered a Tag in Hstore.

The beauty is that Hstore is a great way to do it anyway, as it is a lot
more flexible, provided you do not want to search on specific data in
there, but simply us it to add attributes to the map.

Pierre, well worth looking at.


Regards

Mark Cupitt

If we change the world, let it bear the mark of our intelligence

See me on Open StreetMap https://www.openstreetmap.org/user/Mark_Cupitt


On Sun, Jan 25, 2015 at 2:48 PM, althio althio.fo...@gmail.com wrote:

 Hi Pierre, Mark and all

 FYI some related schemes -- currently used or proposed in OSM -- are
 gathered at this page:

 http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts

 In particular this section

 http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts#.3Cstatus.3E:.3Ckey.3E_.3D_.3Cvalue.3E

 At a basic level it would look like:
 damaged:building=hospital
 (damaged is not yet used or documented)

 I understand that you need more refinement for details:
 * source: imagery/survey
 * date
 * event name or reference

 So maybe you could consider this scheme as a starting point.
 Then you could add more field/key/tag so that it is adapted to your
 needs for completeness and data extraction.


 On Jan 23, 2015 5:04 AM, Markware Software Services
 markwaresoftw...@gmail.com wrote:

  Osm does have these tags already defined, I am sure you are aware
  ...
  abandoned=* - for a building

 and other related tags: disused/demolished/removed...

 But see http://wiki.openstreetmap.org/wiki/Key:abandoned
 in particular the section: Former use (as a simple tag)
 with
 Older scheme (deprecated)
 Intermediate scheme (discouraged)
 Current scheme (recommended)

 From the wiki: Using a simple key is now strongly discouraged. It is
 recommended to use the namespaced form instead.
 This leads to the scheme in

 http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts#.3Cstatus.3E:.3Ckey.3E_.3D_.3Cvalue.3E


 althio

 ___
 HOT mailing list
 HOT@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/hot

___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] Damage evaluation tagging schema

2015-01-24 Thread althio

Hi Pierre, Mark and all

FYI some related schemes -- currently used or proposed in OSM -- are
gathered at this page:

http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts

In particular this section
http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts#.3Cstatus.3E:.3Ckey.3E_.3D_.3Cvalue.3E

At a basic level it would look like:
damaged:building=hospital
(damaged is not yet used or documented)

I understand that you need more refinement for details:
* source: imagery/survey
* date
* event name or reference

So maybe you could consider this scheme as a starting point.
Then you could add more field/key/tag so that it is adapted to your
needs for completeness and data extraction.


On Jan 23, 2015 5:04 AM, Markware Software Services
markwaresoftw...@gmail.com wrote:

 Osm does have these tags already defined, I am sure you are aware
 ...
 abandoned=* - for a building

and other related tags: disused/demolished/removed...

But see http://wiki.openstreetmap.org/wiki/Key:abandoned
in particular the section: Former use (as a simple tag)
with
Older scheme (deprecated)
Intermediate scheme (discouraged)
Current scheme (recommended)

From the wiki: Using a simple key is now strongly discouraged. It is
recommended to use the namespaced form instead.
This leads to the scheme in
http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts#.3Cstatus.3E:.3Ckey.3E_.3D_.3Cvalue.3E


althio

___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] Damage evaluation tagging schema

2015-01-22 Thread Markware Software Services

Hi Pierre

Excellent Thoughts. Interestingly, I am working on a 3D rendering of
buildings project now, and was planning on extending this to HOT's work
when done with the commercial project.

Having everything in one tag k= as you propose helps the query and
rendering scenario a lot. The only downside from a database perspective
would be if you ever needed to query for data within the key data itself.
This would be very slow.

For Example:  if someone wanted to display all Haiyan related data the
query would be something like *WHERE k is Not Null and lower(k) LIKE
haiyan%* which would trigger a sequential Pattern Match Scan. *k* would
need to be indexed, which would help somewhat.

One option would be to consider a couple of specific tags to help any
searches on columns that can be indexed, like

*hot:damage*=type of damage string (as per your proposal)
*hot:crisis*=Haiyan

This would allow rapid extraction of all Haiyan related data using indexes
with a query like *WHERE hot:damage is not null and
lower(hot:crisis)=haiyan;*

Also, consider adding hot: to the tag as this makes it very clear where
the data source is.

Just some thoughts for you to consider


Also, Do you have a summary of what tagging schemes were actually used
during Haiyan, I seem to recall building=damaged, or building=yes, damage=*



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 9:33 AM, Pierre Béland pierz...@yahoo.fr 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

Re: [HOT] Damage evaluation tagging schema

2015-01-22 Thread Rafael Avila Coya

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:haiyanbrownfield, no
 damage:revision:landuse:haiyanbrownfield, 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

Re: [HOT] Damage evaluation tagging schema

2015-01-22 Thread Pierre Béland

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 did1. Aerial imagery evaluation2. 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 exampleselect 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 ravilac...@gmail.com
À : 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

Re: [HOT] Damage evaluation tagging schema

2015-01-22 Thread Markware Software Services

Hi Pierre, you should be asleep by now :) Hope the Snow is not too deep
either :)

I did not know about that the HOT Private Store. Is that rendered on the
OSm Layer or otherwise available? Would be interested in knowing a little
bit more about that.

Selecting objects in Sql is very dependent on the indexing. using + or 
with an index is very efficient. Using Like haiyan% can be reasonably
fast if the data in the tag starts with the term you are searching for (eg:
haiyan) (case conversion will have an impact depending on the size of the
string).

If your search term is in the middle of the key data, eg; damaged: haiyan:
debris it will be VERY slow as that will trigger a sequential scan

I have my own planetosm database, if the crisis is not a seperate tag, ie,
embedded within one tags data, I would set a trigger on the update that
extracted the crisis name, eg: haiyan, and stored it in an indexable
column. This is not particularly efficient, but I would have no choice as I
think it is very important to be able to extract data specific to a Crisis.

If you think about Overpass Queries, they would also not handle the data
embedded in the tag particularly well, I am sure they could do it, but it
would be subject to the same issue above.

One possible solution would be to use the Postgres HStore, which is
basically a text field. Postgres does have a unique ability to index data
withing the hstore, but I would not use this method on my production
database.

Osm does have these tags already defined, I am sure you are aware


   - building:condition
   http://wiki.openstreetmap.org/wiki/Key:building:condition=* *for the
   condition of the building*
   - ruins http://wiki.openstreetmap.org/wiki/Key:ruins=* - *for ruins of
   buildings*
   - abandoned http://wiki.openstreetmap.org/wiki/Key:abandoned=* - *for
   a building *


My thought would to NOT use these, as the fact that a building was tagged
as abandoned is relevant in assessing if you want to assess it in a
Humanitarian Crisis.






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:41 AM, Pierre Béland pierz...@yahoo.fr wrote:

 Mark

 About the prefix hot:, this is reserved for the HOT private store. Adding
 this prefix to objects in JOSM, the objects are saved in the HOT private
 store.

 Pierre

   --
  *De :* Pierre Béland pierz...@yahoo.fr
 *À :* Markware Software Services markwaresoftw...@gmail.com
 *Cc :* HOT Openstreetmap hot@openstreetmap.org; S Volk 
 svo...@hotmail.com
 *Envoyé le :* Jeudi 22 janvier 2015 22h30
 *Objet :* Re: [HOT] Damage evaluation tagging schema

 Hi Mark

 I agree, we have to consider also aspects like how easy to extract for an
 event. For Haiyan, we had a specific tag. But what, if it would have be
 necessary to add tags recently for Hagupit?

 About SQL queries, are-they any efficient way (time related) to say
 select objects where key contains haiyan ?

 Pierre


___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] Damage evaluation tagging schema

2015-01-22 Thread Markware Software Services

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 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 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 ravilac...@gmail.com
*À :* 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

Re: [HOT] Damage evaluation tagging schema

2015-01-22 Thread Pierre Béland

Hi Mark
I agree, we have to consider also aspects like how easy to extract for an 
event. For Haiyan, we had a specific tag. But what, if it would have be 
necessary to add tags recently for Hagupit?
About SQL queries, are-they any efficient way (time related) to sayselect 
objects where key contains haiyan ?
 Pierre 

  De : Markware Software Services markwaresoftw...@gmail.com
 À : Pierre Béland pierz...@yahoo.fr 
Cc : HOT Openstreetmap hot@openstreetmap.org; S Volk svo...@hotmail.com 
 Envoyé le : Jeudi 22 janvier 2015 21h21
 Objet : Re: [HOT] Damage evaluation tagging schema
   
Hi Pierre
Excellent Thoughts. Interestingly, I am working on a 3D rendering of buildings 
project now, and was planning on extending this to HOT's work when done with 
the commercial project.
Having everything in one tag k= as you propose helps the query and rendering 
scenario a lot. The only downside from a database perspective would be if you 
ever needed to query for data within the key data itself. This would be very 
slow. 

For Example:  if someone wanted to display all Haiyan related data the query 
would be something like WHERE k is Not Null and lower(k) LIKE haiyan% which 
would trigger a sequential Pattern Match Scan. k would need to be indexed, 
which would help somewhat.
One option would be to consider a couple of specific tags to help any searches 
on columns that can be indexed, like 
hot:damage=type of damage string (as per your proposal)hot:crisis=Haiyan
This would allow rapid extraction of all Haiyan related data using indexes with 
a query like WHERE hot:damage is not null and lower(hot:crisis)=haiyan;

Also, consider adding hot: to the tag as this makes it very clear where the 
data source is.
Just some thoughts for you to consider

Also, Do you have a summary of what tagging schemes were actually used during 
Haiyan, I seem to recall building=damaged, or building=yes, damage=*


Regards
Mark Cupitt
If we change the world, let it bear the mark of our intelligence
See me on Open Street Map

See me on LinkedIn


See me on StackExchange

===The
 contents of this email are intended only for the individual(s) to whom it is 
addressed and may containconfidential 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 anddelete the email and any attachments.
===
On Fri, Jan 23, 2015 at 9:33 AM, Pierre Béland pierz...@yahoo.fr 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

Re: [HOT] Damage evaluation tagging schema

2015-01-22 Thread Pierre Béland

Mark
About the prefix hot:, this is reserved for the HOT private store. Adding this 
prefix to objects in JOSM, the objects are saved in the HOT private store. 
Pierre 

  De : Pierre Béland pierz...@yahoo.fr
 À : Markware Software Services markwaresoftw...@gmail.com 
Cc : HOT Openstreetmap hot@openstreetmap.org; S Volk svo...@hotmail.com 
 Envoyé le : Jeudi 22 janvier 2015 22h30
 Objet : Re: [HOT] Damage evaluation tagging schema
   
Hi Mark
I agree, we have to consider also aspects like how easy to extract for an 
event. For Haiyan, we had a specific tag. But what, if it would have be 
necessary to add tags recently for Hagupit?
About SQL queries, are-they any efficient way (time related) to sayselect 
objects where key contains haiyan ?
 Pierre

  ___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot