Diario de trabajo 2020

Corrección de errores

• HDMAPMDK-1215 completado
• HDMAPMDK-1218 Completado

HDMAPMDK-1132 Tracing de ID en los extremos de las líneas de carril de señales verticales

El problema de tracing que enfrentan los extremos de las líneas de carril de señales verticales es mucho más simple en comparación con el tracing de objetos lineales. Solo implica un mapeo de ID, sin mapeo de offset ni de longitud.

Sin embargo, también hay que considerar varios aspectos:

1. Procedimiento
2. El sistema de tipificación de ID es un problema persistente y es necesario encontrar una forma de abordarlo.

En esencia, la raíz del problema radica en que al definir los ID utilizamos todos Long ID, mientras que en la definición de MDM se emplean Int, lo que puede provocar problemas de desbordamiento.

Bugfix: HDMAPMDK-1211 Solución encontrada

• La causa raíz es que la segmentación de la línea de producción no es razonable.

Análisis de la causa

Se puede ver que cuando el cambio de carril aún no ha finalizado (la línea central del carril está cruzando la línea de carril), ya se ha realizado la segmentación, y esta segmentación puede cruzar el Rp.

Dado que la información de observación de los bordes de carril (lane border) adjunta a los puntos de forma de la línea central del carril (lanecenter) registra fielmente las líneas de carril a ambos lados mediante el método de línea de exploración (scan line), según la geometría, sin filtrar según la semántica. Por lo tanto, en la posición donde la línea de carril cruza el carril, la línea central del carril que intersecta la línea de carril registrará esta línea de carril en ambas referencias de borde de carril izquierdo y derecho.

Bajo la lógica de código existente, al filtrar la referencia de borde de carril de la línea de carril intersectante según la semántica, se infiere la referencia de borde de carril que se debe eliminar según el tipo de cambio de carril.

La lógica actual falla cuando se encuentra con este tipo de segmentación, lo que provoca este problema.

Solución

El punto central es encontrar la tendencia de cambio de carril de la línea de carril intersectante. Teniendo en cuenta que este tipo de segmentación puede cruzar Rp, el filtrado no debe realizarse por unidades de Rp.

1. Primero, organizar las líneas de carril en un path usando edge lifting (se puede considerar para la futura reconstrucción del grafo): Seq[LaneCenter]
2. Encontrar el LaneCenter a corregir y el lane border a corregir (aquí se asume que este tipo de LaneCenter es causado por un cambio de carril)
3. Calcular la tendencia de cambio de carril de ese LaneCenter según el laneCenter path
4. Realizar el filtrado

Se lo asigné a Ziliang.

Una persona entrevistada no pasó.

• Entrevistas: ambos candidatos no cumplían los requisitos. Reflexionar sobre cómo identificar rápidamente candidatos, tomó 3 horas.
• bugfix: HDMAPMDK-1211 Problema de border incorrecto al eliminar, no se solucionó correctamente en la reparación anterior. Tengo una idea pero no la he terminado de escribir.
• Fui al gimnasio.

• HDMAPMDK-1122 El problema de falta de líneas de borde de carretera no se reprodujo; se decide no invertir más tiempo en investigar la causa.
• Media hora de “Teoría del crecimiento metabólico”
• Refactorización de Visitor para que admita líneas con el mismo punto de inicio y fin.
• Preparé una pregunta de entrevista.

Corrección y pruebas de PolyLine

El problema principal de PolyLine radica en la posibilidad de que se introduzcan puntos duplicados durante la generación, lo que provoca una serie de problemas en los cálculos geométricos relacionados con segmentos:

1. Cálculo de vectores: dos puntos duplicados generan un vector nulo.
2. Cálculo de longitud: la longitud del segmento es 0, lo que fácilmente resulta en valores NaN.

Por lo tanto, al construir PolyLine, se verifica cada punto; si se encuentra un punto duplicado, se lanza una excepción.

Se detectaron los siguientes problemas:

• Problema con getEnd en Jts.

• Problema de normalización en LinearLocation de Jts.

  val loc1 = new LinearLocation(0, 1, 1.0)
  val loc2 = new LinearLocation(0, 2, 0.0)
  
  loc1 compareTo loc2
  // the output is -1
  

• Durante la interpolación, puede haber casos en los que se tomen dos puntos demasiado cercanos.

Problema de fuga de memoria

• La causa directa del problema de fuga de memoria es que después de crear un puntero salvaje con new, no se llamó a delete.
• Después de update current position, Map Kit invocó prepareGuidanceData con el objetivo de encontrar los datos de guía más cercanos a la posición actual.
• prepareGuidanceData llamó a NavInfoProviderImpl::getTrafficLights y NavInfoProviderImpl::getCarParks.
• Tomando NavInfoProviderImpl::getTrafficLights como ejemplo, al llamarlo se crea un puntero a los datos de NaviEventOnPath con new.
• Sin embargo, no se llamó a delete.
• También se descubrió que DestEvent presenta este problema.

Solución: El núcleo es no permitir la existencia de punteros salvajes, por lo que se decide refactorizar NaviEventProvider.

• Primero, agregar dos campos traffic_light_events y car_park_events en NaviInfoProvider.
• En NaviInfoGenerator, actualizar estos dos campos después de que la ruta se actualice (route updated).
• Luego, en cada llamada a get, filtrar según la posición actual del vehículo.
• Por lo tanto, es necesario refactorizar PathReader::getAttributes, ya que la implementación anterior solo consideraba el desplazamiento relativo al vehículo actual. Ahora se necesita una interfaz de desplazamiento relativo a la ruta (Path).

Du Valid

• Usar mill
• Usar nexus-osm

Lluvia de ideas

bugfix

• HDMAPMDK-1143 Problema de que RoadObstacle no compila
• HDMAPMDK-1090

Me tomé medio día para el examen teórico de conducir.

Problema de ancho HDMAPMDK-1130, tres problemas:

1. La especificación estipula que no hay ancho de carril al cambiar de carril.
2. Línea de división causada por una línea de intersección demasiado larga.

Reparación de HDMAPMDK-1121.

Estado muy malo.