Re: [Tagging] tactile_paving=* on highway=steps ?

[Lukas-458]

The advatntage of putting tactile_paving=yes/tactile_paving=yes at the start and at the end of the steps way would also have the advantage, that you can determine whether stair landings (if mapped individually, otherwise create a point within the highway=steps way) also have tactile_paving or not.
However, I have to admit that I've always just put tactile_paving on the steps-way. ID has this also so in its preset.

 
-- Lukas

Gesendet: Donnerstag, 23. Februar 2023 um 16:53 Uhr
Von: "Matija Nalis" 
An: tagging@openstreetmap.org
Betreff: Re: [Tagging] tactile_paving=* on highway=steps ?

On Thu, 23 Feb 2023 12:46:07 +0100, Matija Nalis  wrote:
> Triggered by this StreetComplete quest suggestion:
> https://github.com/streetcomplete/StreetComplete/issues/3534

FYI, it is also being discussed at:

https://wiki.openstreetmap.org/wiki/Talk:Key:tactile_paving#how_to_mark_on_steps%3F
https://community.openstreetmap.org/t/tactile-paving-on-highway-steps/9215


--
Opinions above are GNU-copylefted.


___
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] drones

[Lukas-458]

Hmm, well, I don't know, I guess there will be specific laws in each country about where you are allowed and aren't allowed to fly drones, right?

 


Well, if it is explicitly signposted as not allowed, you could of course map it, but only where it really says so on site, I think.

 

-- Lukas

 

Gesendet: Freitag, 10. Februar 2023 um 12:43 Uhr
Von: "Anne-Karoline Distel" 
An: "OSM Tagging" 
Betreff: [Tagging] drones


What do people think about a key like drone? I'm thinking of heritage sites/ tourist attractions, of course. I noticed on a Welsh heritage site that they had an icon for all the amenities and permissions, and they had one for "Drones not allowed". Obviously, we could add drone=no to every airport as well, but that's not my main concern.

In Ireland, drones are not allowed over Office of Public Works sites, unless you're the photographer for the National Monuments Service. Or maybe an archaeologist with special license for a dig. But as a drone pilot, you might not know whether a site is OPW or not.

I don't have a drone myself, I'm just not sure if this would be useful or not. There are 9 uses so far.

Anne
___ 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] RFC Start - extend telephone covers

[Lukas-458]

Hi all,

 

I want to show you my proposal about extending the values of the key covered=* for detailed mapping how a telephone is covered, again. The proposal's page is here: https://wiki.openstreetmap.org/wiki/Proposed_features/extend_telephone_covers

 

I'm looking forward to your comments.

 

Thank you!

--Lukas

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

Re: [Tagging] Feature Proposal - Voting - traffic_signals=crossing_only

[Lukas-458]

Hi,

in a discussion during voting on my proposal of traffic_signals=crossing_only (https://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals%3Dcrossing_only)

there was mentioned that the existing values of traffic_signals=* partial rather describe the configuration of a traffic signal (blinker, continuous_green, blink_mode) than describing their responsibilty. But I think that's not the case for all ones, because "emergency", "bus/tram_priority" and "ramp_meter" are responsibilities, to me.

 

But how to tag a traffic signal which is blinking every time (blink_mode) but only activated/chaging to red for the cars when a pedestrian wants to cross (traffic_signals=crossing_only) then? Two tags get in conflict here, but I think both have a legitimation to get tagged. The same cann appear for a "bus_priority" signal, for example.

My question is, whether we need a new key for differentiation between "how is a traffic light configured" and "for what is a traffic light responsible".

 

Something like "traffic_signals:default_light"? Then the "resposibility" of a traffic light can go on traffic_signals=*, and traffic_signals:default_light could describe if the signal has a light before getting activated, so values could be "staying_green","staying_yellow","blinking_yellow", something like this.

 

I would like to hear/read what you think.

--Lukas


Gesendet: Freitag, 08. Mai 2020 um 11:25 Uhr
Von: lukas-...@web.de
An: tagging@openstreetmap.org
Betreff: Re: [Tagging] Feature Proposal - Voting - traffic_signals=crossing_only



Hi,

at the moment, there are not so many people who looked at my proposal for traffic_signals=crossing_only :

https://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals%3Dcrossing_only

 

I would look forward to some more people comment or vote on my proposal which has the aim to distingiush those highway=traffic_signals on "straight road" which control only a crossing from other types of traffic signals.

 

Current tagging (highway=crossing/crossing=traffic_signals, sometimes + button_operated=yes), does not allow to distinguish them clearly.

It carries potentially information because the traffic lights I mentioned have other circuits and are often activated on-demand only.

 

If questions comment either here or maybe rather on the discussion page.

 

--Lukas


Gesendet: Freitag, 01. Mai 2020 um 14:05 Uhr
Von: lukas-...@web.de
An: tagging@openstreetmap.org
Betreff: [Tagging] Feature Proposal - Voting - traffic_signals=crossing_only




Hello to everyone,

Voting has opened for the proposal of traffic_signals=crossing_only – see the proposal page here: https://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals%3Dcrossing_only

 

(please note the old name was traffic_signals=crossing_on_demand, but I changed that because the focus is not on the „on demand“, but on the „traffic lights for only a crossing“).

 

It has been discussed about on the mailing list at 2020-04-13 and a few days after.

 

The proposal's purpose:

traffic_signals=crossing_only marks those highway=traffic_signals which do only control a crossing

 

Why?

It's interesting for routers concerning penalty times (much lower on those points than for a junction) and at the moment, there is no real way to mark that:

 

highway=traffic_signals + crossing=traffic_signals is used together on the same node, but NOT only in those cases where there is a „crossing-only“ traffic light. It's also used on junctions. We discussed that it would be difficult to change that, because highway=traffic_signals + crossing=traffic_signals is an accepted tagging and can be used together also when the exact locations of the crossings - at a junction - are not known and in some other cases.

 

highway=traffic_signals + crossing=traffic_signals + button_operated=yes can be used, but with looking just at button_operated=yes, this does not mean that there is only a crossing and not a traffic junction. Crossings at junctions can have buttons for pedestrians, too, example: https://www.openstreetmap.org/node/3070180267

So the solution would be to add another under-category for highway=traffic_signals, as traffic_signals=* does it already.

--Lukas


___ 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 - Voting - traffic_signals=crossing_only

[Lukas-458]

Hi,

at the moment, there are not so many people who looked at my proposal for traffic_signals=crossing_only :

https://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals%3Dcrossing_only

 

I would look forward to some more people comment or vote on my proposal which has the aim to distingiush those highway=traffic_signals on "straight road" which control only a crossing from other types of traffic signals.

 

Current tagging (highway=crossing/crossing=traffic_signals, sometimes + button_operated=yes), does not allow to distinguish them clearly.

It carries potentially information because the traffic lights I mentioned have other circuits and are often activated on-demand only.

 

If questions comment either here or maybe rather on the discussion page.

 

--Lukas


Gesendet: Freitag, 01. Mai 2020 um 14:05 Uhr
Von: lukas-...@web.de
An: tagging@openstreetmap.org
Betreff: [Tagging] Feature Proposal - Voting - traffic_signals=crossing_only




Hello to everyone,

Voting has opened for the proposal of traffic_signals=crossing_only – see the proposal page here: https://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals%3Dcrossing_only

 

(please note the old name was traffic_signals=crossing_on_demand, but I changed that because the focus is not on the „on demand“, but on the „traffic lights for only a crossing“).

 

It has been discussed about on the mailing list at 2020-04-13 and a few days after.

 

The proposal's purpose:

traffic_signals=crossing_only marks those highway=traffic_signals which do only control a crossing

 

Why?

It's interesting for routers concerning penalty times (much lower on those points than for a junction) and at the moment, there is no real way to mark that:

 

highway=traffic_signals + crossing=traffic_signals is used together on the same node, but NOT only in those cases where there is a „crossing-only“ traffic light. It's also used on junctions. We discussed that it would be difficult to change that, because highway=traffic_signals + crossing=traffic_signals is an accepted tagging and can be used together also when the exact locations of the crossings - at a junction - are not known and in some other cases.

 

highway=traffic_signals + crossing=traffic_signals + button_operated=yes can be used, but with looking just at button_operated=yes, this does not mean that there is only a crossing and not a traffic junction. Crossings at junctions can have buttons for pedestrians, too, example: https://www.openstreetmap.org/node/3070180267

So the solution would be to add another under-category for highway=traffic_signals, as traffic_signals=* does it already.

--Lukas


___ 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] Tag:amenity=motorcycle_taxi not approved

