Re: [Tagging] A modest proposal to increase the usefulness of the tagging list

I've just checked the history, and as far as I can tell, there has been a grand total of just 15 proposals put to voting since the beginning of the year (5 months, so 3 per month on avg.) Also, even with all the noise, there have been only about 28 messages per day on avg, which is less then

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

Yes, but that’s not the point. The presence or absence of markings do not change the fundamental operating principle of the crossing (go only when it’s green). The strips shown in the image you linked do not mean that pedestrians have priority here and can just walk across any time, no

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

From: Paul Allen Sent: Saturday, 25 May 2019 10:18 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no The labels chosen for these 4 categories are : no, unmarked, uncontrolled,

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

From: Warin <61sundow...@gmail.com> Sent: Saturday, 25 May 2019 09:49 To: tagging@openstreetmap.org Subject: Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no On 25/05/19 07:32, Paul Allen wrote: On Fri, 24 May 2019 at 22:12,

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

> What can be done here is to basically define that the different crossing=* > values imply default values for various other tags (the same way as the wiki > currently already documents what e.g. crossing=zebra or crossing=pelican > implies). I'm interested in this, in theory, but

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

From: Paul Allen Sent: Saturday, 25 May 2019 06:17 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no crossing=uncontrolled – there are road markings indicating this is

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

> Does any of this change in a jurisdiction where there is an implied > crossing at every intersection unless posted otherwise? Such purely implied crossings would be crossing=unmarked, and under the "do not map local legislation" rule, I would only map them if they have a physical presence

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

The way I see it: crossing=no – crossing here is not legal/possible crossing=unmarked – there are no road markings (or traffic signals) that indicate this is a designated crossing, but based on other factors, it’s a location where pedestrians common cross, e.g. because of lowered kerbs,

Re: [Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

This is not in line with hat others have suggested, and invalidating 2.5 million existing crossing=* tags (everything with a value different from yes/no) is a complete no go. As you said, what others suggested, and what would be a welcome addition, is to leave the existing tag untouched (it

Re: [Tagging] "Unambiguous crossings" proposals and related questions

I’ve read that whole previous discussion, and from my point of view it was just a whole bunch of completely useless noise, with everyone telling you that you aren’t making sense and you ignoring it and bulldozing your way forward. From: Nick Bolten Sent: Monday, 20 May 2019 10:48 To: Tag

Re: [Tagging] "Unambiguous crossings" proposals and related questions

"The "traffic_signals" namespace is used to describe both vehicular traffic signals and pedestrian/bicycle traffic signals, to everyone's confusion." This statement is simply completely factually wrong. a) traffic_signals is the *value* here, not the name of the tag b) there are 2 distinct

Re: [Tagging] Feature Proposal - crossing=marked

People do generally walk on this “grass” sidewalk. From: Martin Koppenhoefer Sent: Tuesday, 14 May 2019 16:04 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Feature Proposal - crossing=marked sent from a phone On 14. May 2019, at 02:24, Graeme Fitzpatrick

Re: [Tagging] Feature Proposal - crossing=marked

Haven’t checked if it shows up as an error, but technically, the grass on each side is the “sidewalk”, and it is simply a shortcoming of the current tagging schemes that it’s not possible to properly tag it as pedestrian routable area. These lowered kerbs represents points with easy access

Re: [Tagging] Feature Proposal - crossing=marked

Forgot that part: > On my walk yesterday, other than the implied crossing at every > intersection (but see "don't map local law") I noted the following: I do generally map crossings as long as they have lowered kerbs, like here:

Re: [Tagging] Feature Proposal - crossing=marked

> 1. Combined foot/cycle crossing - a side path from a combined > foot/cycleway onto a very lightly trafficked suburban street. Marked > with signs bearing the silhouette of a bicycle about 50 m in advance > of the crossing. No markings on the pavement. (This crossing is part > of my daily

Re: [Tagging] Golf tag combinations

> -Original Message- > From: Warin <61sundow...@gmail.com> > Sent: Saturday, 21 July 2018 16:55 > To: Tag discussion, strategy and related tools > > Subject: [Tagging] Golf tag combinations > > using it that way surely is 'tagging for the render' as it is not the > golf tag that is

Re: [Tagging] building=clubhouse

Personally, for a golf club, I would consider the “club base” the area that the clubhouse and related infrastructure is on only, not including the actual holes. From: Marc Gemis Sent: Thursday, 19 July 2018 15:10 To: Tag discussion, strategy and related tools Subject: Re: [Tagging]

Re: [Tagging] building=clubhouse

Sounds like something that could be tagged *in addition* to building=clubhouse to provide more detail? From: Graeme Fitzpatrick Sent: Thursday, 19 July 2018 13:41 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] building=clubhouse Not exactly clubhouse as such but

