Proposal:Escalators and Moving Walkways

several escalators

an horizontal moving walkway

two inclined moving walkways

The Feature Page for this approved proposal is located at Key:conveying

Escalators and Moving Walkways
Proposal status:	Approved (active)
Proposed by:	Saerdnaer, Tordanik
Tagging:	conveying=yes/forward/backward/reversible
Applies to:	way
Definition:	conveyor transport for persons
Draft started:
Proposed on:	2012-01-22
RFC start:	2012-06-03
Vote start:	2012-08-31
Vote end:	2012-09-14

Tagging:	conveying=*
Statistics:

Tagging: conveying=yes Statistics:

Tagging: conveying=forward Statistics:

Tagging: conveying=backward Statistics:

Tagging: conveying=reversible Statistics:

Tagging: conveying=unknown Statistics:

This page proposes tags for the two most common types of conveyor transport for persons: escalators and moving walkways.

An escalator is a moving staircase – a conveyor transport device for carrying people between floors of a building.

A moving walkway (British English) or moving sidewalk (American English) (colloquially sometimes travelator, horizontal escalator, walkalator, autowalk, movator, people mover) is a slow moving conveyor mechanism that transports people, across a horizontal or inclined plane, over a short to medium distance.

This proposal is designed to replace Proposed features/Escalator, Proposed features/Conveyor and a part of User:Oxomoa/Public_transport_schema#Public_conveyors.

Tagging

The conveying key is used together with highway=steps (for escalators) or highway=footway (for moving walkways).

Key	Value	Element	Comment
conveying	yes		indicates that this feature is an escalator / moving walkway with unspecified direction
conveying	forward		movement in way direction
conveying	backward		movement opposite to way direction
conveying	reversible		changing direction

Model each stairway/escalator as own way.

Other useful tags

These could be used for tagging escalators and moving walkways, but they are not part of the proposal.

• incline=*
• width=*
• tactile_paving=yes/no
• Lanes (could be used for physically connected parallel escalators)
• Access (if some potential users are forbidden from using the escalator)

Voting

To vote use {{vote|yes}} or {{vote|no}} and sign with -- ~~~~

• I approve this proposal. --Dieterdreist 10:16, 31 August 2012 (BST)
• I approve this proposal. I vote in favour of this proposal. However I would like to see trolley=yes/no being integrated explicitly. In addition examples on how and when to use lanes in combination would be nice as well as a list of links to indoor proposals. After all an escalator without level information is useless. --andreas.balzer 11:20, 31 August 2012 (GMT+1)

You are free to add a notice to the Tag Documentation Wiki Page, once it's created. --Andi 10:34, 31 August 2012 (BST)

• I oppose this proposal. I am principally in favor of this proposal. However I don't like to map to lanes in opposing direction separately. Add conveying=both or similar to the proposal, and you get my vote. Mapping features that are 2m apart, is simply rubbish!!! We also don't map lanes as separate keys on highways, even if they are opposing direction --Extremecarver 11:44, 31 August 2012 (BST)

conveying=yes seems to be good enough for that... Erik Johansson 19:00, 31 August 2012 (BST)

Nope, it's not enough. The description says "unspecified direction". That is clearly not the same as "moving in both directions".--Extremecarver 09:11, 3 September 2012 (BST)

We *currently* don't map lanes as separate keys on highways, but hopefully, we will be able to do so in the future. Also, the comparison is weak: Highways are several meters wide, the lanes are just part of the highway. Escalators are under 2m wide usually, two escalators are usually two distinct features and 2m do matter more in pedestrian/indoor routing/maps than they do for car applications. -- Errt 13:57, 1 September 2012 (BST)

Hopefully in future we are able to map lanes using separate keys. So how comes we want to start here to map it with separate ways. I disagree. If there are 2 escalators moving in opposite direction, I don't see why we should map them separately. This is just false precision. I doubt we ever have sub 2m accuracy in OSM underground.--Extremecarver 09:11, 3 September 2012 (BST)

The proposal mentions that you can use the Lanes concept with the conveying key. Unlike your suggested solution conveying=both, this a) works for conveyors that have normal steps between or next to them, b) defines which direction is on the left/right and c) lets you add other tags such as width=* to the lanes. An example has been mentioned on the talk page. --Tordanik 09:29, 3 September 2012 (BST)

If this is the case you should remove the note "Model each stairway/escalator as own way." because you simply can model many stairways with only one way and :lanes-tags. --Imagic 07:39, 4 September 2012 (BST)

• I approve this proposal. And +1 for Extremecarver's suggestion for conveying=both (directions) /al 23:03, 31 August 2012 (BST)

• I approve this proposal. -- Kerosin 10:13, 1 September 2012 (BST)

• I approve this proposal. SunCobalt 10:19, 1 September 2012 (BST)

• I approve this proposal. -- Errt 13:57, 1 September 2012 (BST)
• I approve this proposal. But I also like Extremecarver's suggestion for allowing conveying=both. This carries somewhat more information than just saying "yes", which could also mean "it is just one direction, but I do not specify which". --Tronikon 14:22, 1 September 2012 (BST)
• I approve this proposal. As I indicated already on the discussion page, I would however also like to see the value both (or some suitable synonym). At my local train station there are two escalators; one going down and one going up. Which one has which direction however seems to vary over time. In this case it's better to map the two escalators as one unit tagged with conveying=both. -- EAman 15:51, 1 September 2012 (BST)
• I oppose this proposal. Good idea to create a tag for Escalators and Moving Walkways, but the conveying key seem to be not thought-out.--R-michael 18:43, 1 September 2012 (BST)
• I approve this proposal. --PanierAvide 18:50, 1 September 2012 (BST)
• I approve this proposal. --Cobra 19:04, 1 September 2012 (BST)
• I approve this proposal. Good to have an adjective as key, it makes it clearer that this is an attribute to another key. Conveying is an uncommon word but I have no better suggestion--Johan Jönsson 21:44, 3 September 2012 (BST)
• I approve this proposal.--I am in favor of the tags, used in the context of the navigation graph. In "Outdoor" maps the street segments have a double duty as visual elements and the navigation graph. In typical indoor maps there is a navigation graph, which would be labeled as a foot path of some sort, but there is no visual element like a road. There is just a room, corridor, aisles etc. Indoor maps also typically will have a finer scale of detail than the existing outdoor maps, as commented above. I would be in favor of an allowance for an area element, separate from the navigation graph, that could be used to render a stairway, escalator, elevator, moving walkway, etc. It would have been nice to have the tag discussion more within the context of indoor maps in general. Sutter 20:15, 4 September 2012 (BST)
• I approve this proposal. --Fabi2 00:10, 6 September 2012 (BST)
• I approve this proposal. -- And +1 for Extremecarver's suggestion for conveying=both Viking81 12:45, 6 September 2012 (BST)
• I approve this proposal. -- Theonlytruth 09:35, 13 September 2012 (BST)
• I approve this proposal. --Imagic 09:49, 13 September 2012 (BST)

See also

• Proposed features/Goods conveyor for conveyors that transport goods.