Journal du montage projet de commun Kit Traces

Image :

Description en une ligne : chrono du montage du projet...

Description : cette page compile les comptes-rendus des contacts pris pour monter le projet de commun "Kit Minimal pour créer gérer partager des traces de Mobilité". La suite sur le site du projet

Prise de note sur le PAD (cocher si Oui) ?

Document Central (CR) :

Evénement lié :

Organisations impliquées :

Contributeurs :

Tags : traces

Thème : Open Street Map OSM, Données ouvertes, Traces de mobilité et des données associées, Logiciel Libre

Animateur Atelier : GENDRE Patrick

Défi lié à l'Atelier : Produire un nouveau contrat social entre les citoyens et les acteurs publics / privés pour augmenter les connaissances et changer les pratiques, Augmenter les connaissances partagées en cartographie et usages des véhicules et réseaux de transports

Commun(s) impliqué(s) : Kit Minimal pour créer gérer partager des traces de Mobilité

Projet en cours à associer :

Communauté(s) d'intérêt impliquée(s) : Communauté autour des traces de mobilité et des données associées

Personnes clés à solliciter :

Actions décidées par les participants : Identifier ou Produire un Commun utile à la communauté

Espace d'échange FORUM :

Espace d'échange CHAT : https://chat.fabmob.io/channel/traces_mobilite

Complément :

Prochaine Etape :

Autres informations :

Chrono:

Les échanges sur le chat Traces de mobilité apportent quelques éléments sur la genèse du projet.

== Le journal s'arrête fin janvier 2019, la suite sur le site du projet

https://chat.fabmob.io/channel/traces_mobilite

journal Traces de mobilités

12/10/18 point sur CozyCloud

participants: Benjamin André CozyCloud, Gabriel Plassat, Patrick Gendre, au tél.

cozy travaille sur projet R+D avec orange labs, data P2P et IA code libre : https://github.com/cozy/cozy-stack, SDK assez documenté et utilisable par des tiers cozy peut apporter un support (dans des limites raisonnables) et des ressources serveur si besoin Il existe des connecteurs, vers Google par ex.

• serveur perso en nodejs ; interroger le cozy perso en REST
• app mobile (ou client "lourd") : https://electronjs.org/
• client web : en cordova (multiplateformes https://cordova.apache.org/docs/fr/latest/guide/overview/) single page app

• BD : couchdb pas optimisé pour séries temporelles, pourrait poser pb de perfs selon ce qu'on veut faire
• autre difficulté : récupérer des données ailleurs que sur cozy, ex. OSM ; à cause de pb de sécurité du genre cross-platform, il faut mettre en place un proxy
• pour l'appli sur les données partagées, ça peut être compliqué aussi, il faut bien réfléchir à ce qu'on veut faire : il faut procéder en 2 phases, d'abord travailler sur la brique de recueil et le cas d'usage individuel. Ex. de use case: le Grand Lyon pour données conso énergie

Résumé sur les use cases: - appli indiv - appli collective : observatoire, enquête, geomarketing, analyse d'un service de mobilité, d'un pôle d'échanges, PDE

Sites - moveinsaclay (assistance ouishare) - CEA Leti - Lyon - Sophia - La Rochelle

Dev: - tristram / codeurs en liberté

16/10/18 Paris Atelier FabMob n°10

CR complet de l'atelier ici : http://wiki.lafabriquedesmobilites.fr/wiki/CR_Atelier_Fabriquer_les_communs_10 Groupe Kit de traçage : http://wiki.lafabriquedesmobilites.fr/wiki/Kit_Minimal_pour_cr%C3%A9er,_g%C3%A9rer,_partager_des_traces_de_Mobilit%C3%A9 Participants: Gendre, Patrick Favre, Jean-Michel, Mobi-Lise Debacque, Theo, Nexterité Billoud, Bertrand, Kisio

où en est-on?

Les briques du projet sont identifiées:

• un territoire et des utilisateurs (Saclay, CEA Grenoble, Valenciennes, La Rochelle;..)
• recueil de traces individuelles : a minima on pourrait utiliser l'API Google mais l'idée est d'utiliser une brique opensource cloud qui permet aux utilisateurs de partager à leur guise leurs données-
• application individuelle : cas d'utilisation, mobilité du quotidien, loisirs etc. à ce niveau il existe des briques open source (carto, SIG, stats)
• application collective

Utilisation collective des traces

Les cas d'utilisation sont nombreuses : observatoire, enquête déplacement, évaluation d'un service de mobilité ou d'une mesure de mobility management ou autres types d'enquêtes (ex. BVA pour Affimétrie...), organisation d'événements (concerts, matches...), plans de déplacement inter-entreprises, marketing mobilité type transway Les EMD "standard" sont lourdes, n'ont pas forcément d'intérêt pour la collectivités, plus pour l'état pour comparer des territoires entre eux, il y a largement autant de demandes de la part des collectivités pour d'autres enquêtes plus ciblées (cordon etc.) liées à des modèles divers L'application a en général besoin de plusieurs sources, pas que des traces -> débit de trafic, OD, fréquentation TC Un use case "pédagogique" dataviz serait pertinent -> ateliers citoyens, devt avec l'université locale, etc.

L'objectif est désormais de concrétiser l'idée avec un démonstrateur au 1er semestre 2019, financé par l'Ademe.

recueil

La brique open source de recueil est à trouver, similaire par ex. à Mobi-lise ou modalyzer. Devt R&D chez Nokia Bell Labs, CEA Leti? cf. aussi app de localisation comme geouniq, roofstreet.io à voir si ça peut être open source, au moins en partie, un peu comme le SDK navitia qui est open source en version expert, pas open source en version UI Les boitiers GPS ne sont pas chers mais pas utilisables en pratiques si bcp d'usagers pour une enquête par ex.

Un obstacle est le recrutement d'utilisateurs, i.e. de convaincre un nb suffisant d'utilisateurs d'installer l'app, de l'utiliser, de laisser leur téléphone allumé etc., sans même parler d'accepter que leurs données soient partagées. il y a un biais bien sûr à traiter dans les utilisateurs qui acceptent d'être tracés Idéalement la brique recueil aurait une petite empreinte et serait ajoutée à une appli existante par ex. appli de collectivité ou de réseau TC... Les données produites dépendent de l'application : détection de mode, temps réel ou pas

Brique open source pour la détection de modes :

• contacter Nokia Bells Labs (ex Alcatel R&D à Nozay)

-> RDV Ayoub Benyahya 7/11, Eric Lacombe

• outil david montoya thèse Cachan

https://montoya.one/publication/hupme-bda-2014/ https://thymeflow.com/ http://www.theses.fr/2017SACLN009

• https://github.com/sobri909/LocoKit

Autre outils :

• modalyzer : https://www.modalyzer.com/fr/how-to app gratuite allemande de recueil de traces smartphone et calcul offline d'itinéraires multimodaux, marche bien. Semble plutôt financé par la recherche publique. Est très proche de ce qu'on veut faire mais pas open source. Les contacter
• motion tag https://motion-tag.com/en/mobility/ Offre Mobility Analytics précisément sur le créneau que nous visons, SDK (10k€?)
• roofstreet https://roofstreet.io/mobilite/ startup parisienne avec une offre qui ressemble à celle de motion tag, plus sur le créneau de l'analyse de fréquentation des commerces ("retail") que sur celui de la Mobilité mais à contacter!

exemple de Mobi-Lise

Pour Mobi-lise le principal cas d'utilisation est de produire les OD alimentant des modèles multimodaux. MOBI-LISE (MLH SAS) -> Expérimentations : Niort, Reims, Besançon, Corse (déplacements touristiques), suivi technique par Olivier Richard Cerema spécialiste EMD (qui a quitté le Cerema depuis) Source de données: en pratique l'API de Google (il y a encore des erreur de détection de mode mais ça marche assez bien), l'appli de l'Université UTBM.

Le point clé est de détecter les changements de mode, c'est plus déterminant que la détection des modes eux mêmes 2h heures d'autonomie, une mdevt Fesure chaque 5 secondes

Il faut utiliser d'autres capteurs que l'accéléromètre : antennes GSM, Wifi, bluetooth...

Découpage d'une boucle en trajets d'une trace complète, à un niveau de détail car ensuite les traitement sont fait offline en BD, les itinéraires sont map matchés et ajoutés à la base d'OD. On peut identifier par exemple des covoiturages possibles Un questionnaire limesurvey est intégré à l'appli mobile pour compléter l'info fournie par les usagers d'une manière plus simple à renseigner qu'une enquête téléphonique lourde Plusieurs utilisations de l'application mobilise sont possibles

Nexterite

A développé un service http://www.nexterite.com/nextalert-en-temps-reel/ utilisant l'analyse de texte pour améliorer l'information déplacement, alertes TC (intégré à RATP et SNCF en ID) et trafic à partir de l'analyse twitter notamment ;

suite de l'atelier

• mise à jour du WIKI et GDOC (https://docs.google.com/document/d/1dQGivhExtOTowCjapXk4z4gUPJct6_kH7RAXyXlXG54/)

• contacter développeurs App recueil mobilité (Nokia Bell Labs...), développeurs intéressés par le projet, quelques territoires pour définir un cas d'usage cible
• besoin de la présence des collectivités pour identifier les besoins en termes de traces de mobilité.

--> piste de contact avec Valenciennes sur le sujet des traces de mobilité

30/10 vu le chat fabmob, permet de savoir qui s'intéresse à quel sujet ex. https://chat.fabmob.io/https://chat.fabmob.io/channel/traces_mobilite

31/10 : standard de description de données de traces?

Christophe Duquesne signale qu'un travail de modélisation des données de traces de déplacements a été fait au niveau européen http://www.transmodel-cen.eu/ A voir si utilisable, en tout cas la modélisation et les formats d'échange des données sont un point clé Cf. aussi la description des données dans cozy : https://docs.cozy.io/en/cozy-doctypes/docs/README/

31/10 : le projet MesInfos de la FING

Marion Molins FING, Gabriel Plassat, Patrick Gendre, au tél.

mesinfos

Expérimentation en 2016-2018, résultats très complets publiés. Le projet http://fing.org/?MesInfos,258 site pilote : La Rochelle lié au groupe "mobilité" de la FING et à la réflexion initiés par fabmob autour du compte mobilité http://wiki.lafabriquedesmobilites.fr/wiki/Compte_Mobilit%C3%A9

calendrier: pas de dev en 2019, d'abord la réflexion collective sur le besoin 1) d'ici avril: réflexion, exploration -> recensement des données utilisables concrètement à la Rochelle ("data blitz"), centrées sur données perso / self data 2) scénario de dev/mise en oeuvre 2020 d'ici l'été

Ateliers

Les 1ers ateliers (11/10) ont permis d'identifier les use cases prioritaires

• budget mobilité
• co2
• contribuer à repenser l'offre de mobilité
• tourisme / loisirs / evénementiel
• (pas abordé encore : pro, marchandises)

Prochains ateliers: 17/11, 12/2, 16/5 + Paris: 28/3,2/7 avec d'autres villes

lien possible avec le projet de commun Traces

intérêt fort de Marion, objectifs proches de MesInfos / mobilité. contact pour le dev : Guillaume Jacquart (connait cozy, resp. technique du projet mesinfos poue La Rochelle)

protection des données personnelles

En lien avec le RGPD, Gabriel a initié une page sur la récup de données, http://wiki.lafabriquedesmobilites.fr/wiki/R%C3%A9cup%C3%A9rer_vos_donn%C3%A9es_personnelles_de_mobilit%C3%A9 exemple de trainline donné dans le blog de Antoine Augusti (EIG etalab) https://blog.antoine-augusti.fr/2018/10/visualizing-my-train-journeys-thanks-to-gdpr-and-trainline/

cf. aussi PO Dehaye en Suisse https://www.linkedin.com/in/paulolivierdehaye https://personaldata.io/ ou en France https://www.onecub.com/

7/11/18 : brique de traçage, contact Nokia Bell Labs

Call conf avec Ayoub Benyahya, chercheur à Nokia Bell Labs, Saclay

projet movinsaclay

http://www.moveinsaclay.fr/publications/ cf PPT de présentation appli mobile développée en interne (code IOS: swift, code Android : java):

• sur IOS : utilise locokit (https://github.com/sobri909/LocoKit) pour la détection de mode (pas encore porté sur android); + fin que sur Android, distinction bus / VP / moto notamment;
• l'app Android utilise le SDK Android

• remontée des données via API "motion" (déployé sur AWS) puis remontée via bus temps réel kafka sur serveur pour analyses et dashboard ; ça permet de faire remonter des données d'autres sources de donnée que l'app

Ils n'ont pas fait encore de tests importants pour qualifier le recueil et la détection de modes mais ça l'air de marcher correctement. Ils envisagent de redévelopper en interne côté serveur une détection de modes (en utilisant aussi la connaissance de l'offre de transport, pas que les infos des capteurs comme le fait locokit). https://github.com/sobri909/LocoKit Ils ont fait un petit état de l'art mais n'ont pas vraiment trouvé d'alternatives pour le recueil (ils ont pris contact avec MotionTag/Modalyzer mais c'est cher et pas open source bien sûr).

L'appli mobile a d'autres fonctions que le recueil de traces : profil utilisateur (permettant de calculer les coûts et émissions de déplacements), incitation financière (wallet/tokens: système de points mobilité), visu des données indiv, enquêtes (liemsurvey)... Les données sont remontées en t réel (chaque 5') mais surtout traitées en t différé (observatoire). La solution de dataviz de l'observatoire est développée par Nokia (Helsinki, logiciel closed source), ensuite pour MoveInSaclay il n'y a plus qu'à définir les vues qu'on veut afficher à partir des données en base.

L'idée est d'ajouter aussi la fn de recueil de traces, et de points mobilité sur d'autres applis, comme le navigateur transdev (développé pour le projet M2I) et le navigateur de St Quentin en Yvelines (VIAGO?). Donc l'app de recueil n'a pas vocation à devenir un produit, elle ne sert que pour des tests, l'app devrait pouvoir être mise en open source, par conséquent. Pour la partie serveur, les API seront publiques, mettre le code open source est en discussion.

Pour l'instant Nokia autofinance les devs mais l'idée est de trouver d'autres financements (AAP MAAS Ademe...).

Les dévts doivent d'un MVP doivent être terminés pour février 2019, ensuite beta-tests avec employés de Nokia, EDF, étudiants supélec, 100 à 500 U.

14/11/18 : contact Développeurs

Au tél: contact avec Francis Chabouis, puis Guillaume Jacquart

Francis était entrepreneur d'intérêt général avec Tristram pour le ministère de l'intérieur; https://github.com/entrepreneur-interet-general/cartav il est basé à Ajaccio jusque juillet, et est disponible à partir de janvier, et est intéressé par la partie dataviz / utilisation des données. Guillaume a des compétences complémentaires de dévt mobile et connait cozy puisqu'il était développeur du pilote mesinfos de la FING, et est conseiller technique pour le projet suivi par Manon Molins. Il n'est pas dispo pour un plein temps mais est motivé pour contribuer à temps partiel sur ce projet vraiment dans la continuité de mesinfos.

cadrage du projet de commun "kit traces"

• le projet consiste bien à développer un outil de recueil de traces sur smartphone avec une appli individuelle pour tirer parti (visu des données) des traces plus un mécanisme de partage des données et une appli, de niveau preuve de concept, tout open source ;
• un point clé est le choix des briques / composants open source
• pour le recueil de traces : peut être locokit via Nokia, mais à confirmer ; la détection du mode de transport n'est pas un pb simple, avec des solutions évidentes sur étagère, a fortiori en open source ; il pourrait être plus raisonnable de voir ce qu'on faire déjà avec les traces qu'on obtenir via le sdk Android ou API Google
• en perspective on peut imaginer de développer un service public / open de détection de mode à partir de traces mais ce serait un autre projet...
• pour le partage de données : l'hypothèse a priori est qu'on utilisera cozy, mais si ça s'est confirmé cela veut dire que l'app individuelle sera développé avec le SDK cozy, il faut s'assurer qu'il n'y aura pas d'obstacle technique. Par ailleurs en termes d'acceptabilité, cela veut dire que les utilisateurs doivent créer un compte cozy
• l'appli individuelle pourrait tirer parti uniquement des données locales sur le tél, sans nécessiter des traitements sur un serveur (selon le cas d'usage, à voir); en tout cas pour l'app mobile il faut surtout faire qc de simple et performant (conso. batterie, etc.), sinon ça sera peu utilisé
• pour l'appli collective, on imagine une appli côté serveur et pas destinée spécialement au mobile, voire que ce ne soit pas une appli packagée mais simplement un notebook python ou R qui permette au réutilisateur d'analyser / visualiser les données, et sur lequel on développerait quelques fonctionnalités (indicateurs, carto ou autre), ça serait plus rapide pour le dev et plus réutilisable, peut être

ébauche de contenu/planning

• une phase 1 pour le socle technique de l'app de recueil de trace et une version initiale de visu des données individuelles

- 1 mois d'étude technique pour valider le choix des briques, notamment cozy ou pas, détection des modes ou pas ; ce sera déjà un "commun" qui peut être intéressant, en parallèle rédaction d'un doc de présentation du projet et des cas d'usage, prise de contacts

- 1 mois de dévt initial, qui permette de mettre en place l'environnement de travail et d'avoir quelque chose à montrer, dialogue sur les cas d'usage

- 1 mois de dialogue avec des sites intéressés et orientation des devs vers le cas d'usage qui se dégage

• phase 2 : partage et réutilisation des données partagées, sur les 3 derniers mois, 3 itérations de 2 ou 3 semaines

- choix du site et en parallèle et mise en place de l'expé

- panel d'utilisateur, 1ère itération

- 2ème itération

- 3ème itération

- bilan

20/11/18 : idée recueil GPS vélo/trottinette

Julien Solé, à Marseille : idée de mesurer la qualité chaussée / les vibration sur smartphone couplé à parcours GPS ; c'est un point clé pour les usagers de trotinettes ou autres, peut être un peu moins pour les vélos.

28/11/18 préparation inout Rennes mars 2019?

https://www.inout2019.com/

Gabriel et la FabMob ont l’opportunité pendant InOut Rennes 2019 (fin Mars) de proposer un « tracking citoyen » des participants et des citoyens de Rennes. Selon l’avancement coté dév, cela pourrait être intéressant pour tester mais on ne peut pas savoir aujourd’hui. Je proposerai de partir d’une app de tracking existante. Nous pourrons utiliser cozy qui est disponible. La question devient : comment utiliser inout pour faire avancer notre projet de tracking + self data ? quels sont les points que nous souhaitons valider ?

Par exemple, nous pourrions fixer un nb de personne maxi : 20 ou 50 par exemple, leur proposer de charger l’app et de se tracer. Puis de les former pour transférer leur data dans cozy (ou autre), puis visualiser leur data. Puis de commencer à voir les conditions / modalités pour partager / utiliser leur data.

On pourrait **orienter le projet et l'atelier InOut si on confirme, sur des objectifs "pédagogiques"**, c'est-à-dire de viser un public étudiant ou en tout cas réutilisateurs potentiels, produire des explications sur ce qu'on fait à mesure qu'on avance. "approche exploratoire au sens des sciences sociales" : l’idée de ce commun est d’outiller les programmes de recherche sociale avec un actif leur permettant d’explorer le contrat social collectivité/citoyen/entreprise

Compte tenu de nos ressources limitées, du délai limité, du cahier des charges très large pour l'instant, on ne peut pas prétendre produire de nouvelles briques techniques, ou fournir une appli packagée, ou même des résultats intéressants en termes de gestion des mobilités, on n'en est pas là : c'est une phase de PoC donc de test.

Le projet Traces n'est pas porté par une entreprise qui ferait ensuite évoluer le PoC pour créer un produit ou un service. A la fin du projet il faut qu'il reste des éléments/communs réutilisables (ce pourrait être des tutos, un blog technique, en plus du code), et qu'on ait identifié une communauté d'intérêt technique pour réutiliser les briques, et éventuellement continuer ce qui aura été commencé.

Sur le côté pédagogique, avec objectifs de motivation de réutilisateurs : tout dépend du public de l’événement : il s’agit de citoyens très acculturés au sujet ? De développeurs potentiels ?

Si on part pour Rennes d'une app de traçage déjà existante, il est normalement assez facile de récupérer ses données de géoloc’ Google (le connecteur n’est pas déjà déjà présent dans Cozy ?) Pour un public de réutilisateurs, l’atelier pourrait réunir une vingtaine de personnes (en s’assurant qu’ils aient déjà été tracés par google depuis longtemps, s’ils téléchargent l’app le jour de Inout ils n’auront que trop peu de données pour en tirer des visualisations) pour :

1) ouvrir un Cozy

2) activer le connecteur Google

3) télécharger une app « visualisation de ses données de géolocalisation sur une carte » (et donc il faut construire cette application - guillaume l’avait fait pour les données de géoloc orange avec "mapping my life")

4) next steps et présentation des outils pour rejoindre la démarche du projet « Traces » (ce que tu disais patrick sur les éléments réutilisables)

Pour un public de citoyens non acculturés, ouvrir un Cozy est déjà en soi un grand acte … Pour du one-shot (si on ne les revoit plus jamais) je ne vois pas trop l’intérêt de faire pareil que pour les développeurs ? Par contre dans une approche de data literacy, sans Cozy (et donc sans avoir besoin de développer l’app cozy pour mars), il leur suffit d’un ordi chacun :

1) téléchargement du fichier CSV de sa géoloc (ex : via google takeout - je suis sûre que les étapes sont documentées quelque part)

2) Création d’une carte web : https://www.dropbox.com/s/u7c5syiqn50j5kw/03-%20Cr%C3%A9er%20une%20carte%20web%20%C3%A0%20partir%20de%20donn%C3%A9es.pdf?dl=0

3) Discussion autour des futurs usages possibles et de leurs intérêts à partager ces données

Dans les deux cas, une « simple » dataviz suffirait pour leur faire exprimer leurs attentes : "c’est quoi la prochaine fonctionnalité ? Comment on met en place le partage et pour quoi ? ». , répondre à cette question est utile pour nos deux projets Trace et Self Data Territorial.

28/11/18 veille thèse David Montoya Thymeflow

la thèse de David Montoya est vraiment sur notre sujet, et on sent qu'il y a de vraies difficultés techniques (sur la détection de modes entre autres) https://www.theses.fr/2017SACLN009 apparemment pour son proto hup me il a stocké les données dans cozy tout ça me confirme dans l'idée qu'il va falloir bien cibler ce qu'on fait (trouver les bonnes briques, connaitre l'état de l'art), ne pas viser des résultats trop ambitieux David a créé une société Thymeflow mais a dû jeter l'éponge, apparemment il travaille désormais pour la société square-sense.com

