Public Transport Location
Referencing in Gt Britain
Roger Slevin
Standards 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-ofmagnitude 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



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


Occasional users of SMS would not find numbers easy
Repeat presses of same key change character if done quickly
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



Gazetteer linkage allows drilling down





Location referencing uses equivalent to TPEG-loc
Also includes direction of travel at each stop to link to TPEG
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 : roger.slevin@dft.gsi.gov.uk