From OpenStreetMap Wiki
Jump to navigation Jump to search

Discuss Tag:highway=steps here:

direction of arrows

Copenhagen example of walking down steps

Does the direction of the arrows (line segments) mean anything? - User:LA2 18:54, 28 February 2008

Not yet I believe. But why not define a meaning here? IMHO it would make sense to draw them downhill, just like rivers. -- Fröstel 20:03, 28 February 2008 (UTC)
I agree that that would be logical but architects draw an arrow on staircases that points up. Malcolm Boura 21:10, 5 June 2008 (UTC)
I think they need to be downhill --Luisatala 04:29, 15 June 2008 (UTC)
Like architects I'm used to draw arrow pointing uppwards. --Jth 11:18, 2 August 2008 (UTC)
I always put them uphill (and btw. I am an architect). It is internationally consensus to do it this way in technical drawings, and why should we put them contrarily? --Dieterdreist 15:43, 14 April 2009 (UTC)
I think uphill is better --Soldier Boy 17 Dec 2010 (UTC)
+1 for uphill. --Lulu-Ann 13:01, 20 December 2010 (UTC)

Has anyone started following a pattern one way or the other? -- Harry Wood 10:30, 2 August 2008 (UTC)

On IRC we seem to have two votes for uphill 'TeLLuS' and 'achadwick' and one two for downhill 'gwenn' and 'Jannis'. Jannis said "I read the direction is downhill some long time ago (~1 yr) and I drew all my steps like this" -- Harry Wood 10:46, 2 August 2008 (UTC)
Have anyone seen a good symbol to draw for this, I saw this -----> in Copenhage, is it good enough? The only way to help people undestand they have tagged it wrong would be to show a symbol that tells you wheter it's up or down. Erik Johansson 06:39, 29 August 2008 (UTC)

Perhaps add a direction=up, to the steps that are tagged with way pointing upwards and direction=down for ways pointing downwards, and for all others giving implied direction=none? Erik Johansson

I believe that in architectural drawings, steps are almost always marked with an arrow that points up the flight. Since I believe this is an established standard, we should probably orient steps in the up direction. Chriscf 13:40, 30 September 2008 (UTC)
For the time being, I'm using direction=up and direction=down to specify the direction I've drawn the steps. However, if architects have already made it a standard to draw steps upwards I think we shoud follow that standard too. --Jesper Cheetah 19:48, 10 April 2009 (UTC)

I usually spend more time walking up the steps than walking down the steps. Walking down is much more easy. So spending more time walking up the steps I usually think that the direction goes up. But the suggestion to use extra tag k:direction v:up/down seems to me a good idea. Logictheo 08:42, 1 October 2008 (UTC)

I think it's more logical if steps points upwards, because intuitively people associate steps with walking from bottom to the top. There are thousand ways to come down from something (sliding, jumping, rolling), but only one way to go up to something (steps). Therefore we should orientate us by the way how archticts do it. This way fits better than the way drawing it like rivers, because steps are designed by architects. S.A.L. 12:57, 23 November 2008 (UTC)

I think this can still be changed even without an extra tag. It will take some time to control and adjust all steps already in the db, but it is possible (and wrong ones don't create much harm). I would do it according to international standards (from down to up). --Dieterdreist 15:43, 14 April 2009 (UTC)

I'm going to go with the direction of the way points 'uphill'. And presuming that this is the way that we have all been tagging steps for ages and that this is just an out of date wiki page, I'm going to boldly change it to support way direction is up-stairs in the next week or so. Rw 05:11, 21 February 2011 (UTC)

I, on the other hand, assume that those who consciously think about the issue tag the results of their thought process explicitly (using incline=up/down), and the rest just use random directions. --Tordanik 16:40, 21 February 2011 (UTC)

My direction shall be uphill. --T99 02:36, 30 January 2012 (UTC)

The International Standard Organization ISO 6790 .. and (copied) in British Standards B.S. 1192 ... Australian/New Zealand Standards ANZS 1100.. all specify that a stairway arrow points upwards. OSM should follow professional practice .. and that follows the standards .. arrow points upwards on a stair. Warin61 (talk) 09:37, 27 February 2015 (UTC)

In the 3 years since this discussion started, incline=up/down has been added to 10% of steps already. Explicitly tagging the direction helps making sure that people consciously map directions. With implicit directions, you would assign a meaning to steps drawn by people unaware of the convention, as well as those drawn before the convention was established, that simply isn't there. Implicit directions also don't allow for mapping (or importing) steps whose directions you don't know. --Tordanik 09:50, 27 February 2015 (UTC)
Intuitively, I think that uphill is the forward way to go, but generally I think it's better to be explicit and state incline=up or incline=down. (I always state incline=up). -- T99 (talk) 09:29, 21 September 2020 (UTC)
Resolved: it ended being de facto undefined, see later discussion Mateusz Konieczny (talk) 06:10, 22 September 2020 (UTC)


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)

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


If there are flat lines along the stairs to allow persons to push a stroller along, I think we could use stroller=yes. --Lulu-Ann 15:03, 10 September 2008 (UTC)

That's a good idea, those are usually also easy to cycle on. --Ævar Arnfjörð Bjarmason 16:10, 10 September 2008 (UTC)
I Use ramp=yes, since you can use that for bikes as well. :-) But then I've seen steps with just one track ramp, (it was the steps leading up to our bike shed, never seen it anywhere else..) Erik Johansson 07:05, 19 September 2008 (UTC)
A ramp can be used by a wheelchair, but a stroller ramp (steps in the middle) are too risky for a wheelchair. Also stroller ramps can be steeper and longer. There is a big difference between stroller=yes and wheelchair=yes. --Lulu-Ann 16:06, 24 September 2008 (UTC)
Resolved: nowadays stroller ramp tagging is documented on the page Mateusz Konieczny (talk) 06:06, 23 September 2020 (UTC)

surface instead of highway

In fact, I don't understand why there is a highway=steps tag anyway. IMO a surface=steps would be sufficient, like all the proposed tags on this page. Using a special kind of way for a stepped segment does not make much sense, the steps are often part of another way with it's own set of tags and usability. Routing software might look at the surface tag like on the barrier tag, deciding which sort of 'vehicle' can use the way. --tmeller 9:06, 4 October 2008 (UTC)

I agree. --Hawke 20:19, 5 November 2008 (UTC)
If you take it to the extreme, then you could argue that the steps are just large bumps in the surface of a footpath - but that's not how most people would see it. I personally think there's nothing wrong with tagging steps in their own right. They may form part of a longer logical route, but they aren't really the same sort of thing as any old footpath. Richard B 22:30, 5 November 2008 (UTC)
IMO you are right. But there are so many types of steps, you cannot compare them. Lastly I mapped a town in Switzerland, found a way: 6 metres wide, paved, surfaced with steps. Each step was 2 metres long. Makes it complicated but not impassable for a handicapped, doesn't make any difference for a mountainbiker, can even be used slope-down by a lorry. There are other steps - not far apart - in the mountains on a hikingpath. Not usable by even a mountainbiker. The waytype marks their usability. --tmeller 19:16, 23 January 2009 (UTC)
Show me a single step over 8 cm height that can be passed with an ordinary electrical wheelchair. Steps are always impassable. --Lulu-Ann 14:33, 26 January 2009 (UTC)
If a step lower than 8cm is still a step, and steps lower than 8cm are passable, then steps are not always impassable. But the question isn't whether or not highway=steps implies wheelchair=no, it's whether highway=steps is useful at all. tmeller was pointing out that just highway=steps is so broad a category that it doesn't give useful information, and is just a feature of some other route.--Hawke 16:44, 26 January 2009 (UTC)
i see steps as a trait of a way, not a category of a way. similar like highway=unsurfaced is considered obsolete and should not be used, steps do not define what kind of a way it is, they identify a trait for the way (or some section of the way). actual way might be highway=pedestrian, highway=footway or something else. it would seem logical to me that steps would be marked in addition to the appropriate highway value, not instead of it. --Richlv 18:56, 1 May 2009 (UTC)
I totally agree with you. steps should be seen as a feature (with subfeatures like handrail or strollers) of a given highway type. you can't compare steps on a hiking path with steps in a pedestrian area. but that's what you do with highway=steps: they are equalized. and trying to mark the differences with step features like width or step condition just will not do the trick and requires much more work and tags. sure, steps features are nifty, but by using the right highway type as basis you imply a certain set of default features. And in the end that's what's always done with the highway tag. so why break it here... --Marc 15:26, 21 December 2009 (UTC)
Agree with OP. I'm trying to tag up access rights on the rights of way in my area and I can't marked a stepped section of a public footpath as access:foot=designated because, as I understand it, highway=steps implies that access=no (excuse me if I've got the terminology wrong, I'm a newbie). DaveD 21:48, 15 October 2018 (UTC)
You can add foot=designated to highway=steps. Is it enough to solve the problem? Mateusz Konieczny (talk) 11:06, 18 October 2018 (UTC)
Yes, it seems to. I worked it out for myself but thanks for answering. Dave.Dunford (talk) 12:56, 18 October 2018 (UTC)

With a line, the steps can only be perpendicular to the direction (up/downstairs), but how does the renderer know how to draw the steps (they can be up/downstairs but also "left/rightstairs")? I don't oppose the idea (I myself have found flights of steps much wider that long) but I'm curious. --Guillembb (talk) 14:44, 1 June 2014 (UTC)

Resolved: This tag is well established, surface=steps is clearly not viable Mateusz Konieczny (talk) 06:09, 22 September 2020 (UTC)


There is still no solution for the up/down problem. I think it is safe to assume that defining a direction-dependent meaning is practically impossible now, with 40.000 uses of the tag in Europe alone. I therefore suggest to use an additional tag to express up/down information.