Re: [Tagging] Golf wiki page

> -Original Message- > From: Warin <61sundow...@gmail.com> > Sent: Sunday, 15 July 2018 18:41 > To: tagging@openstreetmap.org > Subject: Re: [Tagging] Golf wiki page > > Devils advocate hat firmly on. > > But what is intended? Not the height of the grass .. but the > 'smoothness and

Re: [Tagging] Golf wiki page

Looks fine to me: https://www.dropbox.com/s/tks7yumfju0wz6q/1531564818315.jpg?dl=0 From: Yves Sent: Saturday, 14 July 2018 20:15 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Golf wiki page You should pay attention to the message format, the last one is unreadable.

Re: [Tagging] Golf wiki page

From: Warin <61sundow...@gmail.com> Sent: Saturday, 14 July 2018 17:07 To: tagging@openstreetmap.org Subject: Re: [Tagging] Golf wiki page On 14/07/18 15:11, osm.tagg...@thorsten.engler.id.au wrote: While page is not the best... you seem to

Re: [Tagging] Golf wiki page

While page is not the best... you seem to misunderstand part of it. The "level" reference doesn't have anything to do the level tag. Or any tag at all. It's just saying there are 3 levels of detail at which a golf course can be mapped. As for the "How short is the grass" section, while maybe

Re: [Tagging] landcover=asphalt ; landuse=highway

In my opinion: area:highway=* for the actual road surface (there are some rules how exactly these areas should be segmented at intersections, and how these areas should be connected with the actual highway ways) surface=* on these to describe the material the road surface is made of if

Re: [Tagging] [tagging] Canoe route / nautical channels

> -Original Message- > From: Christoph Hormann > Sent: Tuesday, 3 July 2018 18:26 > To: Tag discussion, strategy and related tools > > Subject: Re: [Tagging] [tagging] Canoe route / nautical channels > > On Tuesday 03 July 2018, Multi Modaal wrote: > > [...] > > > > Summary: > > I would

Re: [Tagging] nautical channels

Maybe following the same scheme as for highways: waterway=navigable_channel (for way along the middle of the channel) area:waterway=navigable_channel (for area bound by buoys, with an intersecting node at both ends between the area and the middle line way) From:

Re: [Tagging] nautical channels

I think it’s slightly different. For canoe routes, there is generally no infrastructure along the route. While navigable channels are marked with buoys, which makes them closer to a “highway” on land than a route. So I think it’s something that belongs in the waterway namespace. If

Re: [Tagging] Canoe route

It might be best to adapt the same language used in the access tag: https://wiki.openstreetmap.org/wiki/Key:access Water-based transportation * access=* (category: any water-based transportation mode) * boat=* (covers small

Re: [Tagging] nautical channels

Without being familiar with the topic at all, and seeing that there don’t seem to be any matching tags yet, maybe something like waterway=dredged_channel ? From: Volker Schmidt Sent: Sunday, 1 July 2018 01:42 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] nautical

Re: [Tagging] tagging religion-based access

This right there is a major reason why it was a bad idea to allow “transportmode=accessvalue” and not always require “access:transportmode=accessvalue”… From: Mateusz Konieczny Sent: Saturday, 30 June 2018 04:36 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] tagging

Re: [Tagging] Feature Proposal - RFC - highway strip

Don't really have a strong opinion on it either way, just to raise a point for discussion... but if it's for emergencies, should it have some tag in the emergency=* namespace? > -Original Message- > From: Jyri-Petteri Paloposki > Sent: Tuesday, 26 June 2018 00:56 > To: 'Tag discussion,

Re: [Tagging] shop=discount

