| Re: [sumo-user] Vehicle Route Conconation |
Hi Mirko, Hi Jakob,
thank you again for helping me. I was able to resolve my problem.
I have followed your advice, Mirko, which brought me to an error within the Berlin Network that I was able to fix.
Then for the larger issue.
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.
I have gotten this error because I was merging multiple routes, connected by calculating net.getFastestPath() from the last stop on the route to the first stop on the next.
If an edge had two stops that were to be connected, with the departing stop after the destination stop, the error would occur, because the calculated path would just consist of the edge that both stops were on.
This was resolved by including the start_pos and end_pos of busStops in the call for getFastestPath, forcing the function to return an actually valid path.
For documentation, the function found here: https://sumo.dlr.de/pydoc/sumolib/net.html#Net.getFastestPath
Best regards,
Sven
Hi Mirko,thank you too, for bothering to look into this.I have uploaded my network to here:Best regards,SvenMirko Barthauer <m.barthauer@xxxxxxxxxxx> schrieb am Dienstag, 7. Juli 2026 um 19:10:
Hi Sven,
as you didn't provide the SUMO network I can only give incomplete advice on the error. Generally this means your route including the stops is not feasible given the network and the vehicle class access permissions of the bus. Normally sumo should be fine with the same stop being reached multiple times within the same route. Then probably it fails already the first time reaching the stop.
I'd suggest debugging it like this:
- remove/comment out all stops in the route starting with the one triggering the error
- run sumo to check if this route does not trigger an error anymore
- display the route in sumo-gui (right mouse click for context menu of the concerned vehicle)
- show all reachable edges of this vehicle class (right mouse click for context menu of the concerned vehicle)
- check if the route passes by the stop cited in the error
If you cannot find any reason connected to your network and vehicle class access permissions, then please provide a sumocfg with all referenced files (preferably small) to reproduce the problem.
Best regards,
Mirko
Am 07.07.2026 um 16:04 schrieb Sven:
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.
Version: SUMO 1.27.0
Best regardsSven
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,
MirkoAm 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 regardsSven
-------- 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,
MirkoAm 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