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 (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
>>>