Re: [Tagging] Emergency shelters

[Blake Girardot]

On Fri, Sep 8, 2017 at 10:33 PM, Nick Hocking <nick.hock...@gmail.com> wrote:
> Eric wrote
>
> "  This is an open database and we all "garden" the data to make sure that
> the
> information is correct."
>
> I think that information critical to safety needs a higher level of
> verification than just peer review.
> So the argument comes down to what is critical information.
>
> I normal times, road geometry on maps should not be critical to drivers
> because we expect them to use eyes/brain ahead of navigation prompts.(and
> yes I know this doesn't always happen)
>
> In times of emergency, certain information just must be correct and can not
> be allowed to be tampered with.
>

As someone who works in times of emergency, I can tell you OSM is the
goto dataset for many formal and informal response groups around the
world.

It is consistently a good dataset, sometimes where no other datasets
can be located and is used very often.

The quality is a known average good and the #opendata nature is always
a plus. The crowd based nature makes it one of the best databases of
local amenities, schools, medical in many parts of the world.

OSM is used at every level of the disaster management cycle from the
UN and EC/EU organs to local groups with a van load of food.

OSM data gets automatically pushed to #HDX the main UN OCHA data
distribution point, it is that important and in demand.

Everyone on this list is making that dataset as good as it is. thank you.

Respectfully,
blake











openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>



-- 

Blake Girardot
OSM Wiki - https://wiki.openstreetmap.org/wiki/User:Bgirardot
HOTOSM Member - https://hotosm.org/users/blake_girardot
skype: jblakegirardot
Live OSM Mapper-Support channel - https://hotosm-slack.herokuapp.com/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Emergency shelters

[Blake Girardot]

Authorities routinely post the hurricane evacuation centers for a year
as they do change a little bit year to year.

but the core typically remains the same, schools etc.

These just need a good lifecycle tag.

Like "good until' date, after which it can be easily found and removed.

I proposed some lifecycle tags for damage tagging and helicopter
landing zones (different than helipads) that would apply here

I will try and find them, but they were based on a known good until
date, after which they should be updated and a new known good until
date added, or should be removed or not relied upon.

cheers
blake

On Thu, Sep 7, 2017 at 11:12 PM, Nick Hocking <nick.hock...@gmail.com> wrote:
> Eric wrote   "Why would you delete data that is still valid and useful?"
>
>
> My concern is that if these are permanent features, then people will say
> "ooh - they'll be the same as last time" and of course they probably won't
> be the same as last time and we may route people to a wrong place, with
> possible tragic results.
>
> I agree that this information should be left in place, but marked ,
> unusable, until specifically activated by authorities, which I agree should
> be well ahead of time, so long as people know that they will not be usable
> until a state of emergency is declared.
>
> Activation should be on a center by centre basis so that authorities will be
> more likely to ensure the list of centers is accurate and up-to-date.
>
> I also think that this information should NOT be edited, in any way by
> anyone other than the authorities. This brings back the old arguments about
> read only data in OSM.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>



-- 

Blake Girardot
OSM Wiki - https://wiki.openstreetmap.org/wiki/User:Bgirardot
HOTOSM Member - https://hotosm.org/users/blake_girardot
skype: jblakegirardot
Live OSM Mapper-Support channel - https://hotosm-slack.herokuapp.com/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Coworking space: amenity vs. office ?

[Blake Girardot]

On Thu, Jan 5, 2017 at 2:03 PM, Martin Koppenhoefer
<dieterdre...@gmail.com> wrote:
>
> 2017-01-05 13:13 GMT+01:00 Blake Girardot <bgirar...@gmail.com>:
>>
>> Wait, what?
>>
>> The point of coworking spaces is that it is people from different
>> companies or independent contractors, consultants, etc are using a
>> shared space and resources.
>
>
>
> that's what I said, with other working places I was referring to places that
> are not _offices_
>

Ah, sorry, somehow I thought we had gotten this reversed.

Anyway, my vote is:

amenity=coworking_space

To my view, they are amenities for a city/community/neighborhood and
much more so an amenity than what we traditionally think of as an
office, although there is for sure a case for office=*.

But I have seen no discussion of why amenity=coworking_space, which is
what is in use now, is a problem worth introducing a significant
change to the existing system. The current tag seems to be working
fine. Is there a problem with it that suggests we should change?

cheers
blake

-- 

Blake Girardot
OSM Wiki - https://wiki.openstreetmap.org/wiki/User:Bgirardot
HOTOSM Member - https://hotosm.org/users/blake_girardot
skype: jblakegirardot
Live OSM Mapper-Support channel - https://hotosm-slack.herokuapp.com/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Coworking space: amenity vs. office ?

[Blake Girardot]

On Thu, Jan 5, 2017 at 11:59 AM, Tom Pfeifer <t.pfei...@computer.org> wrote:
> On 05.01.2017 10:31, Martin Koppenhoefer wrote:
>
>>> On 5 Jan 2017, at 04:58, Eugene Alvin Villar <sea...@gmail.com> wrote:
>>>
>>> Coworking spaces are targeted towards white-collar office desk jobs
>>
>>
>>
>> +1, this is also what comes to my mind when I hear coworking. I propose to
>> use office=coworking for those that are offices, and if you come along a
>> different kind of place where people are working together without being in
>> the same company you'll have to invent a new tag for these particular
>> different kind of places, e.g. there's already something for collective
>> bicycle repair (where coworking isn't a typical term to refer to).
>
>
> However, using office=coworking blocks this key for a description what is
> being done in these offices. So it mixes values of describing the trade with
> how the work is organised.
>
> thus we could have:
>
> * office=graphics_design + coworking=yes
>   or even keep the amenity tag for the facility:
> * office=software_development + amenity=coworking(_space)
>

Just to again add my understanding here: Coworking spaces are usually
not activity specific, that is the point, they are a mix of folks
doing whatever it is they do, programming, design, etc.

office=graphics_design + coworking=yes does not make sense in the
context of actual co-working spaces. that is much closer to describing
how some graphic design firm is doing its office layout.

Yes, there might be some edge cases where a co-working space is
designed specifically for a particular trade like woodworking or metal
work, but as mentioned those are usually maker spaces. But any
coworking space that supports office work would usually support any
type of office work and would not say "only accountants can cowork
here"

cheers
blake


-- 

Blake Girardot
OSM Wiki - https://wiki.openstreetmap.org/wiki/User:Bgirardot
HOTOSM Member - https://hotosm.org/users/blake_girardot
skype: jblakegirardot
Live OSM Mapper-Support channel - https://hotosm-slack.herokuapp.com/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Coworking space: amenity vs. office ?

[Blake Girardot]

On Thu, Jan 5, 2017 at 10:31 AM, Martin Koppenhoefer
<dieterdre...@gmail.com> wrote:
>> On 5 Jan 2017, at 04:58, Eugene Alvin Villar <sea...@gmail.com> wrote:
>>
>> Coworking spaces are targeted towards white-collar office desk jobs
>
>
> +1, this is also what comes to my mind when I hear coworking. I propose to 
> use office=coworking for those that are offices, and if you come along a 
> different kind of place where people are working together without being in 
> the same company you'll have to invent a new tag for these particular 
> different kind of places, e.g. there's already something for collective 
> bicycle repair (where coworking isn't a typical term to refer to).
>

Wait, what?

The point of coworking spaces is that it is people from different
companies or independent contractors, consultants, etc are using a
shared space and resources.

If everyone is coworking in a shared space for the same company that
is just a regular office.


-- 
----
Blake Girardot
OSM Wiki - https://wiki.openstreetmap.org/wiki/User:Bgirardot
HOTOSM Member - https://hotosm.org/users/blake_girardot
skype: jblakegirardot
Live OSM Mapper-Support channel - https://hotosm-slack.herokuapp.com/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How might we best map emergency helicopter landing zones?

[Blake Girardot]

On Tue, Nov 22, 2016 at 9:30 AM, Greg Troxel <g...@lexort.com> wrote:
>
>>> On Nov 22, 2016 8:41 PM, "Blake Girardot" <bgirar...@gmail.com> wrote:
>>>
>>> I have worked with folks doing ground surveys of helicopter landing
>>> zones during emergency response.
>>>
>>> These are ground truthed locations, observed by active search and
>>> rescue helicopter pilots collecting the basic minimum critical ground
>>> survey items for an HLZ for their aircraft type.
>>>
>>> They collect the data and provide it in the public domain and I would
>>> like to map it.
>>>
>>> I think the vast majority of the items collected are already well
>>> supported in OSM, trees, light poles, ground type, area, grade,
>>> landuse.
>>>
>>> What would be the best way to map this data? Does it need its own
>>> namespace? Just map  regular OSM tagging and render the data myself
>>> custom?
>
> For things that exist and are describable independent of caring about
> helicopters, definitely you should use regular tags.  If there is some
> feature of interest that doesn't have established tagging, you'll have
> to invent it.  But choose tags so that anyone who cares about the thing
> in question can be happy with, rather than only people looking at the
> thing from the helicopter viewpoint.  (Easier said than done, I know.)
>

This is very insightful, and excellent rule of thumb to keep in mind
about keeping the right perspective, the osm mappers perspective.

>>> I think issues of does the data belong in OSM are separate issues, I
>>> am just interested in how to map it and tag it well. I would be
>>> mapping nothing but ground truthed data that we already map every day,
>>> trees and light poles and ground type, landuse. It is publicly
>>> available data (CC0).
>
> Sure, that's fine, but beware that you are perhaps verging on an import.

For sure not an import in my mind (6 points at the moment,hand mapped
from a ground survey form which includes a picture of the HLZ from
directly overhead), but happy to take the consensus here if I should
treat it as an import and hopefully with the tagging figured out, any
"near import" would be generally accepted through that full process.

Thank you very much for helping get this sorted out.


>
>>> Other data could and should be added specific to HLZ's so we will need
>>> to discuss any non traditional tags that I would like to see be used
>>> for the HLZs mapped.
>
> Yes.  Here, I think it's mostly "this is a landing zone".
> Tom Pfeifer <t.pfei...@computer.org> writes:
>
>> aeroway=helipad should be used only for built-up infrastructure, not
>> for emergency places that have a different use normally.
>
> It sounds like in the Korean mountain case that in my cases there are
> on-ground markings at these sites.  That might be an intermediate case,
> not a formal helipad but a pre-prepared and marked LZ.  I have also seen
> these in the US, but not that often.  One case was in a big paved area
> at the end of a road used to access a frequently-used steep trail.  It
> was pretty obvious they were expecting trouble.
>
>> An emergency landing place is nothing but a predefined clear space, it
>> could be a soccer pitch or a big lawn in a park in normal situations.
>
> Yes.  My town probably has a half dozen of these.  They are used for
> medical evacuation helicopters (for people extricated from bad car
> crashes who are iffy on making it, basically).
>
>> There is already "emergency=landing_site" defined and used 1800 times
>> that seems to fit the purpose of Blake exactly?
>>
>> https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dlanding_site
>
> That seems to fit, although the image has an H on the ground.
>
> So perhaps we need
>
>   emergency=landing_site means not a formal helipad that may or may not
>   have some markings
>
>   landing_site=unmarked means there is no on-ground markings for the
>   pilot. (In these cases fire/police vehicles often make a circle to show
>   the safe area and light it, because it's often dark and the
>   trees/power lines cannot be seen.)
>
>   landing_site=marked means there is a stone box or ring or a painted
>   circle with an H, or something that is obviously intended to let the
>   pilot know the surveyed-safe area to land
>
> Since a helicopter can land anywhere big enough and unobstructed enough,
> more or less, I think there's merit in having a tag (or defining
> emergency=landing_si

Re: [Tagging] How might we best map emergency helicopter landing zones?

[Blake Girardot]

On Tue, Nov 22, 2016 at 8:33 AM, Tom Pfeifer <t.pfei...@computer.org> wrote:
> aeroway=helipad should be used only for built-up infrastructure, not for
> emergency places that have a different use normally.
>
> An emergency landing place is nothing but a predefined clear space, it could
> be a soccer pitch or a big lawn in a park in normal situations.

This is exactly right to my understanding and tagging. My
understanding and as I have mapped in the past a aeroway=helipad is
for a known built up permanent for the most part landing area. I
mapped a lot of these in Nepal.

> There is already "emergency=landing_site" defined and used 1800 times that
> seems to fit the purpose of Blake exactly?
>
> https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dlanding_site

This does sound like exactly the right tag for what we are planning on mapping.

> On 22.11.2016 14:02, Andrew Errington wrote:
>>
>> I tag them as aeroway=helipad, and it looks like this:
>> http://www.openstreetmap.org/#map=16/35.2932/127.5317
>>
>> There are a lot of them in the mountains of Korea.  Usually marked out
>> with a pattern of white stones embedded in the ground.
>>
>> Would like to know if there's a better way, or if doing it this way is
>> wrong.  Or right.
>>
>> Thanks,
>>
>> Andrew
>>
>>
>> On Nov 22, 2016 8:41 PM, "Blake Girardot" <bgirar...@gmail.com
>> <mailto:bgirar...@gmail.com>> wrote:
>>
>> Dear friends,
>>
>> I have worked with folks doing ground surveys of helicopter landing
>> zones during emergency response.
>>
>> These are ground truthed locations, observed by active search and
>> rescue helicopter pilots collecting the basic minimum critical ground
>> survey items for an HLZ for their aircraft type.
>>
>> They collect the data and provide it in the public domain and I would
>> like to map it.
>>
>> I think the vast majority of the items collected are already well
>> supported in OSM, trees, light poles, ground type, area, grade,
>> landuse.
>>
>> What would be the best way to map this data? Does it need its own
>> namespace? Just map  regular OSM tagging and render the data myself
>> custom?
>>
>> I think issues of does the data belong in OSM are separate issues, I
>> am just interested in how to map it and tag it well. I would be
>> mapping nothing but ground truthed data that we already map every day,
>> trees and light poles and ground type, landuse. It is publicly
>> available data (CC0).
>>
>> Other data could and should be added specific to HLZ's so we will need
>> to discuss any non traditional tags that I would like to see be used
>> for the HLZs mapped.
>>
>> Cheers,
>> Blake
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] How might we best map emergency helicopter landing zones?

[Blake Girardot]

Dear friends,

I have worked with folks doing ground surveys of helicopter landing
zones during emergency response.

These are ground truthed locations, observed by active search and
rescue helicopter pilots collecting the basic minimum critical ground
survey items for an HLZ for their aircraft type.

They collect the data and provide it in the public domain and I would
like to map it.

I think the vast majority of the items collected are already well
supported in OSM, trees, light poles, ground type, area, grade,
landuse.

What would be the best way to map this data? Does it need its own
namespace? Just map  regular OSM tagging and render the data myself
custom?

I think issues of does the data belong in OSM are separate issues, I
am just interested in how to map it and tag it well. I would be
mapping nothing but ground truthed data that we already map every day,
trees and light poles and ground type, landuse. It is publicly
available data (CC0).

Other data could and should be added specific to HLZ's so we will need
to discuss any non traditional tags that I would like to see be used
for the HLZs mapped.

Cheers,
Blake

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] building=yes for multiple building

[Blake Girardot]

I am reluctant to suggest that mapping large groups of buildings as one 
outline is a good idea. As I said, to me it is a last resort and should 
be avoided at all costs. Otherwise we are going to get blocks of easily 
mapped buildings outlined as building just because that is a lot easier 
and then leave the detailed mapping to someone else.


But that being said, since it is acceptable to map large blocks of 
buildings as building in some circumstances, I think we might need a new 
value to the building=* key.


Most data consumers that I work with usually consider building=yes to 
indicate one building.


If we know we are mapping multiple buildings under one polygon would it 
be a good idea to add something like a 'multiple' value to the key?


building=multiple

That would also make it easier to locate them for further refined 
mapping in the future.


cheers
blake



On 3/16/2016 4:48 PM, althio wrote:

Simon Poole wrote:

IMHO we always allow and support progression from rough to more detailed.


+1

Philip Barnes wrote:

Mike Thompson wrote:

My feeling is that individual buildings should be mapped.


In an ideal world I would agree, but we don't live in one and in some cases 
such as medieval building layout it can be incredibly difficult to work out 
what roofline belongs to which building.

I would say its ok, and better than not mapping buildings at all, then you can 
always improve it after more surveys.


+1


I agree it is good to have rough mapping and let it improve over time.

Back to OP question:
Once you trace a rough outline for multiple buildings, what is the tag?
building=yes? or another value?
with a note=*? a fixme=*?

- althio

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] building=yes for multiple building

