Re: [Tagging] Feature Proposal - RFC - Kerb

I assume that if I have a way that runs along the physical location of the kerb (e.g. because it's a closed way or part of a multi-poly that's used to define a landuse area) I could tag that way with kerb= to indicate the type of kerb? In that case, how should the type of kerb shown in this

Re: [Tagging] Storm drains

manhole=drain is clearly wrong I would say. Around here most of the storm drains are identical in appearance to regular manholes: round, about 60 cm diameter, flat on the asphalt, with a removable 2-3 cm thick iron lid - the lid is just perforated. Seem's there's no picture in the wiki, so

Re: [Tagging] Feature Proposal - RFC - Kerb

I assume that if I have a way that runs along the physical location of the kerb (e.g. because it's a closed way or part of a multi-poly that's used to define a landuse area) I could tag that way with kerb= to indicate the type of kerb? I believe that to be an acceptable method. However

Re: [Tagging] Feature Proposal - RFC - Kerb

However, if someone really wants to tag a highway=* to indicate a kerb is on the outer edge, it's better to not use the kerb=* key but rather kerb:left/kerb:right/kerb:both, so there is no confusion. Ah yes, kerb:both, I didn't think about that. Still pretty new to mapping and still getting used

Re: [Tagging] Feature Proposal - RFC - Kerb

Perhaps. I'm ambivalent about this type of usage (i.e. I don't plan to do this myself, but if someone wants to I'd rather them use these tags rather than the primary kerb=* key). I'd say we should get more input before adding kerb:both/left/right, and we should probably keep that as part of an

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

You'll probably also need a type of route relation for this? Also, public_transport=platform is only valid with at least one transport type specific tag, e.g. bus=yes or tram=yes. So there should probably be a walkingbus=yes or walking_bus=yes tag on that. (Whichever is chosen, it should be

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

To add to this, based on a discussion in #osm, please be careful what you map. If there are poles with signs for the stops, map them. If there are public signs describing the routes, map them. But any stops or routes that are private information only between organizers and parents/students

Re: [Tagging] Feature Proposal - RFC - key:spacing=*

> -Original Message- > From: Daniel Koć > Sent: Monday, 7 May 2018 06:03 > > However I think that measuring spacing is worse than just measuring > the number of trees. It's more mapper friendly and less error prone. I've you have a long road with trees along it, it's easy

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

Without a "driver", fixed "stops" and a defined schedule, that sounds more like what's currently already mapped using route=foot relations? > -Original Message- > From: Erkin Alp Güney > Sent: Saturday, 5 May 2018 23:28 > To: tagging@openstreetmap.org > Subject:

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

If there are actual poles and stop signs, you can only “board” at these places and at specific times, and the “driver” stays with the group from the first to the last stop, then yeah, I can see this as being very different from a “school crossing guard” which generally stays at one specific

Re: [Tagging] tagging of one-way cycle lanes

> -Original Message- > From: Marc Gemis > Sent: Monday, 14 May 2018 18:55 > >> cycleway:left=opposite_lane (or cycleway:right, depending) >> oneway:bicycle=no > > I would expect that the above is for the case that there is only a > contra-flow lane. And that for

Re: [Tagging] tagging of one-way cycle lanes

