Are roundabout correctly parsed?

[MarHoff]

After using osm2pgrouting to parse data I've noticed that ways which are part of roundabout are incorrectly considered as two-way.

As stated in OSM wiki for the tag:junction=roundabout

• The OSM ways of the roundabout itself must be drawn in the direction the traffic flows.
• Tag the OSM way(s) of the roundabout with junction=roundabout.
• oneway=yes is implied. Though it is not wrong to add it explicitly, it is not needed.

Unless I did some miss-configuration it look like all ways that are part of roundabout can lead to wrong calculations later on with pgrouting as roundabout awareness is lost in resulting network (when using mapconfig_for_cars.xml).

Even if resulting error is minimal in term of travel time/distance, when mapping result the result look pretty bad and can inspire doubt to the whole calculation method as viewers can pretty easily spot wrong paths in roundabouts.

[cvvergara]

hello,
didn't know that.
I'll see to it, I dont know how to consider it, a bug or feature request. but its labeled

[MarHoff]

Hi!

Here is an illustration of pgr_dijkstra() results based on my dataset over mapnik (we drive right).

As you will notice both paths respects one way restrictions. Access ramp to the roundabout are unaffected as well (marked as one way in the ways table).

But the red path is taking an ugly and illegal shortcut as ways of the roundabout are set to : one_way=0 and reverse_cost=cost

Can you reproduce on another OSM dataset? I guess it might be hard to spot because this heavily depend on queried route and roundabout shape itself.

[cvvergara]

hmm... I must say that I am not a visual person, I am a data person ;)
can you give me the BBOX of the area shown so I can download that ultra petit area (can be a bit larger) so I can down load like this:

CITY="PETIT_AREA"
BBOX="7.097,50.6999,7.1778,50.7721"  #(s,w,n,e)
wget --progress=dot:mega -O "$CITY.osm" "http://www.overpass-api.de/api/xapi?*[bbox=${BBOX}][@meta]"

On the meantime, look for the rows of the roundabout on your edge table, and put a negative number in (cost or reverse_cost) and (cost_s or reverse_cost_s)

[dkastl]

oneway=yes is implied. Though it is not wrong to add it explicitly, it is not needed.

This was new to me. I assumed that by having oneway set on roundabouts there shouldn't be a problem. But as you reference the OSM wiki, my assumption seems to be wrong.

I'm wondering if this doesn't cause problems, as we then need to know if the traffic is left-sided or right-sided to apply the costs accordingly.

[MarHoff]

@cvvergara I confirm that with my implementation updating this roundabout edges so that reverse_cost=-cost solve the issue. Green path is unaffected while red path now avoid illegal turn.

This should be the correct extent for the view (WGS84) but I fear that the problem is pretty widely widespread. I've spotted multiple occurrences in my working area.

    <xmin>7.23983975890579</xmin>
    <ymin>47.8682489475</ymin>
    <xmax>7.25417104109422</xmax>
    <ymax>47.8814727525</ymax>

@dkastl Luckily the OSM wiki also state that "The OSM ways of the roundabout itself must be drawn in the direction the traffic flows." so we should be ok by simply setting one_way=1 for roundabout.
If a contributor didn't respect the traffic way orientation as specified in the wiki, then this become an OSM issue resolved by updating the OSM database.

[cvvergara]

thanks,
I tried it with the developing that I have and as far as can see it had no problems.
I just merged my developing work for v2.3 into develop branch.

Please, can you give it a try, and verify these are correct?
https://github.com/pgRouting/osm2pgrouting/blob/develop/src/osm_elements/Way.cpp#L161
https://github.com/pgRouting/osm2pgrouting/blob/develop/src/osm_elements/Way.cpp#L191

[cvvergara]

This is the merge information
#168

[cvvergara]

@MarHoff
maybe I used the wrong query. something is wrong

[cvvergara]

(the something is wrong is with the code)

[cvvergara]

I think I fixed it with #170 with this commit 4567733

can you see if the problem of the junction gets fixed?

• use develop branch
• use a different database and compare with the output you get currently with the hand made fix
• also compare other queries if possible, just to verify that other things work well

thanks

[MarHoff]

I'm sorry I wont be able to test on the real server until Monday...
I don't have (maybe for the best) remote access to the database on which I noticed the bug :/

[cvvergara]

@MarHoff
don't worry, a lot of work is still pending on v2.3

[MarHoff]

Houston we got a problem this is what showed up after loading the my OSM dataset under develop branch:

This is the way table under 2.2.

I guess this mess come from the fact that I use a custom Dataset generated by http://overpass-api.de/ as I work near an international border and country extract are not relevant for me. Will try figure this mess out and double check. I'll post another issue if needed...