Stops don't show up when a route has no vehicles running

[EddyIonescu]

• they should always show up, even if no vehicles are running on it

[alessandro-pianetta]

I might have found where it's going wrong; in Map.jsx in renderMap() at line 259, each route object in this.props.trynState.routes has an rid that should correspond to the route.properties.name of the selectedRouteNames. On lines like the 38, both will be 38. However, on the K/T, while the name was 'K/T', the rid was 'KT'. My guess is that this discrepancy is why the stops aren't showing up; when we .filter() the this.props.trynState.routes, it filters out those stops because 'K/T' !== 'KT' .

I'll do a little more poking around in the this.props.trynState to see if I can't fix the rid.

[EddyIonescu]

Hey @alessandro-pianetta sounds good - see a comment I wrote on it here (#62 (comment)). Seems like it's routes with dashes/slashes that have this issue due to the inconsitency between their rid and route.properties.name, which is from the GeoJSON file.

If you go to OpenTransit web-app, the K/T routes don't show up at all. As for the stops not showing up for routes with no vehicles, I think that's a separate problem (try it out for the 76X, which only runs on weekends).

The fix could involve adding a map to do the mapping, as the route IDs between Nextbus and GTFS (which was used to generate the GeoJSON). I'd prefer this map be in its own JSON file, so that it's easy to change and makes it clear as to why it's needed.

[alessandro-pianetta]

Yeah, I was able to fix the K/T since it's caused by punctuation by using replace(/[.,/#!$%^&*;:{}=\-_`~()]/g, '') when adding names to the selectedRouteNames set. However, it looks lines like the 76X and *-OWL are just missing from routes object (roughly 11, since we have 74 items in this.props.trynState.routes and 85 in sortedRoutes).

[EddyIonescu]

@alessandro-pianetta so there are two different issues at play here:

1. The mismatching route names (K/T vs. KT)
2. routes object not containing routes that have no vehicles currently running on them. This is because the API won't return a route if there are no vehicles on it (the OWL routes will appear in the middle of the night). It currently results in the stops not being displayed because they're fetched from the API.

As for the solutions:
For 1. this seems like it could cause problems in the future, I think having a mapping ({"K/T": "KT"}) might be the easiest way out of this mess. It's also important as right now the K/T line doesn't work at all on the web-app. It's a pretty useful starter ticket.
For 2, we plan on having the API return routes and route paths, so a muni geojson wouldn't be required and these errors won't happen anymore. This isn't that important, so I think the best option is to do nothing on the client side. Let me know if you'd like to work on making these endpoints available in tryn-api :)