[Blake Girardot]

Hi Joost,

The main wiki entry on building tagging says this about building tagging:

"In addition outlines can either be simplified shapes or very detailed 
outlines which conform accurately to the shape of the building. It is 
not uncommon for buildings to initially be described as simple group 
outlines later be improved with more detailed outlines and to be split 
into individual properties."


http://wiki.openstreetmap.org/wiki/Buildings

I think that fits in well with the idea that mapping and tagging can be 
refined as part of the overall mapping process.


Although, I always encourage people to outline the individual buildings 
if you can tell they are individual building units, even with a shared wall.


The downside of not strictly encouraging that style of mapping is large 
blocks of buildings being outlined with one building=yes tag which is 
much less useful for most use cases of building footprints.


So for me only in the most extreme circumstances will I use a single 
building outline for what I suspect might be multiple individual 
buildings, but I do it once in a while if there is just no way to 
reliably distinguish what might be individual buildings.


Cheers
blake



On 3/16/2016 3:47 PM, joost schouppe wrote:

Is it OK to map multiple buildings as one closed line with the
building=yes tag? Or does building=yes imply it is one single building?
There is the terrace value, but that implies one orderly structure, not
the hodgepodge of houses, buildings and extensions that define
organically grown blocks.

There are a couple of "multiple" values too, which make sense, but is
undocumented and maybe overly precise.