I remember about 20 years ago when I was still living in Germany I regularly went to a shop that was selling (mostly) food stuff "from the pallet", sometimes with slight transport damage (cans with dents, that type of thing). That's what I would expect to find for a shop=discount >

Re: [Tagging] shop=health

The first thing that came to mind when reading shop=health is: https://en.wikipedia.org/wiki/Health_food_store Not sure what the appropriate tag for that is. I agree that shop=health is very ambiguous. From: Mateusz Konieczny Sent: Sunday, 24 June 2018 19:15 To: Tagging Subject:

Re: [Tagging] tower:type=suspension

I was more thinking about the possibility of mapping above ground phone/data cables. Not sure if any of them are strung on what could be considered a “tower” or if it’s always a “pole”… So while there currently is primarily a power=tower + tower:type=* I could see something like

Re: [Tagging] tower:type=suspension

Not in any way involved with power mapping, but I don’t think tower:type should have necessarily any implications about what it is that’s being transmitted over the suspended cables. In the specific case of power=tower, while I guess tower:type=suspension might be considered the “default”

Re: [Tagging] public transport through service

> -Original Message- > From: Michael Tsang > Sent: Saturday, 23 June 2018 01:36 > > I have raised this topic two years ago but it seems that there is > no community consensus here. My problem is "How should we tag a > public transport through service route?" > > In my city there are the

Re: [Tagging] public_transport=platform rendering on osm-carto

> -Original Message- > From: Martin Koppenhoefer > Sent: Friday, 22 June 2018 08:03 > > a bus stop usually didn’t have a highway=platform, just > highway=bus_stop, only for platforms on stations the former is > suggested. > It is only a fraction (94k) of all bus stops (2M) that could be

Re: [Tagging] public_transport=platform rendering on osm-carto

As I previously said, I would consider this vandalism. > -Original Message- > From: marc marc > Sent: Friday, 22 June 2018 01:23 > To: tagging@openstreetmap.org > Subject: Re: [Tagging] public_transport=platform rendering on osm- > carto > > Le 21. 06. 18 à 16:27, Paul Allen a écrit : >

[Tagging] public_transport=platform_edge

I've noticed that while there is a https://wiki.openstreetmap.org/wiki/Tag:railway=platform_edge there is no generalized public_transport=platform_edge. I would propose that we allow public_transport=platform_edge as the exact same concept applies equally well to e.g. island platforms at bus

Re: [Tagging] public_transport=platform rendering on osm-carto

Everything you write is no different between PTv2 and the old tagging scheme. FIRST, all the stops, in order. THEN, all the ways that make up the route, in order. As far as I’m aware, there hasn’t been a route tagging scheme before that mixes the stops into the route before. The

Re: [Tagging] public_transport=platform rendering on osm-carto

I fully agree with everything marc said. But I think Jo's confusion comes primarily from the fact that public_transport=platform replaces BOTH highway=platform AND highway=bus_stop. So under the old tagging scheme you could have a highway=platform way or area, AND a highway=bus_stop node. In

Re: [Tagging] public_transport=platform rendering on osm-carto

>From my reading of the wiki (I wasn’t involved when PTv2 was designed), the >situation as envisioned in PTv2 would be that you have only one node, way, or >area with public_transport=platform. So the existing highway=bus_stop and >highway=platform (in cases where both are present) are merged

Re: [Tagging] public_transport=platform rendering on osm-carto

I would very much welcome rendering of public_transport=platform. But I do not think that it is reasonable to add rendering for it, and at the same moment drop rendering for highway=platform, railway=platform, highway=bus_stop, railway=tram_stop and everything else that

Re: [Tagging] emergency=lifeguard

I just randomly checked out 20 of the places currently tagged with emergency=lifeguard_base and none of them looked like something for which office=lifeguard would seem appropriate, but all of them looked like what I expected, a place where you can find lifeguards, just with more equipment and

Re: [Tagging] emergency=lifeguard

From: Martin Koppenhoefer Sent: Tuesday, 19 June 2018 18:24 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] emergency=lifeguard IMHO, if you want to tag the former, be explicit, do not use amenity=lifeguard because it is ambiguous, use something like

Re: [Tagging] emergency=lifeguard