cf. aussi cet atelier animé par Serge Abiteboul sur les données perso en mai 2018 https://fetedeslibertesnumeriques.org/evenements/

Il faudrait contacter Serge Abiteboul et David Montoya pour des conseils, savoir par où commencer, sur quoi il est réaliste d'obtenir des résultats

28/11/18 fondation VW open source lab?

Gabriel rentre de Berlin où la fondation VW ouvre un Open Source Lab J Ils sont super intéressés par la Fabrique et notamment le projet de traceur !

29/11/18 projet EU Motiv traces vélo app woorti

contact FUB Carole Kaouane

Projet H2020 https://motivproject.eu/ projet MoTiV :mobilité et valeur du temps.

L'application associée (Woorti : worthliness of time) permettra de collecter de la donnée, en open data à la fin du projet, et le code source sera aussi sous licence libre. L'étude des données permettra de mettre en avant les facteurs clés qui influencent la mobilité du quotidien au niveau individuel (besoins, envies, services disponibles...)

L'application sera testée en France au mois de janvier 2019 pour une collecte de données entre mars et juin 2019.

3/12 projet e-mission Berkeley (data logger open source)

projet de recherche à Berkeley https://e-mission.eecs.berkeley.edu/#/home

https://people.eecs.berkeley.edu/~shankari/emission_trb_2017_paper.pdf

