Open mattwigway opened 13 years ago
Ahh. I'd wondered why Portland Streetcar only seemed to have one stop.
It seems that a number of agencies don't use nextbus stop ids. For some reason the nextbus designers saw fit to give each stop two possible ids, but only certain agencies use the stopid. I started with San Francisco Muni, which does use stopids, and so I didn't realize this issue immediately, but I noticed that AC Transit also doesn't use stop ids. (Their data isn't available via the public endpoints yet, of course.)
I think what needs to happen here is to somehow figure out which agencies use stop id and which don't and use tag when they do, or just make both available as you say. I actually wrote this library to power proximobus ( http://proximobus.appspot.com/ ) and was trying to expose only the stopids there to make things simpler, but have effectively made it useless for the agencies that don't use stopid.
Looks like the Charm City Circulator has the same problem. MIT doesn't immediately appear to have the same problem, as quite a few stops are returned, but there are multiple stops with the id of null. I put up a patched version of the library at the SVN repository for a project I'm helping with at http://code.google.com/p/transit-appliance-utils/source/browse/trunk/NextBus/nextbus.py?r=9
For some reason, Portland Streetcar and the Charm City (MD) Circulator don't put stop types in the returned XML. When the stops_dict is created, each stop overwrites the previous one since all the stop_ids are null. Since the stops property just pulls the values from stops_dict, you cannot access the stops in these agencies.
I can come up with two solutions: 1) make stops a list rather than a property, or 2) make the stops_by_tag available to the program. If you don't have unique stop IDs, you need at least to have unique stop tags (although I suppose they don't have to be unique if the stops aren't on the same route) .