Communication Machine-to-machine: les opportunités manquées
•Descargar como PPT, PDF•
0 recomendaciones•771 vistas
Bien que nous soyons entré dans l'âge des données, les organismes publics partagent encore trop souvent de l'information formatée (comme des courriels). Mais cette information ne peut pas être utilisé de manière efficace par des machines. Il faut donc s'assurer de revenir à un partage des données qui puisse être utilisé directement. La présentation se concentre sur les données d'entraves routières et du format 511Ouvert et de ce qui est faisable lorsqu'on partage des données.
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (18)
Similar a Communication Machine-to-machine: les opportunités manquées
Similar a Communication Machine-to-machine: les opportunités manquées (20)
Communication Machine-to-machine: les opportunités manquées
- 1. Communication M2M: les opportunités manquées 511Ouvert et les données d’entraves routières Stéphane Guidoin / @hoedic / @opennorth 49ème Congrès de l’AQTr, le 2 avril 2014
- 2. Nord Ouvert • Organisme à but non lucratif • Transparence gouvernementale et engagement citoyen • Outils web et données ouvertes
- 3. ZoneCone • Projet d’intégration des données d’entraves routières pour Montréal • Constatation: ⇒ Les données n’étaient pas disponibles publiquement, mais elles existaient ⇒ Beaucoup de juridictions ⇒ Nous n’étions pas les seuls
- 4. Proposition pour open511 • Format de données en XML et JSON • Réutilise la structure de TMDD… en plus simple • API: approche “Plug & play” • Négociation de contenu entre serveur et client • Filtre: par date, géographie, sévérités, etc • Crowdsourcing
- 5. Y.A.S: Yet another standard? Source: https://xkcd.com/927/
- 6. Positionnement de 511Ouvert • Données ouvertes • Simplicité d’utilisation (surtout pour le consommateur des données) • Orienté web et mobile
- 7. Partenaires • Financement de GeoConnexions • Ministère des transports de Colombie- Britannique (MOTI BC) • Metropolitan Transportations Commission of the San Francisco Bay Area (MTC SF) • Villes de Montréal, Ottawa et Repentigny
- 8. Processus ouvert • Documenté en ligne au fur et à mesure des avancées • Liste de diffusion publique • Issues tracker public (GitHub) • Annonce dans des conférences
- 9. État des lieux • Spécification version 1.0: http://open511.org/ • MOTI BC et MTC SF préparent leur implémentation • Option de crowdsourcing mise de coté pour le moment • Ajout en cours des caméras de circulation et des informations de vitesse
- 10. FédéralFédéral ProvincialProvincial RégionalRégional MunicipalMunicipal ArrondissementsArrondissements “Utilities”“Utilities” Producteurs Consommateurs Citoyens (via GPS et smartphones)Citoyens (via GPS et smartphones) Sécurité civile (pompiers, polices, ambulances, 911, etc.) Sécurité civile (pompiers, polices, ambulances, 911, etc.) Professionnels de la routesProfessionnels de la routes ChercheursChercheurs Autres gouvernementsAutres gouvernements
- 11. Au-delà des données ouvertes - Votre organisation partage-t-elle ses données d’entrave avec les services incendie? - Oui! - Comment? - Par courriel ou fax… ou parfois par téléphone
- 12. Des œufs et des gâteaux Source: http://epicgraphic.com/data-cake/
- 13. Encore un peu de gâteau? • À partir des même ingrédients (ou d’ingrédients externes), chacun peu faire sa propre recette. • On ne connait pas à l’avance l’utilisation des ingrédients. • Fin de l’intermède culinaire
- 14. Reconstituer les données • Dans un courriel, les données ont disparu • Pour une “machine”, un courriel est un tas de mots inutilisable • Il faut donc partager les données • Après chacun crée la représentation dont il a besoin
- 15. RITIS / CATTLab • Corrélation de multiples sources: – Données d’entraves routières accessibles – Données privées (INRIX, etc.) – Données météorologiques – …
- 16. Source: Université du Maryland, RITIS/CATTLAB, M. L. Pack
- 17. Tendance centralisatrice • De nombreux projets visent une centralisation • Les participants “perdent” contrôle de leur information • La centralisation soulève des problèmes de gouvernance • Depuis le web, les technologies sont faites pour aider la décentralisation (sauf Facebook)
- 18. MASAS • Système national de sécurité publique • L’information routière (hors autoroutes) est une des plus difficiles à obtenir actuellement • Lire X sources différentes n’est pas viable
- 20. Agregation, pas centralisation • MASAS joue un rôle d’agrégation (pas de centralisation) pour sa communauté • “Agrège” car repose sur des données décentralisées… • … mais ces données doivent être standardisées.
- 21. Et les petites juridictions? • La technologie ne doit pas être un frein, mais un moteur • La standardisation des données amène une commodification des outils logiciels
- 22. S o
- 23. Conclusion • Partager des données et non de l’information • Favoriser les approches décentralisées • Favoriser l’utilisation d’un (ou quelques) standards pour faciliter l’intégration et l’agrégation
Notas del editor
- Notre implication dans les transports a commencé avant même que Nord Ouvert soit fondé Volonté de démontrer l’utilité des données ouvertes => montrer ce que pourrait être un outil d’information au moment d’une crise du transport. Les données n’étaient pas disponible (ça on le savait en partant) – mais elles existaient! En revanche, ce qu’on n’avait pas prévu, c’était la complexité de gouvernance: de nombreuses juridictions controlaient une partie de l’information Ce que l’on a découvert aussi, c’est que de nombreux autres organismes souffraient du manque d’accès à cette information, autant des entreprises privées souhaitant offrir un service que d’autres organismes publics.
- Après constatation sur ZoneCone: opportunité de développer un format tel GTFS pour les transports en commun. Sans rentrer dans le contenu technique, le but était de proviter des architectures existant dans le monde web (qui est la génèse des données ouvertes), pour mettre l’information à disposition facilement.
- Tel qu’expliqué, il existait déjà des standards pour ces données, notamment TMDD. Toutefois ces formats ne semblaient pas adaptés pour une mise à disposition publique de l’information: pas de négociation de contenu standardisées, des implémentation très variables. A posteriori, on s’est fait confirmé par des personnes que mettre du TMDD public était difficile. Donc le but n’est pas de créer un n-ième format, mais de créer un format complémentaire avec un use case clair => rendre l’information “publique”. Comme nous le verrons plus tard, la notion de publique peut être plus large qu’on le pense. À noter qu’on travaille sur un convertisseur TMDD => open511 pour justement faciliter la tâche à tout le monde.
- Le use case initial était donc tourné vers les données ouvertes, avec une utilisation simple. Même critère de design que plusieurs API publiques sur le web => rendre la vie du client facile.
- Ceci dit, au fur et à mesure que nous rentrions dans les détails du projet, il est apparu qu’il n’y avait pas seulement le “public” (c-a-d, les gens hors du gouvernement) qui avaient besoin de cette information. Rapidement, il est apparu que cette information circulait pas ou peu entre les différents pallier de gouvernements et que des organisations para-gouvernementales, notamment les services d’urgence, avaient un accès incomplet à ces informations.
- Revenons sur le partage entre gouvernements. Avant de sauter dans le vif du sujet: anecdote utilisée fréquemment => White House Safety Datapalooza: les changements occasionnés par les données ouvertes sont plus importants DANS les gouvernements que HORS des gouvernements. L’ouverture des données est un outil clé pour ouvrir les silos et encourager la collaboration. Plusieurs commentaires depuis le début de 511Ouvert nous en ont convaincu. Exemple d’une discussion classique sur le partage des données => on partage un courriel
- Surement que plusieurs d’entre vous sont conscient de ces différentes. Pardonnez la métaphore un peu simpliste, mais cette illustration a fait le tour des milieux open data et moi-même elle me parle beaucoup La partie importante, dans notre cas, se passe souvent entre les deux premières images => données vs information. Le réflexe est de partager de l’information, parce que c’est ce que nous sommes habitués à manipuler en tant qu’humain. Mais dans une approche où l’on souhaite que les machines traitent l’information (pour aller plus vite, pour réaliser des traitements complexe, pour diffuser l’information “à la demande” et de manière contextuelle), il faut partager des données.
- Pourquoi partager des données? Parce que chaque utilisateur va reconstituer une information (puis une représentation) différentes. En d’autres termes, ils vont faire des récettes différentes, possiblement en apportant d’autres ingrédients. C’est d’ailleurs la grande leçon des données ouvertes: il ne faut pas présager de l’utilisation qui sera faite. C’Est évidemment assez difficile à réaliser car la collecte des données se fait souvent pour un usage précis. Augmenter la variété d’utilisation attendue peut soulever des problèmes, mais comme la plupart des licences le mentionnent, l’information est fournie “as-is”, au meilleur de ce qui était disponible.
- Pour clore sur la théorie: l’exemple classique consiste à envoyer l’information par courriel. C’est numérique, c’est quasi-instantané, on a l’impression d’envoyer des données. Mais dans les faits, ça prend toujours un humain pour traiter l’information.
- Quelques exemple d’utilisation RITIS, Université du Maryland, possiblement que certains connaissent déjà. Analyse du trafic routier sur base de plusieurs source (rappelez-vous: les ingrédients). Objectif: faire de la recherche, être capable de mettre en place des modèles d’analyse et de prévision multi-critères qui, éventuellement pourront être utilisé dans un mode opérationnel.
- Voici le résultat obtenu sur l’impact d’un accident. La bande rouge/orange représente l’augmentation du bouchon créé par un accident et la fermeture de voies. On note aussi le temps que prend le bouchon pour se résorber après. Avec de l’analyse multi-critère et du machine learning il est (ou sera) possible d’améliorer les capacités de prévision. Pour arriver à ce niveau, il fallait que l’information de vitesse (privé) et d’entrave (gouv) soit disponible.
- Autre sujet concernant l’utilisation des données. Comme expliqué, au début, et tout le monde dans la salle en est surement conscient, le réseau routier est un salmigondis de juridictions variées, il en va donc de même avec l’information, au grand dam de tout le monde. La solution habituellement envisagée est que la juridiction de plus haut niveau va mettre en place un outil de centralisation de l’information: donnez-moi votre information, vos données, je m’occuperai de les rendre disponibles. Le problème qui est souvent vécu est une perte de controle, soit au niveau des données, soit au niveau technologique (les outils de gestion partent dans les mains de quelqu’un d’autre). Cela amène souvent des problèmes de gouvernance: qui gère l’outil, qui en assume les coûts? Que faire si la juridiction maitre tire la plug? Pourtant, il est possible d’avoir une approche décentralisé. Hormis Facebook, la majorité des technologies inventées autour du Web favorisent la décentralisation
- Avant de continuer sur la question de la centralisation, laissez-moi vous parler d’un autre exemple: MASAS. Dispatche de l’information pertinente pour les services de sécurité publique à travers le Canada. Les entraves routières sont un de leur cauchemars. Eux ont besoin d’un accès aux données: ils ne peuvent pas recevoir des courriels des 13 provinces et territoires, des miliers des municipalités et je ne sais quel autres source. Mais même quand la données étaient disponible, ça s’est avéré problématique: tout le monde avait son propre format. Google a les moyens de lire plein de format différents parce que leurs attentes sont basses (faible détail de l’information) et qu’ils ont beaucoup de moyen. Quand on a moins de moyen et que l’on veut de l’information de meilleure qualité, ça prend de s’entendre.
- Voici à quoi ressemble l’outil de MASAS: pour la visualisation, ce sont encore des outils web, mais quoiqu’il en soit, l’important c’Est la donnée: ils peuvent envoyer des données pertinente à tous leurs services, ici par exemple concernant une inondation et les routes fermées. Récemment je discutais avec des gens de DNV qui équipent les camions de leurs services incendies avec des systemes pouvant recevoir n’importe quelle données géospatiale. On parle vraiment de donner l’information à ceux qui vont sauver des vies.
- Initialement, face à l’absence de données d’entrave routière, MASAS s’est dit qu’ils allaient créer une interface pour saisir les données. Chaque acteur pourra entrer les données manuellement. Sauf que voilà: les villes voulait aussi que ces données figurent sur leur site web, pouvoir le donner à leurs médias locaux, etc. Et ça, MASAS ne voulait pas le faire. C’Est là que 511Ouvert et la décentralisation viennent jouer: Si chaque organisation publie ses données dans un format (ou quelques formats) documentés, MASAS peut jouer un role d’agrégateur: il consomme de l’information. Certains diront ils centralisent, mais ce n’est pas le cas car ils n’obligent pas les organisations à leur remettre leur données. C’est plutôt MASAS qui va chercher de l’information dispo et la fédère pour un usage particulier.