There is an interesting debug function in GtfsData that outputs structured data after TheTransitClock processes the GTFS shapes. You can paste the output into gpsvisualizer.com, which amazingly still works. This can be helpful to see how different config parameters affect the way TheTransitClock divides up, simplifies, offsets, or otherwise processes GTFS shapes. This commit makes it easier to use this function - instead of hard coding and commenting/uncommenting the existing line in GtfsFileProcessor, you can set the new transitclock.gtfs.outputPathsAndStopsForGraphingRouteIds config option to one or more (comma separated) route ids. When you set the value, you'll get some CSV data dumped to STDERR when you run GtfsFileProcessor (i.e. import GTFS static data). Copy and paste that into http://www.gpsvisualizer.com/map_input to get a debug view of the processed shapes and stops.
The config value is null by default and will not add any debug output unless it is set.
There is an interesting debug function in GtfsData that outputs structured data after TheTransitClock processes the GTFS shapes. You can paste the output into gpsvisualizer.com, which amazingly still works. This can be helpful to see how different config parameters affect the way TheTransitClock divides up, simplifies, offsets, or otherwise processes GTFS shapes. This commit makes it easier to use this function - instead of hard coding and commenting/uncommenting the existing line in GtfsFileProcessor, you can set the new
transitclock.gtfs.outputPathsAndStopsForGraphingRouteIdsconfig option to one or more (comma separated) route ids. When you set the value, you'll get some CSV data dumped to STDERR when you run GtfsFileProcessor (i.e. import GTFS static data). Copy and paste that into http://www.gpsvisualizer.com/map_input to get a debug view of the processed shapes and stops.The config value is null by default and will not add any debug output unless it is set.