Written by: Roger Slevin
Date: 25th March 2007
Version Number: 1.0
NaPTAN is the National Public Transport Access Nodes database, created and maintained locally by Local Transport Authorities - and maintained by Thales Information Systems as a national database for the Department for Transport (also acting for the Welsh and Scottish Governments).
NaPTAN is a key underpinning data source for an increasingly wide range of systems and services which use data about public transport operations - including Traveline, Transport Direct, Accessibility Planning (Accession and other software), various transport planning and transport assessment services and more besides. And it now underpins the Electronic Registration of Bus Services (EBSR) currently under test and expected to be launched nationally during 2007.
To ensure that NaPTAN meets the requirements of all these applications, and can be transmitted between applications, there is a detailed standard specification for the data and an XML schema to carry it. The guidance and schema were updated in 2005/06 and the current version (at March 2007) is v2.2 - although v2.1 is substantially the same and continues to be accepted. Details of the schema and comprehensive technical guidance can be found at and downloaded from www.naptan.org.uk.
This note, however, seeks to provide a simple guide to the key features of the data for those who are creating and editing NaPTAN records. It comprises extracts from the comprehensive guidance along with additional clarification.
A separate note is available concerning the creation and management of NPTG - the national Gazetteer - to which NaPTAN refers for its location-based information.
NaPTAN seeks to assemble and maintain a single source of information on the location and naming of bus stops and other public transport access nodes. NaPTAN includes the following main elements:
NaPTAN stop point identifiers are a systematic way of identifying all UK points of access to public transport. Stops are submitted by administrative area authorities to a central service which consolidates the stops and distributes them back to users.
For every NaPTAN stop there are one or two associated NaPTAN identifiers, each unique within the UK:
The NaPTAN database holds a current copy of all GB stops and their descriptions. Data about stops are submitted by Public Transport Authorities (Metropolitan, County and Unitary) to a central authority which validates and aggregates the stop point data to the national database. The central authority returns the validated data to the submitting authority, and makes it available to others for download in various formats.
The NaPTAN schema was updated and enhanced in 2005 to address issues which had arisen with v1, and to assist in the process of improving data quality. With effect from January 2007, NaPTAN data has only be accepted from authorities in v2 format (preferably XML) although downloads continue to be available in both CSV and XML, and in both v1 and v2 formats. The national database is held in v2 format.
All significant elements of data are subject to "version control" - that is, they must be dated and time-stamped each time they are created or changed. Database management systems such as Transoniq, Routewise, AIM and others should manage these version control attributes automatically - including the situations where the version number increases because a DEPENDENT item of data has changed. Because of this complexity, which is essential to allow data users to identify changes easily, the Department for Transport considers it is not practical for NaPTAN data in version 2 to be managed using spreadsheets.
The NaPTAN database currently is maintained centrally by Thales Information Systems, under contract to the Department for Transport.
NaPTAN data is described by a NaPTAN XML Schema. The schema can be used to describe NaPTAN data when exchanging it between systems as XML documents. The schema describes the content model: not only the elements and Datatypes, but also the rules for combining them. The schema can be used with software tools to check that documents are correctly formatted and have the required content.
The two fundamental entities of the NaPTAN schema are StopPoint and StopArea.
A StopPoint represents a physically identifiable point of access to public transport, for any mode of travel - bus, rail, air, taxi, etc - including bus stops, rail stations, and ferry ports. In a bus station each Bay is a separate StopPoint. In rural areas where there is just one stop flag for both directions NaPTAN requires two separate StopPoints, one for each direction - one will be a Marked (MKD) stop, whereas the other will be an unmarked custom-and-practice (CUS) stop.
Each stop is assigned a unique reference number - the AtcoCode - by the local transport authority responsible for the stop (or by DfT's contractor in the case of stops managed nationally). The AtcoCode is built up of three components :
In addition, each stop for which departure time information can be accessed using the national SMS service, should also have a NaptanCode - a nationally unique 7 or 8 character code that complies with the national standards for this particular code. It may be expressed in alpha or numeric characters, the first three of which denote the local transport authority's area in which the stop is situated. No two consecutive characters can be based on the same telephone key, and the numeric characters 0 and 1 are not permitted. Kizoom, Thales and others offer tools which ensure the allocation of unique permitted codes for use in this field.
Each stop is geocoded to 1m precision using Ordnance Survey all-numeric grid references to 6 characters each for easting and northing. These coordinates are used centrally to calculate Latitude and Longitude which are then added to the NaPTAN database.
Each stop is then named in a way that the public would recognise. The name is held in two fields - the CommonName and the Indicator (used to be called Identifier). :
The CommonName should be a simple name - typically the name of a nearby landmark, or a nearby side-street or (in some cases) the name of the street on which the stop is located. It should NOT be a composite of two street names, or of a landmark and a street name - and it should NOT include details which should fall within the Indicator field. The aim should be to have a unique name for each obvious group of stops (the StopArea - see below) within a single "locality" (see below) - a name that is shared between stops within that StopArea, but is otherwise unique within the Locality.
The Indicator is intended to be a very short way of qualifying which stop (of two or more that may have the same CommonName) is being referred to, and is a qualifier to the CommonName. So these could be items such as : o/s, opp, adj, Bay1, Stance B, Stop C, o/s 23, E-bound. The test that should be applied is "does this Indicator work well with the CommonName?"- so good examples of this combination would be :
St Peter's Church, opp
Coronation Street, adj
Post Office, o/s
Bus Station, Bay 1
War Memorial, stop C
High Street, o/s 23
Redfield Farm, E-bound
Stops may also be located by reference to a nearby Landmark, a nearby side-street name (known in NaPTAN v2 as a Crossing), or the road on which the stop is situated (known in NaPTAN v2 as Street). NaPTAN therefore holds this information as well - the Landmark and Crossing are optional (but one of these generally is then used as the CommonName), whilst the Street on which the stop is located is mandatory. As noted above, there are some circumstances in which a stop can use the Street as its CommonName - where there is no better alternative, and where the road is short enough to have only one set of relevant stops ... so that the CommonName is unique to that one set of stops.
Displays for real-time systems, ticketing systems, etc may require a shorter name - the ShortCommonName - and provision exists in NaPTAN v2 for such a short version to exist. The maximum number of characters for ShortCommonNames is something which can be fixed locally to meet the requirements of particular systems used locally.
The final physical attribute attached to the StopPoint is the Bearing - this is the direction (using the conventional 8 points of the compass) in which the vehicle is pointing when it is stopped at the StopPoint.
To give a stop a location that can be found in a national context, each StopPoint is associated with a Locality using the NptgLocalityCode. This should be the code of the lowest-level locality in which the stop is located. The code, which is taken from NPTG, is associated with its locality name (and with its parent and grandparent localities, if these exist) when the data is uploaded to the central repository - and this data is then added there to the records. It is also possible to associate a stop with one or more secondary localities (again defined using NptgLocalityCode) as might be appropriate if the stop lies on the border between localities.
The importance of the way all of these fields are populated can be seen by considering how the separate data elements are used automatically in information systems. Consider the following examples which describe stops in slightly different ways:
LocalityName, CommonName (indicator)
LocalityName, CommonName (on Street), indicator
LocalityName, indicator CommonName (on Street)
LocalityName, Street - CommonName (indicator)
ParentLocalityName, CommonName (on Street), indicator
You should ensure that your data can be used in all these formats and will read sensibly without duplication. It is important to keep each element as short as possible to avoid these composite names being too long for, say, the timing point section of a matrix timetable.
NaPTAN also has fields for Town and Suburb. These have no national significance and can be left blank unless they have a specific local use.
There is a field entitled LocalityCentre. If this field is used (and it is not mandatory at present), then it should be set to "1" (to indicate "yes") for those stop points which would be considered to represent the centre of the locality to which the stop has been assigned. This should be used sparingly, attached only to the most central of stops in each locality.
Each stop must be given its appropriate classification. There is a StopType which, for bus stops, is further classified by BusStopType. The table below shows the various values available for these classification fields.
|Stop Point Type||Stop Area|
|Group||Mode||Description||Entrance||Access Area||Bay / Pole||Sub Type||Primary Area|
|Ferry||Ferry / Port||FTD*||FER||FBT*||--||GFTD|
|Metro & Tram||Metro Station||TMU*||MET||PLT*||--||GTMU|
|Bus & Coach||Bus or Coach Station||BCE*||BST||BCQ||--||GBCS|
|On Street||Bus||Bus Coach on Street||-||--||BCT||MKD||GBPS, GCLS, GCCH|
|Shared Taxi Rank||STR||--||--||--|
* these elements are not widely used in public-facing information, but may be used internally within some journey planners
In addition, bus stops have a TimingStatus. This has three possible values to indicate a preferred status for the stop - is it a Principal Timing Point (PTP - significant for Registration purposes), a Time Info Point (TIP - where a public time is declared for information) or neither of these (OTH). Bus operators remain free to change the TimingStatus from its default value in their registrations.
Hail-and-Ride Stops (HAR) and flexible Demand Responsive Service zones (FLX) each require supplementary records to define their extent. In the case of Hail-and-Ride stops, each record comprises the entry and exit coordinates of the section of road defined as Hail-and-Ride. In the case of Demand Responsive Service zones, a sequential list of coordinates defines the points describing the boundary of the area within which the service picks up and/or sets down.
All name fields in NaPTAN v2 are associated with a language element to allow for multi-lingual names to be used, either in the main stop record, or in the alternate names records. All stops can have alternative descriptors - CommonName, ShortCommonName, Landmark, Crossing, Street and/or Indicator, whether in the same language or in a different language.
A StopArea is a way of representing a group of stops which are close to each other - they may comprise a pair of stops (one in each direction) or a cluster of stops around a junction, or a number of adjacent stops at which interchange might take place. A StopArea has a location and a name, and contains individual NaPTAN points or other StopAreas ... so a single physical stop may be part of a StopArea - and a StopArea may be part of a larger StopArea. StopAreas are organised hierarchically by type - with each able to contain other StopAreas at its own level or below, but not above. The hierarchy, from the highest level downwards, is
So a rail station may contain a stop area representing a Metro Station and other StopAreas representing Bus Stops; but a Metro Station cannot contain a stop area representing a Rail Station.
A bus station is a StopArea which contains a cluster of individual stopping points (each bay or stance must be a separate StopPoint in NaPTAN). For arrivals, a special "unidentified bay" (BCQ) can be used to cater for the situation where buses may set down at different bays in a bus station - but departures should always be coded to use the correct physical stop. The only exception might be where, say, coach services leave from any one of several adjacent bays, depending on which one is free ... this forms another application for the BCQ stop type.
Each StopArea has the equivalent of a CommonName - and generally this should be the same name as that which is used as the CommonName for each of the stops in the StopArea. AlternativeNames can also be assigned to stop areas for ease of finding them in Gazetteers - and all names are associated with a language to allow for multi-lingual naming where relevant.
Every StopPoint and StopArea must belong to an NPTG AdministrativeArea, which is responsible for managing it and its data. A StopArea may belong to a different AdministrativeArea from that of some of the stop points it contains - although this should be avoided wherever possible. The StopArea is considered to be associated with all the NPTG localities (and alternative localities) of its member stops. Different stops in a given stop area may belong to different NptgLocality instances - but again use this option only where essential. Normally the stops of a stop area will belong to the same NptgLocality, but it is possible that the stops may be in different NPTG localities that are either adjacent to each other, or contained within one or the other (that is, hierarchically related through an 'is part of' association, either directly or indirectly).