1 The Purpose of NaPTAN

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:

2 The NaPTAN Model

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 :

• The first three numbers denote the authority responsible for the stop
• The fourth character is either a "0" (zero) or "G" - 0 indicates that it is a StopPoint, whereas G indicates it is a group record, otherwise known as a StopArea
• The remainder of the code can be of up to 8 alpha-numeric characters determined locally in any format

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
Off Street	Air	Airport	AIR*	GAT		--	GAIR
	Ferry	Ferry / Port	FTD*	FER	FBT*	--	GFTD
	Rail	Rail Station	RSE*	RLY	RPL*	--	GRLS
	Metro & Tram	Metro Station	TMU*	MET	PLT*	--	GTMU
	Bus & Coach	Bus or Coach Station	BCE*	BST	BCQ	--	GBCS
			-	-	BCS	MKD
On Street	Bus	Bus Coach on Street	-	--	BCT	MKD	GBPS, GCLS, GCCH
					BCT	CUS
					BCT	HAR
					BCT	FLX
	Taxi	Taxi Rank	TXR	--		--	--
		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

1. Airport
2. Ferry Port
3. Rail Station
4. Metro Station
5. Bus / Coach Station
6. Coach Stop
7. On-street Bus / Coach Stop cluster
8. On-street Bus / Coach Stop pair
9. Taxi rank

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