Public Transport Location Referencing in Gt Britain

1. Public Transport Location Referencing in Gt Britain Roger Slevin Standards Manager Transport Direct Team Department for Transport London

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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?

21. 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

22. 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