From: osm.tagg...@thorsten.engler.id.au Sent: Monday, 14 May 2018 18:37 if there is only one cycle lane, but it’s allowed to travel in both directions on an otherwise one-way road use: cycleway:left=opposite (or cycleway:right, depending which side, as

Re: [Tagging] tagging of one-way cycle lanes

As far as I can tell, for two-way streets, there is no differences, it’s just more explicit. Given the difference in usage numbers (1522 vs. 254509) I would go with just cycleway=lane (I actually checked these numbers before I made that last post). For one-way streets, I’m not sure how

Re: [Tagging] tagging of one-way cycle lanes

> -Original Message- > From: Marc Gemis > Sent: Monday, 14 May 2018 19:40 > > The wiki page on cycling infrastructure from the Lübeck Stammtish, > mentioned this explicitly "und/oder", see [1] > > I also see that they use cycleway:left/right=sidepath, I have never

Re: [Tagging] tagging of one-way cycle lanes

From: Martin Koppenhoefer Sent: Monday, 14 May 2018 19:07 according to the wiki, you can't use "cycleway:left" and "cycleway:right" at the same time. Would you agree this requirement should be removed? This particular wiki page seems to be somewhat misleading in that

Re: [Tagging] tagging of one-way cycle lanes

The “lanes=count” key gives the number of full lanes for motorized traffic. This gives a good estimate for total carrying capacity for vehicle traffic on this road for software that isn’t too concerned about the details, or simply older software that doesn’t know about the :lanes suffix. If

Re: [Tagging] tagging of one-way cycle lanes

If I may correct your suggestion, that’s not quite right. To quote the wiki for lanes: The lanes=* key should be used to specify the total number of marked lanesof a road. The following lanes should be included: * General purpose

Re: [Tagging] tagging of one-way cycle lanes

See also: https://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#The_issues_with_the_lanes_tag (which is from the approved proposal that established the :lanes suffix). From: osm.tagg...@thorsten.engler.id.au Sent: Thursday,

Re: [Tagging] tagging of one-way cycle lanes

From: Paul Allen Sent: Saturday, 12 May 2018 05:49 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] tagging of one-way cycle lanes On Fri, May 11, 2018 at 8:06 PM, Paul Johnson

Re: [Tagging] tagging of one-way cycle lanes

I'm not sure why we are wasting any time on discussing possible changes to the definition of the lanes tag her. The tag goes back to pretty much the start of OSM and is in widespread usage. Any change in definition that fundamentally changes what value goes into the key given a specific

Re: [Tagging] tagging of one-way cycle lanes

> From: Marc Gemis > Sent: Friday, 11 May 2018 14:44 > > When the "lanes" tag was introduced the community choose to only > count the "full width segments for motorised traffic". Perhaps > because traffic law in some countries (e.g. Belgium [1]) define > them that way.

Re: [Tagging] tagging of one-way cycle lanes

I've always been editing using JOSM and using the "lane and road attributes" mapstyle for visualization (which is pretty much the only editor/map style I'm aware of that has support for the large majority of lane related tags, making it pretty much the defacto standard implementation given the

Re: [Tagging] tagging of one-way cycle lanes

I would tag that as: oneway=yes lanes=3 lanes:psv=1 vehicle:lanes=yes|yes|no psv:lanes=yes|yes|designated parking:lane:left=parallel parking:condition:left=ticket sidewalk=both This sign clearly defines how many lanes there are and that it’s a psv lane (not just a bus lane):

Re: [Tagging] complete tagging of all 'right of way'-cases FOLLOWUP

A few comments: * I don't think this should "obsolete" the highway=give_way nodes completely. For simple cases with oneway=yes roads the highway=give_way node on the way is the easiest way to map them. Also for any "four-way give way" situation, tagging the intersection node is clear and

Re: [Tagging] tagging of one-way cycle lanes

A lot of residential roads here don’t have markings, like here: https://www.google.com.au/maps/@-27.2131302,153.0260346,3a,55y,45.38h,68.9t/data=!3m4!1e1!3m2!1sci60ZE7unqEW6wDOP9Gh6Q!2e0 But they are clearly intended to be 2 lane roads. (Which can be seen from the reflectors that are

Re: [Tagging] tagging of one-way cycle lanes

> From: Martin Koppenhoefer > Sent: Friday, 11 May 2018 21:45 > while I would generally agree with the idea of having officially 3 lanes, > I would have thought that lanes would have to be painted on the road, not > just indicated by signs. Under the strict reading

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

If they are unmarked on the ground, are they documented somewhere? Or is it simply a case of "this is a common route a lot of people walk during certain times as there is a strong flow of people from A to B and this is the most commonly used route"? (In which case they aren't really something

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

Well, but based on your description, these are not planned routes in any way. They are purely transient emergent behaviour based on the fact that a lot of people want to move between these two points, and this is the obvious way to go. Take the people away, and the phenomenon disappears. This

Re: [Tagging] Feature Proposal - RFC - key:spacing=*

> -Original Message- > From: Christoph Hormann > Sent: Sunday, 6 May 2018 03:37 > To: Tag discussion, strategy and related tools > > Subject: Re: [Tagging] Feature Proposal - RFC - key:spacing=* > > If i try to ignore the rendering related

Re: [Tagging] access=disabled

With emergency and disabled as part of access restrictions, they central question becomes, are these access tag values (like yes, no, private, destination, delivery, customers, ...) or transport modes (like foot, bicycle, motor_vehicle, ...) access=no emergency=yes implies that it is a

Re: [Tagging] access=disabled

> > With emergency and disabled as part of access restrictions, they > central question becomes, are these access tag values (like yes, no, > private, destination, delivery, customers, ...) or transport modes > (like foot, bicycle, motor_vehicle, ...) > > this is already documented on the access

Re: [Tagging] Seasonal, intermittent, and ephemeral water tags

Sounds like candidates for: https://wiki.openstreetmap.org/wiki/Proposed_features/floodplain https://wiki.openstreetmap.org/wiki/Key:flood_prone https://wiki.openstreetmap.org/wiki/Tag:landuse=basin Depending if natural or man made. The floodplain proposal definitely needs more work,

[Tagging] type=route tagged on a way?

I've noticed there are 9377 cases of type=route tagged on ways instead of relations: https://taginfo.openstreetmap.org/tags/type=route I've been unable to find any documentation of this tagging approach on the wiki.

Re: [Tagging] Conflicting wiki docu for aerialway=goods and aerialway=station

Not involved in aerialway tagging at all, but I would say that things like aerialway=station or railway=station applies to each place with significant infrastructure where a vehicle might stop for any type of loading/unloading activity, including goods/freight only. While

Re: [Tagging] type=route tagged on a way?

Well, if this particular way of tagging things is generally supported by data consumers, then I would consider it a documentation error instead of a tagging error. But if it’s not used by data consumers in this form (while the same information on a relation is), and clearly the people

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] 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] 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] 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] Feature Proposal - RFC - Walkingbus_stop

I agree that it definitely is "transport" and that it has all the features (pole, waiting area, timetable, fixed route) that make it very suitable to map as public_transport. The only thing we have to decide upon is how "public" a public_transport must be. Does it have to be available to all

Re: [Tagging] Conflicting wiki docu for aerialway=goods and aerialway=station

From: Martin Koppenhoefer Sent: Wednesday, 16 May 2018 04:39 Bonus question: would you say it makes sense to add public_transport=station (plus eventually subtags to state which kind of vehicle) to aerialways? IMO (for whatever that’s worth), aerialways and their

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

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

As I said, it has poles, areas people wait, a fixed route, a repeating timetable, there is a "driver" and it's purpose is specifically to transport people from one location to another. The fact that you have to put in personal effort (walking) during the transportation within this framework

Re: [Tagging] tagging arbiters (gone OT)

It’s not an carto-osm bug, it’s a level lower: https://github.com/openstreetmap/osm2pgsql/issues/230 If that ever gets implemented properly, then carto-osm and other data users can make use of it… From: Paul Johnson Sent: Saturday, 19 May 2018 12:12 To: Tag

Re: [Tagging] Seasonal, intermittent, and ephemeral water tags

> -Original Message- > From: Warin <61sundow...@gmail.com> > Sent: Saturday, 19 May 2018 12:33 > To: Tag discussion, strategy and related tools > > Think I have raised this before but not come to any firm conclusion > myself. > > I think that tagging > > seasonal=summer > >

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 - 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

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] 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 - 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] 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] 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] 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] 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] 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] 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] [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

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] `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] 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] 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] 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] 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] 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] 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

> -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=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] 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=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=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=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] 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] 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] 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] 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] 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

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] 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] 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: 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] 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] 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] 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] 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

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

  1   2   >