[Lukas-458]

"1) Propose using taxi=motorcar, =motorcycle, =boat, =airplane"

 

I believe at least with this key it would be a waste of time, yes, because taxi=yes is already an access tag and then we get into a chaos. If really wanted it would have to be something like "taxi:type", but this was just for noticing, because I was some of them who were opposed to expand amenity=taxi's definition.

 
--Lukas

Gesendet: Donnerstag, 07. Mai 2020 um 20:49 Uhr
Von: "Joseph Eisenberg" 
An: "Tag discussion, strategy and related tools" 
Betreff: [Tagging] Tag:amenity=motorcycle_taxi not approved


The voting period closed for amenity=motorcycle_taxi with 11 votes to approve and 8 votes in opposition, therefore it is not approved, since the 74% majority requirement was not met.

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:amenity%3Dmotorcycle_taxi#Voting

Opposing voters preferred using amenity=taxi + motorcycle=yes or amenity=taxi + taxi=motorcycle
 

Surprisingly, at least 2 opposing voters would be willing to use amenity=taxi + taxi=submarine or taxi=airplane for a location where you could hire a submarine or airplane. 

 

However, several "yes" voters were strongly opposed to expanding the definition of amenity=taxi which currently is limited to taxicabs (generally assumed to be 4-wheel motor vehicles in contemporary British English).

 

So, what's the next step? 

 

1) Propose using taxi=motorcar, =motorcycle, =boat, =airplane, and get that idea officially rejected (it appears it would be certain to fail), or is that a waste of everyone's time?

 

2) Make a proposal to clarify the definition of amenity=taxi as only applying to motorcars, then try to propose the tag again?

 

3) Propose amenity=ojek and just hold the vote in the Indonesian community, like how the Japanese mapper community proposes locally-relevant definitions?

 

4) Give up on mapping things which are not found in western Europe, and recognize that this is in practice a project dominated by English/German/American culture, which will not accept new ideas which were not invented in the West?

 

-- Joseph Eisenberg

___ 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] Is there any tagging scheme for carillons already?

[Lukas-458]

Hmm, okay. I think a carillon is so widespread especially, but not only for bell_towers, that something like carillon=yes wouldn't be useful.

 

But maybe I will start a proposal with attraction=carillon for tagging carillons which are operated as an attraction, but then the definition of that has to be very clear, I think.

 

But I think we need a tag for tagging just bells, too. There exists amenity=bell 198x but I think a bell is not really an "amenity", is it? man_made=bells could be used just for the bell itself, because tower:type=bell_tower ist just about the tower, not about the bell. And if people want to tag those they can decide for themselves, no really matter whether the bells is/are seeable for public or not. There are also some bells which are outside of towers, anyway.

 

I think I would go on with a proposal for that.

 
--Lukas

Gesendet: Donnerstag, 07. Mai 2020 um 07:11 Uhr
Von: "Marc Gemis" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Is there any tagging scheme for carillons already?

On Wed, May 6, 2020 at 7:54 PM Paul Allen  wrote:

> I'm not sure we need to tag the carillon. The ones in churches I've
> encountered or read about aren't operated as attractions.

Not important for tagging, but perhaps worth mentioning.

Normally, in summer there are concerts in 3 Flemish towns on
carillons, called beiaardconcerten [1]
I wonder whether that classifies as "operated as attractions"
It seems that in some towns you can visit them as well [2].

regards

m.

[1] https://nl.wikipedia.org/wiki/Beiaardconcert
[2] https://bib.kuleuven.be/over-ons/Index/beiaardbezoek

___
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] Is there any tagging scheme for carillons already?

[Lukas-458]

An addition to my ideas:

I think bell_tower=carillon does not really fit, because it says nothing about what kind of bell_tower it is, like the other values of bell_tower do.

 

Wikipedia says: "A carillon is a musical instrument that is typically housed in the bell tower (belfry) of a church" okay yes, typically. But that changes nothing about that it's not a type of a bell_tower, but a "content" of it. So that's why I would propose a new tag man_made=bells for it, but I see that that might be like mapping every antenna of a tower:type=communication. Not very useful. So I would go on attraction=carillon then, which could be used for the carillons when they are operated as an attraction.

 
--Lukas

Gesendet: Mittwoch, 06. Mai 2020 um 21:24 Uhr
Von: lukas-...@web.de
An: tagging@openstreetmap.org
Betreff: Re: [Tagging] Is there any tagging scheme for carillons already?



Okay. So I may conclude:

 

- We have those carillons inside bell towers, often we do not see them at all. Not sure whether to tag those, at least the attraction=* key would not fit for all of them.

 

- We have some carillons outside of bell_towers, and I think these are the ones which are operated as an attraction, at least in most cases.

 

What would you say to propose something like "man_made=bells" (not man_made=bell, because several bells can then mapped as one node, for many carillons it would not be really able to map each bell of it) and "bell_count" for tagging "all kinds" of bells? These tags could be used for carillons inside and outside of bell_towers (and maybe for "other bells", too), so it says nothing about being an attraction. If people want to map only the tower, they can do. But I believe there are bells outside of towers, too.

 

If it's purposed for people looking at it and hearing it at scheduled times and so on, we would need something like attraction=carillon or the tourism=attraction tag would have to be added to the man_made=bells, would be my suggestion then.

 

Someone likes to comment on that?

-- Lukas


Gesendet: Mittwoch, 06. Mai 2020 um 20:58 Uhr
Von: "Martin Koppenhoefer" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Is there any tagging scheme for carillons already?



sent from a phone

> On 6. May 2020, at 19:54, Paul Allen  wrote:
>
> I'm not sure we need to tag the carillon. The ones in churches I've
> encountered or read about aren't operated as attractions. The bells aren't
> visible, the mechanisms aren't visible, the operator isn't visible and they're
> not operated frequently.



I understand you are mostly interested in visual aspects, but OSM doesn’t have to limit itself to this, IMHO carillons are mostly about music so whether you can see them is not so important.


> I don't think we need to tag the fact that a carillon is in a church bell tower,
> or how many bells it has. We distinguish between a bell tower and a clock
> tower because they are visibly very different and constitute landmarks .
> Other than that, we don't need to know what is inside.


I disagree.

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] Is there any tagging scheme for carillons already?

[Lukas-458]

Okay. So I may conclude:

 

- We have those carillons inside bell towers, often we do not see them at all. Not sure whether to tag those, at least the attraction=* key would not fit for all of them.

 

- We have some carillons outside of bell_towers, and I think these are the ones which are operated as an attraction, at least in most cases.

 

What would you say to propose something like "man_made=bells" (not man_made=bell, because several bells can then mapped as one node, for many carillons it would not be really able to map each bell of it) and "bell_count" for tagging "all kinds" of bells? These tags could be used for carillons inside and outside of bell_towers (and maybe for "other bells", too), so it says nothing about being an attraction. If people want to map only the tower, they can do. But I believe there are bells outside of towers, too.

 

If it's purposed for people looking at it and hearing it at scheduled times and so on, we would need something like attraction=carillon or the tourism=attraction tag would have to be added to the man_made=bells, would be my suggestion then.

 

Someone likes to comment on that?

-- Lukas


Gesendet: Mittwoch, 06. Mai 2020 um 20:58 Uhr
Von: "Martin Koppenhoefer" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Is there any tagging scheme for carillons already?



sent from a phone

> On 6. May 2020, at 19:54, Paul Allen  wrote:
>
> I'm not sure we need to tag the carillon. The ones in churches I've
> encountered or read about aren't operated as attractions. The bells aren't
> visible, the mechanisms aren't visible, the operator isn't visible and they're
> not operated frequently.



I understand you are mostly interested in visual aspects, but OSM doesn’t have to limit itself to this, IMHO carillons are mostly about music so whether you can see them is not so important.


> I don't think we need to tag the fact that a carillon is in a church bell tower,
> or how many bells it has. We distinguish between a bell tower and a clock
> tower because they are visibly very different and constitute landmarks .
> Other than that, we don't need to know what is inside.


I disagree.

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] Doorzone bicycle lanes

[Lukas-458]

Or use class:bicycle=* for classification of those ways, but I still know it's a tag which might be non-specific, "as someones likes it" and with an individual taste. But it puts several things which have influence on how suitable/useful a cycleway is together, so I think it might be a good idea so or so to order the use a cycleway "gives" to cyclists at least in some way at all.

 
--Lukas

Gesendet: Mittwoch, 06. Mai 2020 um 17:02 Uhr
Von: lukas-...@web.de
An: tagging@openstreetmap.org
Betreff: Re: [Tagging] Doorzone bicycle lanes



Oh Yes I agree, it's the same thing like that that (nearly) all railway=platforms have the risk that a passing-by train appears, and that's also a very general hazard implied by the situation. Or when there's a street with a very narrow sidewalk. It would be tagged by sidewalk:left:width=*, but to me all those things would "crash the system" if they all get a hazard=* value or any similar tagging.

 

Also, the width of the cycleway would play a role concerning dooring. If it's wide, cyclists can hold a distance. Maybe routers should combine this information (when available) together with a warning taken from the tagging.

 

--Lukas


Gesendet: Mittwoch, 06. Mai 2020 um 16:14 Uhr
Von: "Peter Elderson" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Doorzone bicycle lanes


Seems to me that the hazard is a general hazard applying to all mixed traffic/parking situations. I would not map such a general hazard. Mapping events and risks, unless indicated by signage or markings, doesn't seem like a good idea to me.
 

In specific cases the hazard may deserve mapping, then it should be tied to specific OSM-objects, I think. If a parking "lane" is next to a cycle-lane, then you might want to see that when rendering or weigh in/warn when routing.

 

In that case I think maybe the best solution is to map the parking "lane" next to the cycling lane. The hazard then follows from the proximity.

 

Best, Peter Elderson

 

 


Op wo 6 mei 2020 om 15:49 schreef :




Hmm okay, convinced. I only hope noone else comes with that topic later again then, but to me it's ok.

 
-- Lukas

Gesendet: Mittwoch, 06. Mai 2020 um 14:15 Uhr
Von: "Andrew Harvey" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Doorzone bicycle lanes



 
 


On Wed, 6 May 2020 at 22:08, Martin Koppenhoefer  wrote:



sent from a phone

> On 6. May 2020, at 13:20, lukas-...@web.de wrote:
>
> I agree with that, but then note that for "justice" we would need a foot:doorzone=yes, too, because when a sidewalk is in the parking car's doorzone (I think most sidewalks next to parking:lane=parallel are), there is hazard for pedestrians, too. It might be not soo dangerus because pedestrians have much lower speed than cyclists often have, but if we want to tag that hazard I think we would have to affect both, foot and bicycle.



indeed there is much fewer risk for pedestrians and I would not tag it. Next thing would be to add hazards for roof tiles that may fly from roofs in case of storm? Snow sliding from roofs in winter? There may be many hazards if you think it through...
;-)

 

I agree with Martin here, I don't think "foot:doorzone" is really needed as the concept only applies to bicycles.


___ 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




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

Re: [Tagging] Doorzone bicycle lanes

[Lukas-458]

Oh Yes I agree, it's the same thing like that that (nearly) all railway=platforms have the risk that a passing-by train appears, and that's also a very general hazard implied by the situation. Or when there's a street with a very narrow sidewalk. It would be tagged by sidewalk:left:width=*, but to me all those things would "crash the system" if they all get a hazard=* value or any similar tagging.

 

Also, the width of the cycleway would play a role concerning dooring. If it's wide, cyclists can hold a distance. Maybe routers should combine this information (when available) together with a warning taken from the tagging.

 

--Lukas


Gesendet: Mittwoch, 06. Mai 2020 um 16:14 Uhr
Von: "Peter Elderson" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Doorzone bicycle lanes


Seems to me that the hazard is a general hazard applying to all mixed traffic/parking situations. I would not map such a general hazard. Mapping events and risks, unless indicated by signage or markings, doesn't seem like a good idea to me.
 

In specific cases the hazard may deserve mapping, then it should be tied to specific OSM-objects, I think. If a parking "lane" is next to a cycle-lane, then you might want to see that when rendering or weigh in/warn when routing.

 

In that case I think maybe the best solution is to map the parking "lane" next to the cycling lane. The hazard then follows from the proximity.

 

Best, Peter Elderson

 

 


Op wo 6 mei 2020 om 15:49 schreef :




Hmm okay, convinced. I only hope noone else comes with that topic later again then, but to me it's ok.

 
-- Lukas

Gesendet: Mittwoch, 06. Mai 2020 um 14:15 Uhr
Von: "Andrew Harvey" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Doorzone bicycle lanes



 
 


On Wed, 6 May 2020 at 22:08, Martin Koppenhoefer  wrote:



sent from a phone

> On 6. May 2020, at 13:20, lukas-...@web.de wrote:
>
> I agree with that, but then note that for "justice" we would need a foot:doorzone=yes, too, because when a sidewalk is in the parking car's doorzone (I think most sidewalks next to parking:lane=parallel are), there is hazard for pedestrians, too. It might be not soo dangerus because pedestrians have much lower speed than cyclists often have, but if we want to tag that hazard I think we would have to affect both, foot and bicycle.



indeed there is much fewer risk for pedestrians and I would not tag it. Next thing would be to add hazards for roof tiles that may fly from roofs in case of storm? Snow sliding from roofs in winter? There may be many hazards if you think it through...
;-)

 

I agree with Martin here, I don't think "foot:doorzone" is really needed as the concept only applies to bicycles.


___ 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] Doorzone bicycle lanes

[Lukas-458]

Hmm okay, convinced. I only hope noone else comes with that topic later again then, but to me it's ok.

 
-- Lukas

Gesendet: Mittwoch, 06. Mai 2020 um 14:15 Uhr
Von: "Andrew Harvey" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Doorzone bicycle lanes



 
 


On Wed, 6 May 2020 at 22:08, Martin Koppenhoefer  wrote:



sent from a phone

> On 6. May 2020, at 13:20, lukas-...@web.de wrote:
>
> I agree with that, but then note that for "justice" we would need a foot:doorzone=yes, too, because when a sidewalk is in the parking car's doorzone (I think most sidewalks next to parking:lane=parallel are), there is hazard for pedestrians, too. It might be not soo dangerus because pedestrians have much lower speed than cyclists often have, but if we want to tag that hazard I think we would have to affect both, foot and bicycle.



indeed there is much fewer risk for pedestrians and I would not tag it. Next thing would be to add hazards for roof tiles that may fly from roofs in case of storm? Snow sliding from roofs in winter? There may be many hazards if you think it through...
;-)

 

I agree with Martin here, I don't think "foot:doorzone" is really needed as the concept only applies to bicycles.


___ 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] Is there any tagging scheme for carillons already?

[Lukas-458]

"More seriously, attraction=carillon would be appropriate for one in a theme park
or the like but I don't think it suitable for a carillon housed in a bell tower of a

church where it is out of sight (but, sadly, not out of hearing).  I'd suggest that

if attraction=carillon is added to the wiki then the wiki should mention that

this is for visible carillons that are attractions and not for those housed in

bell towers of churches."

 

Okay, I agree with that. So maybe we have to differentiate there. In Germany, Wuppertal, we have this one: https://www.google.com/imgres?imgurl=https%3A%2F%2Fwww.wuppertaler-rundschau.de%2Fimgs%2F90%2F6%2F6%2F1%2F5%2F2%2F3%2F3%2F1%2Ftok_c9e6f7468287079da535ae974baefdef%2Fw1900_h2533_x1626_y1911_Glockenspiel2__2_-082bcb875d8144ff.jpg=https%3A%2F%2Fwww.wuppertaler-rundschau.de%2Flokales%2Fabeler-glockenspiel-in-wuppertal-das-wird-noch-etwas-dauern_aid-45498633=lYCN3tKcBM3PDM=12ahUKEwiWusH2rZ_pAhUI44UKHRglDlsQMygAegUIARDZAQ..i=GFai1JWBTqZgpM=1900=2533=glockenspiel%20wuppertal=2ahUKEwiWusH2rZ_pAhUI44UKHRglDlsQMygAegUIARDZAQ


 

It's inside a building or rather covered by it, but it's function is like a tourism=attraction, and for me there is no tower really, so I came on the attraction=*-key. For those in bell towers of churches man_made=tower or man_made=bell_tower might be appropiate, but actually these tags are describing only the tower and it's type/building-type, not the carillon itself.

 

I don't know whether a carillon inside a bell_tower needs an own tag, but I think those like the one in the picture needs. 

Maybe

attraction=carillon

or rather

man_made=carillon

or

man_made=bell(s)

 

man_made=bell(s) could be used for other "bells", too, but I'm not sure whether this is needed. amenity=bell has 198 uses, but I resist in putting also this feature into the amenity=* key [again].

--

Lukas


Gesendet: Mittwoch, 06. Mai 2020 um 13:59 Uhr
Von: "Paul Allen" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Is there any tagging scheme for carillons already?



On Wed, 6 May 2020 at 12:14,  wrote:




 
In the wiki I found bell_tower=* (but without a carillon-specific value) and I think a carillon does not have to be a bell_tower at all, so these are two different things.




 

According to https://en.wikipedia.org/wiki/Carillon they're typically found in bell

towers but do not have to be.  The first two examples on that page are not in

towers.




 

So if there is no real specific tagging for carillons at the moment, I would want to start a proposal of attractrion=carillon, but before I wanted to hear some opinions




 

 If I lived near one I might want to tag it nuisance=carillon or annoyance=carillon

rather than attraction=carillon.

 

More seriously, attraction=carillon would be appropriate for one in a theme park

or the like but I don't think it suitable for a carillon housed in a bell tower of a

church where it is out of sight (but, sadly, not out of hearing).  I'd suggest that

if attraction=carillon is added to the wiki then the wiki should mention that

this is for visible carillons that are attractions and not for those housed in

bell towers of churches.

 

--

Paul

 


___ 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] Doorzone bicycle lanes

[Lukas-458]

"highway=path,footway,cycleway is in a doorzone
bicycle:doorzone=yes (the bicycle lane of the path,footway,cycleway is in a doorzone) https://www.mapillary.com/map/im/ewtPBxYM_289cWusHEWytw"

 

I agree with that, but then note that for "justice" we would need a foot:doorzone=yes, too, because when a sidewalk is in the parking car's doorzone (I think most sidewalks next to parking:lane=parallel are), there is hazard for pedestrians, too. It might be not soo dangerus because pedestrians have much lower speed than cyclists often have, but if we want to tag that hazard I think we would have to affect both, foot and bicycle.


 
 

Gesendet: Dienstag, 05. Mai 2020 um 04:56 Uhr
Von: "Andrew Harvey" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Doorzone bicycle lanes



On Tue, 5 May 2020 at 02:35, Jan Michel  wrote:


On 03.05.20 19:16, Volker Schmidt wrote:
> I would advocate a more generic approach that remains open to other
> types of hazards (there are many, unfortunately).
> A generic
> hazard:bicycle=yes|dooring|pedestrians_on_cycleway|dangerous_exit|whatever

I agree, but I would rather use
cycleway:(left|right|both|):hazard
'hazard:bicycle' suggests that it is an hazard to all bicycles, but it's
more like an hazard that is a "feature" of the cycleway. Everybody close
to the cycleway is part of the hazard (whether active or passive) but
bicycles in other places of the road are not affected.

 


On Tue, 5 May 2020 at 04:33, Volker Schmidt  wrote:



You are right that in case of cycling infrastructure tagged on the road (like typically cycling lanes) we need a way to indicate to which part of the road it refers, in addition to the type of haxard.



 

Agree with Volker here.

 

cycleway:both:hazard becomes an issue when there are multiple hazards that apply, so "doorzone" should be part of the key not the value.


 

I originally proposed cycleway:lane:doorzone=yes but then since seeing https://www.mapillary.com/map/im/ewtPBxYM_289cWusHEWytw changed it to cycleway:doorzone=yes, but based on what Volker has said about indicating which part of the road it applies to maybe after all:

 

cycleway:lane:doorzone=yes (both sides of the road have a doorzone cyclelane) https://www.mapillary.com/map/im/MXuDWHZY_R9UkGcOk0FZUw

cycleway:lane:left:doorzone=yes (left side of the road has a doorzone cyclelane)

cycleway:lane:right:doorzone=yes

 

highway=path,footway,cycleway is in a doorzone

bicycle:doorzone=yes (the bicycle lane of the path,footway,cycleway is in a doorzone) https://www.mapillary.com/map/im/ewtPBxYM_289cWusHEWytw

 

The third scenario for dooring is just a regular road with no bicycle infrastructure, but parked cars can still lead to dooring eg https://www.mapillary.com/map/im/6YlYnuZPdlziwUsF1m7yWA I guess in that case where there is no bicycle infrastructure the dooring hazard should be determined by a parking:lane:parallel=* and some kind of parking:lane buffer tag?

 

Are there any other scenarios where dooring is a 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] Is there any tagging scheme for carillons already?

[Lukas-458]

Hi, I just wanted to ask whether there is any existing tagging for carillons already. In the wiki I found nothing, and I saw some may use tourism=attraction or bell=carillon already, but their uses are less and furthermore I think that these do not really fit.

 

In the wiki I found bell_tower=* (but without a carillon-specific value) and I think a carillon does not have to be a bell_tower at all, so these are two different things.

 

So if there is no real specific tagging for carillons at the moment, I would want to start a proposal of attractrion=carillon, but before I wanted to hear some opinions on this topic.

 

--Lukas

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

[Tagging] Feature Proposal - Voting - traffic_signals=crossing_only

[Lukas-458]

Hello to everyone,

Voting has opened for the proposal of traffic_signals=crossing_only – see the proposal page here: https://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals%3Dcrossing_only

 

(please note the old name was traffic_signals=crossing_on_demand, but I changed that because the focus is not on the „on demand“, but on the „traffic lights for only a crossing“).

 

It has been discussed about on the mailing list at 2020-04-13 and a few days after.

 

The proposal's purpose:

traffic_signals=crossing_only marks those highway=traffic_signals which do only control a crossing

 

Why?

It's interesting for routers concerning penalty times (much lower on those points than for a junction) and at the moment, there is no real way to mark that:

 

highway=traffic_signals + crossing=traffic_signals is used together on the same node, but NOT only in those cases where there is a „crossing-only“ traffic light. It's also used on junctions. We discussed that it would be difficult to change that, because highway=traffic_signals + crossing=traffic_signals is an accepted tagging and can be used together also when the exact locations of the crossings - at a junction - are not known and in some other cases.

 

highway=traffic_signals + crossing=traffic_signals + button_operated=yes can be used, but with looking just at button_operated=yes, this does not mean that there is only a crossing and not a traffic junction. Crossings at junctions can have buttons for pedestrians, too, example: https://www.openstreetmap.org/node/3070180267

So the solution would be to add another under-category for highway=traffic_signals, as traffic_signals=* does it already.

--Lukas


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

Re: [Tagging] iD semi automatic adding public_transport to aerialway=station

[Lukas-458]

Yes that's true, but then we need a clear definition of what is seen as "public_transport" and what's not, don't we? I think some mappers also use access=private already (I'm not sure whether that fits).

 

I think this proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/Differentiation_for_routes_of_public_transport goes in a direction of that, but note it has nothing to do with aerialway=station.

 

--Lukas

 
 

Gesendet: Sonntag, 19. April 2020 um 13:12 Uhr
Von: "Joseph Eisenberg" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] iD semi automatic adding public_transport to aerialway=station

I agree that a tag like "public_transportation=yes" would be a
sensible tag to add to a aerialway=station which is used as public
transit, and "public_transportation=no" could be useful for a
"railway=station" or "highway=bus_stop" which is not used for public
transit.

-- Joseph Eisenberg

___
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 - Refugee Site Location

[Lukas-458]

Hi,

my question is whether this then rather would be something for the "place" tag? Or did we maybe have that discussion already?


 

--Lukas

 

Gesendet: Freitag, 17. April 2020 um 18:28 Uhr
Von: "Manon Viou" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Feature Proposal - RFC - Refugee Site Location



Hello everyone,

 

It seems I haven't been very clear in my explanations; I sometimes have a bit of trouble choosing the right word (especially in English). And I think the “small”/”large” discussion is going the wrong direction…

 

The new tag we want to propose is to map refugee camps or as it’s seems better to say in English now : refugee sites. So we want to map human settlement.

 

The social_facility=shelter tag is very suitable to map single or individual building or a small group of buildings like a refugee center, an accommodation center or a care and hosting center for refugees.

 

But (according to many people now)  the social_facility=shelter tag is not suitable to map  refugee camps that are human settlements,  populated places where hundreds or  thousands people live.

 

That’s why we propose to create a new value for the amenity tag : amenity=refugee_site, to map human settlement where refugees can find protection.

 

kind regards, 

Manon

 


Le 17 avril 2020 à 13:03, Warin <61sundow...@gmail.com> a écrit :
 
On 17/4/20 5:29 am, Manon Viou wrote:


Hello, 

According to Martin and Warin, the difference between large and small refugee site is not clear enough, 
Martin suggested to use population capacity, for instance less than 200 people fro small refugee site, 

Warin suggested to use number of square meters, 

For what I have observed, small facilities sheltering refugee (for instance: refugee centers, accommodation center, care and hosting center, church) are not exactly what we can call refugee site. the difference, beyond the number of building, number of population or square meter, is quite obvious.


 

?? How is it 'obvious'???

 

I have no idea of what that 'obvious' thing is!

 

 


Is it really necessary to set a precise rule ?


 

At the moment there is nothing that can be used to distinguish between the two.

Suggestion have been made on the number of buildings, number of people and the area.

 

Please tell us how you distinguish between them.

 


I would rather suggest to share some example (like the ones mentioned above) in order to help contributors to decide if it rather an amenity=refugee_site or a social_facility=shelter. 


 

Examples are fine. But there must be a statement in words of the difference between them.


Regards, 

Manon

Le 16 avril 2020 à 02:16, Warin <61sundow...@gmail.com> a écrit :
 
On 16/4/20 1:23 am, Manon Viou wrote:


Thanks Martin, yes, refugee sites should always be temporary even if, as you said, some turn to be very long term places. That's why we do not suggest to add temporary/permanent options. 

Manon


 

In which case the description for amenity=social_facility + social_facility=shelter is not correct.

 

If it is to be done on area then specify the number of square meters rather than the number of buildings???

Buildings can be a of different sizes and capacities. An area could be more consistent as to the number of people.

Imagery may not be up to date so counting buildings may not be possible. 

 



Le 15 avril 2020 à 11:36, Martin Koppenhoefer < dieterdre...@gmail.com> a écrit :

 

sent from a phone

 


On 15. Apr 2020, at 01:13, Warin < 61sundow...@gmail.com> wrote:

 

I would think amenity=refugee_site is an area set aside for the non-temporary residential use of refugees


 

maybe I’m a dreamer, but I would expect all refugee related features to be “temporary”, even if we are talking about relatively long periods of time

 

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


 




Manon Viou

Coordinatrice projet Missing Maps

 m_v...@cartong.org |  manon.viou



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


 




Manon Viou

Coordinatrice projet Missing Maps

 m_v...@cartong.org |  manon.viou
 +33 (0)4 79 26 28 82 |  +33 (0)7 83889839

 Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E

___ 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 - traffic_signals=crossing_on_demand

[Lukas-458]

Maybe there would be some reason th change the proposal on tagging traffic_signals=crossing_only to make it more clear in teh value that only those traffic lights are meant with it, which do control only a crossing. But if that would be a solution at all, I don't really know. Because I think there is no real clear conclusion at the moment when highway=traffic_signals + crossing=traffic_signals to use on the same node and when not, because there are so many different possible situations as some examples were illustrated.

 

--Lukas

 
 

Gesendet: Mittwoch, 15. April 2020 um 15:27 Uhr
Von: "John Willis via Tagging" 
An: "Tag discussion, strategy and related tools" 
Cc: "John Willis" 
Betreff: Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand


 
 

On Apr 15, 2020, at 8:34 PM, Paul Allen  wrote:
 

The traffic lights control the junction


 

We have a lot of traffic light controlled crossings in Japan that are just for a crosswalk, while the smaller intersecting road is stop-sign controlled for cars. Only the crosswalk is controlled by a signal that stops traffic on the larger road - only when pressed. There are many of these. 

 

https://www.openstreetmap.org/way/790227211

https://www.openstreetmap.org/way/729071392

 

- crosswalks for traffic signal controlled intersections where the light is _only_ sensor triggered - magnet loop in the road and a push-button for pedestrians. there are very few of these. a little sign says “push button” - and if you don’t press it, you will wait until a car comes.

 

both of these are “on demand” to me . 

 

this is beyond normal signal controlled crosswalks in the middle of larger roads (like in front of a hospital, etc), 

 

 

Javbw

 

 
___ 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 - traffic_signals=crossing_on_demand

[Lukas-458]

Okay, so this is what I think, too and maybe I would clarify this in the wiki then.

 

But I think in some cases it still wouldn't be clear, because what would be about mapping this then:

https://www.google.co.uk/maps/@52.0898304,-4.6450624,3a,75y,122.71h,87.75t/data="">

 

Which was mentioned a few posts before? The traffic lights control the junction, but people might say that the same one single traffic light is controlling the pedestrian crossing and the junction...

 

--Lukas

 
 

Gesendet: Mittwoch, 15. April 2020 um 00:21 Uhr
Von: "Jarek Piórkowski" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

On Tue, 14 Apr 2020 at 10:00,  wrote:
> So in which cases "highway=traffic_signals + crossing=traffic_signals on the same node" should be used? Only for the "crossing only-traffic lights" I mentioned?

Yeah, personally I would agree with that. Only on
pedestrian/cycle-crossing-only traffic lights.
https://www.openstreetmap.org/node/2771622922 as an example.

I think that if you're going to the extent of mapping separate stop
lines on all ways leading into the intersection, you can also separate
the car stop line node from the pedestrian crossing node. (And if
you're not, highway=traffic_signals on the main intersection node
still works.) So don't use highway=traffic_signals +
crossing=traffic_signals, except for a pedestrian-crossing-only light.

--Jarek

___
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] insurance health

[Lukas-458]

"I am still not completely sure, but I believe, "Allianz" is a group
here, and health care insurance will be provided by a member of this
group, and agents will sell you any product the group offers (i.e. in
the details they are different "companies", but you can find several
of these companies together, bundled as "group")."

 

Yes, that's completely true. So my vote would also be rather for an additional tag like insurance=health.

 
 

Gesendet: Mittwoch, 15. April 2020 um 11:08 Uhr
Von: "Martin Koppenhoefer" 
An: "Tag discussion, strategy and related tools" 
Cc: "Agustin Rissoli" 
Betreff: Re: [Tagging] insurance health

sent from a phone

> On 15. Apr 2020, at 03:17, Joseph Eisenberg  wrote:
>
> But it takes more time for each mapper to add 2 tags instead of one.
> Mapper time is the most precious resource in OpenStreetMap: we don't
> have enough mappers, and most are working for free, for fun.
> Let's make things as easy as possible for mappers: one tag for one main feature.


most time is spent finding the “best” or at least mostly used and
appropriate tagging, much more than you need to actually type it in.
And people relying on presets don’t care anyway, because a preset can
set 2 tags with one click.

I agree we should strive for easy tagging, but it may also imply to
sometimes use 2 tags rather than one.

When there are places where an insurance company office lets you sign
up for health insurance and other insurance types, the distinction in
the main tag will be an issue.
I am not completely sure, but from a quick verification it doesn't
seem improbable that you can get healthcare insurance at the same
place as other insurance types, e.g. when you look here for offices of
a specific German insurance company (which offers "all" kinds of
insurances, including private healthcare insurance) in a specific
town, the search form does not have a selection for the type of
insurance, hence I would suspect that all of them will be able to sell
you all of their insurances:
https://www.allianz.de/agentursuche/karlsruhe/?address=karlsruhe
I am still not completely sure, but I believe, "Allianz" is a group
here, and health care insurance will be provided by a member of this
group, and agents will sell you any product the group offers (i.e. in
the details they are different "companies", but you can find several
of these companies together, bundled as "group").

Also, the assumption for your assessment of easyness is that people
will want to tag "healthcare insurance company office", so they will
need 2 tags to describe office=insurance, insurance=health(_care)
but if all the mapper wants to tag is "insurance company" (regardless
of types of insurances), she could add office=insurance which is
arguably simpler and easier than office=health_insurance

So, in accordance with your statement "Let's make things as easy as
possible for mappers", we could argue just as well for
"office=insurance" and optional details about the kind of insurance in
additional tags.

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 - traffic_signals=crossing_on_demand

[Lukas-458]

"My understanding of the detailed-intersection-tagging
norms was that this should have highway=traffic_signals on the stop
line for cars, and highway=crossing+crossing=traffic_signals on the
middle of the pedestrian crossing"

 

Yes, this was actually exact that what were in my thoughts. But I think that not all mappers know that or follow that practice. So that's why my original purpose was to ban highway=traffic_signals + crossing=traffic_signals on the same node, but I know that's not possible and that's also what I don't want anymore to reach.

But what I see is, that we have to clarify much more WHEN, so in which case, highway=traffic_signals + crossing=traffic_signals on the same node should be seen as "accepted"/"good mapping practice" and in which cases not. I think it has to come more clear in the wiki that highway=traffic_signals + crossing=traffic_signals on the same node in NOT a "shortcut" or "mapping practice" for detailed intersection tagging/mapping.

 

Is it right tht we agree with that? So in which cases "highway=traffic_signals + crossing=traffic_signals on the same node" should be used? Only for the "crossing only-traffic lights" I mentioned?

 

--Lukas

 
 

Gesendet: Dienstag, 14. April 2020 um 15:43 Uhr
Von: "Jarek Piórkowski" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

On Tue, 14 Apr 2020 at 06:23,  wrote:
>
> To response on the mentioning:
> "Currently the wiki page says "traffic_signals=crossing_on_demand makes
> it easy to mark all traffic lights which do only control a crossing",
> again I personally find highway=traffic_signals +
> crossing=traffic_signals sufficient for that"
>
> Yes, that's true. I agree with that, but my point is, that not only those traffic lights, which do control only a crossing, a mapped like this. Mappers use it just as a shortcut for traffic light and crossing, no matter in which relation between each other they are. That is not wrong, but it does not really show for what the lane traffic lights are "resposible". Please have a look at https://www.openstreetmap.org/node/1339612951 and many many others in this city. The traffic lights of course control the crossing, yes, but they control the junction nearby, too.
> So looking at highway=traffic_signals + crossing=traffic_signals on the same node also makes it not possible to see only those crossings where n junction or something else is, as I see it at the moment.

Hm, that's tagging I haven't seen before. My suggestion would be to
not tag like that (the proposed new tag would suggest retagging of
this anyway). My understanding of the detailed-intersection-tagging
norms was that this should have highway=traffic_signals on the stop
line for cars, and highway=crossing+crossing=traffic_signals on the
middle of the pedestrian crossing - e.g.
https://www.openstreetmap.org/node/1822620449 or
https://www.openstreetmap.org/node/393547028

--Jarek

___
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 - traffic_signals=crossing_on_demand

[Lukas-458]

Hmm, yes I know there a several values for traffic_signals, but the main value "signal" comes just from the default value by iD which wasn't discussed, I think many of you will know about it. I chose the key "traffic_signals" because as the wiki says, it says something about the function of the traffic signal or for what is it "responsible". I think traffic_signals:_on_demand_=yes could be an option maybe, but it still would miss the goal to mark all those traffic signals, which do control ONLY a crossing. Many traffic lights are activated "on demand", but also those, which are at a junction, too.

 

"To me it seems there are different aspects that could occur on the same traffic signal controlled crossing"

Hmm. As I saw it, the existing "traffic_signals" values which are documented (so NOT traffic_signals=signal which does nothing say at all) specify "special" traffic signals. Nothing where different aspects appear really on the same one, or am I wrong? I do not even know what traffic_signals=signal wants to say to us.

 

"Also, there can be huge differences between different "on demand" crossings, some of them almost instantly turn red for vehicular traffic after you push the button, others may have long waiting times even when you push."

 

Yes that's true, but traffic_signals=crossing_on_demand does not say anything about that. It's only saying for what the traffic lights are responsible.Maybe we would need another key like "waiting_time" for that then, but I think it often depends on traffic situation and maybe can be changed during the daytime by a controlling center etc.

 
 

Gesendet: Dienstag, 14. April 2020 um 12:27 Uhr
Von: "Martin Koppenhoefer" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand



 
 


Am Mo., 13. Apr. 2020 um 14:16 Uhr schrieb :




Hi,

oh sorry you are confused. Maybe it's too much text I think. But your conclusion is completely correct, yes.

 





 

 

Did you have a look at the currently used values for traffic_signals? https://taginfo.openstreetmap.org/keys/traffic_signals#values

94% are tagged with "signal"

1,3% "traffic_lights"

1,2% "pedestrian_crossing"

0,6% "blinker"

0,4% "ramp_meter"

 

According to the wiki, the tag "Gives details about the type or function of traffic signals."

https://wiki.openstreetmap.org/wiki/Key%3Atraffic_signals

 

To me it seems there are different aspects that could occur on the same traffic signal controlled crossing, mixed into the same key, and your proposal would add just another property as a "main type"?

Have you considered something like traffic_signals:_on_demand_=yes?

 

Also, there can be huge differences between different "on demand" crossings, some of them almost instantly turn red for vehicular traffic after you push the button, others may have long waiting times even when you push.

Not sure if recording these times might seem a bit too much detail though ;-)

 

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 - traffic_signals=crossing_on_demand

[Lukas-458]

To response on the mentioning:


"Currently the wiki page says "traffic_signals=crossing_on_demand makes
it easy to mark all traffic lights which do only control a crossing",
again I personally find highway=traffic_signals +
crossing=traffic_signals sufficient for that" 

 

Yes, that's true. I agree with that, but my point is, that not only those traffic lights, which do control only a crossing, a mapped like this. Mappers use it just as a shortcut for traffic light and crossing, no matter in which relation between each other they are. That is not wrong, but it does not really show for what the lane traffic lights are "resposible". Please have a look at https://www.openstreetmap.org/node/1339612951 and many many others in this city. The traffic lights of course control the crossing, yes, but they control the junction nearby, too.

So looking at highway=traffic_signals + crossing=traffic_signals on the same node also makes it not possible to see only those crossings where n junction or something else is, as I see it at the moment.

 

Gesendet: Dienstag, 14. April 2020 um 12:12 Uhr
Von: lukas-...@web.de
An: tagging@openstreetmap.org
Betreff: Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand



Hi,

the difference would be that traffic signals which control a junction but a crossing too, can have buttons for pedestrians as well as traffic signals which do only control a crossing. At least here in Germany. With looking at button_operated, you cannot clear whether the traffic lights are controlling a crossng only and not a junction.

 

Soon I will add some photos you mentioned it would be a bit clearer maybe then.

 

Lukas

 
 

Gesendet: Dienstag, 14. April 2020 um 11:03 Uhr
Von: "Volker Schmidt" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand



What's the difference between

 

highway=traffic_signals plus button_poperated=yes

and

highway=traffic_signals plus traffic_signals=crossing_on_demand

 

?

 

 


On Tue, 14 Apr 2020 at 02:55, Jarek Piórkowski  wrote:

On Mon, 13 Apr 2020 at 12:56, Paul Allen  wrote:
> On Mon, 13 Apr 2020 at 17:43,  wrote:
>> The second goal my proposal wants to message is to deprecate tagging "crossing=traffic_signals" together with "highway=traffic_signals" on the same node. Especially if you're saying this is a full crossing mapped. It breaks the highway=crossing - tagging scheme we use for all other types of crossing (except crossing=no). Some mappers use "crossing=traffic_signals" together with "highway=traffic_signals" on the same node als a shortcut for "lane traffic signal" and "foot traffic signal" because it is rendered as two traffic signals in JOSM. Or for mapping traffic signals for crossing cyclists. But I think in every case it is better to use two different (nearby) nodes for that.
>
> Am I misunderstanding you?  You propose using two nearby nodes for
> https://goo.gl/maps/3Sg5ndQ2ZCMBN9uy9  You can just see the yellow
> pedestrian-control box at the left.  It controls the crossing (marked with studs)
> going from left to right across the picture.  The same lights that tell motorists
> to stop for pedestrians also control traffic flow at the T junction ahead.  The
> same set of lights is both a highway traffic signal and a crossing traffic signal.
> This sort of thing is not uncommon in the UK, with the same set of lights
> being used for both purposes.

My understanding was that traffic signals=crossing on demand is meant
for things like https://www.openstreetmap.org/node/2771622922 (
https://www.mapillary.com/map/im/2oyFQXVHvy2r-XypCZTECg ) however I
might be wrong? Or https://www.openstreetmap.org/node/1416834957 (
https://www.mapillary.com/map/im/DkuEFqSbOuQPGMtABsFFCA ) including
cyclists? (Esri is good for satellite imagery of these)

Personally I find highway=traffic_signals + crossing=traffic_signals
on one node sufficient for these crossings.

Currently the wiki page says "traffic_signals=crossing_on_demand makes
it easy to mark all traffic lights which do only control a crossing",
again I personally find highway=traffic_signals +
crossing=traffic_signals sufficient for that - maybe I'm missing
something. Of course any new tags can be proposed. But I would suggest
adding some real-world photos of crossings that would be tagged with
crossing_on_demand to the wiki page.

--Jarek

___
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

Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

[Lukas-458]

Hi,

the difference would be that traffic signals which control a junction but a crossing too, can have buttons for pedestrians as well as traffic signals which do only control a crossing. At least here in Germany. With looking at button_operated, you cannot clear whether the traffic lights are controlling a crossng only and not a junction.

 

Soon I will add some photos you mentioned it would be a bit clearer maybe then.

 

Lukas

 
 

Gesendet: Dienstag, 14. April 2020 um 11:03 Uhr
Von: "Volker Schmidt" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand



What's the difference between

 

highway=traffic_signals plus button_poperated=yes

and

highway=traffic_signals plus traffic_signals=crossing_on_demand

 

?

 

 


On Tue, 14 Apr 2020 at 02:55, Jarek Piórkowski  wrote:

On Mon, 13 Apr 2020 at 12:56, Paul Allen  wrote:
> On Mon, 13 Apr 2020 at 17:43,  wrote:
>> The second goal my proposal wants to message is to deprecate tagging "crossing=traffic_signals" together with "highway=traffic_signals" on the same node. Especially if you're saying this is a full crossing mapped. It breaks the highway=crossing - tagging scheme we use for all other types of crossing (except crossing=no). Some mappers use "crossing=traffic_signals" together with "highway=traffic_signals" on the same node als a shortcut for "lane traffic signal" and "foot traffic signal" because it is rendered as two traffic signals in JOSM. Or for mapping traffic signals for crossing cyclists. But I think in every case it is better to use two different (nearby) nodes for that.
>
> Am I misunderstanding you?  You propose using two nearby nodes for
> https://goo.gl/maps/3Sg5ndQ2ZCMBN9uy9  You can just see the yellow
> pedestrian-control box at the left.  It controls the crossing (marked with studs)
> going from left to right across the picture.  The same lights that tell motorists
> to stop for pedestrians also control traffic flow at the T junction ahead.  The
> same set of lights is both a highway traffic signal and a crossing traffic signal.
> This sort of thing is not uncommon in the UK, with the same set of lights
> being used for both purposes.

My understanding was that traffic signals=crossing on demand is meant
for things like https://www.openstreetmap.org/node/2771622922 (
https://www.mapillary.com/map/im/2oyFQXVHvy2r-XypCZTECg ) however I
might be wrong? Or https://www.openstreetmap.org/node/1416834957 (
https://www.mapillary.com/map/im/DkuEFqSbOuQPGMtABsFFCA ) including
cyclists? (Esri is good for satellite imagery of these)

Personally I find highway=traffic_signals + crossing=traffic_signals
on one node sufficient for these crossings.

Currently the wiki page says "traffic_signals=crossing_on_demand makes
it easy to mark all traffic lights which do only control a crossing",
again I personally find highway=traffic_signals +
crossing=traffic_signals sufficient for that - maybe I'm missing
something. Of course any new tags can be proposed. But I would suggest
adding some real-world photos of crossings that would be tagged with
crossing_on_demand to the wiki page.

--Jarek

___
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 - traffic_signals=crossing_on_demand

[Lukas-458]

I see. Thanks for your answers. Okay, now it's clearer to me why highway=traffic_signals is used sometimes together with crossing=traffic_signals. I will change the proposal to only add the new traffic_signals=*-value and then get in touch again.

 

Thanks.

--

Lukas

 
 

Gesendet: Montag, 13. April 2020 um 20:16 Uhr
Von: "Mark Wagner" 
An: tagging@openstreetmap.org
Betreff: Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

On Mon, 13 Apr 2020 18:42:42 +0200
lukas-...@web.de wrote:

> The second goal my proposal wants to message is to deprecate tagging
> "crossing=traffic_signals" together with "highway=traffic_signals" on
> the same node. Especially if you're saying this is a full crossing
> mapped. It breaks the highway=crossing - tagging scheme we use for
> all other types of crossing (except crossing=no). Some mappers
> use "crossing=traffic_signals" together with
> "highway=traffic_signals" on the same node als a shortcut for "lane
> traffic signal" and "foot traffic signal" because it is rendered as
> two traffic signals in JOSM. Or for mapping traffic signals for
> crossing cyclists. But I think in every case it is better to use two
> different (nearby) nodes for that. What do you think about it?

I think you should split it up into two proposals.
"highway=traffic_signals;crossing=traffic_signals" is so widely used
there's not a chance you'll get agreement to forbid it. If you tie
your proposed "traffic_signals=crossing_on_demand" tagging to it, all
that will happen is that "traffic_signals=crossing_on_demand" will be
rejected as well.

--
Mark

___
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] Request for assistance in creating a tag.

[Lukas-458]

So what's the consensus on clinics?  If there is a consenus (rather than the

usual bunfight) I'll amend the wiki pages to make it explicit that clinic

can be used for units/departments/centres in hospitals.

 

I even do not know whether there is a consensus. In Germany, we use "amenity=clinic" often for everything which has not "hospital" (in german) in their name but looks like a hospital, often the difference is just emergency=no. Many of them are healthcare=rehabilitation, is amenity=clinic then still fitting also with that?

 

Lukas


 
 

Gesendet: Montag, 13. April 2020 um 15:14 Uhr
Von: "Paul Allen" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Request for assistance in creating a tag.



On Mon, 13 Apr 2020 at 11:29, Joseph Eisenberg  wrote:



Right, that doesn't work. If the HIV clinic or department has
different details, such as a different name, opening_hours, website,
etc, then it will need to be mapped as a separate feature, such as an
amenity=clinic node inside of the amenity=hospital area.

 
Thanks for giving your view of  the usage of amenity=clinic (and, by

implication, healthcare=clinic as the wiki states it's an alternative

to amenity=clinic).  The wiki pages for healthcare=clinic and

amenity=clinic don't seem to explicitly state that these tags are

appropriate for units/departments/centres of hospitals.

 

I agree with your view.  The value "clinic" may not have been the best we

could have chosen but there doesn't seem to be any other value to use

for the X-ray department, diabetes centre, renal dialysis unit, etc. of a

hospital. Before the current crisis I was mapping my nearest general

hospital and using amenity=clinic + healthcare=clinic in this way.

 

The only reason to think otherwise is that the wiki page on healthcare

lists only two specialities for clinics: abortion and fertility, indicating that

at least one person considered clinics to be standalone and not normally

part of hospitals.

 

So what's the consensus on clinics?  If there is a consenus (rather than the

usual bunfight) I'll amend the wiki pages to make it explicit that clinic

can be used for units/departments/centres in hospitals.

 

--

Paul

 

___ 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 - traffic_signals=crossing_on_demand

[Lukas-458]

The second goal my proposal wants to message is to deprecate tagging "crossing=traffic_signals" together with "highway=traffic_signals" on the same node. Especially if you're saying this is a full crossing mapped. It breaks the highway=crossing - tagging scheme we use for all other types of crossing (except crossing=no). Some mappers use "crossing=traffic_signals" together with "highway=traffic_signals" on the same node als a shortcut for "lane traffic signal" and "foot traffic signal" because it is rendered as two traffic signals in JOSM. Or for mapping traffic signals for crossing cyclists. But I think in every case it is better to use two different (nearby) nodes for that.

 

What do you think about it?

 
Lukas

Gesendet: Montag, 13. April 2020 um 14:14 Uhr
Von: lukas-...@web.de
An: tagging@openstreetmap.org
Betreff: Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand



Hi,

oh sorry you are confused. Maybe it's too much text I think. But your conclusion is completely correct, yes.

 
 

Gesendet: Montag, 13. April 2020 um 13:47 Uhr
Von: "Andrew Davidson" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand



I'm a bit confused by your proposal, but it would seem to me that what you want to do is add crossing_on_demand to the list of values for the key traffic_signals. Is this correct?

 

 


On Mon, Apr 13, 2020 at 9:10 PM  wrote:




Hi people,

I made a proposal to reform the tagging of those traffic signals, which do only control a crossing. The proposal has two main messages: First that crossing=traffic_signals is every time a strict under-tag of highway=crossing and should not be used on the same node with highway=traffic_signals, because it makes the scheme of how we tag crossings (on nodes) inconsistent. The second is that it wants to add the value traffic_signals=crossing_on_demand as an under-tag of highway=traffic_signals, to mark for the lane-traffic that there is a traffic-signals-node whch does only control an "on demand" crossing. These sets of lane traffic signals often miss a green light because most of the time there is "default green". Also it would fit into the traffic_signals=* tagging scheme for specifying the "type" of a traffic signal.

 

The link to the proposal is here: https://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals%3Dcrossing_on_demand

 

I'm looking forward to your comments. Please (also) comment on the proposal's discussion page.

 

Yours, Lukas

User Lukas458


___
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 - traffic_signals=crossing_on_demand

[Lukas-458]

Hi,

oh sorry you are confused. Maybe it's too much text I think. But your conclusion is completely correct, yes.

 
 

Gesendet: Montag, 13. April 2020 um 13:47 Uhr
Von: "Andrew Davidson" 
An: "Tag discussion, strategy and related tools" 
Betreff: Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand



I'm a bit confused by your proposal, but it would seem to me that what you want to do is add crossing_on_demand to the list of values for the key traffic_signals. Is this correct?

 

 


On Mon, Apr 13, 2020 at 9:10 PM  wrote:




Hi people,

I made a proposal to reform the tagging of those traffic signals, which do only control a crossing. The proposal has two main messages: First that crossing=traffic_signals is every time a strict under-tag of highway=crossing and should not be used on the same node with highway=traffic_signals, because it makes the scheme of how we tag crossings (on nodes) inconsistent. The second is that it wants to add the value traffic_signals=crossing_on_demand as an under-tag of highway=traffic_signals, to mark for the lane-traffic that there is a traffic-signals-node whch does only control an "on demand" crossing. These sets of lane traffic signals often miss a green light because most of the time there is "default green". Also it would fit into the traffic_signals=* tagging scheme for specifying the "type" of a traffic signal.

 

The link to the proposal is here: https://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals%3Dcrossing_on_demand

 

I'm looking forward to your comments. Please (also) comment on the proposal's discussion page.

 

Yours, Lukas

User Lukas458


___
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] Feature Proposal - RFC - traffic_signals=crossing_on_demand

[Lukas-458]

Hi people,

I made a proposal to reform the tagging of those traffic signals, which do only control a crossing. The proposal has two main messages: First that crossing=traffic_signals is every time a strict under-tag of highway=crossing and should not be used on the same node with highway=traffic_signals, because it makes the scheme of how we tag crossings (on nodes) inconsistent. The second is that it wants to add the value traffic_signals=crossing_on_demand as an under-tag of highway=traffic_signals, to mark for the lane-traffic that there is a traffic-signals-node whch does only control an "on demand" crossing. These sets of lane traffic signals often miss a green light because most of the time there is "default green". Also it would fit into the traffic_signals=* tagging scheme for specifying the "type" of a traffic signal.

 

The link to the proposal is here: https://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals%3Dcrossing_on_demand

 

I'm looking forward to your comments. Please (also) comment on the proposal's discussion page.

 

Yours, Lukas

User Lukas458

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