Pouvoir charger les données DiaLog dans un logiciel GIS

[florimondmanca]

User story

ETQ utilisateur d'un progiciel GIS propriétaire, je dispose d'une API standard et bien outillée pour réutiliser les données fournies à ce progiciel

• Exemple : ETQ responsable GIS de la Mairie de Lille, je veux récupérer les données que j'ai saisies dans Litteralis (l'accès et l'utilisation du WFS me sont difficiles)

ETQ membre de la communauté GIS (par ex OpenStreetMap, logiciels libres de cartographie / itinéraires, etc), je dispose d'un moyen courant de récupérer les données de DiaLog (DATEX II n'est pas considéré comme "courant" car nécessite un parser côté client)

Critères d'acceptation

• (Must have) Pouvoir charger les données DiaLog dans QGIS

Implémentation

Contenu des données exposées

On expose des restrictions (notion distincte des mesures, localisations, périodes : c'est l'application d'une mesure sur une unité de lieu et une unité de temps)

• Géométrie (brute)
• Type de restriction (circulation interdite, limitation de vitesse)
• Date de début
• Date de fin
• Véhicules concernés
• Localisation
  • NamedStreet
    • cityLabel
    • cityCode
    • street
  • NumberedRoad
    • roadName
    • roadNumber
    • administrator (gestionnaire)
    • fromPointNumber
    • fromAbscissa
    • fromSide
    • toPointNumber
    • toAbscissa
    • toSide
  • RawGeoJSON
    • label

Solution d'implémentation de l'API

Utiliser pg_featureserv, comme exploré dans #974

pg_featureserv est une implémentation en Go de serveur d'API respectant le standard "OGC API Features" (NB : attention aux abus de langage, "OGC API" est un standard regroupant une dizaine d'APIs différentes, Features n'étant qu'une d'entre elles - cf https://ogcapi.ogc.org/#standards)

Contexte supplémentaire

• cf POC : Création d'un endpoint WFS / OGC API Features #974

Un chef de projet refonte GIS de la Mairie de Lille nous a signalé l'intérêt que pourrait représenter la mise à disposition des données sous le format standard OGC API Features (successeur de WFS)

Le cas d'usage est de récupérer en open data les données saisies dans le logiciel propriétaire Litteralis, y compris pour des collègues de services qui n'ont pas directement accès au WFS de Litteralis. (Lui-même a indiqué avoir des difficultés à accéder au WFS du Litteralis de la Mairie de Lille. NB : à ce jour la Mairie et la MEL ont un Litteralis chacun, qui ne communiquent pas.)

Pour cela les données fournies par DiaLog doivent être sous un format le plus brut possible (les polygônes), notamment au niveau de la géométrie (pas de post-traitement des polygônes), afin de refléter les données saisies. Les squelettes actuellement calculés pour les besoins du CIFS ne sont pas adaptés et pourraient d'ailleurs être confondus avec le réseau routier alors que ce sont des approximations qui ne correspondent à aucun référentiel.

(=> Conséquence : il faudrait déporter le post-traitement des polygônes pour qu'il soit uniquement fait pour l'export CIFS (techniquement, il faudrait créer une vue qui convertirait les polygônes en squelettes) - Ticket dédié à prévoir)

Le déversement dans l'écosystème OpenStreetMap lui semblait bénéfique et serait facilité par l'usage d'un format aussi courant que l'OGC API Features.

Le contact à la Mairie de Lille nous a conseillé de passer par la Géoplateforme pour l'hébergement. Selon la GeoPF pourrait moissonner notre flux et les clients requêteraient alors la version hébergée par la GeoPF (qui s'occupe du cache etc). Notamment en vue d'une montée en charge.

[johanricher]

Il me semble que ça a la même intention que #200 mais on avait décidé que cet ancien ticket devait être exploré pour préciser le besoin, il me semble qu'aujourd'hui grâce à ce contact on avance justement sur l'exploration.

Il me semble pas que "OGC" soit un format SIG contrairement à GeoJSON ou Shapefile, par exemple. "API standard" ou "user friendly" est trop vague également. Donc j'aimerais que la terminologie soit clarifiée mais surtout qu'on parte du besoin et de la finalité, ici il s'agirait de : télécharger les données de Dialog avec les géométries (et certainement d'autres propriétés à préciser).

Par exemple :

Pouvoir télécharger un fichier au format GeoJSON contenant toutes les données de DiaLog serait un cas d'usage.

Pouvoir télécharger un fichier au format GeoJSON correspondant à un arrêté spécifique (identifié par son ID) ou à une recherche ciblée, serait deux autres cas d'usages.

[florimondmanca]

Oui le périmètre de #200 est différent de ce ticket / du cas d'usage souhaité par la Mairie de Lille

