Closed felixmt closed 1 year ago
Hello, Any news on this issue ? Having the same problem when processing any gtfs thanks
Sorry for the late reply. Passing extended GTFS route types through pfaedle has been an often-requested feature, and hopefully I will come around to implementing this this week (it shouldn't be too much work).
I am not so sure, however, if extended route type 400 should be mapped to "classic" route type 1. 400 is "Urban Railway Service". "Subway". "Subway/Metro/Unterground" is 401 or 402, and these are mapped to classic route type 1.
This is now fixed in master via 43904f2. Extended route types are now fully supported.
Generally, there are now two types of MOT selection in the -m
parameter and the config file: (1) string-based MOTs (tram
, rail
, bus
, etc.), which now capture classes of MOTs (for example, tram
contains the classic type 0
, and all extended types for tram services). This preserves the old behavior of existing config files and command line invocations. (2) integer-based MOTs (1
, 2
, 1006
, 1700
, etc.). This matches only the specific MOT ID.
In the config file, this allows e.g. to define a section [rail]
for all rail services, and later a section [101, 102]
which refines the config for high-speed and long distance trains.
On GTFS that use extended route types extension (https://developers.google.com/transit/gtfs/reference/extended-route-types), pfaedle switch route_types back to the 1, 2, 3 notation. On top of that, it switches route_types 400 (subway) to route_types 2 instead of 1.
Any idea how we could tell pfaedle not to update the route_types ?
Thanks, Félix