Proposed features/Stop Area

From OpenStreetMap Wiki
Jump to: navigation, search

Stop Areas are places used to access public transport services. They can be as simple as one or two bus stops beside the highway where buses stop to pick up passengers. At the other extreme it might be as large as a complex multi-modal interchange with an associated airport, mainline and metro railway together with a bus station, coach station and other facilities.

This page describes the background to the proposed solution, the problem, the proposed solution. It then demonstrates the use of this model in different real-life situations, details the mapping between current and proposed tags and the tasks associated with a possibly implementation of the proposal.

Background

This model is extensively based on the Public Transport Schema developed by Oxomoa with input from the German community during the May/June 2008. It also responds to subsequent input from Nick Kowles from Kizoom in relation to CEN IFOPT and CEN Transmodel standards. The original Public Transport Schema proposal was developed with reference to Proposed features/unified stoparea and QROTI.

The problem

Various inconsistent approaches are currently (August 2009) used to tag different transport modes and a complete set of tagging is not available for all modes. Ferry terminals are not defined, and although there is a entrance defined for a metro station there is not one for a main-line railway station. Railway stations and tram stations are normally tagged within the highway/trackway and bus stops are normally tagged as nodes next to the highway/trackway. There are other inconsistencies and it is not feasible to model very large interchanges such as Heathrow Airport with 5 terminals, many gates and a bus station, underground station, mainline station and coach station integrated into the airport.

This table shows the availability and inconsistency of tagging for the interchange, Access points (platform/gate/bus stop/ferry quay) etc, and entrance (if applicable).

Mode Overall tag On-way vehicle stopping point Waiting point used by passengers Entrance
Airports aeroway=aerodrome none (the position where the aircraft stops on the end of the taxiway) none none?
Buses amenity=bus_station (for bigger stops) none highway=bus_stop none (bus stations are normally on private property and have entrance for the highway - some are indoors)
Cablecar/ chair lift/ drag lift aerialway=station none none none (some larger cable-car terminals warrant separate entrances from the access points from stopping points 0 see talk page)
Ferries amenity=ferry_terminal mooring=ferry none none
Railways railway=station (The station tag is normally positioned in the middle of the area of the station as a node on the track. There is only one per station) none (There should be one stopping_point for each place where a train can stop opposite a platform) railway=platform railway=subway_entrance (Underground only)
Trams railway=tram_stop (only one tram-stop is used per 'station') none (there should be one stopping-point for every distinct point where a tram can stop, normally at least two per Stop Area - one for each direction) railway=platform none

The proposed Stop Area model

A single hierarchical Stop Area model is used to describe both simple and complex situations. The basic structure of this model is independent from the types of public service vehicles serving a stop or the traffic way a stop is related to and the Stop Area model can be used to describe a bus stop, bus station, railway station, ferry terminal, airport etc or any combination of them. This model is based on a professional international standard (IFOPT) which was been tested in real situations although some terms have been adjusted for compatibility with OpenStreetMap practice.

Stop Area

A Stop Area comprising one or more locations where vehicles may stop and also ones where passengers may board or leave vehicles or prepare their trip. A Stop Area will usually have one or more well known names and may also be associated with entrances.

A Stop Area is modeled as a relation of type site=* with a value of bus_station, railway_station, airport, ferry_terminal, tram_station for simple Stop Area serving a single primary mode. For multi-modal interchanges transport_interchange should be used.

For more complex Stop Areas serving multiple modes that Stop Areas can contain other Stop Areas. For example a main-line railway which includes a metro station and bus station which are all managed by different authorities or have different names. The elements relating to each mode may be modeled as Stop Areas in their own right and these are then 'wrapped up' using a single 'transport_interchange' relation. In very large interchanges, such as multi-terminal airports, such as Heathrow, there might be a further level of hierarchy. For example there might be a transport_interchange for the airport itself (Heathrow Aiport) which would contain a 'transport_interchange' for each of the main terminals (terminal 1-5). The terminal interchanges mught then contain details of facilities associated with the terminal, including a metro station (Heathrow - Terminal 4 metro) and the airport facilities themselves (Heathrow-Terminal 4).

The following tags should be used:

Key Value Description
type site
site text airport, aerialway_station, bus_station, bus_stop, ferry_terminal, funicular_station, light_rail_Station, metro_station, monorail_station, railway_station, tram_station, transport_interchange
ref number or text reference ID
name text name
Authority text The managing authority for the facility


An Stop Area can contain the following:

  • One or more Access features from where passengers wait immediately before accessing the transit vehicle such as a bus stop, platform, stance, gate, quayside etc. An access will normally be referred to by a reference such as 'Gate 1', Platform 4A.
  • Zero of more Entrances where people enter the Stop Area. In the case of a simple pair of bus stops on the road there will be no entrances as passengers approach the Accesses from the highway. In the case of an Stop Area with associated corridors, escalators, lifts and moving walkways it will have entrances to identify how passengers gain access to the Stop Area from the highway.
  • Zero or more Path Link elements which may include footways, cycleways, escalators, concourses, conveyors and lifts to describe the linkage between the above features. These Interconnect features will often be in 3 dimensions and it may not be possible to determine their exact relative positions.
  • One or more Stopping Points features which identify where the vehicle stops on the trackway in order for passengers to board or alight from a vehicle. A Stoppping Point for a Bus will be on a highway, for a train it will on a railway etc.
  • An arbitrary number of additional facilities associated with the Stop Area, including amenity=toilets, amenity=car park, amenity=bicycle_parking, car or bike rental, shops and ticket services etc.