C'est open source, une app js cordova et un serveur node pour suivre ses traces multimodales, c'est un proto et le projet date de 2017 mais c'est quand même à creuser. https://github.com/e-mission

échange avec la chercheuse de Berkeley qui développe e-mission, confirmation de l'intérêt de partir de e-mission pour le projet "kit minimal de gestion des traces de mobilité" création d'une fiche pour décrire e-mission sur le wiki : http://wiki.lafabriquedesmobilites.fr/wiki/E-mission_GPS_tracker_Berkeley

9/01/2019 hébergement des applications e-mission

Echanges avec Benjamin https://ficusnode.com/ : Le projet va s'appuyer sur une suite de logiciels existants développé en mode R&D, appelée e-mission.

• ça comprend une partie front en node.js / cordova et une partie back en python (jupyter notebook) + mongo
• pour l'instant on ne sait pas si on intégrer cozy dans le projet, c'est envisagé en effet mais pas à court terme

La doc d'install minimale (avec le serveur dans un conteneur) est ici: https://github.com/e-mission/e-mission-docs/blob/master/docs/overview/quickstart.md L'idée est que le framework e-mission ait juste besoin d'être adapté pour chaque nouveau site pilote, en modifiant uniquement les vues côté front/phone, sans toucher au serveur, rendant ainsi l'outil beaucoup plus simple à adapter et donc à utiliser. Y compris dans le cadre d'ateliers sur de 2 ou 3 jours, exemple : https://github.com/e-mission/e-mission-docs/blob/master/docs/workshops/fall_2018/hands-on-overview.md La doc complète d'install serveur est ici (a priori on en aura besoin) : https://github.com/e-mission/e-mission-docs/blob/master/docs/e-mission-server/deploying_your_own_server_to_production.md

