Currently, the output CityGML files are missing some successor and predecessor connections. As for the car lanes, the successor and predecessor connections seem to be working fine. However, the lane types SIDEWALK and BIKING suffer from some unset successor and predecessor connections which leads to fragmented networks of those lane types. This is especially significant in intersection areas where many TrafficArea and TrafficSpace objects exist to model the curved street. This can be seen in the following image, showing the TrafficAreas and their TrafficSpace (red) elements.

There might be a way to set the right connections during the converting process. Otherwise, generating the missing connections using only the CityGML data is a tedious task.

The following TrafficSpace element (highlighted in green) is close to multiple CityFurniture elments. However, instead of having a link to the different CityFurniture elements it has several links to the same CityFurniture element with variables changing the corresponding lanes. I guess it should be the other way around that the CityFurniture object is connected to the different lanes present near the object.

The lane id for the selected TrafficSpace element is -4. The section id is constant for all referenced elements at 5.

The following screenshot shows the CityFurniture object that is referenced multiple times.

It contains links to multiple different TrafficSpace and AuxiliaryTrafficSpace objects.

This example is found in the Grafing dataset near the main square in the east. However, it is not the only occurrence of this issue.

RTron version: 1.3.0

If the "height" attribute is not generated for an object, the following warning is added to the 02_opendrive_evaluator_report.json report file:

{
    "type": "",
    "info": "Road object contains a polyhedron with non-zero height, but the height of the road object element is Option.None.",
    "location": "Road object: roadObjectId=2, roadId=8",
    "incidentSeverity": "WARNING",
    "wasFixed": false,
    "infoValues": {
    },
    "messageSeverity": "WARNING"
}

This warning indicates that the "height" attribute was not indicated. However, according to the OpenDRIVE schema, this attribute is optional. Because of this, we believe that this message should be of level "INFO" rather than "WARNING".

GenericObjects 'LaneCenterLine' should contain a citygml_function attribute (e.g. DRIVING, SIDEWALK, etc.). Using lod0Network geometries these lines could be written as 'Road' objects. (Lane centerlines would also correspond to linear representations of CityGML3.0 TrafficSpaces in granularity = 'lane')

RTron version: 1.3.0

When validating an OpenDRIVE file with several "spiral" geometry definitions, several warnings and errors are raised. These errors are saved to the 02_opendrive_evaluator_report.json file, and are of type GapBetweenPlanViewGeometryElements. Here is an example of such an error:

{
    "type": "GapBetweenPlanViewGeometryElements",
    "info": "Geometry elements contain a gap from Vector2D(x=64.29300909560088, y=197.04569937574584) to Vector2D(x=64.28923043599997, y=197.03699148) with an euclidean distance of 0.00949240310457702 above the warning tolerance of 0.001.",
    "location": "Road: roadId=1",
    "incidentSeverity": "WARNING",
    "wasFixed": false,
    "infoValues": {
    },
    "messageSeverity": "WARNING"
}

These errors indicate that between two consecutive spirals of a single road, a gap of the indicated length exists. When visualizing the OpenDRIVE file in question with other tools (such as odrviewer.io), however, no such gap exists.

It is possible that the values along spirals are not correctly computed, and therefore the resulting gaps are incorrectly detected.

It would be interesting to have information if roads are part of bridges / tunnels.

Issue

Currently, there is no connection between the street sign or other CityFurniture which are important for one specific section of the road. This includes but is not limited to speed limits and restrictions for certain lanes.

Task

Map information, such as traffic sign information (speed limits, etc.) with respect to the corresponding street segment.

Solution Idea

Use the linear referencing in OpenDRIVE and add a generic attribute to the corresponding CityGML street objects using generic attributes or a link to the corresponding CityFurniture object.

Also transform object markings (11.6 of OpenDRIVE 1.7.0)

