Public Transport Location Referencing in Gt Britain

Public Transport Location Referencing in Gt Britain

Roger SlevinStandards Manager

Transport Direct Team

Department for Transport

London

The context Government was to launch new national travel

information service in 2004 – to be called Transport Direct

This built on experience with traveline, a public transport information service launched in 2000

Traveline has been delivered through collaboration between transport operators and local transport authorities : 11 regional organisations of varying size covering 140 local transport authorities

Traveline had built on previous experience of some leading local transport authorities

The inheritance During the 1990s, authorities and suppliers had

reached voluntary agreements for data sharing Based on ATCO .CIF “Common Interchange

Format” which had reached v5.1 by 2000 Included a standard for referencing stops (but not

location or naming standards) – 12 characters in format

nnnfamamamam (eg: 040012AB3826) Three number prefix for transport authority [nnn] One digit “flag” for location within or out of area [f = 0 or 1] Up to 8 alphameric characters for each stop [amamamam]

no prescribed format Many linked to asset management systems

Other factors Same structure could be used for other public transport

locations Rail industry had TIPLOC codes for all stations,

comprising up to 8 (normally alpha) characters National Express Coaches had a stop reference of five

numbers and one alpha International Airports have an IATA code of three

letters; domestic airport codes have four letters All could be given their own “national mode” prefix to fit

the same coding structure Before traveline started there was a de facto national

standard for referencing public transport locations

The need and opportunity Regional traveline services did not need to exchange

information – but Transport Direct will need to do so Users of Transport Direct will face an order-of-

magnitude more information covering whole country Stop codes were unique nationally – but no consistent

standards for classifying, naming or locating them Over £1m made available in 2002 for local transport

authorities to build National Public Transport Access Nodes – NaPTAN – database

How was it built & maintained? Work done by each of the 140 local transport

authorities following written guidance We learnt that there were about 350,000 bus stops

nationwide (Gt Britain) Work took longer, and cost more, than expected –

fundamentals completed in 2004 but still needs more work on naming and some other aspects

Guidance not strong enough in some areas and not followed by many editors … hence issues with naming stops; these are unhelpful but not fundamental to use of NaPTAN

Stop referencing revisited NaPTAN was built around the ATCOcode (also known

as the NaPTAN code) of 12 characters as the database key

ATCOcode is an INTERNAL back-office code By 2003, however, a case for a PUBLIC-FACING code

was becoming clear with the proposals for offering information on-the-move through mobile devices

Initial requirement was Short Messaging Service (SMS) Clean sheet – so need to consider

Administration of the codes – creating and allocating them to stops Matching codes within information systems The end-user experience

Developing the SMS code End-user experience dictated constraints – aim was

ease of use within SMS rules Occasional users of SMS would not find numbers easy Repeat presses of same key change character if done quickly

So some rules were adopted Codes better expressed in alpha rather than numeric Codes should be unique based on sequence of key presses Repeat pressing of same key should not be required System should parse all multiple key presses as the same as one key press

Led to use of alpha-8 characters (keys 2-9) Area prefixes, though, should look sensible

For example KNT for Kent

Users still only have to press each key once So they can key JMT rather than KNT for Kent; system treats them as the

same

SMS code format Based on the rules, SMS code is in two parts

Three alpha characters for local transport authority area Three, four or five alpha-8 characters for the stop reference in that area

Transport authorities with large areas were offered multiple prefix codes where necessary to give enough codes using four alpha-8 characters

But most large transport authorities have opted for one prefix and five alpha-8 characters

So typical code would be

kntdjtgm knt is the area prefix djtgm is the stop reference in that area

Other SMS codes and syntax Rules adopted for bus stops could follow the

agreed principles. Syntax can accept line number after location code to target information.

Rules for other modes – aim to follow similar principles if possible, but legacy codes may conflict with ease-of-use rules

Rail stations – back-office uses TIPLOC code but there is a shorter three-letter CRS code used in ticketing and reservations; not based on alpha-8; target information by destination station

Airports – information needed by IATA code and flight number; not based on alpha-8

Key to using stop codes Both the legacy ATCOcode and the new, more

efficient SMScode, are part of the NaPTAN record ATCOcode is the legacy key to the data; SMScode

could become the key in future. Systems using SMS code currently have to cross-reference to ATCO code

All route and timetable data in systems currently is referenced to ATCOcode data

What’s in NaPTAN We have the keys in ATCOcode and SMScode Modes : Air, Ferry, Rail, Metro/Tram, Bus, Taxi What is in the database for every stop?

