je suis totalement favorable à la standardisation des formats des données, mais j’ai toujours un problème avec ces référentiels qui demandent toujours plein de champs à renseigner…
En fait je me place toujours à la place de la personne qui va saisir ce fichier et fournir ce jeu de données pour le mettre en open data et notamment les petits (sans côté péjoratif de ma part) producteurs de données.
Quand on voit les données demandées, je pense directement à un de mes producteurs de donnée dans une petite commune de notre territoire. En plus on a là une commune de moins de 1500 habitants, donc sur une démarche volontariste d’ouverture des données. Si je demande à ce monsieur de se mettre en conformité avec ce format il risque de me regarder avec des grands yeux ronds.
Dans les grosses structures, c’est souvent plus simple parce qu’on a des choses plus structurées, mais dans les petites communes (et là je pense particulièrement à la cambrousse, pour reprendre le terme de @lolobobo , où je vis) où on a un.e maire, un.e secrétaire de mairie, une personne en charge de tout ce qui est technique (de la gestion des espaces verts à l’entretien des bâtiments municipaux et des routes, …) et là qui rempli ce fichier ?? même s’il n’y en a qu’un sur le territoire de la commune, ces personnes là ne sont pas à l’aise avec la donnée voire avec le numérique tout court…
Et même les communes moyennes qui ont plus de défibrillateurs sur leur territoire, ces gens là vont s’amuser à créer ce jeu de données…
J’ai peur que toutes ces complexités viennent tuer toutes les démarches et bonnes volontés qu’on arrive à trouver.
A ma première lecture j’ai eu la même réaction,fichier complexe à produire par les collectivités.
Mais à la deuxième lecture je comprends que c’est à l’exploitant de fournir ces données, qui pourrait me dire qui est l’exploitant : le fournisseur, le directeur général de la santé (article 2)…
Les collectivités doivent récupérés ces données auprès de qui … d’une base nationale, la demander à leur fournisseur ???
L’Open data devient de plus en plus complexe pour les petites (ou grosses) collectivités (mille feuille de l’opendata), a l’image des aires de covoiturage: les collter founissent leur bdd et puis l’état les récupère pour dire aux collterr que maintenant c’est celle de l’état qui est la référence.
Quid ensuite de la mise à jour.
Un portail Opendata par collectivité centralisé par une plateforme nationale puis de plateformes spécifiques …je m’y perds
Quand je suis intervenu l’année dernière sur ce dossier, j’ai poussé pour que ce soit les sociétés qui installent et maintiennent les défibrillateurs qui se chargent en priorité d’alimenter et maintenir la base à jour.
En effet, ce sont bien elles qui savent où des défibrillateurs en état de marche sont disponibles… mais bon, la logique administrative est malheureusement toute autre.
L’exploitant c’est le propriétaire du DAE, le directeur général de la santé lui exploite la base nationale, pas les DAE.
Les données sont souvent à récupérer auprès des fournisseurs et société de maintenance qui (il me semble) peuvent être chargés par l’exploitant de fournir les données à la base nationale.
La collecté de données locales pour agrégation nationale et rediffusion est un sujet récurent. Ce type de données ne devient exploitable que lorsqu’elles sont agrégées, sinon on ne sait jamais où les trouver sur les portails opendata locaux, ni sous quel nom elles ont été publiées.
On le voit avec d’autres jeux de données, comme celui des bornes de recharges… obligation de publication sur data.gouv.fr dans un format donné pour recevoir les subventions après l’installation (carotte). Du coup ça a permis de publier une base agrégées.
L’articulation entre portails locaux, nationaux et thématiques permettent:
un accès à des données sur un territoire donné
un accès global
un accès thématique (transport, adresses, etc)
Les trois se complètent, par contre, il faut que ce soit fluide entre les trois (moissonnages) pour ne pas avoir à publier 3 fois !
J’ai partagé mes remarques sur ce schéma ici : https://github.com/Alkante35/schema-dae/issues/1 et je vous encourage à faire de même avant que ce schéma très attendu soit ouvert au grand public et exploité en production par un grand nombre d’acteurs.
Je repartage également cette communication de l’Agence régionale de santé Auvergne-Rhône-Alpes dont je viens de prendre connaissance :
Le standard de la base de données nationale DAE a été publié par arrêté le 13 novembre dernier. Il est disponible au lien suivant : https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000039363959. Il est le fruit de la concertation menée au mois de mai dernier pour laquelle vous nous avez grandement aidé et nous vous en remercions.
L’ouverture de la base de données nationale est prévue d’ici la fin du mois de janvier. A ce titre, nous organisons des webdémos afin de présenter son fonctionnement. 3 créneaux sont proposés :
Le 21 janvier à 10h55 ;
Le 24 janvier à 13h25 ;
Le 27 janvier à 13h55.
Pour y participer, il suffit de se connecter de la manière suivante :
Suite à la présentation de ce jour par l’ARS Auvergne-Rhône-Alpes, l’animateur a confirmé que le gid (identifiant unique du DAE dans la base de données) n’a pas de raison d’être en diffusion limitée. Il s’agit donc d’une erreur.
Concernant les horaires d’ouverture par contre, le formulaire en place sur le site de test qui a été présenté ne va pas plus dans le détail qu’un choix entre :
24h/24
heures ouvrables
heures de nuit
Donc ne colle pas au format OSM. Mais correspond à ce qui est dans l’arrêté du 29/10/2019 : champ disp_h.
Concernant l’alimentation de la base, ce sont bien les exploitants qui sont chargés d’ajouter les DAE.
Les mainteneurs sont désignés par les exploitants pour chaque DAE et ils peuvent mettre à jour les DAE (par exemple sur l’état).
Les applis citoyennes autour des DAE pourront se connecter à la base et continuer à animer leur communauté. Si un·e citoyen·ne signale un problème sur un DAE, l’exploitant devra lever le doute (confirmer un état, un DAE inexistant…) via la plateforme mise en place.
Les secours auront un accès à la base, y compris de données en accès limité (notamment numéro de téléphone sur le lieu du DAE).
Des API sont mises en place pour l’accès aux données.
La mise à jour de la base sur data.gouv.fr sera faite, pas de fréquence de mise à jour décidée à ce jour (peut-être journalière…).
Une annonce de lancement de la plateforme de production sera faite par la ministre de la santé (si je ne me trompe pas) courant février 2020. Le nom GeoDAE sera remplacé par un nouveau nom officiel.
Concernant l’alimentation de la base, ce sont bien les exploitants qui sont chargés d’ajouter les DAE.
Malgré les efforts importants qui semblent avoir été faits, persiste néanmoins l’impression que ce dispositif est une usine à gaz… On verra avec le temps si cette base parvient à être plus exhaustive que ses concurrentes ; OSM en tête, qui non seulement part avec une longueur d’avance mais profitera aussi des éventuels ajouts dans la base DAE qui ne sont pas encore dans OSM.
La mise à jour de la base sur data.gouv.fr sera faite
Pour information, suite à l’arrêté de description des données de cette future base, j’ai cherché les concordances avec les tags OSM afin de faciliter l’intégration.
C’est un 1er jet qui nécessite d’être amélioré. Il y a quelques tags pour lesquels je n’ai pas de correspondance. Il va donc falloir les créer.
La communauté OpenStreetMap lance son Projet du Mois de septembre sur les défibrillateurs. http://www.openstreetmap.fr/projet-du-mois-defibrillateurs/
Le projet n’est pas tant d’en avoir le plus possible dans la base OSM que de faire parler des enjeux, de confronter les données pour les améliorer et donner un coup de boost.
N’hésitez pas à en parler autour de vous. Il y a de la communication sur les profils Twitter et FB d’OSM France.
Une idée du modèle de https://sauvlife.fr sur la partie données?
Identifié via un reportage d’Envoyé Spécial. Intéressant pour la partie appli mais pour les données, bien qu’ils semblent fournir les données remontées aux SAMU (encore que « sera à la disposition des SAMU de France. » soit librement interprétable), cela me semble encore être un nième solution non mutualisée.
J’en profite pour poser la question de l’avancement de ce projet défibrillateurs OpenData en général. Des changements notables depuis? Cela avance mais « tranquillement »?