Re: [Tagging] Feature Proposal - RFC - Hazards

[Graeme Fitzpatrick]

On Sun, 6 Dec 2020 at 04:22, Martin Koppenhoefer 
wrote:

>
> you guys are finding real world examples for every weird situation that
> nobody expected to even exist. Traffic lights for rock fall somewhere?
>

No actual traffic lights, but how about a posted No Waiting zone? :-)

https://parks.des.qld.gov.au/__data/assets/image/0021/162651/mt-maroon-rockfall.jpg

Thanks

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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Martin Koppenhoefer]

sent from a phone

> On 5. Dec 2020, at 22:34, Niels Elgaard Larsen  wrote:
> 
> Volker Schmidt:
>> Hi,
> 
>> In the case of signed hazards, I see two alternative ways of tagging the 
>> signing:
>>  * (only for nodes and ways highway segments) by adding source:xxx=sign like 
>> we do
>>with speed limits
> 
> I this it the best option.
> 
>>  * by mapping the relative signs as nodes
> 
> That often will not work. For example in Denmark on road with high speed 
> limits animal crossing hazards are usually signed ahead of the hazard 


yes, signs are usually ahead of the hazard. We can do both (the signs are best 
when it comes to verifiability, but if you want routers to warn you, highway 
properties or nodes on the highway bear a much greater probability of being 
implemented)

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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Niels Elgaard Larsen]

Volker Schmidt:

Hi,



In the case of signed hazards, I see two alternative ways of tagging the 
signing:

  * (only for nodes and ways highway segments) by adding source:xxx=sign like 
we do
with speed limits


I this it the best option.


  * by mapping the relative signs as nodes


That often will not work. For example in Denmark on road with high speed limits 
animal crossing hazards are usually signed ahead of the hazard like this:


https://www.mapillary.com/app/?focus=photo=7G5cfeYYHs7T_TQD4l-ifw=true=true=55.54605389678716=9.557919996586406=17

The same for hidden driveways in North America.



Insertion of signposted hazards do not require any assessment of the presence of the 
hazard by the mapper.


Signposted hazards are most often signalling dangers for vehicle drivers. Let's take 
the sign for hazard=cyclists (crossing), which warns clearly the vehicle drivers on 
the carriageway, that there could be cyclists crossing.

There is normally no such warning on the crossing cyclists' path.



We have warning signs for speed bumps on bicycle lanes and for low height when a 
bicycle lane go under a low brige.


This of course should be tagged by using traffic_calming and max_height on the 
highway=cycleway


Then we have also the asymmetric situations: e.g. car drivers are warned by a sign 
that there will be cyclists crossing, but the (bigger) hazard of cars hitting the 
cyclists on the same crossing is not signposted for cyclists.


Around here I think that is reasonable because it is usually when a road is crossed 
by a small unpaved path, that is used by cyclists.


If it is a real cycle path it would have a yield sign for cyclists.


--
Niels Elgaard Larsen

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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Martin Koppenhoefer]

Am Sa., 5. Dez. 2020 um 21:37 Uhr schrieb Volker Schmidt :

> Traffic lights triggered by avalanches! Is that close enough, Martin?
>
>
> https://elearning.unipd.it/scuolaamv/pluginfile.php/19629/mod_resource/content/1/04_02%20difesa%20dalla%20valanghe.pdf
>


I knew you would deliver :)

interesting presentation, thank you Volker

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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Volker Schmidt]

Traffic lights triggered by avalanches! Is that close enough, Martin?

https://elearning.unipd.it/scuolaamv/pluginfile.php/19629/mod_resource/content/1/04_02%20difesa%20dalla%20valanghe.pdf

I remember I saw them for the first time in 1985 in the Val Zoldana,
Provincia di Belluno (SP251), but had no idea how they worked. The document
above explains it.
:-)

Volker

On Sat, 5 Dec 2020 at 19:22, Martin Koppenhoefer 
wrote:

>
> >
> > Also at much larger airports. Brize Norton
> > (https://en.wikipedia.org/wiki/RAF_Brize_Norton), for example.
>
>
> you guys are finding real world examples for every weird situation that
> nobody expected to even exist. Traffic lights for rock fall somewhere?
>
> Cheers Martin
> ___
> 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] Feature Proposal - RFC - Hazards

[Brian M. Sperlongano]

I want to address the points that were raised on crossings.

As we already have highway=crossing, I have resisted adding new hazard=*
values for crossing hazards, as that is properly the domain of the
highway=crossing tag.  For golf cart crossing, there is already an
established tag combination highway=crossing + golf_cart=yes.  This was
already described on the wiki page for golf_cart, and I edited the wiki
page for highway=crossing to match this.

Considering this, I've updated the text on hazard=bicycle to reflect that
it is specifically about the hazard of cyclists in the roadway, and not for
bicycle crossings, which also has its own existing tagging.

This leaves hazard=school_crossing as the sole remaining "crossing"
hazard.  There are only a few usages of it, and I am leaning strongly
towards removing from the proposal entirely as it seems that a school
crossing belongs more properly within the scope of highway=crossing.

Lastly, the specific case of hazard=low_flying_aircraft is not a crossing
hazard, as the hazard is a distraction to motorists or perhaps jetwash
rather than collision, as with a crossing.  The only actual "airplane
crossing" that I am aware of is the case of the Gibraltar airport which has
a road that crosses the airport runway.  However, this is an exceptionally
rare case, and in any case, it too would belong under highway=crossing.

On Sat, Dec 5, 2020 at 12:43 PM Volker Schmidt  wrote:

> Hi,
> I have been following this proposal with interest. I often have tried to
> tag hazards, and not found a good ways of doing it.
> We are now compiling a long list of hazards, including golf players
> crossing the road, but I see some basic aspects which are not being
> addressed (unless I missed something):
>
> I would like to see signposted hazards completely separately tagged from
> hazards that the mapper perceives in a place, but which are not signed.
>
> Signed hazards should be mapped.
>
>- on nodes, if the extension of the hazard is point-like (example:
>dangerous railway crossing)
>- on ways, if the hazard exists along a highway (example: animals
>crossing zones)
>- (possibly) on areas, if the hazard is present in an area (example:
>landslides)
>
> In the case of signed hazards, I see two alternative ways of tagging the
> signing:
>
>- (only for nodes and ways highway segments) by adding source:xxx=sign
>like we do with speed limits
>- by mapping the relative signs as nodes
>
> Insertion of signposted hazards do not require any assessment of the
> presence of the hazard by the mapper.
>
> Signposted hazards are most often signalling dangers for vehicle drivers.
> Let's take the sign for hazard=cyclists (crossing), which warns clearly the
> vehicle drivers on the carriageway, that there could be cyclists crossing.
> There is normally no such warning on the crossing cyclists' path.
> There are exceptions of hazard warnings for both parties like a "cyclists
> sharing the road" sign, but that's the only one that comes to mind.
>
> Another aspect that should be defined: Are writings or pictograms on the
> road surface equivalent to vertical traffic signs?
>
>
> A completely different story are unsigned hazards with no signs on the
> ground, i.e. situations perceived as a hazard by the mapper.
> These are the tricky ones. I map cycling infrastructure, hence my examples
> come from that perspective.
> Examples:
>
>- foot-cycle crosswalks where there is a sign-posted speed limit of
>30km/h, but where 90% of the cars pass with speeds far exceeding that value
>and making the place really dangerous
>- a two-way cycle path that is parallel to a main road and crosses  a
>side road with a foot.bicycle crosswalk - car drivers entering the side
>road regularly overlook cyclists which ride in the same direction as they
>drive (to my knowledge the major cause of cyclists being killed in many
>countries. These in most cases in my part of the world have no danger
>signs.
>- And now consider the same situation with a row of trees between the
>cycle path and the main carriage way.
>- In my part of the world authorities put all kinds of bollards,
>arches, chicanes on cycleways (supposedly for the safety of cyclists, but
>in reality to keep car drivers from parking there). Many of these are grey
>metal objects that become invisible at night even if you have a good cycle
>light, as they have no reflective markers on them.
>
> The problem here is that the tagging will be based on my perceived version
> of ground truth. If I am a cyclist, I may be good at spotting hazards for
> cyclists. If I am a horse rider I will be good at mapping hazards for horse
> riders.
>
> Then we have also the asymmetric situations: e.g. car drivers are warned
> by a sign that there will be cyclists crossing, but the (bigger) hazard of
> cars hitting the cyclists on the same crossing is not signposted for
> cyclists.
>
> Volker
>
>

Re: [Tagging] Feature Proposal - RFC - Hazards

[Yves via Tagging]

Le 5 décembre 2020 19:19:31 GMT+01:00, Martin Koppenhoefer 
 a écrit :
>
>you guys are finding real world examples for every weird situation that nobody 
>expected to even exist. Traffic lights for rock fall somewhere?
>
>Cheers Martin  
They are no so rare, I remember one going down from La Grave toward Grenoble in 
the alps. No picture at hand though, and not sure they belong or not to the 
road section that has to be rebuilt. 

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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Joseph Eisenberg]

The solution to the lack of official signs is to petition your local
government to add the signs or pavement markings or some other visible
warning of the hazard. This will have much more real-world impact than
adding a tag to OpenStreetMap. And it will make it possible to verifiably
add the tag of the hazard.

In my part of the world, cyclists sometimes spray-paint the pavement with
warnings to mark the location of hazards like tree roots or pot-holes or
dangerous crossings. While these are not official markings, they exist and
are verifiable, so they could also be mapped.

(Before considering heading out with a can of spray-paint, please check
your local vandalism legislation... :-) )

-- Joseph Eisenberg

On Sat, Dec 5, 2020 at 9:43 AM Volker Schmidt  wrote:

> Hi,
> I have been following this proposal with interest. I often have tried to
> tag hazards, and not found a good ways of doing it.
> We are now compiling a long list of hazards, including golf players
> crossing the road, but I see some basic aspects which are not being
> addressed (unless I missed something):
>
> I would like to see signposted hazards completely separately tagged from
> hazards that the mapper perceives in a place, but which are not signed.
>
> Signed hazards should be mapped.
>
>- on nodes, if the extension of the hazard is point-like (example:
>dangerous railway crossing)
>- on ways, if the hazard exists along a highway (example: animals
>crossing zones)
>- (possibly) on areas, if the hazard is present in an area (example:
>landslides)
>
> In the case of signed hazards, I see two alternative ways of tagging the
> signing:
>
>- (only for nodes and ways highway segments) by adding source:xxx=sign
>like we do with speed limits
>- by mapping the relative signs as nodes
>
> Insertion of signposted hazards do not require any assessment of the
> presence of the hazard by the mapper.
>
> Signposted hazards are most often signalling dangers for vehicle drivers.
> Let's take the sign for hazard=cyclists (crossing), which warns clearly the
> vehicle drivers on the carriageway, that there could be cyclists crossing.
> There is normally no such warning on the crossing cyclists' path.
> There are exceptions of hazard warnings for both parties like a "cyclists
> sharing the road" sign, but that's the only one that comes to mind.
>
> Another aspect that should be defined: Are writings or pictograms on the
> road surface equivalent to vertical traffic signs?
>
>
> A completely different story are unsigned hazards with no signs on the
> ground, i.e. situations perceived as a hazard by the mapper.
> These are the tricky ones. I map cycling infrastructure, hence my examples
> come from that perspective.
> Examples:
>
>- foot-cycle crosswalks where there is a sign-posted speed limit of
>30km/h, but where 90% of the cars pass with speeds far exceeding that value
>and making the place really dangerous
>- a two-way cycle path that is parallel to a main road and crosses  a
>side road with a foot.bicycle crosswalk - car drivers entering the side
>road regularly overlook cyclists which ride in the same direction as they
>drive (to my knowledge the major cause of cyclists being killed in many
>countries. These in most cases in my part of the world have no danger
>signs.
>- And now consider the same situation with a row of trees between the
>cycle path and the main carriage way.
>- In my part of the world authorities put all kinds of bollards,
>arches, chicanes on cycleways (supposedly for the safety of cyclists, but
>in reality to keep car drivers from parking there). Many of these are grey
>metal objects that become invisible at night even if you have a good cycle
>light, as they have no reflective markers on them.
>
> The problem here is that the tagging will be based on my perceived version
> of ground truth. If I am a cyclist, I may be good at spotting hazards for
> cyclists. If I am a horse rider I will be good at mapping hazards for horse
> riders.
>
> Then we have also the asymmetric situations: e.g. car drivers are warned
> by a sign that there will be cyclists crossing, but the (bigger) hazard of
> cars hitting the cyclists on the same crossing is not signposted for
> cyclists.
>
> Volker
>
>
> On Sat, 5 Dec 2020 at 17:05, ael via Tagging 
> wrote:
>
>> On Fri, Dec 04, 2020 at 09:48:27PM +, Paul Allen wrote:
>> > On Fri, 4 Dec 2020 at 19:56, Martin Koppenhoefer <
>> dieterdre...@gmail.com>
>> > wrote:
>> >
>> > Up until around ten years ago, a minor road went past the end of the
>> > runway at what passes for an airport.  The planes could be so low on
>> > approach to the runway that there were traffic signals to prevent
>> > vehicles crossing the path of an aircraft.  There were also signs
>> > warning of low-flying aircraft, which I referred to as "Give way
>> > to aircraft."
>>
>> Also at much larger airports. Brize Norton
>> 

Re: [Tagging] Feature Proposal - RFC - Hazards

[Martin Koppenhoefer]

sent from a phone

> On 5. Dec 2020, at 17:05, ael via Tagging  wrote:
> 
> Also at much larger airports. Brize Norton
> (https://en.wikipedia.org/wiki/RAF_Brize_Norton), for example.


you guys are finding real world examples for every weird situation that nobody 
expected to even exist. Traffic lights for rock fall somewhere?

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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Volker Schmidt]

Hi,
I have been following this proposal with interest. I often have tried to
tag hazards, and not found a good ways of doing it.
We are now compiling a long list of hazards, including golf players
crossing the road, but I see some basic aspects which are not being
addressed (unless I missed something):

I would like to see signposted hazards completely separately tagged from
hazards that the mapper perceives in a place, but which are not signed.

Signed hazards should be mapped.

   - on nodes, if the extension of the hazard is point-like (example:
   dangerous railway crossing)
   - on ways, if the hazard exists along a highway (example: animals
   crossing zones)
   - (possibly) on areas, if the hazard is present in an area (example:
   landslides)

In the case of signed hazards, I see two alternative ways of tagging the
signing:

   - (only for nodes and ways highway segments) by adding source:xxx=sign
   like we do with speed limits
   - by mapping the relative signs as nodes

Insertion of signposted hazards do not require any assessment of the
presence of the hazard by the mapper.

Signposted hazards are most often signalling dangers for vehicle drivers.
Let's take the sign for hazard=cyclists (crossing), which warns clearly the
vehicle drivers on the carriageway, that there could be cyclists crossing.
There is normally no such warning on the crossing cyclists' path.
There are exceptions of hazard warnings for both parties like a "cyclists
sharing the road" sign, but that's the only one that comes to mind.

Another aspect that should be defined: Are writings or pictograms on the
road surface equivalent to vertical traffic signs?


A completely different story are unsigned hazards with no signs on the
ground, i.e. situations perceived as a hazard by the mapper.
These are the tricky ones. I map cycling infrastructure, hence my examples
come from that perspective.
Examples:

   - foot-cycle crosswalks where there is a sign-posted speed limit of
   30km/h, but where 90% of the cars pass with speeds far exceeding that value
   and making the place really dangerous
   - a two-way cycle path that is parallel to a main road and crosses  a
   side road with a foot.bicycle crosswalk - car drivers entering the side
   road regularly overlook cyclists which ride in the same direction as they
   drive (to my knowledge the major cause of cyclists being killed in many
   countries. These in most cases in my part of the world have no danger
   signs.
   - And now consider the same situation with a row of trees between the
   cycle path and the main carriage way.
   - In my part of the world authorities put all kinds of bollards, arches,
   chicanes on cycleways (supposedly for the safety of cyclists, but in
   reality to keep car drivers from parking there). Many of these are grey
   metal objects that become invisible at night even if you have a good cycle
   light, as they have no reflective markers on them.

The problem here is that the tagging will be based on my perceived version
of ground truth. If I am a cyclist, I may be good at spotting hazards for
cyclists. If I am a horse rider I will be good at mapping hazards for horse
riders.

Then we have also the asymmetric situations: e.g. car drivers are warned by
a sign that there will be cyclists crossing, but the (bigger) hazard of
cars hitting the cyclists on the same crossing is not signposted for
cyclists.

Volker


On Sat, 5 Dec 2020 at 17:05, ael via Tagging 
wrote:

> On Fri, Dec 04, 2020 at 09:48:27PM +, Paul Allen wrote:
> > On Fri, 4 Dec 2020 at 19:56, Martin Koppenhoefer  >
> > wrote:
> >
> > Up until around ten years ago, a minor road went past the end of the
> > runway at what passes for an airport.  The planes could be so low on
> > approach to the runway that there were traffic signals to prevent
> > vehicles crossing the path of an aircraft.  There were also signs
> > warning of low-flying aircraft, which I referred to as "Give way
> > to aircraft."
>
> Also at much larger airports. Brize Norton
> (https://en.wikipedia.org/wiki/RAF_Brize_Norton), for example.
>
> https://www.openstreetmap.org/node/190194553 for one of the traffic
> lights.
>
> ael
>
>
> ___
> 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] Feature Proposal - RFC - Hazards

[ael via Tagging]

On Fri, Dec 04, 2020 at 09:48:27PM +, Paul Allen wrote:
> On Fri, 4 Dec 2020 at 19:56, Martin Koppenhoefer 
> wrote:
> 
> Up until around ten years ago, a minor road went past the end of the
> runway at what passes for an airport.  The planes could be so low on
> approach to the runway that there were traffic signals to prevent
> vehicles crossing the path of an aircraft.  There were also signs
> warning of low-flying aircraft, which I referred to as "Give way
> to aircraft."

Also at much larger airports. Brize Norton
(https://en.wikipedia.org/wiki/RAF_Brize_Norton), for example.

https://www.openstreetmap.org/node/190194553 for one of the traffic
lights.

ael


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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Michael Patrick]

I pretty much learned to drive in the State of Montana, and they had a
superbly simple method of road hazard warning. For every fatal accident,
they would plant a post, and on the post would be one or more crosses
corresponeding to the fatalities in that accident. ( Keep in mind for many
years, Montana had an unlimited speed limit, and even aft the nationall 55
limit, you were issued a $5 'fuel consumption violation' )

So, when you were cruising up to curve in the road, especially at night
when your headlights would reflect off them, it gave a nicely quantitative
measure of how fast one should take that stretch of road. :-)

https://bozemanmagazine.com/articles/2019/12/01/103395-sobering-reminder-montanas-fatality-marker
and https://bit.ly/37FUnzZ

Michael Patrick



Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Hazards (verifiability - frost heave?)

[Graeme Fitzpatrick]

On Sat, 5 Dec 2020 at 07:13, Joseph Eisenberg 
wrote:

>
> This will make it easier to fix problems with mappers who want to add
> hazard=curve to every single curve on a long curvy road, or add very
> subjective hazard features which  cannot be confirmed or denied even when
> visiting the location in person.
>

But in some cases, "hazardous" or not will be weather / season dependent.
This curve is fine in bright, sunny, dry weather, but in rain, or when icy
during winter, it's deadly. So when you pass by that spot during summer,
you could well say why is it posted as a hazard, while the locals who are
there year-round know why.

& thanks, Brian - it's getting better all the time! :-)

Thanks

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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Paul Allen]