--
Joost @
Openstreetmap  |
Twitter  | LinkedIn
 | Meetup
 | Reddit
 | Wordpress



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Immigration, asylum, refugee centers

[Blake Girardot]

Thank you for all the help with this topic everyone.


On 9/24/2015 6:25 AM, Warin wrote:


Perhaps
office=government
government=immigration ?

or
government:immigration=yes
would be better where the office functions are combined..
government:passport=yes
government:vehicle_licence=yes
etc...

The office=government is under represented in the OSM data base ..
perhaps because there are no sub tags to further identify what it is
used for.



I like where these two suggestions are going. What are the next steps?

This is an important topic at the moment in Europe and people are 
mapping border and immigration related items in several countries.


Cheers
blake


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Immigration, asylum, refugee centers

[Blake Girardot]

Hi all,

I am looking through taginfo and the wiki, but I don't see a good clear 
tag for immigrant/asylum/refugee "reception" centers.


These are usually government type facilities that process immigrants and 
refugees.


Some are also holding facilities, and some are just government offices.

They are separate and distinct from standard passport control or border 
check points.


Any suggestions?


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] large roof garden

[Blake Girardot]

Hi Volker,

I generally tag them with:

roof:material=grass

or

roof:material=plants

http://wiki.openstreetmap.org/wiki/Key:roof:material

But in this case and maybe in other smaller cases it looks like we 
almost need a:


roof:use=*

Where the roof is used for something besides just covering.

Either way, I don't think the roof:material=* tags would be incorrect.

By the way it looks like the roof or the tunnel that goes under it could 
use some layer=* tags as well.


http://wiki.openstreetmap.org/wiki/Key:tunnel

It might even be more accurately tagged tunnel=building_passage

Cheers,
Blake

On 9/13/2015 2:16 PM, Volker Schmidt wrote:

How does one correctly map a roof garden (or better: roof park) like this:
https://www.openstreetmap.org/way/303934391

It's on top of a shopping centre/garages construction. There are even
appartment blocks "in" the roof top park. At present it's tagged as
building, nothing more.
You can clearly see the extension by observing the ventilation and/or
light openings on the satellite photos.
Incidentally there is another one just to the north of this one that is
not tagged at all.

Volker
(Italy)


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Damage Assessment Tags - Would like feedback on a schema

[Blake Girardot]

These replies are all very helpful, thank you very much.

On 5/22/2015 9:04 AM, Frederik Ramm wrote:


Whether the bridge was broken by a hurricane or an earthquake or in a
war, will often not be easy to discern on the ground. Therefore I view a
tag that details the event which broke the bridge, and when that event
happened, as problematic.