The CityGML linking of predecessor and successor elements is currently confusing, as it is dependent on the direction of the respective reference line used in OpenDRIVE. A correct linking regarding the driving direction should be considered.

An OpenDRIVE road should be mapped to CityGML Road with (TrafficAreas, AuxilaryTrafficAreas) and an OpenDRIVE junction should be mapped to a CityGML Road (function=Intersection) (intermediate solution until CityGML3, see: examples)

Auxilary Traffic Areas: Border, trafficIsland, raisedMedian, Shoulder, Median, None, Road_Works

There are gaps between the transitions of two lane section when the lane height offset changes:

To close such gaps, the information on the lane's successor and predecessor have to be known.

OpenDRIVE datasets usually contain road markings with color and rule information (see: p.98ff. of OpenDRIVE v.1.6.).
Thus, these should also be transformed towards CityGML.

Add capability of transforming outlines of OpenDRIVE road objects which have mixed height entries (height=0 and height!=0).

The href attributes should have a prefix # in their value.

Example:

• Currently:

  <tran:successor xlink:href="id1"/>
  <tran:predecessor xlink:href="id2"/>

• Should be:

  <tran:successor xlink:href="#id1"/>
  <tran:predecessor xlink:href="#id2"/>

Issue/Current Status

Within the dataset, some bidirectional elements are not modelled using the trafficDirection "both". They are modelled using the trafficDirection value "forward" and include two successor and two predecessor links. In combination with the trafficDirection a singular successor and predecessor element should be sufficient.

Proposed Solution

Change the attribute value for bidirectional OpenDRIVE segments to trafficDirection "both" and include only one set of successor and predecessor relationships of the lane with "priority".

Current State

At the moment, traffic sign CityFurniture elements are connected to the nearest TrafficSpace. However, depending on the chosen size and number of the modelled TrafficSpaces, the rules of a single traffic sign might apply to more than the nearest TrafficSpace.

Future State

Each TrafficSpace affected by the rules of a traffic sign should be connected to this CityFurniture element to allow the retrieval of the semantic information. Thus, different regulations for neighbouring lanes can be realized, and semantic information is also available in consecutive TrafficSpaces.

Requested Changes

Check which TrafficSpaces are affected by the presence of a traffic sign, e.g., a speed limit is valid until another sign changes the value. Add a link to this traffic sign (CityFurniture object) for all affected TrafficSpaces.

Current situation

The screenshot shows a narrow part of a road in the Grafing dataset. Here, two lanes in different directions have to share the road in a single element for a short distance due to a bottleneck. The lane on top is connected correctly as its the primary connection path in this example. However, the lane on the bottom gets narrower and narrower closer to the bidirectional segment. This leads to a dead end with no connection between the two ends of the lower lane.

Proposed solution

As can be seen in the added red connections additional predecessor and successor connections to the bidirectional elements would be sufficient to remove the dead ends. Additionally, it might be necessary to set additional predecessor and successor connections in the opposite direction, as a bidirectional element can be traversed in both directions.

RTron version: 1.3.0

When validating OpenDRIVE files with some specific junction topologies, a warning is raised stating that such junction is not needed, as that junction only has two incoming roads. Here is an example of such an error:

{
    "type": "",
    "info": "Junctions of type default should only be used when at least three roads are coming in (currently incoming road ids: [9, 12])",
    "location": "Junction: junctionId=0",
    "incidentSeverity": "WARNING",
    "wasFixed": false,
    "infoValues": {
    },
    "messageSeverity": "WARNING"
},

The junction in question is the following (road IDs are indicated in red):

The OpenDRIVE standard states that:

"Junctions should not be used when only two roads meet." ("Rules" section of OpenDRIVE 1.7, chapter 10.1)

From our understanding, this means that if a junction is only used to connect two roads, then the junction is not needed. In the case shown above, however, three roads are meeting at the junction: road 8, 9 and 12. The standard also states that:

"Junctions shall only be used when roads cannot be linked directly. They clarify ambiguities for the linking. Ambiguities are caused when a road has two or more possible predecessor or successor roads." ("Rules" section of OpenDRIVE 1.7, chapter 10.1)

In this case, the successor of road 8 is ambiguous, as both roads 10 and 11 are valid successors. As stated by the standard, to clarify this ambiguity a junction is needed.

The error indicated by rtron is therefore incorrect, but there are still situations in which a junction could be unnecessary. We tried to better understand how to identify not needed junctions, and the algorithm we came up with is:

for each connecting road of the junction, store the ID of the road before (predecessor) and after (successor) the connecting road.
If any road was stored more than once, the junction is necessary (solves an ambiguity of that road).
If no road was stored more than once, no ambiguity is present, and therefore the junction could be replaced with 1 to N roads (the connecting roads of the junction itself).

Here are some examples showing situations with ambiguities and without ambiguities. The algorithm described above would correctly identify these situations:

We believe that the algorithm described above covers all cases, but if a counter-example is found please feel free to reply describing that situation.

How to change the input version of opendrive to any specific version available.
Also, is it possible to output a corrected odr-file in the same version as input along with or instead of 1.7?
If not, what changes should have to be done to fulfill these requirements.

Polygon-based cutouts

roadspaces_to_citygml reports contain recursive texts that are difficult to interpret.

Information on markings is currently not transported into the CityGML version 2.0 export. Markings could/should be included as "AuxiliaryTrafficAreas" in CityGML v 2.0.

class
function
Usage
SurfaceMaterial

When working with CityGML and 3DCityDB simoultaneously it is helpful to have correspondent gml_ids.

The offset values set in the OpenDRIVE header should be considered when transforming to CityGML.

Issue description

I noticed that within the generated CityGML file some TrafficSpace objects do not have an individual UUID. All of those occurrences seem to be related to the usage as a container for TrafficArea objects such as crosswalks.

For generating complete pedestrian networks it could be beneficial to connect the two sides of the road via the crossWalk element by adding a usable TrafficSpace object and connecting it with predecessor and successor links to the SIDEWALK TrafficSpace objects next to the crosswalk.

The image shows a scene in which such a crosswalk is present in the output CityGML file. It has limited semantic information, compared to the other TrafficAreas of the road. Thus, it is just connected to the road via the generic attributes.

Code example

The following code shows the output CityGML data with the TrafficSpace elements missing a unique identifier (UUID).

<tran:trafficSpace>
    <tran:TrafficSpace>
        <boundary>
            <tran:TrafficArea gml:id="UUID_4b3f2da5-6f01-3393-aa26-58afc3faa71c">
                <gml:name>crossWalk</gml:name>
                    <genericAttribute>
                        <gen:StringAttribute>
                            <gen:name>identifier_roadObjectId</gen:name>
                            <gen:value>4030022</gen:value>
                       </gen:StringAttribute>
                    </genericAttribute>
                      ...
            </tran:TrafficArea>
        </boundary>
        <tran:granularity>lane</tran:granularity>
    </tran:TrafficSpace>
</tran:trafficSpace>

OpenDRIVE road objects allows defining a bounding box as an angular object (width, length, and height attributes) or a circular object (radius and height attributes). These can be 3D but also 2D, depending on the attribute values.
More detailed geometries can be defined with the repeating objects and outlines concepts.

Thus, it would be beneficial if the transformation to CityGML supported multiple geometry LoDs.
This could, for example, help to identify inconsistencies between the bounding box and more detailed geometry, as mentioned here.

Add a more detailed description and explanation of the parameters of the configuration files.

trafficIslands and raisedMedians should be classified as AuxilaryTrafficAreas

OpenDRIVE allows defining an optional width and height attribute for road signals (used for traffic signs & traffic lights).
Currently, the CityGML objects derived from this are only represented by point geometries, although an areal geometry representation would be beneficial.