Proposal talk:Escalators and Moving Walkways

From OpenStreetMap Wiki
Jump to navigation Jump to search

Additional key (e.g. moving or conveying) instead of escalator for walkways

An alternative suggestion: for the moving walkway, tag it with:

and for the escalator, instead of

use

This will make the indication that it is moving use the same tag for both, and will also make the moving walkway have more in common with non-moving footways --- in fact, the same amount in common with them as the escalator will have with steps. --HillWithSmallFields 17:21, 3 June 2012 (BST)

I have to agree. We should stick with existing tags (footway and steps) and use an additional tag for moving walkways and escalators. This is much more consistent imo. --Imagic 08:38, 4 June 2012 (BST)
+1. If the power goes out, an escalator becomes steps and a moving walkway becomes a footway. -- Joshdoe 11:44, 4 June 2012 (BST)
Actually you are right. We didn't came to that idea. But I think moving is not the best term for automated transport. Any other good ideas for the tag name? --Saerdnaer 12:31, 4 June 2012 (BST)
I also support an additional tag to steps and footway. If you don't like the key moving it could maybe be conveying=*? Also have a look at wikipedia: [1] it seems to fit nicely with both, steps and footway. --Dieterdreist 14:05, 4 June 2012 (BST)
+1 for conveying=yes/no. --Joshdoe 14:35, 4 June 2012 (BST)
No matter what term we use, wouldn't it be better to use steps=<whatever> and footway=<whatever> for this? Simply because it is a property of the "steps"/"footway" we are describing here. For example: highway=steps steps=moving and highway=footway footway=moving --Imagic 13:00, 4 June 2012 (BST)
I am opposing footway=moving because this will limit the tagging possibilities of combinations. In the a=b, b=c scheme it is often not clear, what kind of aspect c is describing, IMHO a tagging fail (e.g. others use footway=sidewalk, but then how to describe a conveying sidewalk?). --Dieterdreist 14:05, 4 June 2012 (BST)
In that case you can't use conveying=yes/no either. Because there could be another feature one the same way, that is (not) conveying. How to distinguish them? If you want to follow your own reasoning you would need something like footway:conveying=yes. --Imagic 14:53, 4 June 2012 (BST)
The proposal says "Model each stairway/escalator as own way." so there is now other feature on the same way. --Saerdnaer 22:21, 4 June 2012 (BST)
My point was that the reasoning of Dieterdreist is flawed. He claimed that footway=moving will limit the tagging possibilities of combinations (which btw is not fully correct) but missed the fact that conveying=yes/no doesn't tell us to which feature it refers. --Imagic 08:03, 5 June 2012 (BST)

I had a discussion with the co-author of this proposal. We agree on highway=footway + an additional tag for moving walkways but see no advantage in using the same additional tag for escalators and moving walkways. escalator=yes is already used on ~1200 ways, we see no real reason to rename it. --Saerdnaer 22:31, 4 June 2012 (BST)

What did you expect when the key escalator=* was documented in the wiki about highway=steps on the 6th March 2009? But now I actually don't understand the goal of this proposal anymore. So the result could be either "approved" or "de facto approved" - correct? --Imagic 08:03, 5 June 2012 (BST)
There are other things than escalator=* in the proposal - in particular the use of oneway=yes or oneway=reversible, and the moving walkways -, which are not yet "de facto approved". And if someone did find a reason why escalator=yes doesn't work at all, we could change even that one. But so far I do not see a sufficiently strong reason to do so. --Tordanik 14:01, 5 June 2012 (BST)

Width

Does the escalator's width should include the handrail's width ? Or just the width of the walkable part ? --PanierAvide 15:29, 4 June 2012 (BST)

I allways interpreted width=* as the width of the walkable area. Maybe we should clarify this on the key wiki page. --Saerdnaer 22:24, 4 June 2012 (BST)
I agree. In my opinion width=* should always describe that width of a feature that is relevant for its main use. --Imagic 08:05, 5 June 2012 (BST)

Key "oneway" only for vehicles and legal restrictions?

According to Key:oneway#Translation for routing "oneway restrictions presumably do not apply to pedestrians". Also, I believe that oneway=* should be used when it's illegal to go in the opposite direction. That might not be applicable in this case. From that perspective, Escalators and moving walkways are a bit comparable to Waterways which typically are not oneway, but "the way used should point in the direction of water flow". --EAman 23:37, 4 June 2012 (BST)

