> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/analytics/es/iot-query/schema-overview/transformation-layer/common-transformations/trips.md). # Recorridos Registros de recorridos de vehículos derivados de datos telemáticos brutos. Incluye horas de inicio y fin, distancia, estadísticas de velocidad y detección de zonas La transformación de Viajes procesa datos telemáticos sin procesar en registros discretos de recorridos de vehículos. Cada fila en `processed_common_data.Viajes` representa un recorrido completo: dónde comenzó y terminó, cuánto tiempo tomó, qué distancia recorrió el vehículo y de qué zonas salió o a cuáles llegó. La transformación integrada se ejecuta cada 8 horas y cubre una ventana deslizante de 12 horas de Datos brutos. En cada ejecución, los registros calculados previamente para esa ventana se reemplazan por un nuevo cálculo, de modo que la tabla siempre refleje los datos más recientes disponibles. {% hint style="info" %} * Los datos de esta tabla pueden tener hasta 8 horas de antigüedad, lo que refleja la ejecución completada más recientemente. * Todas las marcas de tiempo se almacenan en UTC. {% endhint %} ## Tabla de salida: processed\_common\_data.Viajes Cada fila representa un recorrido validado del vehículo. La tabla se indexa por `device_id` y `recorrido_start_time`.
CampoTipoDescripción
device_identeroIdentificador del dispositivo. Para obtener la etiqueta del Objeto, únase a raw_business_data.objects activado device_id donde is_deleted = false para evitar la multiplicación de filas a partir de asignaciones históricas de dispositivos.
recorrido_start_timemarca de tiempoTiempo en que comenzó el Recorrido. Determinado por el primer punto de un nuevo segmento de Movimiento después de una parada válida o una brecha de datos.
hora_de_fin_del_Recorridomarca de tiempoHora en que terminó el recorrido. Se establece en el momento en que el dispositivo pasó de En movimiento a una parada que duró al menos 5 minutos.
duración del recorridotextoDuración del recorrido formateada como HH:MI:SS.
duración_del_recorrido_en_segundosnumericDuración del Recorrido en segundos. Use este campo para cálculos aritméticos.
distancia_del_Recorrido_en_metrosnumericDistancia total del recorrido en metros, calculada a partir de la geometría de línea de PostGIS construida a partir de todos los puntos del recorrido.
velocidad_promedionumericVelocidad promedio en todos los puntos del Recorrido, en km/h.
max_speednumericVelocidad máxima registrada durante el Recorrido, en km/h.
min_speednumericVelocidad mínima registrada durante el Recorrido, en km/h.
latitude_startnumericLatitud del primer punto del Recorrido, en grados.
longitude_startnumericLongitud del primer punto del Recorrido, en grados.
altitude_startnumericAltitud al inicio del Recorrido, en metros sobre el nivel del mar.
latitude_endnumericLatitud del último punto del recorrido, en grados.
longitud_finnumericLongitud del último punto del recorrido, en grados.
altitud_finnumericAltitud al final del recorrido, en metros sobre el nivel del mar.
puntos_en_recorridoenteroCantidad de puntos telemáticos sin procesar incluidos en el recorrido. Mínimo 2 para un recorrido válido.
zona_iniciotextoNombre de la zona de geocerca que contiene el punto de inicio del recorrido, si existe. Nulo si el punto de inicio no cae dentro de una zona definida.
zona_fintextoNombre de la Zona que contiene el punto final del Recorrido, si existe. Null si el punto final no cae dentro de una zona definida.
Los ejemplos a continuación muestran patrones de consulta comunes. La consulta básica devuelve registros de recorrido de los últimos 7 días, ordenados por dispositivo y hora de inicio. El segundo ejemplo se une a `raw_business_data.objects` para incluir la etiqueta legible para humanos del Objeto junto con cada Recorrido. {% tabs %} {% tab title="Consulta básica de recorrido" %} {% code overflow="wrap" expandable="true" %} ```sql SELECT device_id, recorrido_start_time, hora de fin del Recorrido, duración del recorrido, distancia_del_Recorrido_en_metros, velocidad promedio, zona de inicio, zona_fin FROM processed_common_data.Viajes DONDE el inicio_del_recorrido >= FECHA_ACTUAL - INTERVAL '7 days' ORDER BY device_id, trip_start_time; ``` {% endcode %} {% endtab %} {% tab title="Con etiqueta de Objeto" %} {% code overflow="wrap" expandable="true" %} ```sql SELECT t.device_id, o.object_label, t.trip_start_time, t.recorrido_end_time, t.distancia_del_recorrido_metros, t.avg_speed, t.start_zone, t.end_zone FROM processed_common_data.Viajes t LEFT JOIN raw_business_data.objects o ON o.device_id = t.device_id WHERE t.recorrido_start_time >= CURRENT_DATE - INTERVAL '7 days' ORDER BY t.device_id, t.trip_start_time; ``` {% endcode %} {% endtab %} {% endtabs %} ## Cómo se construyen los Viajes Un registro de recorrido no es una lectura bruta del dispositivo; es una entidad derivada ensamblada a partir de cientos\ de puntos telemáticos individuales. La transformación trabaja sobre los Datos brutos por etapas:\ primero decidiendo qué puntos vale la pena conservar, luego clasificando el estado de Movimiento de cada punto,\ luego agrupando los puntos en segmentos de recorrido y, por último, calculando las métricas agregadas que\ aparecen en la tabla de salida. Entender este proceso le ayuda a interpretar correctamente\ los resultados y a reconocer cuándo es necesario ajustar la configuración predeterminada para su Flota. Estos son los pasos del algoritmo que forma un registro de recorrido: {% stepper %} {% step %} #### **Recopilar y limpiar la entrada** La transformación lee las últimas 12 horas de datos de dos tablas de origen: * `Seguimiento_datos_núcleo` para las lecturas de posición y movimiento * `estados` para la bandera de movimiento de hardware que envía cada rastreador Los puntos se filtran antes de cualquier procesamiento adicional: * Los registros con coordenadas cero se descartan. * Los puntos con menos de 3 satélites se excluyen del conjunto GNSS. * Puntos LBS (`satélites = -1`) son la excepción: pasan para un manejo independiente en el siguiente paso, ya que las posiciones de torres celulares requieren distintas comprobaciones de validez antes de poder participar en la detección de recorridos. {% endstep %} {% step %} #### **Decidir si cada punto representa movimiento** Cada punto se clasifica en uno de tres estados: * `En movimiento`: la velocidad es igual o superior a 3 km/h, y la distancia desde el punto anterior supera 50 metros o el indicador de movimiento de hardware del rastreador está activo. Ambas condiciones evitan falsos positivos: la comprobación de distancia filtra picos de velocidad, y el indicador de hardware detecta el movimiento real a baja velocidad que la distancia por sí sola no detectaría. * `Detenido`: la velocidad está por debajo del umbral o la distancia es insuficiente. * `aparcado`: no hay una lectura de velocidad disponible para este punto. Los puntos LBS pasan por una verificación adicional antes de recibir un estado. Todo punto LBS en el que la velocidad calculada entre posiciones consecutivas supere 200 km/h se descarta como un artefacto de posicionamiento. Un punto LBS que pasa esta verificación e inmediatamente sigue a un punto GNSS puede formar su propio segmento de recorrido de un solo punto, cubriendo casos en los que un dispositivo pasa del posicionamiento por satélite al posicionamiento por torres celulares a mitad del recorrido. Todos los demás puntos LBS no válidos se eliminan. {% endstep %} {% step %} #### Agrupación de puntos en viajes Con cada punto llevando un estado de movimiento, la transformación identifica los límites del recorrido. Un nuevo recorrido comienza cuando: * El dispositivo genera su primer punto de datos en la ventana de procesamiento. * El movimiento se reanuda después de una parada que cumple los criterios (se supera la duración mínima de estacionamiento). * El movimiento se reanuda después de un intervalo sin datos (se supera el tiempo de espera). Un recorrido termina cuando: * El dispositivo ha estado Detenido de forma continua durante la duración mínima de estacionamiento. * Se produce una brecha de datos de la duración del tiempo de espera mientras el dispositivo no está En movimiento. Los umbrales que controlan estos límites se enumeran en los [Parámetros de configuración](#configuration-parameters) de referencia a continuación. {% endstep %} {% step %} #### Cálculo de métricas de salida Una vez que se establecen los límites del Recorrido, todos los puntos de cada Recorrido se agregan en una sola fila de salida: * `distancia_del_Recorrido_en_metros`: derivada de una geometría de línea de PostGIS construida a partir de la secuencia ordenada de puntos usando `ST_MakeLine`. * `velocidad_promedio`, `max_speed`, `min_speed`: calculada a partir de todos los puntos del Recorrido. * `latitude_start`, `longitude_start`, `latitude_end`, `longitud_fin`: tomado de los primeros y últimos puntos de la secuencia. * `zona_inicio`, `zona_fin`: poblado al hacer coincidir las coordenadas de inicio y fin con `processed_common_data.zones_geom`. La coincidencia requiere que el punto caiga exactamente dentro del límite de la zona; no se aplica ningún búfer. {% endstep %} {% step %} #### Filtrado de ruido antes de escribir los resultados No todos los segmentos del recorrido que identifica el algoritmo vale la pena conservar. Los segmentos cortos causados por una breve recuperación del GPS, los dispositivos estacionarios con deriva ocasional de posición o los datos incompletos en el límite de la ventana se descartan. Un recorrido solo se escribe en la tabla de salida cuando cumple simultáneamente todas las condiciones siguientes: | Condición | Umbral | | ----------------------------- | --------------------------- | | Puntos en el recorrido | Al menos 2 | | Velocidad máxima registrada | Al menos 3 km/h | | Distancia total del recorrido | Al menos 100 metros | | Hora de inicio del recorrido | Debe determinarse (no nulo) | | Hora de fin del recorrido | Debe determinarse (no nulo) | | {% endstep %} | | | {% endstepper %} | | Las dos secciones de referencia siguientes contienen los parámetros configurables y las reglas de escalamiento de datos brutos que la transformación aplica internamente.
Parámetros de configuración Estos umbrales gobiernan cómo se dividen y validan los recorridos. Son los objetivos más comunes para la personalización. Consulte [Personalizar la transformación](#customizing-the-transformation) las instrucciones sobre cómo ajustarlos en la plantilla del flujo de trabajo.
ParámetroValor predeterminadoDescripción
Duración mínima de estacionamiento300 segundos (5 minutos)Una parada más corta que esta no termina el recorrido actual. Se considera que el dispositivo sigue en el mismo recorrido.
Tiempo de espera de brecha de datos1200 segundos (20 minutos)Si no llegan datos durante este tiempo, el recorrido actual termina y comienza uno nuevo cuando se reanuda la llegada de datos.
Distancia mínima de movimiento50 metrosUn punto debe estar al menos a esta distancia del punto anterior para contar como movimiento.
Velocidad mínima de movimiento3 km/hLos puntos por debajo de esta velocidad no se clasifican como en movimiento.
Escalamiento de valores brutos Datos telemáticos brutos de `Seguimiento_datos_núcleo` almacena los valores de coordenadas y velocidad como enteros para un almacenamiento eficiente. La transformación los convierte a unidades estándar antes del procesamiento. | Campo | Divisor | Resultado | | --------------------- | ---------------- | --------------------------------------- | | `latitud`, `longitud` | 10,000,000 (1e7) | Grados (p. ej., 554567890 → 55.456789°) | | `altitud` | 10,000,000 (1e7) | Metros sobre el nivel del mar | | `velocidad` | 100 (1e2) | km/h (p. ej., 6530 → 65.30 km/h) |
## Personalizar la transformación La transformación predeterminada de Viajes refleja la lógica general de detección de recorridos de Navixy. Si su escenario operativo requiere un comportamiento diferente, puede cargar la plantilla del flujo de trabajo en [Transformation Builder](/docs/analytics/es/iot-query/schema-overview/transformation-layer/transformation-builder.md), modificar los nodos relevantes y programar el flujo de trabajo ajustado como una transformación personalizada en `processed_custom_data`. {% hint style="warning" %} Varios nodos en el flujo de trabajo de Viajes usan funciones geométricas de PostGIS y funciones de ventana (`LAG`, `FIRST_VALUE`, `LAST_VALUE`, `SUM OVER`). Modificar estos nodos requiere un sólido conocimiento de SQL. Siempre obtenga una vista previa del resultado usando el botón **Ejecutar** en el Generador de transformaciones antes de programar un flujo de trabajo modificado. {% endhint %} ### Ejemplos de personalización Expanda las secciones siguientes para ver algunos ejemplos de personalización basados en casos.
Ajustar los umbrales de parada y de brecha Úselo cuando el umbral predeterminado de estacionamiento de 5 minutos divida lo que debería ser un solo recorrido continuo en varios registros; esto es común en rutas de reparto urbanas con paradas cortas frecuentes. Este ajuste también ayuda cuando los dispositivos tienen intervalos de reporte irregulares y el tiempo de espera de brecha de 20 minutos termina los recorridos prematuramente. Los valores del umbral están codificados de forma rígida como constantes enteras en dos nodos de SQL personalizado: 1. Abra el **Banderas del recorrido** nodo (`custom_9`). Encuentre la condición `parking_duration >= 300 * INTERVAL '1 second'`. Esto aparece dos veces en el nodo. Reemplace `300` con su valor objetivo en segundos en ambos lugares. Por ejemplo, para exigir una parada de 10 minutos, use `600`. 2. En el mismo **Banderas del recorrido** nodo (`custom_9`), encuentre `time_diff >= 1200`. Luego abra el **Marcadores de estacionamiento** nodo (`custom_6`) y encuentre allí la misma condición. Reemplace `1200` con su valor objetivo en segundos en ambos nodos. Por ejemplo, para tolerar brechas de 30 minutos, use `1800`. 3. Haga clic en **Ejecutar** para previsualizar el resultado y confirmar que los límites del recorrido coincidan con sus expectativas operativas antes de programar.
Activar el filtrado de LBS basado en distancia Úselo cuando su flota opere en áreas con poca cobertura GPS y los puntos LBS estén introduciendo grandes saltos de coordenadas — por ejemplo, un dispositivo pierde la señal satelital y se engancha a una torre celular a varios kilómetros de distancia. Excluir estos puntos produce una geometría del recorrido más limpia y cálculos de distancia más precisos. La plantilla del flujo de trabajo incluye un marcador de posición para esta verificación en el **LBS procesado** nodo (`custom_3`), pero está inactivo de forma predeterminada. La `distance_status` columna está codificada de forma rígida para devolver siempre `'VALID'` mediante la expresión provisional `CASE WHEN 1 != 1 THEN 'EXCLUDED_DISTANCE' ELSE 'VALID' END`. Para activarlo: 1. Abra el **LBS procesado** nodo de SQL personalizado (`custom_3`) en el Generador de transformaciones. 2. Reemplace la línea provisional por una condición real basada en `distance_meters`. Por ejemplo, para excluir puntos LBS a más de 500 metros del punto anterior: ```sql CASE WHEN point_type = 'LBS' AND distance_meters > 500 THEN 'EXCLUDED_DISTANCE' ELSE 'VALID' END AS distance_status, ``` Un umbral entre 200 y 1000 metros es un rango inicial razonable: use un valor menor en áreas con cobertura densa de torres celulares, y uno mayor donde las torres sean escasas. 3. Haga clic en **Ejecutar** para previsualizar el resultado. Verifique cuántos puntos LBS quedan excluidos ahora y si los recorridos restantes se ven correctos. Ajuste el umbral si es necesario antes de programarlo.
Excluir por completo los puntos LBS Úselo cuando su flota use dispositivos solo GPS que nunca producen lecturas LBS, o cuando quiera que los registros del recorrido se construyan exclusivamente a partir de posiciones GNSS confirmadas. 1. Abra el **Datos centrales** nodo fuente (`telematics_1`, tipo: Datos brutos: Telemática). En el **Condición de filtro** campo, elimine `OR satellites = -1` desde la comprobación de satélites, cambiando: ``` event_id IN (2, 802, 803, 804, 811) AND latitude <> 0 AND longitude <> 0 AND (satellites >= 3 OR satellites = -1) ``` a: ``` event_id IN (2, 802, 803, 804, 811) AND latitude <> 0 AND longitude <> 0 AND satellites >= 3 ``` 2. Elimine el **LBS procesado** nodo (`custom_3`) y el **LBS filtrado** nodo (`custom_4`) del grafo, junto con todas las aristas conectadas a ellos. Dibuje una nueva arista desde el **Con distancia** nodo (`custom_2`) al **Filtro inválido** nodo (`filter_1`) para restaurar el flujo de datos. 3. Abra el **Filtro inválido** nodo y reemplace ambas condiciones dinámicas existentes con una sola condición directa: `calculated_speed_kmh <= 200`. Las condiciones originales (`lbs_excluded_flag = 0` y `speed_status = 'VALID'`) hacen referencia a columnas generadas por los nodos eliminados y provocarán un error de ejecución si se dejan tal cual. 4. Haga clic en **Ejecutar** para previsualizar la salida. Verifique que el conteo de puntos y los límites de los recorridos se vean correctos para sus datos antes de programar.
### Uso de la plantilla del flujo de trabajo Navixy proporciona una plantilla de flujo de trabajo de recorridos lista para usar que puede cargar en Transformation Builder como punto de partida. La plantilla cubre todos los pasos de procesamiento descritos en esta página, desde la ingesta de datos brutos hasta la coincidencia con zonas y la agregación. Consulte la [Plantillas](/docs/analytics/es/iot-query/schema-overview/transformation-layer/transformation-builder/templates.md) página para la descarga, las instrucciones de importación y la configuración del nodo Output para esta transformación. ## Próximos pasos * [**Transformaciones comunes**](/docs/analytics/es/iot-query/schema-overview/transformation-layer/common-transformations.md): Volver al índice de transformaciones. * [**Plantillas**](/docs/analytics/es/iot-query/schema-overview/transformation-layer/transformation-builder/templates.md): Descargue la plantilla de flujo de trabajo de recorridos e impórtela en Transformation Builder. * [**Transformation Builder**](/docs/analytics/es/iot-query/schema-overview/transformation-layer/transformation-builder.md): Aprenda a trabajar con el editor visual de flujos de trabajo, agregar nodos y previsualizar los resultados. * [**Capa de Datos brutos**](/docs/analytics/es/iot-query/schema-overview/bronze-layer.md): Explore las tablas de origen que alimentan la transformación de recorridos: `Seguimiento_datos_núcleo`, `estados`, y `zones_geom`. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://navixy.com/docs/analytics/es/iot-query/schema-overview/transformation-layer/common-transformations/trips.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.