Le mieux d'avoir une machine dédiée où on pourrait créer nos VM ou conteneurs, sous linux (debian).

11/01 Idée capteur de pression

Suggestion de Tristram : utiliser si disponible l'info de capteur de pression atmo du smartphone : utile d'une part pour mesurer le dénivelé (marche, vélo) d'autre part la profondeur d'un trajert souterrain (métro)

16/01/2019 Recrutement du développeur

Sur la base de ce cahier des charges: Évaluation R&D de e-mission , suite de logiciels libres de recueil / analyse de traces de mobilité et après consultation de plusieurs développeurs freelance sur malt.fr, codeurs en liberté, happy-dev.fr... on a retenu Fouad Khodja, de la société IC-IA, qui a une longue expérience sur des projets du domaine transport, en mode R+D et en mode opérationnel, et utilise au quotidien les technologies choisies dans e-mission : cordova/js pour la partie mobile, python pour la partie back-end.

Le projet démarrera la semaine du 21/01 !

24/01 contact avec le Cerema

Nicolas Nuyttens (DTecTV Lyon) et Maria Tebar (Lille) travaille sur les enquêtes de mobilité, dites aussi Enquêtes Ménages sur les Déplacements (EMD). Ils s'intéressent notamment aux applications smartphone ou autres boitiers GPS comme compléments aux enquêtes Certifiées Cerema. Le Cerema se pose des questions autour des applications smartphone et des boitiers qui permettent de recueillir des traces GPS : Quelles utilisations ? Quels objectifs ? Quelle fiabilité ? Quelle représentativité ? Quelles analyses ? Il y a des incertitudes méthodologiques et techniques à la fois. Ces nouveaux outils ne sont sans doute pas une alternative aux enquêtes "EMC2", mais complémentaires.

