add doc for deployment on web

2025-09-18 14:50:30 +02:00 · 2025-09-18 14:50:30 +02:00 · 3e9d3c838e
commit 3e9d3c838e
parent 339147e762
11 changed files with 309 additions and 469 deletions
--- a/doc/concept_oedb_by_cquest_2017.md
+++ b/doc/concept_oedb_by_cquest_2017.md
@ -0,0 +1,144 @@
+# openeventdatabase.org
+(Article de 2017 https://cq94.medium.com/openeventdatabase-org-f15ccf290537 )
+
+
+Pour plus d’info, contacter: christian.quest+oedb@gmail.com
+
+Dernière avancée:
+
+le premier prototype d’API est opérationnel !
+projet sur github https://github.com/openeventdatabase
+début de documentation sur le wiki de l’API https://github.com/openeventdatabase/backend/wiki
+
+Le concept
+
+- Un calcul d’itinéraire peut avoir besoin de données en temps réel pour s’ajuster: bouchons, ralentissements, travaux, conditions météo. Cela permet de passer d’une appli passive à une appli temp-réel.
+- Que faire ce week-end ? Pour trouver facilement un loisir, une activité proche de chez soi… les spectacles, activités, horaires de ciné. 
+- Conserver des évènements historiques, ou l’historique de géométries changeantes: anciens tracés de routes, champs de bataille, découpages administratifs, frontières… et les évènements passés plus ponctuels.
+
+Dans tout ces exemples, trois informations sont nécessaires: quoi, où et quand.
+
+Aucun projet à l’heure actuelle ne propose de mettre en commun ce type de données. OpenStreetMap répond à quoi et où, mais pas à quand et n’a pas vocation ni à collecter des données “temps-réel”, ni à collecter des données historiques.
+
+Le projet OpenEventDatabase tente de combler ce manque en proposant une base de données géo-temporelles pour échanger des informations de type “quoi / où / quand” de tout type.
+
+Les usages sont très nombreux, comme détecter des “collisions” d’événements:
+
+    une prévision météo incompatible avec un événement sportif: annulation, report
+    un retard de train qui aura des conséquences sur d’autres événements liés (correspondances affectées).
+
+Pour figurer dans cette base, une donnée doit comporter les 3 composantes :
+Quoi: description sémantique
+
+    type d’événement: type=*
+    scheduled : planifié (horaires de spectacles, de transports, travaux, chantiers)
+    unscheduled : accident, bouchon, retard/avance, etc
+    forecast : probabilité issu d’une prévision (modèle météo, récurrence d’événements passés)
+    observed : une mesure météo…
+    autre ?
+    famille d’événement: what=*
+    culture (spectacles, concerts, cinéma, etc)
+    sport (match, entraînements, rencontres, etc)
+    transport (routier, ferroviaire, aérien, maritime, covoiturage, etc)
+    environnement (météo, pollution, etc)
+    autre ?
+    importance ?
+
+Où: composante géographique
+
+    géométrie: geojson
+    lien avec OSM (where_osm) -> non stable
+    lien avec wikipédia (where_wikipedia)
+    lien avec wikidata (where_wikidata)
+    autre liens ?
+
+Quand: composante temporelle au format ISO8601
+
+    gestion des répétitions, des intervalles, des fuseaux horaires
+    avec précision variable :
+    2014: année 2014
+    2014–01: janvier 2014
+    2014–01–07: 7 janvier 2014
+    etc
+
+Metadonnées
+
+    identifiant unique (uuid) attribué par l’API
+    timestamp de création et de dernière mise à jour de la donnée (qui sert aussi au versionning) gérés par l’API
+    source de la donnée (source par défaut et/ou source sur chaque attribut)
+    licence de la donnée (licence par défaut et/ou sur chaque attribut) la base peut collecter des données sous différentes licences ?)
+
+API + dump
+
+A l’instar d’OpenStreetMap, les données seront manipulables via une API, mais aussi sous forme de dumps pour permettre des analyses sur les historiques.
+
+Get Christian Quest’s stories in your inbox
+
+Join Medium for free to get updates from this writer.
+
+L’API doit permettre:
+
+    d’ajouter/modifier un évènement
+    de rechercher des évènements par combinaison de what/where/when
+
+Les résultats de recherche pourront être proposés sous forme geojson (FeatureCollection) de flux RSS ou iCal.
+Le format et l’organisation des données
+
+La description pourra se faire à l’aide d’attributs sur le modèle clé=valeur d’OpenStreetMap
+
+Exemples:
+
+Une séance de cinéma
+
+    what=leisure.cinema.movie
+    type=scheduled
+    when=2014–01–19T13:50+0100
+    where_osm=node:1428007260
+    what_name=Le Loup de Wall Street
+    where_name=Max Linder Panorama
+    wikipedia_what=fr:Le Loup de Wall Street
+    wikipedia_where=fr:Max Linder Panorama
+
+Un départ de TGV
+
+    type=scheduled
+    what=public_transport.train.departure
+    when=2014–01–19T06:23+0100
+    where_name=Paris-Gare de Lyon
+    where_uic_ref=8768600
+    what_operator=SNCF
+    what_ref=TGV6701
+    source=SNCF
+    source_where_wkt=OpenStreetMap
+    licence_where_wkt=ODbL/1.0
+
+Un bouchon
+
+    type=unscheduled
+    what=traffic.jam
+    when=2014–01–19 16:40
+    where_osm=way:68613064
+    where_name=A4 direction Paris
+    source_where= OpenStreetMap
+    licence_where=ODbL/1.0
+
+Une alerte météo de vigilance orange pluie sur un département
+
+    type=forecast
+    what=weather.warning.rain
+    start=2014–01–19T19:00+01:00
+    stop=2014–01–20T06:00+01:00
+    where_name=Var
+    where_osm=relation:7390
+    source=meteo.fr
+
+Les formats d’échange pourront s’appuyer sur: GeoJSON, XML ou autre.
+Resources
+
+http://www.geoevent.net/about/
+
+http://blog.programmableweb.com/2014/02/14/olympics-are-now-a-global-api-event/
+
+https://blog.twitter.com/2014/manhattan-our-real-time-multi-tenant-distributed-database-for-twitter-scale
+
+http://www.journaldunet.com/solutions/cloud-computing/coulisses-techniques-de-twitter/