On Fri, 4 Dec 2020 at 19:56, Martin Koppenhoefer 
wrote:

>
> They do not imply that you have to fear airplanes on the street, they
> are meant to prepare you for low flying aircraft.
>

Up until around ten years ago, a minor road went past the end of the
runway at what passes for an airport.  The planes could be so low on
approach to the runway that there were traffic signals to prevent
vehicles crossing the path of an aircraft.  There were also signs
warning of low-flying aircraft, which I referred to as "Give way
to aircraft."

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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Joseph Eisenberg]

While hazard=yes is certainly in use (like barrier=yes and even
amenity=yes), it shouldn't be included in the proposal.

In every case it will be more helpful if users make up a new tag. If there
is a sign warning of monkeys which are prone to steal tourist's purses,
then hazard=purse_pilfering_primates is better than hazard=yes, since it
immediately make it possible for other mappers and database users to get
some idea about the kind of hazard.

The current mention of hazard=yes in addition to another main tag, like
man_made=adit + hazard=yes, is not terrible, though man_made=adit +
hazard=collapse or hazard=toxic_air would be clearer - it's not always
obvious which kind of hazard to expect.

-- Joseph Eisenberg

On Fri, Dec 4, 2020 at 12:38 PM Brian M. Sperlongano 
wrote:

> There's a few usages of hazard=golf_balls, which is more like what you're
> describing and actually a hazard.  It seems a bit nebulous, but perhaps the
> sign could be mapped.  That's different from a golf crossing, which is a
> place where golfers and golf carts would cross a road.
>
> I've already added hazard=low_flying_aircraft as was previously suggested.
>
> And with regard to the generic hazard sign, there is always the generic
> catch-all of hazard=yes!
>
> Thanks for the link to the directory of German signs.  I think most of
> them are covered, though there's a few outliers.  I'm trying to err on the
> side of defining fewer values to make sure that we don't end up duplicating
> something that exists elsewhere (for example, in the cases of
> highway=crossing and traffic_calming=* which are both often signed as
> hazards).  Essentially my net is "values that have high existing usage plus
> values that people feel strongly about including".
>
>
>
> On Fri, Dec 4, 2020 at 2:56 PM Martin Koppenhoefer 
> wrote:
>
>> sent from a phone
>>
>> > On 4. Dec 2020, at 17:42, Brian M. Sperlongano 
>> wrote:
>> >
>> > I am thinking this case (crossing golfers) is more of a
>> highway=crossing rather than a hazard?
>>
>>
>> I think it is a warning that a golf ball might eventually hit your
>> vehicle, and if you’re prepared you won’t be startled
>>
>> There is also the crossing airplane hazard, even 2 variants, airplanes
>> from the right:
>>
>> https://commons.wikimedia.org/wiki/File:Zeichen_101-10_-_Flugbetrieb,_Aufstellung_rechts,_StVO_2017.svg
>> and from the left:
>>
>> https://commons.wikimedia.org/wiki/File:Zeichen_101-20_-_Flugbetrieb,_Aufstellung_links,_StVO_2017.svg
>>
>> They do not imply that you have to fear airplanes on the street, they
>> are meant to prepare you for low flying aircraft.
>>
>> A picture list of all German "standard hazards" can be found here:
>>
>> https://de.wikipedia.org/wiki/Bildtafel_der_Verkehrszeichen_in_der_Bundesrepublik_Deutschland_seit_2017#Gefahrzeichen_nach_Anlage_1_(zu_%C2%A7_40_Absatz_6_und_7_StVO)
>> but with this  sign
>>
>> https://commons.wikimedia.org/wiki/File:Zeichen_101_-_Gefahrstelle,_StVO_1970.svg
>> in combination with a text sign, any hazard can be signposted.
>>
>> These are only the official road signs, on footways and private
>> properties, information signs etc., you might find all kind of other
>> hazard warnings. Is the tag only thought for roads and official road
>> signs, or is its scope extended to other official signs (e.g. in some
>> forests, there are "Rabies prone area" official signs, military areas
>> might warn with "restricted area, armed guards", and a property owner
>> might allude their dog is snappish.
>>
>> Cheers
>> Martin
>>
>> ___
>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Hazards (verifiability - frost heave?)

[Martin Koppenhoefer]

sent from a phone

> On 4. Dec 2020, at 21:43, Brian M. Sperlongano  wrote:
> 
> Does that satisfy your concern?


yes, very reasonable, maybe could add that unsigned hazards can not only be 
found in the developing world, but the probability of encountering them will 
raise the farther you move from civilization/other people. E.g. in the 
mountains you’ll hardly find hazard signs, but a lot of hazards

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

Re: [Tagging] Feature Proposal - RFC - Hazards (verifiability - frost heave?)

[Joseph Eisenberg]

Re: "However, in some cases, notably in the developing world, these types
of hazards may be tagged even if unsigned."

While this is certainly a true statement which represents the actual
situation in OpenStreetMap, I think it isn't needed in the proposal.
Mappers will always feel free to add features which are generally
recognized to exist by local people. I would prefer that the proposal focus
on mapping verifiable evidence of hazards, such as the signs, barriers, and
official announcements.

This will make it easier to fix problems with mappers who want to add
hazard=curve to every single curve on a long curvy road, or add very
subjective hazard features which  cannot be confirmed or denied even when
visiting the location in person.

-- Joseph Eisenberg

On Fri, Dec 4, 2020 at 12:43 PM Brian M. Sperlongano 
wrote:

>
> This was a concern of mine as well.  I did not want someone micromapping
> every bend in a road with hazard=curve for example.  The intent is for
> officially declared hazards rather than vague interpretations.  However, I
> also recognize that, particularly in the developing world, formal signage
> or declaration may not exist and that unsigned hazards should be allowed.
> I specifically wrote the paragraph below (from the proposal) to address
> this issue.
>
> Does that satisfy your concern?
>
> === Proposal text below ===
>
> Hazards are verifiable via the following means:
>
> * Hazards to drivers indicated by roadside traffic signs.
> * Hazards to health and safety indicated by fences or other barriers with
> posted signs
> * Government-declared hazardous areas as marked on government maps and/or
> GIS systems
> * For countries which routinely sign traffic hazards (such as "dangerous
> curve" or "school zone"), mappers should only tag these hazards when they
> are actually signed. However, in some cases, notably in the developing
> world, these types of hazards may be tagged even if unsigned.
>
> On Fri, Dec 4, 2020 at 3:56 AM Jez Nicholson 
> wrote:
>
>> As long as your frost heave conforms to verifiability guidelines by being
>> either:
>> a) signposted (possibly)
>> b) fenced off, with a sign (no, because it's in the road)
>> c) a government-declared hazardous area (no)
>>
>> I'm concerned that this hazard tagging proposal will encourage subjective
>> tagging over what constitutes a 'hazard'.
>>
>>
>> On Thu, Dec 3, 2020 at 7:49 PM Brian M. Sperlongano 
>> wrote:
>>
>>> I'd think that frost heaves (which are seasonal and conditions-based)
>>> versus permanent bumps are different.  If there aren't objections, I'd
>>> propose both a hazard=bump (which has a few trace uses) and a new value
>>> hazard=frost_heave to cover frost heaves specifically.
>>>
>>> On Thu, Dec 3, 2020 at 2:37 PM Adam Franco  wrote:
>>>
 *hazard=frost_heave, hazard=bump?*

 One of the common road hazards I encounter and would like to tag are
 large frost heaves that occur at consistent locations every year. A few
 roads in my region like VT-17 and NY-8 have poor roadbeds and get damaged
 by frost heaves the first winter after repaving. These roads often have
 several hundred yards of nice smooth and fresh pavement, then 2"-8" frost
 heaves with cracks that reappear in the same places year after year.

 Some examples:

- VT-17: section A
, section B
 (with
"BUMP" sign), section C

- NY-8: section A

 ,
section B

 

 This has been previously mentioned in an OSMUS Slack thread
  in
 regard to smoothness=*, but tagging particularly bad (and often
 permanent) heaves may be preferable as other sections of the roadway may be
 smooth and freshly paved.

 Signage on these tends to be inconsistent, often using phrasing like
 "BUMP", "CAUTION: FROST HEAVE", "FROST HEAVE AHEAD", or other similar
 phrases. In some locations the signs are permanently mounted, while other
 locations get folding signage. As these are point features with varying
 placement of signage, I would suggest mapping them as nodes on a roadway at
 the heave position with something like hazard=frost_heave.
 Alternatively, hazard=bump may be applicable to other situations
 worldwide for dangerous bumps caused by something other than freeze/thaw
 cycles.

 Best,
 Adam

 On Wed, Nov 25, 2020 at 8:27 AM Brian M. Sperlongano <
 zelonew...@gmail.com> wrote:

Re: [Tagging] Feature Proposal - RFC - Hazards (verifiability - frost heave?)

[Brian M. Sperlongano]

This was a concern of mine as well.  I did not want someone micromapping
every bend in a road with hazard=curve for example.  The intent is for
officially declared hazards rather than vague interpretations.  However, I
also recognize that, particularly in the developing world, formal signage
or declaration may not exist and that unsigned hazards should be allowed.
I specifically wrote the paragraph below (from the proposal) to address
this issue.

Does that satisfy your concern?

=== Proposal text below ===

Hazards are verifiable via the following means:

