Open Event Database : le retour?

Communs et géocommuns Géocommuns potentiels
1

Open Event Database

alias OEDB pour les rares intimes

C’est un projet que nous avions mis en place suite au hackathon “Nec mergitur” organisé par la Ville de Paris et la Préfecture du Police suite aux attentats de 2015.

L’idée de départ:

  • OSM c’est très pour savoir QUOI + OU, mais pas QUAND (pas d’informations temporaires dans OSM)
  • créer une base collaborative complémentaire, ouverte, qui répondrait à QUOI, OU et QUAND

Le QUOI pouvant être de nature très variable, sur le modèle d’OSM où le système de tags n’a pas été prédéterminé et n’a donc pas limité artificielle les thématiques.

Un évènement au sens OEDB, ça peut être quelque chose de :

  • planifié (travaux, match, vide-grenier, marché),
  • d’imprévu (accident, panne),
  • une observation
  • une prévision (météo, crue)

QUAND: un événement peut avoir une date de début et de fin ou être ponctuel.

OU : un événement est attaché à une géométrie, ponctuelle (un accident de la route), linéaire (un bouchon) ou surfaçique (un feu de forêt).

QUOI : un tag hiérarchique permet de décrire de quoi il s’agit, exemples:

  • traffic.roadwork : des travaux sur la route
  • traffic.accident : un accident de la route
  • culture.music : pour un concert
  • fuel.price : pour les prix des carburant
  • health.check : un contrôle d’hygiène
  • meeting.linux.install-party : pour une install party Linux
  • nature.earthquake.8 : pour les tremblements de terre d’une magnitude supérieurs ou égale à 8
  • nature.radiation : pour les contamination radioactives
  • public_transport.delay : un retard dans les transports publics
  • public_transport.incident.unattended_luggage : un colis suspect…
  • sport.bicycle.tour_de_france : les étapes du Tour de France
  • sport.competition.olympics.athletics : les compétition d’atlhétisme aux JO
  • sport.match.soccer.euro2016 : les match de l’Euro2016 de football
  • weather.alert.avalanche : risques d’avalanche
  • weather.alert.flood : risque de crue
  • weather.alert.hightemp : alerte canicule
    etc…

Une API publique est toujours fonctionnelle… voici le endpoint des stats:

https://api.openeventdatabase.org/stats

Il y a plus de 13 millions d’événements actuellement dans les base, l’essentiel étant créé par des scripts qui soit reprennent des données opendata (comme les prix des carburants, les vigilance méteo) ou qui scrappent certains sites (sytadin, RATP, etc).

Cette dimension événements permet d’envisager une version libre et ouverte de l’incontournable Waze (c’était mon idée d’origine… compléter OSM pour faire un waze-like), mais on peut aller bien au delà en ne se limitant pas à l’unique aspect circulation routière.

Des tests avaient été faits avec la Préfecture de Police pour la diffusion d’alertes via les applis de tous les jour, plutôt que de créer une n-ième appli dédiée (RIP SAIP !). Maintenant il y a FR-ALERT qui devrait répondre à ce besoin.

Quelques services publics avaient manifesté leur intérêt. Le SAMU 45 avait par exemple diffusé en temps-réel ses interventions sur le terrain sur OEDB.

Le code de l’API est sur github:

7 Likes
2

