Proposed features/unified stoparea

From OpenStreetMap Wiki
Jump to: navigation, search
Available languages — Proposed features/unified stoparea
Afrikaans Alemannisch aragonés asturianu azərbaycanca Bahasa Indonesia Bahasa Melayu Bân-lâm-gú Basa Jawa Baso Minangkabau bosanski brezhoneg català čeština dansk Deutsch eesti English español Esperanto estremeñu euskara français Frysk Gaeilge Gàidhlig galego Hausa hrvatski Igbo interlingua Interlingue isiXhosa isiZulu íslenska italiano Kiswahili Kreyòl ayisyen kréyòl gwadloupéyen Kurdî latviešu Lëtzebuergesch lietuvių magyar Malagasy Malti Nederlands Nedersaksies norsk bokmål norsk nynorsk occitan Oromoo oʻzbekcha/ўзбекча Plattdüütsch polski português português do Brasil română shqip slovenčina slovenščina Soomaaliga suomi svenska Tiếng Việt Türkçe Vahcuengh vèneto Wolof Yorùbá Zazaki српски / srpski беларуская български қазақша македонски монгол русский тоҷикӣ українська Ελληνικά Հայերեն ქართული नेपाली मराठी हिन्दी অসমীয়া বাংলা ਪੰਜਾਬੀ ગુજરાતી ଓଡ଼ିଆ தமிழ் తెలుగు ಕನ್ನಡ മലയാളം සිංහල ไทย မြန်မာဘာသာ ລາວ ភាសាខ្មែរ ⵜⴰⵎⴰⵣⵉⵖⵜ አማርኛ 한국어 日本語 中文(简体)‎ 吴语 粵語 中文(繁體)‎ ייִדיש עברית اردو العربية پښتو سنڌي فارسی ދިވެހިބަސް

unified stoparea
Status: Abandoned (inactive)
Proposed by: itschytoo
Drafted on: 2009-03-03

Proposal to unify and extend tagging schemes for public transport

Plase note, that english is not my first language. If some parts are difficult to understand or I got the vocabulary wrong, please feel free to correct. --Gerrit 21:38, 15 February 2009 (UTC)

Downsides and problems of current schemes

  • It's inconsistent. Often in bus network stops are added alongside the road in rail networks its mainly as a node in the way. But there are many exceptions.
  • If only one stop is marked we lose detail. If every bus stop sign is mapped separately we use a clear view.
  • Information about correlation between all the members of a stop is not given.
  • Routing and other applications need a consistent model.

These and other problems (please expand) shall be solved by the following proposal. One main concern is backwards compatibility. Some details shall be optional to ease and speed up conversion of existing stops. This scheme is supposed to work for all kinds of stops, be it bus, tram, train, subway, light_rail, even ferries. Currently osmarender displays platforms as a grey area/line/dot. If this system is widely implemented, the renderer can be made more flexible rendering stops. In small zoom levels it only displays the name of the whole stop, in higher levels it shows all the elements the stops consist of, allowing more detail.

Existing Standards

A great deal of work has been done over the past 15 years in the PT community to try and develop good general conceptual models for representing stations & stops. It is desirable to draw on these models for two reasons - (i) A lot of existing stop data will be available in formats based on these existing standards, such as NaPTAN. (ii) There are a number of subtleties in how to best model stop data to support a wide number of purposes, for which these models suggest abstractions based on extensive experience of real requirements.

CEN Transmodel

Transmodel is the main CEN standard underpinning Public Transport information systems. It specifies a layered model for transport information. It considers stops primarily as logical stopping points in a timetable (ie the same scheduled stop point may be assigned to different physical points). For example it has the concepts:

  • STOP POINT a logical stop such as a station, bus stop
  • STOP AREA - a named grouping of stops