Comments

Comment: I think it's confusing to use the term 'stop place' for both the relation and the vehicle stopping point (eg in these last two bullet points). How about using it for the relation only, and using "stopping point" only for the on-way vehicle stop points? Frankie Roberto 22:27, 11 August 2009 (UTC)

I have proposed changing the name 'stop place' to 'interchange' which as a side-effect makes the 'Stopping Place' term less confusing. Does that help? PeterIto 14:06, 12 August 2009 (UTC)
'Interchange' is a better name for the relation, certainly. I wasn't sure whether they would always be 'interchanges' as people perceive them (eg two bus stops on opposite sides of the road), but I guess that you may well use the stop to interchange between bus routes. For the on-way vehicle stop location nodes, how about calling these "Stopping Points" rather than "Stopping Places"? I think that's a little more specific... Frankie Roberto 15:18, 14 August 2009 (UTC)
I have now changed the term as per your suggestion. They are indeed points and it does seem to be a better term even if it is not the official CEN standard term. It does however still map clearly to the relevant CEN concept which is the main thing from a standards perspective. PeterIto 20:17, 15 August 2009 (UTC)
I have reverted to Stop Area for this name as this seems to have become established as the OSM name for the thing. PeterIto 12:03, 2 September 2009 (UTC)

Q: I'm not sure I understand this (Interchanges/Stop Place containing Interchanges/Stop Place). Do you mean a stop place relation can contain other stop place relations? Frankie Roberto 22:27, 11 August 2009 (UTC)

A: Yes I do propose that there is this hierarchy where there are distinct facilities serving different modes which are managed as distinct entities. PeterIto 13:32, 12 August 2009 (UTC)
Do you have an example? I can't think of anywhere where this would apply... Frankie Roberto 15:18, 14 August 2009 (UTC)
Let's start creating example in Examples section below to test out the proposal. The example I gave for a hierarchy is King's Cross. I also give Heathrow as an example of a possible three level interchange in the introduction. PeterIto 20:17, 15 August 2009 (UTC)

Q: When should one relate a number of bus stops as a single Stop Area? :A: If two bus stops are directly facing, a number of stops in a row close together or form a group around a junction and if they are known by the same name then they should be modeled as a single Stop Area.

Accesses

An Access is the place where a person would wait in the moments before boarding the vehicle. This could be a railway platform, ferry quay, bus stop, taxi rank, airport gate or similar. Accesses will sometimes have structures associated with then, for example a bus shelter, pier or building.

If the structures is primarily associated with a single access and used for waiting passengers then the access tagging can be associated with that structure. If the structure serves multiple accesses or is large then a separate feature should be defined for the access.

A complexity exists where a single waiting area is used to access vehicles at two different stopping points (for example at a train station where a single platform serves tracks on either side).

Another complexity exists where a single waiting area can be subdivided for some services. A long train may use the entire length of the platform (platform 4 for example), whereas the same platform can be subdivided into a number of sections (4A, 4B and 4C for example).

Other tags can be added to an Access to describe facilities associated with the Access, for example (eg toilets=yes) or (eg wheelchair=yes).

Access should be associated with the appropriate Stop Area with the role'access'.

Types of Access

  • Airport: Comment what tag should be use? Gate? (see below)
  • Buses: For normal bus stops beside the road a feature of type highway=bus_stop is created using a node or area for each distinct place where passengers can wait for a bus. If buses stop on both sides of a road then there two bus stops should be created.
  • Ferry Terminals: No tag is currently defined. What should we use (see below)
  • Railways (Funicular, mainline, metro, light rail etc): An access is created for each distinct railway=platform. If there are sub-platforms then a feature should be created for each sub-platform.

Comments

Q: Where one platform serves two or more stopping points (eg an island platform), and where there are different names each side of the platform or waiting area (eg "Platform 1" and "Platform 2", or even "Platform 1A" and "Platform 1B") it is unclear what the name of the overall platform should be.

Q: How should we tag a Quay?

Comment: do we have any tags for quays? Frankie Roberto 22:39, 11 August 2009 (UTC)

Q: How should we model sub-divided platforms?

