Talk:Tag:highway=steps/Archive 1

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)

Stroller

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)

up/down

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 http://www.openstreetmap.org/edit?lat=46.1746&lon=6.7086&zoom=14)

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

Is this steps?

Should I map as steps mountain trail paved like this: 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)

Area

https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging

https://wiki.openstreetmap.org/wiki/Key:stairs --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 https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging 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 https://wiki.openstreetmap.org/wiki/Tag:highway%3Dsteps#Examples ? 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)

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)

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)

Resolved: Mateusz Konieczny (talk) 06:06, 22 September 2020 (UTC)

Handrail

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)

escalator

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)

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: http://www.openstreetmap.org/?lat=51.629223&lon=6.641881&zoom=18&layers=B000FTF

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

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)

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: https://wiki.openstreetmap.org/w/index.php?title=Tag%3Ahighway%3Dsteps&type=revision&diff=1145409&oldid=1115262 - 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)