#200 semblait se restreindre à une organisation donnée, ce ticket est plutôt dans une logique open data => Pouvoir accéder aux arrêtés publiés par d'autres organisations dont j'aimerais consulter la donnée réglementaire, en pouvant m'appuyer sur les logiciels classiques d'exploration de données géographiques (logiciels SIG != format SIG)

Donc le cas d'usage ne me semble pas être exactement parmi ceux que tu as proposé en exemple

Par rapport à GeoJSON, le téléchargement d'un GeoJSON ou la mise à dispo d'une API OGC seraient deux façons de permettre "d'accéder à la donnée"

Mais ces deux approches sont de nature différente :

• Le GeoJSON n'est qu'un format de fichier, il est "statique". Si on produit un GeoJSON avec "toutes les données DiaLog" (ou même juste pour une orga / un arrêté), il faut d'une part le fabriquer, d'autre part gérer son acheminement depuis le serveur jusqu'à un client (exemple : fabrication puis hébergement d'un fichier statique, avec les questions de mise en cache, compression, performance, etc). Une fois chargé dans un logiciel SIG, les possibilités de "requêtage" peuvent varier en fonction du logiciel.
• L'OGC API Features est un standard de service web, qui s'appuie sur le GeoJSON comme format d'échange, mais vient avec un standard de service web et de requêtage que tous les logiciels SIG compatibles partageront (QGIS, ArcGIS, etc), et avec des solutions sur étagère qui interrogent directement PostGIS.

Dans les 2 cas il faut décider des champs qu'on expose, mais en termes de mise en service la fabrication et l'hébergement de fichiers GeoJSON "par nous-mêmes" serait peut-être + coûteuse, paradoxalement

[johanricher]

D'accord, le contact de la Mairie de Lille parle d'une API mais je me demande si cela n'est pas une approche solutionniste car il ne précise pas la finalité. A ce stade de ma compréhension, rien ne me permet de dire que des données (fichiers statiques disponibles au téléchargement, plutôt qu'une API) ne serait pas un moyen valide de répondre à son besoin.

Sur l'approche API vs données et pourquoi prévilégier l'une au détriment de l'autre peut poser problème : https://cq94.medium.com/les-api-cest-bien-en-abuser-ca-craint-b5d1c92b32f2

Une diffusion de fichiers téléchargeables, si possible historisés est très complémentaire d’une diffusion par API et permet d’autres types de réutilisations que celles envisagées par les services proposés par l’API. (...)

Dans certains cas, une API offre un service à valeur ajoutée sur des données brutes disponibles par ailleurs. Par exemple l’API de géocodage proposée sur adresse.data.gouv.fr permet de tirer parti de la Base Adresse Nationale de façon bien plus utile que le simple accès aux fichiers de référence.

Ceux-ci sont bien entendu disponibles en téléchargement, sans passer par l’API pour permettre d’autres usages ou services que ceux proposés car une API ne peut pas être assez universelle pour prévoir tout type d’usage et de réutilisation des données… ou alors elle devient une usine à gaz.

[florimondmanca]

Merci pour l'article

Est-ce que la conclusion serait qu'une diffusion par fichier historisé serait complémentaire d'une diffusion par API "d'exploration" ?

En effet Jean-Roc nous a évoqué des cas d'usage nécessitant une échelle de temps à la journée, qui semblent peu compatibles avec la gestion d'une publication historisée (ça fait un paquet de fichiers à héberger et à gérer) ?

Exemple (je paraphrase) : je m'occupe des travaux, je passe ma vie dans QGIS, j'aimerais voir si la métropole a déjà pris un arrêté là où je veux en créer un ; ou à l'inverse m'assurer que la métropole ou le service voisin voit que j'ai mis en place une restriction à tel endroit.

La diffusion fichier répondrait plutôt à des cas d'usage comme celui-ci ? Faire une analyse historique des arrêtés à partir d'un snapshot à un instant donné que j'ai besoin de télécharger entièrement pour y appliquer du traitement hors ligne.

(P.S. : apparemment le service d'hébergement de la GeoPF (attention car je n'ai rien trouvé à ce sujet sur le site de la Géoplateforme, il faudrait demander des précisions) permettrait de faire cette historisation "pour nous". À creuser...)

Par ailleurs, serait-il utile que tu rencontres à ton tour Jean-Roc pour lui poser les questions que tu as en tête et aider à clarifier les besoins ? On n'est pas ressortis avec autre chose qu'en substance "Je veux récupérer les données que j'ai mis dans Litteralis ainsi que celles des services adjacents qui ont aussi Litteralis".

[MathieuFV]

J'appuie la conclusion de Florimond, ce que nous a appris cet entretien c'est qu'il y a une frustration de voir les données Litteralis enfermées, mais sur les cas d'usage c'était plus flou...

