Proposal talk:Hazard
Discussion Archives
- Archive #1: Discussion from the original proposal.
2007 Proposal Discussion
cycle_hazard
Just a heads-up that I've been using cycle_hazard=* for dangers to cyclists (such sidepaths where you have to watch for turning traffic). --NE2 07:59, 3 August 2010 (BST)
Refining the classification
At only 387 uses, yet with the most used value having been used only 17 times, this could do with some generalization. Looking at the values, and keeping in mind the different traffic signs that are classified under "hazard warnings" (literally, the triangles pointing up), I would start with these:
- warnings of natural features, as signposted: not only animals such as moose , deer
, cows 
, sheep and so on, but also falling rocks. - warnings of natural hazards that aren't signposted: "bees", "angry goose", "ticks", "nettles"
- warnings of unexpected road users, or of them crossing the road: skiers, cyclists
, children 
, pedestrians 
- lane arrangements or other road construction "failures" that can present a situation where the driver has little time to react, but has to; these include
- short, or missing acceleration lanes (might be signposted, but doesn't need to be)
- lanes ending unexpectedly after a corner/curve
- tight curves, where it limits the practical speed possible, yet where one would normally drive, or want to drive, at the speed limit; not only acceleration lanes/links where one can't accelerate beforehand, but also some (rural) highways, or even some offramps. Often signposted, but not always. Sometimes with
or similar, sometimes with the 
- Other signposted warnings of road condition: slippery road, bumps (which aren't traffic_calming), narrow parts (which aren't traffic_calming).
- Other signposted warnings of traffic: queues (likely), ?
- poor visibility; places where driving at the the speed limit, or at a reasonable speed (for example on a cycleway), one would see any possible crossing traffic with little or no time to react; think pedestrian/cyclists underpasses with a blind corner. Later some objective line of sight requirements could be reasoned to make it more objective.
,_StVO_1992.svg){kind=small}
,_StVO_1992.svg){kind=small}
,_500x1500,_StVO_1992.svg){kind=small}
The fact that railway crossings are signposted, doesn't make them a special hazard - it's evident from the railway=crossing tag. Such a railway crossing can have poor visibility, though. This would just be way to categorize these, and freeform values could (naturally!) still be used. Any thoughts? Alv 11:17, 7 March 2011 (UTC)
Subdivision of the hazard namespace
To me it would come naturally to subdivide the namespace as follows for different users of the road:
- hazard:general=
- hazard:pedestrian=
- hazard:motor_vehicle=
- hazard:bicycle=
- etc.
(This could absorb 1:1 the existing cycle_hazard tagging)
The main reason for such a subdivision is obviously that the hazards for the different users are different.
Then it would also make sense to indicate whether a hazard is signposted or not. The position of the danger signs is often different form the position of the hazard itself, so I am not sure whether the danger signposts are sufficient. -- User:Voschix
- Nice idea, but I'd rather use hazard=* than hazard:general=* --Dieterdreist (talk) 11:06, 10 March 2015 (UTC)
hazard=ammunition
There are a lot of areas with former military training grounds. There are often warning signs not to enter this are because of old ammunition (http://www.google.de/imgres?imgurl=http%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2Fb%2Fb9%2FSchild_Munitionsbelastung_Peenem%2525C3%2525BCnde.JPG&imgrefurl=http%3A%2F%2Fcommons.wikimedia.org%2Fwiki%2FFile%3ASchild_Munitionsbelastung_Peenem%25C3%25BCnde.JPG&h=3240&w=4320&tbnid=DxYa-_fo81kQXM%3A&zoom=1&docid=KbZp0PRjjck4zM&ei=X1UYVeDCOs3qONrBgJgN&tbm=isch&iact=rc&uact=3&dur=335&page=1&start=0&ndsp=9&ved=0CCAQrQMwAA) I think this would be useful to have this in the proposal.
hazard=wind
for traffic sign like this 
may be add hazard=wind? i don't find a better tag inf the wiki
hazard=side_winds seems to be in use. Rafmar (talk) 12:41, 12 April 2015 (UTC)
General hazard
How about defining a tag for a general hazard like <hazard=yes> that can be combined with a tag like <description=text> or <hazard:description=text> to add human-readable text that describes the specific hazard? This would be helpful for situations that are not covered by the pre-defined values for the tag <hazard=*>. Eventually, when a sufficient number of similar hazard situations has been tagged, a new value for <hazard=*> and a corresponding symbol can be defined. --Biff (talk) 23:25, 18 May 2016 (UTC)
- I agree that it should exist a general tag for those kind of places and hazards that are not defined here. For example, a cave entrace has no signage (most of the times) but it could be tagged with hazard=yes when a more specific tag isn't available. --AntMadeira (talk) 19:28, 25 February 2021 (UTC)
ISO 7010
An international standard for safety signs exists and provides quite a lot of symbols that warn of hazards that are not yet described in the proposal and that are not covered by normal road signs. Below is a table with all hazards and their symbols from ISO 7010. I suppose that these symbols can be helpful but that not all of them will be needed. If some of the symbols are not shown then they are not yet available on Wikimedia Commons and can instead be found here.--Biff (talk) 01:43, 19 May 2016 (UTC)
| Hazard | Symbol |
|---|---|
| Generic warning | 
|
| Explosive material | 
|
| Radioactive material or ionizing radiation | 
|
| Laser beam | 
|
| Non-ionizing radiation | 
|
| Magnetic field | 
|
| Floor level obstacle | 
|
| Drop (fall) | 
|
| Biological hazard | 
|
| Low temperature / freezing conditions | 
|
| Slippery surface | 
|
| Electricity | 
|
| Guard dog | 
|
| Fork lift trucks and other industrial vehicles | 
|
| Overhead load | 
|
| Toxic material | 
|
| Hot surface | 
|
| Automatic start-up | 
|
| Crushing | 
|
| Overhead obstacles | 
|
| Flammable materials | 
|
| Sharp elements | 
|
| Corrosive substance | 
|
| Crushing of hands | 
|
| Counter rotating rollers | 
|
| Battery charging | 
|
| Optical radiation | 
|
| Oxidizing substance | 
|
| Pressurized cylinder | 
|
| (Hazards of press brake tools) |  File:ISO 7010 W031.svgFile:ISO 7010 W032.svg
|
| Barbed wire | File:ISO 7010 W033.svg |
| Beware of bull | File:ISO 7010 W034.svg |
| Falling objects | 
|
| Fragile roof | File:ISO 7010 W036.svg |
| Run over by remote operator controlled machine | File:ISO 7010 W037.svg |
| Sudden loud noise | File:ISO 7010 W038.svg |
| Falling ice | 
|
| Roof avalanche | File:ISO 7010 W040.svg |
| Asphyxiating atmosphere | File:ISO 7010 W041.svg |
Railway hazards
Here are some examples of hazards that may be present at railway stations:
slope in platform: fasten brakes of baby carriages, wheeled luggage and wheelchairs
beware of passing trains
.jpg)
--Biff (talk) 10:15, 2 June 2016 (UTC)
- Oh yes you are right, but concerning the second picture, something like hazard=passing_trains we could add nearly to all way tagged railway=platform. This sign is a bit too generic for me or it should be an implicit hazard. If we go it like this, we would have to add a hazard also to all recycling_type=centres because every container there has a sign that is warning of falling into the container. And many many other things like this. A hazard can go out from everything, and for me some signs might be useful, but cover too many situations. The thing with the gradient of a platform would be a single hazard and the difference is that you would not be aware of implicitly, so I think this is more what hazard=* as a map feature should mean. --Lukas458 (talk) 14:32, 6 May 2020 (UTC)
Flood danger areas directly downstream of dams
TAIPEI (Taiwan News) — Three campers were killed and one went missing when their tents were swept away by a river after a sluice gate accidentally opened at a dam upstream…
Taiwan Power Company (Taipower), which manages the dam, confirmed in a news release on Sunday that Water Gate No. 6 of the upstream Wujie Dam accidentally opened at 4:12 a.m. and again at 5:08 a.m. Taipower said that it will look into the cause and urged the public to observe the signs and stay out of the dry riverbed, as the upstream dam can release water at any time.[1]
See also
- https://www.damsafety.in/ecm-includes/PDFs/Guidelines_for_Mapping_Flood_Risks_Associated_with_Dams.pdf
- https://sciencing.com/flood-formed-6296881.html#I0_1600094340031:~:text=Flooding%20at%20Dams,can%20be%20man%2Dmade%20structures%2C%20or%20can
- https://www.lrh.usace.army.mil/Portals/38/docs/civil%20works/Living%20With%20Dams.pdf
- https://en.wikipedia.org/wiki/Spillway#Safety
- Tag:usage=spillway
Jidanni (talk) 14:51, 14 September 2020 (UTC)
2020 Revival
I have contacted User:Esper and he has graciously granted me permission to adopt this proposal. I look forward to hopefully bringing this proposal to the finish line! --ZeLonewolf (talk) 23:23, 6 November 2020 (UTC)
Animal crossings as road segments
Resolved: The scheme of hazard:animal=* or hazard:species=* is reflected in the proposal. --ZeLonewolf (talk) 04:11, 7 December 2020 (UTC)The proposal currently recommends tagging animal crossing hazards as nodes, presumably on the roadway as well as on the traffic_sign=*. This may make sense for a farm animal like a 
cow or a small animal like a duck (near a pond). However, a 
moose crossing sign doesn't necessarily mean moose will cross at exactly the location of the sign. It's more accurate to tag a segment of the roadway that extends to the crossing signs on either side of the road (which can be hundreds of feet apart or more for some wild animals). But it would be awkward to tag roadways with animal=*. Can we use a syntax like hazard=crossing:moose (reminiscent of surface=* tags) or a namespaced key like hazard:crossing=* or hazard:animal=*? – Minh Nguyễn 💬 01:29, 18 November 2020 (UTC)
- I agree about your point about nodes versus ways - that's how I've got it listed, both
and 
.
- I took a look at the current usages of hazard=animal_crossing and similar tags, and here are some approaches that mappers have used:
- Is one of these a more standard approach than the others? --ZeLonewolf (talk) 01:51, 18 November 2020 (UTC)
- animal_crossing=* would be an example of iterative refinement, while hazard:animal=* would be an example of namespaces. The former is simpler but the latter is more flexible in case there's eventually a need to say more about the animal crossing beyond the species. hazard:species=* would be maximally flexible, but unlike tree and zoo mappers, road mappers are less familiar with binomial nomenclature, so editor conveniences would become critical to adoption. Perhaps the proposal could at least offer hazard:animal=* as an optional alternative to hazard:species=*? – Minh Nguyễn 💬 16:33, 18 November 2020 (UTC)
- the go-to guy for stuff related to this ought to be Florian (aka panneaubiche) :-). A couple of comments: as Minh says there's a big difference between a toad crossing warning and moose/elk (en-us/en-gb) warnings. In the former case the point is an actual crossing (usually an anceitne migratory route which the road crosse), whereas in the latter it merely indicates a higher likelihood of encountering animals on that section of the road. The hazards are slightly different too: danger of killing vulnerable creatures versus danger of a collision which may damage you & your vehicle as well as the unfortunate animal. For the latter typical signs will have a distance panel (e.g., for the next 3.5 km), and there may be repeaters. I've found a big reason to map the signs is that it's often difficult to tell exactly the part of road which is intended, and I dont think there's any/much usage of a sign marking the end of the hazardous section (other than trying to see signs for the opposite direction in ones rear-view mirror). So I'd agree that it's probably worth distinguishing these two types and I also agree that it make sense, **once one has adequate data**, to assign the tag to road segments. One other minor point is to avoid confusion with man_made=wildlife_crossing which refers to bridges, tunnels & other structures designed to allow wildlife to paas across a highway safely. SK53 (talk) 18:49, 18 November 2020 (UTC)
- Very helpful! I've made some updates to incorporate the animal/species tagging, clarify man_made=wildlife_crossing, and clarify tagging of signs versus highway segments. Beyond tagging a way versus a node, is there any other distinction that should be made between the two variants of a signed hazard? --ZeLonewolf (talk) 19:32, 18 November 2020 (UTC)
The way we often see the signs is either just as "Wildlife" or as an animal symbol eg a kangaroo, together with "Next "4" km" Fizzie41 (talk) 22:13, 25 November 2020 (UTC)
MUTCD warnings
Resolved: The signs and discussion below are reflected in the proposal, with the exception of school crossing, which I've removed in order to keep a clean line of separation with highway=crossing. --ZeLonewolf (talk) 04:09, 7 December 2020 (UTC)I compiled a field guide of MUTCD warning signs that are standard across the U.S., along with the most popular tags to represent them so far. I consider it a draft, since many of the tags are ad-hoc usage. In particular, it ends up making extensive use of hazard=* values that this proposal would deprecate. I'm generally in favor of the changes proposed here. However, the MUTCD does make some distinctions that aren't reflected either in current tagging or this proposal, for example:
- A
turn versus a 
curve - One versus
two versus 
multiple curves - A slight turn versus a
hairpin turn versus a 
270° turn
It would be great if the proposal could accommodate these distinctions, even if some other countries may not signpost them.
– Minh Nguyễn 💬 10:50, 19 November 2020 (UTC)
- Recently I thought about that. Really depends on whether direction of turn (I see you haven't written about the side variants), reverse curve, etc, warrants tagging at this level. Also, whether it is realistic to expect software or users to realize which side/direction this will be happening. ---- Kovposch (talk) 15:05, 19 November 2020 (UTC)
- What do you think about adding hazard:curve=* to further describe the type of curve? That would be an optional add-on tag if someone wants to map the specific signed curve warning. Perhaps:
- And
- --ZeLonewolf (talk) 20:14, 19 November 2020 (UTC)
I figure that one of the two use cases for hazard tagging (other than influencing routing) would be rendering signs. To ensure intuitiveness, the signs would have to more or less match the sign standard. I don't think it would be easy to come up with a sign design that would simultaneously be faithful enough to the sign standard to be recognizable but at the same time be generic enough to cover all the kinds of curves above. So hazard=curve would be of little use on its own, even if we call hazard:curve=* optional.
Most instances of curve and turn signs are on two-way roads, in which case you'd have to tag hazard:curve:direction:forward=left with hazard:curve:direction:backward=right. But the direction should be so evident to a data consumer that I'd hesitate to make that any kind of requirement. I find the other distinctions above to be more interesting, because it isn't as straightforward for a data consumer to tell that there should be an advisory speed of 30 mph (in the event of a missing maxspeed:advisory=* tag), or that multiple curves are separated by a tangent distance of 600 feet (given all kinds of imprecision when mapping in rugged terrain from aerial imagery), or that the turn is more than 135 degrees (since the way may be split arbitrarily for reasons unrelated to hazards or road geometry).
– Minh Nguyễn 💬 22:40, 20 November 2020 (UTC)
- Thanks for this feedback - I've made substantial edits which should hopefully address the concerns! --ZeLonewolf (talk) 04:22, 21 November 2020 (UTC)
Thanks, I think this is definitely an improvement, and I appreciate the work you've put into accommodating both the MUTCD and other schemes around the world. A few things that come to mind for me, having recently compiled MUTCD/W and MUTCD/S:
- The only distinction between what the MUTCD calls a
reverse turn and a 
reverse curve is the sharpness of the curve. In both cases, it's a series of two curves that more or less cancel out each other. I think they would have similar tagging, such as hazard=curves curves=2 and hazard=dangerous_turn turns=2. 
indicates an indeterminate number of curves, so something non-numeric like "extended" is sensible, if not immediately discoverable, since a mapper may not be able to tell how many curves the sign is referring to just looking at a single street-level image. - A
school zone may contain multiple 
school crossings, but the proposal currently would conflate the two concepts. A school zone is worth keeping distinct because it would correspond with a lower (possibly variable) speed limit. - I've been assuming that hazard=dangerous_junction corresponds to any of the signs in series W2. Not all of them can be represented by a single point. It's common for an
intersection warning to come with an advisory speed, in which case the road would be tagged with both hazard=* and maxspeed:advisory=* from this sign to the identical sign on the other side of the intersection. - A generic traffic_sign=hazard tag is a good idea as a catch-all. However, I think it should remain valid to tag that more specific code in traffic_sign=* if known, for instance
traffic_sign=US:W2-2L or 
traffic_sign=US:OH:W11-14a.
– Minh Nguyễn 💬 05:58, 23 November 2020 (UTC)
- Once again, we often have the "snake" sign together with xx km Fizzie41 (talk) 22:21, 25 November 2020 (UTC)
By the way, the goal of deprecating less common tags in favor of more common tags may lead to some inconsistency among the tags that remain. hazard=dangerous_turn is both inconsistent with hazard=curve and also redundant, since "hazard" implies a danger. Since this is the first time the hazard=* key has gone through the proposed features process, I think it would be reasonable to deprecate some tags in favor of less common tags if that makes the overall scheme easier to understand and use. On the other hand, I realize you might not have expected to spend as much time finessing the traffic hazard part of this proposal, and this inconsistency is relatively minor. – Minh Nguyễn 💬 06:03, 23 November 2020 (UTC)
- It is no problem to spend the time that it takes to get it right. I have no interest in putting out a half-arsed proposal. With regard to "turn" and "junction":
- hazard=dangerous_turn has 444 usages, and there are no usages of hazard=turn or hazard=turns
- hazard=dangerous_junction has 404 usages, and there are 4 usages of hazard=junction
- Clearly, turn/turns/junction would be more consistent with the way hazard=curve & hazard=curves is specified. Are those 400+ tag counts small enough that it is reasonable to replace them with invented tagging? --ZeLonewolf (talk) 13:37, 23 November 2020 (UTC)
- It is outnumbered by usage of hazard=curve, so in my opinion it's fine to deprecate the "dangerous" tags. But it would be great to hear thoughts from others reading this proposal. – Minh Nguyễn 💬 17:20, 23 November 2020 (UTC)
Narrow/Slippery Hazards
Resolved: The tag hazard=slippery has been added to the proposal! A narrow road hazard may be controversial because there are already tags for describing road width, but I would encourage a discussion of adding a "narrow road" hazard on the mailing list if you feel strongly that it should be included as separate tagging. --ZeLonewolf (talk) 04:19, 7 December 2020 (UTC)Some others we see frequently, that don't appear to be listed, are Narrow Bridge https://en.wikipedia.org/wiki/File:Australia_W4-1.svg, Road Narrows https://en.wikipedia.org/wiki/File:Australia_W4-3.svg & Slippery Road https://en.wikipedia.org/wiki/File:Australia_road_sign_W5-20.svg Fizzie41 (talk) 22:21, 25 November 2020 (UTC)
- The hazards I have listed were based on the most significant tagging that mappers had already used. But, I'm happy to expand to additional values if people feel they are useful. The tags below are good candidates for documentation - appreciate your thoughts on best tagging.
| hazard=road_narrows | hazard=narrow | hazard=slippery | hazard=slippery_road |
|---|---|---|---|
--ZeLonewolf (talk) 22:37, 25 November 2020 (UTC)
hazard=unexploded_ordnance
Resolved: This tag has been added to the proposal. --ZeLonewolf (talk) 01:10, 26 November 2020 (UTC)Requesting to add hazard=unexploded_ordnance to the list (UXO). --Aharvey (talk) 22:41, 25 November 2020 (UTC)
- Great idea! It does not appear that anyone has tried to tag this before, so your proposed tag sounds good to me. Sound like we'll want to couple that with military=danger_area and model it as an
. --ZeLonewolf (talk) 22:57, 25 November 2020 (UTC)
- The danger of UXO isn't restricted to active military areas though. We have areas signposted with "Warning: Unexploded Ammunition", that are actually now National Parks or similar, & even, in some cases, residential areas! eg https://noosatoday.com.au/stories/18-04-2018/noosa-blast-zone/. The same thing will apply anywhere in the world where wars have been fought or troops trained.
- Ah, interesting. Since military=danger_area requires landuse=military, that would be a conflict if it's on top of a landuse=residential. But, would we really tag such an area that has a UXO hazard with landuse=residential? I think you've raised a significant enough point that we should at least allow either style. I will update the proposal to reflect these alternatives. --ZeLonewolf (talk) 23:02, 26 November 2020 (UTC)
school zone
| hazard=school_zone | restriction=school_zone |
|---|---|
We have at least two tags in use currently for school zones. In my opinion they are more a restriction than a hazard, but it's not big of a deal. Ideally we'd just have one approved tag for school zones. --Aharvey (talk) 22:50, 25 November 2020 (UTC)
- Well, since neither seems to be approved, looks like we need to pick one. I'm open to dropping this value from the proposal if there are objections to this usage, or keeping it and deprecating the other one if it belongs here. --ZeLonewolf (talk) 23:03, 25 November 2020 (UTC)
- On review of Relation:restriction, it does not sounds like school_zone fits the definition of restriction (which seems to be, what types of turns are allowed at road nodes). --ZeLonewolf (talk) 03:48, 26 November 2020 (UTC)
explictly mention that existing hazards are not taggable unless signed or official
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.
(also posted on mailing list) Mateusz Konieczny (talk) 08:07, 26 November 2020 (UTC)
- Perhaps language like this:
- "In general, the standard of verifiability suggests that mappers should only tag hazards that are verifiable via explicit signage. However, in some areas of the world, particularly the developing world, hazards are not always signed. In these places, it is acceptable to reasonably tag hazards that are not explicitly signed. In areas where hazards are routinely tagged, such as a hazard=curve sign in a western nation, it would be incorrect, for example, to tag every bend in the road as a curve hazard in the absence of explicit signage."
- --ZeLonewolf (talk) 14:58, 26 November 2020 (UTC)
Is hazard: prefix really needed?
Why hazard:animal=* and hazard:species=* is needed instead of animal=* and species=*? (also posted on tagging mailing list) Mateusz Konieczny (talk) 08:09, 26 November 2020 (UTC)
- That was how I originally had it, also. The issue is that the combination highway=* and animal=* implies a road for animals, so I needed hazard:animal=* in order to make that distinction. --ZeLonewolf (talk) 14:59, 26 November 2020 (UTC)
- See #Animal crossings as road segments. – Minh Nguyễn 💬 10:42, 28 November 2020 (UTC)
failing rocks and rock slide is not the same
Resolved: Based on this and mailing list discussions "falling rocks" and "landslide" are now separate tags. --ZeLonewolf (talk) 04:06, 7 December 2020 (UTC)"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).
(also posted on tagging ML) Mateusz Konieczny (talk) 08:10, 26 November 2020 (UTC)
Frost Heaves?
Resolved: This tag has been added to the proposal! --ZeLonewolf (talk)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:
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.
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.
(Also posting on mailing list) Adamfranco (talk) 19:33, 3 December 2020 (UTC)
- Thanks for the suggestions, I've added both tags! --ZeLonewolf (talk) 21:51, 3 December 2020 (UTC)
Speed bumps
Resolved: The proposal has been clarified to address these concerns.
@ZeLonewolf: According to the U.S. standard, the 
Bump sign is primarily used to warn about an upcoming artificial speed bump, i.e., traffic_calming=bump or traffic_calming=hump. [2] In my experience, 
Rough Road is the most common sign for naturally occurring bumps on the road due to frost or other conditions. The proposal uses File:Wikist aces 0039.jpg to illustrate the use of hazard=bump, but I believe that sign is being used in a standard way to refer to a speed bump or hump.
Is it essential that hazard=bump be used only for naturally occurring bumps? If so, would the roadway between that sign and the bump be tagged only maxspeed:advisory=15 mph with no other tag to indicate why the advisory speed limit applies? In my opinion, hazard=* can be tagged on the roadway independently of the physical traffic calming device also being tagged, because a hazard sign can sometimes be orthogonal to the physical hazard it warns about.
If the intention was to avoid compelling mappers to tag every traffic_calming=bump with hazard=bump, regardless of signage, then I think the proposal can say so while allowing for the same tag to represent signposted speed bumps where that's standard. I hope it isn't too late to resolve this contradiction within the proposal.
– Minh Nguyễn 💬 05:37, 14 December 2020 (UTC)
Cyclists
Resolved: Excellent observations; This change has been made! --ZeLonewolf (talk) 17:20, 6 December 2020 (UTC)| hazard=cyclists | hazard=bicycle |
|---|---|
Why not use hazard=cyclists instead of hazard=bicycle? If there is a good reason for not using hazard=cyclists it should also be marked as deprecated. --Mapper999 (talk) 17:07, 6 December 2020 (UTC)
Pedestrians
Resolved: This tag has been added to the proposal! --ZeLonewolf (talk) 04:05, 7 December 2020 (UTC)| hazard=pedestrians |
|---|
Could you add hazard=pedestrians for places where pedestrians have to share the road? --Mapper999 (talk) 17:07, 6 December 2020 (UTC)
- I like this idea in theory, though I want to be very careful in not creating a duplicate of highway=crossing. Are you aware of examples of this that aren't crosswalks? --ZeLonewolf (talk) 17:24, 6 December 2020 (UTC)
- All of these examples are signposted with German traffic sign Vz133 . These are not general crossing signs in Germany, but they are also often used where pedestrians are frequently crossing the road or crossing pedestrians are unexpected. In many cases there isn't a formal or defined crossing which could be marked as highway=crossing. You could mention in the description, that hazard=pedestrians should not be used for regular crosswalks (highway=crossing). --Mapper999 (talk) 19:35, 6 December 2020 (UTC)
- Non-German example: lake access is on one side of the street, houses are on the other, and you get people just wandering across wherever they want
- --Carnildo (talk) 02:01, 7 December 2020 (UTC)
Tourists
We would quite like to see tourists as a type of hazard for highways - there are some areas of cities where tourists gather (e.g. next to landmarks) in ways which block highways. Currently there is no good way for a router to be aware that caution should take caution. We realise this this is somewhat subjective, given there is no actual signage obviously, but it is likely to be the kind of thing that does get consensus amongst locals who know an area. For instance, in Cambridge, Garret Hostel Bridge and the Benet' Street / King's Parade junction (in both cases, these have very high cycle flows, but caution is needed from gathering groups of tourists, which actively causes delays that should be modelled). In Amsterdam, the red light district, which again converts a standard highway into very slow footways. --CycleStreets 19:12, 24 December 2020 (UTC)
- How does a tourist hazard differ from a pedestrian hazard? --Carnildo (talk) 21:58, 25 December 2020 (UTC)
- I tend to agree that this sounds like a hazard=pedestrian. Is there really a difference from the perspective of a motorist or router as to the exact reason that pedestrians are in the roadway? --ZeLonewolf (talk) 22:11, 25 December 2020 (UTC)
horse_riders -> equestrians
Resolved: Per discussion below.May we please change "horse_riders" to the much more commonly-used term "equestrians"? Thank you. Stevea (talk) 02:21, 7 December 2020 (UTC)
- Below is the current usage of both tags:
| hazard=horse_riders | hazard=equestrian |
|---|---|
- Below is how other horse-related features are tagged:
- horse=yes - "Use this key for mapping access permission for equestrians (people riding horses) on highways/tracks/footpaths"
- leisure=horse_riding - "The tag leisure=horse_riding is used to tag an equestrian facility, often called equestrian centre, riding centre or riding stables, where people practise horse riding, typically in their spare time."
- sport=equestrian - "An equestrian sport is a sport that is practised with the horse as a partner."
- There seems to be a convention for using "horse" to refer to more ordinary horseback riding, while "equestrian" seems to be used for
equestrian sports. Given the other usages, and the initial preference for horse_riders (albeit with a tiny usage of ~40 tags), I'm not sure that equestrian is really the better tag value. --ZeLonewolf (talk) 03:47, 7 December 2020 (UTC)
Orthogonal to physical features
Resolved: The proposal has been clarified to address these concerns.I'm planning to endorse this proposal, because overall it is well thought-out. However, before I do so, I'd like to call attention to the fact that the proposal repeatedly admonishes mappers not to use hazard=* where related tags already exist to represent physical features that may present a hazard. I believe this is problematic because hazard signs often generalize physical hazards: for example, a dangerous intersection sign does not say "there is a dangerous intersection at this very spot"; rather, it says "a dangerous intersection is coming up ahead, so you should slow down [to a given speed]". As I mentioned in #MUTCD warnings and #Speed bumps, these signs may come with advisory speed limits, making it desirable to tag both the signposted hazard and advisory speed limit along the stretch of road between the two opposing hazard signs. #Speed bumps highlights how the existing admonitions are already causing the proposal to contradict itself.
It's perfectly reasonable that the proposal would avoid giving mappers the impression that a hazardous physical feature doesn't necessarily need to be tagged as a hazard in every instance. However, I believe it should be considered acceptable to indicate a hazard redundantly along the affected road segment if mapping the physical feature per se doesn't provide as much information. I think this would be compatible with the general intent of the proposal, but it would be worth clarifying to avoid unfortunate literal readings of the hazard=* page in the years to come. Sorry for coming in during the voting period with these concerns. Hopefully it's possible to address this issue in a nuanced way without undermining the support that the proposal has already received.
– Minh Nguyễn 💬 06:14, 14 December 2020 (UTC)
After vote
FYI, I just found hazard_type=* Mateusz Konieczny (talk) 14:55, 28 December 2020 (UTC)
- Good find, too bad it wasn't noticed until after the proposal and vote. Looks like most of the usage was from 2013 looking at the taginfo chronology. I'll put up a "multiple tagging schemes" template on both page and hopefully it will sort itself out over time. --ZeLonewolf (talk) 15:07, 28 December 2020 (UTC)