En particulier, les GPS/Smartphones apportent : - des temps de parcours plus précis que ceux qu'on peut tirer des EMD - des itinéraires parcourus (les EMD ne donnent que des origines - destinations) - la possibilité d'interroger des populations qui sont mal représentées dans les échantillons des EMD, notamment les étudiants

Depuis quelques années, le Cerema réalise des tests divers avec ces différentes sources de données mais ces tests ne sont pas encore terminés. Ils ont observé le potentiel des boitiers qui recueillent des traces sans pour autant avoir une interaction avec la personne ou le véhicule. En 2019, l'objectif est de creuser le monde des applications smartphone qui permettent "de suivre" des personnes, d'où un lien possible avec le projet Traces FabMob. Le Cerema va tester plusieurs applications existantes et voir le potentiel de chacune, puis les avantages et les inconvénients pour les introduire dans une méthodologie d'enquête : de l'échantillonnage à l'analyse des résultats. Par exemple, l'application itinerum développée par l'U de Concordia à Montréal, ou l'application développée par Alyce pour la CTC en 2018. Le travail est complexe car il existe de nombreuses applications en plus de certaines applications qui sont plutôt virées à un produit commercial. Étant donné que ce travail est dirigé vers les collectivités, le Cerema s'oriente plutôt vers un produit "open source" ou libre d'utilisation, donc l'évaluation de l'app e-mission va être intéressante à ce titre. Selon les objectifs du site pilote retenu pour le PoC avec e-mission, le Cerema pourrait contribuer à l'évaluation.

