Exportation des données de suivi

Au fur et à mesure que les appareils de suivi fonctionnent, leurs données sont envoyées et stockées dans la base de données de la plateforme Navixy, afin que vous puissiez consulter les trajets dans le module de surveillance et générer des rapports de trajet. Toutefois, il peut exister des situations où vous devez extraire toutes les informations d’enregistrement du suivi sous forme de points de géolocalisation. Cela est généralement nécessaire pour analyser les données dans des situations controversées. Dans ce cas, vous pouvez demander ces informations directement à la base de données.

Cette méthode vous permet d’obtenir les données de manière plus détaillée et « technique » que ce que vous voyez dans la surveillance. Mais il est important de comprendre que pour apparaître dans la base de données, les données doivent avoir été effectivement transmises par un appareil de suivi, et il ne sera pas possible de reconstituer des trajets totalement absents de la surveillance de cette manière.

Vous aurez besoin d’un accès direct à la base de données MySQL pour extraire les données de suivi, ce qui signifie que vos clients ne disposent pas des droits pour cette opération, et seuls les techniciens ayant accès au serveur possèdent l’autorisation nécessaire.

Les données de suivi sont stockées dans la base de données tracking Selon la date et la méthode de déploiement de votre instance de plateforme, deux façons fondamentalement différentes d’organiser la structure de la base de données sont possibles.

  • Structure par buckets. Dans ce cas, les données de suivi sont partitionnées en plusieurs buckets (16 par défaut).

  • Structure fichier par fichier, où chaque traceur correspond à une table séparée nommée d’après son IMEI.

Le type d’organisation des données que vous utilisez est facile à vérifier en ouvrant simplement le répertoire de stockage des fichiers de la base de données - par exemple, sous Linux ceci est /var/lib/mysql/tracking par défaut. À l’intérieur, vous trouverez soit des fichiers partitionnés nommés comme bucket_****.ibd, soit plusieurs fichiers ibd et fichiers frm nommés d’après l’IMEI des appareils.

Structure par buckets

Il s’agit d’un type contemporain d’organisation de base de données où, pour optimiser les performances, les données ne sont pas stockées dans des tables individuelles pour chaque traceur, mais dans les soi‑disant buckets. Par défaut, il y en a 16, les traceurs y sont placés de manière aléatoire. Chaque traceur possède son propre storage_id, selon lequel nous pouvons retrouver le bucket requis.

Pour demander les données, vous avez besoin de l’IMEI du traceur (dans cet exemple, nous utilisons l’IMEI fictif 987654321012345), et de l’identifiant interne de l’appareil nommé source_id.

Découvrez source_id et storage_id en utilisant cette requête :

SELECT storage_id, source_id FROM google.sources WHERE source_imei='987654321012345'; 

Le storage_id résultat commence par le numéro du bucket - de 1 à 16. Par exemple, storage_id=201000 signifie bucket_2 et storage_id=1301000 signifie bucket_13.

Dans la requête suivante, nous avons besoin à la fois du numéro du bucket et du source_id. Avec cette requête nous sollicitons les données de suivi pour la période requise et les exportons dans un fichier CSV.

Veuillez noter :

  • nous utilisons le source_id et bucket numéro trouvé avec la requête précédente.

  • get_time est le moment d’enregistrement des données par l’appareil, il est spécifié en UTC+0, indépendamment du fuseau horaire du compte utilisateur.

  • MySQL doit disposer des permissions d’écriture dans le dossier spécifié dans la requête.

La requête SQL elle‑même est la suivante :

SELECT 'Id','TrackID','Server time','Tracker time','Longitude','Latitude','Speed','Altitude','Satellites','Status','Heading','Event ID','Duration','Mileage','Inputs','Outputs','Address'   
UNION ALL   
SELECT id, track_id, actual_time, get_time, lng, lat, speed, alt, satellites, status, heading, event_id, duration, mileage, input_status, output_status, address  
FROM tracking.bucket_2 where source_id=12345 and get_time between '2024-07-20 20:11:00' and '2024-07-20 20:13:00'   
INTO OUTFILE "/var/lib/mysql-files/987654321012345.csv"
FIELDS TERMINATED BY ','   
ENCLOSED BY '"' LINES   
TERMINATED BY '\n';

Pour Windows, le chemin ressemble à :

INTO OUTFILE "C:/ProgramData/MySQL/MySQL Server 8.0/Uploads/987654321012345.csv"

Structure fichier par fichier

Ceci est une ancienne manière d’organiser la structure de la base de données, qui reste toutefois pertinente pour de nombreuses instances Navixy ayant plusieurs années d’historique.

Pour demander les données dans ce cas, vous n’avez besoin que de l’IMEI du traceur (dans cet exemple, nous utilisons l’IMEI fictif 987654321012345).

Veuillez noter :

  • get_time est le moment d’enregistrement des données par l’appareil, il est spécifié en UTC+0, indépendamment du fuseau horaire du compte utilisateur.

  • MySQL doit disposer des permissions d’écriture dans le dossier spécifié dans la requête.

La requête SQL est la suivante :

SELECT 'Id','TrackID','Server time','Tracker time','Longitude','Latitude','Speed','Altitude','Satellites','Status','Heading','Event ID','Duration','Mileage','Inputs','Outputs','Address'  
UNION ALL  
SELECT id, track_id, actual_time, get_time, point_y, point_x, speed, altitude, satellites, status, heading, event_id, duration, mileage, input_status, output_status, address 
FROM tracking.987654321012345 where get_time between '2024-07-20 20:11:00' and '2024-07-20 20:13:00'  
INTO OUTFILE "/var/lib/mysql-files/987654321012345.csv"  
FIELDS TERMINATED BY ','  
ENCLOSED BY '"' LINES  
TERMINATED BY '\n';

Pour Windows, le chemin ressemble à :

INTO OUTFILE "C:/ProgramData/MySQL/MySQL Server 8.0/Uploads/987654321012345.csv"

Export des données

La requête SQL ci‑dessus générera un fichier CSV contenant tous les points de suivi enregistrés pour l’appareil.

Ce fichier peut être importé dans Excel ou utilisé dans tout développement interne.

Mis à jour

Ce contenu vous a-t-il été utile ?