search

MTES-MCT / dialog

Intégration de la réglementation de circulation dans les solutions numériques
https://dialog.beta.gouv.fr
GNU Affero General Public License v3.0
9 stars 0 forks source link

Intégrer les données BAC IDF dans DiaLog #456

Closed johanricher closed 6 months ago

johanricher commented 1 year ago

Contexte

La base de données commune pour les arrêtés de circulation et de stationnement en île-de-France (BAC IDF) était un projet antérieur à DiaLog avec le même objectif. En 2023, il a été racheté par la DGITM, pour la partie financée par l’IDF, afin de fusionner avec DiaLog.

Critères d'acceptation

Questions

Prochaines étapes

Implémentation

Prérequis

Intégration

MathieuFV commented 1 year ago

J'ai reçu aujourd'hui le dump de la base de données comme je l'avais demandé avant mon départ en congés. Le fichier zippé ne pèse que 830ko... A voir ce que l'on y trouve, on peut au moins regarder la structure des données. J'attends d'autres éléments de la part des équipes de BAC IDF, notamment le schéma de base de données et les adresses/clés des éventuelles APIs qui permettraient de capter directement leurs données.

Le fichier est stocké ici avec d'autres ressources issues de BAC IDF.

florimondmanca commented 10 months ago

J'ai inspecté le dump cet après-midi. C'est un dump MongoDB au format BSON (JSON binarisé optimisé, ce qui explique la petite taille du dump).

La collection "decrees" contient 621 arrêtés.

J'ai ingéré et réexporté les données en JSONL à l'aide de ceci :

# docker-compose-bacidf.yml
version: "3.8"

services:
  mongo:
    image: mongo:7.0.2
    restart: always
    environment:
      MONGO_INITDB_ROOT_USERNAME: dialog
      MONGO_INITDB_ROOT_PASSWORD: dialog
    volumes:
      - ./docker/bacidf/data:/etc/bacidf/data
$ docker-compose -f docker-compose-bacidf.yml up -d
$ docker-compose -f docker-compose-bacidf.yml exec mongo bash
> mongorestore -d bacidf -c decrees /etc/bacidf/data/decrees.bson -u dialog -p dialog --authenticationDatabase admin
> mongoexport -d bacidf -c decrees -o /etc/bacidf/data/decrees.jsonl mongodb://localhost:27017 -u dialog -p dialog --authenticationDatabase admin

