Proposal talk:Steps features

Correct names?

Technically steps have a rise rather than a height and a run rather than a length. If you talk to a builder/architect these are the terms they will recognise and use. Should not OSM use these terms too? See https://www.calculator.net/stair-calculator.html for more. Warin61 (talk) 22:40, 29 March 2019 (UTC)

Handrail

handrail=yes/no is very good. Valuable information for walking or visually impaired persons. Especially because I can attach a braille writing tag.

What about escalators? --Lulu-Ann 14:38, 24 April 2009 (UTC)

Might it also be important on which side the handrail is (if it is only on one side)? Escalators are already in Tag:highway=steps. --Driver2 18:35, 24 April 2009 (UTC)

I would like to suggest an alternative format for handrail:

• handrail=none where there is no handrail. This would be assumed if there is no handrail=* tag at all, but handrail=none should be coded explicitly if there is no handrail in a place where one might reasonably be expected.
• handrail=left where there is a handrail on the left, in the direction of the way.
• handrail=right where there is a handrail on the right, in the direction of the way.
• handrail=both where there is a handrail on both the right and the left of the way.
• handrail=center where there is a handrail in the center of the way but not on the left or the right. I consider this an awkward placement, but we have several of them on our university campus.
• handrail=multiple where there there are multiple handrails and one of the above tags does not cover. For example, we have a very wide stairway with two steps in front of one of our buildings, and there are four handrails--one left, one right, and two spread approximately equally between them. Use note=* as needed to describe, and include width=# in meters as needed to provide guidance.--EdH 20:59, 10 December 2010 (UTC)

I don't think the above is the best solution. This is evidenced by the fact that you need note=* for some cases, which does not allow for automated parsing at all. Instead, I suggest to use handrail:left=yes, handrail:right=yes and handrail:center=yes as defined on the proposal page now. Additionally, I would use handrail:center=<number> if there is more than one handrail in the center. So for "one left, one right, and two spread approximately equally between them", you would use handrail:left = yes + handrail:right = yes + handrail:center = 2. --Tordanik 22:22, 28 July 2012 (BST)

I also would like to suggest that handrail=*, as described above, be allowed for footways, paths, ramps, and landings, as well as for steps. We have several footways/sidewalks on campus next to drainage swales, with handrails on the side next to the downward drainage slope. We also have several handrails that do double-duty as barriers between footways and streets (where the footway is immediately adjacent to the street, without an intervening planting strip or green buffer). These use designs of open handrails rather than closed barriers (which we have at some other locations). Lulu-Ann can probably comment better on this, but I think that knowing that handrails are available, even if not continuously, would be helpful to persons with a variety of disabilities. --EdH 20:59, 10 December 2010 (UTC)

Ramp

It should be possible to add multiple ramps to a way without resorting to semicolons. I therefore suggest using ramp:stroller=yes, ramp:bicycle=yes (similar to recycling: and proposed fuel: syntax) instead of ramp=stroller etc. --Tordanik 16:23, 25 April 2009 (UTC)

yes, I agree with Tordanik. Instead of the ramp sometimes there is a metal profile (U) für bicycles, so maybe the tag ramp could be more generic or we could use an extra tag for those profiles? -- Dieterdreist 03:39, 6 May 2009 (UTC)

Maybe ramp:bicycle=yes if there is one narrow ramp and ramp:bicycle=metal or ramp:bicycle=even (maybe we find better values) if you want to further specify what type it is. --Driver2 12:33, 6 May 2009 (UTC)

Conveyor belts

I don't have a picture right now, but some (normal) stairs I know have a mechanic conveyor belt going parallely to transport luggage (e.g. at the trainstation). What about an extra tag for them? -- Dieterdreist 03:39, 6 May 2009 (UTC)

Yeah, why not. Should we tag it as a special ramp? Like ramp:luggage=yes/automatic/manual (are there also some that don't move automatically but only provide some kind of sliding surface, that would be 'manual'?). --Driver2 12:33, 6 May 2009 (UTC)

ramp might be misleading, as you are not allowed to step on the belt. Maybe luggage=conveyor_belt/sliding would be more specific. Or stairs:luggage=conveyor_belt/sliding if you prefer, as this is a stairs-feature, not a ramp-feature. -- Dieterdreist 16:48, 18 July 2009 (UTC)

Sometimes you aren't allowed to step on a bicycle ramp either (and even where it is allowed, it doesn't make much sense). So where's the difference? --Tordanik 17:05, 18 July 2009 (UTC)

I map ramps like this: ramp=yes;bike=yes and if it's mapped ramp=yes I assume that stroller=yes Erik Johansson 12:47, 11 September 2009 (UTC)

Material

sometimes in "natural-like" parks the steps are made of wood and earth and are therefore neither real steps (when low) nor a real ramp. -- Dieterdreist 16:48, 18 July 2009 (UTC)

Tags name

Why are the tags surface.material step.condition step.height step.length spelled with a dot?

