Arbeitstagebuch 2020

Fehlerbehebungen

• HDMAPMDK-1215 abgeschlossen
• HDMAPMDK-1218 Erledigt

HDMAPMDK-1132 ID-Tracing der Endpunkte von Fahrbahnmarkierungen an Masten

Das Tracing der Endpunkte von Fahrbahnmarkierungen an Masten ist im Vergleich zum Tracing von linearen Objekten sehr einfach. Es besteht lediglich eine ID-Abbildung, ohne dass eine Abbildung von Offset und Länge erforderlich ist.

Dennoch gibt es einige Punkte zu beachten:

1. Verfahren
2. Das ID-Typisierungssystem ist ein hartnäckiges Problem, für das eine Lösung gefunden werden muss.

Im Kern liegt das Problem darin, dass wir bei der Definition der IDs ausschließlich Long-IDs verwendet haben, während die MDM-Definition Integer verwendet, was zu Überlaufproblemen führen kann.

Fehlerbehebung: HDMAPMDK-1211 – Lösungsidee gefunden

• Die Hauptursache ist die unsachgemäße Segmentierung der Produktionslinie.

Ursachenanalyse

Es ist zu erkennen, dass die Segmentierung bereits erfolgt, bevor der Fahrspurwechsel abgeschlossen ist (die Fahrspurmittelüberquerungskurve überschreitet die Fahrspurmarkierung). Diese Segmentierung kann möglicherweise Rp überschreiten.

Da die Beobachtungsinformationen der Fahrspurgrenzen, die an den Formpunkten der Fahrspurmitte anhaften, geometrisch getreu mittels der Scan-Line-Methode die Fahrspurmarkierungen auf beiden Seiten erfassen, ohne eine semantische Filterung vorzunehmen. An der Stelle, an der die Fahrspurmarkierung die Fahrspur kreuzt, zeichnet die Fahrspurmitte, die die Fahrspurmarkierung kreuzt, diese Fahrspurmarkierung gleichzeitig in den linken und rechten Fahrspurgrenzreferenzen auf.

Im bestehenden Codelogik wird bei der semantischen Filterung der Grenzreferenzen kreuzender Fahrspurmarkierungen anhand des Fahrspurwechseltyps die zu entfernende Grenzreferenz abgeleitet.

Die aktuelle Logik versagt jedoch bei dieser Art von Segmentierung, was zu diesem Problem führt.

Lösung

Der Kernpunkt liegt darin, den Wechseltrend der kreuzenden Fahrspurmarkierung zu finden. Da diese Art von Segmentierung Rp überschreiten kann, sollte die Filterung nicht auf Rp-Ebene erfolgen.

1. Organisieren Sie die Fahrspurmarkierungen mithilfe von Edge-Lifting zu einem Pfad (zur späteren Graph-Rekonstruktion): Seq[LaneCenter]
2. Finden Sie die zu korrigierenden Lane-Centers und die zu korrigierenden Lane-Borders (hier wird angenommen, dass solche Lane-Centers durch einen Fahrspurwechsel verursacht werden).
3. Berechnen Sie den Wechseltrend des Lane-Centers basierend auf dem Lane-Center-Pfad.
4. Führen Sie die Filterung durch.

Wurde an Ziliang übergeben.

Ein Interviewkandidat wurde abgelehnt.

• Vorstellungsgespräch: Beide Kandidaten waren nicht qualifiziert. Überlegung, wie man Kandidaten schnell identifizieren kann, dauerte 3 Stunden.
• Bugfix: HDMAPMDK-1211 Problem mit falsch gelöschtem Border – beim letzten Fix nicht erfolgreich behoben. Habe eine Idee, aber noch nicht fertig geschrieben.
• War im Fitnessstudio.

• HDMAPMDK-1122 Das Problem des fehlenden Straßenrandstreifens konnte nicht reproduziert werden. Es wurde beschlossen, keine Zeit mehr für die Ursachenforschung aufzuwenden.
• Metabolische Wachstumstheorie: eine halbe Stunde
• Visitor-Umstrukturierung, die es ermöglicht, Linien mit gleichem Start- und Endpunkt zu unterstützen.
• Vorbereitung einer Interviewfrage.

PolyLine-Reparatur und -Test

Die Hauptprobleme von PolyLine liegen darin, dass möglicherweise doppelte Punkte beim Erstellen der PolyLine hinzugefügt werden, was zu einer Reihe von geometrischen Berechnungsproblemen im Zusammenhang mit Segmenten führt:

1. Vektorberechnung: Zwei doppelte Punkte ergeben einen Nullvektor.
2. Längenberechnung: Die Länge eines Segments ist 0, was leicht zu NaN-Problemen führt.

Daher wird beim Konstruieren der PolyLine eine Überprüfung der Punkte in der PolyLine durchgeführt. Falls doppelte Punkte gefunden werden, wird eine Ausnahme ausgelöst.

Es wurden folgende Probleme festgestellt:

• getEnd in Jts funktioniert nicht korrekt.

• LinearLocation in Jts hat ein Problem mit der Normalisierung.

  val loc1 = new LinearLocation(0, 1, 1.0)
  val loc2 = new LinearLocation(0, 2, 0.0)
  
  loc1 compareTo loc2
  // Das Ergebnis ist -1
  

• Beim Interpolieren kann es vorkommen, dass zwei zu nahe Punkte ausgewählt werden.

Speicherleck-Problem

• Die direkte Ursache des Speicherlecks ist, dass nach dem new eines wilden Zeigers kein delete erfolgt.
• Nach dem Aktualisieren der aktuellen Position ruft das Map Kit prepareGuidanceData auf, um die nächstgelegenen Guidance-Daten zur aktuellen Position zu finden.
• prepareGuidanceData ruft NavInfoProviderImpl::getTrafficLights und NavInfoProviderImpl::getCarParks auf.
• Am Beispiel von NavInfoProviderImpl::getTrafficLights: Beim Aufruf wird ein Datenzeiger aus NaviEventOnPath mit new erstellt.
• Es erfolgt jedoch kein delete.
• Zudem wurde festgestellt, dass das Problem auch bei DestEvent auftritt.

Lösungsansatz: Der Kern liegt darin, keine wilden Zeiger zuzulassen. Daher wird eine Umstrukturierung von NaviEventProvider beschlossen.

• Zunächst werden zwei Felder traffic_light_events und car_park_events in NaviInfoProvider hinzugefügt.
• In NaviInfoGenerator werden diese beiden Felder nach einer Routenaktualisierung aktualisiert.
• Beim späteren Zugriff (get) wird dann eine Filterung basierend auf der aktuellen Fahrzeugposition vorgenommen.
• Daher muss PathReader::getAttributes umstrukturiert werden, da die bisherige Implementierung nur den Offset relativ zum aktuellen Fahrzeug berücksichtigt. Nun wird eine Schnittstelle für einen Offset relativ zum Pfad benötigt.

Du Valid

• mill verwenden
• nexus-osm verwenden

Brain Strom

Fehlerbehebung

• HDMAPMDK-1143 Problem, dass RoadObstacle nicht kompiliert wurde
• HDMAPMDK-1090 Unterstützung für die Verbindung von Endcaps (einschließlich z.B.) hinzugefügt

Die theoretische Fahrprüfung (Teil 1) dauerte einen halben Tag.

HDMAPMDK-1130 Breitenproblem, drei Probleme:

1. Der Spezifikation zufolge gibt es beim Spurwechsel keine Fahrbahnbreite.
2. Die zu lange intersecion-Linie führt zu einer Split-Line.

HDMAPMDK-1121 erneut repariert.

Zustand: sehr schlecht.