Puis petit script Python pour reconvertir le JSONL en JSON (liste d'objets)

# docker/bacidf/process.py
import json
from pathlib import Path

with (Path(__file__).parent / "data" / "decrees.jsonl").open("r") as f:
    items = [json.loads(line) for line in f.readlines()]
    (Path(__file__).parent / "data" / "decrees.json").write_text(json.dumps(items))
python3 docker/bacidf/process.py

Le résultat est stocké sur le kDrive (16 Mo).

Je vais maintenant regarder plus en détail le schéma des données BAC IDF

florimondmanca commented 10 months ago

Commentaires en vrac

MathieuFV commented 10 months ago

Cette évolution de la localisation vers des polylignes est également ce que demanderaient les GPS (Waze et TomTom dans leurs retours), si j'ai bien suivi. On aura sans doutes par la suite à stocker également des géométries en polygones, par exemple pour les ZFE, ça plaide plutôt pour l'option avec l'attribut geometry qui semble plus versatile, non ?

florimondmanca commented 10 months ago

Aperçu des données

Il y a 621 arrêtés dans le dump

Avec la première ébauche dans le commit https://github.com/MTES-MCT/dialog/pull/502/commits/5a893918ece30563cda88303e5d82fd7e432a32c j'ai pu intégrer 214 arrêtés permanents

Cette 1ère ébauche ignore :

Notes d'implémentation

J'ai repris l'essentiel de la logique ETL (extract, transform, load) du connecteur Eudonet.

Ce n'est pas si surprenant car l'ETL est un pattern très répandu et solide.

Peut-être qu'on pourra "abstraire" tout ça dans le futur, ou utiliser une lib comme FlowPHP (pas sûr que ça nous facilite la vie car ça rajouterait une dépendance, il faudrait minutieusement regarder son état, sa maintenance, etc).

MathieuFV commented 10 months ago

Plusieurs remarques qui découlent de ce que tu présentes :

1° Il va falloir changer notre manière de stocker la localisation pour disposer de géométries plus complètes en polygones et polylignes. Ca pose la question de l'outil et du référentiel qu'on utilisera pour obtenir ces données. Est-ce que la BAN et Addok permettent de le faire ?

2° On va aussi avoir besoin d'indexer la voirie d'autres manières qu'en utilisant uniquement les adresses. On voit que les POI seraient intéressants (les places, les ronds point, etc.). On a aussi besoin de gérer les points kilométriques du réseau structurant.

Donc : 2-1° Y-a-t-il un outil de géocodage qui permettrait de taper dans plusieurs bases de données afin de permettre aux utilisateurs de déclarer des localisations en utilisant plusieurs repérages différents ? Addok permet-il de le faire (je crois qu'on a déjà évoqué ça au moins oralement) ? 2-2° Quelles bases de données interroger ? On a la BAN, on avait aussi un POC sur les intersections de rues, il nous manquerait au moins les POI et les PK/PR. Pour ce dernier l'IGN semble être une première piste mais j'ai du mal à les mobiliser... 2-3° Quelle UX pour localiser nos restrictions de toutes ces manières différentes ?

3° S'agissant des critères véhicules, peut-on faire l'analyse de ce qui est renseigné dans BAC IDF afin de voir où nous serions potentiellement incomplets dans DiaLog ?

4° Sur les horaires : Si l'exemple est représentatif, ils ont fait le choix de la simplicité. On ne peut que déclarer des période et des heures si je comprends bien. Ca tient aussi beaucoup au fait que ce ne sont que des arrêtés permanents.

5° Il serait intéressant de regarder la liste des attributs des arrêtés de stationnement pour commencer à réfléchir sur ce que l'on peut faire de notre côté là-dessus. On peut aussi regarder ce qui existe dans Eudonet.

florimondmanca commented 10 months ago

1° Il va falloir changer notre manière de stocker la localisation pour disposer de géométries plus complètes en polygones et polylignes

Disons plutôt qu'on ne peut stocker qu'une version apauvrie de ce qu'on peut trouver dans BAC-IDF. (Toutes les localisations ne sont peut-être pas aussi détaillées, je me suis basé sur 3 exemples jusqu'ici)

Il n'y a donc pas de "nécessité" sauf si les GPS nous pressent pour avoir un linéaire détaillé, mais ce serait un sujet différent de ce ticket

2° On va aussi avoir besoin d'indexer la voirie d'autres manières qu'en utilisant uniquement les adresses.

Oui et on a toujours des sujets ouverts dans ce domaine. Notamment #419 : pour l'instant on démarre un Addok en local avec les données BAN + intersections OSM pour les besoins du géocodage Eudonet notamment. Mais il n'y a aucune UI correspondante pour l'instant, et en prod le géocodeur est uniquement l'API Adresse.

On voit que les POI seraient intéressants (les places, les ronds point, etc.).

Selon moi il faut discuter de la pertinence de traiter rapidement le cas des places et des ronds-points : est-ce qu'il y a une problématique "concrète" à résoudre dans ce cas-là, par ex est-ce qu'on a des poids lourds qui bloquent des places... ? Je ne suis pas sûr

On a aussi besoin de gérer les points kilométriques du réseau structurant.

Je vais continuer l'analyse des arrêtés dans BAC-IDF et je regarderai s'il est fait référence à des PR (points de repères), ou s'il n'y a que des données "absolues" (coordonnées lat/lon). Dans le 2nd cas, la question des PR serait séparée de ce ticket.

4° Sur les horaires : Si l'exemple est représentatif, ils ont fait le choix de la simplicité. On ne peut que déclarer des période et des heures si je comprends bien. Ca tient aussi beaucoup au fait que ce ne sont que des arrêtés permanents.

Leur modèle semble compatible avec notre modèle "Certains jours" (jours de la semaine avec des créneaux horaires valable pour chaque jour choisi) (cc #455)

florimondmanca commented 10 months ago

Suite au daily du jour

Proposition de solution provisoire : avancer en prenant le 1er et le dernier point du linéaire.

florimondmanca commented 8 months ago

Mise à jour :

Grâce à #543 on devrait pouvoir reprendre l'intégration des données BAC-IDF dont les localisations sont au format GeoJSON.

florimondmanca commented 8 months ago

Petit problème rencontré en essayant d'intégrer les données véhicules des arrêtés BAC-IDF

TL;DR : faudrait-il que les champs poids / largeur / longueur / hauteur maximum s'affichent dans tous les cas, sans avoir à sélectionner un type de véhicule concerné ?

cc @aureliebaton @MathieuFV

Voilà pourquoi :

Les données véhicules BAC-IDF contiennent par exemple le PTAC max, les dimensions max... Donc on peut avoir une mesure disant : Longueur MAX = 10m

Mais il n'y a aucun champ "véhicules concernés" et a fortiori rien qui indique que la mesure vise spécifiquement "les poids lourds"

Or dans l'interface pour faire apparaître les caractéristiques max, il faut cliquer sur "véhicules concernés" puis choisir "poids lourds" :

Screenshot 2023-12-21 at 14-41-32 Arrêté temporaire F02_TEST (copie) - DiaLog

Côté modèle de données, ça se traduit par le fait que pour pouvoir enregistrer une largeur maximale (champ heavyweightMaxWidth), il faut avoir mis $allVehicles = false ET avoir mis au moins une valeur dans $restrictedTypes.

florimondmanca commented 8 months ago

^Pour contourner ça et avancer j'ai indiqué que la mesure concernait uniquement les poids lourds dès lors que le poids ou une dimension est indiquée dans l'arrêté BAC-IDF... En mettant le poids max à 3.5 tonnes même si aucun n'est défini dans l'arrêté (car le poids max est considéré comme obligatoire par DiaLog).

Bref, de la bidouille

Ce qu'il faudrait envisager de changer selon moi :

Ça serait aligné DATEX II, car dans DATEX II les champs tels que 'vehicleType' ("type de véhicule concerné") ou 'grossWeightCharacteristic' ("poids maximum") sont des propriétés de VehicleCharacteristics qui peuvent être remplis indépendamment les unes des autres.

Edit : on peut en discuter sur #582

florimondmanca commented 8 months ago

@MathieuFV Voici la liste des communes qui ont un arrêté de circulation dans BAC-IDF

city_code city_label
77251 Lieusaint (77127)
78208 Élancourt (78990)
78490 Plaisir (78370)
78498 Poissy (78300)
78551 Saint-Germain-en-Laye (78100)
91661 Villebon-sur-Yvette (91140)
92012 Boulogne-Billancourt (92100)
92048 Meudon (92190)
92049 Montrouge (92120)
92073 Suresnes (92150)
92075 Vanves (92170)
93027 La Courneuve (93120)
93029 Drancy (93700)
93031 Épinay-sur-Seine (93800)
93045 Les Lilas (93260)
93048 Montreuil (93100)
93059 Pierrefitte-sur-Seine (93380)
93070 Saint-Ouen-sur-Seine (93400)
93079 Villetaneuse (93430)
94021 Chevilly-Larue (94550)
94028 Créteil (94000)
94041 Ivry-sur-Seine (94200)
94054 Orly (94310)
95127 Cergy (95000)
95127 Cergy (95800)
95306 Herblay-sur-Seine (95220)

(26 rows)

MathieuFV commented 7 months ago

Hello, la liste des communes est entrée dans DiaLog. Cergy n'apparait qu'une fois (forcément), il faudra peut être nous assurer que les arrêtés BAC IDF référencés aux deux codes postaux 95 000 et 95 800 soient rattaché à Cergy.

MathieuFV commented 7 months ago

Coucou ! Voici le schéma que j'ai pu extraire des données BAC IDF. Garder en tête que c'est une interprétation, j'ai artificiellement créé des tables avec leurs id/clés pour montrer les ramifications. Je devrais aller sur BAC IDF pour vérifier ce qu'il y a dans les enums et voir si je ne me suis pas trop trompé, mais je crois que c'est un bon point de départ. J'ai pu faire des erreurs notamment dans les liens entre les tables (1-1 ou 1-n).

https://dbdiagram.io/d/Aires-de-livraison-636a0adec9abfc6111710074

Je retiens qu'ils ont une logique similaire à nous : Un arrêté est lié à des mesures (REG_CIRCULATION) - qui peut d'ailleurs concerner la circulation et le stationnement - ces mesures sont rattachées à des voies (REG_VOIES).

A noter que les véhicules concernés et exemptés sont rattachés directement à l'arrêté et pas à des mesures individuelles, ce qui est logique dans la mesure où BAC IDF était focalisé sur la réglementation du transport de marchandises, donc avec des arrêtés qui s'adressent à des classes de véhicules. Pour nous c'est moins pratique, on peut trouver des arrêtés qui parlent à la fois aux poids lourds et à tous les véhicules.

A préciser dans les prochaines étapes...

florimondmanca commented 7 months ago

A noter que les véhicules concernés et exemptés sont rattachés directement à l'arrêté et pas à des mesures individuelles,

Non ce n'est pas ce que j'ai vu ?

Les véhicules sont dans les propriétés des objets REG_CIRCULATION qui représentent effectivement des mesures au sens de DiaLog

Ils ne sont pas directement des propriétés de l'arrêté

Pour le reste j'ai la même conclusion, leur modèle de données ressemble beaucoup au nôtre une fois l'inversion faite #577

florimondmanca commented 6 months ago

Dans les données BAC-IDF, un type de véhicule exempté qui revient souvent c'est "véhicules de services".

Dans les exemptions "autres", on retrouve aussi les véhicules de déménagement qui ont pour équivalent DATEX la valeur removals. Mais c'est souvent en texte libre, par exemple "véhicules de déménagement justifiant d'une dérogation", alors que les valeurs non-autres sont standardisées (par exemple "SECOURS" ou "VEHICULES DE SERVICES"). Donc pas évident à extraire.

MathieuFV commented 6 months ago

Les véhicules sont dans les propriétés des objets REG_CIRCULATION qui représentent effectivement des mesures au sens de DiaLog

En effet il faut considérer REG_CIRCULATION comme nos "mesures"... Je me relis aujourd'hui mais ne sais plus pourquoi j'en étais arrivé à cette conclusion...

Au sujet des "véhicules de service" la solution que tu proposes semble correcte, j'ai demandé confirmation à l'équipe de BAC IDF.

Ca voudrait dire que l'on regroupe dans une même catégorie les transports en commun et les véhicules de service, ce qui ne me paraît pas gênant, à voir ce que l'on veut faire de cette nouveauté en termes d'UX ? @aureliebaton

florimondmanca commented 6 months ago

Suite au daily de ce matin j'ai rajouté le critère d'acceptation:

(Must have) Les arrêtés doivent être rattachés à l'organisation correspondante (cf liste https://github.com/MTES-MCT/dialog/issues/456#issuecomment-1866382032)

Signalé par @MathieuFV

En effet dans l'état actuel de #502 l'organisation où sont intégrés les arrêtés est fixée (j'ai utilisé DiaLog sur staging), mais c'est vrai que ça n'a pas de sens de tout intégrer dans "Ville de Paris" par exemple.

cc @johanricher

florimondmanca commented 6 months ago

@MathieuFV Il y a un frein à cette correspondance automatique : trouver le SIRET d'une commune à partir de son code Insee. Cf https://github.com/MTES-MCT/dialog/pull/502#discussion_r1486446169

Les 9 premiers chiffres du SIRET correspondent au SIREN, ce qu'on peut récupérer via le découpage administratif (nécessite de stocker ça dans notre table fr_city).

Les 5 derniers chiffres sont le "NIC" et c'est comme ça qu'on différencie les établissements au sein d'une commune (si j'ai bien compris). Je ne sais pas comment récupérer le NIC de la commune ; il varie. Par ex Valenciennes => NIC = 00018 mais La Courneuve => NIC = 00012

Options

L'option :star: aurait ma préférence, sous l'hypothèse que la liste de communes dans Bac-IDF n'évolue pas trop (?).

florimondmanca commented 6 months ago

Autre option @MathieuFV Demander à Bac-IDF s'ils peuvent ajouter le SIRET dans les données

johanricher commented 6 months ago

Je pense aussi après réflexion qu'on n'aura probablement pas besoin d'un système automatisé pour inférer le SIRET d'une commune à partir de son code INSEE. Le SIRET sera enregistré lors de la création d'une compte d'une organisation dans DiaLog, donc le seul cas où on n'aura pas de SIRET c'est comme ici quand on fera de l'intégration de données. Or, on intégrera rarement des données de plusieurs communes à la fois et si, ça arrive, les récupérer à la main comme ici (26 communes) n'est pas suffisament chronophage pour justifier une automatisation.

Si BAC-IDF ne peut pas donner rapidement cette info je le ferais.

MathieuFV commented 6 months ago

J'ai demandé au dev de BAC IDF s'il était possible de passer au SIRET de leur côté, si ça peut nous permettre d'aller plus vite.

Par ailleurs il m'a renvoyé la liste des choix possibles pour les exemptions de leur côté (voir image).

TLDR : Je réfléchis à propos des catégories qu'on peut proposer dans "Certains véhicules" et "Sauf..." dans DiaLog en croisant BAC IDF, DATEX, le Code de la Route et l'IISR (guide de la signalisation routière).

ValeursExceptionsBACIDF

C'est un peu bizarre, trouve-je. Pour moi par exemple la catégorie "Véhicules de services" couvre "Transport de déchets", il n'y a pas de catégorie "Transport en commun" pourtant je l'ai déjà vu de manière certaine dans un arrêté, la distinction entre "Police" et "Secours" n'est pas tout à fait claire pour moi, etc.

Je crois que cette liste a été construite pour correspondre à ce qui avait été trouvé parmi une liste d'arrêtés, autrement dit c'est une logique "sémantique" et pas quelque chose prévu pour être communiqué à des tiers comme les GPS. Ce qui nous laisse avec DATEX, dans l'enum "VehicleUsageEnum" on a les catégories suivantes (Je remets les catégories avec une proposition - tout à fait personnelle - de traduction) :

Ca pose deux questions :

1° Quelles catégories on veut proposer dans DiaLog ? 2° Comment on fait la correspondance de BAC IDF dans DiaLog ?

Sur la première question :

La première chose c'est je crois de savoir si ces catégories DATEX ont un pendant dans le code de la route. J'ai donc tapé la traduction de la catégorie + code de la route dans Google (préparez vous à entrer dans le temple du fun)...

EDIT : J'ai aussi été voir dans l'IISR qui est le guide de référence sur la signalisation routière en France. A noter : Dans l'IISR les panonceau (petits panneaux sous les gros panneaux...) qui caractérisent les "Types de véhicules" tombent dans la catégorie M4. C'est une bonne manière de vérifier si une catégorie de véhicule est utile dans DiaLog puisqu'il y a toujours une signalisation associée à une réglementation (sinon on comprend rien!).

A savoir : Dans le Code de la Route, les catégories de véhicules sont fixées par l'article R221-4.

Engins agricoles : Il n'y a pas de mention spécifique aux engins agricoles dans le R221-4, en gros un tracteur seul = catégorie B (comme une voiture), ou une catégorie de véhicule avec attelage : BE pour une remorque de mois de 750kg et C1E si elle dépasse 750kg. MAIS : on trouve plus tard dans le Code de la Route l'article R221-20 qui fait, lui, mention des engins agricoles. L'idée est que cet article donne un régime spécifique de restrictions pour les engins agricoles affectés à une exploitation (en gros ceux qui sont en train d'être utilisés pour travailler et qui ne sont pas juste en transit). Ca abaisse notamment l'âge minimum pour conduire un tracteur seul à 16 ans (18 s'il y a une remorque). BREF : les engins agricoles existent bel et bien dans le Code de la Route. On trouve aussi un symbole "Véhicule agricole" sur le panonceau M4i et le panneau d'interdiction B9d.

