From OpenStreetMap Wiki
Jump to navigation Jump to search

Discuss Tag:highway=steps here:


I think it makes sense to use highway=steps also on nodes, to describe a single step or a small flight of steps. If you don't have aerial photography, it's quite hard to create an accurate separate way. I've been using it like this for a while, and apart from the fact that it isn't rendered, I don't see a problem with it. Robx 09:25, 3 July 2008 (UTC)

I totally agree with you Robx. GeoJ 12:48, 21 July 2008 (UTC)
Sorry, I don't agree here. I still think a short way is desirable, over a node. Remember that a node represents a point. You use steps to travel from A to B. A node steps would be travelling from A to A. I believe the only way a node could be permissable for something you could walk a distance over might be something like a road crossing - where there is some context (i.e. the node represents crossing the way, not merely a link between two separate ways). I don't believe that short ways need to be particularly accurate - and of course if you use JOSM, you can zoom in and create ways of almost arbitrary smallness. Richard B 19:14, 6 August 2008 (UTC)
As it makes a big difference for the handicapped an for persons carrying a bicicly with heavy load if they have to climb up or down, a node is not suitable for mapping steps. --Lulu-Ann 16:25, 7 August 2008 (UTC)
Of course in some cases mapping steps as a way may be more useful, but in most cases it's annoying when a way is cut into pieces just b/c there's a small steps.
Mapping steps as a node is much more comfortable:
  1. in cases like way-steps-junction-steps-junction-steps-junction-steps-way it's very nasty to cut the way into pieces
  2. you can still tag/name/edit the footway as a whole
  3. in my area there are cases of a 100m footway with three times three stairs & and I feel terrible about
    1. cutting the way in 7 (!) pieces or
    2. pretending that there's a 100m staircase..
  4. very likely there would be more steps tagged if it's more simple
  5. the information 'there are stairs' is the most valuable
  6. you can still tell the direction (eg. inclining in the direction of the way -->-->-->--)
  7. the mapnik rendering of stairs like ||||||| sucks. --DerKuchen 17:10, 28 June 2010 (UTC)
Seems you are the only one who is to lazy to map some stairs the right way. I recommend you place your nodes in OpenStreetBugs, as somebody needs to clean up after you anyways :-) Lulu-Ann

What about steps with no horizontal extent - ladders. [1] --SpeedEvil 18:11, 18 May 2009 (UTC)

A way, by definition, implies horizontal extent in the direction of the way. A single step in a footpath does not generally have measurable horizontal extent (except across the way). Therefore, tagging a single step as a way is logically incorrect. Moreover, the word "steps" is a plural. Tagging a single step as "highway=steps" is grammatically incorrect. On the other hand, a node does not necessarily imply a lack of physical extent. Almost all objects worth mapping have some extent. Quite a large object, such as an airport, can be mapped as a single node. --T99 (talk) 19:55, 27 March 2016 (UTC)

Apparently, since there has been no objection in over 4 years, the above mentioned use of this tag on a node has been approved de facto. There's also another case were a single node is appropriate: a vertical stairwell containing multiple overlapping flights of stairs in a zig-zag, spiral or other formation, where it's not practical to map the horizontal extent of any of the flights. The location of the stairwell is still useful information. If you don't agree, you are welcome to come and map the missing detail. -- T99 (talk) 07:57, 25 June 2020 (UTC)

Where and by whom is it approved 'de facto'? Or where is it displayed as approved? I see only a node icon crossed in red, and the tooltip saying "should not be used on nodes" on this Wiki page. Without it one cannot even make QA tools like OSMI to accept it. Anyway, I also second the pro-arguments above, like a single step or steps too far away from each other. A step_count=*=1 would indicate it's indeed a single step so it imposes only a minor difficulty for wheelchairs, strollers, bicycles or for the elderly. Like a kerb. (Please don't suggest using barrier=kerb nodes instead for single steps.) ITineris (talk) 06:31, 4 February 2021 (UTC)
Personally, I use short segment of highway=steps line with step_count=1. Mateusz Konieczny (talk) 08:56, 4 February 2021 (UTC)
"cutting the way in 7 (!) pieces" - I see no problem with that and do it, in case of evenly spaced steps (one step every 4 meters) step_count=* is useful. Mateusz Konieczny (talk) 08:56, 4 February 2021 (UTC)
"the mapnik rendering of stairs like ||||||| sucks" - rendering in specific map style is offtopic here Mateusz Konieczny (talk) 08:56, 4 February 2021 (UTC)
Overall I see no need for tagging steps on nodes Mateusz Konieczny (talk) 08:56, 4 February 2021 (UTC)

