johanricher
commented
1 week ago 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
MathieuFV
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
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
Design
Implémentation
Contexte supplémentaire
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.