Talk:Key:ladder
Jump to navigation
Jump to search
Only for ladders in mountain paths or also other ladders?
Shall this key be used only for ladders in mountain paths or also for other uses of ladders? For exmaple, a ladder allowing to go from grass into a river or lake for swiming, a ladder as emergency equipment of a road to pass a retaining wall, a ladder to go onto a town wall for touristic purpose. In all those cases, usually, only few ladders exist in a bigger area so it would be nice to see them on the map.
- This is part of this approved proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/Safety_measures_on_hiking_trails So yes, it was meant for mountain paths only. But I think that naming the tag ladder=yes is not very distinctive. There are already more amenity=hunting_stand with this tag than ladders in the true sense of this tag. --Eartrumpet (talk) 19:15, 25 November 2018 (UTC)
- Yea, I know the background of this key, but it's wording is not via_ferrata:ladder=yes or mountain_path_ladder or the like, but just ladder - hence, already the name suggests a broad usage. I do not see a good reason to have multiple specialized tags for ladder, but wanted to check with others, because maybe the good reasons for multiple ladder keys just did not come to my mind :) --Schoschi (talk) 19:32, 25 November 2018 (UTC)
- At OpenAndroMaps all ladder=yes with amenity=hunting_stand are already filtered, because we want to render those for hiking trails only. So when the usage is even more widened, it won't be possible to only render those in the original meaning. Maybe it would be time to think about changing the original tag, or adding secondary one, like hiking_ladder=yes or ladder=yes and safety_measure=yes. --Eartrumpet (talk) 19:43, 25 November 2018 (UTC)
- I heavily use OpenAdroMap & Elevante, and I also would like the map not being cluttered with ladders. But how to distinguish between "more" and "less relevant" ladders? I like your idea of a combination of tags, e.g. ladder with safety_measure=yes seems meaningful and not only usable for via ferrata but also emergency escape from a road as mentioned above which IMHO shall also be rendered (similar to defilibrators or emergency phones). I'm not sure about ladders to enter e.g. a lake, personally, I'd like them to be rendered in Elevante, but not those ladders leading onto a hunting stand or mobile anetanna mast or a house's roof. Hence, we may conduct a list of tags (probably not that long) that define whether a ladder is taken over into OpenAndroMaps and/or rendered in Elevate. --Schoschi (talk) 10:19, 26 November 2018 (UTC)
- Whatever the solution, this should be discussed more widely, as the original tag without any additional one would still mean a ladder on a hiking path. Maybe strictly adding additional tags to non-hiking-ladders would serve this best at first? E.G. ladder=roof, ladder=emergency, ladder=private etc., and of course ladder=hiking. So every ladder with ladder=hiking or without any additional tag can be interpreted in the original meaning, any other one in a different meaning. --Eartrumpet (talk) 12:52, 26 November 2018 (UTC)
- I heavily use OpenAdroMap & Elevante, and I also would like the map not being cluttered with ladders. But how to distinguish between "more" and "less relevant" ladders? I like your idea of a combination of tags, e.g. ladder with safety_measure=yes seems meaningful and not only usable for via ferrata but also emergency escape from a road as mentioned above which IMHO shall also be rendered (similar to defilibrators or emergency phones). I'm not sure about ladders to enter e.g. a lake, personally, I'd like them to be rendered in Elevante, but not those ladders leading onto a hunting stand or mobile anetanna mast or a house's roof. Hence, we may conduct a list of tags (probably not that long) that define whether a ladder is taken over into OpenAndroMaps and/or rendered in Elevate. --Schoschi (talk) 10:19, 26 November 2018 (UTC)
- At OpenAndroMaps all ladder=yes with amenity=hunting_stand are already filtered, because we want to render those for hiking trails only. So when the usage is even more widened, it won't be possible to only render those in the original meaning. Maybe it would be time to think about changing the original tag, or adding secondary one, like hiking_ladder=yes or ladder=yes and safety_measure=yes. --Eartrumpet (talk) 19:43, 25 November 2018 (UTC)
- Yea, I know the background of this key, but it's wording is not via_ferrata:ladder=yes or mountain_path_ladder or the like, but just ladder - hence, already the name suggests a broad usage. I do not see a good reason to have multiple specialized tags for ladder, but wanted to check with others, because maybe the good reasons for multiple ladder keys just did not come to my mind :) --Schoschi (talk) 19:32, 25 November 2018 (UTC)
- I have very recently changed the via ferrata proposal+documentation to allow ladder=* and rungs=*. This kind of ladders and rungs requires a highway (path or via_ferrata) as the main tag so this would be a way to distinguish them from ladders on roof and such, in addition sac_scale + via_ferrata_scale could be examined. Some of the other uses would be better served with highway=ladder. RicoZ (talk) 20:26, 27 November 2018 (UTC)
- Testing for highway=path etc. would only help with ways, but not with nodes, as the tags of the ways the nodes are attached to are not inherited by the nodes. The majority of the ladders etc. tags are nodes. --Eartrumpet (talk) 20:58, 27 November 2018 (UTC)
- highway=via_ferrata can be applied to a node as well in such case, similar to highway=elevator.. not that I would like this solution very much. Unfortunately I also doubt that suggesting ladder=roof etc in the description would keep many people from mapping it wrongly. So either filtering, or I believe it should be possible get the inheritance by writing an overpass query that would get all highway ways with via_ferrata/path+sac_scale/via_ferrata_scale and all their nodes, which could be be than checked for ladder=yes and marked so that OpenAndroMaps could use it. It has been some years since I have done something that complicated with Overpass API/Overpass QL though. RicoZ (talk) 22:00, 27 November 2018 (UTC)
- Testing for highway=path etc. would only help with ways, but not with nodes, as the tags of the ways the nodes are attached to are not inherited by the nodes. The majority of the ladders etc. tags are nodes. --Eartrumpet (talk) 20:58, 27 November 2018 (UTC)
- I have very recently changed the via ferrata proposal+documentation to allow ladder=* and rungs=*. This kind of ladders and rungs requires a highway (path or via_ferrata) as the main tag so this would be a way to distinguish them from ladders on roof and such, in addition sac_scale + via_ferrata_scale could be examined. Some of the other uses would be better served with highway=ladder. RicoZ (talk) 20:26, 27 November 2018 (UTC)
Use height=x or length=x rather than ladder=x
Currently this page recommends using ladder=13 for a 13 meter long/tall ladder, but almost all ladders are tagged with ladder=yes. Wouldn't it make more sense to tag this with a separate tag like height=13 or length=13? --Jeisenbe (talk) 05:00, 18 June 2020 (UTC)
- As ladders may be inclined, height=* sounds more on point. -- Kovposch (talk) 13:03, 18 June 2020 (UTC)
- Agree with both of you but this is an approved feature and designed in analogy with the other elements of the Proposed features/Safety measures on hiking trails so from this perspective it makes a little more sense and right now not sure if it is worth to change and complicate things. As of length vs height, there are also (nearly) horizontal ladders in some places so if anything I would suggest to use height=* in addition to the current . RicoZ (talk) 17:44, 18 June 2020 (UTC)
- In practice ladder=# is hardly used, and the same is true for the related tags like safety_rope=#. So there is still time to improve the tagging advice by separating the tag for a ladder or safety rope/cable from the length or height of the safety feature. The confusion about length vs height suggests that these should best be mapped separately: length is not needed if the feature is mapped as a way, but could be used on a node, while height is always helpful. --Jeisenbe (talk) 17:07, 19 June 2020 (UTC)
- I see this has been already discussed in Talk:Proposed_features/Safety_measures_on_hiking_trails#yes.2Fno.2Flenght. The argument why height/length will not work makes sense to me. RicoZ (talk) 19:12, 20 June 2020 (UTC)
Nautical ladders
Ladders are also found along quays and other areas along waterways. Those are not rendered on OSMAnd, unless they are a node on a way, so the quay or wall has to be mapped as well which requires quite a bit of extra effort. It's not ideal. And even then, they are only rendered on the regular map style, never on the nautical one. B-unicycling (talk) 19:27, 13 July 2023 (UTC)
- The problem is it's not specified in IHO S-101 https://iho.int/uploads/user/Services%20and%20Standards/S-100WG/S-101PT8/S-101PT8_2021_06.1A_EN_S101_DCEG_1.0.2.20111205_Working_V2.pdf , nor S-57 https://iho.int/uploads/user/pubs/standards/s-57/31ApAch2.pdf attributes. It's in Seamarks/INT-1 Section U, but is grouped together in small crafts facility with landing steps, which is seamark:type=shoreline_construction + seamark:shoreline_construction:category=landing_step , not seamark:type=small_craft_facility + seamark:small_craft_facility:category=* . Assuming it's less relevant to larger ships. —— Kovposch (talk) 10:53, 14 July 2023 (UTC)
- I went around and mapped some of them in the town near where I live, 17 so far. I think they might be more to do with rescuing missions or cleaning the shores, idk. One of the rivers/ streams isn't even navigable, but it has one next to the bridge. Some might be used by kids jumping into the river in the summer and getting out again. I'm not sure what their intended purpose was, really, so I'm not too keen mapping them as seamarks. (https://overpass-turbo.eu/s/1xqd) B-unicycling (talk) 14:52, 15 July 2023 (UTC)