Implied Wheelchair=no

I don't think that wheelchair=no should be implied. If somebody is tagging steps he/she might forget the implied wheelchair=no. Later on you won't be able to find out if somebody has taken the decision that there is no ramp or if the manual setting of wheelchair=no has been forgotten. Routing software for the handicapped will consider steps to be barriers anyway, so no need to imply this in the tagging. As I don't know about a voting about this I will remove the "implies wheelchair=no". --Lulu-Ann 16:29, 7 August 2008 (UTC)

Well, it is obvious that routing software will – as you say – consider all steps not explicitly tagged as usable for wheelchairs to be a barrier, which is the very meaning of it being “implied”. Personally, I’d prefer if router designers didn’t need to use undocumented assumptions, not the least because they might forget some relevant implications. Moreover, implying a “no” here wouldn’t stop mappers from explicitly setting a wheelchair=no to indicate that they have indeed checked this fact.
But alright, if you disagree here, we’ll leave it out. --Tordanik 17:31, 7 August 2008 (UTC)
(my 2nd comment in a row) Maybe it's good for public awareness to add wheelchair=no . For example someone notices that tag saying 'no' and gets the idea to ask the local administration to add wheelchair ramps to steps planned for the future, or even modify existing steps. Logictheo 08:51, 1 October 2008 (UTC)

I've also reconsidered, when before I thought it was a good idea to imply wheelchair=no . Since most people are not in wheelchairs it's logical to not put it in. The software in the wheelchair case might instead search for the wheelchair=yes tag, which I think is the most practical solution Logictheo 08:45, 1 October 2008 (UTC)

If in doubt, we should probably assume that an arbitrary set of steps is not navigable by wheelchair unassisted. I have certainly seen flights that have shallow risers and long going that a wheelchair user can negotiate, but this only comes where we have specific knowledge of the flight. Chriscf 09:50, 1 October 2008 (UTC)
See also DE:Rollstuhlfahrer-Routing

highway=steps, bicycle=yes

I have an example of where bicycles and be brought up/down stairs. And Yes, on the right side is the up side of the stairs. I'll tag it highway=steps bicycle=yes and include this stairway as part of a cycle route (as it is). The paved path stops and turns to gravel when going under the bridge, not suitable for road bicycles.

Imo, that's no "bicycle=yes", because you can't drive your bicycle up/down there. Carrying or pushing bicycles doesn't count for bicycle=* (otherwise, most pedestrian only ways would need a bicycle=yes, which would lead to wrong interpretations by software), but should of course be assumed as a possibility by bicycle routers. --Tordanik 11:53, 1 April 2009 (UTC)
But their might be some talented folks who could :) But this is an extension of the hand rail. As in this case, it doesn't require the user to 'carry' the bike... they 'push' the bike up/down. Ideal for long distance tourers with lots of gear. The feature is designed specifically for bicycles.

--acrosscanadatrails 19:05, 1 April 2009 (UTC)

When a steep ramp is wheelchair=limited, then is a ramp to push a bike up/down bicycle=limited, as it slows you down, you need to get off the bike and it is not possible to use it with heavy luggage. --Lulu-Ann 12:52, 2 April 2009 (UTC)
Stroller yes.jpg

This is to me:

--Lulu-Ann 12:52, 23 April 2009 (UTC)


I would like to clarify what kind of ramps there are on steps. What does ramp=yes mean? Is it the same as a stroller_ramp=yes? I think this should be documented and explained with pictures. --Driver2 00:52, 10 April 2009 (UTC)

If stroller_ramp=yes then bicycle_ramp=yes should also exist (as per above image link) because it is a physical feature designed to assist those with strollers (ramp eithor side) --acrosscanadatrails 03:30, 10 April 2009 (UTC)
Sounds better to me than ramp=yes, wheelchair=no for stroller ramps. --Lulu-Ann 10:54, 13 September 2009 (UTC)


