Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proportion of trips on different route_types #107

Open
mpadge opened this issue Jun 15, 2023 · 4 comments
Open

Proportion of trips on different route_types #107

mpadge opened this issue Jun 15, 2023 · 4 comments

Comments

@mpadge
Copy link
Member

mpadge commented Jun 15, 2023

The "routes" tables have a "route_type" column which specifies:

  • 0 Tram, Streetcar, Light rail. Any light rail or street level system within a metropolitan area.
  • 1 Subway, Metro. Any underground rail system within a metropolitan area.
  • 2 Rail. Used for intercity or long-distance travel.
  • 3 Bus. Used for short- and long-distance bus routes.
  • 4 Ferry. Used for short- and long-distance boat service.
  • 5 Cable tram. Used for street-level rail cars where the cable runs beneath the vehicle, e.g., cable car in San Francisco.
  • 6 Aerial lift, suspended cable car (e.g., gondola lift, aerial tramway). Cable transport where cabins, cars, gondolas or open chairs are suspended by means of one or more cables.
  • 7 Funicular. Any rail system designed for steep inclines.
  • 11 Trolleybus. Electric buses that draw power from overhead wires using poles.
  • 12 Monorail. Railway in which the track consists of a single rail or a beam.

These values could be mapped on to the timetable used in all C++ routines, and the proportions of all trips in these categories calculated for each route (in time, not distance). Current routines return matrices with 3 columns: start times, durations, ntransfers. This would require one additional collumn for each route type, so would have to be restricted to something like the first four, and even that would more than double the size of the returned matrix. This could obviously only be implemented as an optional extra ability, and not in any default mode. Note also that these are strictly integer matrices, so values would have to be total times along each mode, which could later be converted to proportions by dividing by the first column of total duration.

library (gtfsrouter)

# -------- load and prepare feed:
gtfs <- extract_gtfs ("./feeds/freiburg.zip")
#> ▶ Unzipping GTFS archive✔ Unzipped GTFS archive
#> Warning: This feed contains no transfers.txt 
#>   A transfers.txt table may be constructed with the 'gtfs_transfer_table' function
#> ▶ Extracting GTFS feed✔ Extracted GTFS feed 
#> ▶ Converting stop times to seconds✔ Converted stop times to seconds
gtfs <- gtfs_transfer_table (gtfs)
from <- sample (gtfs$stops$stop_id, 10)
day <- "Monday"
gtfs <- gtfs_timetable (gtfs, day)

# -------- Then map trip_id values from timetable on to route_type values:
trip_ids <- gtfs$trip_ids$trip_ids [gtfs$timetable$trip_id]
route_ids <- gtfs$trips$route_id [match (trip_ids, gtfs$trips$trip_id)]
gtfs$timetable$route_type <- gtfs$routes$route_type [match (route_ids, gtfs$routes$route_id)]

print (gtfs$timetable)
#>         departure_station arrival_station departure_time arrival_time trip_id
#>      1:               464             467          15060        15120    2719
#>      2:               467             471          15120        15240    2719
#>      3:               471             107          15240        15300    2719
#>      4:               107             484          15300        15420    2719
#>      5:               484             564          15420        15480    2719
#>     ---                                                                      
#> 168468:               383             381         105420       105540    7949
#> 168469:               385             383         105480       105600    7941
#> 168470:               381             377         105540       105660    7949
#> 168471:               383             381         105600       105660    7941
#> 168472:               381             377         105660       105780    7941
#>         route_type
#>      1:           3
#>      2:           3
#>      3:           3
#>      4:           3
#>      5:           3
#>     ---            
#> 168468:           0
#> 168469:           0
#> 168470:           0
#> 168471:           0
#> 168472:           0
table (gtfs$timetable$route_type)
#> 
#>     0     3 
#> 83833 84639

Created on 2023-06-15 with reprex v2.0.2

Then just add extra code in the routing algorithms to aggregate those route_type values along each route, weighted by (arrival_time - departure_time).

@FlxPo
Copy link

FlxPo commented Jan 29, 2024

I don't know if you still plan to implement this, but I am interested !

For now i use gtfs_traveltimes and the start and stop ids to extract the first and last leg modes of each trip. But I can't extract the exact time / distance breakdown by mode, and I am obviously missing modes (for trips with more than one transfer).

@mpadge
Copy link
Member Author

mpadge commented Jan 29, 2024

@FlxPo Yes, definitely still planned. Unsure when, but if all goes well maybe soon. Let me know if it's a hold-up for you not having it, and i'll try to get it together sooner. Appreciate the interest 👍

@FlxPo
Copy link

FlxPo commented Jan 29, 2024

It's not a hold-up but definitely something that we need, to compute accurate GHG emissions per trip in our Mobility project (https://github.com/mobility-team/mobility).

@mpadge
Copy link
Member Author

mpadge commented Jan 29, 2024

Cool project! As an aside, let me know which French cities you'd like added to https://urbananalyst.city, and I'll happily do it. Plan for this issue is to incorporate measures of modal proportion in that platform too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants