It has been 8 years since the original NaPTAN (National Public Transport Access Nodes) data was imported into the UK space of OpenStreetMap in 2009. It was done on a piecemeal basis and only in areas where it was requested, which was generally where there were active mappers. Since that time I am not aware of any organised attempts to bring that data up-to-date. There will certainly have been localised efforts based purely on surveys.
So when the local OSM community, mappa-mercia, was approached by TfWM (Transport for West Midlands) with the offer of resources to bring the NaPTAN data up to date as TfWM was reviewing all their public map production and could consider OSM as a candidate for displaying this data, we leapt at the chance.
We had started out locally some 8 years ago with a lot of enthusiasm and surveyed bus stops crazily but given the scale of the task (some 12,000 bus stops) even a dedicated bunch of mappers is going to get bored – and so we did. Updates and confirmation of existing data languished outside of a couple of public transport enthusiasts and sporadic surveying by others when out surveying something else.
So two internal developers from TfWM and me set to work meeting every Tuesday afternoon in TfWM’s Birmingham head office to put matters right. Our aim was to get an accurate up-to-date map of Public Transport data in the West Midlands using mostly NaPTAN data. We planned and documented and kept relevant OSM talk lists up to date with what we were doing.
Peripheral tasks were:
1. entering the location of all the new Swift Collector points – these are where passengers can upload new ride allowances into their Swift Smart Cards
2. entering West Midands Fare Zone data to all railway stations in the region
3. entering the proposed routes of all planned Metro tram lines
The first task was to clean up the existing OSM data. This involved moving bus stop nodes that were nodes on highways rather than to one side, identifying and tagging non-naptan bus stops ( for example car park shuttle buses at the Airport, large campuses such as the National Exhibition Centre and personnel shuttle buses for multisite campuses, usually hospitals) and finally identifying, and resolving where possible, what we dubbed “orphan” bus stops which were those surveyed by OSMers but with no NapTAN data attached.
The next task was to check the positional accuracy of the current 2017 NapTAN data against both aerial imagery and known OSM well-surveyed areas, as that would determine our approach. Sadly we found that the positional accuracy had not improved systematically over the 8 years. So any refresh of NapTAN data would have to rely on OSM position.
Our next step was to remove all those bus stops marked DEL, for deleted, in the NaPTAN data by removing the highway=bus_stop tag and adding a note to that effect and leaving the remainder of the tags. This was very much a belt-and-braces approach.
Next we updated all the bus stops that had a NapTAN identifier with a standardised naming convention preferred by TfWM and agreed by the local OSM community, and with current route_ref information.
That left all the new bus stops that had been added in the intervening 8 years. This had to be done semi-manually in order not to remove any bus stops surveyed by OSMers and also to check the positional accuracy (OSM surveys always won!)
As CUS (Customary) stops do not render as there is nothing verifiable on the ground such as a pole we imported those first, as is.
Then any remaining “orphan” bus stops were checked against the new bus stops, relevant data transferred and positions moved before deleting them. We managed to remove nearly 300 of these but were unable to resolve about 50. Then the new bus stops with improved positions were imported. We could have automated this more, but preferred to adopt a more cautious , if laborious, approach of human review.
Finally, having achieved an accurate up-to-date bus stop estate we added shelter information: shelter=yes and shelter_ref=xxxxxxxx.
Loose ends are largely those bus stops still in existence on the ground with NOT IN USE displayed prominently on the pole flag, which NaPTAN treat as non-existent but OSMers can see and will map; and Ring and Ride bus stops which also were not in the NapTAN data. There are also numbers of bus stops with poles that are still labelled as CUS in NapTAN.So we never achieved 100% accuracy but the percentage of errors/queries is of the order of <1%.
Next we have to agree with TfWM not to let our hard work atrophy by entropy but keep the data up-to-date by agreeing a frequency of when we do it and a process of how we do it.
What we didn’t do: upgrade existing and enter missing bus routes as relations. Neither party was willing to devote the resources to entering these as relations. Which was a pity but maybe we have to realise that the easiest way of representing these given their quantity and volatility ( and the upcoming changes in the Bus Bill which will demand electronic submission of bus routes) is layering on the base map in a separate application.
The process in numbers
| Item | Approx number |
| Elapsed time | 3 months |
| TfWM resource hours | 30 hours |
| OSM resource hours | 30 hours |
| Total bus stops | 12,500 |
| Bus stops deleted | 400 |
| New bus stops imported | 800 |
| Orphans removed | 300 |
| Shelters added | 5,000 |
Conclusion
TfWM have some great developers and we quickly developed a rapport together. We have built good relations not only at a personal level, but also as organisations.
If the state of our bus stop data in the West Midlands is typical for the UK then we have a lot of work to do to obtain an accurate UK-wide map of bus stops. If we were to contemplate upgrading throughout the UK I would say it couldn’t be done without a dedicated full-time team and would consequently need some national sponsorship with a business case for devoting the resources necessary. A region-by-region or city-by-city approach would be more doable. So how about it OSM UK and DfT (Department for Transport)?
