Je viens tenter de trouver une solution à un problème de moissonnage ici en déserpoir de cause, les services d’OpenStreetMap France ne parvenant plus à accéder à certaines données.
Depuis le changement de la plateforme de données ouvertes de l’Agence ORE et d’Enedis, data.gouv ne parvient plus à moissonner les fichiers disponibles là-bas.
Le contrôle qualité d’OSM opéré par Osmose n’est plus mis à jour sur la thématique concernée par ce jeu de données et le problème semble toucher le moisonnage des plateformes Koumoul. Votre équipe a-t-elle prévue de travailler pour améliorer ce point ?
Ce sujet avait bien été identifié et remonté par nos équipes auprès d’Enedis, qui investigue actuellement avec leur fournisseur pour corriger ce problème.
Nous leur avons également transmis votre message, afin qu’ils puissent vous répondre directement sur le forum et vous tenir informé de l’avancement.
Ce que je me demandais aussi, c’est l’ampleur exacte du problème : arrive-t-il spécifiquement sur les solutions Enedis / Agence ORE ou sur d’autres plateformes Koumoul ?
Parce que soit il y a corrections côté Agence ORE, ou bien le moissonnage peut être globalement adapté pour Koumoul.
J’ai moi-même tenté de modifier notre sourcing pour aller directement télécharger à la source et j’ai bien vu les adaptations à faire qui ne sont pas forcément spécifiques à notre cas.
Les jeux de données virtuels, c’est-à-dire ceux qui sont constitués avec plusieurs fichiers, ne peuvent pas apparaitre directement dans la rubrique « Fichier principal » de data.gouv.fr lors d’un moissonnage avec/depuis/vers les plateformes open data proposées par Koumoul.
C’est ce qui explique que seuls certains jeux de données de l’Agence ORE ou d’Enedis possèdent des liens directs vers des fichiers CSV, XLSX ou ZIP.
Cependant, les organisations certifiées possèdent un lien de téléchargement présenté dans le fichier « Consulter les données » si le fichier est au format tabulaire. Cette fonctionnalité est active pour l’Agence ORE (certifiée) mais pas pour Enedis, qui n’est pas (encore) certifiée par data.gouv.fr
La demande pour certifier l’organisation Enedis a dores et déjà été envoyée via le formulaire du site, nous sommes à ce jour en attente d’un retour.
Quand j’accède à la ressource data.gouv 60c2d265a275be87d62fcb3b / 8828893d-0265-4a53-af2e-633964ea5a16, je reçois du HTML, pas le contenu du jeu de données comme précédemment.
Je me tiens disponible pour faire des tests au besoin
Le jeu de données des poteaux mentionné est constitué de plusieurs fichiers shapefile différents, qui sont concaténés pour donner un seul jeu de données publié. C’est le cas de la majorité des jeux de données de cartographie publiés par Enedis.
Si je comprend bien le problème, il n’est plus possible de récupérer toutes les données d’un coup via un fichier CSV sur data.gouv.
Il y a effectivement une différence depuis le changement de plateforme : Data Fair (plateforme Koumoul) ne permet pas de télécharger un fichier CSV contruit à chaud depuis l’API si celui ci fait plus de 10k lignes. Par conséquent il n’y a pas de lien de ressource pour ce CSV publié sur data.gouv.
Je vois 2 solutions possibles :
Mettre en place des exports périodiques (calés sur les rythmes de mise a jour des données) pour créer ces fichiers CSV, puis voir si on peut les publier en tant que ressource sur data.gouv. (mais je pense que ca va etre compliqué de garder le meme identifiant de ressource que celui écrit dans le code python).
Voir si il est possible de proposer un analyser OSM qui pourrait récupérer les données depuis l’API
Il s’agit ici de fichiers mis à jour semestriellement, je pense que la plateforme consomme plus de ressources à produire les résultats paginés lorsqu’il faut fournir l’ensemble brut que de stocker un csv statique. Ce qui n’empêche pas de devoir l’indexer en base de données pour faire du filtre ou du catalogage.
L’identifiant dans le code python se change facilement chez nous. Ce qui compte c’est de pouvoir réutiliser le même connecteur (voir ci-dessous).
OSM dans l’ensemble, je ne sais pas. Osmose en particulier oui.
C’est une bonne piste ce connecteur, mais j’ai l’impression qu’il va chercher le fichier source, qui n’est pas disponible dans notre cas vu qu’on est sur un JDD composé de plusieurs fichiers. Une option serait d’adapter ce connecteur pour qu’il dépagine l’API.
Par contre sans filtres le fichier est tres volumineux et il est possible que la connexion soit coupée pour timeout. Je vois que toutes les lignes ne sont pas forcément utilisées, il y a peu être moyen de rajouter des paramêtres de requête select / where pour diminuer la taille du fichier ?
Entendu, je garde cette option en low prio si les autres ne sont finalement pas fructueuses.
Excellent point, ça peut certainement nous aider. Ces endpoints ne sont déployés que sur les instances Agence ORE/Enedis ou sur l’ensemble de vos instances ?
Exactement, sur les 6 millions de lignes existantes, nous ne conservons qu’un million et demi environ (cette proportion va augmenter au gré des travaux d’Enedis de porter les lignes en casse C vers les classes A et B) et n’utilisons que certaines colonnes, donc il y a moyen de réduire la taille du fichier en longueur comme en largeur.
Nous sommes capables d’indiquer les filtres à faire dans l’URL, si c’est ce que tu entends.
Les endpoints de rétrocompatibilité s’activent par compte, on les active lors de migrations uniquement. Les portails EDF les ont aussi, pour savoir si c’est actif il faut aller sur la documentation d’API d’un jeu de données, si il y a une section retrocompatibilité, c’est que c’est actif.
A noter que les endpoints de rétrocompatibilité sont marqués comme dépréciés sur l’API mais nous allons les maintenir quelques années. Si les migrations peuvent être faites vers les API natives Data Fair dès qu’il y a un peu de temps libre ça sera toujours mieux a plus long terme.