CONCLUSION : on peut proposer cette option dans les véhicules concernés ou exemptés sur DiaLog.

Covoiturage : Encore une fois, nada dans le R221-4. Mais ce qui est sûr c'est qu'il existe des voies réservées au covoiturage. C'est clairement quelque chose qu'on souhaite avoir dans DiaLog puisque ça permettrait aux GPS de le signaler.

CONCLUSION : a mon sens c'est utile de proposer l'option "Covoiturage".

A noter que ce sont des voies réservées, dans la logique actuelle sous DiaLog on renseignerait donc "Circulation interdite" puis "Pour tous les véhicules" puis "Sauf le covoiturage". NOTA : C'est déjà possible aujourd'hui. Une autre option serait d'ajouter dans les types de restriction la mention "Voie réservée", ce qui forcerait le choix de "Certains véhicules", et on pourrait ensuite choisir "Covoiturage".

Logistique : Dans l'article R221-4 la distinction entre véhicules est fondée sur leurs dimensions et poids, donc pas vraiment de mention du transport de marchandises. A noter que la catégorie C (= poids supérieur à 3,5t et remoque d'un poids maxi de 750kg) est celle qui est implicitement reconnue comme la catégorie à laquelle correspond la plupart des véhicules de logistique. Dans l'IISR on trouve en revanche un panneau B8 et un panonceau M4g qui s'adressent spécifiquement aux "véhicules affectés au transport de marchandises".

