search

ad-freiburg / pfaedle

Precise map-matching for public transit feeds. Generates high-quality GTFS shapes from OSM data.
GNU General Public License v3.0
208 stars 29 forks source link

route_types issue after "pfaedling" #41

Closed felixmt closed 1 year ago

felixmt commented 1 year ago

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

alexandremoyrand commented 1 year ago

Hello, Any news on this issue ? Having the same problem when processing any gtfs thanks

patrickbr commented 1 year ago

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.

patrickbr commented 1 year ago

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.