Proposal talk:Area-steps

Test relations

Hi, I did a changeset to tag three steps as areas http://www.openstreetmap.org/changeset/29262130 For reference, here's one of them http://www.mapillary.com/map/im/Sm-Z_ExNd3ePPDzuPu6sqQ --Sarchittuorg (talk) 09:45, 5 March 2015 (UTC)

I have tested out this relation on the short, wide steps in the photo I added to the main page. https://www.openstreetmap.org/changeset/59691423 --Lefty74 (talk) 13:59, 9 June 2018 (UTC)

For steps, some terms used are rise for the height, and run for the 'depth', these are for a single step, rather than 'short', 'wide' as they can become confusing with some taking the 'width' to be the distance from side to side and height to be the total hight from the first step to the last step. Possibly these terms need to be introduced as tags too. See https://www.calculator.net/stair-calculator.html Warin61 (talk) 05:17, 10 April 2019 (UTC)

Some remarks

• I think you should forget "type=area". it's too generic and very confusing for newcomers with "type=multipolygon". Why not "type=stairs" only (no highway) ?
• ways : for the compatibility, you should mention that the old and former "highway=steps" way should still be mapped and keep all the attributs like "step_count" into the classical way itself. Renderes are able to see if a highway=steps is spatially between one or more "stairs" relations and decide if it renders the old way or the new polygon.
• you create a tag for the upper way and one for the lower way. Many contributors don't see the relations and the risk is that such ways without tags are deleted by accident. And you identify immediately the geometry and direction of incline.
• your relation should contain only the upper and lower way. No laterals, neither intermediate steps. They should better create several relations in case of complex shapes.

-- Pieren (talk) 15:16, 5 March 2015 (UTC)

Most of that I agree with and have changed the proposal. The laterals may curve, be a different 2D lengths, have different numbers of steps so they have to remain. Thanks for your thoughts, I'm still thinking about the problems that I have with it! Warin61 (talk) 00:04, 10 April 2019 (UTC)

"Upper and lower ways: Create 2 ways, one for the upper part of the steps, another for the lower. They should have the same number of nodes and have the same direction."

At the first example "Palace of Queluz" looking from above: the steps may be modelized with three areas: the large lower step and two upper steps. But the upper way of the lower stays should have two nodes, because it is nearly straight, and the lower way should have six nodes, because it has corners ... that doesn't fit the proposed model ... For curved steps one way also may have more points, because it is longer ... If both ways should have the same number of points, the step area may fail, if an inexperienced mapper makes one way a little bit rounder, so it looks better ... --MitteloberrheinischerWaldameisenschreck (talk) 20:31, 11 April 2019 (UTC)

Extending area:highway=*

Hi, I suggest you extend the idea expressed in Proposed features/area:highway. So the stairs could be mapped with (1) a way with the usual highway=steps, step_count=*, incline=up/down etc and (2) a polygon with the tag area:highway=steps. It seems to be a simpler, backwards-compatible way of doing almost the same thing. Cheers --Jgpacker (talk) 18:10, 5 March 2015 (UTC)

Does not address the issues of curved steps, steps with differing numbers of steps across the face, steps that flow around right angled corners ... Sorry but I don't see it as compatible. Warin61 (talk) 00:09, 10 April 2019 (UTC)

use area and add a step direction

I'm wondering why you need a relation. Similar to highway=pedestrian areas, steps could be mapped as areas, too.

Draw a closed way with the tags:

• highway=steps
• area=yes
• direction=NE direction is up the stairs
• stepcount=25 into the direction given by direction
• ...

A multipolygon is an area too. --Werner2101 (talk) 20:53, 5 March 2015 (UTC)

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

https://wiki.openstreetmap.org/wiki/Key:stairs

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

I agree with Masaki123, this could be mapped with existant tags and only one area. The only questions I have is : should we use highway=* or area:highway=* ? And what if the steps are ON a building (ex. going to the 2nd level) ? --clementroux 03 November 2018