The location : National Grid Reference and WGS84 to 1m precision A “Common Name” – should be short (but legacy names can be very long) The name of the road on which stop is located The name of a nearby landmark or cross-street An “Indicator” – could be a marked stop number, or a relationship to the entity

in Common Name (eg: opposite, outside, stop 7, Bay G) A pointer to a named locality in the National Public Transport Gazetteer The ability to have alternate names and localities, and different languages The type of stop (mode specific) – and sub-type where relevant

Systems using NaPTAN & NPTG have rich options for searching for stops and mapping their locations

What else is in NaPTAN? Links to other standards are important

Location referencing uses equivalent to TPEG-loc Also includes direction of travel at each stop to link to TPEG

Gazetteer linkage allows drilling down NPTG is hierarchical gazetteer of cities, towns, suburbs and villages Where relevant, lowest-level (child) localities have a “parent” and even a

“grand-parent” NaPTAN links to child locality for each stop; systems can drill-down to

this from parent or grand-parent localities

Stops can belong to pairs, groups or clusters (a “stop area” in Transmodel)

Hierarchical structure of major interchange types Airports, ferry ports, rail stations, coach and bus stations

Other NaPTAN features Ability to handle different types of stop – marked,

unmarked, Hail-and-Ride sections of route, service zones for Demand Responsive operations

Uncertainty of stop usage – service uses whichever one of a set of stops is available

Attach other features – eg: stop is in PlusBus zone for integrated rail/bus ticketing

Stops are moved temporarily or permanently … maintain history for dependent information

All data with strict versioning – will allow in future for change-only updates

Considering interchanges NaPTAN contains basis for interchange model Each interchange comprises three levels :

Entrance – relevant to modelling walk links between stops Circulation area – a point to represent the entity in simple models Platforms – greater detail where relevant

Groups can also exist within groups A cluster of bus stops outside a rail station can be a group (passengers

change between buses) That cluster can be part of the rail station group (passengers change

between bus and train) Can also have Taxi ranks and Shared Taxi ranks within the groups

What are we referencing? When public ask for information they don’t know

the PRECISE stop they need – they are asking about stops in an area .. from a pair or cluster of stops

When we give information we must give PRECISE information about the stop that is used so traveller finds the required service

So Gazetteering and consistent naming of stops within a single stop area / cluster are crucial to asking the question; information systems need to treat precise questions as imprecise ones

Precise stop codes are essential in giving answers

Underpinning model NaPTAN – and related UK standards such as

NPTG, TransXChange and JourneyWeb – all based on principles in Transmodel

All standards have just been revised to be modular – links between them have been strengthened – links to Transmodel have been made clearer through naming

Lessons for standards NaPTAN and related developments are an important

application of Transmodel standards within UK Question for CEN and ISO is what aspects of this work

would benefit from NEW standards? For CEN, Transmodel already includes the intellectual

database model for stop referencing. Other standards such as TPEG cover location referencing.

ISO does not have Transmodel as frame of reference. Is this significant?

UK example shows how any one country will come to stop referencing with different legacies and pressures – the data model is the key standard, not its implementation

Conclusions Transmodel already provides the conceptual data

model for describing stops, and stop areas Giving these codes will depend on legacy codes,

particularly those operationally significant (eg: rail station codes used in timetables and ticketing) or already set by other standards (eg: IATA)

Coding structures can follow simple principles – {[international] –} [national area] – [stop code] – but is this a significant “standard”.

Local circumstances will dictate format of [stop code] – and may be different if public facing to that used only for internal system purposes

The challenge to TC204 The UK experience has gone a lot further than

SNSPTS proposes – because it needed to UK based its work on Transmodel conceptual data

model, which provides robust framework UK believes NaPTAN is one of its DOMESTIC

standards implementing Transmodel principles Is SNSPTS an implementation standard of a

conceptual data model? If it is too prescriptive, can it ever be accepted internationally?

Is this a microcosm of the TCIP / Transmodel debate? Do Transmodel principles underpin TCIP? Is TCIP a local implementation standard?

References NaPTAN schema and documentation (v2) – also

covers NPTG

www.naptan.org.uk TransXChange (v2) – schema for conveying route

and timetable description, uses NaPTAN and NPTG

www.transxchange.org.uk JourneyWeb – schema for journey planning and

other information systems to communicate with each other. Follow link from

www.kizoom.co.uk

Contact details

Roger Slevin

4/02 Gt Minster House

76 Marsham Street

London SW1P 4DR

Phone : +44 20 7944 2668

E-mail : [email protected]