Re: [sumo-user] clarification for gtfs2pt outputs

[Jakob Erdmann <namdre.sumo@xxxxxxxxx>]

Apologies for the long answering delay caused by the summer holidays.

> 2) the --repair option, which helps me trim the GTFS file to the small network I have.

Option --repair only takes effect when running with option --osm-routes. The recommended workflow uses osm stops (with option --stops) instead of option --osm-routes. 

> 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. 

I agree. It seems we currently do not test/account for the fact that the same sequence of stops could schedule different timings within the trip.

This is now tracked at https://github.com/eclipse-sumo/sumo/issues/18238

> 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? 

When stop 'until' values are defined in a named route, they are used as offsets for the vehicle departure time. See https://sumo.dlr.de/docs/Simulation/Public_Transport.html#stops_in_a_stand-alone_route

> 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?

The assignment of sub_indices to distinguish both directions of the same line (or different stop sequences that have the same line id in GTFS), only uses the order of appearance in the GTFS files

The 'direction' field is not evaluated.

> - 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?

The option --use-gtfs-stopids was a recent addition. Thank you for pointing out a novel bug (https://github.com/eclipse-sumo/sumo/issues/18237)

regards,

Jakob

Am Di., 4. Aug. 2026 um 22:03 Uhr schrieb Soheil Keshavarz via sumo-user <sumo-user@xxxxxxxxxxx>:

Dear SUMO community,

I am following up on the email I sent earlier about gtfs2pt outputs. I would appreciate any guidance when you have a chance.

Best,
Soheil

On Mon, Jul 20, 2026 at 2:53 PM Soheil Keshavarz <soheil99@xxxxxx> wrote:

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

soheil99@xxxxxx  /  washington.edu

Wilson Ceramic Laboratory, floor 2

_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user