> 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/fr/iot-query/schema-overview/transformation-layer/common-transformations/trips.md). # Trajets Enregistrements de trajets de véhicule dérivés des données télématiques brutes. Inclut les heures de début et de fin, la distance, les statistiques de vitesse et la détection de zone La transformation des Trajets traite les données télématiques brutes pour les convertir en enregistrements distincts de trajets de véhicule. Chaque ligne dans `processed_common_data.Trajets` représente un voyage complet : où il a commencé et s’est terminé, combien de temps il a duré, quelle distance le véhicule a parcourue et de quelles zones il est parti ou auxquelles il est arrivé. La transformation intégrée s'exécute toutes les 8 heures et couvre une fenêtre glissante de 12 heures de Données brutes. À chaque exécution, les enregistrements précédemment calculés pour cette fenêtre sont remplacés par un nouveau calcul, de sorte que le tableau reflète toujours les données les plus récentes disponibles. {% hint style="info" %} * Les données de ce tableau peuvent dater de jusqu’à 8 heures, reflétant l’exécution la plus récemment terminée. * Tous les horodatages sont stockés en UTC. {% endhint %} ## Table de sortie : processed\_common\_data.trips Chaque ligne représente un Voyage de véhicule validé. Le tableau est indexé sur `device_id` et `voyage_start_time`.
ChampTypeDescription
device_identierIdentifiant de l’appareil. Pour obtenir l’étiquette du Traceur, joindre à raw_business_data.objects activé device_id où is_deleted = faux pour éviter la multiplication des lignes due aux affectations historiques des appareils.
voyage_start_timehorodatageMoment où le Voyage a commencé. Déterminé par le premier point d'un nouveau segment de Mouvement après un arrêt admissible ou une lacune de données.
heure_de_fin_du_voyagehorodatageMoment où le Voyage s'est terminé. Défini au moment où l'appareil est passé de En mouvement à un arrêt qui a duré au moins 5 minutes.
durée_du_voyagetexteDurée du Voyage formatée en HH:MI:SS.
durée_du_voyage_en_secondesnumériqueDurée du Voyage en secondes. Utilisez ce champ pour les calculs arithmétiques.
distance_du_voyage_en_mètresnumériqueDistance totale du Voyage en mètres, calculée à partir de la géométrie de ligne PostGIS construite à partir de tous les points du Voyage.
vitesse_moyennenumériqueVitesse moyenne sur tous les points du Voyage, en km/h.
vitesse_maximalenumériqueVitesse maximale enregistrée pendant le Voyage, en km/h.
vitesse_minimalenumériqueVitesse minimale enregistrée pendant le Voyage, en km/h.
latitude_de_débutnumériqueLatitude du premier point du Voyage, en degrés.
longitude_de_débutnumériqueLongitude du premier point du voyage, en degrés.
altitude_de_débutnumériqueAltitude au début du voyage, en mètres au-dessus du niveau de la mer.
latitude_de_finnumériqueLatitude du dernier point du voyage, en degrés.
longitude_de_finnumériqueLongitude du dernier point du voyage, en degrés.
altitude_de_finnumériqueAltitude à la fin du voyage, en mètres au-dessus du niveau de la mer.
points_du_voyageentierNombre de points télématiques bruts inclus dans le voyage. Minimum 2 pour un voyage valide.
zone_de_débuttexteNom de la Zone géographique qui contient le point de départ du voyage, le cas échéant. Null si le point de départ ne se trouve pas dans une zone définie.
zone_de_fintexteNom de la Zone géographique qui contient le point d'arrivée du voyage, le cas échéant. Null si le point d'arrivée ne se trouve pas dans une zone définie.
Les exemples ci-dessous montrent des modèles de requête courants. La requête de base renvoie les enregistrements de voyage des 7 derniers jours, triés par appareil et heure de début. Le deuxième exemple joint à `raw_business_data.objects` pour inclure le libellé lisible du Traceur à côté de chaque voyage. {% tabs %} {% tab title="Requête de voyage de base" %} {% code overflow="wrap" expandable="true" %} ```sql Sélectionner device_id, heure_de_début_du_voyage, heure_de_fin_du_voyage, durée_du_Voyage, distance_du_Voyage_en_mètres, vitesse_moyenne, zone_de_départ, zone_de_fin FROM processed_common_data.Trajets WHERE heure_de_début_du_Voyage >= CURRENT_DATE - INTERVAL '7 days' ORDER BY device_id, heure_de_début_du_Voyage; ``` {% endcode %} {% endtab %} {% tab title="Avec le libellé de Traceur" %} {% code overflow="wrap" expandable="true" %} ```sql Sélectionner t.device_id, o.libellé_Traceur, t.heure_de_début_du_Voyage, t.heure_de_fin_du_Voyage, t.distance_du_Voyage_en_mètres, t.vitesse_moyenne, t.zone_de_départ, t.zone_d'arrivée FROM processed_common_data.Trajets t LEFT JOIN raw_business_data.objects o ON o.device_id = t.device_id WHERE t.heure_de_début_du_Voyage >= CURRENT_DATE - INTERVAL '7 days' ORDER BY t.device_id, t.heure_de_début_du_Voyage; ``` {% endcode %} {% endtab %} {% endtabs %} ## Comment les Trajets sont construits Un enregistrement de Voyage n'est pas une lecture brute de l'appareil ; c'est une entité dérivée assemblée à partir de centaines de points télématiques individuels. La transformation traite les Données brutes par étapes :\ d'abord en décidant quels points méritent d'être conservés, puis en classant le statut de Mouvement de chaque point,\ puis en regroupant les points en segments de Voyage, et enfin en calculant les métriques agrégées qui\ apparaissent dans la table de sortie. Comprendre ce processus vous aide à interpréter correctement les résultats\ et à reconnaître quand les paramètres par défaut doivent être ajustés pour votre Flotte. Voici les étapes de l'algorithme qui forme un enregistrement de Voyage : {% stepper %} {% step %} #### **Collecte et nettoyage des entrées** La transformation lit les 12 dernières heures de Données brutes provenant de deux tables sources : * `suivi_data_core` pour les relevés de position et de mouvement * `états` pour l'indicateur matériel de Mouvement envoyé par chaque Traceur Les points sont filtrés avant tout traitement supplémentaire : * Les enregistrements avec des coordonnées nulles sont supprimés. * Les points avec moins de 3 satellites sont exclus de l'ensemble GNSS. * Les points LBS (`satellites = -1`) font exception : ils passent par un traitement séparé à l'étape suivante, car les positions des antennes relais nécessitent des contrôles de validité différents avant de pouvoir participer à la détection des Trajets. {% endstep %} {% step %} #### **Déterminer si chaque point représente un Mouvement** Chaque point est classé dans l'un des trois statuts : * `En mouvement`: la vitesse est égale ou supérieure à 3 km/h, et soit la distance depuis le point précédent dépasse 50 mètres, soit l'indicateur matériel de Mouvement du Traceur est actif. Les deux conditions évitent les faux positifs : le contrôle de distance filtre les pics de vitesse, et l'indicateur matériel détecte un véritable Mouvement à faible vitesse que la distance seule manquerait. * `Arrêté`: la vitesse est inférieure au seuil ou la distance est insuffisante. * `Stationné`: aucune mesure de vitesse n'est disponible pour ce point. Les points LBS passent par un contrôle supplémentaire avant de recevoir un statut. Tout point LBS dont la vitesse calculée entre positions consécutives dépasse 200 km/h est rejeté comme un artefact de positionnement. Un point LBS qui passe ce contrôle et suit immédiatement un point GNSS peut former son propre segment de Voyage à point unique, couvrant les cas où un appareil passe du positionnement par satellite au positionnement par antenne relais au milieu du Voyage. Tous les autres points LBS invalides sont supprimés. {% endstep %} {% step %} #### Regroupement des points en Trajets Avec chaque point portant un statut de Mouvement, la transformation identifie les limites des Trajets. Un nouveau Voyage commence lorsque : * L'appareil produit son premier point de données dans la fenêtre de traitement. * Le Mouvement reprend après un arrêt admissible (la durée minimale de stationnement est dépassée). * Le Mouvement reprend après une interruption de données (le délai est dépassé). Un Voyage se termine lorsque : * L'appareil est resté Arrêté en continu pendant la durée minimale de stationnement. * Une interruption de données d'une durée égale au délai se produit alors que l'appareil n'est pas En mouvement. Les seuils qui contrôlent ces limites sont indiqués dans les [paramètres de configuration](#configuration-parameters) référence ci-dessous. {% endstep %} {% step %} #### Calcul des métriques de sortie Une fois les limites du Voyage établies, tous les points de chaque Voyage sont agrégés en une seule ligne de sortie : * `distance_du_voyage_en_mètres`: dérivé d'une géométrie linéaire PostGIS construite à partir de la séquence ordonnée de points à l'aide de `ST_MakeLine`. * `vitesse_moyenne`, `vitesse_maximale`, `vitesse_minimale`: calculé sur l'ensemble des points du Voyage. * `latitude_de_début`, `longitude_de_début`, `latitude_de_fin`, `longitude_de_fin`: tiré du premier et du dernier point de la séquence. * `zone_de_début`, `zone_de_fin`: renseigné en faisant correspondre les coordonnées de début et de fin avec `processed_common_data.zones_geom`. Une correspondance exige que le point se situe exactement à l'intérieur de la limite de la zone ; aucune zone tampon n'est appliquée. {% endstep %} {% step %} #### Filtrage du bruit avant l'écriture des résultats Tous les segments de Voyage que l'algorithme identifie ne méritent pas d'être conservés. Les segments courts causés par une brève récupération GPS, des appareils stationnaires avec une dérive de position occasionnelle, ou des données incomplètes à la limite de la fenêtre sont écartés. Un Voyage n'est écrit dans la table de sortie que lorsqu'il remplit simultanément toutes les conditions suivantes : | Condition | Seuil | | ---------------------------- | -------------------------- | | Points dans le Voyage | Au moins 2 | | Vitesse maximale enregistrée | Au moins 3 km/h | | Distance totale du Voyage | Au moins 100 mètres | | Heure de début du Voyage | Doit être défini (non nul) | | Heure de fin du Voyage | Doit être défini (non nul) | | {% endstep %} | | | {% endstepper %} | | Les deux sections de référence suivantes contiennent les paramètres configurables et les règles de mise à l'échelle des Données brutes que la transformation applique en interne.
paramètres de configuration Ces seuils régissent la manière dont les Trajets sont segmentés et validés. Ce sont les cibles de personnalisation les plus courantes. Voir [Personnalisation de la transformation](#customizing-the-transformation) pour savoir comment les ajuster dans le modèle de workflow.
ParamètreValeur par défautDescription
Durée minimale de stationnement300 secondes (5 minutes)Un arrêt plus court que cela ne met pas fin au Voyage en cours. L'appareil est considéré comme étant toujours sur le même Voyage.
Délai d'expiration de l'absence de données1200 secondes (20 minutes)Si aucune donnée n'arrive pendant cette durée, le Voyage en cours se termine et un nouveau commence lorsque les données reprennent.
Distance minimale de Mouvement50 mètresUn point doit se trouver à au moins cette distance du point précédent pour compter comme Mouvement.
Vitesse minimale de Mouvement3 km/hLes points en dessous de cette vitesse ne sont pas classés comme En mouvement.
Mise à l'échelle des valeurs brutes Les données télématiques brutes provenant de `suivi_data_core` stocke les valeurs de coordonnées et de vitesse sous forme d'entiers pour un stockage efficace. La transformation les convertit en unités standard avant le traitement. | Champ | Diviseur | Résultat | | ----------------------- | ---------------- | --------------------------------------- | | `latitude`, `longitude` | 10,000,000 (1e7) | Degrés (p. ex., 554567890 → 55.456789°) | | `altitude` | 10,000,000 (1e7) | Mètres au-dessus du niveau de la mer | | `vitesse` | 100 (1e2) | km/h (p. ex., 6530 → 65,30 km/h) |
## Personnalisation de la transformation La transformation Trajets par défaut reflète la logique de détection des trajets à usage général de Navixy. Si votre scénario opérationnel nécessite un comportement différent, vous pouvez charger le modèle de workflow dans [Constructeur de transformations](/docs/analytics/fr/iot-query/schema-overview/transformation-layer/transformation-builder.md), modifier les nœuds concernés et planifier le workflow ajusté comme transformation personnalisée dans `processed_custom_data`. {% hint style="warning" %} Plusieurs nœuds du workflow Trajets utilisent des fonctions géométriques PostGIS et des fonctions fenêtre (`LAG`, `FIRST_VALUE`, `LAST_VALUE`, `SUM OVER`). La modification de ces nœuds nécessite une solide connaissance de SQL. Prévisualisez toujours le résultat à l'aide du **Exécuter** bouton dans Transformation Builder avant de planifier un workflow modifié. {% endhint %} ### Exemples de personnalisation Développez les sections ci-dessous pour voir quelques exemples de personnalisation basés sur des cas.
Ajustement des seuils d'arrêt et d'écart Utilisez ceci lorsque le seuil de stationnement par défaut de 5 minutes divise ce qui devrait être un seul trajet continu en plusieurs enregistrements — ce qui est courant dans les itinéraires de livraison urbains avec des arrêts courts fréquents. Cet ajustement est également utile lorsque les appareils ont des intervalles de remontée irréguliers et que le délai d'attente d'écart de 20 minutes met fin aux trajets prématurément. Les valeurs de seuil sont codées en dur comme constantes entières dans deux nœuds Custom SQL : 1. Ouvrez le **Indicateurs de voyage** nœud (`custom_9`). Repérez la condition `parking_duration >= 300 * INTERVAL '1 second'`. Cela apparaît deux fois dans le nœud. Remplacez `300` par votre valeur cible en secondes aux deux endroits. Par exemple, pour exiger un arrêt de 10 minutes, utilisez `600`. 2. Dans le même **Indicateurs de voyage** nœud (`custom_9`), repérez `time_diff >= 1200`. Ensuite, ouvrez le **Marqueurs de stationnement** nœud (`custom_6`) et repérez-y la même condition. Remplacez `1200` par votre valeur cible en secondes dans les deux nœuds. Par exemple, pour tolérer des écarts de 30 minutes, utilisez `1800`. 3. Cliquez sur **Exécuter** pour prévisualiser le résultat et confirmer que les limites des trajets correspondent à vos attentes opérationnelles avant la planification.
Activation du filtrage LBS basé sur la distance Utilisez ceci lorsque votre Flotte opère dans des zones avec une mauvaise couverture GPS et que des points LBS introduisent de grands sauts de coordonnées — par exemple, lorsqu'un appareil perd le signal satellite et se rabat sur une antenne relais située à plusieurs kilomètres. L'exclusion de ces points produit une géométrie des trajets plus propre et des calculs de distance plus précis. Le modèle de workflow inclut un emplacement réservé à ce contrôle dans le **LBS traité** nœud (`custom_3`), mais il est inactif par défaut. La `distance_status` colonne est codée en dur pour toujours renvoyer `'VALID'` via l'expression factice `CASE WHEN 1 != 1 THEN 'EXCLUDED_DISTANCE' ELSE 'VALID' END`. Pour l'activer : 1. Ouvrez le **LBS traité** nœud Custom SQL (`custom_3`) dans Transformation Builder. 2. Remplacez la ligne factice par une condition réelle basée sur `distance_meters`. Par exemple, pour exclure les points LBS situés à plus de 500 mètres du point précédent : ```sql CAS WHEN point_type = 'LBS' AND distance_meters > 500 THEN 'EXCLUDED_DISTANCE' ELSE 'VALID' END AS distance_status, ``` Un seuil compris entre 200 et 1000 mètres constitue une plage de départ raisonnable — utilisez une valeur plus basse dans les zones à forte densité de couverture des antennes relais, et plus élevée là où elles sont rares. 3. Cliquez sur **Exécuter** pour prévisualiser le résultat. Vérifiez combien de points LBS sont désormais exclus et si les trajets restants semblent corrects. Ajustez le seuil si nécessaire avant l’ordonnancement.
Exclusion totale des points LBS Utilisez ceci lorsque votre flotte utilise des appareils GPS uniquement qui ne produisent jamais de relevés LBS, ou lorsque vous souhaitez que les enregistrements de trajets soient construits exclusivement à partir de positions GNSS confirmées. 1. Ouvrez le **Core Data** nœud source (`telematics_1`, type : Données brutes : Télématique). Dans le **Condition de filtre** champ, supprimez `OR satellites = -1` du contrôle des satellites, en remplaçant : ``` event_id IN (2, 802, 803, 804, 811) AND latitude <> 0 AND longitude <> 0 AND (satellites >= 3 OR satellites = -1) ``` par : ``` event_id IN (2, 802, 803, 804, 811) AND latitude <> 0 AND longitude <> 0 AND satellites >= 3 ``` 2. Supprimez le **LBS traité** nœud (`custom_3`) et le **LBS filtrés** nœud (`custom_4`) du graphe, ainsi que tous les liens qui y sont connectés. Tracez un nouvel arc depuis le **Avec la distance** nœud (`custom_2`) vers le **Filtrer les invalides** nœud (`filter_1`) pour rétablir le flux de données. 3. Ouvrez le **Filtrer les invalides** nœud et remplacez les deux conditions dynamiques existantes par une seule condition directe : `calculated_speed_kmh <= 200`. Les conditions d'origine (`lbs_excluded_flag = 0` et `speed_status = 'VALID'`) font référence aux colonnes produites par les nœuds supprimés et provoqueront une erreur d'exécution si elles sont laissées en place. 4. Cliquez sur **Exécuter** pour prévisualiser la sortie. Vérifiez que les décomptes de points et les limites des trajets sont corrects pour vos données avant l’ordonnancement.
### Utilisation du modèle de workflow Navixy fournit un modèle de workflow Trajets prêt à l’emploi que vous pouvez charger dans Transformation Builder comme point de départ. Le modèle couvre toutes les étapes de traitement décrites sur cette page, de l’ingestion des Données brutes jusqu’à la correspondance avec les zones et à l’agrégation. Voir la [Modèles](/docs/analytics/fr/iot-query/schema-overview/transformation-layer/transformation-builder/templates.md) page pour le téléchargement, les instructions d’importation et la configuration du nœud de sortie pour cette transformation. ## Étapes suivantes * [**Transformations courantes**](/docs/analytics/fr/iot-query/schema-overview/transformation-layer/common-transformations.md): Retour à l'index des transformations. * [**Modèles**](/docs/analytics/fr/iot-query/schema-overview/transformation-layer/transformation-builder/templates.md): Téléchargez le modèle de workflow Trajets et importez-le dans Transformation Builder. * [**Constructeur de transformations**](/docs/analytics/fr/iot-query/schema-overview/transformation-layer/transformation-builder.md): Découvrez comment utiliser l’éditeur visuel de workflow, ajouter des nœuds et prévisualiser les résultats. * [**Couche de Données brutes**](/docs/analytics/fr/iot-query/schema-overview/bronze-layer.md): Explorez les tables sources qui alimentent la transformation Trajets : `suivi_data_core`, `états`, et `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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://navixy.com/docs/analytics/fr/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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.