There is a difference to (most) waterways: an escalator may change its moving direction at any time. Maybe the direction=* would fit better? --Imagic 08:07, 5 June 2012 (BST)
"direction" is used for too many different things: Established values already include angles and clockwise/counter-clockwise. We should avoid introducing yet another set of values for that key. The original suggestion to use implicit directions like with waterways also doesn't work because the direction can change. So, to me, oneway seems like the best option. And since these ways are intended specifically for pedestrians, I don't expect the oneway key, when used on an escalator, to be misinterpreted to only refer to vehicles. --Tordanik 14:08, 5 June 2012 (BST)

A way to indicate motion and direction in one tag

From the discussion above I conclude that we have agreed to use highway=footway and highway=steps as the "base" tag. What we haven't concluded is how to indicate motion and the direction of the motion. Could we perhaps simplify by combining those two into one tag motion=* like this:

  • motion=yes: Moving, but direction is not indicated.
  • motion=forward/backward: Direction of the motion in relation to the direction of the way.
  • motion=reversible: Reversible direction as previously proposed.
  • motion=both: Allows modelling more than one escalator or moving walkway as one way. I agree with the original proposal that it's preferable to model each one as its own way, but we also want graceful fallback for less detailed mapping.

This proposal is generic enough to also be used for features like aerialway=* which for the most part seem to lack indication of direction today. You could substitute motion=* for moving=*, but "motion" feels more correct to me since the position of the feature itself is fixed. This is even more apparent if used together with something moving along a track or even on a zip line. --EAman 11:21, 6 June 2012 (BST)

This is an interesting suggestion. In addition to the benefit of the suggestion discussed above, it would also save one tag, and would allow for a more flexible definition of values instead of a need to re-use those oneway tags that might not fit 100%. Together these benefits might justify switching away from "escalator=yes". So yes, I like this, even though I think that "conveying" from the discussion above could also be considered as a key. Could others please comment what they think about this suggestion to use just one key that also defines the direction? --Tordanik 22:01, 12 June 2012 (BST)
I support this idea: one tag for one property. I also prefer "moving" over "conveying". --Imagic 08:33, 13 June 2012 (BST)
Great that you like the proposal. Let's discuss what's the most appropriate word to use as key, then: I prefer something based on the word "move" since it is generic enough to apply to several forms of transport and is guaranteed to be understood also by non-native English speakers. The word "moving" was the first one mentioned above, but I'd like to reserve that for future use for features that are in a semi-permanent position on the map, such as a floating island, a sand dune or a winter road. If you use "moving" as key, you'd also need to replace "reversible" with "reversibly" to get the grammar right. Either of the words "motion" or "movement" give me the right association to the transportation we're discussing. --EAman 18:08, 13 June 2012 (BST)
Unless anybody speaks up in favour of the old escalator key, we will probably modify this proposal to one of the new keys suggested here. I'd also appreciate some more feedback regarding the relative popularity of the moving/motion/movement/conveying variants. --Tordanik 17:12, 19 June 2012 (BST)
After a discussion with Saerdnaer I've now modified the proposal to use the conveying key, as this clearly seems more popular than using different solutions for escalators and moving walkways. Comments are still welcome of course! --Tordanik 20:19, 26 June 2012 (BST)

Escalators that change direction at set times

Some escalators switch direction at set times. This is used when there is not an up and down escalator next to each other. For example in Hong Kong: BBC Video.

Also, for 2 escalators side by side (for up & down) are you proposing to map them as 2 different ways? --RobJN 16:13, 11 June 2012 (BST)

For escalators switching direction on a fixed schedule, we could look at oneway=* which refers to Extended conditions for access tags and hope that someone will write the code to parse the schedule. If you want to model two escalators as one way, my proposal above suggests that you could use the value "both" to indicate that there is (at least) one per direction. --EAman 18:21, 13 June 2012 (BST)
I agree that condition syntax could be used for direction changes at fixed times. I don't like the "both" value, though: There is too much information missing, such as which of the escalators is on the left/right. Instead, I could imagine using the Lanes syntax on such escalators if you want to model steps/escalators that are directly next to each other as one way. This could look like highway=steps + conveying:lanes=backward|forward (for two escalators) or highway=steps + conveying:lanes=backward|no|forward (for two escalators with normal steps inbetween). --Tordanik 17:56, 29 June 2012 (BST)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Escalators_and_Moving_Walkways&oldid=2513728"