Complete chapter Road network structure (7.3.5)

[LudwigFriedmann]

Is your feature request related to a problem? Please describe.
(TBD) Currently, the chapter and its subchapters are lacking text and illustrations. https://publications.pages.asam.net/standards/ASAM_OpenDRIVE/ASAM_OpenDRIVE_Specification/latest/specification/06_general_architecture/06_05_overview_elements.html and the Miro board can serve as sources of information.

Describe the solution you'd like
Text and illustrations are added to the chapter.

Describe alternatives you've considered

Additional context

[ClemensLinnhoff]

We need to have another discussion about this topic. We briefly discussed it and splitting 3D geometry into lanes might not make much sense.
@LudwigFriedmann what do you think? Let's discuss in the next meeting.

[LudwigFriedmann]

Having lane-specific nodes and meshes enables the idenfification and editing of individual lanes, their geometry, boundaries and lane-markings in 3D modeling tools.

[ClemensLinnhoff]

We were thinking about the upcoming ASAM concept project to link OpenDRIVE to CityGML following an area definition instead of a lane definition. Then you might still have lane markings, but not individual lanes in the geometry.

[LudwigFriedmann]

1. The structure needs some fixes:

• Lanesegment_idx should be added to lanes to clearly indicate to which lanesegment they belong
• Children of junctions should not be connections, but lanes and lanemarkings underneath

2. Do we want to have lane-specific information from OpenDRIVE in our 3D geometry?
   Consideration of individual lanes as individual nodes/meshes is useful for validation of the geometry of lanes and roadmarkings. OpenDRIVE indices create direct references to the OpenDRIVE file. This is useful for the validation of opendrive networks, but may not be relevant for rendering or sensor simulation use-cases.

With regards to the different use-cases, there are multiple options to model road networks as 3D geometry

1. Have individual nodes/meshes for lanes
2. Have one node/mesh per road
3. Add extra information, like curves, to represent lanes while using a common node/mesh for the road (and not separate ones for the lanes)

Current Proposal

• Rename the chapter to "Environment"
• Apply the following node structure:

Root (T)
|-- Terrain
|-- Objects
----|--Buildings
----|--Vegetation
|-- Road_Network
----|--Driving_Area
----|--Sidewalks
----|--Road_Marks
----|--Road_Object_<object_idx> (T)
----|--Signal_<signal_idx> (T)
-------|--Sign_<sign_idx> (T)
-------|--Bulb_<bulb_idx> (T)

Definitions

• Terrain: Ground, landscape (not including vegetation and building)
• Road_Network: Drivable area (comparable to scope of OpenDRIVE for on-road use-cases), including lanes, signs and related objects (which are separate nodes)
• Objects: Vegetation, Buildings, etc. (arbitrary sub-nodes or separate assets)

[ipg-sig]

Personal Opinion:

With regards to the different use-cases, there are multiple options to model road networks as 3D geometry

    Have individual nodes/meshes for lanes
    Have one node/mesh per road
    Add extra information, like curves, to represent lanes while using a common node/mesh for the road (and not separate ones for the lanes)

I would favor the combination of option 2 & 3:
Have one mesh per road and curves (NURBS) as children for the different lanes. This would allow us to optimize the mesh for realtime rendering and also be able to edit the lanes in the 3D application (would allow to convert it in both ways and to edit in 3D and in the corresponding software, some additional meta data for the width could be needed in this case). Also the curves would allow an 3D artist to easily replace the sidewalks or place assets along the already generated curves inside the 3D application. This comes in handy on construction sides, etc.

Also I would like to propose the following naming and structure:
"Others" - Group Node for objects, which aren´t categorized yet
"Signal" - Group Node, contains all traffic lights and signs
"Sign" - Group Node, contains all traffic signs
"Traffic_Light" - Group Node, contains all traffic lights (count from left to right, top to down)
"Light" - Group Node, contains all light sources (emits light and casts shadows)
"Cover" - Group Node, contains the outer cover of the traffic light

"Signal" is a little bit to generic in my opinion. It is not clear on the first look if all signals are meant, or traffic lights, or traffic signs.
Therefore I would like to have a "Sign" and a "Traffic_Light" group. Makes it easier to identifiy, which is what. To stay consistent with the vehicle naming conventions, I also would also like to rename "Bulb" to "Light".

Example structure:
Root (T)
|-- Terrain
|-- Objects
----|--Buildings
----|--Vegetation
----|--Others
|-- Road_Network
----|--Driving_Area
----|--Sidewalks
----|--Road_Marks
----|--Road_Object_<object_idx> (T)
----|--Signal_<signal_idx> (T)
-------|--Sign_<sign_idx> (T)
-------|--Traffic_Light_<traffic_light_idx> (T)
---------|--Cover_<case_idx> (T)
---------|--Light_<bulb_idx> (T)

I don´t know for sure if we are binded by the names by the other standards, but I wanted to take it as a disscusion point to the group.