This is easy where the steepness is known: if the steps' incline is 30%, for example, we can add incline=30%, which indicates that the steps go up in way direction (it would be incline=-30% otherwise). I'm not sure what to do where we don't have this information, however. Of course, we could use something like incline=up and incline=down to roughly express up/down information. Opinions? --Tordanik 11:28, 23 February 2009 (UTC)

I started by tagging all mine with the arrow pointing up before finding this page, as it seemed logical. I think I was probably subconsciously aware of the architects standard as the same was used in roleplaying game maps for games I used to play decades ago. More recently I've not been so consistent in mapping steps, but could use ITOmapper (or whatever it is called) to find all the ones I've added and make them consistent. Most of those that will be different will be the steps down to the beach where they start at the path and just end at the beach. --EdLoach 10:33, 23 March 2009 (UTC)
In my humble opinion,
* in openPisteMap the pistes are dawn from up to down when aerialway are drawn from down to up ( see
* waterways (rivers are drawn from up to down
* and maybe other stuff...
openStreetMap is a map, and not an architectural plan, so the natural way should be up to down.
FrViPofm 11:41, 26 March 2009 (UTC)
It's no problem to have implicit up/down information for objects that have "natural" directions. I suggest, however, that you explicitly document that. If we decided to use incline=up and incline=down, for example, you could say that a piste implies incline=down, thus matching the convention of drawing them "up to down".
Steps, however, don't have a natural direction in my opinion, so they should not imply a direction (probably 50% of the tens of thousands of existing steps would be wrong if we decided on one). --Tordanik 11:53, 26 March 2009 (UTC)

In Michelin's french maps, sloping roads have arrows indicating sloap importance, from down to up. We could apply this concept on steps... It seems natural to me (but perhaps not for you). Wagner51 13:38, 18 April 2009 (UTC)

The direction of the way should be pointing up the stairs. Only reason I can think of to not do this is if there were one-way steps. Anybody know of such a thing. RussNelson 21:04, 13 June 2009 (UTC)

Resolved: direction-dependent meaning is practically impossible now, incline tag is documented
Mateusz Konieczny (talk) 06:05, 23 September 2020 (UTC)

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)


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)

Steps features

Please comment on Proposed features/Steps features. --Driver2 16:08, 25 April 2009 (UTC)

Resolved: Mateusz Konieczny (talk) 06:07, 22 September 2020 (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)

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)

Is this steps?

Should I map as steps mountain trail paved like this: Steps on mountain trail.jpg May be this will be good idea to use this photo as a good or bad example of steps. --Nataraj (talk) 06:19, 22 March 2013 (UTC)

As long as its man-made I suggest it goes for steps. In this case it is kind of hard to make out from the picture, but it does look man-made to me. --Ascaaear (talk) 14:16, 1 May 2017 (UTC)
As someone who has constructed such steps on a mountain trail, they absolutely count as stairs, complete with standard tolerances for height, width, depth and slope of each step (albeit a little looser than your typical concrete steps due to variance in the material and the traffic being less general). The proper way to tag this would indeed be with highway:steps, and I would think also material: or building:material: or surface:stone. Arlo James Barnes (talk) 02:17, 23 September 2017 (UTC)
This might be a good use case for the (rarely used) step.condition=rough tag... (Proposed_features/Steps_features#Step_condition) --Tordanik 16:40, 28 September 2017 (UTC)
For me it is clearly case of steps - recognized as steps, with the same implications for routing, rendering and other data use Mateusz Konieczny (talk) 15:51, 8 November 2017 (UTC)

Resolved: added to examples, noone seems to be opposed Mateusz Konieczny (talk) 06:04, 23 September 2020 (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)

trail steps

I plan on adding one more tagging example with trail steps (surface=dirst, highway=steps, ramp=no) Mateusz Konieczny (talk) 15:57, 11 November 2017 (UTC)

FLT CT6 10.9 mi - 12 log steps - panoramio.jpg
Resolved: Mateusz Konieczny (talk) 06:06, 22 September 2020 (UTC)

Area --Masaki123(talk) 19 January 2018

can you explain what you wanted to discuss? Mateusz Konieczny (talk) 11:54, 19 January 2018 (UTC)

There seems to be two different tags using stairs and steps being proposed as an area. i have seen stairs already being implemented. Are either of these currently acceptable?--Masaki123(talk) 19 January 2018

As I understand proposal duplicates existing tags (so indoor stairs would have tag separate from outdoor steps). Note Any tags you like. Mateusz Konieczny (talk) 13:48, 19 January 2018 (UTC)
Resolved: Mateusz Konieczny (talk) 06:03, 23 September 2020 (UTC)

Steps made of tires

Also note steps made of tires... yes, the surface is still dirt, but filling in a rubber tire, placed one after another up a hillside. Mention how to tag. Jidanni (talk) 00:05, 8 October 2019 (UTC)

highway=steps + surface=dirt + material=tire? Similar to last example at ? Mateusz Konieczny (talk) 15:11, 8 October 2019 (UTC)
Resolved: If there is an image on an open license (for example any image from Wikimedia Commons) it can be also added to examples Mateusz Konieczny (talk) 06:07, 22 September 2020 (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)