USSPegasus / monav

Automatically exported from code.google.com/p/monav
0 stars 0 forks source link

Router misuses entry and exits to roundabouts #1

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Find a suitably complex roundabout for which you have verified the data:
http://nroets.dev.openstreetmap.org/demo3/index.html?lat=51.075352&lon=-4.065188
&zoom=18&layers=B000FTFTT

or 
http://www.openstreetmap.org/?lat=52.3828567564487&lon=-1.56514137983322&zoom=18

And route around them.

It seems to go round the roundabout by going out the exit, u-turning and then 
going back onto the roundabout.

Original issue reported on code.google.com by steve_t...@evolvedlight.co.uk on 3 Aug 2010 at 12:08

GoogleCodeExporter commented 8 years ago
The current implementation defaults the speed in roundabouts to 10km/h. This 
causes to the observed behavior as routing along the connected street is much 
faster.

I'll probably remove the speed limit of 10km/h, in which case the maxspeed tag 
or the highway type determine the speed. 

Original comment by veaac.fd...@gmail.com on 3 Aug 2010 at 11:44

GoogleCodeExporter commented 8 years ago
Should be fixed in r169
I uploaded an updated UK data set [http://www.megaupload.com/?d=R48WYONF Link]. 
The other data sets should be updated soon.

Original comment by veaac.fd...@gmail.com on 3 Aug 2010 at 1:11

GoogleCodeExporter commented 8 years ago
I know it would add some time to the preprocessing stage, but would there be 
better methods to fix this?

For example, you could look at the length of the road, and give a time value 
for the edge accordingly - for example you could assume that the car cannot 
immediately hit the max speed for the road and so say for the first 10m of a 
road, they would go at 10km/h, then for the next 20m 20km/h. Basically 
penalising small roads. 

You could even look at the angle of the turn, and the maxspeed/new expected 
speed of the road that was previous to the new edge and work out a slowdown 
factor for the turn, and be able to calculate an "initial speed" for the new 
edge to work out a more accurate expected speed. But that could get tricky :(

Thanks for the quick update anyway :)

Original comment by steve_t...@evolvedlight.co.uk on 3 Aug 2010 at 1:22

GoogleCodeExporter commented 8 years ago
I gotta admit that your update does actually work pretty well, so perhaps my 
suggestions are not needed at all.

Original comment by steve_t...@evolvedlight.co.uk on 3 Aug 2010 at 1:26

GoogleCodeExporter commented 8 years ago
The routing algorithm, while achieving excellent query times, does not consider 
turning restrictions and penalties at the moment. I am planning to add this 
feature in the near future, though, as I've already got some ideas on 
integrating it.

When this feature is available the importer plugin will most likely penalize 
turns depending on their angle and direction. That would some more obscure 
situations where the routing algorithm prefers U-turns.

Original comment by veaac.fd...@gmail.com on 3 Aug 2010 at 1:31