Y a t’il une discussion engagé ou des liens avec le gouvernement à propos des défibrillateurs cardiaques et les propositions faites sur l’extension du socle commun d’Open Data France?
1 « J'aime »
Ce serait bien de lancer un process ouvert pour fabriquer le standard. Pour ma part je me moque un peu de qui le porte du moment qu’il est discuté.
Ça pourrait d’ailleurs faire un beau projet pour Open Data impact : construire et documenter la mise en oeuvre d’un standard open data.
On pourrait commencer par lister les bonnes pratiques. Pour ma part je trouve que le SCDL et les quelques standards “Etalab” ont été riche d’enseignement.
2 « J'aime »
à dispo pour en discuter, avec Open Contracting notamment on commence à avoir pas mal de retours d’expérience sur les bonnes pratiques de développement et animation de standards de données ouvert(e)s. Pour rappel aussi ce billet que @samgoeta avait écrit :
3 « J'aime »
Secouriste à la Croix-Rouge depuis une paire d’année et contributeur OSM, j’attendais cette loi avec impatience (euphémisme).
En fait, je ne comprends pas bien pourquoi il y aurait besoin d’un standard pour cette donnée.
Pour moi, il s’agit surtout d’une BDD géographique classique avec des attributs (x, y, modèle, version du logiciel, fabriquant,…). Il y a lieu de définir simplement les données obligatoires et facultatives par défibrillateur et de mettre ca dans un format classique, genre .csv
Ai-je mal compris la question?
1 « J'aime »
Il ne suffit pas d’avoir seulement des coordo géographiques il faut également avoir un descriptif pratique: accès libre ou non , horaires d’ouverture du lieu, le descriptif du lieu (étage…)…
A enrichir avec des bonnes idées des jeux proposés sur Datagouv.
Du pratique !
La ville de bégard vient de publier un jeu sur le modèle proposé par ODF
C’est bien mon propos 
Des coordonnées géographiques agrémentées d’autres données utiles.
@gendy54 le standard permet de plus facilement agréger les données.
C’est quasi indispensable (et même pas suffisant) quand on a un grand nombre d’acteurs qui peuvent être à l’origine de ces données.
L’expérience des infrastructures de recharges pour véhicules électriques (IRVE) ou des adresses montre qu’il est très compliqué d’utiliser des dizaines de jeux de données décrivant en principe le même type d’objet si ils sont tous organisés différemment. Je ne parle même pas du format, mais bien de ce qu’on trouve dans les fichiers.
Pour les IRVE, bien qu’il y ait un arrêté ministériel décrivant le format et des subventions à la clé, le standard n’est que partiellement respecté… c’est là où des outils en ligne de validation permettent de vérifier que le fichier produit est celui attendu et donc permet effectivement d’alimenter une base plus globale, car c’est elle qui sera vraiment utile, pas des centaines ou milliers de fichiers morcelés.
1 « J'aime »
Oui @cquest ca me semblait tellement évident d’imposer un standard que je me suis pris les pieds dans le tapis.
Dispo donc pour échanger sur le standard.
1 « J'aime »
C’est un bon début qui a le mérite de lancer la discussion. Il faudrait jeter un oeil aux autres comme celui d’Issy-les-Moulineaux : https://www.data.gouv.fr/fr/datasets/defibrillateurs/
Je vois pas mal de choses à améliorer sur le “modèle ODF”.
- tout d’abord je ne vois pas l’intérêt de répéter les coordonnées géographiques : EQUIP_GEOLOCALISATION est redondant par rapport à EQUIP_LAT et EQUIP_LONG je ne garderais que ces deux derniers
- à quoi sert l’identifiant unique (maintenance ?) ? est-il présent sur l’appareil ? sinon pourquoi ne pas reprendre ce dernier ? sinon comment est-il déterminé ? Lat-lon ne peuvent-ils suffirent pour garantir l’unicité ? l’ID OSM pourrait-il avoir du sens ?
- COLL_NOM doit être spécifié correctement sans quoi on aura “Bégard”, “BEGARD” ou “BÉGARD”.
- Pourquoi COLL_NOM ? Ne faudrait-il pas préférer systématiquement le nom de la commune (plus parlant) que celui de la collectivité ? On peut considérer qu’avoir la commune est une information redondante si on a les coordonnées géographiques. Mais dans certains cas d’usage je pense que ce n’est pas une mauvaise pratique. Cela permet à un humain d’identifier la commune sans passer par une cartographie ou un calcul. On parle ici de sauver des vies, ne mégotons pas…
- COLL_SIRET : dans ton exemple Dominique, je pense que tu as indiqué le code INSEE et pas le SIRET ; soit dit en passant il y a un espace entre 22 et 004 alors que les codes INSEE n’en contiennent pas.
- COLL_SIRET : je comprends que souvent (tout le temps ?) le DAE est rattaché à un local, un établissement, qui, dans la plupart des cas va posséder un code SIRET. Ce n’est pas idiot mais dans certains cas ce code pourrait changer régulièrement. À voir.
- LIEU_TYPE : quel usage ? Je comprends que c’est une liste fermée ?
- Pour l’adresse je pense qu’il faut faire appel à l’expertise de @cquest Trouver un truc simple mais le plus compatible possible avec la BAN.
- ACCES_LIBRE : à quoi sert il ? J’imagine qu’en cas de problème cardiaque cette notion n’a plus vraiment court non ?
- Horaires : ISO 8601 permet de spécifier des intervalles mais je ne sais s’il peut gérer des plages complexes. Je pense qu’il faut creuser un peu.
- AUTRE_INFORMATIONS : pourquoi faire ?
- EQUIP_ACCES_PARTICULIER : champ crucial mais plus ou moins bien utilisé dans l’exemple de Dominique ; je pense que ce dernier devrait systématiquement indiquer l’emplacement précis : “Bâtiment B-RdC face à l’ascenseur” est bien vu ; mais je ne vois pas l’intérêt de “Snack Bar”.
- J’ajouterais bien des informations utiles au suivi du “parc” (utile à l’acteur public ou des assos ou des services de secours ou autres) :
- la date de dernière observation où l’appareil était présent et paraissait fonctionnel
- le contact du responsable de l’appareil
Si vous voulez je peux rédiger une spec un peu propre pour embrayer, sachant que ce ne sera qu’une base de travail.
Il faudrait faire rentrer d’autres acteurs dans la conversation. Lesquels ?
SDIS ? Médecins ? ARS ? Croix-Rouge ? Assos sur les risques cardio-vasculaires ? Un type acteur particulier se sent-il la responsabilité particulière de produire ces données ?
Certes on peut discuter longtemps sur le standard à mettre en place.
L’idée de lancer cette discussion est justement d’avoir les bons interlocuteurs.
En effet ODF et d’autres ont ou vont proposer des standard pour différents sujets.
Le HIc c’est que lorsque le gouvernement par décret propose un standard il devient forcément le référentiel à utiliser, d’où ma question sur les échanges avec le gouvernement, il ne sert à rien que l’on discute entre nous s’il n’est pas dans la boucle car au final c’est lui qui tranchera.
On l’a bien vu pour les marchés publics et les subventions!
1 « J'aime »
Sur la question de la maintenance des standards, je vous conseille de regarder la gouvernance de l’Open Contracting Data Standard : http://standard.open-contracting.org/latest/fr/support/governance/
bonjour,
je me permet d’intervenir sur la structure du fichier (qui est obligatoirement mauvaise puisque créée de manière empirique).
Mais je crois que mon manque de méthode peut aider a trouver une méthode plus efficace ;).
premièrement, histoire de ne pas réinventer la roue j’ai été voir ce qui existait sur https://www.data.gouv.fr/fr/ et je n’ai pas trouvé grand chose de satisfaisant, parfois on a une liste avec des adresses de rues (mais sans commune ni code INSEE) et à mon avis c’est important pour la réutilisation.
Ensuite, çà fait bientôt deux ans que Dominique on s’interroge sur la structure que pourrait avoir un fichier opendata sur le défibrillateur. au fil de sa réflexion @dom_datarmor a commencer à imaginer la structure qu’il a mis en lien
Dans la pratique elle me plait bien, il y a juste un truc que je ne vois pas bien aborder, ce sont les champs Horaire 1 Horaire 2 Horaire 3 en effet on peut avoir des horaires d’accès mais aussi des périodes d’ouverture d’un lieu sur l’année (c’est le cas d’Armoripark à Bégard, le parc est fermé d’octobre a avril et n’est ouvert que quelques jours ou plage horaires dans la semaine hors vacance d’été) bref je ne vois pas bien comment trouver une norme de marquage pour les dates (mais j’ai honte ).
Comme il nous semblait judicieux de faire un truc qui soit relativement réutilisable ou du moins qui puisse aider à la réflexion, avec la mairie de Bégard on c’est dit qu’on pouvait voir dans le socle commun si un jeu pouvait être un peu le modèle.
celui ci : https://drive.google.com/file/d/1McWh0BBFqiTFW3jlqrkuGYunptW7M9_4/view
nous semblait intéressant.
On a donc remixé les deux (mais c’est loin d’être au point)
Je reviens sur ACCES_LIBRE je pense que çà peut avoir du sens : un défibrillateur n’est pas toujours dans un lieu public (ou géré par un établissement public) , il peut être dans un lieu privé (un immeuble de bureaux, une usine) auquel cas il est bien de savoir qu’il existe, si on en a besoin quand on est à proximité du lieu pendant ses horaire d’ouverture, mais il est tout aussi bien de savoir qu’on n’y aura pas accès hors des horaires d’ouverture.
a la relecture du truc, il m’apparait aussi que la présence d’un champ nommé pour définir l’étage auquel est installé l’équipement pourrait être intéressant pour les immeubles.
Enfin, on c’est emmêlé les pinceaux entre l’INSEE et le Siret (les risque de l’expérimentation).
je note tout çà pour qu’on puisse améliorer le fichier.
Pour recentrer sur le débat de la loi “défibrillateur” effectivement elle va permettre d’avoir un standard (et c’est bien) par contre ce serait bien que çà ne se fasse pas hors sol et que les ébauches et travaux qui ont étés proposés jusqu’à présent en opendata puisse servir de base de réflexion.
En attendant merci a tous et a Dominique d’avoir lancé le débat, j’ai appris plein de choses et j’y vois un peu plus clair.
Nous sommes d’accord. J’ose espérer que c’est Étalab qui se chargera de la spec et qu’on pourra donc dialoguer. Ça ne nous empêche pas d’y réfléchir dès aujourd’hui, d’anticiper un peu les discussions et d’arriver, pourquoi pas, avec des propositions qui permettrons de gagner du temps.
Ça n’était pas si mauvais et ça a eu le mérite de lancer le sujet.
Votre méthode était aussi bien vue :
- voir l’existant en terme de données afin de voir s’il y a des consensus/dissensus
- voir l’existant en terme de standards proches afin de réutiliser des “motifs” (par exemple pour l’adresse ou autre)
- publier ici même pour avoir des premiers retours
Jusqu’ici je trouve que c’est la bonne méthode. Il s’agit sans doute maintenant de mieux cerner les publics et ceux qui devraient pouvoir contribuer.
Oui, ce sujet est épineux mais je pense que certains ont déjà du bosser là-dessus. Je pense notamment @cquest créateur d’OpenEventDatabase.
Je ne comprends pas bien. S’il s’agit d’un établissement géré par un acteur public, prenons une mairie par exemple, on y aura pas plus accès qu’un lieu privé en dehors des horaires d’ouverture. J’aurais tendance à penser que le fait que le lieu soit un lieu public ou privé ne change rien : quand quelqu’un est mal, il est du devoir de chacun de l’assister lorsqu’on en a les moyens non ? (concept de non assistance à personne en danger). Je peux comprendre le distinguo accès permanent vs accès selon des horaires. Mais pas celui public/privé. (Mais je peux me tromper lourdement.)
Est-ce que ce n’est pas rôle de EQUIP_ACCES_PARTICULIER qui permet de préciser justement de préciser l’accès ?
Oui !
Oui merci à tous.
effectivement, je reformule il peut arriver (c’est le cas dans ma cambrousse) qu’un défibrillateur public soit de plus accessible sur la voie publique. je reprends l’exemple de ma cambrousse, il y a un défibrillateur posé devant l’entrée du gymnase.
par contre ( mais toujours dans ma cambrousse) le supermarché du coin et une ou deux entreprises ont un défibrillateur, qui n’est pas accessible depuis la voie publique.
c’était là que je faisait la distinction
Je signale que le sujet a été évoqué lors du dernier groupe de travail Open Data de l’Afigéo.
Thomas Portier à l’origine du modèle minimal des Points d’Eau Incendie (PEI) voulait remettre le couvert avec cette thématique proche.
Je pense qu’on remettra ça à l’ordre du jour à la prochaine session.
Idéalement il faudrait que seuls les champs essentiels soient obligatoire.
2 « J'aime »
L’Open Data Institute vient de sortir un guide pratique très complet sur les standards de données https://standards.theodi.org Il compile de nombreuses ressources pour comprendre comment créér, développer et favoriser l’adoption des standards …
3 « J'aime »
Bonjour à tous,
Pour avoir eu à faire qques recherches récemment, il y a une opération de recensement organisée par L’association arlod. Elle propose un moteur de recherche qui ne permet que d’obtenir une réponse selon une localisation précise mais n’ouvre pas ses fichiers :
https://www.defib-arlod.fr/un-defibrillateur-pres-de-chez-vous
mais peut être faut il creuser…
1 « J'aime »