Just to highlight a potential inconsistency with the definition of direction=NE; there is a similar tag for skillion roofs - roof:direction gives the direction of the lowest side; "this is the downslope direction of the roof, from the top of the roof towards its bottom" roof:direction=*. So it would be better if direction=NE also gave the direction down the stairs. --spiregrain 05 December 2018

How do these schemes map steps that;

• have a different number of steps across the face of the steps? e.g. Relation: 9441459
• have a curved area that is wider at top or bottom? May have curved laterals. e.g. Spanish steps?
• have multiple right angles top and bottom? e.g. Relation: 9443810

It is the edge cases that this attempts to address. Warin61 (talk) 00:17, 10 April 2019 (UTC)

Wuzzy's random remarks

I've been waiting for something like this. I totally agree that steps as areas are needed. Since this is kinda tricky to do this right, I wish for this proposal to be sane before it goes into voting.

And I think the proposal needs to be refined a bit. Could you please give some examples, maybe with some simple drawings to illustrate the basic idea? This would help a lot. Also, some mistakes/problems:

• I do not understand the “lateral” role. What exactly is the point of it? When would I need it? When not?
• “handrail=yes/no the 'steepness' of the steps in %.” … uhm, nope.
• The proposal is unclear about how the stair outline should be segmented. The proposal should be clear here, because if you require roles like “upper” and “lower”, this implies you cannot get away by using only 1 line.
• The proposal is unclear about more complex stair systems which may “split” in mid-way, like in the photo. How would you draw that?
• The proposal needs refinement in routing. I think especially the edges could be tricky.

My other opinions:

• I am against using or suggesting width=*, because the width can already be inferred from the area itself and simple calculations and much more precisely by the correct programs. width=* would only be redundant.
• “They [the upper and the lower ways] should be parallel,”: This sounds like an unreasonable restriction to me, even if it is just a “should”. In real life, steps do not always behave like this.
• source=* does not need to be mentioned explicitly IMO. In this proposal. But this tag is old anyways: The source is now transferred in the changeset itself, so usually you don't need to add it at tag IMHO.

--Wuzzy (talk) 22:57, 19 April 2015 (UTC)

Thanks. Changed a few things to make it clearer and removed some idiocies, but I still have some work to do on how and why some details are needed. Takes time. Warin61 (talk) 00:23, 10 April 2019 (UTC)

Conveying stairs

If this proposal were to live again, it should take into account escalators and indicate whether the escalator goes up or down (which is achieved wit a conveying=forward/backward/reversible tag when using a highway=steps linear way). A conveying=upward/downward/reversible tag might be added on the relation to indicate whether the escalator goes from the lower way to the upper way or from the upper way to the lower way. Thbz (talk) 11:23, 22 July 2018 (UTC)

No.Escalators are simple linear features ... they do not need a relation. Not part of this proposal. Warin61 (talk) 00:20, 10 April 2019 (UTC)

See conveying=* for how to map escalators. Warin61 (talk) 05:27, 10 April 2019 (UTC)

Steps as barriers

For the "wide but short" use case, I've used key:barrier=steps before, on the argument that it's pretty much a more elaborate case of Tag:barrier=kerb. It's not a usage that's very widespread though (less than 30 uses). Circeus (talk) 21:16, 7 April 2019 (UTC)

Stair-like seating areas

The Serpentine Wall in Cincinnati 28718490 28718490 has linear steps at various points, but the overall wall is shaped similarly to the kind of steps imagined by this proposal. So are large amphitheaters and the seating areas at traditional concrete bowl stadiums. I think we should model those structures similarly, with upper and lower ways in a relation but perhaps a different relation type. It would be easier for 3D renderers to reuse code for both types of features. – Minh Nguyễn ^💬 19:12, 8 April 2019 (UTC)

I'd have thought seating was covered by Tag:leisure=bleachers or Tag:building=grandstand. Circeus (talk) 23:54, 9 April 2019 (UTC)