I’ve come across the following inconsistencies in bus-related data in the Unified API, that I have not been able to resolve on my own understanding:
490000345Z, 999188670, 999188661 and 999188652 are all listed as stops on bus routes, but are of type NaptanRailAccessArea and have no child records. I have not seen predictions when querying any of these ids
490G000117 is listed as a stop on a bus route, but is of type NaptanRailAccessArea, and has a child record 490000453X which is a NaptanPublicBusCoachTram; should the route be referencing this instead? I have not seen predictions when querying either id
Several route sequences have a difference between the number of line strings and ordered line routes - e.g. 142 outbound has 1 line string, and 2 ordered line routes. Should there be 2 line strings? Or 1 ordered line route?
Some stops are not mentioned in any route sequences. e.g. 490000149L has no lines, and is not on any route sequences, yet has live predictions for route 21 inbound. Conversely, stop 490000149Z looks like it is the same stop, has lines and is on the route sequence for route 21 inbound, but has no live predictions.
Is anyone able to shed some light on these? Are they anomalies, or am I missing something?
490000345Z I think that lots of bus routes that were going into Canning Town station are being diverted for a while for reason that escape me.
999188670, 999188661 and 999188652 I think that TfL are no longer serving these stops in Potter’s Bar, but the stops are still there.
490G000117 might be another TfL stop that is no longer served by TfL with NaptanRailAccessArea being used as holder.
142 route might be doing something odd in Edgware. The bus station/tube interface there is very unusual.
490000149Z is probably a last-stop where the bus ends: the TfL system predicts departures, not arrivals so the last “stop” is omitted as the bus only arrives there.
I guess my more general question is how am I meant to determine whether a stop should be shown to my users, given the “strange” examples above? Should I be showing them the stops that you say TfL are no longer serving? In my app, I show the list of stops any particular route stops at, and these stops are still listed as part of routes. But if they’re no longer being served by TfL, I’ll be presenting inaccurate information. Shouldn’t TfL remove the stops from the routes if they’re no longer being served?
I note what you say about route 142 possibly doing something strange near Edgware. But that doesn’t help me understand what to do with a route that has N line strings and M ordered line routes. Which line strings belong with which routes? Surely there should be the same number of each?
Re 490000149Z - no, it is not a last stop, it’s right smack in the middle of the route. It’s a stop I use myself not infrequently (although not in the last few weeks!). Again, I’m concerned about the experience for my users. They will have no way to see the live predictions for that stop. In fact, I’ve just checked on TfL’s website (by selecting bus, then route 21, then change direction, and clicking on Moorgate Station in the list), and they can’t display live predictions for this stop…so it seems this is definitely a data issue that should be fixed.
I suppose that, at worst, my app will display the same inaccuracies as TfL’s website, but it sure makes it difficult to work out the precise logic to use when determining which StopPoints I should be showing to users.
Just to pick up on the line string vs. route issue, there was a discussion in this thread about the mismatch here. I also recall that the line strings for a given route were always the outbound ones, even for inbound responses. I haven’t had occasion to look at them in more detail recently, but I haven’t seen any posts that suggest that the issues have been resolved,
Regarding unserved stops, there are quite a few stops around bus stations (Peckham comes to mind) that are there for use when the bus station is closed. So they’re real stops that, for most of the time, don’t have any bus serving them.
Looking at 490000149Z, this is shown as being on Ropemaker Street, which seems unlikely. I’m wondering if this is the temporary stop replacing stop B (490000149B), which is closed during the works to Moorgate station.
Further on closed stops, there has been quite a lot of discussion on this forum as to when, or if, the database is updated during route diversions. The result seems to be that it is a complete lottery as to whether the changes are registered, regardless of the expected length of time of the diversion. This is also reflected on the (separate) displayer and announcer systems on the buses themselves, which may or may not reflect what is actually happening at any given moment.
@stile@briantist as a local resident (small world!) I’m pretty sure they’re still served by TfL - a quick Google shows those IDs to be stops for the 313 which services the secondary school just down the road. Since the schools are closed at the moment they may not be stopping there for the time being which could explain the weird data?
This is probably what “out of use” means. The other sort is when bus routes get changed on a semi-perm basis by new building works taking out a bus stop (due to a site entrance, say), but always with the intention of reinstating it, such as around Gallons Reach DLR.
It’s a big deal to actually close a bus stop, but new ones get created all the time like I saw recently at Barking Riverside.
The three 999… codes relate to the afternoon school journey from Dame Alice Owen School, according to the Datastore file. The corresponding inward stops have numbers in the 2100… series. Sad as it may be, I have some older information on stops as well and it seems that before 2015 the stops in both directions were numbered 999…
It might be that a mass renumbering of stops in the area (or even all stops in Hertfordshire?) took place then, in which case why were these three missed? I think it is the case that other services use that route inwards to the school but only the 313 uses it outwards (other services running via Baker Street). Perhaps the stops were overlooked at that point by whoever (Hertfordshire? TfL?) did the renumbering.
The main 313 used to start from further west and I imagine that the anomalous 313 routeing was used to enable it to serve an extra stop on route of the main service. It need not do that any more but still does - I have seen it.
Stop 490000149Z is shown as a southbound stop on 21 43 and 141, described as Moorgate Station, so not on Ropemaker Street. It has only been in Datastore files for a few weeks. These routes are often diverted via Eldon Street and so on, so often that last time I was there I could see a permanent stop on the diversion routeing! Stop 490000149L has not been seen on Datastore files for many years, so predictions for that code are a bit of a mystery. The predictions on my favourite London Vehicle Finder app jump straight from Finsbury Square to Great Swan Alley, then to Bank Station - no Moorgate Station stop shown (and no diversion?). A simple miscode?
Thanks, @nickp, @J15t98J, mjcarchive and briantist (again) for all your input! (Sorry, can only tag 2 of you apparently as a “new user”)
I’ll have another look at the line strings in light of what you say, @nickp - that does potentially help de-mystify it to an extent.
And I suppose I’ll just have to accept that there will be inconsistencies in the data generally, although thankfully in a small number of cases. Given that the same data drives TfL’s own website, at least my users can’t accuse me of being any less accurate than that.
