Open clemenshabedank opened 3 years ago
Nr.1 Diverging Lane How is this represented in OSI? If possible, maybe just an adaption/clarification in documentation is necessary.
Nr.2 Modeling Tunnels In OpenDrive a simple attribute of the road In OSI unclear: Three Objects (2x Wall, 1x Overhead Structure)? Similar for Pedestrianbridges and Parking houses
Nr.3 Modeling Objects OpenDrive „soundBarrier“ hat keine direkte Entsprechung in OSI (am ehesten „Wall“) Ebenso „gantry“, „crosswalk“ und „trafficIsland“ Umgekehrt z.B: „curbstone“ oder „construction_site_element“ Mapping von Objekttypen zwischen OpenDrive und OSI unklar. Hier können in jede Richtung (OSI → OpenDrive oder OpenDrive → OSI) Informationen verloren gehen bzw. es müssten neue Informationen „erfunden“ werden wie bei den Spurlinien. Wünschenswert: Gemeinsamer Ansatz möglich? Relevante logische Eigenschaften beschreiben. Details des 3D Modells extern lassen.
Describing a lane that has a line marking and a curbstone next to it. Required Information: Road AND Lane boundary Use Case: Driving behaviour can vary due to different road edges Prio 2, LOD 1 (logic level + dimension and position BBox level sufficient)
Intersections are described as one free space currently. For agent navigation virtual lanes would be useful. Required Information: lanes and overlapping areas regarding intersections Use Case: Agent navigation in typical turning scenarios Prio 1, LOD 1 (current lane describtion level for virtual lanes required, center line required)
Turing lanes classified with assigned type. In order to identify if the current lane fits the route the virtual information would be very useful. Prio 2, LOD 2 (logic information)
Currently pedestrian crossings are represented as road markings not as lane. For the identification of potential conflict areas, the description as (virtual) lane would be crucial. Prio 1, LOD 1 (Current lane describtion sufficient but required for areas like pedestrian crossings)
Use the advantage of agent models compared to automated driving functions-> we have GT and do not need sensors to capture for example lane markings (arrows for turning) but we can built models on map interpreted map informations. (Currently: Map -> decoding -> coding -> decoding)
Einflüsse von Unebenheiten in der Straße (Bsp. Spurrillen, Schlaglöcher, Kopfsteinpflaster,..) auf die Trajektorie können auf Grund der Fehlenden Informationen nicht modelliert werden. Prio 3 (weiter in der Zukunft), Detailgrad LOD 0 (sehr hoch, lokales Mesh des Straßenabschnitts benötigt)
Das Verhalten eines Fahrers kann stark durch die Straßenbegebenheit (statische Unebenheiten, dynamisch: wassersansmmlungen bei Regen,… ) Beeinflusst werden. Um solche Aspekte in der Modellierung zu betrachten, werden detaillierte Infos benötigt. Prio 3 (weiter in der Zukunft), Detailgrad LOD 0 (sehr hoch, lokales Mesh des Straßenabschnitts benötigt)
Zukünftig sollen Agenten ihrer Trajektorie nicht nur wie auf “Schienen” folgen sondern nach der Trajektorien Planung soll ein komplexeres Dynamik Model verwendet werden können. Hierfür ist es Notwendig, dass etwaige Regler Störgrößen der Umgebung erhalten (Wie Straßenanregung, Z-Anregung, …) Prio 2, Detailgrad LOD 0 (sehr hoch, lokales Mesh des Straßenabschnitts benötigt)
Anforderung durch Fahrwerkstests des Ego Fahrzeugs? Straßenanregung benötigt!
Issues from the Harmonization-WG related to this: Centerline for other lane types? #443 => Centerlines are not defined for non-driving lanes and intersections but would be very useful, e.g. for traffic participants.
Add Longitudinal Rotation of Lane Boundaries #436 => The height and width of laneboundaries are not sufficiently defined, since the surface of the road is not described in OSI.
Boundary Points for dashed lines #539 => For dashed lines it is not possible to distinguish between gap and line. The new roadnetwork model should also have a consistent definition for this.
I will suggest some Use-Cases to be considered for the enhancement of the road network model.
As it was discussed in the meeting at Monday (5.7.2021), a Level of Detail (LOD) definition could be used for finding Use-Cases. @rockteresa and I discussed this today. For our Use-Cases we used 3 LOD Layers:
For my Use-Cases however, the LOD description is not valid. Most of them should be usable at all LOD levels and are more general:
This issue shall function as a container to catch painpoints of the current OSI version (v3.3.1) with regard to the road network. It is totally fine to not already have a solution and also the form is very free (e.g. bullet point list). The plan is to brainstorm first, and then later to consolidate and plan features for v4.0 which may also be not backward compatible.