25/01 première install !!

Fouad et Yann ont installé le serveur et l'app e-mission, l'ensemble fonctionne ! A suivre désormais sur le site du projet (qui va encore évoluer)

30/1 intérêt de la Rochelle

Echange avec Valérie Steiner, de la ville de la Rochelle, qui participe au projet self data territorial de la FING. Un gros travail d'expression et d'analyse des besoins des utilisateurs est réalisé actuellement par ateliers. L'application e-mission peut être intéressante pour la Rochelle à condition que la protection de la vie privée et la possibilité de réutiliser et partager les données recueillies soit bien prise en compte. Il est apparu que de nombreux usagers pourraient accepter d'utiliser une app et d'être tracés dans le cadre d'un PoC à condition qu'il puissent avoir d'autres usages de leurs données que celles prévues dans le cadre du PoC/pilote, de partager leurs données avec qui ils veulent (les stocker dans un cloud personnel), ou de pouvoir les croiser avec des données publiques open data (par ex. accidentologie, logement, etc.). Des sites pilotes potentiels à la Rochelle sont le grand port maritime pour l'analyse de la mobilité des 2000 personnes qui y travaillent, l'université (qui travaille sur un projet ANR Ecomob), et la ville elle-même dans le cadre de la suite du projet FING MesInfos au 2ème semestre 2019.