Re: [Tagging] Inclined elevators

2020-12-04 Thread Joseph Eisenberg
I agree that the indoor or semi-indoor inclined elevators, which are fully
enclosed and look completely similar to a vertical elevator, should be
tagged as highway=elevator.

Once they are outdoors and there are visible tracks it gets ambiguous.

Since the Montmarte "funicular" is tagged as railway=funicular even though
the pairs cars are now no longer connected to one cable, I think we can
edit the Tag:railway=funicular page to mention that the tag is also used
for similar cable-driven inclined railways which are not technically
funiculars, but looks the same to the non-expert.

-- Joseph Eisenberg

On Fri, Dec 4, 2020 at 3:30 PM Guillaume Chauvat 
wrote:

> Sorry for spamming.
>
> I also think it's fine if the Montmarte funicular is tagged as a
> funicular. But I'm asking because of things that are clearly elevators,
> like this one:
> https://www.alamy.com/stock-photo-tekniska-hgskolan-metro-station-stermalm-district-stockholm-sweden-41948022.html
> . It goes on a path parallel to the escalators, not vertically (I have been
> inside). To me it looks very wrong to call this a funicular. But maybe
> others disagree...
>
> Guillaume
>
> On 2020-12-05 00:07, Clay Smalley wrote:
>
> On Fri, Dec 4, 2020, 5:00 PM Joseph Eisenberg 
> wrote:
>
>> The wiki page text says that a railway=funicular is "A funicular, also
>> known as an inclined plane or cliff railway, is a cable railway in which a
>> cable attached to a pair of tram-like vehicles on rails moves them up and
>> down a steep slope, the ascending and descending vehicles counterbalancing
>> each other.”
>>
>> However, the description in the infobox (which is much more commonly seen
>> in places like taginfo and iD) is only “Cable driven inclined railway” -
>> and this could include many types of "inclined elevators” which mostly run
>> on rails too. So mappers might be using railway=funicular for inclined
>> elevators already.
>>
>
> Indeed they are. For example, here's the Montmartre Funicular in Paris,
> which was historically a true funicular but is now technically a pair of
> inclined elevators: https://www.openstreetmap.org/way/29403578
>
> The distinction between a funicular and an inclined elevator is to me a
> technical one. Many inclined elevators, like the previous example, are
> named as funiculars, and passengers may not even notice that they are on
> one or the other - for all they know, they're just on a vehicle going up
> and down steeply sloped rails.
>
> I'm in favor of tagging inclined elevators as funiculars whenever they may
> resemble one. Perhaps an additional tag like
> railway:funicular=inclined_elevator could be invented for those interested
> in the technical details on how the steep-slope-railway-thing works.
>
> -Clay
>
>>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://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] Inclined elevators

2020-12-04 Thread Clay Smalley
On Fri, Dec 4, 2020, 6:30 PM Guillaume Chauvat  wrote:

> Sorry for spamming.
>
> I also think it's fine if the Montmarte funicular is tagged as a
> funicular. But I'm asking because of things that are clearly elevators,
> like this one:
> https://www.alamy.com/stock-photo-tekniska-hgskolan-metro-station-stermalm-district-stockholm-sweden-41948022.html
> . It goes on a path parallel to the escalators, not vertically (I have been
> inside). To me it looks very wrong to call this a funicular. But maybe
> others disagree...
>

I guess I missed the beginning of the discussion. I agree with you that
this particular inclined elevator doesn't really resemble a funicular and
shouldn't be tagged as such. If it's indoors or operates on demand by a
button press, tagging it as an elevator in some way would be more
appropriate (though I'm still unclear on the best way to do so).

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


Re: [Tagging] Inclined elevators

2020-12-04 Thread Guillaume Chauvat

Sorry for spamming.

I also think it's fine if the Montmarte funicular is tagged as a 
funicular. But I'm asking because of things that are clearly elevators, 
like this one: 
https://www.alamy.com/stock-photo-tekniska-hgskolan-metro-station-stermalm-district-stockholm-sweden-41948022.html 
. It goes on a path parallel to the escalators, not vertically (I have 
been inside). To me it looks very wrong to call this a funicular. But 
maybe others disagree...


Guillaume

On 2020-12-05 00:07, Clay Smalley wrote:
On Fri, Dec 4, 2020, 5:00 PM Joseph Eisenberg 
mailto:joseph.eisenb...@gmail.com>> wrote:


The wiki page text says that a railway=funicular is "A funicular,
also known as an inclined plane or cliff railway, is a cable
railway in which a cable attached to a pair of tram-like vehicles
on rails moves them up and down a steep slope, the ascending and
descending vehicles counterbalancing each other.”

However, the description in the infobox (which is much more
commonly seen in places like taginfo and iD) is only “Cable driven
inclined railway” - and this could include many types of "inclined
elevators” which mostly run on rails too. So mappers might be
using railway=funicular for inclined elevators already.


Indeed they are. For example, here's the Montmartre Funicular in 
Paris, which was historically a true funicular but is now technically 
a pair of inclined elevators: https://www.openstreetmap.org/way/29403578


The distinction between a funicular and an inclined elevator is to me 
a technical one. Many inclined elevators, like the previous example, 
are named as funiculars, and passengers may not even notice that they 
are on one or the other - for all they know, they're just on a vehicle 
going up and down steeply sloped rails.


I'm in favor of tagging inclined elevators as funiculars whenever they 
may resemble one. Perhaps an additional tag like 
railway:funicular=inclined_elevator could be invented for those 
interested in the technical details on how the 
steep-slope-railway-thing works.


-Clay


___
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] Inclined elevators

2020-12-04 Thread Clay Smalley
On Fri, Dec 4, 2020, 5:00 PM Joseph Eisenberg 
wrote:

> The wiki page text says that a railway=funicular is "A funicular, also
> known as an inclined plane or cliff railway, is a cable railway in which a
> cable attached to a pair of tram-like vehicles on rails moves them up and
> down a steep slope, the ascending and descending vehicles counterbalancing
> each other.”
>
> However, the description in the infobox (which is much more commonly seen
> in places like taginfo and iD) is only “Cable driven inclined railway” -
> and this could include many types of "inclined elevators” which mostly run
> on rails too. So mappers might be using railway=funicular for inclined
> elevators already.
>

Indeed they are. For example, here's the Montmartre Funicular in Paris,
which was historically a true funicular but is now technically a pair of
inclined elevators: https://www.openstreetmap.org/way/29403578

The distinction between a funicular and an inclined elevator is to me a
technical one. Many inclined elevators, like the previous example, are
named as funiculars, and passengers may not even notice that they are on
one or the other - for all they know, they're just on a vehicle going up
and down steeply sloped rails.

I'm in favor of tagging inclined elevators as funiculars whenever they may
resemble one. Perhaps an additional tag like
railway:funicular=inclined_elevator could be invented for those interested
in the technical details on how the steep-slope-railway-thing works.

-Clay

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


Re: [Tagging] Inclined elevators

2020-12-04 Thread Guillaume Chauvat
My main issue with this is not technical details about how they work, 
but about how they are used. They look like an elevator, act like one 
and serve exactly the same purpose. You press a button, they come, the 
doors open, you press a button inside to go up or down, etc.

They are used on relatively short distances, often alongside escalators.
Funiculars to me look more like trains, and have a different 
connotation: something you have to buy a ticket for, that go longer 
distances, etc. In the end it's a common issue with categories being 
inherently fuzzy and we have to draw a distinction somewhere.


I would have no problem if the wiki instructed to model inclined 
elevators as funiculars even if it might not be technically correct.
But it isn't: 
https://wiki.openstreetmap.org/wiki/Tag:highway%3Delevator#How_to_Map_as_a_Way 
(and this page is also referenced from the funicular page) so there is 
an ambiguity.
How do I tag the inclined elevator close to where I live? With 
highway=elevator, as stated on the wiki and which seems more technically 
correct? But then the maps don't display it and it's typically not 
included in navigation software. Or do I tag it as a funicular because 
at least it will be displayed on maps, even though it's technically 
wrong and goes against the wiki?


This also creates a chicken an egg problem. Mappers don't use 
highway=elevator because it's not supported, and then developers may 
refuse to consider it because it's not commonly used...



Guillaume


On 2020-12-04 22:58, Joseph Eisenberg wrote:

I've looked into these.

Most inclined elevators seem to also operate with cables, with the 
difference being that in a funicular there are 2 cars attached to 1 
cable, so one ascends while the other descends, but in an inclined 
elevator each car (or there might only be 1 car) is attached to a 
counterweight or a winch.


Unfortunately it looks like most uses of the tag highway=elevator on a 
way are actually areas (closed ways):
https://overpass-turbo.eu/s/10S8 - 3080 highway=elevator ways are 
closed. A review of a few of these suggests they are mostly 4 node 
rectangular ways which represent the area of a verticle elevator. 
About half are tagged |indoor=room| - https://overpass-turbo.eu/s/10Se

vs
https://overpass-turbo.eu/s/10S9 - 190 ways which are not closed. 
These look to be inclined elevators, though in some cases it’s not 
possible to tell if they might actually be a funicular instead.


While railway=funicular is 10 times as common, this might or might not 
represent the actual relative frequency of these features in the real 
world, I don’t know.


The wiki page text says that a railway=funicular is "A funicular, also 
known as an inclined plane or cliff railway, is a cable railway in 
which a cable attached to a pair of tram-like vehicles on rails moves 
them up and down a steep slope, the ascending and descending vehicles 
counterbalancing each other.”


However, the description in the infobox (which is much more commonly 
seen in places like taginfo and iD) is only “Cable driven inclined 
railway” - and this could include many types of "inclined elevators” 
which mostly run on rails too. So mappers might be using 
railway=funicular for inclined elevators already.



-- Joseph Eisenberg


On Thu, Dec 3, 2020 at 2:55 PM Graeme Fitzpatrick 
mailto:graemefi...@gmail.com>> wrote:




On Fri, 4 Dec 2020 at 08:33, Guillaume Chauvat
mailto:guilla...@chauvat.eu>> wrote:

Yes, but this is a node, not a way. Inclined elevators require
a way and those are not displayed properly.


Sorry, didn't get what you were getting at!

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


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


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

2020-12-04 Thread 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] Inclined elevators

2020-12-04 Thread Joseph Eisenberg
I've looked into these.

Most inclined elevators seem to also operate with cables, with the
difference being that in a funicular there are 2 cars attached to 1 cable,
so one ascends while the other descends, but in an inclined elevator each
car (or there might only be 1 car) is attached to a counterweight or a
winch.

Unfortunately it looks like most uses of the tag highway=elevator on a way
are actually areas (closed ways):
https://overpass-turbo.eu/s/10S8 - 3080 highway=elevator ways are closed. A
review of a few of these suggests they are mostly 4 node rectangular ways
which represent the area of a verticle elevator. About half are tagged
indoor=room - https://overpass-turbo.eu/s/10Se
vs
https://overpass-turbo.eu/s/10S9 - 190 ways which are not closed. These
look to be inclined elevators, though in some cases it’s not possible to
tell if they might actually be a funicular instead.

While railway=funicular is 10 times as common, this might or might not
represent the actual relative frequency of these features in the real
world, I don’t know.

The wiki page text says that a railway=funicular is "A funicular, also
known as an inclined plane or cliff railway, is a cable railway in which a
cable attached to a pair of tram-like vehicles on rails moves them up and
down a steep slope, the ascending and descending vehicles counterbalancing
each other.”

However, the description in the infobox (which is much more commonly seen
in places like taginfo and iD) is only “Cable driven inclined railway” -
and this could include many types of "inclined elevators” which mostly run
on rails too. So mappers might be using railway=funicular for inclined
elevators already.


-- Joseph Eisenberg

On Thu, Dec 3, 2020 at 2:55 PM Graeme Fitzpatrick 
wrote:

>
>
> On Fri, 4 Dec 2020 at 08:33, Guillaume Chauvat 
> wrote:
>
>> Yes, but this is a node, not a way. Inclined elevators require a way and
>> those are not displayed properly.
>>
>
> Sorry, didn't get what you were getting at!
>
> 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

2020-12-04 Thread 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

2020-12-04 Thread 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?)

2020-12-04 Thread 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?)

2020-12-04 Thread 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?)

2020-12-04 Thread 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

2020-12-04 Thread 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

2020-12-04 Thread 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

2020-12-04 Thread 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

2020-12-04 Thread 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] RFC Update - Hazard Proposal - rock/land fall/slide

2020-12-04 Thread Kevin Kenny
On Thu, Dec 3, 2020 at 8:50 PM Brian M. Sperlongano 
wrote:

> I poked into the existing usages of hazard=landslide, and they seem to
> mostly be on hiking trails or at best track roads, rather than regular
> roads.  I don't think anyone would quibble with tagging a landslide hazard
> on this [1] for example.
>
> [1] https://commons.wikimedia.org/wiki/File:Landslide_area.JPG
>

I think that https://www.flickr.com/photos/ke9tv/50114553127 might have
similar signage on the trail that runs on the canyon rim - warning people
who might want to head out to the edge for a photo.  There's no signage at
river level, but I'd still give the slope a wide berth when hiking in
winter or heavy rain. (In better weather, all that scree makes for an easy
ford, and in fact I'd just crossed dry-shod when I turned back to snap
the picture.) In any case, I don't think there would be much controversy
that the hazard exists, signed or not - and probably ought to be indicated.
The place is close to the city of Schenectady, and many people come out
unprepared for the conditions. Technical rescues are common, and every few
years someone suffers a fatal fall or drowns.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2020-12-04 Thread 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