NaPTAN/Birmingham Trial

From OpenStreetMap Wiki
Jump to: navigation, search

A trial import of NaPTAN data for the West Midlands region was commenced at the end of March 2009.

Currently Imported Data

Town Date Imported Number of nodes Notes
Birmingham 30/03/09 4332 Missing bearing and stop type
Coventry 08/04/09 1442
Dudley 03/04/09 1439
Oldbury 03/04/09 843
Solihull 03/04/09 986
Walsall 03/04/09 1398
West Bromwich 03/04/09 657 Reimported, originally 01/04/09
Wolverhampton 03/04/09 1153

Surveying and Merging NaPTAN and OSM data

  • Christoph has commenced work on a merging tool that will help visualise the different datasets (NaPTAN and OSM).
  • Custom for merging data is still evolving but at the moment the following is suggested:
    • highway=bus stop on the single merged node
    • The location of the node adjusted from accurate survey or an average position taken between the NaPTAN node point and the OSM node point. We have already established that NaPTAN nodes in Birmingham can be off position by anything between 5m and 100m so its ok to move NaPTAN nodes around but make sure the road alignment is correct before you do this manually if you haven't checked the position of a stop with a GPS receiver.
    • It's important to be standing EXACTLY at the bus stop and is best done when stationary not attempting to capture its position when driving or cycling past.
    • Where the bus stop is not kerbside but there is a pull-in for the bus like a mini-layby, the bus stop will be positioned some extra distance from the median line represented in the renderers. Suggest adding a tag layby=yes to indicate why the bus stop is further back than kerbside ones
    • Removal of the naptan:unverified=yes tag
    • Ensure that source tag is edited to source=naptan_import;survey
    • Where present the route_ref tag should be propagated with the bus route numbers separated by semicolons

If a NaPTAN node is not physically present on the ground and you have no knowledge that it is used as a stop then:

  • Add a physically_present=no tag
  • Do NOT add a highway=bus_stop tag

If a NaPTAN node is not physically present on the ground but you have knowledge that it is used as a stop then:

  • Add a physically_present=no tag
  • Add a highway=bus_stop tag
    • --Brianboru 13:18, 3 April 2009 (UTC) or, we could leave the naptan node as is with unverified tag deleted and a note to the effect it's a stop with no physical presence. This way our data is correct and the map only renders what is physically present. For non-mappers I would think this is more intuitive. Tagging it as highway=bus_stop will get it rendered and most people using the map won't get to see the physically-present=no tag and could be confused thinking that there is actually a bus stop there(i.e a pole with a plate on it)
      • Once we start making relations for the route's we will need to have those stops which have no physically present features but where the bus does actually stop. blackadder 13:40, 8 April 2009 (UTC)

These latter stops may already have a NaPTAN "CUS" tag which indicates its a customary stop. We might make that explicit by adding a customary_stop=yes tag.

Verification Progress

A list of localities from the ITO NaPTAN management tool.

Locality Being Verified by Date verified Notes
Boldmere Blackadder blackadder 3 April 2009 (UTC)
Sutton Coldfield Blackadder blackadder 1 April 2009 (UTC) 27% of stops on physically present
West Bromwich Various Bus station and partial completion during West Bromwich mapping party April 2009
Wylde Green Blackadder blackadder 2 April 2009 (UTC)

Import Omissions

  • Bearing (only missing for Birmingham region)
  • 'CUS' bus stop types are unmarked on the ground, yet imported as full stops. (only missing for Birmingham region)
  • Import the "Locality" tag to help group data as ITO NaPTAN management tool does
    • This is part of the NPTG data, so is not being handled in the first pass of the datasets.
  • There's a route local to me user:Brianboru where there are whole roads where the bus stops have been removed and the roads are designated as Hail and Ride zones (information from latest published timetable. Is the practice on the ground ahead of the NaPTAN data?

Sample Data

Please leave any comments on the converted data below - now is the time to complain if you have any issues with the conversion, or the way data is copied for tag values, it can be changed! If you think of something that may save us all time in the QC stages, please also comment. Merging of existing and newly imported NaPTAN data will have to be done by hand until another tool exists to help us.

Image Existing OSM Data Converted NaPTAN Data Raw NaPTAN Data
[1]
<node id="321803637" lat="52.5328477" lon="-1.8297563">
<tag k="route_ref" v="104;104A;105;110;112;115;118;902;904;905;915"/>
<tag k="highway" v="bus_stop"/>
<tag k="shelter" v="yes"/>
<tag k="location" v="Sutton Road;The Yenton"/>
<tag k="asset_ref" v="504956"/>
<tag k="towards" v="Sutton Coldfield"/>
</node>
<node id="-4863" lat="52.5328926843" lon="-1.8298454687">
    <tag k="created_by" v="naptan2osm" />
    <tag k="local_ref" v="YF" />
    <tag k="naptan:AdministrativeAreaRef" v="105" />
    <tag k="naptan:AtcoCode" v="43000503702" />
    <tag k="naptan:CommonName" v="The Yenton" />
    <tag k="naptan:Indicator" v="Stop YF" />
    <tag k="naptan:NaptanCode" v="nwmdgpgm" />
    <tag k="naptan:PlusbusZoneRef" v="BHAMNWS" />
    <tag k="naptan:Street" v="SUTTON RD" />
    <tag k="naptan:Bearing" v="NE" />
    <tag k="naptan:unverified" v="yes" />
    <tag k="source" v="naptan_import" />
</node>
<StopPoint CreationDateTime="2004-08-19T00:00:00"
 ModificationDateTime="2009-01-20T00:00:00"
 Modification="revise" RevisionNumber="40" Status="active">
  <AtcoCode>43000503702</AtcoCode>
  <NaptanCode>nwmdgpgm</NaptanCode>
  <Descriptor>
    <CommonName>The Yenton</CommonName>
    <Street>SUTTON RD</Street>
    <Indicator>Stop YF</Indicator>
  </Descriptor>
  <Place>
    <NptgLocalityRef>N0072585</NptgLocalityRef>
    <Town>BIRMINGHAM</Town>
    <LocalityCentre>1</LocalityCentre>
    <Location>
      <Translation>
        <GridType>UKOS</GridType>
        <Easting>411639</Easting>
        <Northing>292793</Northing>
        <Longitude>-1.8298454687</Longitude>
        <Latitude>52.5328926843</Latitude>
      </Translation>
    </Location>
  </Place>
  <StopClassification>
    <StopType>BCT</StopType>
    <OnStreet>
      <Bus>
        <BusStopType>MKD</BusStopType>
        <TimingStatus>OTH</TimingStatus>
        <MarkedPoint>
          <Bearing>
            <CompassPoint>NE</CompassPoint>
          </Bearing>
        </MarkedPoint>
      </Bus>
    </OnStreet>
  </StopClassification>
  <AdministrativeAreaRef>105</AdministrativeAreaRef>
  <PlusbusZones>
    <PlusbusZoneRef CreationDateTime="2008-06-18T17:18:13"
     ModificationDateTime="2008-06-18T17:18:13"
     Modification="new" RevisionNumber="0" Status="active">
      BHAMNWS
    </PlusbusZoneRef>
  </PlusbusZones>
</StopPoint>
[2]
<node id="203919" lat="52.5506776" lon="-1.8253467">
<tag k="route_ref" v="104;104A;105;110;112;902;904;905;915"/>
<tag k="highway" v="bus_stop"/>
<tag k="location" v="Birmingham Road;Monkseaton Road"/>
<tag k="asset_ref" v="0561201"/>
<tag k="towards" v="Sutton Coldfield"/>
</node>
<node id="-5231" lat="52.5511188804" lon="-1.8258666765">
    <tag k="created_by" v="naptan2osm" />
    <tag k="naptan:AdministrativeAreaRef" v="105" />
    <tag k="naptan:AtcoCode" v="43000561201" />
    <tag k="naptan:CommonName" v="Monkseaton Rd" />
    <tag k="naptan:Indicator" v="opp" />
    <tag k="naptan:NaptanCode" v="nwmdgwgt" />
    <tag k="naptan:PlusbusZoneRef" v="BHAMNWS" />
    <tag k="naptan:Street" v="BIRMINGHAM RD" />
    <tag k="naptan:Bearing" v="N" />
    <tag k="naptan:unverified" v="yes" />
    <tag k="source" v="naptan_import" />
</node>
<StopPoint CreationDateTime="2004-08-19T00:00:00"
 ModificationDateTime="2009-01-20T00:00:00"
 Modification="revise" RevisionNumber="47" Status="active">
  <AtcoCode>43000561201</AtcoCode>
  <NaptanCode>nwmdgwgt</NaptanCode>
  <Descriptor>
    <CommonName>Monkseaton Rd</CommonName>
    <Street>BIRMINGHAM RD</Street>
    <Indicator>opp</Indicator>
  </Descriptor>
  <Place>
    <NptgLocalityRef>E0032154</NptgLocalityRef>
    <Town>BIRMINGHAM</Town>
    <LocalityCentre>1</LocalityCentre>
    <Location>
      <Translation>
        <GridType>UKOS</GridType>
        <Easting>411905</Easting>
        <Northing>294821</Northing>
        <Longitude>-1.8258666765</Longitude>
        <Latitude>52.5511188804</Latitude>
      </Translation>
    </Location>
  </Place>
  <StopClassification>
    <StopType>BCT</StopType>
    <OnStreet>
      <Bus>
        <BusStopType>MKD</BusStopType>
        <TimingStatus>OTH</TimingStatus>
        <MarkedPoint>
          <Bearing>
            <CompassPoint>N</CompassPoint>
          </Bearing>
        </MarkedPoint>
      </Bus>
    </OnStreet>
  </StopClassification>
  <AdministrativeAreaRef>105</AdministrativeAreaRef>
  <PlusbusZones>
    <PlusbusZoneRef CreationDateTime="2008-06-18T17:18:13"
     ModificationDateTime="2008-06-18T17:18:13"
     Modification="new" RevisionNumber="0" Status="active">
      BHAMNWS
    </PlusbusZoneRef>
  </PlusbusZones>
</StopPoint>

Comments

Refer to history for fixed issues.

  • <tag k="local_ref" v="YF" /> Prefer tag k="naptan:indicator" v="YF"
    • We already import the full form of the indicator as naptan:Indicator, some automatic parsing of the local_ref will be useful, since afaict it's not been tagged in anywhere, although the stops have the details on them. We can assume that any stop refs of this form will be correct and most likely displayed. --Thomas Wood 12:17, 26 March 2009 (UTC)


Echo Brian's comments. Where we import a NaPTAN data element we should always place a naptan: in front of the key, that verifies the source. If the same value already appears in the OSM database (ie NaPTAN and OSM have the same data) then we can decide if we maintain a duplicate in its different key form when we do verification survey on the ground. Keeping the two separate and distinct gives us a way of differentiating between the data that's been imported and the data that's obtained from survey. We know from other data sets that there will be errors in each direction and this approach is better able to flag the differences. Finally, if in doubt, we should add the NaPTAN data even if its questionable about its use today, we never know if it might be useful to others in the future. blackadder 10:52, 26 March 2009 (UTC)

I'll just add that in other areas, it'd make more sense to pull in all data we can, rather than just leaving the majority under the naptan: namespace. --Thomas Wood 19:06, 27 March 2009 (UTC)