How about tagging if there is a handrail? I would propose handrail=yes (what else ;-). Here's a picture of a step with handrail:


--Michi 22:10, 23 April 2009 (UTC)

I don't see a problem with this tag -- unless someone wants to add where the handrail is (on both sides, on one side, in the center, ...). As that would probably be of little practical relevance, handrail=yes should indeed be enough. --Tordanik 23:43, 24 April 2009 (UTC)
To specify the position of the handrail, handrail=left, handrail=right, handrail=both, handrail=center could be used, and handrail=yes if no detailed position is available. --Michi 03:16, 25 April 2009 (UTC)
This doesn't cover things like wide steps with tree or four handrails. ;-) But as I said, I don't think it's necessary to specify those. I don't see a use-case. --Tordanik 09:33, 25 April 2009 (UTC)
Nobody sees a usecase. The usecase is OSM for the blind. --Lulu-Ann 10:55, 13 September 2009 (UTC)
I prefer Michi's versions since I dont see any advantage to put the orientation of the handrail after a : and tell it "yes". Tordanik: any example where a "handrail:$orientation" would work better than a "handrail=$orientation"? -- Malenki 19:01, 13 December 2009 (UTC)
Well, now that we have handrail:left/right/center as part of the Steps features proposal, we can and should use these for that use case. --Tordanik 20:16, 13 September 2009 (UTC)
@Malenki: handrail:left=yes + handrail:center=yes is an example, unless you use semicolons (but I assume that Michi didn't mean to, using handrail=both rather than handrail=left;right). Furthermore, it might make sense to replace "yes" with a number for multiple handrails in the center, but it's not yet defined this way. --Tordanik 22:44, 13 December 2009 (UTC)
Resolved: documented nowadays Mateusz Konieczny (talk) 09:02, 4 February 2021 (UTC)


Could we please discuss tags before putting them into an "extended usage" section? Nobody even commented on handrail=yes/no so far.

More to the point: I don't really agree with the escalator and escalator_dir keys, which have, to my knowledge, never been formally proposed or discussed. What's the meaning of escalator=parallel, for example? Why does escalator_dir use up/down rather than forward/backward (what direction is up, after all)? And why is escalator=yes + escalator_dir=up needed, instead of a single tag such as escalator=forward? --Tordanik 11:34, 24 April 2009 (UTC)

Yeah, I guess handrail=yes is so boring that noone will comment it. Yes, I agree to handrail=yes, because handrails are objects that can be used other than only with steps, so we should have a separate tag. Handrails are valuable pieces of information to walking and visually impaired persons. I would like handrails to be tagged, because in public buildings braille writing is sometimes attached to them, what is a valuable information for HaptoRender.

Escalator=parallel was my idea for "there are stairs and parallel at the side of the stairs is an escalator". I will try to make a photo. This is often used in subway stations.

The direction of stairs is discussed, I will wait for the result. To me it is more interesting if the escalator goes up or down, as I know if I want to descend or ascend, but I agree that is not enough for routing software as long it is not clarified which direction is forward.

Shall we start a proposal for escalators? --Lulu-Ann 14:34, 24 April 2009 (UTC)

In my opinion, escalator=parallel could be expressed as two parallel ways for normal steps and escalator. It would be more flexible that way: Sometimes there are normal steps and two parallel escalators (usually one for each direction, rarely even one with fixed and one with dynamic direction, which makes using escalator_dir rather difficult if only a single way is created). Having two separate ways would also make it possible to add attributes for each way unambiguously, e.g. step_count. And it would maybe allow merging escalator and escalator_dir into a single tag.
A small proposal would be a good idea to collect some additional opinions. --Tordanik 23:38, 24 April 2009 (UTC)

OK, all ideas go here. --Lulu-Ann 12:19, 28 April 2009 (UTC)

Following some input from the tags mailing list, it seems that Tordanik's suggestion (two separate ways) is what people agree with. Unless there is disagreement, I am adding this to the page documentation, as well as to Key:conveying. Bjohas (talk) 19:45, 1 July 2016 (UTC)

Resolved: removed from page Mateusz Konieczny (talk) 09:04, 4 February 2021 (UTC)


Should steps have a level tag on them? Or do they inherit the level on both ends because of course they transition between levels. Of course, the ground could have a slop up which the stairs climb, in which case the stairs *don't* transition between levels. But you can figure that out by looking at the levels of the things on both ends. RussNelson 21:29, 13 June 2009 (UTC)

Sure, see level proposal. --Lulu-Ann 22:40, 13 June 2009 (UTC)

New idea for the up/down discussion

Until today we have no conclusion in what direction the way should point, upwards or downwards. So, I think we shold tag the two endpoints of the steps with an explicite tag, like steps:endpoint=up and steps:endpoint=down. In this case the direction of the way is unimportant. The architects can point the way upwards, the "river people" can point the way downwards and both can use the tags for the endpoints. Then everybody is happy and the orientation of the steps is clear defined. :-)