Ca entraîne une autre question : Est-ce que ce panneau peut être utilisé seul ou bien est-il toujours accompagné d'une limite de poids ou de gabarit ? Et la réponse semble être qu'il est possible de le voir seul (on interdit la circulation à tous les véhicules qui transportent des marchandises, y compris les petits utilitaires). Voir ce wiki: "Ce panneau utilisé seul ne comporte aucune notion de minimum de tonnage, il concerne tous les véhicules répertoriés comme "utilitaires" sur la carte grise, c'est-à-dire que cela inclut ceux d'un PTAC inférieur à 3,5 tonnes et dont la case J.1 de la "carte grise" comporte "CTTE". "

CONCLUSION : Il me semble qu'avoir une chip "Marchandises" dans DiaLog (avec un camion en picto) serait utile, pour porter les interdictions de circulation spécifiques à ces véhicules sans pour autant être obligé de préciser leur poids ou gabarit.

Véhicules de service : Même topo, le R221-4 ne fait pas de distinction d'usage des véhicules (à part pour le transport en commun avec la catégorie D). En revanche, je me rends compte qu'il y a peut être un quiproquo... Dans la question initiale de @florimondmanca il y avait un lien vers le site saisirprudhomme, on y parle des "Véhicules de service" au sens des voitures de services que certains employés peuvent utiliser dans le cadre de leur activités salariées. Si on se place plutôt du côté d'un gestionnaire de voirie, la notion de véhicule de service est bien entendu différente et fait plutôt référence (me semble-t-il) aux véhicules de service PUBLIC type ramassage des ordures ménagères, entretien. Mais il n'y a aucune réelle définition de cet ensemble de véhicules, et en cherchant les panneaux associés on n'en trouve pas dans l'IISR, par contre les sites qui en vendent précisent qu'ils ne sont à utiliser que sur des voies privées. Curieux.

