Diario de trabajo 2020

Hoy principalmente se trataron los siguientes asuntos:

Completar la sincronización de mdm proto y mdm spec

1. Junto con Lin Nan, corregí las partes con errores de expresión en el mdm spec de Ruoganchu.
2. Dejamos varios elementos pendientes que Lin Nan y yo no podíamos decidir solos.
3. En la reunión matutina del 2020-04-26, se decidió posponer la modificación de los más problemáticos LaneSplitMerge y Polyline.
4. Completé la modificación del proto.
5. Completé la modificación del nexus.
6. Completé la modificación del mdk.
7. Además, solucioné un problema con los datos de prueba (se reportaban errores de datos constantemente).

Corrección de errores

Cercano al lanzamiento del 430, la cantidad de bugs aumentó drásticamente.

HDMAPMDK-1111 Análisis completado.

• Script de copia automática de casos de prueba
• Exportar recordatorios de Apple

• Completé el enlace POI del carril de objetos y terminé la depuración [4]

Vinculación de POI en carriles opuestos

• Realizar la vinculación de los datos después de multidigitize
• Construir datos de prueba

Reparación de RoadBorder

• Se completó la migración de los casos de prueba.
• Se mejoró Dune y su ReadMe para que pueda generar directamente datos de prueba.
• Hablé con Weiyu, y mirando hacia el futuro, me concentraré en el sistema de compilación.

Vinculación de POI en carriles opuestos

• Realizar binding de los datos después de multidigitize.

Límite de velocidad personalizado

• Guangcong convirtió la entrada en un vector y agregó pruebas.
• Un pequeño problema es que Guangcong no comprende realmente el principio de funcionamiento de los punteros en C++.
• ¿Quizás intentar resolver https://github.com/scalameta/scalafmt/issues/337?
• Hacer que los archivos compartidos por el tío sean anónimos a través de Resillo Sync.

Reparación de RoadBorder

Me di cuenta de que había hecho suposiciones incorrectas. En los registros de rc, la información de lc y rb puede existir con las siguientes condiciones:

1. Solo hay un lc, por lo tanto no se puede asumir que lc tenga al menos dos.
2. Es posible que no exista un rb en un lado, por lo tanto no se puede asumir que rb siempre exista.

Se completó la limitación de velocidad.

• Verificación de compilación de SpeedLimit: OSMSerializable no es muy adecuado, porque el SpeedLimit enlazado no tiene geometría. Puede haber un problema: al incorporarse a la rampa, el límite de velocidad enlazado puede causar problemas.
• Interpolación
• Distancia de Hausdorff
• LcInJunctionTile

Algunas ideas creativas

• ¿Ir directamente a Spark?
• ¿Qué contexto necesita OSM?

• Aclarar con Yiming la interfaz del límite de velocidad personalizado: él asegura que un par de ubicaciones de entrada siempre puede determinar una única ruta más corta. Después de regresar, discutir con Guangcong el algoritmo para generar el límite de velocidad personalizado:
  1. Dada una ruta
  2. Si se sabe que |start DiRoadOnPath::count - end DiRoadOnPath::count| ≤ 1, entonces siempre se puede encontrar un par (start DiRoadOnPath, end DiRoadOnPath) que tenga la distancia más corta.
• Publicar temporalmente una versión snapshot disponible del compilador pylon-v0.1.1 para Xiaokang.
• Bajar con Hanteng a dar una vuelta y charlar sin ton ni son.
• Confirmar con Zizhe y Yicheng la interfaz de uso del mapa SUMO.
• La compilación de speed limit fue exitosa pero aún no se ha verificado.

• Determinar el esquema de límite de velocidad personalizado @guangcong
  1. Usar el nuevo módulo dynamicEvent para resolver este problema
  2. Publicar la actualización del límite de velocidad personalizado como un nuevo evento que desencadena la actualización de los datos de horizon
  3. Es necesario considerar el manejo de excepciones y los problemas de memoria Después de discutir con Guangcong, él encontró algunos problemas
• Revisión de Xiaokang Java, como un lenguaje sólido, tiene bastante sustancia
• Compilación del límite de velocidad Prácticamente ningún avance, solo se agregó la lógica para extraer RoadCenterTile
• Resolución del problema de seccionamiento, análisis de la optimización de edgeLifting, propuesta de un algoritmo de optimización: Dada la cabeza de traverse y la función de connectivity, se proporciona la forma de recorrido
• Investigación del principio de un Jar auto-ejecutable

• Limitación de velocidad de compilación
• Límite de velocidad personalizado