Proposal:Through service

From OpenStreetMap Wiki
Jump to navigation Jump to search
Through service
Proposal status: Rejected (inactive)
Proposed by: miklcct
Applies to: relation
Definition: A public transport service which routing changes between lines
Rendered as: N/A
Draft started: 2016-09-14
RFC start: 2016-09-14
Vote start: 2016-11-22
Vote end: 2017-05-08

Proposal

This proposes a kind of relation to associate different public transport services to become a through service, i.e. the vehicles run through the services sequentially, allowing passengers staying on board.

Rationale

In the approved Proposed_features/Public_Transport schema, there is no provision for through service, i.e. a service which route changes between lines, where its reference number changes at the same time. This is very common in railways in Japan, where trains frequently change between lines, even lines with different operators.

Examples

Normal through service

  • A scheduled bus service first runs a part of route K58, then reforms to route K53 at an interchange for the remainder of the trip.
  • A scheduled train service from Zhaoqing to Kowloon, due to operational reason, always uses the reference number Z806 for the segment from Zhaoqing to Guangzhou East, and the reference number Z803 from Guangzhou East to Kowloon.

Circular through service

  • Light Rail routes 614P/615P (Tuen Mun Ferry Pier ↔ Siu Hong), where both termini are the same, form a circular route by means of through service. LRVs on route 614P change to route 615P at either terminus and vice versa.
  • Bus S56 (Tung Chung Station → Tung Chung North → Airport → Tung Chung Station), itself a circular route, forms a through service with itself at its terminus, i.e. passengers may remain on board waiting the bus passing the terminus without leaving the vehicle or re-pay the bus fare, enabling passengers travelling between any two points on the route (e.g. from Airport to Tung Chung North).

Tagging

Key Value Meaning
type=* route indicates this is a route relation compulsory
route=* bus/train/light_rail/... indicates the mode of transport of the route compulsory
ref=* the combined reference number of the through service if the through service has a reference number, composed by its parts, identified on its marketing materials recommended if available
from=* Station name The origin station of the through service recommended
to=* Station name The destination station of the through service recommended
roundtrip=* yes/no If yes, this indicates there exists a through service between the last segment and the first segment, creating a through service where the passengers can remain on board indefinitely compulsory if yes

Members

Role Member Count Meaning
none relation type=route 1 or more The segments composing the through service, in the order where the vehicle travels through. The route=* of the members have to be the same as the parent relation, the ending way in a member relation has to be connected to the starting way in the next member relation, and the last stop_position/platform in a member relation may be the same to the first stop_position/platform in the next member relation.

If roundtrip=yes, the above also applies between the last and the first relation members.

Rendering

None. Only affects public transport routing.

External discussions

Discussion on mailing list about multiple reference numbers

Comments

Please comment on the discussion page.

Voting

  • I approve this proposal I approve this proposal. Jc86035 (talk) 12:00, 23 November 2016 (UTC)
  • I approve this proposal I approve this proposal. emergency99 (talk) 03:34 1 December 2016 (UTC)
  • I oppose this proposal I oppose this proposal. Polyglot (talk) 05:18, 1 December 2016 (UTC)
  • I oppose this proposal I oppose this proposal. Weide. If some variants (type=route) of a public transport route (type=route_master) are collected in an additional relation, this relation should not be tagged with type=route. And route=light_rail is not part of the approved proposal mentioned above (The text voted upon was changed after the vote).
  • I oppose this proposal I oppose this proposal. The essence of the "how" is not disclosed. Relations route_master should include relations with all directions and references. --FreeExec (talk) 11:52, 2 December 2016 (UTC)
  • I approve this proposal I approve this proposal. erkinalp 16:03, 28 January 2017 (UTC)
  • I oppose this proposal I oppose this proposal. ToniE (talk) 05:24, 28 April 2017 (UTC). The tagging does not introduce new tags but only routes as member. Routes should not be members of other routes.