NaPTAN/Aberdeen

NaPTAN Aberdeen is an import of part of the NaPTAN dataset covering the Aberdeen area of the United Kingdom. The import is currently complete as of 2019-07-16. A summary and review of the import process can be found here.

Goals

• Import data specifically for the Aberdeen admin area (ATCO code 639)
• Import stops of type BCT ("On-street Bus / Coach / Trolley Stop.")
• Import BCT stops of type MKD ("Marked (pole, shelter etc)")
• Manually conflate and review the data before upload using JOSM
• Split the edits up according to the "LocalityName" NaPTAN data field (basically districts)

A more broad goal is to establish and document a working methodology of importing NaPTAN data since it currently lies mostly dormant and unused. From what I can tell the older import process hasn't been very well documented and was never applied to the entire country.

Schedule

As this is data for a specific region and I intend to split it into smaller areas, there is no pressing need to import everything at once. I would plan to import the data as quickly as possible, but the priority is really accurate conflation (in test runs this hasn't taken very long following the process described below). I can't see the process taking more than a day or two at most.

Import Data

Background

Data source site: https://data.gov.uk/dataset/ff93ffc1-6656-47d8-9155-85ea0b8f2251/national-public-transport-access-nodes-naptan
Data license: http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3
OSM attribution (if required): https://wiki.openstreetmap.org/wiki/Contributors#Department_for_Transport_-_NaPTAN_data
ODbL Compliance verified: yes as per the NaPTAN entry at Import/Catalogue

Import Type

One time import, human conflated and uploaded using JOSM.

Data Preparation

Data Reduction & Simplification

Not really anything to simplify, this import is just bus stop nodes. Other data is present in NaPTAN and will be left out of this import.

Tagging Plans

The naptan: tagging namespace already exists and I've consulted with the talk GB mailing list to determine which tags are valuable to import

Through discussion on the talk GB mailing list (see bottom of page) I've arrived at the use of the following tags:

• highway=bus_stop
• public_transport=platform
• bus=yes
• name [Imported - defer to existing tagging during conflation]
• naptan:AtcoCode [Imported - useful for linking OSM data to NaPTAN data]
• naptan:NaptanCode [Imported - same as above, plus some external services may use this code]
• naptan:CommonName [Imported - should match name but may differ, is what the indicator is relative to]
• naptan:Indicator [Imported - useful to distinguish stops and sometimes can be loc_ref data]
• naptan:verified=no [Gets deleted upon survey verification according to the original guidelines]

Notably, these do not cover all naptan: tags which were present in the old import. The reason for this is to avoid bloating the OSM database with unnecessary tags. As per the import guidelines: "Your data source may have many many fields, but OSM data elements with many many tags can be difficult to work with."

Changeset Tags

Changesets will be marked with source=naptan_import as was previously done (see changesets of user NaPTAN) and uploaded by user naptan_import_aberdeen. Changeset descriptions will be "Uploading NaPTAN data for X" where X is the local area name.

Data Transformation

Data will be transformed from CSV into OSM XML using python (see script here).

Data Transformation Results

Here is a data file representing all of the stops that would be imported across the area. The script actually splits the data into files representing each smaller changeset (according to the "LocalityName" NaPTAN data field).

Data Merge Workflow

Load OSM XML into JOSM, conflate, upload.

Team Approach

Just me.

Workflow

1. Script will be run.
2. Output data will be loaded into JOSM.
3. JOSM conflation plugin will be used to conflate with existing data.
4. Data will be uploaded.
5. Reversion can be achieved with JOSM reverter plugin if necessary (have used it in the past, simple process).

Conflation

Data can be conflated using the JOSM conflation plugin. Below is my tested step by step process for this.

1. Open up one of the converted OSM XML files in JOSM.
2. Download bus stop data for the current area as a new layer from Overpass API
   

   [out:xml][timeout:25][bbox:{{bbox}}]; ( node["public_transport"="platform"]; node["highway"="bus_stop"]; ); (._;>;); out meta;

3. Configure the conflation settings
   1. Set the existing OSM data layer as active and Ctrl + A to select all stops, click freeze to make these the conflation reference.
   2. Set the imported data layer as active and Ctrl + A to select all stops, click freeze to make these the conflation subject.
   3. Using default settings, generate matches (can tweak if necessary, but NaPTAN data seems to be close to true stop positions).
4. Go through the list of matches and perform conflation.
   1. Check that the stop nodes being matched are actually the same stop. If not, click remove in the conflation window to unmatch them. If other stops are nearby then check for matches amongst those and manually conflate.
   2. Check the position of the stop against aerial imagery (Bing and Esri enhanced have best alignment in this region). If the existing data has a bad position, change the active layer and move the node as needed.
   3. With position and match verified, click conflate in the conflation window. This brings up a list of tag conflicts if there are any. Defer to any existing stop name. If naptan:verified=yes is present then delete the tag as per the original import guidelines.
5. Upload the data layer which was originally the imported data (now the imported and conflated data).

See also

An email to the Talk GB mailing list was sent on 2019-07-01 and can be found in the archives of the mailing list at [1].

A second (more productive) email to the Talk GB mailing list was sent on 2019-07-05 and can be found in the archives of the mailing list at [2].

An email to the Imports mailing list was sent on 2019-07-05 and can be found in the archives of the mailing list at [3].