Dear SUMO team, hope you are doing well.
I'm reaching out to raise some questions regarding your gtfs2pt.py outputs. In our work, we are basically trying to import
King County GTFS data into a network of downtown Seattle and, at the same time, enrich our simulations with Personflows created from
ridership data. To do this, I first used gtfs2pt.py with:
1) --use-gtfs-stopids option, which was recently added to the source code and helps me make my outputs tractable and connect them to ridership data, and
2) the --repair option, which helps me trim the GTFS file to the small network I have.
Here are some observations and questions regarding the outputs, and I would appreciate your guidance and clarification.
- The output demand file is formatted as a set of <route>s and a set of <vehicle>s that refer to routes. The first issue is that route ID refers to trip ID of the first trip that utilizes that route. In the example below, you see information about the first trip that uses route 100132 from gtfs files and then output route and some examples of trips generated for that path.
- Consequently, it seems that the 'until' parameter in the route only refers to that of the first trip. However, in other trips from the same route, timings could be different. Moreover, the times in the gtfs2pt output seem to be global times in the simulation and are not exact arrival/departure times in HH:MM:SS or simulation time in seconds. Could you clarify if that is the case or if the until parameter refers to the time relative to the departure time of a trip? See the example below. I think one way to fix this could be to use <trip> <stop> <trip/> format for each trip instead of coding stops within routes.
- I also noticed some ambiguity in how 'line's are coded. In the example below, you can see that for one route dircetion_id=1 is mapped to line=24 and direction_id=0 is mapped to line=24#1, but vice versa for another route. Could you please clarify how # is handled when generating gtfs2pt outputs?
- Lastly, using --use-gtfs-stopids may cause busStops with duplicate IDs, which will later cause the simulation to crash while loading the configuration file. For now, I am removing one of the stops to run the simulation but may I know the underlying issue causing this behavior?
Thank you very much for the help and your effort in keeping SUMO updated
Soheil
SOHEIL KESHAVARZ (he/him)
PhD Student | Research Assistant at iUTS Lab
Wilson Ceramic Laboratory, floor 2
