Proposal talk:Advanced footway and cycleway

Opinions, shows of hands, general thoughts

I much prefer Proposed_features/right_left to this proposal right now. It is patterned after in-use tags such as name:left, it's more generally useful (generative! composeable!), and it explains itself better. --achadwick 16:21, 2 February 2009 (UTC)

Proposed_features/right_left has a completely different purpose. It aims at standardizing direction-dependant tags, while this proposes a tagging schema for a certain application. If you don't understand something in this proposal, please ask about it. --Driver2 16:35, 2 February 2009 (UTC)

I was a bit confused by the Proposal page template being left expressed with asterisks when we're talking about 4 or 5 discrete strings on each side of the "=" sign. Also by why so much reference is made to Proposed_features/Properties_for_Tags (about half of the non-tabular part of the Tagging section) and its dot-notation. Can I suggest losing all references to that abandoned proposal, thus simplifying this proposal? In addition, making the green template box into a summary would be very helpful indeed. --achadwick 17:36, 2 February 2009 (UTC)

You can. However it was often critized about these kind of tagging schemes that you can't define properties of the ways anymore. That's because I have included this in here. --Driver2 17:42, 2 February 2009 (UTC)

I use the advanced footway like footway:right.surface=unpaved for the sidewalks now. I'll try it for a routing for wheelchair users: Rollstuhlfahrer-Routing -- Astrid 17:01, 6 April 2009

Resolve ambiguity of "footway"

Wouldn't this be a good time to resolve the ambiguity of the tag "footway"? What I mean is that footway is described as mainly/exclusively for pedestrians. It is the mainly that is rather annoying, as people may tag anything they personally consider a footway and there are no clear rules. It also means that there is a difference between your proposed tag "footway=right" and "highway=footway". When you tag a sidewalk with footway=right this means a sidewalk, as in exclusively dedicated to pedestrians and off limits to vehicles and bicycles. The way highway=footway is currently used, it may mean the same, or it may be an unmarked way that is open to other traffic or it may be a track. I think it is problematic if the same term used as a value means something different from when it is used as a tag, so I suggest changing the defintion of highway=footway to "exlusively designated for pedestrians" as well. --Nop 20:37, 26 December 2008 (UTC)

Fine with me. Since footway implies foot=designated and designated usually is used as 'exclusively'. At least in Germany it is used for ways that are exlusively for pedestrians. However it is also sometimes used for small ways that might also be allowed for some vehicles. It would be nice if this could be resolved. --Driver2 20:33, 27 December 2008 (UTC)

Unfortunately, this is not true. Footway is frequently used as an all-purpose tag, merely indicating that someone has passed by here on foot. --Nop 17:46, 23 February 2009 (UTC)

It is not true that it is used for 'exclusive' footways but for others as well? How often it is used for what kind of way is near to impossible to determine. --Driver2 19:09, 23 February 2009 (UTC)

Oneway

Seems like a good approach! One thing that's missing and probably common enough to include here is cycleways in conjunction with oneway streets and bidirectional cycleways. This might fit in nicely: cycleway=left, cycleway:left.oneway=false if there's a cycleway on the left side of the road that's open in both directions. This works whether or not the highway is oneway. For this to work, these side-cycleways should be oneway by default. Robx 07:58, 27 December 2008 (UTC)

I'm not sure if many cycleways here are oneway. But why not? --Driver2 20:35, 27 December 2008 (UTC)

Until this is properly explained I think this proposal is useless. What do we need to have inside the tag? All info that otherwise can't be directly associated. So the main points that we need to know are:

• Is the cycleway on both sides of the street or only on one
• If on both sides, is each side oneway or does either of them allow for traffic in each direction or each oneway only
• If on one side: is it oneway or not.
• For all of the above, is it a track or a lane
• The direction / oneway=no/oneway=yes of the highway itself is then unimportant, and any routing software can analyse it on top.

I don't get how to properly define each of the above situations, please explain step by stet. If the above is unresolved, correct autorouting is impossible. Don't get me wrong here, just because it is very complex, does not mean that I favour in any way to have seperate cycleways. Once cycleways are drawn seperate autorouting preferences become impossible, because no blody routing software will be able to analyse alongside what kind of street a way will go. And while a (old system) cycleway=lane on a highway=residential is usually nice to cycle along, a cycleway:track on a highway=primary shopping street in the middle of the city is amongst the worst nightmare if you want to quickly get from A to B. So yes, the cycleway has to be tagged on the same line as the principal highway, but every damn possibility of direction and side of the street has to be blody clear.--Extremecarver 20:10, 4 September 2009 (UTC)

Segregated cycle- and footway?

There is a proposition on German roads tagging which distinguishes between separate and common cycle- and footways. You may have reasons to ignore this aspect, but reason should be stated why it should be overruled by your proposition. Ipofanes 14:58, 27 December 2008 (UTC)

