Combo route support in new version
danielleogden opened this issue · comments
Hi Brendan,
Our dev is running into the error below when running gtfs2html on Sonoma County Transit, which has combo routes. As a workaround, they were able to run g2h successfully on this feed with an older version of g2h that uses mongo--Version 0.18.5.
The new version of g2h does not seem to support multi-routes. Can you update it so that it includes the functionality that previously handled this? Let me know if you need more info.
Can you share with me the GTFS you are using? When I tried it with http://data.trilliumtransit.com/gtfs/sonomacounty-ca-us/sonomacounty-ca-us.zip published 14-Apr-2021 I didn't get that same error. Combined route timetables like timetable_id 2150 (route 12/14) and 2224 (routes 44, 44X, 48, 48X) worked as expected using the latest version of GTFS-to-HTML.
Hi! @brendannee When we run timetables the feed used/updated for any agency will be the one that ends in --ttable. (Just for future reference!) This is the one that was used. http://data.trilliumtransit.com/gtfs/sonomacounty-ca-us/sonomacounty-ca-us--ttable.zip
Also I don't believe the issue is that this newest version doesn't support multi-routes. It does. Adding Evan here to give insight from the Support side.
@brendannee I'm also investigating on our side how an errant stop could show up on timetable_stop_order.txt when it isn't in a corresponding row in stop_times.txt
I believe the ideal situation would be that g2h would perform a similar skip function to what it does when it finds an empty timetable - produce an empty timetable with some kind of indication that 'timetable_stop_order contains invalid value' for that table.
The larger use case is for our Transit Custom Posts tool which relies on values included in timetables.txt even if we don't need those values to generate new timetables using g2h. In this exact scenario, we needed to generate two new tts, with all the others remaining the same. The timetable_stop_order file got modified on a table we didn't need, but we couldn't necessarily remove that row from timetable.txt because we needed it for TCP. It's definitely a data integrity error, but as with any error, it is usually desirable to have the tool record the error and move on, rather than shut down.
I pushed version 1.4.15 which logs issues like this and proceeds instead of breaks, so you can have routes with invalid data in timetable_stop_order and not affect the processing of all other routes.
Try it out and let me know what you think.
This worked! Thank youuu @brendannee :)