CONCLUSION : J'ai l'impression que les arrêtés qui interdisent l'accès "sauf véhicules de service" ne sont pas légaux...

Je serais intéressé de voir un exemplaire d'arrêté qui fait mention de ça pour voir où l'interdiction a lieu. Dans l'attente je pense qu'il ne faut pas intégrer cette catégorie dans les propositions que l'on fait aux utilisateurs DiaLog...

Secours : Rien dans le Code de la Route à ce sujet... Côté panneaux, pas plus, et de la même façon que pour les véhicules de service les sites qui vendent ces panneaux précisent qu'il ne peuvent être utilisés que sur des voies privées. En bref, sur des voies du domaine public il n'y pas d'accès réservé aux véhicules de secours, ceux qui bénéficient de facilités de passages (avec un gyrophare) ont la priorité de fait.

**CONCLUSION : J'ai encore l'impression que cette option n'est pas utile, de même que celle que nous avons proposé "Véhicules d'urgence" dans les véhicules exemptés et je me demande si c'est vraiment utile. Car de fait les véhicules d'urgence ont droit de rouler là où les autres ne peuvent pas (je crois?). A voir ce que l'on fait de cette catégorie DATEX, peut être qu'on peut trouver des exemples de données qui en font usage ?

Véhicules militaires : Ici il n'y ni mention particulière dans le Code de la Route, ni de panneau particulier.