L’idée d’une base ouverte de ce type serait effectivement intéressante à différents égards mais le travail est assez colossal de par la diversité des sources et la quantité de données à traiter. Nous avons essayé de mettre en place une approche similaire pour alimenter en données variées nos différentes applications (comme Akt’n’Map) ou celles de nos clients. A chaque jeu de données (eg Catalogue cartographique | Akt'n'Map) correspond un service autonome (eg GitHub - kalisio/k-hubeau: A Krawler based service to download data from French open API Hub'Eau) déployable sur une infrastructure et qui en gros alimente une table dans une base de données. Chaque job est construit de façon assez similaire en utilisant un petit ETL (GitHub - kalisio/krawler: A minimalist (geospatial) ETL), ce qui en simplifie la maintenance sur le long terme.

Le modèle de donnée est très basique, ce qui le rend très générique, une feature GeoJson (point, linéaire ou polygone) avec un timestamp: Services | KDK. Quelques spécificités permettent ensuite de traiter des données de type séries temporelles acquise par des capteurs mobiles ou non: Services | KDK.

L’idée des tags à la OSM parait très bonne pour permettre de “naviguer” selon certaines thématiques dans l’ensemble des données. En effet de notre côté les données sont pour l’instant classées plutôt par “source” et les sources structurées le plus souvent selon des catégories dans un catalogue thématique.

Je crois qu’un aspect déterminant est le fait de savoir si l’on ne se concentre que sur des évènements “ponctuels” dans le temps, ie de type alertes, ou si l’on souhaite gérer des séries temporelles. En effet, celles-ci nécessitent le plus souvent des outils et optimisations spécifiques. Je suis d’ailleurs surpris par le faible nombre d’éléments dans la base actuelle depuis ces nombreuses années car si l’on s’interresse à des données comme les stations de mesure du niveau d’eau du BRGM l’ordre du million d’éléments est plutôt ce qu’on obtient pour quelques jours d’exploitation.

De notre côté, nous souhaiterions archiver ce type de données sur le long terme, mais nous n’en avons clairement pas les moyens. A mon sens, l’archivage long-terme nécessite un reformattage et des traitements de simplification pour être viable sur des séries temporelles. Mais il aurait une grande valeur pour réaliser des REX et analyses de données diverses (eg IA).

Au final, il s’agit d’agrégger diverses bases de données selon un modèle de données commun. Nous avons pu échanger à ce sujet avec certains acteurs animant les sources de données, et ce type d’approche est souvent mal perçue car les fournisseurs mettent le plus souvent en place des API pour consommer directement leurs données à la demande (en gros depuis un client) et non pas les “télécharger” dans une base tampon. Se pose par exemple parfois des problème de sunchronisation si des modifications sont appliquées sur des données du passé. Je ne sais pas si vous avez eu des retours similaires concernant votre base ?

Il me semble que la force d’OSM est d’avoir proposé un modèle de données commun mais d’être aussi devenu “la source” de données de référence et non pas uniquement un aggrégateur. Mais “obliger” tous les fournisseurs de données à pousser dans une base de ce type me parait assez utopique.

3

Oui, c’est un projet utopique, OSM ou wikipédia aussi l’étaient quand ça a démarré.

Personne n’est obligé à quoi que ce soit, c’est juste un moyen générique de partager ses données.

Pour le stockage/Archivage des mesures, c’est un challenge technique…

Les choix que j’ai fait pour le PoC actuel sont légers:

  • postgresql + postgis
    • une table “événements”, avec quelques index “qui vont bien”
    • une table des géométries liées aux événements (car souvent redondantes, surtout pour les surfaciques administratives)
  • une API légère codée en python (moins de 500 lignes)
  • que du geojson en entrée et sortie, directement consommable par des outils géo

Les scripts qui alimentent le PoC sont de mini ETL qui vont récupérer les données, les remettent en forme pour les envoyer à l’API OEDB. Certains sont plus complexes car mettent à jour l’événement au fur et à mesure. C’est le cas pour tout ce qui est accident/incident, qui apparaît à un moment donné, puis disparaît.

Dans les requêtes sympa, j’avais implémenté la recherche d’événements à proximité d’un itinéraire (linestring).

1 Like
4

Oui c’est sûr que tout le monde n’aurait pas parié sur OSM à ses débuts, ce qui “oblige” à un moment est la large adoption, le standard de facto.

La gestion communautaire de réseaux de capteurs nécessite pour être menée jusqu’au bout d’aller déployer et de maintenir opérationnels des éléments sur le terrain, ce qui me parait être une tâche plus complexe que de se limiter à fournir une base de données. Mais il y a des projets très intéressants à ce sujet comme OpenRadiation, OpenAQ, Centipede RTK, … Souvent leur est reproché le fait de ne pas apporter une garanti de “fiabilité” car non opérés par des acteurs “reconnus”. Des processus de “validation” des données devraient être adjointes mais nécessite de la connaissance en métrologie.

Quoiqu’il en soit fournir dans un premier temps une API pour lire/écrire des événements spatio-temporel serait déjà un premier pas. Il est par exemple aujourd’hui assez difficile de simplement récupérer des informations sur le traffic ou les accidents comme vous l’indiquiez en parlant de waze, les données sont disparates et disponibles ou non suivant les départements.

Les contributeurs devraient donc être des experts en traitement de données dans un premier temps. Peut-être faut-il que chacun puisse utiliser l’ETL de son choix pour pousser des données dans la base et proposer une sorte d’architecture modulaire ou chaque contributeur serait responsable du traitement de certaines sources plutôt que de tout centraliser à un endroit ? Je ne sais pas si la GeoPlateforme pourrait fournir ce genre de service.

5

Petite musique qu’on a toujours entendu côté OSM aussi… validation, données certifiées devenue ensuite données d’autorité.

Pour OEDB, les mesures continues ne sont peut être pas envisageables à grande échelle, mais les mesures anormales peuvent être considérées comme des événements.

J’avais par exemple repris les données de l’USGS pour les tremblements de terre, au delà d’une certaine magnitude.

Les ETL ne sont pas complexes à mettre en place dans bien des cas, lorsque les données sont diffusées en tant données, sauf aquand leur mode de diffusion change.
Ce qui est plus complexe, ce sont les données récupérées par scrapping car non diffusées officiellement en tant que data. Là ça change beaucoup plus souvent, et il faut vite s’adapter.

6

C’est un sujet qu’il faudrait pousser aux oreilles de osmand qui pourrait implémenter une saisie rapide de blocage (type wa ze)
Je sais que osmand a essayé d’implémenter une système de notation pourpre les poi mais ça n’a jamais décollé.

7

Je ne connaissais pas le projet. C’est cool.
Quand j’ai vu le terme “évènement” j’ai immédiatement pensé au schéma event de schema.org : Event - Schema.org Type.
Je ne le cite pas pour dire que le modèle de données OEDB n’est pas adapté ni qu’il est trop simple c’est juste que :

  • je me dis qu’en regardant ce schéma il y a peut-être quelques petites choses intéressantes au regard de certains usages
  • je me dis qu’il existe une tonne d’évènements dans la nature qui sont disponibles sur le web (et documentés avec ce schéma) et qui seraient peut-être réexploitables
  • il y a peut-être là une manière d’être interopérable avec d’autres systèmes (dites-le une fois)

Bon voilà, c’est peut-être complètement idiot.

1 Like
8

Ça pourrait être intéressant de relancer le projet en se focalisant sur des thématiques précises. Par exemple, suivre les événements de sécheresse (arrêtés sécheresse), les événements climatiques, etc.

Faudrait aussi voir comment on fait le lien éventuel entre un événement OEDB et une entité Wikidata et un objet OSM.

9

Vu qu’on risque d’avoir plusieurs événements pour un même objet wikidata ou OSM, c’est côté OEDB qu’il faudrait permettre de rechercher les événements liés à un objet à partir de son ID externe et pas juste par la position géographique.

Il suffirait de se mettre d’accord sur un champ du json et de l’indexer.

J’avais créé des événements avec des champs:

  • where:osm
  • where:wikidata
  • where:wikipedia

Exemple:

{
"stop": "1992-09-27 02:00:00+01",
"type": "scheduled",
"what": "time.daylight.summer",
"start": "1992-03-29 03:00:00+02",
"where:osm": "relation/1403916",
"where:wikidata": "Q212429",
"where:wikipedia": "fr:France métropolitaine"
}

Oui, ce sont les périodes d’heures d’été et d’hiver en France :wink:

1 Like
10

Exemple d’événements où figure une référence wikidata:

http://api.openeventdatabase.org/event?what=sport.competition.olympics.marathon_swimming&start=2000-01-01

{
  "count": 2,
  "features": [
    {
      "geometry": {
        "coordinates": [
          -43.18742,
          -22.9867
        ],
        "type": "Point"
      },
      "properties": {
        "createdate": "2016-08-03T22:53:12.256685",
        "id": "42ef9a43-cf9c-48c2-940d-afa5d0036256",
        "lastupdate": "2016-08-03T23:11:09.927384",
        "lat": -22.9867,
        "lon": -43.18742,
        "name": "Marathon Swimming - Men's 10km",
        "source": "https://www.rio2016.com",
        "type": "scheduled",
        "what": "sport.competition.olympics.marathon swimming",
        "when": "2016-08-16T12:00:00Z",
        "where:name": "Fort Copacabana",
        "where:wikidata": "Q5470982"
      },
      "type": "Feature"
    },
    {
      "geometry": {
        "coordinates": [
          -43.18742,
          -22.9867
        ],
        "type": "Point"
      },
      "properties": {
        "createdate": "2016-08-03T22:49:25.941359",
        "id": "8a89803d-8e7d-4622-9b83-1dee4aefc7b8",
        "lastupdate": "2016-08-03T23:11:09.927384",
        "lat": -22.9867,
        "lon": -43.18742,
        "name": "Marathon Swimming - Women's 10km",
        "source": "https://www.rio2016.com",
        "type": "scheduled",
        "what": "sport.competition.olympics.marathon swimming",
        "when": "2016-08-15T12:00:00Z",
        "where:name": "Fort Copacabana",
        "where:wikidata": "Q5470982"
      },
      "type": "Feature"
    }
  ],
  "type": "FeatureCollection"
}

Est-ce qu’une requête de ce genre irait ?

http://api.openeventdatabase.org/event?where:wikidata=Q5470982&start=2000-01-01

C’est maintenant implémenté sur where:osm et where:wikidata :wink:

6 lignes de code de plus et un index dans postgresql… allow searches on where:osm and where:wikidata · openeventdatabase/backend@656c3fd · GitHub

11

Cela pourrait être une partie de la solution à un problème auquel un nombre grandissant de camps scouts sont confrontés chaque été, à savoir la prévention des risques d’incendie par la connaissance des interdictions de faire des feux de camp.

Le contexte : l’association des Scouts et Guides de France envoie chaque année en camp d’été des dizaines de milliers de jeunes dans tout le territoire national.

Or, depuis plusieurs années, ces camps d’été sont de plus en plus soumis à des restrictions liées en particulier au dérèglement climatique, en tout premier lieu des interdictions de faire des feux de camp, en vue naturellement de réduire les risques d’incendie.

Le problème des camps scouts n’est pas de respecter la réglementation (on sait cuire au Butagaz depuis longtemps quand il le faut), c’est de la connaître.

Ces restrictions sont contenues dans des arrêtés publiés par les préfectures. Or une interdiction est un “événement” avec un “où” (une ou plusieurs communes, massifs ou régions, un “quand” (par exemple du 1er juin au 30 septembre). Le “quoi” est aujourd’hui pour nous l’interdiction de faire des feux, mais avec quelque chose comme Open Event Database, rien n’interdirait d’encoder à l’avenir d’autres types de restrictions qui peuvent affecter les camps d’été des scouts.

Si de tels “événements” étaient facilement découvrables et interrogeables, ce seraient des centaines de camps scouts et de guides que nous pourrions aider, à la fois lors de la préparation des dossiers de camp, ou durant l’été par la possibilité d’émettre les bonnes alertes rapidement. Ce serait certainement un outil utile pour d’autres activités de plein air ou même pour les directions départementales Jeunesse et Sports.

Un commun, en somme ?

Les SGDF ont, depuis l’été dernier, une première expérience de moissonnage collaboratif par nos bénévoles, fait à partir des dizaines ou des centaines de registres d’actes administratifs. Nous voulons devenir plus efficace pour les étés à venir, tout en gardant une structure légère et réactive. Travailler avec une telle base de données serait donc d’un grand secours.

3 Likes
12

La base du problème est ici… la culture administrative du document, rédigé, textuel, jamais publié sous forme de données exploitables.

Je vois régulièrement passer des tweets de la préfecture de police avec des jolis plans pour signaler les zones de manifestations. Plans sortis en PDF, qui sortent de plus en plus souvent d’un SIG avec potentiellement des périmètres géo sous forme de données.

Il y a les ZICAD (Zones d’Interdiction de Captation Aérienne de Données, ex ZIPVA), publiée dans un arrêté au JO avec des listes interminables de coordonnées géo obtenus bien sûr à partir d’un SIG mais pas publiées comme données.

En attendant que nos services publics changent de paradigme, on peut chacun de notre côté remettre ça sous forme de données et le publier par exemple dans OpenEventDatabase.

C’est du geojson en entrée, et en sortie, donc facile à manipuler.

Il faut juste s’accorder sur le champ “what”.

1 Like
13

Bah, si à l’occasion de la résolution de notre petit bout de sujet sur les interdictions de feux, nous pouvons montrer l’exemple et contribuer à la solution d’un problème plus vaste, nous serons très heureux.

L’avantage direct pour nous d’adapter (ou faut-il dire adopter ?) Open Event Database est que l’on sait que l’on ne partirait pas sur du spécifique. Bénéfice : gain de temps, gain de jus de cerveau, gain de coût (le temps des bénévoles dans le scoutisme est précieux même quand il n’est pas facturé).

Cela ne nous empêchera pas de nous désoler quand l’info administrative est difficile à extraire, surtout si elle n’a pas de raisons intrinsèques de l’être.

1 Like
14

Je réagis uniquement sur l’exemple des ZICAD, j’ai vraiment un doute sur comment elles ont été définies (SIG ou non) car dans les listes interminables de coordonnées il y a pas mal de choses pas top (en plus du fait que ce n’est pas facilement exploitable), par exemple :

  • Les coordonnées à 183° W pour le centre pénitentiaire de MATA UTU à Wallis-et-Futuna… on dépasse les 180° !
  • Les mêmes coordonnées indiquées plusieurs fois pour le même polygone (P1, P2, P3, P4 puis P1, P2, P3 à nouveau…)
  • Des caractères divers et variés pour les minutes et secondes d’angle… deux caractères minutes ça ne fait pas un caractère seconde :blush:
  • Des espaces au milieu des coordonnées (0 01° au lieu de 001°) ou alors un manque d’espace avant les caractères degré, minute, seconde…

J’ai dû retravailler le fichier d’origine à la main avant de pouvoir convertir les zones en géométries correctes.

15

Le fichier géo est dispo sur data gouv !

16

Maintenant oui mais tout début janvier ce n’était pas le cas.

17

Bonjour
Il faudrait vraiment faire du lobbying auprès de l’état pour que ces interdictions de faire du feux soient publiés comme données sur le data.gouv. Ces décisions ne seront plus “anecdotiques” :frowning: et concernent vos milliers de jeunes et des milliers de randonneurs.