IFOPT Identification of Fixed Objects in Public Transport is a refinement to Transmodel specifically concerned with describing physical stops, stations, etc. (Documentation and schema available here here. Key concepts relevant for passengers include:

  • STOP PLACE - A physical transport interchange such as a station, airport, ferry port, pair of bus stops. This can contain a number of different types of STOP PLACE COMPONENT, such as:
    • QUAY - A labelled point of immediate physical access to a transport vehicle, such as a Platform, Bus Stop Pole, Boarding Gate.
    • BOARDING POINT - A labelled point on a QUAY such as a section on a platform (e.g. coach boarding sections on a Eurostar platfrom ), a front or back gangway accessed from the same gate(e.g. for an airplane), or where the doors are on an enclosed subway platfrom (eg on the LUL Jubilee Line).
    • ACCESS SPACE - An area within a stop place such as a concours or booking hall or corridor that does not offer immediate physical access.
    • ENTRANCE A point where one can enter a STOP PLACE, QUAY, or ACCESS SPACE.

IFOPT also covers vehicle positions, for example:

  • STOPPING POINT - the point at a which a vehicle needs to stop to be corretly positioned to serve a QUAY. For example, in a train station the locomotive stops ahead of the platform. IFOPT specifies the point on the vehicle that corresponds to the STOPPING POINT. Transmodel also has elements for the physical infrastructure such as track {RAIL ELEMENT) or road way so that the stopping point can be associated with them.

Typically a STOP POINT from a timetable (SCHEDULED STOP POINT) corresponds to a STOP PLACE, but it may additionally be assigned to a QUAY, STOPPING Point etc. Both STOP PLACES & QUAYS can be used recursively. For example a large station such as Victoria may be split up into several STOP PLACEs. IFOPT also has concepts to describe how all the above are linked up and can be navigated.

IFOPT has an extensive EQUIPMENT model to describe amentities such as seats, toilets, ticket machines, barriers, etc. This can be used to describe not just amenities, but also their properties. It has a availability model to describe opening times.

IFOPT has an accessibility model to describe accessibility for different types of user, e.g. Wheelchair, those with baggage etc. This is indended to supprot journey planners.

Some Examples

A single bus stop thus may be both a STOP PLACE, and a QUAY, (and optionally a BOARDING POINT and STOPPING POINT for the vehicle).

  • A pair of bus stops would be a STOP PLACE, two QUAYs, etc
  • A rail station would be a STOP PLACE, two or more QUAYs, etc
  • A coach station would be a STOP PLACE, multiple QUAYs, etc
  • A taxi rank would be a QUAY, either within another mode STOP PLACE or standa alone, etc
  • A Large airport would be a STOP PLACE, with a child STOP PLACE for each Terminal, containing QUAYs for each gate, ENTRANCEs etc . There might be additional STOP PLACES for Metro, rail etc,

A train stopping at a STOP POINT on its timetable will be visiting a STOP PLACE, it may additionally be assigned to a QUAY and a VEHICLE STOPPING POSITION. Passengers may be instructed to use a particular BOARDING POINT in order to find their seat or to make a particular trip (e.g. front four coaches for Istanbul, rear four for Moscow).


NaPTAN is the UK data stop data set. It's conceptual model

  • STOP POINT a station entrance, platform, bus stop, ferry point, etc. (Ie an IFOPT STOP PLACE COMPONENT).
  • STOP AREA - a named grouping of stops (i.e. equivalent to a very basic IFOPT STOP PLACE)


The General Transit Feed Specification (GTFS) has a stop model that overloads the various concepts of STOP POINT, STOP PLACE and QUAY as can be seen in the specification:

  • Stop (location type = 0) - physical stop.
  • Stop (location type = 1) - a named grouping of stops

This comparison paper allows one to see the equivalences with Transmodel/ IFOPT

Definition of terms used henceforth

Halt (Stopping Point)

The spot on the road/rail/water where the vehicle actually comes to an halt to have passengers board.
  • Since it it is in the road or rail track, this corresponds to the IFOPT concept of STOPPING POINT.
  • Geometry of the halt needs to be clear - simplest as a fixed point relative to a specific place on the vehicle (since vehicles can be of different length), but could also be a bounding point.

Platform (Quay)

Place where passengers wait to physically board the vehicles. Might be the train stations departure platform or the small area next to a road where the bus stop sign resides with some shelter or a bench.
  • This corresponds to the IFOPT concept of QUAY. QUAYs can contain EQUIPMENT such as shelters

Stop (Stop Place)

All elements relevant to public transport that can be combined under the same name.
A big Stop like some train station might consist of 8 Halts (Rails where trains come to an halt) and 4 Platforms.
A simple bus stop often consists of two Halts and two Platforms (one on each side of the road).
  • This corresponds to the IFOPT concept of a STOP PLACE (we use the term STOP PLACE rather than Stop to avoid confusion with "stop" as a simple point bus stop, and because there is no English word that covers Airports, Stations, clusters of bus stops, Ports, etc).
  • Stops may have several types of name and identifier for different contexts Eg King's Cross, London King's Cross, London King's Cross Rail Station, KGX, etc
  • IFOPT allows STOP PLACES to contain other STOP PLACEs, so a big airport such as Heathrow can be referred to both as a single stop and discrete stops (Terminal 1, Terminal 4 underground, Coach Station, etc) within it.


Halt (Stopping Point)

Node highway=bus_stop or railway=tram_stop or railway=halt or man_made=pier
A node described as such marks a Halt of the specified type and is found on top/as part as the way (Road, Rail, ...).
please note, that highway=bus_stop is according to current definitions to be tagged at the position of the pole (beside the way) and not on the way. To tag the stop position on the way there is public_transport=stop_position. --Dieterdreist 10:41, 13 August 2010 (BST)

Platform (Quay)

Node Way Area highway=platform or railway=platform
At a way or area this key marks a Platform.
At a node it marks the position of the stop sign (with schedule and such).

Stop (Stop Place)

Relation type=site and site=stop_area
The relation [1] creates a logical combination Stop. Its members are all Platforms and Halts which belong together.

More details/optional stuff

Halt (Stopping Point)

  • Halts are included as members in type=route relations (Platforms aren't!).
  • To simplify tagging, some Halts could be merged if they are not too far apart
    Example.: On a village road there may be two opposite Platforms and only one logical Halt for both directions;
    Its important that there exists a correct Halt to include in the route relation. For that reason, in train stations we can not merge Halts.

Platform (Quay)

  • If not clear, Platforms can have additional information what kind of vehicle it serves. For example, if bus- and tram is served from the same platform: services=bus;tram. Likewise services=light_rail might exist.
  • Additional features (like Shelter) can either be tagged as propperties to the Platform (shelter=yes) or as a separate node (amenity=shelter) which should be included in the Stop relation.
  • highway=platform should primarily be used (the platform being paved and resembling a pedestrian street or foot way). For compatibility reasons railway=platform is also considered.
  • For Plattform names use the ref key (i.e. ref=9 3/4, ref=south).

Stop (Stop Place)

  • The Stop (i.e. the relation) is given all attributes that belong for all its members like name, operator, business hours (at stations), ...
  • Other fitting elements like ticket vending machines, information desks etc. should be added to Stop as well.
    • IFOPT has an equipment model for these


  • amenity=station and railway=station will both become amenity=station and mark the building or area of the station (mainly for train stations, ferry terminals. It is also added to the Stop relation.
    • This means the explicit separation between railway=halt and railway=station is depreciated.
    • The significance of a train station can now be determined by the number of Halts and/or Platforms.
  • Additional elements that might occur in a stop (like loading bridges to car carrying trains, elevators to subway stations etc) shall not be discussed herein. They shall be defined somewhere else and be added into the stop_area-relation.

Elements that should/could also be added to the site relation

Depending on its dependence/affiliation with the stop (please amend):


Examples/Best Practices

  • If a tram and a bus halt at the same spot, the Halt node is tagged with highway=bus_stop;railway=tram_stop. The Platform next to it would be tagged highway=platform;services=bus;tram.
  • To change a typical bus stop from current scheme to the new model, change both nodes with highway=bus_stop to highway=platform. Add at least one Halt Node on/in the way and add everything to a Stop relation.
  • To change a typical train station to the new model is even easier, a Halt usually exists already. Add more for each position where train stop (usually 1 or 2 per railtrack). Add Platforms if they do not already exist and put it all into the relation
  • Where should be Halt node placed in case of long vehicles (trains, trams)? Is it the point, where the front side of the train usually stops or the point somewhere in the middle of the train? --Vrabcak 15:36, 17 February 2009 (UTC)
It should be a place where one can be sure to enter the vehicle. So somewhere in the middle of longer trains seems reasonable. It doesn't really matter that much as the position/size/geometry of the adjacent Platform gives a far better measure.
For a railway platform that only serves one train at a time I would put the Halt at about 50%; if it serves two trains simultaneously (e.g. 7a, 7b) I would put the Halts either at 25%,75% or at 33%,66%
If a bus Platform can serve 2 or more buses at a time; I would still add only one Halt node, as one can't know which bus will stop where. If you CAN know (bigger bus terminals with seperate "slots") you should use multiple Halts

... will be completed.

See also