Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [sumo-user] Vehicle Route Conconation
Hi Mirko, Hi Jakob,

thank you very much for your responses, and your ideas.

I have followed your advice and successfully implemented a method of joining routes in the desired manner.
However, I continue to experience some issues.

My intended implementation has buses perform a long route, consisting of multiple „lines“ e.g a service trip with stops and predefined edges, connected by deadheads generated trough net.getFastestPath().
While the connected routes are simulated successfully when excluding busStops, adding busStops to service trips results in following error:

Error: busStop 'agg_11800_1_11164_1_10948_8_12561_10_10965_1' for vehicle 'cicero_3006' on lane '30144130#1_0' is not downstream the current route.

If I understand correctly, this is “intended behaviour”, in so far as the bus performs a stop at the first opportunity, but has then skipped other stops, leading to there not being any opportunities for stopping at following stops?

How can I create a more concise route-definition, or force my vehicle to perform stops only in the intended way?

I have included two routes files and the busStop.add, cut down to the vehicle and stop for which I get the error.
Presumably this happens for more than this one vehicle, but it does not happen for every vehicle as a few depart before the affected one.

Running /tools/route/routecheck.py just results in this warning:
    Warning: This script does not handle nested 'stop' elements properly.

I have also found others encountering the same error, but their circumstances seem quite different to my own.
https://www.eclipse.org/lists/sumo-user/msg00324.html
https://github.com/eclipse-sumo/sumo/issues/15626

Version: SUMO 1.27.0

Best regards
Sven


Jakob Erdmann <namdre.sumo@xxxxxxxxx> schrieb am Donnerstag, 2. Juli 2026 um 08:21:
I also think this could be handled fairly easy in a pre-processing script (which should be written in python to be eligble for inclusion in our tool suite).
Something that reads your description above and concatenates route edges and route stops into a single long route with all the stops.
You may need an extra attribute for each route that specifies the expected service period for that segment in order to shift the 'until' times forward on each concatenation.
Giving your requirements to a coding assistent and doing rigorous testing may already be sufficient.

Am Mi., 1. Juli 2026 um 20:31 Uhr schrieb Mirko Barthauer via sumo-user <sumo-user@xxxxxxxxxxx>:

Hi Sven,

it would be rather similar to the repeated loop concept in the sense that it is merely some parsing/generating code before the simulation starts. I imagine this is similar to what you do now externally.

  • define / load shorter routes first
  • define a new route which refers to a sequence of previously defined routes in a special attribute "concatenate" (maybe there is a better name)
    • when parsing the route, check for the attribute "concatenate"
    • look up the referred routes, return an error if they cannot be found or cannot be joined through the common last/first edge
    • otherwise get the edges of the routes and join, adapting until values

Best regards,
Mirko

Am 01.07.2026 um 19:36 schrieb Sven:
Hi Mirko,

thank you for your response.
Im afraid looping and flows are not suited for my goal of simulating persistent vehicles operating accoarding to multi-line schedules.

Your Idea for a "conconation" attribute however sounds very interesting.
How would that work? Could you elaborate on that?
If there is a way for me to implement a functionality like that myself, id be very willing to put in the time.

Best regards
Sven




-------- Original Message --------
On Wednesday, 07/01/26 at 19:26 Mirko Barthauer via sumo-user <sumo-user@xxxxxxxxxxx> wrote:

Hi Sven,

AFAIK there is currently no such thing like creating a new route from 2+ arbitrary route building blocks internally or even keeping a list of routes to take one after another. As it seems just another way of defining routes, this may be possible to implement. I'd rather define a new attribute "concatenate" where the building blocks can be put so there is no confusion whether there are routes and edges of the same name.

However if you have bus services repeatedly serving the same line (both directions), you can make it a looped route (see docs). That way you can define it once and then set the repeat attribute (which internally will make sumo copy the route edges).

Best regards,
Mirko

Am 01.07.2026 um 17:40 schrieb Sven via sumo-user:
Dear SUMO-Community,

my name is Sven, ive written here before, a few weeks ago. I have since continued to work on a project concerning the charging behaviour of electric buses.

Many thanks to Moritz Schweppenhäuser, i really like your work and your scenario is very helpful to me.

However, i seem to have hit a blockade within my own approach of simulating.
While SUMO provides routes, flows and some interaction via TraCI, there seems to be no supported way of having vehicles use what id call "modular routes".

For my bus-simulation, it would be ideal to have vehicles perform their service one route after another, by providing a list of pre-defined routes, to then have a vehicle perform multiple of these, one after another:

<routes>
<vType id="bus" vClass="bus"/>
<route id="161_A" color="" edges="A B C">
<stop busStop="X1" duration="20.0" until="20.0" parking="true"/>
<stop busStop="X2" duration="20.0" until="80.0" parking="true"/>
</route>
<route id="161_B" color="" edges="C D E">
<stop busStop="X3" duration="20.0" until="20.0" parking="true"/>
<stop busStop="X4" duration="20.0" until="80.0" parking="true"/>
</route>
</routes>
<routes>
    <vType id="type1" accel="0.8" decel="4.5" sigma="0.5" length="5" maxSpeed="70"/>
    <vehicle id="0" type="type1" route="161_A 161_B" depart="0" color="1,0,0"/>
    <vehicle id="1" type="type1" route="161_B 161_A" depart="0" color="0,1,0"/>
</routes>
My current plan is to generate new routes from these partial-routes beforehand, but this requieres a lot of effort, of calculating possible combinations, and "until" values, for potentially many hundred routes.
I am therefore asking, wether there are more convinient ways to achive what im planning, or if such a feature could potentially be implemented sometime.
Best regards
Sven

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

Attachment: stop_not_downstream.zip
Description: Zip compressed data

Back to the top