Something like that is exactly what I as looking for… From: Graeme Fitzpatrick Sent: Tuesday, 19 June 2018 14:24 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] emergency=lifeguard On 19 June 2018 at 08:45, Graeme Fitzpatrick mailto:graemefi...@gmail.com> >

Re: [Tagging] `amenity=shelter` implies `building=yes`?

Personally, I would tag most bus shelters as building=roof. But for e.g. sun_shelter (which are usually just fabric spanned between poles) building=roof would be wrong. From: Bryan Housel Sent: Tuesday, 19 June 2018 00:47 To: Jo Willems ; osm-tagging Subject: Re: [Tagging]

Re: [Tagging] emergency=lifeguard

From: Andrew Harvey Sent: Monday, 18 June 2018 21:17 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] emergency=lifeguard Do we have any tagging scheme for “an area in which it is likely for a lifeguard to be”? I’m not sure if simply tagging an area with

Re: [Tagging] [talk-au] Mapping houses and addresses in Sydney

Oops. Sorry, that went to the wrong mailing list :/ From: osm.tagg...@thorsten.engler.id.au Sent: Monday, 18 June 2018 21:07 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] [talk-au] Mapping houses and addresses in Sydney From: Warin <61sundow...@gmail.com

Re: [Tagging] [talk-au] Mapping houses and addresses in Sydney

From: Warin <61sundow...@gmail.com> Sent: Monday, 18 June 2018 20:57 To: talk...@openstreetmap.org Subject: Re: [talk-au] Mapping houses and addresses in Sydney On 18/06/18 20:30, Andrew Harvey wrote: On 18 June 2018 at 19:21, Dion Moult mailto:d...@thinkmoult.com> > wrote: Thanks Andrew

Re: [Tagging] emergency=lifeguard

No worries. For what it’s worth, I fully agree with you. Any emergency=lifeguard[_*] that’s not anywhere close to water is pretty much guaranteed to be a tagging error. While on the topic of lifeguards, lifeguard=place on a node doesn’t really fit to beaches where there a lifeguard place

Re: [Tagging] emergency=lifeguard

> -Original Message- > From: Marc Gemis > Sent: Monday, 18 June 2018 17:59 > To: Tag discussion, strategy and related tools > > Subject: Re: [Tagging] emergency=lifeguard > > If you use Google translate from English "lifeguard" to Russian, > you get Спасатель Doing the translation in

Re: [Tagging] emergency=lifeguard

From: Warin <61sundow...@gmail.com> Sent: Monday, 18 June 2018 17:35 To: tagging@openstreetmap.org Subject: Re: [Tagging] emergency=lifeguard On 18/06/18 16:24, osm.tagg...@thorsten.engler.id.au wrote: From: Graeme Fitzpatrick

Re: [Tagging] emergency=lifeguard

From: Graeme Fitzpatrick Sent: Monday, 18 June 2018 16:01 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] emergency=lifeguard while some show a shape in one image, but other's, possibly during the northern winter, show an empty deserted beach. I would consider

Re: [Tagging] Street exits

They DO have exactly this type of living street in the Netherlands too, see https://nl.wikipedia.org/wiki/Woonerf But the particular street Peter is talking about is, on purpose, NOT such a living street. The street itself is a normal residential street, with sidewalks and raised kerbs.

Re: [Tagging] Street exits

From: Peter Elderson Sent: Friday, 15 June 2018 16:29 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Street exits The street is residential, but the exit is over a sidewalk, with a dropped curb. That's the piece I'm talking about: not the street, just the exit.

Re: [Tagging] Street exits

A quick search shows that it's probably not a "living street", as the concept does exist in the Netherlands, but does require explicit signs like in Germany: https://nl.wikipedia.org/wiki/Woonerf Also, in my experience "living streets" usually lack a clear kerb and distinction between road and

Re: [Tagging] Street exits

If you follow the road in SV, you can see that it’s a normal road with it’s own name, and connections to other roads. My first impulse was also “if it’s treated like a driveway, tag it as a driveway”, but it clearly isn’t one once you are actually in the road. It’s only the part where it

Re: [Tagging] maxweight=* specified for different axle counts

Based on the documentation for conditional tags, I would say: maxweight=10 st maxweight:conditional=17 st @ (axles >= 4), 16 st @ (axles = 3) it’s best to put the lowest limit as default into the non-conditional tag, so that if a software doesn’t or can’t parse the conditional tag it’s