Comment: I think the simplest solution (and the one I've adopted so far) is to draw only one way or area per physical platform. If the one physical platform contains multiple platform numbers, you can give it a name of something like "Platforms 1 & 2". The question of how to more accurately model which edges of the platform are 1 and 2 is a bit of an open question (see Sheffield). I've suggested adding the names to the stop points (the nodes on the railway) - however it was suggested that this isn't particularly semantic (as the stop points aren't 'platforms'). The solution might be some kind of "Boarding Point" nodes along the platform way. However, we can probably park this question for a bit. As Gerrit suggested, this is mapping down to the metre level! Suggestions welcome though. Frankie Roberto 22:39, 11 August 2009 (UTC)

Q: There's a bit of ambiguity over whether to use railway=platform or highway=platform. The former seems better supported/more common, though the latter is perhaps more 'logical', in some sense... Frankie Roberto 22:39, 11 August 2009 (UTC)

Entrances

An entrance defined the point where passengers enter the Stop Area. In the case of a simple Stop Area with one or two bus stops beside the road there will be no entrances. In the case of a more complex Stop Area with its own escalators, corridors and lifts there will be one or more entrances between the highway and the property associated with the interchange. Entrances may be for pedestrians, cyclists, taxis, buses or private cars.

Entrances should be a node tagged with entrance=yes and be associated with the relevant Stop Area relation.

Comments

Q: How should entrances for different transport modes be tagged? Is it sufficient to just use entrance=yes, or indeed entrance=yes, foot=yes, bicycle=no etc? Using this approach the fact that it is an entrance to a bus station would be deduced by the site it is associated with.

: I would have thoughts that entrance=yes (along with the optional access tags) is sufficient - it should be possible to tell from the walkways, escalators, and so on, which mode the entrance connects with. Frankie Roberto 15:21, 14 August 2009 (UTC)

:: Agreed, and the entrance will be associated with the relevant interchange in the relation. The 'role' is not really necessary now and I have removed it from the requirement. PeterIto 20:17, 15 August 2009 (UTC)

Path Links

Path Links are the paths that passengers use to travel between the entrance and an access point (if entering or exiting), or between one access point and other (if interchanging). These may consist of walkways (corridors, paths, etc), moving walkways ('travelators'), escalators, lifts (or elevators), and sometimes even monorails and other forms of light rail (eg at airports).

The links should be tagged with whichever tag is appropriate (eg see list below). Additionally, the link should be part of the overall Stop Area relation, optionally with a role=link tag (useful if this isn't otherwise obvious).

See:

Path Link elements can be tagged with access information:-

Key Value Description
oneway yes / -1 / no use in one direction only?
wheelchair yes / no / limited / only suitable for wheelchair users?
capacity number maximum capacity
maxweight number maximum weight
operator text operating infrastructure company
identifier text Sometimes fixed to the wall or feature)

Comments

Q: Unlike most mapping, transport interchanges can be highly three dimensional and also it will not be easy to establish the location of each node in the system given that GPS does not work underground. How should we deal with this?

Stopping Points

A Stopping point is used to identify each position within the Stop Area where a transit vehicle stops adjacent to one or more Accesses.

A Stopping Point should be positioned at the point where the front of the vehicle stops. For long vehicles, such as multi-carriage trains the boarding position for different carriages can then be calculated back from this position.

In some situations a single Stopping Point may be served from two Accesses (one on either side of the track).

Additional tags can be added to provide details of which public transport Routes serve the Stopping Point.

Types of stopping Point-

Comments

Q: I don't like the highway=stopping_place tag because it is not bus related. Any ideas on how to tag this to make it easy for mappers and also for renderers? PeterIto 07:27, 10 August 2009 (UTC)

Examples for the application of the model for Stop Area

Examples:

Bus stops around a square

A number of bus stops around a square may be arranged in a simple hierarchy with one Stop Area tagged with name=Church Square (East) and another one tagged with name=Church Square (West). These are then combined by another which uses the name name=Church Square.

A major rail interchange with associated metro station

A metro station within a rail interchange may be managed by a separate authority and possibly also have distinct names. Kings Cross Underground Station would be described as one Stop Area and Kings Cross Railway station as another. These two would then made part of overall Stop Area of type 'transport_interchange'. A map rendering could then choose if the render both separately (more more detailed maps) or as a single node for summary maps.

Comment: I think in this example it'd be better to model them as a single Stop Place, as it's always shown as a single station on transport maps. The different operators could be defined either using a semi-colon separated list on a tag on the relation, or separate operator tags on each of the different bits of infrastructure. Frankie Roberto 22:27, 11 August 2009 (UTC) :I don't really agree, there structures are used to access different transport modes and are managed by different authorities (Network Rail for the main-line station and TfL for the underground station). shall we come back to this one? PeterIto 13:32, 12 August 2009 (UTC)

Examples from Oxomoa's proposal - needs to be reworked to this terminology

In the most simple case there is only one stopping point with a name:

Stopping place (map view)
Stopping place (data view)

If two accesses are "joining" the stopping place a Interchange shall be created:

Stop place (map view)
Stop place (data view)

If two (not necessarily adjacent) stop places belong to one stop a stop place group shall be created:

Stop place group (map view)
Stop place group (data view)


Migration

This section describes how the migration from current tagging to the agreed new tagging would be achieved.

more needed..