User:Rurseekatze/Simple Public Transport Draft

From OpenStreetMap Wiki
Jump to: navigation, search

This page describes a draft of a simplified method of modelling public transport in OpenStreetMap.

Motivation

PTv2 considers mapping every route variant with separate relation. This is not practicable for public transport lines with a fragmented timetable with a lot of route variants (example), as it requires a lot of relations with redundant information.

Goals

  • Reduce the required work
  • Reduce dependencies of data
  • Better support in editing tools

Description

The focus of this draft is less to create a complete new tagging schema, but to collect all information related to public transport and to create a roadmap on how to establish this schema by improving documentation, adding support to editors and renderers and creating quality assurance tools.

Tagging

Infrastructure

Both stop positions and platforms are always required for a public transport stop. Mapping just one of both may reduce redundancy in some cases, but makes it difficult to use the data because applications have to consider different cases. Mapping both stop positions and platforms explicitly makes it also easier for quality assurance tools to check the completeness of the data.

Stop positions

Node A stop position is a place where a public transport vehicle (bus, train, etc.) stops along a public transport route to pick up or drop off passengers. It is mapped as a node on the way (road, railway track, waterway or aerialway). This tag can be used for any transport mode, or combination of transport modes. A stop position should have an associated platform. Stop positions are necessary for routing purposes because they ensure the right position of a public transport stop in the network graph of roads, railways, waterways or aerialways.

Tag Description Recommendation
public_transport=stop_position Defines this node as a stop position of a public transport vehicle. required
name=* The name of the stop position. required
operator=* TODO required
operator:wikidata=* TODO optional
network=* TODO required
ref:IFOPT=* TODO optional
local_ref=* TODO optional

Platforms

NodeWayArea A platform is a place where passengers are waiting and entering or leaving a public transport vehicle. It is mapped either as a node, a way or an area. This tag can be used for any transport mode, or combination of transport modes. A platform must have an associated stop position. Platforms are necessary for rendering on a map and routing passengers to the platform.

Tag Description Recommendation
public_transport=platform Defines this node, way or area as a platform. required
name=* The name of the platform (equal to the name of the associated stop position). required
operator=* TODO required
operator:wikidata=* TODO optional
network=* TODO required
ref:IFOPT=* TODO optional
local_ref=* TODO optional

Stations

Stop areas

Relations of stop areas are not necessary in most cases because they provide redundant information. A stop area can also be created by grouping stop positions and platforms by their name, their operator, a reference like ref:IFOPT=* or their geographic distance, for example with a GROUP BY statement of a database.

Stop area relations are necessary, if applications are not able to easily recognize that stop positions and platforms are forming a single stop. This is the case when their name=*, operator=* or type of transit (bus, train, etc.) differs within the stop. If all stop positions and platforms of a stop have the same name=*, operator=* and type of transit, a stop_area relation is not necessary.

Routes

Relation TODO

Tag Description Recommendation
type=route Defines this relation as a route relation. required
route=train/light_rail/tram/subway/bus TODO required
service=high_speed/long_distance/regional/commuter/car/car_shuttle/night/tourism TODO required
ref=* TODO required
name=* TODO required
service=* TODO required
operator=* TODO required
wikipedia=* TODO optional
wikidata=* TODO optional
color=* TODO optional
text_color=* TODO optional
public_transport:version=1 TODO required


Route direction

This solution is similar to PTv1, but the relation contains just the ways, but no stop positions and platforms. There would be just one relation collecting every way that is used by this line without a correct order being necessary. Adding stop positions or platforms to the relation is not necessary because stop positions are already part of the ways. There would not be any mapping of route variants.

Pro

  • Sufficient for rendering maps such as OpenPtMap; no preprocessing necessary
  • Just one relation for each line necessary
  • Very easy to map lines with a lot of route variants example timetable
  • Less redundancy of route variants that differ only in details
  • Still contains the information which ways exactly are used by a line. This allows it to calculate the correct route by routing. To route a single route variant, just download the relation and use the member ways as routing graph.

Contra

  • Still dependencies between ways and route relations with a risk of broken relations
  • Does not contain information about route variants, external information necessary to be able to calculate a route variant using exactly the right platforms and stop positions
  • Mapping of very long routes, e.g. long distance trains or travel coaches requires a lot of manual work and creates relations with a lot of members

Route master

Route master relations are not necessary any more because route variants are not mapped as separate relations in this schema. Route master relations would also provide redundant information.

Examples

Simple bus stop

Combined bus and tram stop

Railway station

Bus route

Local train route

Long-distance train route

Advantages

Disadvantages

Differences to PTv2

Use Cases

Retagging of old data

Status

  • Write a tagging draft (in Progress)
  • Discussion on mailing lists, on the talk page and the forum
  • Write a JOSM tagging preset
  • Create example data to check the pratical usage and get experience
  • Develop implementations that use the new schema
  • Write validation rules and develop quality assurance tools for mapper feedback and as a help to update old tagging to the new schema
  • Develop automatically generated lists that replace the existing manual lists in this wiki

Links