Could you please tell me which one of these you can't tag with this proposal? --Driver2 20:07, 27 December 2008 (UTC)

I don't see a hint to the segregated tag here. Ipofanes 10:46, 2 January 2009 (UTC)

You can use path, so nothing prevents you from using path.segregated=yes. --Driver2 16:32, 2 January 2009 (UTC)

cycleway:left or left:cycleway?

For some reason I always tend to have a different opinion on this. People seem to suggest cycleway:left, while I think left:cycleway is more natural (as it's the cycleway of the left side of the street, rather than the left side of the cycleway).

The same argument goes for tags like bicycle:oneway=no whereas other people often suggest oneway:bicycle=no. I guess it's a point of view, but shouldn't we have proper rules on this to reduce ambiguity? --Eimai 17:03, 27 December 2008 (UTC)

I guess both ways are possible. That's how I would understand it:

• cycleway:left=*: 'left' is a parameter for 'cycleway', so it's the 'left cycleway'.
• left:cycleway=*: 'left' points to the left side of the street and 'cycleway' is a subkey that defines the whatever properties the cycleway needs.

How would you define what ways a street has? With both=*, left=*, right=*? If you would still want to use cycleway=* .. I would find cycleway:left=* more logical, since 'cycleway' is the main key that should come first. --Driver2 20:20, 27 December 2008 (UTC)

cycleway next to road

this case should IMHO be mapped seperately, because:

• the crossings with other ways are most probably not the same then those of the street
• imagine some more parked cars and you don't join or cross the street any more
• the way is seperated by green from the street (and therefore not crossable)

I admit that this case is on the limit, and with even less seperation could well be tagged as a track. According to my experience (metropolitan/urban) mostly the seperation green (dependant on the context) would be longer / less passable. Dieterdreist 20:06, 7 January 2009 (UTC)

Even with more cars parked at least pedestrians would still be able to cross the street at will, as well as most cyclists. There are often wide enough spaces between cars and the green is not very wide. Even if there are specific situations where you can't cross the street, that doesn't mean you never can. On the contrary, most of the time you probably can. For that reason, I wouldn't map it as a seperate way. A seperate way would give the impression you can never cross over to the road. If the green would be along the whole way and maybe a bit wider or grown higher, it would be another story. You could still cross over to the street (you could also climb a wall to do that), but it's nothing you would normally do. However crossing over a parking spot (maybe even with a car parked) is nothing unusual. --Driver2 23:43, 7 January 2009 (UTC)

There won't be any missed potential advised crossing points, if, (at most) one adds "extra" connections in places where there's any way tagged with highway=* on the "other" side of the road (driveways mostly). Routing across "open land" will anyway require deducing what lies in the areas between features, i.e. if a footway is parallel and close to a road and there isn't any feature (barrier, landuse, building etc.) drawn inbetween, it's a sidewalk with direct access all along. I'm confident that in the really long term OSM data will evolve to cover anything down to (wheelbending) curbstones. Starting with sidewalks and exact (legal) crossing topologies is the first step towards that. Alv 14:52, 17 August 2010 (BST)

Editor software support

When a piece of editor software such as JOSM, OSM2Go reverses a way, must all tags on it which are =left or =right be reversed for consistency? I think doing this will be overreaching and error-prone. Not doing so will cause data rot in the long run. How will this proposal square that? --achadwick 16:19, 2 February 2009 (UTC)

It is obvious that it has to be reversed, if this is done with all tags automactially, just a defined list or maybe only warns the user, depends on how the devlopers want to handle it. --Driver2 16:48, 2 February 2009 (UTC)

Okay, so it isn't overreaching and it doesn't lead to data rot. Perhaps a small functional spec should be added for this to the main proposal, listing all the tags which would need to be reversed, with before and after states. Real simple stuff, but it does help to spell it out. --achadwick 17:22, 2 February 2009 (UTC)

implying values to highway=*

I do not like the way footway and/or cycleway are implied to highway, when nothing is stated, nothing should be assumed. For instance, tagging all highway=secundary around the rural locations of a country with footway=none is meaningless. You do not need to imply footway or cycleway at all, and if there is a need to indicate sidewalks than do so by tagging urban roads. Besides, many places I have been, I would have tagged footways separated from the roads for several reasons, such as clear separation from the road, have separate crossing or diversions when passing obstructions, etc. I end up with marginal areas where a sidewalk can be tagged together with the road it follows. Another reason is to add tags for surface values, most roads are tarmac or something similar, while sidewalks often are cobblestone or tiles. --Skippern 20:05, 3 March 2009 (UTC)

You can't assume 'nothing'. You can either assume that there IS a sidewalk or that there is NONE. The default values are open for discussion of course. But at least for something like 'residential', I would assume that there are footways, else it would be very much work to add it everywhere.

As for the surface values. You can also use subtags for properties like footway:right.surface=unpaved. --Driver2 22:15, 3 March 2009 (UTC)

Ok, so assume there is sidewalk on residential, but other type of roads are very much outside the urban sphere, so it can be safe to assume NONE. I do not like left/right tags, so I would tag the footway along the road as a separate feature. --Skippern 18:34, 4 March 2009 (UTC)

There is still one example that say highway=secondary would imply footway=both. If there's no solution yet, the page should at least be consistent. --ThyMythos 20:08, 3 June 2009 (UTC)

How to tag a parking lane or line of trees

Hi,

as I try to collect requirements for a navigation software for blind persons, I wonder how these lanes will be represented in this scheme?

--Lulu-Ann 07:08, 16 May 2009 (UTC)

Not at all. --Driver2 10:56, 16 May 2009 (UTC)

Thanks Driver2! - As far as I watched it, you are pretty ambitioned to support tags for wheelchair drivers. Nice comment from you for another group of disabled persons. :-( --Lulu-Ann 12:17, 21 September 2009 (UTC)

what about parking=lane --Cbm 11:48, 16 May 2009 (UTC)

Expanding this proposal to include multi-lane tagging

Hi everybody, I hope the following idea has not yet been mentioned: this proposal could easily be expanded to describe roads with several lanes by multiple use of "left:" and "right:" in the following way:

1. Use the scheme left:cycleway=* instead of cycleway:left=* to tag a cycleway on the left side of the street. For example to tag a cycleway where walking is not permitted on the left side of the street one would add left:cycleway=track and left:foot=no

2. Use n times "left:" to describe n lanes on the left side of the street. To describe for example a footway where bicycling is not permitted on the left side of the already tagged cycleway (see 1.) one would use left:left:footway=yes and left:left:bicycle=no

3. Maybe on the right side of the street mentioned in 1. and 2. there is a parking lane where cars are parking in parallel to the street. This could easily be tagged as right:parking_lane=parallel. If next to the parking lane there is a line of trees one would add right:right:line_of_trees=yes. Maybe next to that line of trees there is a footway where bikes are allowed. This could still easily be tagged as right:right:right:footway=yes and right:right:right:bicycle=yes

How do you like that idea? I find it really intuitive! --Santiago1504 21:32, 3 June 2009 (UTC)

Well, you will

• get very long tags (is that left:left:left:left really necessary? Couldn't we just do, say, "left4"?)
• and quite a lot of them (probably inevitable, and I'd like some nice frontend anyway).

Other problems I can see:

• It reduces the usefulness of primitive statistics like tagwatch.
• It won't instantly work with renderers that only recognize 100% matching tags. (There are similar problems for solutions using separate ways.)
• It doesn't support advanced features like lane based turn restrictions (junction layouts). Generally, it's impossible to refer to lanes in relations.

Nevertheless, I can imagine it would be used. It fits into the OSM tradition of "the easiest thing that could possibly work" hacks. And surprisingly, I kind of like it right now. (Except for the fact that I'd prefer numbers to right:right:right:right:right...) --Tordanik 22:22, 3 June 2009 (UTC)

• You're absolutely right that it is better to use left:, left2:, left3:, ... instead of left:left:left:...
• I think this concept actually DOES support features like lane based turn restrictions. For example you could define lane-types called right_turning_lane, left_turning_lane and forward_lane. Let's say we are e.g. in Germany and therefor driving on the right side of the road. Additionally the middle of the road is defined as reference. Maybe the first lane on the right side of the middle is a lane where you're only permitted to turn left. Then you'd tag this lane as right1:lane_type=left_turning_lane. Next might be right2:lane_type=forward_lane and then a right3:lane_type=right_turning_lane. I think in at least 95% of all cases you could define turning rules like that (especially if you allow things like "right2:lane_type=forward_lane;right_turning_lane" in cases when both are permitted). I guess that routing software can understand these rules although they are less machine-readably than relations are. But: this concept is better editable by humans - which is IMHO much more important. AND: that's the way turning rules are actually defined in reality. In reality there are no signs that tell: "You're not allowed to turn from street A to street B" but there are signs like: "You're not allowed to turn right".
• In more complicated cases (junctions that can't be described using "left_turning_lane", "right_turning_lane" and "forward_lane") a relation could be used that describes from which lane on way A you can get to which lane on way B. Like a turn_restriction this relation would have 3 members (from, via and to) and additional values like from_lane=right<n> and to_lane=right<m> in case the <n>th lane on the right side of way A is connected to the <m>th lane on the right side of way B. If you think all this is complicated just remember that we are talking about REALLY complicated junctions. To describe turning rules for such junctions I have not seen any simple concept so far. So: it IS possible to refer to lanes in relations, BUT: it is not really automaticly maintainable by the database software, i.e. you habe to update the relation's values everytime you change the enumeration of lanes. But this will not often be the case as lanes are quite stable.
• even more: this concept allows to define rules to switch from one lane to another. For example if you're allowed to move from lane right2 to right3 but not from right2 to right1. This could be tagged as right2_1:lane_switch=no and right2_3:lane_switch=yes. This would even solve the problem of connecting motorways with motorway_links where one can typically switch from one to the other over a distance of several hundred meters (afaik so far this fact is not mapped at all).
• As this is a very powerful generalization of the original proposal and addresses some more problems it might be useful to open a new proposal!? I joined the community only recently and therefor do not know if it is common to do so? What do you guys think?--Santiago1504 07:04, 4 June 2009 (UTC)

I won't go into every detail of your suggestions right now -- for example, I'd probably prefer adapting the old Proposed_features/Divider proposal to support a divider between each pair of adjacent lanes instead of your lane_switch solution, but we can discuss this later.

For now, I think that this goes far beyond the scope of this proposal and should therefore be a proposal of its own. Just be warned that it will require significant work for documentation and (especially) discussion, as this topic has been touched several times and we still don't have a solution. Some of the attempts to solve this were

• WikiProject Germany/Workshops/Linienbündel
• Proposed_features/lane_and_lane_group

Still, I'd like to see a well-documented and detailed proposal page based on your idea. There will be a lot of aspects to discuss, of course, but we need a solution for lanes, and yours looks like it might work well. --Tordanik 20:39, 5 June 2009 (UTC)

Expanding this proposal to include surface and smoothness

This way of tagging seems to be logical and simple to understand and every situation can be displayed. Also in Germany it is important if you have to use the cycleway or if you could use it.

• left:cycleway=designated|yes|no
• right:cycleway=designated|yes|no
• left:footway=designated|yes|no
• right:footway=designated|yes|no
• left:segrated=yes
• right:segrated=yes
• left:cycleway.surface=asphalt|...
• left:cycleway.smothness=excelent|...
• right:cycleway.surface=asphalt|...
• right:cycleway.smothness=excelent|...
• left:footway.surface=asphalt|...
• left:footway.smothness=excelent|...
• right:footway.surface=asphalt|...
• right:footway.smothness=excelent|...--Aighes 18:16, 19 August 2009 (UTC)

This is nice, but it does not tell you if the footway is at the very left or between the cycleway and the street... --Lulu-Ann 12:18, 21 September 2009 (UTC)

Exactly. It's an attempt to create a "solution" for a small part of the lanes problem instead of a generally solving the problem. A proper solution should

• specify the order of sub-ways/lanes
• allow lane types to occur more than twice (thus a proper solution cannot be limited to a simple left/right).

This suggestion does not match these requirements. --Tordanik 08:31, 24 September 2009 (UTC)

Exact tag names

It would be good to follow some common rules for all side-dependent tags like these:

• place :left and :right at the end of tag name (footway.surface:left instead of footway:left.surface), so editor may detect them in easiest "tag agnostic" way. Also variant with beginning of name (left:... etc.) may be accepted.
• or do not use key delimiters other than colon (:) (say full stop .). For example footway:left:surface. There's no need in different delimiters.
• do not use *way=left/right, just *way:left/right=yes instead.

I am also working on Proposed features/Divided road, and want to use common scheme for side and direction dependent tagging. --- Vovanium 18:51, 25 January 2010 (UTC), upd 11:24, 17 February 2010 (UTC)

How to tag footway=no?

this example showing a street without footway. How can I tag it? footway=no? --Xan 10:09, 11 August 2010 (BST)

On the photo there is nothing indicating that pedestrians are not allowed to walk there. I would only tag width=2.00. Lulu-Ann

If they perform a balancing act ;-) Perhaps they have 15 cm to walk though. —Preceding unsigned comment added by Xan (talk • contribs) 14:19, 17 August 2010 (BST)

Unless it's illegal to walk on this street, foot=no is not appropriate. Consider using sidewalk=none to indicate no sidewalk is present. Joshdoe 14:55, 27 July 2011 (BST)

footway=none or sidewalk=none! Both seem to mean the same thing. I use footway=none. --phobie m d 22:50, 28 July 2011 (BST)

I prefer sidewalk=none, as it's clearer. "Nested" tags like highway=service+service=driveway make sense to me, as the latter is a refinement of the former. Looking at the Key:footway page, it's actually a bit contradictory as it says "This page lists refinement tags for highway=footway", but only two of the tags are actually refinements, while the footway=both/left/right/none is not a refinement but rather meant for tagging roads. As far as I can tell, it means the same thing as sidewalk=both/left/right/none, so I think we should resolve this and stick to using one or the other. --Joshdoe 12:59, 29 July 2011 (BST)