* Hazards to drivers indicated by roadside traffic signs.
* Hazards to health and safety indicated by fences or other barriers with
posted signs
* Government-declared hazardous areas as marked on government maps and/or
GIS systems
* For countries which routinely sign traffic hazards (such as "dangerous
curve" or "school zone"), mappers should only tag these hazards when they
are actually signed. However, in some cases, notably in the developing
world, these types of hazards may be tagged even if unsigned.

On Fri, Dec 4, 2020 at 3:56 AM Jez Nicholson 
wrote:

> As long as your frost heave conforms to verifiability guidelines by being
> either:
> a) signposted (possibly)
> b) fenced off, with a sign (no, because it's in the road)
> c) a government-declared hazardous area (no)
>
> I'm concerned that this hazard tagging proposal will encourage subjective
> tagging over what constitutes a 'hazard'.
>
>
> On Thu, Dec 3, 2020 at 7:49 PM Brian M. Sperlongano 
> wrote:
>
>> I'd think that frost heaves (which are seasonal and conditions-based)
>> versus permanent bumps are different.  If there aren't objections, I'd
>> propose both a hazard=bump (which has a few trace uses) and a new value
>> hazard=frost_heave to cover frost heaves specifically.
>>
>> On Thu, Dec 3, 2020 at 2:37 PM Adam Franco  wrote:
>>
>>> *hazard=frost_heave, hazard=bump?*
>>>
>>> One of the common road hazards I encounter and would like to tag are
>>> large frost heaves that occur at consistent locations every year. A few
>>> roads in my region like VT-17 and NY-8 have poor roadbeds and get damaged
>>> by frost heaves the first winter after repaving. These roads often have
>>> several hundred yards of nice smooth and fresh pavement, then 2"-8" frost
>>> heaves with cracks that reappear in the same places year after year.
>>>
>>> Some examples:
>>>
>>>- VT-17: section A
>>>, section B
>>> (with
>>>"BUMP" sign), section C
>>>
>>>- NY-8: section A
>>>
>>> ,
>>>section B
>>>
>>> 
>>>
>>> This has been previously mentioned in an OSMUS Slack thread
>>>  in
>>> regard to smoothness=*, but tagging particularly bad (and often
>>> permanent) heaves may be preferable as other sections of the roadway may be
>>> smooth and freshly paved.
>>>
>>> Signage on these tends to be inconsistent, often using phrasing like
>>> "BUMP", "CAUTION: FROST HEAVE", "FROST HEAVE AHEAD", or other similar
>>> phrases. In some locations the signs are permanently mounted, while other
>>> locations get folding signage. As these are point features with varying
>>> placement of signage, I would suggest mapping them as nodes on a roadway at
>>> the heave position with something like hazard=frost_heave.
>>> Alternatively, hazard=bump may be applicable to other situations
>>> worldwide for dangerous bumps caused by something other than freeze/thaw
>>> cycles.
>>>
>>> Best,
>>> Adam
>>>
>>> On Wed, Nov 25, 2020 at 8:27 AM Brian M. Sperlongano <
>>> zelonew...@gmail.com> wrote:
>>>
 Comment is requested on the proposal "hazard", which describes
 hazardous or dangerous features.  This tagging was first proposed in 2007,
 and I have adopted the proposal with permission from the original author.
 Thanks to the various folks that assisted in the development of this
 proposal prior to this RFC.

 The key "hazard" has achieved over 28,000 usages, and it is proposed to
 formalize usage of the most popular values of this key while deprecating
 less-popular synonyms.  In addition, this proposes to deprecate
 protect_class=16 in favor of the hazard key.

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

>>> ___
>>> Tagging mailing list
>>> 

Re: [Tagging] Feature Proposal - RFC - Hazards

[Brian M. Sperlongano]

There's a few usages of hazard=golf_balls, which is more like what you're
describing and actually a hazard.  It seems a bit nebulous, but perhaps the
sign could be mapped.  That's different from a golf crossing, which is a
place where golfers and golf carts would cross a road.

I've already added hazard=low_flying_aircraft as was previously suggested.

And with regard to the generic hazard sign, there is always the generic
catch-all of hazard=yes!

Thanks for the link to the directory of German signs.  I think most of them
are covered, though there's a few outliers.  I'm trying to err on the side
of defining fewer values to make sure that we don't end up duplicating
something that exists elsewhere (for example, in the cases of
highway=crossing and traffic_calming=* which are both often signed as
hazards).  Essentially my net is "values that have high existing usage plus
values that people feel strongly about including".



On Fri, Dec 4, 2020 at 2:56 PM Martin Koppenhoefer 
wrote:

> sent from a phone
>
> > On 4. Dec 2020, at 17:42, Brian M. Sperlongano 
> wrote:
> >
> > I am thinking this case (crossing golfers) is more of a highway=crossing
> rather than a hazard?
>
>
> I think it is a warning that a golf ball might eventually hit your
> vehicle, and if you’re prepared you won’t be startled
>
> There is also the crossing airplane hazard, even 2 variants, airplanes
> from the right:
>
> https://commons.wikimedia.org/wiki/File:Zeichen_101-10_-_Flugbetrieb,_Aufstellung_rechts,_StVO_2017.svg
> and from the left:
>
> https://commons.wikimedia.org/wiki/File:Zeichen_101-20_-_Flugbetrieb,_Aufstellung_links,_StVO_2017.svg
>
> They do not imply that you have to fear airplanes on the street, they
> are meant to prepare you for low flying aircraft.
>
> A picture list of all German "standard hazards" can be found here:
>
> https://de.wikipedia.org/wiki/Bildtafel_der_Verkehrszeichen_in_der_Bundesrepublik_Deutschland_seit_2017#Gefahrzeichen_nach_Anlage_1_(zu_%C2%A7_40_Absatz_6_und_7_StVO)
> but with this  sign
>
> https://commons.wikimedia.org/wiki/File:Zeichen_101_-_Gefahrstelle,_StVO_1970.svg
> in combination with a text sign, any hazard can be signposted.
>
> These are only the official road signs, on footways and private
> properties, information signs etc., you might find all kind of other
> hazard warnings. Is the tag only thought for roads and official road
> signs, or is its scope extended to other official signs (e.g. in some
> forests, there are "Rabies prone area" official signs, military areas
> might warn with "restricted area, armed guards", and a property owner
> might allude their dog is snappish.
>
> Cheers
> Martin
>
> ___
> 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] Feature Proposal - RFC - Hazards

[Martin Koppenhoefer]

sent from a phone

> On 4. Dec 2020, at 17:42, Brian M. Sperlongano  wrote:
>
> I am thinking this case (crossing golfers) is more of a highway=crossing 
> rather than a hazard?


I think it is a warning that a golf ball might eventually hit your
vehicle, and if you’re prepared you won’t be startled

There is also the crossing airplane hazard, even 2 variants, airplanes
from the right:
https://commons.wikimedia.org/wiki/File:Zeichen_101-10_-_Flugbetrieb,_Aufstellung_rechts,_StVO_2017.svg
and from the left:
https://commons.wikimedia.org/wiki/File:Zeichen_101-20_-_Flugbetrieb,_Aufstellung_links,_StVO_2017.svg

They do not imply that you have to fear airplanes on the street, they
are meant to prepare you for low flying aircraft.

A picture list of all German "standard hazards" can be found here:
https://de.wikipedia.org/wiki/Bildtafel_der_Verkehrszeichen_in_der_Bundesrepublik_Deutschland_seit_2017#Gefahrzeichen_nach_Anlage_1_(zu_%C2%A7_40_Absatz_6_und_7_StVO)
but with this  sign
https://commons.wikimedia.org/wiki/File:Zeichen_101_-_Gefahrstelle,_StVO_1970.svg
in combination with a text sign, any hazard can be signposted.

These are only the official road signs, on footways and private
properties, information signs etc., you might find all kind of other
hazard warnings. Is the tag only thought for roads and official road
signs, or is its scope extended to other official signs (e.g. in some
forests, there are "Rabies prone area" official signs, military areas
might warn with "restricted area, armed guards", and a property owner
might allude their dog is snappish.

Cheers
Martin

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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Brian M. Sperlongano]

I am thinking this case (crossing golfers) is more of a highway=crossing
rather than a hazard?  There appear to be no existing values of hazard for
indicating crossing golfers to lean on here.

On Fri, Dec 4, 2020 at 11:23 AM Niels Elgaard Larsen 
wrote:

> Brian M. Sperlongano:
> > Niels, thanks for the list.
>
>
> I found another Danish hazard
> Crossing golfers:
> https://hopcycling.pl/wp-content/uploads/2019/06/L9720954.jpg
>
>
> --
> Niels Elgaard Larsen
>
> ___
> 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] Feature Proposal - RFC - Hazards

[Niels Elgaard Larsen]

Brian M. Sperlongano:

Niels, thanks for the list.



I found another Danish hazard
Crossing golfers:
https://hopcycling.pl/wp-content/uploads/2019/06/L9720954.jpg


--
Niels Elgaard Larsen

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

Re: [Tagging] Feature Proposal - RFC - Hazards (frost heave?)

[Jez Nicholson]

As long as your frost heave conforms to verifiability guidelines by being
either:
a) signposted (possibly)
b) fenced off, with a sign (no, because it's in the road)
c) a government-declared hazardous area (no)

I'm concerned that this hazard tagging proposal will encourage subjective
tagging over what constitutes a 'hazard'.


On Thu, Dec 3, 2020 at 7:49 PM Brian M. Sperlongano 
wrote:

> I'd think that frost heaves (which are seasonal and conditions-based)
> versus permanent bumps are different.  If there aren't objections, I'd
> propose both a hazard=bump (which has a few trace uses) and a new value
> hazard=frost_heave to cover frost heaves specifically.
>
> On Thu, Dec 3, 2020 at 2:37 PM Adam Franco  wrote:
>
>> *hazard=frost_heave, hazard=bump?*
>>
>> One of the common road hazards I encounter and would like to tag are
>> large frost heaves that occur at consistent locations every year. A few
>> roads in my region like VT-17 and NY-8 have poor roadbeds and get damaged
>> by frost heaves the first winter after repaving. These roads often have
>> several hundred yards of nice smooth and fresh pavement, then 2"-8" frost
>> heaves with cracks that reappear in the same places year after year.
>>
>> Some examples:
>>
>>- VT-17: section A
>>, section B
>> (with
>>"BUMP" sign), section C
>>
>>- NY-8: section A
>>
>> ,
>>section B
>>
>> 
>>
>> This has been previously mentioned in an OSMUS Slack thread
>>  in regard
>> to smoothness=*, but tagging particularly bad (and often permanent)
>> heaves may be preferable as other sections of the roadway may be smooth and
>> freshly paved.
>>
>> Signage on these tends to be inconsistent, often using phrasing like
>> "BUMP", "CAUTION: FROST HEAVE", "FROST HEAVE AHEAD", or other similar
>> phrases. In some locations the signs are permanently mounted, while other
>> locations get folding signage. As these are point features with varying
>> placement of signage, I would suggest mapping them as nodes on a roadway at
>> the heave position with something like hazard=frost_heave.
>> Alternatively, hazard=bump may be applicable to other situations
>> worldwide for dangerous bumps caused by something other than freeze/thaw
>> cycles.
>>
>> Best,
>> Adam
>>
>> On Wed, Nov 25, 2020 at 8:27 AM Brian M. Sperlongano <
>> zelonew...@gmail.com> wrote:
>>
>>> Comment is requested on the proposal "hazard", which describes hazardous
>>> or dangerous features.  This tagging was first proposed in 2007, and I have
>>> adopted the proposal with permission from the original author.  Thanks to
>>> the various folks that assisted in the development of this proposal prior
>>> to this RFC.
>>>
>>> The key "hazard" has achieved over 28,000 usages, and it is proposed to
>>> formalize usage of the most popular values of this key while deprecating
>>> less-popular synonyms.  In addition, this proposes to deprecate
>>> protect_class=16 in favor of the hazard key.
>>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/hazard
>>> ___
>>> 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 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] Feature Proposal - RFC - Hazards (frost heave?)

[Brian M. Sperlongano]

I'd think that frost heaves (which are seasonal and conditions-based)
versus permanent bumps are different.  If there aren't objections, I'd
propose both a hazard=bump (which has a few trace uses) and a new value
hazard=frost_heave to cover frost heaves specifically.

On Thu, Dec 3, 2020 at 2:37 PM Adam Franco  wrote:

> *hazard=frost_heave, hazard=bump?*
>
> One of the common road hazards I encounter and would like to tag are large
> frost heaves that occur at consistent locations every year. A few roads in
> my region like VT-17 and NY-8 have poor roadbeds and get damaged by frost
> heaves the first winter after repaving. These roads often have several
> hundred yards of nice smooth and fresh pavement, then 2"-8" frost heaves
> with cracks that reappear in the same places year after year.
>
> Some examples:
>
>- VT-17: section A
>, section B
> (with "BUMP"
>sign), section C
>
>- NY-8: section A
>
> ,
>section B
>
> 
>
> This has been previously mentioned in an OSMUS Slack thread
>  in regard
> to smoothness=*, but tagging particularly bad (and often permanent)
> heaves may be preferable as other sections of the roadway may be smooth and
> freshly paved.
>
> Signage on these tends to be inconsistent, often using phrasing like
> "BUMP", "CAUTION: FROST HEAVE", "FROST HEAVE AHEAD", or other similar
> phrases. In some locations the signs are permanently mounted, while other
> locations get folding signage. As these are point features with varying
> placement of signage, I would suggest mapping them as nodes on a roadway at
> the heave position with something like hazard=frost_heave. Alternatively,
> hazard=bump may be applicable to other situations worldwide for dangerous
> bumps caused by something other than freeze/thaw cycles.
>
> Best,
> Adam
>
> On Wed, Nov 25, 2020 at 8:27 AM Brian M. Sperlongano 
> wrote:
>
>> Comment is requested on the proposal "hazard", which describes hazardous
>> or dangerous features.  This tagging was first proposed in 2007, and I have
>> adopted the proposal with permission from the original author.  Thanks to
>> the various folks that assisted in the development of this proposal prior
>> to this RFC.
>>
>> The key "hazard" has achieved over 28,000 usages, and it is proposed to
>> formalize usage of the most popular values of this key while deprecating
>> less-popular synonyms.  In addition, this proposes to deprecate
>> protect_class=16 in favor of the hazard key.
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/hazard
>> ___
>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Hazards (frost heave?)

[Adam Franco]

*hazard=frost_heave, hazard=bump?*

One of the common road hazards I encounter and would like to tag are large
frost heaves that occur at consistent locations every year. A few roads in
my region like VT-17 and NY-8 have poor roadbeds and get damaged by frost
heaves the first winter after repaving. These roads often have several
hundred yards of nice smooth and fresh pavement, then 2"-8" frost heaves
with cracks that reappear in the same places year after year.

Some examples:

   - VT-17: section A
   , section B
    (with "BUMP"
   sign), section C
   
   - NY-8: section A
   
,
   section B
   


This has been previously mentioned in an OSMUS Slack thread
 in regard to
smoothness=*, but tagging particularly bad (and often permanent) heaves may
be preferable as other sections of the roadway may be smooth and freshly
paved.

Signage on these tends to be inconsistent, often using phrasing like
"BUMP", "CAUTION: FROST HEAVE", "FROST HEAVE AHEAD", or other similar
phrases. In some locations the signs are permanently mounted, while other
locations get folding signage. As these are point features with varying
placement of signage, I would suggest mapping them as nodes on a roadway at
the heave position with something like hazard=frost_heave. Alternatively,
hazard=bump may be applicable to other situations worldwide for dangerous
bumps caused by something other than freeze/thaw cycles.

Best,
Adam

On Wed, Nov 25, 2020 at 8:27 AM Brian M. Sperlongano 
wrote:

> Comment is requested on the proposal "hazard", which describes hazardous
> or dangerous features.  This tagging was first proposed in 2007, and I have
> adopted the proposal with permission from the original author.  Thanks to
> the various folks that assisted in the development of this proposal prior
> to this RFC.
>
> The key "hazard" has achieved over 28,000 usages, and it is proposed to
> formalize usage of the most popular values of this key while deprecating
> less-popular synonyms.  In addition, this proposes to deprecate
> protect_class=16 in favor of the hazard key.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/hazard
> ___
> 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] Feature Proposal - RFC - Hazards

[Peter Neale via Tagging]

>Date: Fri, 27 Nov 2020 12:08:25 -0500
>From: "Brian M. Sperlongano" 
>To: "Tag discussion, strategy and related tools"
>   
>Subject: Re: [Tagging] Feature Proposal - RFC - Hazards
>Message-ID:
    
>Content-Type: text/plain; charset="utf-8"

>Niels, thanks for the list.

>I was able to find examples and existing tagging for most of the values you
>noted as missing, and I've updated the proposal to add them.  I did already
>have a value listed dangerous intersection (hazard=dangerous_junction, 400
>usages).

>The one you listed that is not clear is the one that you describe as
>"dangerous road edge".  The linked sign looks more like a "soft verge" or
>"soft shoulder" sign, and there are no existing tag values that I can find
>for this type of hazard.  There is a small number of usages of
>hazard=uneven_road, however that sign usually looks something like this:
>https://commons.wikimedia.org/wiki/Traffic_sign#/media/File:1.16_Russian_road_sign.svg

>There is also a small usage of hazard=cliff, which has particularly fun
>signs, notably:
>https://commons.wikimedia.org/wiki/File:Ireland_road_sign_W_160.svg

I thought that was for a harbour, or jetty with no guard rail (rather than a 
cliff).
>https://commons.wikimedia.org/wiki/File:Don%27t_fall_off_the_Cliff!_(16841837743).jpg

I am not sure whether that is to warn a person (at the top of the cliff) that 
they might fall down, or to warn a person on a road or footpath (at the bottom 
of the cliff) that a person might land on top of them!
Peter
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Hazards (mine shaft)

[Brian M. Sperlongano]

It seems to me that there is a clear case for there being both hazardous
and non-hazardous examples of man_made=mineshaft.  The question is how to
tag the ones that are hazardous.

I think the right answer is simply man_made=mineshaft + hazard=yes.  If we
were to approve hazard=open_mineshaft, you create ambiguity as to whether a
mappers could tag ONLY hazard=open_mineshaft and omit the
man_made=mineshaft, which is not desirable.  The hazard=yes tag is intended
to mark features that are already properly described by other tagging, but
indicate that it is also hazardous.

On Fri, Nov 27, 2020 at 8:38 AM ael via Tagging 
wrote:

> On Thu, Nov 26, 2020 at 04:01:09PM -0500, Brian M. Sperlongano wrote:
> > On Thu, Nov 26, 2020 at 3:41 PM ael via Tagging <
> tagging@openstreetmap.org>
> > wrote:
> >
> > > On Thu, Nov 26, 2020 at 09:11:25AM -0500, Brian M. Sperlongano wrote:
> > > > I am not opposed to including unsigned hazards
> > >
> > > There are a surprising number of abandoned open mineshafts in the far
> > > West of England which are a hazard, if not an extreme hazard. Not all
> > > of these are signed or fenced. You might have noticed some of them
> when you
> > > trawled through the existing usage.
> > >
> > > It would be absurd to require such cases to be "signed": those are the
> > > least hazardous by virtual of the signage.
> >
> > Ok, I'm convinced that unsigned hazards are acceptable to be signed!
> >
> > In the case of open mineshafts, there is already an approved tag
> > man_made=mineshaft with 10,000 usage (and a similar de facto tag for
> > horizontal shafts, man_made=adit with 12,000 usages).
>
> A mineshaft is not a hazard if it is properly protected or capped or
> whatever. So there is no need for a hazard tag in the majority of cases.
>
> As a result, the
> > hazard key hasn't really been used for this -- there is a
> > hazard=open_mineshaft with 5 usages, and a single use of
> hazard=mineshaft.
> > I'm not sure if all mine shafts are hazardous or only some of them, but
> in
> > any case, I would think that man_made=mineshaft + hazard=yes would make
> > more sense than a a mineshaft-specific value.
>
> Well, that is better than nothing, but I don't see why a more specific
> value is not useful. The hazard might be toxic effluent coming out of
> a (probably disused) mineshaft. There are even cases where there can be
> toxic fumes as the result of bacterial activity.
>
> For back ground, many of the open mineshafts in Cornwall come from the
> long (even pre-historic) undocumented mining history. Many old shafts
> were capped with timber supports that have since rotted away and shafts
> suddenly appear unexpectedly. Other shafts are covered in undergrowth
> and may have never been capped. Pets and people are regularly rescued
> from such places.
>
> Adits are normally much less hazardous by virtue of being approximately
> horizontal. Of course, if an inexperienced person chooses to enter then
> they may well be exposed to many hazards, and maybe that could be tagged
> as well, but apart from perhaps the risk of  rock fall/collapse, I would
> think tagging underground features is at least problematic in OSM.
>
> ael
>
>
> ___
> 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] Feature Proposal - RFC - Hazards