It would be more consistant with current practice to use a colon, so the names become surface:material step:condition step:height step:length --Renaud 19:08, 18 July 2009 (UTC)

I prefer dots for properties. --Driver2 21:01, 18 July 2009 (UTC)

It seems the vast majority of these sorts of sub-keys use colons rather than periods, so I believe we should try and stick to the convention. But I sympathize with you coming from programming. :) -- Joshdoe 12:58, 29 March 2011 (BST)

Units for measured sizes

If the value for height or length is a number your proposal notes "Please always specify a unit (e.g. cm)" which is a contradiction. Either it's a number or it's a string made up of a number + some unit string. I suggest the metric system as default for all numeric values like it's the standard in most parts of OSM. The documentation should be altered to "Default unit is centimeters. Please specify all non-metric units (e.g. in)"

I don't think it would be a good idea to use centimeters as the default unit. I, for example, would probably assume that the value defaults to meters (as all other measure tags in OSM I know of) if I hadn't read this. So unless we decide on meters as the default, units should be specified explicitly. --Tordanik 13:01, 19 July 2009 (UTC)

I agree... meters are SI unit. --Lulu-Ann 10:32, 20 July 2009 (UTC)

The thought behind 'always specify the unit' was, that I don't expect many mappers to actually measure the steps, which will make establishing a standard harder. Not many people would check which kind of unit was actually used and if it is the 'correct' one (i.e. the one we agreed on here). I'm also not sure if meters is the best unit. Even though other tags default to meters, they are also used to measure much greater length. The step height would be something like 0.27, so I would rather use centimeters. But meters would be ok too, to keep consistency. --Driver2 02:47, 21 July 2009 (UTC)

Copied some parts to tag:ramp=yes

Basically I think there are eough peopleusing this part of thetag. Erik Johansson 12:59, 11 September 2009 (UTC)

So, is the Key:ramp parts already approved? If so, why do we have them included in this proposal also? --Kslotte 10:42, 18 February 2010 (UTC)

Other Properties

I would welcome some discussion of the suggested landing=yes/no/count. Thinking of someone who is blind and navigating stairs where there are possible multiple landings, I think it would provide more information to code each landing separately, either as highway=footway, landing=yes, or simply as highway=landing. So a descending stairway with two landings could be tagged (going in the direction of the way, from top to bottom) as

• highway=steps with step_count=*;
• highway=footway, landing=yes;
• highway=steps with step_count=*;
• highway=footway, landing=yes;
• highway=steps with step_count=*.

Each could have separate information about handrails, if required. This would accommodate situations in which the number of steps varies between landings.

highway=landing or its equivalent is also useful where an inclined footway has landings along the way. We have several of these on our university campus, where the inclined parts of the footway have handrails on both sides, while the landings have no handrails. I think these may have been build under a previous standard for Americans with Disabilities Act [1] accessibility that has been superseded and not yet updated, because a new instance has been built in which the handrails are continuous for the entire length of the footway, including the landings. highway=landing or its equivalent also would be useful for switchback wheelchair ramps, in which a ramp goes up to a landing, turns 180 degrees, goes up to another landing, turns another 90 degrees, and goes up to finally reach the door of the building. And highway=landing or its equivalent would be useful for describing the short level way at the top of stairs just before a doorway. highway=landing or its equivalent should probably be rendered as for highway=footway.

My questions are, would this be helpful? Could it be done better? Is highway=footway, {{Tag|landing||yes}) preferable to highway=landing? The latter is simpler but would not require a new high-level highway=* tag.--EdH 21:37, 10 December 2010 (UTC)

Actually there is no need for stepcounts for blind persons (without other disabilities), because steps can easily be identified with the blind cane. The step count and landings are more important for persons with a walking impairment or persons carrying a stroller. Blind persons appreciate information about handrails, not because of their existance only but because then we can stick more information on the handrail tag like if there is braille writing on the handrail (common for railway stations, you have the track numbers written there in Braille). Landings are also important on ramps for wheelchair drivers! --Lulu-Ann 15:49, 14 December 2010 (UTC)

A new top level highway tag is too much for a special-interest tag like that, especially if most applications will treat it exactly like a footway anyway. I'd therefore prefer highway=footway, landing=yes. It would make some sense for highly detailled renderings, even though it's probably not that imporant for most users. -- Tordanik 12:59, 16 December 2010 (UTC)

I would prefer to use

• highway=steps with landing=yes or
• highway=ramp with landing=yes

instead of

• highway=footway, landing=yes.

because it does not look strange in rendering and you can draw a continuing ramp or stairs without changing the landing in the middle to footway. --Lulu-Ann 12:31, 20 December 2010 (UTC)

use only objectivly measured characteristics

Vovkav 17:43, 21 February 2010 (UTC): We should use only objective chars of length and height (in cms as standard SI units) to avoid ambiguity. We could also recommend ranges to consider step narrow-normal-wide and so on , but this should still be renderer's concern.