| Re: [sumo-user] Rail vehicles turning around on a bi-directional edge |
_______________________________________________Thanks for the response Jakob. I did add a stop near the end of the edge, but I still encountered the same turnaround problem.After debugging the code, I think I see what's going on. The MSVehicle::canReverse() method relies on the myBidiEdge member of MSEdge. This property gets set based on a call to MSEdge::isSuperposable, which among it's check compares the shape vertex points of the 2 lanes to see if they're equal. This logic seems to work ok if the 2 edges being compared are perfectly straight, but if the edge has curves then the vertex points of the 2 lanes don't always match up 100%.I'm using Union Station in Washington DC as my sample data. It isn't setup to use bi-directional lanes, so I applied the "--railway.topology.all-bidi" flag to force it. I'm also using elevation data ingested from Osmosis.Here are 2 edges that I'm testing with:<edge id="51701500" from="1131054237" to="818174600" priority="15" type="railway.rail" spreadType="center" shape="6991.53,1494.68,25.96 7064.88,1733.39,15.10 7068.32,1744.57,14.77 7074.47,1759.23,14.47 7081.38,1777.38,14.36 7092.50,1802.08,14.24"><lane id="51701500_0" index="0" allow="rail rail_electric" speed="83.33" length="301.68" shape="6991.53,1494.68,25.96 7064.88,1733.39,16.92 7068.32,1744.57,16.50 7074.47,1759.23,15.60 7081.38,1777.38,14.50 7083.31,1781.67,14.24"/></edge><edge id="-51701500" from="818174600" to="1131054237" priority="15" type="railway.rail" spreadType="center" shape="7092.50,1802.08,14.24 7081.38,1777.38,14.36 7074.47,1759.23,14.47 7068.32,1744.57,14.77 7064.88,1733.39,15.10 6991.53,1494.68,25.96"><lane id="-51701500_0" index="0" allow="rail rail_electric" speed="83.33" length="301.67" shape="7083.31,1781.67,14.24 7081.38,1777.38,14.42 7074.47,1759.23,15.18 7068.32,1744.57,15.79 7064.88,1733.39,16.25 6991.53,1494.68,25.96"/></edge>The shape definitions from the original edges match perfectly. But when it adds the lanes to the edges, the numbers vary a little. Those variations are enough to throw off the comparison between the 2 lanes' shapes. I'm not sure how lanes get produced from edges, so I don't know why the points don't match up exactly or why they vary between the 2 lanes since they're both based on edge shapes that are identical. Rounding errors maybe?Seems like this whole comparison could be avoided if we just checked the IDs of the edges to see if they're inverses of each other. -51701500 is the negative lane of 51701500, couldn't we always consider them to be "superposable"? That assumption may be too simplistic for regular roads, but for railways maybe it's ok?Thanks for your assistance!Date: Wed, 12 Dec 2018 18:18:01 +0100
From: Jakob Erdmann <namdre.sumo@xxxxxxxxx>
To: Sumo project User discussions <sumo-user@xxxxxxxxxxx>
Subject: Re: [sumo-user] Rail vehicles turning around on a
bi-directional edge
Message-ID:
<CAMbUcbyquTGS7McHmFzRUaro8+Z=KfGz94gxnXTdqvez=HjRrQ@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
Did you let the train stop before reaching the end of the edge (e.g. with a
<stop> definition)?
You can find an example at
https://github.com/eclipse/sumo/tree/master/tests/sumo/extended/rail/reverse_at_stop
If you added a stop and it still does not work, send me your input files so
I can look for a bug.
regards,
Jakob
Am Mi., 12. Dez. 2018 um 17:14 Uhr schrieb Linwood Hudson <
vtkougrr@xxxxxxxxx>:
> Thanks for the guidance Jakob. That pages contain a lot of useful
> information. I'm experimenting now with the --railway.topology.repair
> and --railway.topology.all-bidi flags noted there.
>
> In both cases, it appears to successfully convert single edges into
> bi-directional, adding turn-around connections and all the required
> prerequisites noted on the page. But the reversing-direction process still
> takes a long time. The train almost seems to turn itself inside-out in
> order to make a complete U-turn on the edge, at a less-than-0.1 m/s pace. A
> default 5-car train takes nearly 30 minutes to complete a reversal.
>
> Can you clarify what the expected behavior should be in this case? Is this
> slow turn what you would expect to happen, or should the reversing process
> occur faster/instantaneously?
>
> Thank you!
>
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-user
_______________________________________________Thanks for the response Jakob. I did add a stop near the end of the edge, but I still encountered the same turnaround problem.After debugging the code, I think I see what's going on. The MSVehicle::canReverse() method relies on the myBidiEdge member of MSEdge. This property gets set based on a call to MSEdge::isSuperposable, which among it's check compares the shape vertex points of the 2 lanes to see if they're equal. This logic seems to work ok if the 2 edges being compared are perfectly straight, but if the edge has curves then the vertex points of the 2 lanes don't always match up 100%.I'm using Union Station in Washington DC as my sample data. It isn't setup to use bi-directional lanes, so I applied the "--railway.topology.all-bidi" flag to force it. I'm also using elevation data ingested from Osmosis.Here are 2 edges that I'm testing with:<edge id="51701500" from="1131054237" to="818174600" priority="15" type="railway.rail" spreadType="center" shape="6991.53,1494.68,25.96 7064.88,1733.39,15.10 7068.32,1744.57,14.77 7074.47,1759.23,14.47 7081.38,1777.38,14.36 7092.50,1802.08,14.24"><lane id="51701500_0" index="0" allow="rail rail_electric" speed="83.33" length="301.68" shape="6991.53,1494.68,25.96 7064.88,1733.39,16.92 7068.32,1744.57,16.50 7074.47,1759.23,15.60 7081.38,1777.38,14.50 7083.31,1781.67,14.24"/></edge><edge id="-51701500" from="818174600" to="1131054237" priority="15" type="railway.rail" spreadType="center" shape="7092.50,1802.08,14.24 7081.38,1777.38,14.36 7074.47,1759.23,14.47 7068.32,1744.57,14.77 7064.88,1733.39,15.10 6991.53,1494.68,25.96"><lane id="-51701500_0" index="0" allow="rail rail_electric" speed="83.33" length="301.67" shape="7083.31,1781.67,14.24 7081.38,1777.38,14.42 7074.47,1759.23,15.18 7068.32,1744.57,15.79 7064.88,1733.39,16.25 6991.53,1494.68,25.96"/></edge>The shape definitions from the original edges match perfectly. But when it adds the lanes to the edges, the numbers vary a little. Those variations are enough to throw off the comparison between the 2 lanes' shapes. I'm not sure how lanes get produced from edges, so I don't know why the points don't match up exactly or why they vary between the 2 lanes since they're both based on edge shapes that are identical. Rounding errors maybe?Seems like this whole comparison could be avoided if we just checked the IDs of the edges to see if they're inverses of each other. -51701500 is the negative lane of 51701500, couldn't we always consider them to be "superposable"? That assumption may be too simplistic for regular roads, but for railways maybe it's ok?Thanks for your assistance!Date: Wed, 12 Dec 2018 18:18:01 +0100
From: Jakob Erdmann <namdre.sumo@xxxxxxxxx>
To: Sumo project User discussions <sumo-user@xxxxxxxxxxx>
Subject: Re: [sumo-user] Rail vehicles turning around on a
bi-directional edge
Message-ID:
<CAMbUcbyquTGS7McHmFzRUaro8+Z=KfGz94gxnXTdqvez=HjRrQ@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
Did you let the train stop before reaching the end of the edge (e.g. with a
<stop> definition)?
You can find an example at
https://github.com/eclipse/sumo/tree/master/tests/sumo/extended/rail/reverse_at_stop
If you added a stop and it still does not work, send me your input files so
I can look for a bug.
regards,
Jakob
Am Mi., 12. Dez. 2018 um 17:14 Uhr schrieb Linwood Hudson <
vtkougrr@xxxxxxxxx>:
> Thanks for the guidance Jakob. That pages contain a lot of useful
> information. I'm experimenting now with the --railway.topology.repair
> and --railway.topology.all-bidi flags noted there.
>
> In both cases, it appears to successfully convert single edges into
> bi-directional, adding turn-around connections and all the required
> prerequisites noted on the page. But the reversing-direction process still
> takes a long time. The train almost seems to turn itself inside-out in
> order to make a complete U-turn on the edge, at a less-than-0.1 m/s pace. A
> default 5-car train takes nearly 30 minutes to complete a reversal.
>
> Can you clarify what the expected behavior should be in this case? Is this
> slow turn what you would expect to happen, or should the reversing process
> occur faster/instantaneously?
>
> Thank you!
>
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-user