[Brian M. Sperlongano]

It looks like you're referring to this area:
https://www.openstreetmap.org/query?lat=40.3482=46.5377#map=10/40.3812/46.8347

It seems that this giant border-area polygon was removed recently as it's
only rendered at lower zoom levels.

If the precedent is that military conflict areas are mapped with
landuse=military and possibly also military=danger_area, then it doesn't
sound like there is a need for an additional hazard tag, unless we think
that the type of danger_area needs to be further described by the addition
of a hazard tag.  There does not seem to be any existing usages of the
hazard key that I can find for an active military conflict zone, other than
hazard=minefield.

On Fri, Nov 27, 2020 at 8:28 AM Andy Townsend  wrote:

>
> On 27/11/2020 04:25, Brian M. Sperlongano wrote:
>
> Assuming that the boundary of that area is reasonably permanent, my first
> reaction is that this could be described by military=danger_area.  However,
> that tag requires landuse=military as the primary tag, which probably isn't
> correct here.
>
> On Thu, Nov 26, 2020 at 10:59 PM Graeme Fitzpatrick 
> wrote:
>
>> Not wanting to create a bunfight, but just reading the news, & wondering
>> if this sort of thing should be tagged as a hazardous area?
>>
>>
>> https://www.abc.net.au/news/2020-11-27/ethiopia-to-launch-final-phase-of-offensive-in-tigray-region/12926606
>>
>>
> Yes, there are precedents for having that sort of thing in OSM as military
> areas of some sort - have a look at how the frontline in the recent
> Azerbaijan / Armenia conflict was mapped over the last few months.
>
> Best Regards,
>
> Andy
>
>
> ___
> 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] Feature Proposal - RFC - Hazards

[Brian M. Sperlongano]

Niels, thanks for the list.

I was able to find examples and existing tagging for most of the values you
noted as missing, and I've updated the proposal to add them.  I did already
have a value listed dangerous intersection (hazard=dangerous_junction, 400
usages).

The one you listed that is not clear is the one that you describe as
"dangerous road edge".  The linked sign looks more like a "soft verge" or
"soft shoulder" sign, and there are no existing tag values that I can find
for this type of hazard.  There is a small number of usages of
hazard=uneven_road, however that sign usually looks something like this:
https://commons.wikimedia.org/wiki/Traffic_sign#/media/File:1.16_Russian_road_sign.svg

There is also a small usage of hazard=cliff, which has particularly fun
signs, notably:
https://commons.wikimedia.org/wiki/File:Ireland_road_sign_W_160.svg
https://commons.wikimedia.org/wiki/File:Don%27t_fall_off_the_Cliff!_(16841837743).jpg

On Fri, Nov 27, 2020 at 8:06 AM Niels Elgaard Larsen 
wrote:

> På Thu, 26 Nov 2020 09:11:25 -0500
>
>
> I am missing values for:
>
> horse riding:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_47.png
> hazard:animal=horse should only be for wild horses
>
> Crossing bicyclists:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_45.png
>
> Slippery road:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_50.png
> How do we map "slippery when wet"? Or ice?
>
> Loose rocks on the road:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_52.PNG
>
> Dangerous road edge:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_54.png
>
> low airplanes and helicopters:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_82.png
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_83.png
>
> Queue risk:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_44.png
>
> Dangerous intersections
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_85.png
>
> "Brian M. Sperlongano"  skrev:
> >I am not opposed to including unsigned hazards, if that's the
> >consensus.  I was trying to address anticipated concerns about tagging
> >unverifiable things.
>
> It could be verified in other ways. For example official reports based
> on statistics. Or newspaper articles on accidents caused by crossing
> animals on a certain stretch of road.
>
> > For example, someone in a western country
> >tagging a curve hazard on every instance of a bend in the road and not
> >just the signed parts.
>
> I agree. In fact there is not much point in tagging even the signed
> parts.
>
> The reason for those signs is that the driver cannot see road ahead or
> that it is difficult to judge the sharpness from the perspective of a
> car.
> But with a map it can be done. A data consumer is in a better position
> to decide if turns are hazards. When using a navigation system, I can
> look at the screen and judge if the next turn could be a problem.
>
> I could also tell my navigation software which vehicle I am driving and
> it could use that information together with my current position, my
> actual speed and the data on the road ahead to decide if I should be
> alerted.
>
> For the same reason there is also no reason to tag signed hazards for:
>
> Tunnels:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_68.png
>
> Steep inclines/declines:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_69.png
>
> level crossing without gates:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_71.png
>
> bridges that open:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_79.png
>
> Quays without guards:
> https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_80.png
>
> because all those can be inferred from other tags.
>
> >On Thu, Nov 26, 2020, 8:06 AM Yves via Tagging
> > wrote:
> >
> >> And hazards for niche practices (climbing, whitewater sports, ski
> >> touring,...) that are actually mapped in OSM are not generally
> >> signposted or 'official'.
> >> Maybe we can't expect this proposal to cover them, but you can't
> >> prevent users to use the tag hazard to map them.
> >> Yves
> >>
> >> Le 26 novembre 2020 10:10:45 GMT+01:00, Martin Koppenhoefer <
> >> dieterdre...@gmail.com> a écrit :
> >>>
> >>> Am Do., 26. Nov. 2020 um 08:25 Uhr schrieb Mateusz Konieczny via
> >>> Tagging < tagging@openstreetmap.org>:
> >>>
> 
> - It is not explicitly mentioned, but it would be a good idea to
> have explicit mention
> - is it OK to tag hazard that
> -
> - - exists
> - - is unsigned
> - - government has not declared that it exists (maybe
>  government is dysfunctional/missing like
> - in Somalia, or it is covering-up the problem, or it has higher
> priorities - for example during war)
> 
> 
> >>>
> >>> +1. This may also depend on the context. The same kind of hazard on
> >>> a road may well be signposted, but not 

Re: [Tagging] Feature Proposal - RFC - Hazards (mine shaft)

[ael via Tagging]

On Thu, Nov 26, 2020 at 04:01:09PM -0500, Brian M. Sperlongano wrote:
> On Thu, Nov 26, 2020 at 3:41 PM ael via Tagging 
> wrote:
> 
> > On Thu, Nov 26, 2020 at 09:11:25AM -0500, Brian M. Sperlongano wrote:
> > > I am not opposed to including unsigned hazards
> >
> > There are a surprising number of abandoned open mineshafts in the far
> > West of England which are a hazard, if not an extreme hazard. Not all
> > of these are signed or fenced. You might have noticed some of them when you
> > trawled through the existing usage.
> >
> > It would be absurd to require such cases to be "signed": those are the
> > least hazardous by virtual of the signage.
> 
> Ok, I'm convinced that unsigned hazards are acceptable to be signed!
> 
> In the case of open mineshafts, there is already an approved tag
> man_made=mineshaft with 10,000 usage (and a similar de facto tag for
> horizontal shafts, man_made=adit with 12,000 usages).

A mineshaft is not a hazard if it is properly protected or capped or
whatever. So there is no need for a hazard tag in the majority of cases.

As a result, the
> hazard key hasn't really been used for this -- there is a
> hazard=open_mineshaft with 5 usages, and a single use of hazard=mineshaft.
> I'm not sure if all mine shafts are hazardous or only some of them, but in
> any case, I would think that man_made=mineshaft + hazard=yes would make
> more sense than a a mineshaft-specific value.

Well, that is better than nothing, but I don't see why a more specific
value is not useful. The hazard might be toxic effluent coming out of
a (probably disused) mineshaft. There are even cases where there can be
toxic fumes as the result of bacterial activity.

For back ground, many of the open mineshafts in Cornwall come from the
long (even pre-historic) undocumented mining history. Many old shafts
were capped with timber supports that have since rotted away and shafts
suddenly appear unexpectedly. Other shafts are covered in undergrowth
and may have never been capped. Pets and people are regularly rescued
from such places.

Adits are normally much less hazardous by virtue of being approximately
horizontal. Of course, if an inexperienced person chooses to enter then
they may well be exposed to many hazards, and maybe that could be tagged
as well, but apart from perhaps the risk of  rock fall/collapse, I would
think tagging underground features is at least problematic in OSM.

ael


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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Andy Townsend]

On 27/11/2020 04:25, Brian M. Sperlongano wrote:
Assuming that the boundary of that area is reasonably permanent, my 
first reaction is that this could be described by 
military=danger_area.  However, that tag requires landuse=military as 
the primary tag, which probably isn't correct here.


On Thu, Nov 26, 2020 at 10:59 PM Graeme Fitzpatrick 
mailto:graemefi...@gmail.com>> wrote:


Not wanting to create a bunfight, but just reading the news, &
wondering if this sort of thing should be tagged as a hazardous area?