Je peux rappeler que nous avions assisté, Stéphane et moi, à une réunion de préparation de chantier à la métropole de Rennes où la métropole, la ville, l'opérateur de transport en commun etc. examinaient des plans de situation des travaux prévus (et des mesures de circulation). Ce genre d'outils par exemple bénéficierait de la possibilité d'utiliser les données DiaLog dans des logiciels de géointelligence. Par exemple je crée une carte avec les règles de circulation permanente dans le quartier ou dans le bassin de mobilité et je dessine là où je vais faire des travaux pour voir où les camions vont passer.

[johanricher]

Cas d'usage QGIS avec OGC API :

https://github.com/opengeospatial/ogcapi-features/blob/master/implementations/clients/qgis.md

[florimondmanca]

Description du ticket mise à jour avec une idée de définition des champs à exposer

Le concept : exposer des "restrictions", une restriction étant définie comme ça :

Une restriction correspond à une mesure appliquée sur une unité de lieu (localisation) et sur une unité de temps (période)

Dans DiaLog, une mesure contenant 3 localisations et 2 périodes définirait donc en tout 3 x 2 = 6 restrictions (1 restriction par localisation et par période)

Est-ce que tu es raccord @johanricher ?

[johanricher]

Merci pour ce CR de nos échanges de ce matin pour cadrer les critères d'acceptation, ou en tout cas des premiers pour un premier pas d'implémentation. 👍 Le plus tôt on pourra montrer une fonctionnalité utilisable par le contact pilote, mieux on pourra itérer.

Une restriction correspond à une mesure appliquée sur une unité de lieu (localisation) et sur une unité de temps (période)

Super ! cette définition de "restriction", si elle tient, nous sera très utile car on a beaucoup tourné autour sans arriver à la fixer, notamment en lien avec ce qu'on diffuse auprès de nos réutilisateurs ("restriction" dans DiaLog serait en gros équivalent à "incident" dans Waze) et pour bien calibrer la granularité de nos indicateurs #562.

[florimondmanca]

(Réflexion à voix haute)

Par rapport à :

Géométrie (brute)

Je faisais référence au fait que Jean-Roc souhaite récupérer la géométrie "brute", telle qu'elle provient directement de Litteralis, sans aucun post-traitement fait pour les besoins de DiaLog

tl;dr : je propose de ne pas traiter ça dans le cadre de ce ticket, même si ça veut dire que ça ne résoudrait pas directement le cas d'usage de Jean-Roc (qui se compose en fait de deux besoins : pouvoir charger les données dans QGIS, + pouvoir récupérer les données telles que saisies Litteralis).

On aurait donc besoin d'un autre ticket : "exposer les géométries primaires" (dont je donne une définition ci-dessous).

---

Détails :

Actuellement on ne stocke qu'une seule "version" de la géométrie, dans le champ geometry, et ce n'est pas une géométrie "brute".

Voici comment on calcule la geometry dans les différents cas :

Source	Description	Stocke-t-on la géométrie brute ?
UI DiaLog	Géocodage DiaLog	✔️ (pas d'autre source que le géocodage)
Eudonet Paris	Localisation type NamedStreet (voie nommée) avec géocodage DiaLog	✔️ (idem)
Bac-IDF	Localisation type NamedStreet où la geometry est une GeometryCollection construite à partir du champ VOIE_GEOJSON (pas de traitement)	✔️
JOP2024	Localisation type RawGeoJSON (données GeoJSON) où la geometry est constituée des tronçons de route contenus dans le polygône décrit par chaque (rouge, bleue, etc)	❌ (les polygônes des zones ne sont pas retenus)
Litteralis	Localisation type RawGeoJSON où la geometry est constituée des tronçons de route contenus dans chaque polygône décrit par la geometry source	❌ (les polygônes source ne sont pas retenus)

Il y a nécessairement au moins deux "versions" de la géométrie :

1. La géométrie "brute", qu'on peut aussi appeler "primaire"
2. La géométrie au sens actuel, qu'on peut appeler "finale"

Aujourd'hui la géométrie finale est en fait utilisée de plusieurs façons :

Cas d'usage	Ce qu'on expose	Pourrait-on utiliser plutôt la géométrie primaire ?
Carte	La geometry telle que stockée en DB	❓ Pourquoi pas, mais ne vaut-il pas mieux afficher les géométries telles qu'elles seront transmises aux GPS ?
Export DATEX	La geometry telle que stockée en DB	❓ idem, les réutilisateurs ne sont-ils pas d'abord intéressés par une géométrie la plus "prête à l'emploi" possible ?
Export CIFS	Un incident par linestring contenue dans la geometry	❌ Non, en CIFS on ne peut indiquer qu'une polyline (linestring) par incident ; il faut nécessairement transformer la géométrie primaire pour obtenir la liste des tronçons auxquels elle correspond
Export OGC API Features	?	❓ Jean-Roc pousse vers la géométrie primaire, mais on peut aussi imaginer des réutilisateurs préférer le format OGC API Features au format DATEX (plus facile à manipuler), et qui préfèreraient une géométrie la plus "prête à l'emploi" possible ?

Au final cette analyse ne me permet pas vraiment de conclure...

Ce que Jean-Roc souhaiterait c'est une sorte de "proxy" qui fasse un relais le plus direct possible. Mais DiaLog n'a pas été pensé comme ça, jusqu'ici on a voulu exposer des géométries les plus prêtes à l'emploi possibles...

Est-ce que ça ne veut pas dire qu'il faudrait deux "vues" ? Une vue "primaire", où on fournit la géométrie la plus brute (les polygônes dessinés dans Litteralis, les polygônes des zones JOP), et une vue "dialog" où on fournit la géométrie finale telle qu'actuellement stockée par DiaLog.

Ça voudrait dire en tout cas qu'on peut créer cette vue "primaire" dans un second temps, en complément de la vue "dialog", et donc qu'on peut commencer par exposer une OGC API Features où la geometry est celle actuellement stockée dans DiaLog.

[Jean-Roc]

Bonjour, je n'avais pas vu cet échange, n'hésitez pas à rajouter un @ pseudo pour me notifier si vous souhaitiez des compléments d'informations.

Dans le désordre :

• dans notre cas, la géométrie primaire (le polygone formé par Literalis sur la base des voies/numéros) permet d'exploiter le périmètre sans étape de reprojection d'un axe médian approximatif sur un référentiel de voirie
  • selon les logiciels utilisés dans notre collectivité, c'est plus où moins simple
  • plusieurs référentiels peuvent être utilisés dans un même projet (le note, celui de la mel, ign, etc.)
• le besoin principal c'est de pouvoir permettre à des agents de la mobilité, de l'urbanisme, de la police municipale, etc. de connaître les périmètres d'arrêtés saisis par l'unique collègue en charge de literalis
  • la même chose, sur le même périmètre géographique, par un autre établissement (dans notre cas, la MEL)
  • de pouvoir l'exploiter dans un logiciel bureautique (QGIS) et dans un portail cartographique sans mettre autre chose en place qu'un appel d'api
• un fichier GeoJSON n'offre pas les mêmes conditions d'usage qu'un service web puisque même en allant sur un sous-ensemble géographique, ça implique de télécharger tout le fichier avant de le parser pour ne retenir que les éléments présents dans le sous-ensemble
  • l'API OGC Feature permet de faire ça confortablement en spécifiant l'étendu et en ne communiquant que les enregistrements concernées dans le paquet geosjon
  • on peut remplacer ou compléter l'approche API avec une approche fichier mais dans ce cas il faut plutôt privilégier des formats comme le flatgeobuf ou le geoparquet qui sont cloud native (traduction du buzzword, optimisés pour des requêtes http range)

[florimondmanca]

Merci pour les compléments @Jean-Roc

le besoin principal c'est de pouvoir permettre à des agents de la mobilité, de l'urbanisme, de la police municipale, etc. de connaître les périmètres d'arrêtés saisis par l'unique collègue en charge de literalis

J'avais une question complémentaire

Actuellement DiaLog n'intègre que les mesures d'interdiction de circulation et de limitation de vitesse, car ce sont les seules qu'on peut traiter dans notre UI (sachant que seule l'interdiction de circulation peut être traitée par Waze aujourd'hui)

Mais ici, j'imagine que vous vous attendriez à ce que tous les arrêtés saisis dans un Litteralis soient visibles par les collègues ?

En fait j'ai l'impression que votre besoin serait une sorte de "proxy open data" par-dessus le WFS de Litteralis (qui n'est accessible que via des identifiants)

Ça pose d'autres questions, mais si l'objectif est d'obtenir la donnée la plus intacte possible, il vaut peut-être mieux imaginer une solution qui ne passe pas par les pipelines de traitement de DiaLog. Notre "intégration Litteralis" traite les données pour les besoins de la republication vers les GPS.

[Jean-Roc]

@florimondmanca, j'avais bien ces limites en tête, rien que l'ouverture consommable des arrêtés de circulation/stationnements serait un grand pas en avant.

Après, les arrêtés de fêtes et manifestations (Braderie, parades, manifestations, fêtes de quartiers, etc.) et les arrêtés de tournage pourraient être intéressants mais il n'y a peut-être que dans les hauts de france ou la saison des braderies rend la circulation aventureuse ;)