[sumo-user] Questions about the junction
Dear sir/madam I am conducting a test for a single intersection in SUMO. I found that when I assigned the pedestrian from the west to the south, he/she didn't follow the crossings, instead, he/she simply moves from the northwest corner to the southeast corner (see figure below, ped 6). I noticed that my vehicle road is one-way, and the pedestrian road is generated with the vehicle road, deleting the left side of the pedestrian road will correct the pedestrian behavior. However, I want to keep the sidewalks and I wonder if there exist any ways I can avoid this crossing *without* changing the sidewalk(pedestrian lanes)? The test file is also attached. Thanks for your time and every help! Best regards, Yiran [image: image.png] <> ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
Re: [sumo-user] define route id through randomTrips.py
That isn't possible at the moment. Note, that randomTrips doesn't generate any routes, only trips. The routes are created in the background by the duarouter application. Code contributions are welcome (https://github.com/eclipse/sumo/issues/8643) Am Di., 18. Mai 2021 um 17:07 Uhr schrieb Xun Liu : > Hello everyone, > > > > I am using randomTrips.py to generate the route file for the network. And > in my generated rou.xml file, there is no route id for every route. > Therefore, I would like to consult if there were possible methods to assign > the id for every generated route. Thanks. > > > > Yours, > > Xun > ___ > sumo-user mailing list > sumo-user@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/sumo-user > ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
[sumo-user] define route id through randomTrips.py
[cid:image003.jpg@01D74BD5.E9F1BC90] Hello everyone, I am using randomTrips.py to generate the route file for the network. And in my generated rou.xml file, there is no route id for every route. Therefore, I would like to consult if there were possible methods to assign the id for every generated route. Thanks. Yours, Xun ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
Re: [sumo-user] Obtaining the estimated time of arrival of the vehicle
Thanks Dear Jakob, After trying various methods, including the one you gave me, the difference in estimated arrival times has been resolved! The problem was that the exittime of the duarouter did not include the travel time of the junction. So I set net.xml to --no-internal-links and that solved the problem! Thank you for always answering my questions. The information you have given me has helped me understand Sumo better. Best regard, Nishikawa - Original Message - From: Jakob Erdmann To: Sumo project User discussions Date: 2021-05-18 17:58:58 Subject: Re: [sumo-user] Obtaining the estimated time of arrival of the vehicle The speed depends on the right-of-way rules and traffic on minor roads has to slow down before entering the intersection. You can reduce the slow-down by setting a higher value for attribute 'visibility' of the connection elements (if vehicles can observe that the intersecion is free of traffic they do not have to slow down). Or you can set all junction types to "unregulated" which disables right-of-way rules. Am Di., 18. Mai 2021 um 10:23 Uhr schrieb g2121044 : Thank you for your reply. I changed the VType and was able to reduce the difference in arrival time a bit. However, there is still a big difference. After observing the simulation, there is still a deceleration of 1 to 2 m/s at the junction and I think this is one of the reasons. For reference, I changed the limitTurnSpeed in net.xml from 5.5 to 13.88, but the speed through the junction is still 6~7m/s. Looking at the following page, is it not possible to change the speed for the safety of the car? https://sumo.dlr.de/docs/Simulation/Safety.html Other than changing limitTurnSpeed, is there any other way to change the speed through the junction? regard, Nishikawa - Original Message - From: Jakob Erdmann To: Sumo project User discussions Date: 2021-05-18 16:02:21 Subject: Re: [sumo-user] Obtaining the estimated time of arrival of the vehicle In the simulation, there are some random factors that affect vehicle speed. See https://sumo.dlr.de/docs/Simulation/Randomness.html You can eliminate them by re-configuring the vType with sigma="0" speedDev="0". Note, that there can still be interaction at junctions which are not predicted by duarouter. Am Di., 18. Mai 2021 um 07:57 Uhr schrieb g2121044 : Hello. I have a question about this email. https://www.eclipse.org/lists/sumo-user/msg09369.html I forgot to include the net.xml information in this email. The conditions I used in my simulation are ・No traffic lights ・No randomly generated general vehicles (only demand cabs) ・Equal speed limit on the map The conditions are as follows Even though I eliminated all factors that affect the arrival time of the vehicles, there was a difference between the exitTime and the simulation time. The difference is created even when the vehicle is running in a straight line. This difference seems to grow in proportion to the distance traveled. For example, if I want to know the estimated time of arrival of a demand cab, is there any way to know it other than using duarouter(--exit-time)? I'm sorry for repeating myself. regard, Nishikawa ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
Re: [sumo-user] Get all public transport routes between an origin and a destination
There is currently no tool that supports this. As a workaround you could - parse the intermodal routing graph written by duarouter --intermodal-network-output and do your own exhaustive search - run duarouter repeatedly and remove some or all used transport lines from the input until you get no new results. regards, Jakob Am Di., 18. Mai 2021 um 12:00 Uhr schrieb Bachmann, Frederik < frederik.bachm...@tum.de>: > Dear all, > > > > is it possible to get all possible public transport routes for a person > between an origin and a destination? > So far I tried the “alternatives-output” of duarouter”, which gave me > merely one trip definition for each person as alternatives, even though the > options “max-alternatives” was set to 20 and “keep-all-routes” was set to > true. > > findallroutes.py gave me a list of routes defined by lists edge-ids but > did not consider public transport. > > > > Thank you. > > > > Kind regards, > > Frederik > > > ___ > sumo-user mailing list > sumo-user@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/sumo-user > ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
[sumo-user] Get all public transport routes between an origin and a destination
Dear all, is it possible to get all possible public transport routes for a person between an origin and a destination? So far I tried the "alternatives-output" of duarouter", which gave me merely one trip definition for each person as alternatives, even though the options "max-alternatives" was set to 20 and "keep-all-routes" was set to true. findallroutes.py gave me a list of routes defined by lists edge-ids but did not consider public transport. Thank you. Kind regards, Frederik ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
Re: [sumo-user] Obtaining the estimated time of arrival of the vehicle
The speed depends on the right-of-way rules and traffic on minor roads has to slow down before entering the intersection. You can reduce the slow-down by setting a higher value for attribute 'visibility' of the connection elements (if vehicles can observe that the intersecion is free of traffic they do not have to slow down). Or you can set all junction types to "unregulated" which disables right-of-way rules. Am Di., 18. Mai 2021 um 10:23 Uhr schrieb g2121044 : > Thank you for your reply. > I changed the VType and was able to reduce the difference in arrival time > a bit. > However, there is still a big difference. > After observing the simulation, there is still a deceleration of 1 to 2 > m/s at the junction and I think this is one of the reasons. > For reference, I changed the limitTurnSpeed in net.xml from 5.5 to 13.88, > but the speed through the junction is still 6~7m/s. > Looking at the following page, is it not possible to change the speed for > the safety of the car? > https://sumo.dlr.de/docs/Simulation/Safety.html > > Other than changing limitTurnSpeed, is there any other way to change the > speed through the junction? > > regard, > Nishikawa > > *- Original Message -* > *From: Jakob Erdmann >* > *To: Sumo project User discussions >* > *Date: 2021-05-18 16:02:21* > *Subject: Re: [sumo-user] Obtaining the estimated time of arrival of the > vehicle* > > In the simulation, there are some random factors that affect vehicle > speed. See https://sumo.dlr.de/docs/Simulation/Randomness.html > You can eliminate them by re-configuring the vType with sigma="0" > speedDev="0". > Note, that there can still be interaction at junctions which are not > predicted by duarouter. > > Am Di., 18. Mai 2021 um 07:57 Uhr schrieb g2121044 : > >> Hello. >> I have a question about this email. >> https://www.eclipse.org/lists/sumo-user/msg09369.html >> >> I forgot to include the net.xml information in this email. >> The conditions I used in my simulation are >> ・No traffic lights >> ・No randomly generated general vehicles (only demand cabs) >> ・Equal speed limit on the map >> The conditions are as follows Even though I eliminated all factors that >> affect the arrival time of the vehicles, there was a difference between the >> exitTime and the simulation time. The difference is created even when the >> vehicle is running in a straight line. This difference seems to grow in >> proportion to the distance traveled. >> >> For example, if I want to know the estimated time of arrival of a demand >> cab, is there any way to know it other than using duarouter(--exit-time)? >> >> I'm sorry for repeating myself. >> >> regard, >> Nishikawa >> ___ >> sumo-user mailing list >> sumo-user@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/sumo-user >> > > > ___ > sumo-user mailing list > sumo-user@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/sumo-user > ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
Re: [sumo-user] Obtaining the estimated time of arrival of the vehicle
Thank you for your reply. I changed the VType and was able to reduce the difference in arrival time a bit. However, there is still a big difference. After observing the simulation, there is still a deceleration of 1 to 2 m/s at the junction and I think this is one of the reasons. For reference, I changed the limitTurnSpeed in net.xml from 5.5 to 13.88, but the speed through the junction is still 6~7m/s. Looking at the following page, is it not possible to change the speed for the safety of the car? https://sumo.dlr.de/docs/Simulation/Safety.html Other than changing limitTurnSpeed, is there any other way to change the speed through the junction? regard, Nishikawa - Original Message - From: Jakob Erdmann To: Sumo project User discussions Date: 2021-05-18 16:02:21 Subject: Re: [sumo-user] Obtaining the estimated time of arrival of the vehicle In the simulation, there are some random factors that affect vehicle speed. See https://sumo.dlr.de/docs/Simulation/Randomness.html You can eliminate them by re-configuring the vType with sigma="0" speedDev="0". Note, that there can still be interaction at junctions which are not predicted by duarouter. Am Di., 18. Mai 2021 um 07:57 Uhr schrieb g2121044 : Hello. I have a question about this email. https://www.eclipse.org/lists/sumo-user/msg09369.html I forgot to include the net.xml information in this email. The conditions I used in my simulation are ・No traffic lights ・No randomly generated general vehicles (only demand cabs) ・Equal speed limit on the map The conditions are as follows Even though I eliminated all factors that affect the arrival time of the vehicles, there was a difference between the exitTime and the simulation time. The difference is created even when the vehicle is running in a straight line. This difference seems to grow in proportion to the distance traveled. For example, if I want to know the estimated time of arrival of a demand cab, is there any way to know it other than using duarouter(--exit-time)? I'm sorry for repeating myself. regard, Nishikawa ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
Re: [sumo-user] Obtaining the estimated time of arrival of the vehicle
In the simulation, there are some random factors that affect vehicle speed. See https://sumo.dlr.de/docs/Simulation/Randomness.html You can eliminate them by re-configuring the vType with sigma="0" speedDev="0". Note, that there can still be interaction at junctions which are not predicted by duarouter. Am Di., 18. Mai 2021 um 07:57 Uhr schrieb g2121044 : > Hello. > I have a question about this email. > https://www.eclipse.org/lists/sumo-user/msg09369.html > > I forgot to include the net.xml information in this email. > The conditions I used in my simulation are > ・No traffic lights > ・No randomly generated general vehicles (only demand cabs) > ・Equal speed limit on the map > The conditions are as follows Even though I eliminated all factors that > affect the arrival time of the vehicles, there was a difference between the > exitTime and the simulation time. The difference is created even when the > vehicle is running in a straight line. This difference seems to grow in > proportion to the distance traveled. > > For example, if I want to know the estimated time of arrival of a demand > cab, is there any way to know it other than using duarouter(--exit-time)? > > I'm sorry for repeating myself. > > regard, > Nishikawa > ___ > sumo-user mailing list > sumo-user@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/sumo-user > ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
Re: [sumo-user] somulib parse_fast_nested
Please update to the latest repository version which now supports all use cases. Am Mo., 17. Mai 2021 um 22:04 Uhr schrieb Sasan Amini : > Dear all, > > since version 1.9.1 I noticed a small change in the sumolib/xml.py in > parse_fast_nested function i.e. > https://github.com/eclipse/sumo/commit/72e6bf842a49dba9c1399ef608eecf187addf7ac#diff-05f6455dc67b972faeae4013588d6f120b07c16f68621556b98aff3d144579d1 > that causes duarouter/marouter output parsing not working as in the > previous version of the function. > Currently, I cannot retreive the attributes of route element as I could > previously using my python script: > for row in > sumolib.output.parse_fast_nested(filePath,'vehicle',['id','depart'],'route',['cost','probability','edges']): > ((vehidi,departTimei),(costi,probi,edgesi)) = row > I undid the changes and my script works again. Just wondering how should I > adapt my code to work with the new function? > > Thanks, > Sasan > ___ > sumo-user mailing list > sumo-user@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/sumo-user > ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
Re: [sumo-user] MAROUTER: input flow and scale issue
The option --weight-priority is only compatible with Dijkstra at the moment. Am Mo., 17. Mai 2021 um 20:07 Uhr schrieb Sasan Amini : > A* (astar) routing algorithm works only when I pass no options. When I > pass the following options, it switches back to Dijsktra: > marouter --route-files ./SUMO/Demand/trips_marouter.trip.xml --net-file > ./SUMO/Net/sumo_secondary_filter.net.xml -o > ./SUMO/Output/marouter_outputastar.rou.xml --weights.interpolate > --paths.penalty 1 --junction-taz --scale 0.001 --tolerance 0.001 > --max-inner-iterations 1000 --paths 5 --route-choice-method logit > --weight-attribute traveltime --logit.beta 0.15 --logit.gamma 4 > --logit.theta 0.01 --max-iterations 1 --keep-all-routes > --weights.priority-factor 100 --routing-algorithm astar > --aggregation-interval 3600 --routing-threads 36 --netload-output > ./SUMO/Output/netload_Marouterastar.xml --verbose --ignore-errors --log > ./SUMO/Output/Marouter_logasta > r.xml > > On Mon, May 17, 2021 at 3:20 PM Jakob Erdmann > wrote: > >> CHRouter currenlty doesn't work very well with marouter: >> - the results are wrong because the contraction hierarchy doesn't get >> rebuilt >> - it works slowly since CHRouter doesn't support efficient 1-to-many >> routing >> >> try astar. >> >> Am Mo., 17. Mai 2021 um 13:02 Uhr schrieb Sasan Amini > >: >> >>> I am passing the following command with almost all default values for >>> the parameters: marouter --route-files >>> ./SUMO/Demand/trips_marouter.trip.xml --net-file >>> ./SUMO/Net/sumo_secondary_filter.net.xml -o >>> ./SUMO/Output/marouter_output.rou.xml --weights.interpolate >>> --paths.penalty 1 --junction-taz --scale 20 --tolerance 0.001 >>> --max-inner-iterations 1000 --paths 5 --route-choice-method logit >>> --weight-attribute traveltime --logit.beta 0.15 --logit.gamma 4 >>> --logit.theta 0.01 --max-iterations 10 --keep-all-routes >>> --weights.priority-factor 10 --routing-algorithm CH --aggregation-interval >>> 3600 --routing-threads 36 --netload-output >>> ./SUMO/Output/netload_Marouter.xml --verbose --ignore-errors --log >>> ./SUMO/Output/Marouter_log.xml >>> I tried multiple versions with fewer options too (which I didn't save) >>> and still I got the response from Dijkstra router. >>> >>> On Mon, May 17, 2021 at 12:48 PM Jakob Erdmann >>> wrote: >>> There is only the code: https://github.com/eclipse/sumo/blob/64a041537ce537690f5a22edcc46ef40df8d5fa0/src/marouter/ROMAAssignments.cpp#L115-L163 astar should work fine with marouter default options. Which options are you passing? Am Mo., 17. Mai 2021 um 12:02 Uhr schrieb Sasan Amini < amini...@gmail.com>: > Thank for the explanation. Are there any documents to help me make a > realistic guesstimation of travel times? What I see in the course code is > travelTime > = capacityConstraintFunction(edge, newFlow / intervalLengthInHours); > and thought travel times are directly exportable from Marouter. What > is the exact form of the capacityConstraintFunction? I think I can extract > densities from the netload file, but to calculate travel times I need to > know the function. The network is too big to run sumo even in the > mesoscopic model. > One other issue I noticed was that no matter which router I give to > Marouter, in the end, I always get the message Dijksrarouter has answered > the queries. I think in the current implementation only the Dijsktra > router > is working (could be related to: > https://github.com/eclipse/sumo/issues/6935)? > > Thanks, > Sasan > > On Mon, May 17, 2021 at 11:08 AM Jakob Erdmann > wrote: > >> The issue with fromJunction and toJunction is now fixed. >> >> The route costs in marouter are travel times multiplied with a >> traffic-density dependent capacityConstraintFunction. >> The actual travel time can only be guessed at at this point since it >> will depend on vehicle interactions. To compute empty-network travel >> times >> you can pass the marouter-routes to duarouter. If you need more realistic >> traveltimes, simulate with sumo. >> >> Am Fr., 14. Mai 2021 um 16:48 Uhr schrieb Sasan Amini < >> amini...@gmail.com>: >> >>> True, the scale parameter works perfectly fine. I am not sure if I >>> was testing it on a nightly build version of 1.8.x, but now on 1.9.0 it >>> works. >>> However, the fromJunction - toJunction option for route files is not >>> working, while it works perfectly fine in DUAROUTER. Moreover, for the >>> output of MAROUTER I was under the impression that route costs are >>> travel >>> times (since the weight attribute is by default traveltime) but I get >>> values that are much larger than traveltime, maybe distance in meters? >>> Is >>> this cost in MAROUTER modifiable i.e. to get travel time of each trip? >>> >>> Best, >>> Sasan >>>
[sumo-user] SUMO Version 1.9.2 hotfix released
Dear friends and users, due to a bug in traci related to subscriptions we are releasing 1.9.2 as a hotfix. The download links are at https://sumo.dlr.de/wiki/Download There are some additional fixes and even some enhancements in this release and the most important ones are listed below. For a full list of changes, as always see https://sumo.dlr.de/wiki/ChangeLog === Bugfixes === - traci: Fixed crash when trying to read parameters for subscriptions that don't have them. - simulation: vehroute output for persons now writes the correct stopping place type (i.e. parkingArea, busStop, etc.) - netedit: When adding stops to a trip, the route now changes as necessary to pass the stop location. - netedit: Person stages that end at a busStop can now be defined. - netconvert: Added automated check to prevent disconnected routes due to invalid lane-change permissions in OSM input. - netconvert: Fixed failure of --tls.guess-signals in lefthand network. - marouter: Input attributes fromJunction and toJunction are now working. === Enhancements === - simulation: Vehroute-output now includes stop attributes 'started' and 'ended' and ride attribute 'ended' if option --vehroute-output.exit-times is set. - netedit: Vehicle attributes departEdge and arrivalEdge are now supported. - duarouter: Added option --keep-route-probability which lets a given proportion of vehicles keep their old routes (selected at random). - duaIterate.py now supports option --convergence-steps which forces route choices to converge in the given number of steps . This is recommended when usiong option --logit which otherwise may not converge at all. - countEdgeUsage.py now allows filtering and grouping counts by vehicle departure time. Have fun with the new release, Michael, Yun-Pang, Angelo, Laura, Pablo, Jakob, Robert, Giuliana, Melanie, Johannes and Matthias, ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