The intention of the damage:event=* or maybe disaster:event=*  tag 
doesn't have much to do with assigning causation, and has more to do 
with tag maintenance. We want to be able to run projects that get 
objects that were tagged with an event related tag to review, revise or 
remove them.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Damage Assessment Tags - Would like feedback on a schema

[Blake Girardot]

I don't know Andreas, do we need to say what kind of event it is?

I would lean toward damage:type=hurricane|earthquake|etc

or event:type=hurricane|earthquake|etc

But this actually brings up an issue that we ran into in Nepal.

How do identify the event (and maybe event type) independent of any of tags.

Because we want to map IDP camps, but we want to associate them to the 
specific event was well.


damage:event=* seems like it is for damage tags only.

unless you think of it as a damage event, meaning an event that does 
damage. so maybe the key name should be damage_event= in that case.


But that was not what we were thinking when we suggested damage:event, 
we were thinking it meant the event that was associated with the other 
damage tags.


We need to figure out how best to take different types of tags, damage 
tags, camp tags, potential landing zone tags and associate them with a 
disaster event so we can review, revise and remove them later.


Maybe disaster?

disaster=nepal_earthquake_2015
disaster:type=*
disaster:damage=*
etc ?

Regards,
Blake


On 5/21/2015 9:36 PM, Andreas Goss wrote:

As you linked to this on the HOT list a few things noticed...


What about the typhoon:, earthquake: or tsunami: tags? Replaced with
damage:event?

What about e.g. damage:building? This could still be used even if you
have building= and damage=

What about the status= and impassable= keys and tags?



Greetings everyone,

I am looking to help further develop a set of tags to reflect disaster
event damage to mapped objects in OSM. OSM has already used damage
tags in the past several times for example after Typhoon Haiyan:

http://wiki.openstreetmap.org/wiki/Damaged_buildings_crisis_mapping

And after the 2011 Sendai earthquake and tsunami

http://wiki.openstreetmap.org/wiki/2011_Sendai_earthquake_and_tsunami

And in Haiti

http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/Humanitarian_Data_Background#OpenStreetMap:_Tags_in_Current_Usage


I have read feedback about issues related to those tags and would like
to generate a set of tags that address that feedback. The main
feedback I saw was that the damage tags need to be separated from the
main object tags themselves (building=*, natural=*, highway=*, etc)
and they need to be easily removed after the damage is resolved or the
event is over.

Toward that end this is what myself and some other more experiences
mappers have come up with. We think it addresses those issues and
improves damage tagging in general. We would like community feedback
to help improve them before creating a wiki proposal page. Our over
arching goal of course is to create the most useful set of tags
possible. We are also going to reach out to some humanitarian
organizations to get feedback about their damage assessment data
models and hopefully use that to make improvements as well.

I know there are other people interested in this topic as well so if
anyone has complete alternative suggested schemas that would be great
too.

Any and all feedback and discussion is most welcome.

Tagging Schema
Criteria:
1. Separate feature/object from damage tag itself
2. Identify event the damage tag is related to for analysis and easily
removing them later
3. Allow for assessed and revised indication
4. Specify type/source of assessment
5. Easy to enter, remember, understand for mappers
6. Works well with overpass/overpass-turbo queries
7. Relatively easy for routing software to work with
8. Most similar to existing OSM tagging schemas
9. Allow for initial or revised damage assessment based on ground survey

For any area or node (buildings, amenities, landuse, natural, etc)
damage=[none | partial | major | destroyed]
damage:event=event_name[;event_name2;etc]
damage:assessment=[none | initial | revision]
damage:organization=organization_adding_damage_tags_name
source:damage=[satellite | aerial | survey]

For ways (highways)
These are the same as above, but we add a damage specific key
damage:smoothness and use the values from the existing smoothness key
values (http://wiki.openstreetmap.org/wiki/Key:smoothness). Routing
software would look for the damage:smoothness=* key and if present use
that value over the explicit or implicit smoothness=* value. When the
damage tags are removed, routing would return to pre-event status
automatically.
damage=[none | partial | major | destroyed]
damage:smoothness=[excellent | good | bad | horrible | impassable]
damage:event=event_name[;event_name2;etc]
damage:assessment=[none | initial | revision]
damage:organization=organization_adding_damage_tags_name
source:damage=[satellite | aerial | survey]


Cheers,
Blake

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging






___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Damage Assessment Tags - Would like feedback on a schema

[Blake Girardot]

Damage info has been tagged in OSM for a long time.

OSM already tags a lot of temporary and transient stuff.

We are aware of the nature of the tags and want to be able to review, 
maintain the remove the tags, it is one of the main goals of any tagging 
system we settle on like that.





On 5/21/2015 10:22 PM, Bryce Nesbitt wrote:

I feel this is a good example of a database that should use
OSM as a base layer.

A rendering engine can match a given primary key for, say, a building
outline
to the given damage assessment tag.

---

Damage assessment data is very transitory, compared to the lifetime of
objects in OSM.




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Damage Assessment Tags - Would like feedback on a schema

[Blake Girardot]

On 5/22/2015 1:43 AM, Bryce Nesbitt wrote:

On Thu, May 21, 2015 at 3:52 PM, Rafael Avila Coya ravilac...@gmail.com
mailto:ravilac...@gmail.com wrote:

Hi, Bryce:
Yes. Everything is temporary. So whatever we do in OSM for temporary
objects has to be applied to ALL objects.


We don't store the number of chickens found in each compound.
We do store railways, the traces of which are often found a hundred
years after construction.

---

Somewhere in the middle is a boundary.

The mapping of survey data feels to be better served by use of OSM as a
base map, rather than attributes of the base map.
The survey data as well involves a judgement: the type that's often not
verifiable or maintainable by a latter mapper.

That temporary road clearly belongs in OSM.  When it's replaced, an on
the ground mapper can see that situation
and adjust.  No so for the chicken count, or the damage assessment data.




While I appreciate this discussion, I don't feel this is the place for it.

Things like damaged/blocked roads, bridges, dams and even building 
damage data are verifiable on the ground. We work to train people in 
areas where OSM has little to no reach how to survey, confirm and care 
take the data.


OSM is about mapping what is important to people, and believe me, if the 
only bridge for 50km is out that is important to me and others.


I don't think we really tag this sort of damage very often, but when and 
where we do, we and others consider it important data.


So I would really like to get the most sensible tagging possible for 
damaged infrastructure and buildings and other disaster event related 
objects so where it makes sense to tag those in OSM we can tag them well.


Regards
blake

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Damage Assessment Tags - Would like feedback on a schema

[Blake Girardot]

Greetings everyone,

I am looking to help further develop a set of tags to reflect disaster
event damage to mapped objects in OSM. OSM has already used damage
tags in the past several times for example after Typhoon Haiyan:

http://wiki.openstreetmap.org/wiki/Damaged_buildings_crisis_mapping

And after the 2011 Sendai earthquake and tsunami

http://wiki.openstreetmap.org/wiki/2011_Sendai_earthquake_and_tsunami

And in Haiti

http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/Humanitarian_Data_Background#OpenStreetMap:_Tags_in_Current_Usage

I have read feedback about issues related to those tags and would like
to generate a set of tags that address that feedback. The main
feedback I saw was that the damage tags need to be separated from the
main object tags themselves (building=*, natural=*, highway=*, etc)
and they need to be easily removed after the damage is resolved or the
event is over.

Toward that end this is what myself and some other more experiences
mappers have come up with. We think it addresses those issues and
improves damage tagging in general. We would like community feedback
to help improve them before creating a wiki proposal page. Our over
arching goal of course is to create the most useful set of tags
possible. We are also going to reach out to some humanitarian
organizations to get feedback about their damage assessment data
models and hopefully use that to make improvements as well.

I know there are other people interested in this topic as well so if
anyone has complete alternative suggested schemas that would be great
too.

Any and all feedback and discussion is most welcome.

Tagging Schema
Criteria:
1. Separate feature/object from damage tag itself
2. Identify event the damage tag is related to for analysis and easily
removing them later
3. Allow for assessed and revised indication
4. Specify type/source of assessment
5. Easy to enter, remember, understand for mappers
6. Works well with overpass/overpass-turbo queries
7. Relatively easy for routing software to work with
8. Most similar to existing OSM tagging schemas
9. Allow for initial or revised damage assessment based on ground survey

For any area or node (buildings, amenities, landuse, natural, etc)
damage=[none | partial | major | destroyed]
damage:event=event_name[;event_name2;etc]
damage:assessment=[none | initial | revision]
damage:organization=organization_adding_damage_tags_name
source:damage=[satellite | aerial | survey]

For ways (highways)
These are the same as above, but we add a damage specific key
damage:smoothness and use the values from the existing smoothness key
values (http://wiki.openstreetmap.org/wiki/Key:smoothness). Routing
software would look for the damage:smoothness=* key and if present use
that value over the explicit or implicit smoothness=* value. When the
damage tags are removed, routing would return to pre-event status
automatically.
damage=[none | partial | major | destroyed]
damage:smoothness=[excellent | good | bad | horrible | impassable]
damage:event=event_name[;event_name2;etc]
damage:assessment=[none | initial | revision]
damage:organization=organization_adding_damage_tags_name
source:damage=[satellite | aerial | survey]


Cheers,
Blake

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging