Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand
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 PMwrote: 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
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 PMwrote: 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
Re: [Tagging] Request for assistance in creating a tag.
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 Eisenbergwrote: 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] insurance health
"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
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] Feature Proposal - RFC - Refugee Site Location
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
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] 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órkowskiwrote: 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
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órkowskiwrote: 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
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
"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] iD semi automatic adding public_transport to aerialway=station
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 - traffic_signals=crossing_on_demand
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 Allenwrote: 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
[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] Feature Proposal - RFC - traffic_signals=crossing_on_demand
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
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
Re: [Tagging] Is there any tagging scheme for carillons already?
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?
"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
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 Koppenhoeferwrote: 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] Is there any tagging scheme for carillons already?
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
Re: [Tagging] Doorzone bicycle lanes
"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 Michelwrote: 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
Re: [Tagging] Is there any tagging scheme for carillons already?
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] Tag:amenity=motorcycle_taxi not approved
"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] 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
Re: [Tagging] Doorzone bicycle lanes
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] 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
Re: [Tagging] Feature Proposal - Voting - traffic_signals=crossing_only
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
[Tagging] RFC Start - extend telephone covers
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] tactile_paving=* on highway=steps ?
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
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