Just a quick note to ask for input about adding more detail to highway=steps objects.
Currently the following keys are widely used with steps: step_count, handrail[:*], surface, tactile_paving.
There are some other aspects of steps which I think could be captured which would be of assistance for people who might not find negotiating steps easy (restricted mobility, respiratory problems etc.). These are:
Number of flights (and implictly or explicitly landings). For longer series of steps people may need to pause on a landing, and thereās a big difference between step_count=32 and two times step_count=16. This can be captured by micromapping, which is also valuable for tagging placement of tactile paving as nodes at the top & bottom of steps, but it is not a convenient way to capture information, especially for objects which have already been mapped. Currently there are 3 instances of the key flights applied to steps, two created by me in the English East Midlands, and one independently in Santa Fe, New Mexico. Syntax is either a single number being the count of flights or a semi-colon separated step count for each flight. There is a single use of steps:flights (also by me). This latter key is probably better as less ambiguous. Storing step counts in two places obviously is prone to inconsistency (as witnessed by one of the examples), but providing step_count is regarded as definitive I think the extra information conveyed outweighs this.
Riser height. The riser height is the height of each step, and contributes to how easy a given set of steps might be, particularly if there is no handrail. There is an undocumented steps:height but I think this refers to the total height (so riser_height = steps:height/step_count).
Going. The depth of the tread on each step. We have flat_steps to indicate going of over 1 metre. I donāt see a reason why we might want to capture more than this at present, so added for completeness.
Iād welcome views, and suggestions as to the most suitable way to capture this sort of information. I think keys of the form steps:* are less likely to result in confusion.
I have no idea what āflightā means in the context of steps. A quick Google search showed me:
āāFlightā is a term used in building design and construction to denote a continuous sequence of steps (or risers) connecting floors, landings or intermediate landings . The typical width of a flight in a domestic setting is around 850mm or more.ā
Never heard of that term before to be honest, although I kinda understand what it means. Not sure if in the context of mapping would work for outside in the open steps.
Riser height, that is the height of each step, is indeed useful to have. It will be easy for well-constructed steps which usually have a constant step height. Steps that are like paths on the ground, made by stone, that will vary by each step for sure, making the micromapping more challenging.
Going, as in how long is the step, is also something that is useful, because Iām pretty sure while mapping, people canāt be sure when a path can be considered steps when they are pretty long and variably.
I added a link to the EN Wikipedia article on the highway=steps page: this has an extensive set of terms related to steps (outside) and stairs (inside). Flights is common usage in English āthey live up 3 flights of stairsā.
Public stairs tend to follow specific design rules. I found those for pedestrian footbridges and these mandate flights of no more than 13 steps (risers) with risers no more than 15 cm. Regularity of width, riser etc. are all mandated too. US rules are somewhat different, often relating a ratio of riser to going (i.e., regulating the pitch of the stairs).
Riser height on irregular stairs of course is a different issue: in fact the most important factor is that they are irregular, as this tends to increase the effort to climb them. riser_height=irregular would be useful. Many steps outdoor formed on step terrain with really only risers as wooden boards are typical of such irregular steps.
Micromapping landings absolutely works, but I agree that there should be a tag.
Should there be a way to tag step counts between landings that are not evenly distributed? Something like step_count:flights=10;12;10 (left to right in the direction of the way) maybe?
Another way to tag it could be similar to maxheight, that is something like riser:maxheight and riser:minheight (or riser_height:max and riser_height:min based on your suggestion) to better denote how different the difficulty is per landing, because riser_height=irregular along would still be useful, but not enough for the end-user to understand how much irregular.
It is good to have a notation for flights but it like it would be easier to map the flights and landins. Break up each flight of steps with a simple footway. Optionally adding a footway=landing to denote the footway is a landing and exists a part of a larger staircase.
The micromapping (splitting ways) approach works for linear steps, especially when theyāre outdoors and visible on aerial imagery. Less so for a spiral staircase, where you would have lots of overlapping ways for all the flights and landings (example). I guess indoor mapping tries to solve this with repeat_on. Iām not sure how well that works (never used it).
Tagging either the number of flights or the number of landings seems reasonable.
While we are at the topic of flights, how is the level=0;1 syntax supposed to work when micromapping by splitting the stairs into multiple parts? Tag both stairs before and after the flight split in the middle?
I donāt think it needs to be that explicit, i.e., that the values are step counts (there are still 9000 steps=* which are mainly counts too). The US example showed flights being used as a single count (presumably mapped from aerial imagery): this is still pretty useful, at least in built-up areas as steps will tend to follow design rules about the maximum number of steps per flight. Also if the actual counts per flight are there then itās relatively simple for a data consumer to count the items to arrive at the number of flights.
Ultimately this stuff is most useful if it can be used by routers : thereās a maximum number of steps I can cope with before I need to pause before carrying on (somewhere between 16 and 24) and the next bit needs to be flat. In many stations I will prefer to wait for a lift if one is available, particularly if I have a suitcase (even a small one) as the extra load will reduce my O2 sats, which are low, quite a bit faster.
highway=steps ways are usually mapped outdoors where pedestrian routers use them. I donāt know of any outdoors routing engine that understands repeat_on, and I donāt expect support for that key to be straightforward, because of the complexity and ambiguity when building a routing graph, especially if the feature is partially indoors or some other way intersects with it.
Whenever Iāve mapped a spiral staircase or spiral parking garage ramp, Iāve always mapped a way going in a loop. Since a self-overlapping way is apparently considered problematic, I split it halfway along each loop and increment the layer and/or floor tag. (I guess I donāt go through the trouble of splitting water slides, but I know some mappers do.)
Fractional values are accepted, i.e. mapping a first flight with level=0;0.5, then a short landing as a footway with level=0.5 and finally the other flight with level=0.5;1. I did this when mapping subway stations (Way: 466661795 | OpenStreetMap). It can break some third-party apps and does not scale well if there are more than one landing. I am also very interested in finding a suitable solution to simplify the overall layout.
Iāve found this difficult with a tram station with level access to B Floor in a hospital (effectively 1st floor in European terminology, 2nd in US) which also has an external set of stairs/steps which are in 4 flights. Doesnāt help that there is also level access to another hospital building at the a different floor level (one higher). Internally the main hospital also has 4 flights of stairs between each level (there is a hidden service floor between each main floor). Although this is mainly a separate issue about how to manage transitions in level tags between buildings.
That was me. IIRC, I did it because it seemed silly at the time to add short footways for the ālandingsā seen in the imagery (now that Iāve had more practice micromapping, something like that wouldnāt bother me).