https://www.abc.net.au/news/2020-11-27/ethiopia-to-launch-final-phase-of-offensive-in-tigray-region/12926606





Yes, there are precedents for having that sort of thing in OSM as 
military areas of some sort - have a look at how the frontline in the 
recent Azerbaijan / Armenia conflict was mapped over the last few months.


Best Regards,

Andy


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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Niels Elgaard Larsen]

På Thu, 26 Nov 2020 09:11:25 -0500


I am missing values for:

horse riding:
https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_47.png
hazard:animal=horse should only be for wild horses

Crossing bicyclists:
https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_45.png

Slippery road:
https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_50.png
How do we map "slippery when wet"? Or ice?

Loose rocks on the road:
https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_52.PNG

Dangerous road edge:
https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_54.png

low airplanes and helicopters:
https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_82.png
https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_83.png

Queue risk:
https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_44.png

Dangerous intersections
https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_85.png

"Brian M. Sperlongano"  skrev:
>I am not opposed to including unsigned hazards, if that's the
>consensus.  I was trying to address anticipated concerns about tagging
>unverifiable things.

It could be verified in other ways. For example official reports based
on statistics. Or newspaper articles on accidents caused by crossing
animals on a certain stretch of road.

> For example, someone in a western country
>tagging a curve hazard on every instance of a bend in the road and not
>just the signed parts.

I agree. In fact there is not much point in tagging even the signed
parts.

The reason for those signs is that the driver cannot see road ahead or
that it is difficult to judge the sharpness from the perspective of a
car.
But with a map it can be done. A data consumer is in a better position
to decide if turns are hazards. When using a navigation system, I can
look at the screen and judge if the next turn could be a problem.

I could also tell my navigation software which vehicle I am driving and
it could use that information together with my current position, my
actual speed and the data on the road ahead to decide if I should be
alerted.

For the same reason there is also no reason to tag signed hazards for:

Tunnels:
https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_68.png

Steep inclines/declines:
https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_69.png

level crossing without gates:
https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_71.png

bridges that open:
https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_79.png

Quays without guards: 
https://www.retsinformation.dk/image.aspx?id=196668=CX316_8_80.png

because all those can be inferred from other tags.

>On Thu, Nov 26, 2020, 8:06 AM Yves via Tagging
> wrote:
>
>> And hazards for niche practices (climbing, whitewater sports, ski
>> touring,...) that are actually mapped in OSM are not generally
>> signposted or 'official'.
>> Maybe we can't expect this proposal to cover them, but you can't
>> prevent users to use the tag hazard to map them.
>> Yves
>>
>> Le 26 novembre 2020 10:10:45 GMT+01:00, Martin Koppenhoefer <
>> dieterdre...@gmail.com> a écrit :
>>>
>>> Am Do., 26. Nov. 2020 um 08:25 Uhr schrieb Mateusz Konieczny via
>>> Tagging < tagging@openstreetmap.org>:
>>>

- It is not explicitly mentioned, but it would be a good idea to
have explicit mention
- is it OK to tag hazard that
-
- - exists
- - is unsigned
- - government has not declared that it exists (maybe
 government is dysfunctional/missing like
- in Somalia, or it is covering-up the problem, or it has higher
priorities - for example during war)


>>>
>>> +1. This may also depend on the context. The same kind of hazard on
>>> a road may well be signposted, but not on a hiking trail in a
>>> forest.
>>>
>>> Cheers,
>>> Martin
>>>
>> ___
>> 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] Feature Proposal - RFC - Hazards

[Graeme Fitzpatrick]

On Fri, 27 Nov 2020 at 14:28, Brian M. Sperlongano 
wrote:

> Assuming that the boundary of that area is reasonably permanent, my first
> reaction is that this could be described by military=danger_area.  However,
> that tag requires landuse=military as the primary tag, which probably isn't
> correct here.
>

Yeah, it would probably best be described as hazard=conflict_zone or
similar?

Is that something that should be mapped in OSM?

Thanks

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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Brian M. Sperlongano]

Assuming that the boundary of that area is reasonably permanent, my first
reaction is that this could be described by military=danger_area.  However,
that tag requires landuse=military as the primary tag, which probably isn't
correct here.

On Thu, Nov 26, 2020 at 10:59 PM Graeme Fitzpatrick 
wrote:

> Not wanting to create a bunfight, but just reading the news, & wondering
> if this sort of thing should be tagged as a hazardous area?
>
>
> https://www.abc.net.au/news/2020-11-27/ethiopia-to-launch-final-phase-of-offensive-in-tigray-region/12926606
>
> Thanks
>
> Graeme
>
> ___
> 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] Feature Proposal - RFC - Hazards

[Graeme Fitzpatrick]

Not wanting to create a bunfight, but just reading the news, & wondering if
this sort of thing should be tagged as a hazardous area?

https://www.abc.net.au/news/2020-11-27/ethiopia-to-launch-final-phase-of-offensive-in-tigray-region/12926606

Thanks

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

Re: [Tagging] Feature Proposal - RFC - Hazards (mine shaft)

[Paul Allen]

On Thu, 26 Nov 2020 at 21:56, Brian M. Sperlongano 
wrote:

I'm not sure if all mine shafts are hazardous or only some of them, but in
> any case,
>

If the mineshaft is capped in some way, such as a grill, and the cap cannot
be removed without special tools, it's probably safe.  If the mineshaft has
a
sturdy fence preventing access, it's probably safe.  If you can just wander
along and fall down it without realizing it was there, it's probably not
safe.
I suspect the last of those three is the type ael was thinking of.

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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Graeme Fitzpatrick]

On Fri, 27 Nov 2020 at 06:41, ael via Tagging 
wrote:

>
> There are a surprising number of abandoned open mineshafts in the far
> West of England which are a hazard, if not an extreme hazard.


But if it's already (presumably) tagged with =mineshaft (+ =abandoned?),
does it also need to be tagged as a hazard?

Thanks

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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Graeme Fitzpatrick]

Sorry, just read further through the e-mail list & saw that this has
already been covered

Thanks

Graeme


On Fri, 27 Nov 2020 at 08:40, Graeme Fitzpatrick 
wrote:

>
> But if it's already (presumably) tagged with =mineshaft (+ =abandoned?),
> does it also need to be tagged as a hazard?
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Hazards (rock slide etc)

[Brian M. Sperlongano]

It looks like the vast majority of the uses of hazard=erosion is in
Bolivia, where it appears (from overhead imagery) to be used to tag
locations where these dirt roads are near or intersected by intermittent
streams which tend to wash the road out.  Often they are combined with
ford=yes when the stream actually crosses the road.  That seems like it
could be a reasonable thing to tag, and not at all like the various
"falling rocks/landslide/rockslide" variants which are all versions of
"land falling from above".

On Thu, Nov 26, 2020 at 3:05 PM Martin Koppenhoefer 
wrote:

> Am Do., 26. Nov. 2020 um 17:48 Uhr schrieb Brian M. Sperlongano <
> zelonew...@gmail.com>:
>
>>  This is good feedback, and I would potentially toss another into the
>> mix: hazard=erosion which has about 300 tags.  Do we think these four tags
>> (rock_slide, falling_rocks, landslide, erosion) represent four distinct and
>> separate things that are properly tagged separately?
>>
>>
>
> I would see erosion as the parent category for all of the other 3,
> possibly too generic to get an idea what particularly is happening there.
> I'd rather deprecate it than encourage its use.
>
> Cheers
> Martin
>
> ___
> 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] Feature Proposal - RFC - Hazards (mine shaft)

[Brian M. Sperlongano]

On Thu, Nov 26, 2020 at 3:41 PM ael via Tagging 
wrote:

> On Thu, Nov 26, 2020 at 09:11:25AM -0500, Brian M. Sperlongano wrote:
> > I am not opposed to including unsigned hazards
>
> There are a surprising number of abandoned open mineshafts in the far
> West of England which are a hazard, if not an extreme hazard. Not all
> of these are signed or fenced. You might have noticed some of them when you
> trawled through the existing usage.
>
> It would be absurd to require such cases to be "signed": those are the
> least hazardous by virtual of the signage.


Ok, I'm convinced that unsigned hazards are acceptable to be signed!

In the case of open mineshafts, there is already an approved tag
man_made=mineshaft with 10,000 usage (and a similar de facto tag for
horizontal shafts, man_made=adit with 12,000 usages).  As a result, the
hazard key hasn't really been used for this -- there is a
hazard=open_mineshaft with 5 usages, and a single use of hazard=mineshaft.
I'm not sure if all mine shafts are hazardous or only some of them, but in
any case, I would think that man_made=mineshaft + hazard=yes would make
more sense than a a mineshaft-specific value.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Hazards

[ael via Tagging]

On Thu, Nov 26, 2020 at 09:11:25AM -0500, Brian M. Sperlongano wrote:
> I am not opposed to including unsigned hazards


There are a surprising number of abandoned open mineshafts in the far
West of England which are a hazard, if not an extreme hazard. Not all
of these are signed or fenced. You might have noticed some of them when you
trawled through the existing usage.

It would be absurd to require such cases to be "signed": those are the
least hazardous by virtual of the signage.

ael


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

Re: [Tagging] Feature Proposal - RFC - Hazards (rock slide etc)

[Martin Koppenhoefer]

Am Do., 26. Nov. 2020 um 17:48 Uhr schrieb Brian M. Sperlongano <
zelonew...@gmail.com>:

>  This is good feedback, and I would potentially toss another into the mix:
> hazard=erosion which has about 300 tags.  Do we think these four tags
> (rock_slide, falling_rocks, landslide, erosion) represent four distinct and
> separate things that are properly tagged separately?
>
>

I would see erosion as the parent category for all of the other 3, possibly
too generic to get an idea what particularly is happening there. I'd rather
deprecate it than encourage its use.

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

Re: [Tagging] Feature Proposal - RFC - Hazards (animals)

[Paul Allen]

On Thu, 26 Nov 2020 at 16:40, Brian M. Sperlongano 
wrote:

>
> On Thu, Nov 26, 2020 at 2:25 AM Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org> wrote:
>
>>
>>- Why hazard:animal and hazard:species is needed instead of animal
>>and species?
>>
>> I initially had it as just animal and species as you suggest.  However,
> for hazards along a stretch of road (for example, "moose crossing next 5
> miles"), you would end up tagging a way with animal=moose.  This creates
> ambiguity in the tagging as to whether the road is *for* moose or
> contains a *moose hazard*.  Thus, I invented hazard:animal to explicitly
> draw a distinction.
>

Good point.  A section of way is a moose hazard because a moose might wander
into the road and damage your car.  A different section of way is a child
hazard
because a child might wander into the road and damage your car.

There was me thinking that the hazard was to the child and that the warnings
should be made clear to the child, but the hazard is to the car and and
children
killed are just more roadkill to be disposed of.

More seriously, I don't think the children crossing case should be handled
the
same way.

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

Re: [Tagging] Feature Proposal - RFC - Hazards (rock slide etc)

[Brian M. Sperlongano]

>
>
>- The use of hazard =
>rock_slide
>
> 
>is more popular than several alternatives,
>- which are essentially describing the same thing: a hazard where
>rocks, earth, or mud might fall from above.
>-
>- There is a big difference between rock slide, failing rocks and
>landslide.
>-
>- I do not thing that deprecation of failing_rocks and landslide is a
>good idea,
>- I would keep them (I have seen signposted sign about landslide
>exactly once,
>- many, many signs of failing rocks - tagging rock_slide for either of
>them would
>- be incorrect).
>
>  This is good feedback, and I would potentially toss another into the mix:
hazard=erosion which has about 300 tags.  Do we think these four tags
(rock_slide, falling_rocks, landslide, erosion) represent four distinct and
separate things that are properly tagged separately?  I can see erosion
being "the ground may fall from under you at the cliff's edge" but the
others sounded like "the ground may fall from above".

The signs that I have found for landslide look exactly the same,
pictorally, as falling rocks, although I have found some with the actual
words "landslide".  It would be helpful someone can offer this flat-lander
examples where there are clear signage differences between these, or offer
clear definition differences between these values - especially if we go in
the direction of tagging unsigned hazards also.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Hazards (animals)

[Brian M. Sperlongano]

On Thu, Nov 26, 2020 at 2:25 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>- Why hazard:animal and hazard:species is needed instead of animal and
>species?
>
> I initially had it as just animal and species as you suggest.  However,
for hazards along a stretch of road (for example, "moose crossing next 5
miles"), you would end up tagging a way with animal=moose.  This creates
ambiguity in the tagging as to whether the road is *for* moose or contains
a *moose hazard*.  Thus, I invented hazard:animal to explicitly draw a
distinction.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Hazards

[Brian M. Sperlongano]

I knew when I started this that it would be impossible to address every
single possible hazard that may exist in the world.  I tried to curate a
list of the most popular hazards that people were actually actually tagging
with the 28,000 existing usages of the hazard key, and that I felt I was
able to adequately understand, describe, and provide examples for.
However, if people believe I'm missing something, I would be more than
happy to add to the list!

On Thu, Nov 26, 2020 at 8:06 AM Yves via Tagging 
wrote:

> And hazards for niche practices (climbing, whitewater sports, ski
> touring,...) that are actually mapped in OSM are not generally signposted
> or 'official'.
> Maybe we can't expect this proposal to cover them, but you can't prevent
> users to use the tag hazard to map them.
> Yves
>
> Le 26 novembre 2020 10:10:45 GMT+01:00, Martin Koppenhoefer <
> dieterdre...@gmail.com> a écrit :
>>
>> Am Do., 26. Nov. 2020 um 08:25 Uhr schrieb Mateusz Konieczny via Tagging <
>> tagging@openstreetmap.org>:
>>
>>>
>>>- It is not explicitly mentioned, but it would be a good idea to
>>>have explicit mention
>>>- is it OK to tag hazard that
>>>-
>>>- - exists
>>>- - is unsigned
>>>- - government has not declared that it exists (maybe government is
>>>dysfunctional/missing like
>>>- in Somalia, or it is covering-up the problem, or it has higher
>>>priorities - for example during war)
>>>
>>>
>>
>> +1. This may also depend on the context. The same kind of hazard on a
>> road may well be signposted, but not on a hiking trail in a forest.
>>
>> Cheers,
>> Martin
>>
> ___
> 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] Feature Proposal - RFC - Hazards

[Brian M. Sperlongano]

I am not opposed to including unsigned hazards, if that's the consensus.  I
was trying to address anticipated concerns about tagging unverifiable
things.  For example, someone in a western country tagging a curve hazard
on every instance of a bend in the road and not just the signed parts.

On Thu, Nov 26, 2020, 8:06 AM Yves via Tagging 
wrote:

> And hazards for niche practices (climbing, whitewater sports, ski
> touring,...) that are actually mapped in OSM are not generally signposted
> or 'official'.
> Maybe we can't expect this proposal to cover them, but you can't prevent
> users to use the tag hazard to map them.
> Yves
>
> Le 26 novembre 2020 10:10:45 GMT+01:00, Martin Koppenhoefer <
> dieterdre...@gmail.com> a écrit :
>>
>> Am Do., 26. Nov. 2020 um 08:25 Uhr schrieb Mateusz Konieczny via Tagging <
>> tagging@openstreetmap.org>:
>>
>>>
>>>- It is not explicitly mentioned, but it would be a good idea to
>>>have explicit mention
>>>- is it OK to tag hazard that
>>>-
>>>- - exists
>>>- - is unsigned
>>>- - government has not declared that it exists (maybe government is
>>>dysfunctional/missing like
>>>- in Somalia, or it is covering-up the problem, or it has higher
>>>priorities - for example during war)
>>>
>>>
>>
>> +1. This may also depend on the context. The same kind of hazard on a
>> road may well be signposted, but not on a hiking trail in a forest.
>>
>> Cheers,
>> Martin
>>
> ___
> 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] Feature Proposal - RFC - Hazards

[Yves via Tagging]

And hazards for niche practices (climbing, whitewater sports, ski touring,...) 
that are actually mapped in OSM are not generally signposted or 'official'.
Maybe we can't expect this proposal to cover them, but you can't prevent users 
to use the tag hazard to map them.
Yves 

Le 26 novembre 2020 10:10:45 GMT+01:00, Martin Koppenhoefer 
 a écrit :
>Am Do., 26. Nov. 2020 um 08:25 Uhr schrieb Mateusz Konieczny via Tagging <
>tagging@openstreetmap.org>:
>
>>
>>- It is not explicitly mentioned, but it would be a good idea to have
>>explicit mention
>>- is it OK to tag hazard that
>>-
>>- - exists
>>- - is unsigned
>>- - government has not declared that it exists (maybe government is
>>dysfunctional/missing like
>>- in Somalia, or it is covering-up the problem, or it has higher
>>priorities - for example during war)
>>
>>
>
>+1. This may also depend on the context. The same kind of hazard on a road
>may well be signposted, but not on a hiking trail in a forest.
>
>Cheers,
>Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Hazards

[Martin Koppenhoefer]

Am Do., 26. Nov. 2020 um 08:25 Uhr schrieb Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

>
>- It is not explicitly mentioned, but it would be a good idea to have
>explicit mention
>- is it OK to tag hazard that
>-
>- - exists
>- - is unsigned
>- - government has not declared that it exists (maybe government is
>dysfunctional/missing like
>- in Somalia, or it is covering-up the problem, or it has higher
>priorities - for example during war)
>
>

+1. This may also depend on the context. The same kind of hazard on a road
may well be signposted, but not on a hiking trail in a forest.

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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Mateusz Konieczny via Tagging]

It is not explicitly mentioned, but it would be a good idea to have explicit 
mention
is it OK to tag hazard that

- exists
- is unsigned
- government has not declared that it exists (maybe government is 
dysfunctional/missing like
in Somalia, or it is covering-up the problem, or it has higher priorities - for 
example during war)

Currently it is implied that it is not taggable, it would be good to have it 
mentioned explicitly.

Why hazard:animal and hazard:species is needed instead of animal and species? 

--

The use of hazard =rock_slide 

 is more popular than several alternatives, 
which are essentially describing the same thing: a hazard where rocks, earth, 
or mud might fall from above.

There is a big difference between rock slide, failing rocks and landslide.

I do not thing that deprecation of failing_rocks and landslide is a good idea,
I would keep them (I have seen signposted sign about landslide exactly once,
many, many signs of failing rocks - tagging rock_slide for either of them would 
be incorrect).

Nov 25, 2020, 14:12 by zelonew...@gmail.com:

> Comment is requested on the proposal "hazard", which describes hazardous or 
> dangerous features.  This tagging was first proposed in 2007, and I have 
> adopted the proposal with permission from the original author.  Thanks to the 
> various folks that assisted in the development of this proposal prior to this 
> RFC.
>
> The key "hazard" has achieved over 28,000 usages, and it is proposed to 
> formalize usage of the most popular values of this key while deprecating 
> less-popular synonyms.  In addition, this proposes to deprecate 
> protect_class=16 in favor of the hazard key.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/hazard
>

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

Re: [Tagging] Feature Proposal - RFC - Hazards

[Graeme Fitzpatrick]

On Wed, 25 Nov 2020 at 23:27, Brian M. Sperlongano 
wrote:

> Comment is requested on the proposal "hazard", which describes hazardous
> or dangerous features.  This tagging was first proposed in 2007, and I have
> adopted the proposal with permission from the original author.  Thanks to
> the various folks that assisted in the development of this proposal prior
> to this RFC.
>

Good work, Brian!

Couple of comments added to the talk page

Thanks

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