Talk:Proposed features/Area-steps

From OpenStreetMap Wiki
Jump to: navigation, search

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)

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)

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)

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

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)

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)