OpenDRIVE: problems when importing a network for left-hand traffic

[michael-mi]

When trying to convert Town04.xodr map using left hand traffic, an invalid map is generated. Screenshot of RHT map:

Same junction using LHT:

As can be seen from the screenshot, the direction of connecting road is not changed according to traffic direction and we get a road connecting to opposite direction.

I'm using the following options of netconvert: --output.original-names true --opendrive.import-all-lanes true --precision 8 --lefthand true

[behrisch]

Are you referring to this file: https://github.com/carla-simulator/opendrive-test-files/blob/master/OpenDrive/Town04.xodr ?

[michael-mi]

Are you referring to this file: https://github.com/carla-simulator/opendrive-test-files/blob/master/OpenDrive/Town04.xodr ?

Yes

[behrisch]

netconvert is not meant to convert an arbitrary RHT network into a LHT network. The network should originate from data of a real left hand driving region. I am not sure whether this is the case here.

[ohadsch]

How can an ODR 1.4 map file represent a real left hand driving region? what is its expected structure?

As I understand it, since ODR 1.4 does not define driving direction, the "right" way to parse the map is as follows:

• Assume the loaded map represents RHT.
• On default configuration, assume the traffic direction on right lanes follow the direction of the ODR road, and the traffic direction on the left lanes is opposite to the ODR road direction
• when --lefthand is used, reverse the directions in the above rule

[behrisch]

Problems arise with one way streets as in your example. You probably would expect them to be reverted but there is no general rule to follow whether a one way street should be reverted.

[ohadsch]

I agree, this is why I suggested the heuristic above. Without some kind of heuristic there is no way to convert ODR file properly using the "--lefthand" option.

[namdre]

The problem arises because the lefthand logic of netconvert is tailored for osm-style networks that define a forward direction for all edges and this direction will correctly indicate driving direction in one-way lefthand roads. Put in another way: OSM defines forward/backward rather than right/left.

What netconvert does in ODR import right now is to assume that the right-hand lanes always correspond to the forward direction and then it moves geometries to the other side of center-line geometry when using the lefthand option. I think this needs to be changed.

I don't even think this is a question of heuristics. In a lefthand network, left means forward and right means backward. The above statement corresponds to Michaels point that a lefthand network is encoded differently from a right hand network. When trying to re-interpret a right-hand network as lefthand, some sort of heuristic is indeed needed.