Yesterday I added some highway=steps with my proposal, here you can see what I mean:

Ok, the correct syntax of this new tag can be discussed, but I think it is clear what I mean. Thank you for any reaction. Daswaldhorn 18:39, 23 June 2009 (UTC)

It should be "high" and "low" instead of "up" and "down", which will be confusing on escalators. --Lulu-Ann 00:13, 24 June 2009 (UTC)
Yes it would be one possible alternative, to use "high" and "low", but I don't think it's confusing to escalators, because there it is used on ways, here on nodes. A third possiblity would be "top" and "bottom", a fourth ... . But I think the meaning of all possibilities is the same: to define the orientation of the steps without the direction of the underlying way. So, let's do it! :-) Daswaldhorn 17:37, 26 June 2009 (UTC)
What if a node is the top node of one highway=steps way and the bottom node of another? --Tordanik 18:00, 26 June 2009 (UTC)
Why would you want to devide the steps into two sets of stairs? A relation could help, that uses "upstrairs" and "downstairs" or "high" and "low" as roles. --Lulu-Ann 23:38, 26 June 2009 (UTC)
Just imagine a T-shaped set of stairs. The central node is an example for the problem. And no, a relation is far too complicated if I could simply add a tag to the way. (In fact, I even consider adding tags to two nodes too much effort if one tag on a way would be enough.) --Tordanik 14:28, 27 June 2009 (UTC)
Ok, lets say that the vertical way of the T goes upstairs from the central node, then the central node gets "down/low/bottom" and the other end node gets "up/high/top". The horizontal way of the T gets on one side "down/low/bottom" and on the other "up/high/top". The central node is on this way in the middle and gets no tag due to this horizontal way. And yes, of course you are right. One tag on the way would be better than two tags on the endnodes. But there is no consensus in this discussion and so the idea of the endnode tag was born. Another point is, that I don't want to wait until someday a committee named "Rat der Weisen" ("council of wise men"), which is just being discussed on the talk-de mailing list, decides in which direction the way has to point... Daswaldhorn 19:50, 27 June 2009 (UTC)
Apparently I didn't describe the T shape well enough. It was supposed to consist of 3 ways like this:
                       A <---------C-----------> B
The arrows indicate the "up" direction here. C is therefore "up/high/top" node of D-C and "down/low/bottom" node of C-B as well as C-A.
I think I'll simply continue to use incline=up/down (or precise incline values where available) on the ways. It works quite well, and there doesn't seem to be a problem with that solution. --Tordanik 11:59, 28 June 2009 (UTC)
OK, I got the problem. This example consists of two ways, not of three. D-C-A is one way, C-B the other. A middle node C in the way D-C-A can carry a high or low tag without interfering the high and low tags on D and A. A problem only occurs if D-C-A needs to be split up because the stairs have different names or differ in any other detail. However, a relation to add to the ways would always work fine. --Lulu-Ann 00:14, 29 June 2009 (UTC)
What exactly is wrong with incline=up/down? --Driver2 21:57, 29 June 2009 (UTC)
I agree with Driver2. We should initiate a vote for the "incline=up/down" proposal to settle this once and for all. Every stair feels different for everyone. Discussion on how to render can be done later...Pauluzz 15:12, 13 July 2009 (UTC)
-> Proposed_Features/incline_up_down --Tordanik 13:53, 20 August 2009 (UTC)
Resolved: tagging incline seems to be standard now, documented on that page Mateusz Konieczny (talk) 06:40, 21 May 2021 (UTC)