CONCLUSION : Rien à prévoir dans DiaLog à priori.

Véhicules Particuliers : Pour moi il s'agit du tout venant, qui se définit plutôt par opposition avec les véhicules "commerciaux", ou ceux qui sont utilisés pour des déplacements de "loisir".

CONCLUSION : Rien à prévoir, contenu dans la catégorie "tous les véhicules"

Patrouille : Pas de panneau dans l'IISR, de plus la notion de "Patrouille" est peu utilisée en France (peut être plus à l'étranger) et je ne pense pas que l'option sera vraiment utile à quoi que ce soit...

CONCLUSION : Dismissed, sauf si on nous en fait une demande spécifique.

Dépannage : idem

CONCLUSION : Idem

Véhicules de chantier : Plus courant de voir des interdiction "sauf chantier" il me semble, mais encore une fois il s'agit d'une réglementation qui ne peut exister que sur des voies privées, pas dans le domaine public routier.

CONCLUSION : A priori pas utile de proposer l'option dans DiaLog.

Véhicules du gestionnaires de voirie : De même, ces derniers ont droit de circuler partout et l'interdiction de circuler à l'exception de ces véhicule ne peut exister que sur des voies privées...

CONCLUSION : Idem

Taxi : Ici il existe le panonceau M9z spécifique aux "taxis et bus" et reconnu dans l'IISR.

