Nextbus::Client.stops doesn't get detailed stop info

[jbinto]

Summary: When searching for a stop, only the @tag attribute is present. All other fields (title, lat, lng, stopId) are nil.

Details:

Nextbus::Stop.all and Nextbus::Stop.find simply defer to Nextbus::Client.stops, and perform additional filtering.

Nextbus::Client.stops just hits the routeConfig endpoint. It takes in an agency, route, and direction.

Recall that direction is a Nextbus concept.

  route
    stop (full data: tag, lat, lng, title, stopid)
    stop (full data: tag, lat, lng, title, stopid)
    ...
    direction
      stop (tag only)
      stop (tag only)
      ...
    direction
      stop (tag only)
      stop (tag only)
      ...
    path
      point
      point
    path
      point
      point

Even the Boston data was structured in this normalized fashion (list of stops under a direction only using tag id).

It seems the reason for this is just that the gem was never completed.

There are tests that purport to cover this type of thing, but it seems that it only works by coincidence due to how a quirk in Boston's data.

For instance, in TestStop#test_find, it attempts to call Nextbus::Stop.find by passing in a stop_id, and then assert that it got the right stop.tag back.

But this is a meaningless test: in Boston stop_id == stop_tag and the only thing that the Nextbus::Client.stops command returns is an array looking like:

  [{"tag"=>"14161"},
   {"tag"=>"4402"},
   {"tag"=>"2800"},
   {"tag"=>"3442"},
   {"tag"=>"8499"},
   {"tag"=>"7801"},
   ...
  ]

That's because it's just a direct mirror of the XML response from NextBus.

So it is broken in Boston as well, but the test passes due to the faulty assumption that stop_id will always == stop_tag.

The way to fix it?

Same as in the JavaScript. We need to map the stops inside a direction back to their parents.

It should be rather easy since we have the entire data structure in memory already.