Spiral and helical stairs

There is some spiral stairs on the streets.

I propose to map it as a way from one end to another (through additional node at the central pole), with "spiral=yes".

Maybe some extra tags with information about number of turns or height would be useful too. --Antares19 08:59, 15 July 2010 (UTC)

How about mapping them as nodes instead of ways (with highway=steps and steps:type=spiral or spiral=yes)? Since a spiral staircase goes straight up, mapping it as a way doesn't really make sense. --CareyM

It doesn't go straight up, but around a central pole. So just map a way going in (multiple) circles. No need for a special case. It might seem somewhat pointless in 2D, but when mapping indoor features, you need to take the third dimension into account.--Tordanik 15:37, 19 November 2015 (UTC)

low density steps


I propose to add as an example that highway=steps may be used to tag also relatively low density steps Mateusz Konieczny (talk) 16:06, 8 November 2017 (UTC)

Wearing my data consumer hat, that image makes me a bit uncomfortable. It breaks several common assumptions (equal distance between steps, each individual step being mostly straight), and I doubt I could treat it correctly if it's tagged indistinguishably from regular steps. That gravel section after the first step on the bottom right, in particular, looks pretty much like a regular path rather than part of a flight of steps. --Tordanik 18:18, 13 November 2017 (UTC)
So how it should be tagged? Each step as separate short highway=steps way (I encountered this in past)? Mateusz Konieczny (talk) 22:39, 21 November 2017 (UTC)
I would probably tag at least the step on the bottom right as a separate short highway=steps, yes. For the two steps that are closer to each other, either separate ways or a single highway=steps way would work in my opinion. Preferably, all of these should also use step_count=* to make the situation more clear. --Tordanik 15:09, 26 November 2017 (UTC)

Now there is flat_steps=* a tag to express that the steps are actually flat enough to be driven on (e.g. 1 step every meter) mentioned in Tag:highway=steps#Tags_to_use_in_combination --Opk12 (talk) 16:02, 20 September 2022 (UTC)

by convention?

"By convention, the direction of the way should preferably point uphill" - I am very dubious about this part and I propose to remove this.

Editors in general offer no feedback about meaning of direction, personally I never even considered that direction of steps have meaning. I think that this claim is a wishful thinking and there is no such convention Mateusz Konieczny (talk) 21:19, 20 September 2020 (UTC)

I agree. A similar phrase was added in March 2015, but from 2008 to 2015 the page had said that there was no consensus about which way the steps should be drawn: - previous text was "Discussion whether the direction of the way should point up- or downhill is so far been inconclusive. It's possible to tag this explicitly using incline=up or incline=down". --Jeisenbe (talk) 04:39, 21 September 2020 (UTC)
I also agree. Change the phrase and emphasize the importance of using incline=up or incline=down. --mikkolukas (talk) 06:05, 21 September 2020 (UTC)
Resolved: removed Mateusz Konieczny (talk) 09:03, 4 February 2021 (UTC)

Tagging wheelchair lifts

We have the ramp=* tag to indicate that the steps have an attached ramp so that wheelchairs can navigate it. But, what do we do if the steps have an attached chair lift? Something like Could we use a tag like chairlift=yes. Or would it be smarter to generalize wheelchair access to either wheelchair=ramp or wheelchair=lift ? --Taktaal (talk) 09:58, 20 April 2021 (UTC)

Steps at heart/axis of ways

We have many ways in the hilly/mountainous area that are usually surface=concrete, narrow themselves, 2.5 to 3 meters wide with steps at the heart of 0.5m at or so wide (1.5-2 feet), the way itself often with anti-skid carvings for cars when wet or snowy. These residential (drive)ways are reasonably to quite steep. They have either steps integrated at the axis or at one of the sides. To kick a conversation in taginfo I've mapped a way with incline and added steps=centre. At the sides I've so far mapped them separately but could as well use steps=left and steps=right however the way's direction was originally mapped. Any thoughts on how to map/tag these features?

--SekeRob (talk) 12:17, 20 April 2022 (UTC)