CONCLUSION : Il faut garder l'option "Sauf taxi", j'aurais tendance à laisser séparés "bus" et "taxi" en revanche car il existe des voies réservées aux transports en commun. L'utilisateur ajoutera "taxi" si ces derniers sont les bienvenus.

Ouverture : Malgré cette fine analyse, le maire peut toujours interdire la circulation a qui bon lui semble par arrêté motivé, c'est le résultat de l'article 2213-4 du CGCT (voir notamment ici ). Nonobstant, ce genre de porte ouverte peut nous rendre la vie impossible, car cela laisse la possibilité d'interdire à tous types et usages de véhicules ("interdit sauf les tricycles électriques rouges qui transportent du lait entier").

Il est donc bon de réfléchir aux catégories que l'on propose à nos utilisateurs. Il me semble que celles qui sont actuellement disponibles sont déjà très suffisantes, et si certains demandent à ce que l'on en ajoute on pourra revenir sur ce commentaire pour nous aider à décider, j'espère.

MathieuFV commented 6 months ago

BAC IDF a mis en place un endpoint pour accéder à leurs données, je relaie ici leur message :

Nous avons déployé l'API de récupération qui permettra à votre système d'obtenir tout nouveau arrêté, en utilisant le dernier identifiant de notre base de données (_id), ou de commencer à partir de 0 par lot. J'ai joint le document avec l'endpoint et les paramètres qui peuvent être utilisés (page 3). Il est publié à l'adresse https://staging.bacidf.fr/api/decrees/new. J'ai testé avec notre système de mise à jour programmée (celui qui collectera les données depuis votre API) et il envoie les informations qui sont sur le serveur de Staging. Ainsi, vous pouvez le tester de votre côté puis le déployer en production.

