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: AB3826)  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 TransXChange (v2) – schema for conveying route and timetable description, uses NaPTAN and NPTG JourneyWeb – schema for journey planning and other information systems to communicate with each other. Follow link from

Contact details Roger Slevin 4/02 Gt Minster House 76 Marsham Street London SW1P 4DR Phone :