3 ms·

I think I've found the issue with the 11m distance - the 11m distance is: [-0.126102, 51.502769] to [-0.126018, 51.502714] What is happening is that the TfL s

I think I've found the issue with the 11m distance - the 11m distance is: [-0.126102, 51.502769] to [-0.126018, 51.502714] What is happening is that the TfL sequence API is starting the bus route sequence on one side of the road of Parliament Street, before turning it around at the corner with Whitehall Place. The bus stops on either side of the road are very close together. Other maps/sequences elsewhere start the sequence at the end of Parliament Street, meaning the short distance is avoided.

zimpenfish 7y ago
Ah, you're parsing the `lineStrings` blob? I'm looking at the lat/long pairs in the `stopPointSequences` structure[1] which gives a different set of coords (in particular, 51.502769, -0.126102 doesn't exist as a stop for the 53.) [1] `.stopPointSequences | .[0] | .stopPoint | .[] | [.name, .id, (.lat|tostring), (.lon|tostring)]` in jq parlance
- superqwert 7y ago
  Interesting! I wonder why the Line strings blob differs... Maybe it doesn't represent bus stops at all, but points at which the route changes for the purpose of drawing?
  - zimpenfish 7y ago
    It does seem to be "the route as you'd show on a map" - if I plot the two sets points on GPSVisualizer, it's fairly different. https://imgur.com/a/BUSW3C2 https://imgur.com/a/BUSW3C2 I guess the 389/631 routes are reasonably simple and don't need more "drawing points" than you'd get from the bus stops anyway? [edit: added the 389 bus stops and line points to the imgur gallery]
    - superqwert 7y ago
      nice!
- superqwert 7y ago
  but then... why would my query have matched your query in the cases of 389 and 631?!
- superqwert 7y ago
  In fact, it seems for 53 that none of the lineStrings match the stopPointSequence lat/lons