-- Leo's gemini proxy
-- Connecting to unbon.cafe:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;
L'association 2Pieds2Roues de Toulouse a publié une carte des incidents impliquant piétons ou cyclistes sur la zone de Toulouse[1]. Sur demande, je me suis prêté à l'exercice à échelle locale.
À noter que la carte obtenue n'est pas à prendre seule, elle ne laisse entendre ni la responsabilité des personnes ni le risque par rapport au volume de trafic total. C'est seulement une carte permettant de situer où ont lieux les incidents, aiguillant sur les lieux à sécuriser, ou créer des itinéraires alternatifs.
Le résultat[2], et le code[3] sont disponibles en ligne.
La source des données est le fichier national Base de données Anuelles des Accidents corporels de la Circulation (BAAC), administré par l'Observatoire National Interministériel de la Sécurité Routière (ONISR) – Ou, comme je préfère l'appeler l'Observatoire National de l'InSécurité Routière.
Ces données sont publiées en OpenData[4]. Les noms de variables sont plus qu'obscurs, et il faut avant toute chose consulter le manuel[5].
Les données sont divisées en 4 « catégories » (sic), et un recollement se fait via les variables `Num_Acc` (identifiant l'incident) et `id_vehicule` (identifiant un parti).
Les variables qui m'intéressent sont :
Caractéristiques : `dep` (Dans l'idéal ma carte couvrirait tout le Doubs) ;
Lieux : `vma` (Vitesse maximale autorisée) ;
Véhicules : `catv` (Je recherche uniquement les cyclistes 01 et 80, EDP(m) 50 et 60) ;
Usagers ; `catu` (Les piétons 3).
J'ai utilisé R, encore une fois[6]. Pour pouvoir facilement ré-apparier les données entre elles, en particulier par rapport au fichier caractéristiques où se trouve la localisation des évènements.
L'opération est on ne peut plus simple, chargement de chaque fichier sous forme de variable, correction de bêtises de l'ONISR, et appariement.
L'étape de filtre par localisation via la variable `dep` permet à partir des 55302 évènements ayant eu lieu courant 2022 d'en conserver 356 sur le Doubs. Filtrer à cette étape implique une surcharge aux étapes précédentes, mais me permet d'écrire moins de lignes.
Par curiosité, j'ai ajouté une étape ici pour connaître le nombre global d'évènements qui m'intéressent, impliquant piéton, cycle, ou EDP. Il y en a 131 recensés.
La fonction d'import uMap est relativement simple, il suffit d'insérer un fichier csv, son URL, ou directement son contenu pour que les données apparaissent sur une couche pour peu que les champs lat et long existent. Eeet on remarque une erreur, tous les évènements sont distribués en trois points uniques. Il ne m'a pas fallu longtemps pour comprendre que uMap demande à ce que les caractères séparateurs dans les coordonnées soient des points et non des virgules. L'opération est assez simple pour être réalisée via un tableur, un peu plus complexe via un éditeur de texte étant donné que la virgule sert également de séparateur de valeurs. Ne me demandez pas comment j'ai réussi à faire la substitution ; J'ai pris un morceau de code qui traînait, mes tentatives me modifiant le format des données.
À cette étape les données sont humainement « exploitables », mais pourraient bénéficier d'une quelques modifications des valeurs pour gagner en lisibilité. Une chose importante est que uMap ne dispose pas de fonction de filtre[7] ce qui rend assez compliqué d'explorer des données cartographiques avec plus d'une variable (en jouant sur la forme). À défaut, ma solution de fortune a été de diviser par moyen de déplacement, de sorte à créer trois couches à opacité réduite au cas où des points seraient superposés.
-- Response ended
-- Page fetched on Sun May 19 03:28:13 2024