Re: [Tagging] I can't support transit:lanes

From: Paul Johnson Sent: Thursday, 14 June 2018 08:00 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] I can't support transit:lanes So how is this different from placement=transition, then? placement=* defines the relation between the position of the way

Re: [Tagging] RFC: amenity=waiting_room and amenity=waiting_area

I would go for waiting_room=yes/no And if we have waiting_room=foo/bar subtypes (no idea what subtypes there may be) for amenity=waiting_room in the future, then this naturally also applies to waiting_room tags on other features with any value other than no implying that there is a waiting

Re: [Tagging] RFC: amenity=waiting_room and amenity=waiting_area

These both look pretty straight forward. I don’t see anything objectionable at first glance. It might be interesting to explore how these interact with public_transport=platform. (e.g. train station, you got the platform edge, and behind that you have benches or individual seats along most

Re: [Tagging] The endless debate about "landcover" as a top-level tag

From: Mateusz Konieczny Sent: Wednesday, 13 June 2018 19:49 To: Tag discussion, strategy and related tools Cc: Tag discussion, strategy and related tools Subject: Re: [Tagging] The endless debate about "landcover" as a top-level tag 13. Jun 2018 11:36 by marc.ge...@gmail.com

Re: [Tagging] The endless debate about "landcover" as a top-level tag

For me, the situation (as it should be, not as it is) is pretty clear. Landuse describes how the land is used. residential, industrial, commercial, retail, military, farmland, forestry, ... None of these have a fixed implication of what's on the land. Landcover

Re: [Tagging] I can't support transit:lanes

No you don’t. transit:lanes describes how the lanes from the end of one way connect to the end of another way in the direction of traffic flow. For each pair of from/to ways, there is going to be exactly one node where they connect. That is your via node. From: Paul Johnson Sent:

Re: [Tagging] I can't support transit:lanes

From: Simon Poole Sent: Tuesday, 12 June 2018 01:44 To: tagging@openstreetmap.org Subject: Re: [Tagging] I can't support transit:lanes You are seriously telling me that if you have two ways that share a node, you are unable to figure out what that node is without having it explicitly

Re: [Tagging] I can't support transit:lanes

From: Bryan Housel Sent: Tuesday, 12 June 2018 01:12 To: osm-tagging Subject: Re: [Tagging] I can't support transit:lanes Two issues here. First, the tag is not “transit:lanes” the tag is “transit” and it can be used with the generalized “:lanes” suffix. There are general rules

Re: [Tagging] I can't support transit:lanes

From: Bryan Housel Sent: Tuesday, 12 June 2018 01:12 To: osm-tagging Subject: Re: [Tagging] I can't support transit:lanes I’ve already written plenty of code to deal with turn restrictions. There are lots of rules for splitting and joining things to other things depending on where the

Re: [Tagging] emergency=fire_alarm_box

Well, I’ve often seen their location marked on emergency plans. I agree that they aren’t something that should normally be rendered at most of the usual zoom levels used for OSM, but once you get into detailed indoor mapping, I think they are something that’s worthwhile mapping. From: Paul

Re: [Tagging] emergency=fire_alarm_box

And many other places, yes… that’s why I was surprised to see that emergency=stop_button has only been used a single time worldwide and there don’t seem to be any other similar values in the emergency key. From: Philip Barnes Sent: Tuesday, 12 June 2018 00:26 To: Tag discussion, strategy

Re: [Tagging] emergency=fire_alarm_box

From: Warin <61sundow...@gmail.com> Sent: Monday, 11 June 2018 17:34 To: tagging@openstreetmap.org Subject: Re: [Tagging] emergency=fire_alarm_box On 11/06/18 15:29, osm.tagg...@thorsten.engler.id.au wrote: On a remotely related note, while looking

Re: [Tagging] Feature Proposal - RFC - Lounges

From: Stephen Doerr Sent: Monday, 11 June 2018 21:18 To: Tag discussion strategy and related tools Subject: Re: [Tagging] Feature Proposal - RFC - Lounges My experience may be different from yours, but no one I know talks about a 'waiting room' in an airport. The general waiting area is quite

Re: [Tagging] I can't support transit:lanes

From: Jo Sent: Monday, 11 June 2018 17:47 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] I can't support transit:lanes Name should indeed be changed, but I'd go for lanes:transition, so it groups with the other lanes related tags. Not sure if that is a good type

Re: [Tagging] Fwd: Feature Proposal - Voting - Dog poop area (dog_toilet)

There is already: amenity=waste_basket + waste=dog_excrement often co-located with a: https://wiki.openstreetmap.org/wiki/Tag:vending%3Dexcrement_bags Tagging of collection bags and bins should probably make use of existing tags for such features instead of adding new ones.

Re: [Tagging] emergency=lifeguard

From: Andrew Harvey Sent: Monday, 11 June 2018 15:31 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] emergency=lifeguard > Also, water_rescue_station is probably identical to lifeguard_base Agree based on the description given at

Re: [Tagging] emergency=fire_alarm_box

Just because something “can be found just about anywhere” isn’t really a valid argument for not mapping it. If someone is doing detailed indoor mapping of building and wants to map emergency features, the location of fire alarms is certainly something I would consider to be worthwhile

Re: [Tagging] emergency=fire_alarm_box

I noticed there are also 24 uses of emergency=fire_callbox, which I assume is something similar. And, surprising, just 1 uses of a more generic fire_alarm. I'm not sure if there really is an important enough distinction between a fire alarm box and a fire alarm as you find them inside

Re: [Tagging] emergency=lifeguard

These are different things, and the differentiation should definitely not simply thrown away. Though I’m not fundamentally opposed to making it a hierarchical tag along the lines of: emergency=lifeguard lifeguard=base/place/platform/tower Also, water_rescue_station is probably

Re: [Tagging] emergency=first_aid_kit

That seems reasonable to me. From: Bryan Housel Sent: Monday, 11 June 2018 14:08 To: osm-tagging Subject: [Tagging] emergency=first_aid_kit I was looking at https://wiki.openstreetmap.org/wiki/Key:emergency today. Can we add a tag for `emergency=first_aid_kit` ? thanks, Bryan

Re: [Tagging] Feature Proposal - RFC - Sauna

It might be interesting to tag the presence of a cold plunge pool/dunking pool. > -Original Message- > From: Jyri-Petteri Paloposki > Sent: Monday, 11 June 2018 01:47 > To: tagging@openstreetmap.org > Subject: Re: [Tagging] Feature Proposal - RFC - Sauna > > On 10.06.2018 18:34,

Re: [Tagging] Feature Proposal - RFC - Lounges

I fully agree that something like a “normal” waiting area, like the area at the gate for an airport, or the waiting room at a hospital, dentist or whatever is not a lounge. Nobody proposed to tag these as amenity=lounge. The proposal is for “A distinct tag for lounges, such as those in

Re: [Tagging] Feature Proposal - RFC - Lounges

> -Original Message- > From: ael > Sent: Sunday, 10 June 2018 23:26 > > In British English, a lounge first and foremost is a room in a > private dwelling. Other uses have "leaked in" from other dialets > and while now fairly well understood in a limited number of > contexts, they are

Re: [Tagging] Feature Proposal - RFC - Sauna

If you are tagging one individual leisure=sauna, it makes sense that the sauna key has only one value. But if you are tagging sauna=* on a hotel or other larger object that contains a sauna, there might be different ones available. In that case, there should be some defined way to allow

Re: [Tagging] Feature Proposal - RFC - Lounges

A “waiting room” is something very different from an airport lounge. In the context of an airport, a waiting room (or rather, waiting area) is something like this: https://upload.wikimedia.org/wikipedia/commons/8/8d/Kolkata_Airport_New_Terminal_gate_waiting_area.jpeg They are part of

Re: [Tagging] Access=no for bus lanes

Depending on the exact situation, it might be necessary to do something like: access=no bus=designated foot=yes or vehicle=no bus=designated or motor_vehicle=no bus=designated or any number of other variants. It’s important to look closely at the transport mode

Re: [Tagging] Lifeguards

I agree that the 5 different values shown on the wiki describe distinctly different things and should all be retained. From: Andrew Harvey Sent: Friday, 8 June 2018 20:41 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Lifeguards I strongly disagree that they are

Re: [Tagging] Access=no for bus lanes

To be a bit more specific about it: All access tags follow the pattern: transport mode = access value All the different transport modes form a tree, as can bee seen here: https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation “access” is the key used for the

Re: [Tagging] The endless debate about "landcover" as a top-level tag

I don’t think anyone has asked for the deprecation of landuse=forest, landuse=grass or natural=scrub or whatever. Instead, to focus back down to the original issue, what is asked for is proper support for landcover in the default map style (in addition to whatever is already in there)

Re: [Tagging] RFC proposed water property key 'ephemeral '

I would like to repeat (slightly extended) the contents of my previous post of how to interpret these tags: The default state (no tags) is: water (usually) always present The seasonal, intermittent and ephemeral tags (allowing season or month timeframes in addition to yes) say: The

Re: [Tagging] roundtrip

The real question, which as far as I can tell you haven’t answered, is: Does that same vehicle, after completing its route, start at the beginning of the same route again? Based on your description, the route as mapped is A1->B->C->D->E->A2. Can I get on at E, stay on the vehicle, and

Re: [Tagging] roundtrip

From: Philip Barnes Sent: Sunday, 27 May 2018 03:53 I enjoy linear walks from a to b as you can cover more ground, or at least more diverse ground, 2.pi.r and all that. Generally they involve public transport for one of two parts but its still a round trip. Bus from

Re: [Tagging] roundtrip

If the route as a whole is a roundtrip, then exactly that point. Let’s assume the route has stops: A1 B C D E A2 A1 and A2 may be exactly the same point or close to each other, but that doesn’t matter, because for a roundtrip route, I would expect the vehicle to visits: A1

Re: [Tagging] roundtrip

Or to express it even more general: If you start at any stop, and remain on the vehicle, you will at some later point get back to the stop you started on. From: osm.tagg...@thorsten.engler.id.au Sent: Friday, 25 May 2018 20:23 To: 'Tag discussion,

Re: [Tagging] roundtrip

I interpret roundtrip as “you can get from a stop to another stop that’s *before* it in the list of stops by simply remaining in the vehicle”. You can have routes where the start and stop are the same location, but this is not true (as the vehicle always goes on to serve another route after

Re: [Tagging] RFC proposed water property key 'ephemeral '

That is actually pretty strongly dependant on El Nino: http://www.bom.gov.au/climate/updates/articles/a008-el-nino-and-australia.shtml The shift in rainfall away from the western Pacific, associated with El Niño, means that Australian rainfall is usually reduced through winter–spring,

Re: [Tagging] RFC proposed water property key 'ephemeral '

The way I interpret it: The default state (no tags) is: water always flows The seasonal, intermittent and ephemeral tags says For these times, the explicit state is: the water always flows, is intermittent, or is ephemeral For all other times, the default state is: the water

Re: [Tagging] RFC proposed water property key 'ephemeral '

If I’ve understood it correctly, I would tag that as: seasonal=winter,spring,autumn ephemeral=summer From: Mateusz Konieczny Sent: Thursday, 24 May 2018 16:28 To: Tag discussion, strategy and related tools Cc:

Re: [Tagging] Sample tagging for highways with no lane markings

From: Javier Sánchez Portero Sent: Wednesday, 23 May 2018 17:27 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Sample tagging for highways with no lane markings Anyway, for your example of the LR-333 road, most of the

Re: [Tagging] opening_hours:sign=no - RFC

> -Original Message- > From: Warin <61sundow...@gmail.com> > Sent: Wednesday, 23 May 2018 09:31 > >> Could not this information be included in the note tag? > > note is free text for mapper > > unsigned is also used by tools like http://qa.poole.ch/ > > I don't think any data consumer

Re: [Tagging] Sample tagging for highways with no lane markings

From: yo paseopor Sent: Wednesday, 23 May 2018 04:11 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Sample tagging for highways with no lane markings oneway=no lanes=1

Re: [Tagging] Sample tagging for highways with no lane markings

Personally, I tend to tag roads that are wide enough for 2 lanes (two cars can pass each other without noticeably slowing down) and which are clearly meant to be two lane (one lane each direction) roads with: lanes=2 divider=no Yes, I know that is in violation of the strict reading of the

  1   2   >