Maintenant, il ne nous manque plus que la méthode de mappage entre la Structure de Dialogue et la structure BAC-IDF pour terminer l'intégration.

Question : Avons-nous un moyen de leur transmettre le script d'intégration des données BAC IDF dans DiaLog ? Je crois que ça les aiderait à faire la réciproque de DiaLog à BAC IDF.

MathieuFV commented 6 months ago

La documentation de l'API BAC Description technique API Dialog_fr.docx

florimondmanca commented 6 months ago

@MathieuFV Merci pour le doc

Il confirme que BAC-IDF a l'intention de devenir réutilisateur des données DiaLog : ils aimeraient réintégrer les arrêtés qui proviennent d'ailleurs que BAC-IDF

Ça vaudrait peut-être son propre ticket / exploration

D'une manière générale je dirais que le DATEX doit être LA façon pour une personne tierce d'accéder aux données (on a publié l'endpoint datex sur datagouv)

Mais ils vont avoir besoin d'un filtre sur la source

Si votre modèle peut filtrer toutes les données qui ont notre API comme source, nous vous en serons reconnaissants.

Il faudrait voir si DATEX a des prescriptions sur comment implémenter ce filtre, sinon on peut imaginer quelque chose comme ?source_exclude=['bac_idf']. Et il faudra trouver un moyen de documenter ça...

MathieuFV commented 6 months ago

Ok merci pour ces précisions, en tout cas on a des choses plus prioritaires pour le moment il me semble pour le moment.

florimondmanca commented 6 months ago

Table de correspondance code Insee <-> SIRET (obtenu par recherches sur https://annuaire-entreprises.data.gouv.fr/) :

city_code city_label siret
77251 Lieusaint (77127) 21500270000015
78208 Élancourt (78990) 21780208100018
78490 Plaisir (78370) 21780490500016
78498 Poissy (78300) 21780498800012
78551 Saint-Germain-en-Laye (78100) 20008692400012
91661 Villebon-sur-Yvette (91140) 21910661400072
92012 Boulogne-Billancourt (92100) 21920012800011
92048 Meudon (92190) 21920048200012
92049 Montrouge (92120) 21920049000015
92073 Suresnes (92150) 21920073000014
92075 Vanves (92170) 21920075500011
93027 La Courneuve (93120) 21930027400012
93029 Drancy (93700) 21930029000018
93031 Épinay-sur-Seine (93800) 21930031600011
93045 Les Lilas (93260) 21930045600015
93048 Montreuil (93100) 21930048000015
93059 Pierrefitte-sur-Seine (93380) 21930059700016
93070 Saint-Ouen-sur-Seine (93400) 21930070400018
93079 Villetaneuse (93430) 21930079500123
94021 Chevilly-Larue (94550) 21940021500014
94028 Créteil (94000) 21940028000018
94041 Ivry-sur-Seine (94200) 21940041300015
94054 Orly (94310) 21940054600269
95127 Cergy (95000) 21950127700897
95306 Herblay-sur-Seine (95220) 21950306700015