armgilles / vcub_keeper

Analyse de l'activité des stations Vcub dans la métropole de Bordeaux afin de détecter en amont les stations hors service

vcub_keeper

Analyse de l'activité des stations Vcub dans la métropole de Bordeaux afin de détecter en amont les stations hors service

Impossible de valider la prise d'un vélo (absence de bouton "validation") sur une station quasi pleine.

Problème :

Je suis un grand utilisateur du service Vcub (vélos en libre-service) à Bordeaux. Le problème c'est que trop souvent à mon gout, j'arrive à une station pour prendre un vélo et celle-ci est hors service ce qui provoque une certaine frustration...

Il n'est pas question ici de prédire le nombre de vélos disponibles à la station afin de ne pas tomber sur une station vide, mais bien d'arriver à prédire le fait que la station soit HS avant que celle-ci soit déconnectée par TBM.

Il peut y avoir plusieurs problèmes (écran HS, application HS, problème dans l'API des cadenas...). Pourtant lorsque l'on a un peu d'expérience, on sait si celle-ci doit être presque vide ou pleine à une certaine heure. Par exemple si je regarde la station des châtrons le matin vers 9H, celle-ci doit être presque vide (en général 3 à 5 vélos disponibles) en semaine. Lorsque celle-ci est pleine le matin, je sais qu'il y a un problème sur cette station.

Objectif :

Analyser les données des stations Vcub de Bordeaux afin de déterminer si la station est hors service (impossibilité de prendre un vélo alors que des vélos sont disponibles) alors que cette station est active.

Prévenir via twitter @TBM_V3 dès qu'une station est détecté comme HS (fonctionnalité dans un autre repo privé).

Data :

Wiki des données utilisées.

Les données proviennent du travail de Damien Garaud via le projet open-source Jitenshea

Installation :

Utiliser le fichier requirements.txt avec pip ou environment_linux.yml pour un environnement conda (tester uniquement sous Linux).

Variable :

Creer un .env à la racine du projet avec :

• API_METEO="YOUR TOKEN HERE" (finalement, la météo n'est plus utilisé dans le projet).
• MAPBOX_TOKEN="YOUR TOKEN HERE" (pour l'utilisation des graphiques avec mapbox).
• KEY_API_BDX="YOUR KEY HERE" (pour l'utilisation de l'API open data de Bordeaux. Pour obtenir une clef)

Études :

Analyse exploratives :

Réduction de dimension (via PCA) sur l'activité d'une station avec plus d'un an d'historique. On peut facilement distinguer les 7 jours de la semaine qui forment des silos. Plus les points sont hauts, plus il y a une absence d'activité sur la station et potentiellement un problème sur la station.

Identique à l'image précédente, mais en 3D afin de mieux observer certains phénomènes.

Prédictions :

Détection d'anomalies sur la station Rue de la Croix Blanche à partir des données en temps réel de la station.

vcub_keeper's Issues

Pas de données de stations pour certaines dates

Il y a quelques trous dans la time serie de l'activité des Vcub :

• Investiguer
• Impact sur les features de type transactions ?

Création d'un fichier de profile des stations suivant leurs activités / fréquences

Objectif :

Différencier les stations selon leurs activités et fréquences.

On ne peut pas comparer lors de la détection d'anomalies une station comme celle de la victoire (très souvent utilisé) à une station en périphérie avec beaucoup moins d'activités.

Si notre station très active à un arrêt d'activité (consecutive_no_transactions_out) de 4 heures a beaucoup plus d'importance que pour une station très peu fréquentée.

Update plot_station_activity function

Pouvoir afficher plusieurs variables pour une même station.

• Le graphique ne pourra afficher qu'une seule station, mais on pourra observer plusieurs features en même temps.

• Permettre de retourner un DataFrame si besoin via argument afin de pouvoir analyser les données de la station.

ref #5

Modification et création du fichier de référence des stations.

Les données de référence des stations ne sont plus accessibles en open-data sur le portail open-data de bordeaux-metropole. Après envoi d'un message, voici la réponse :

Bonjour,

Les données TB_* (obsolètes depuis 3 ans) ont été fusionnées avec le SAEIV  (TBM en temps réel) – tous les détails du nouveau modèle ici : http://data.bordeaux-metropole.fr/forum/viewtopic.php?f=8&t=278
 
Les stations VCUB quant à elles existent en temps réel depuis longtemps dans la couche CI_VCUB_P.

Plus d'informations #47

Actions :

• Création d'une fonction qui permet de télécharger + modifier la structure des données.
• Modification de la fonction de lecture reader.reader.py - read_stations_attributes().
• Update de la documentation data.md.

Warning

Le fichier final après lecture doit respecter la structure suivant (possibilité d'ajout de colonnes si besoin) :

	Geo Point	Geo Shape	COMMUNE	total_stand	NOM	TYPEA	ADRESSE	TARIF	station_id	lat	lon
0	44.8351755,-0.5720497	{"type": "Point", "coordinates": [-0.5720497, 44.8351755]}	BORDEAUX	17	Grosse Cloche (fermée depuis le 26/09/2016. Réouverture prévue septembre 2017)	VCUB	12 place de la Ferme de Richemont	VLS	104	44.8352	-0.57205
1	44.8723721,-0.5906954	{"type": "Point", "coordinates": [-0.5906954, 44.8723721]}	BRUGES	20	Bruges La Vache	VCUB	Rue Léopold Laplante	VLS PLUS	169	44.8724	-0.590695
2	44.8500962,-0.5855819	{"type": "Point", "coordinates": [-0.5855819, 44.8500962]}	BORDEAUX	16	Place Marie Brizard (supprimée le 11 mars 2016 en raison des travaux tram D)	VCUB	209 rue Fondaudège	VLS	35	44.8501	-0.585582
3	44.8492876,-0.4966899	{"type": "Point", "coordinates": [-0.4966899, 44.8492876]}	ARTIGUES-PRES-BORDEAUX	19	Artigues Feydeau	VCUB	22 Boulevard Feydeau	VLS PLUS	150	44.8493	-0.49669
4	44.7821503,-0.5661566	{"type": "Point", "coordinates": [-0.5661566, 44.7821503]}	VILLENAVE-D'ORNON	21	Pont de la Maye (retirée le 19 novembre 2015 en raison des travaux d'extension du tram C)	VCUB	face au 564 route de Toulouse	VLS PLUS	76	44.7822	-0.566157

Script pour effectuer le learning du cluster par station

Faire un script qui permet de lancer la phase de learning des cluster pour chaque station.

• Suivant un niveau d'activité définit par station_profile = read_station_profile() (#28)
• Exporter le pipeline du cluster dans le dossiers /model/

Nombre de transaction de type dépôt de vélo pour une même stations

Création d'une nouvelle feature afin de connaitre le nombre de dépôt de vélo qu'il y a eu entre 2 points de données pour une même station.

#2

Refactoring du fichier reader.py afin de ne plus call config.py afin d'avoir les path

Une fois la lib installer et dans un contexte de dev, lorsque que l'on appelle une fonction dans reader.py exemple :

from vcub_keeper.reader.reader import read_station_profile

station_profile = read_station_profile()

L'exécution va se passer dans .../python3.8/site-packages/vcub_keeper/reader ce qui rend impossible dans l'état actuel des choses le bon fonctionnement de l'acquisition dynamique du path ROOT_DIR dans config.py.

Afin de trouver une solution sans non plus casser les différents pipelines de données en dev ou prod. On ajoute un argument dans les fonctions de lecture de type path :

def read_stations_attributes(file_name="tb_stvel_p.csv"):

# Devient

def read_stations_attributes(path, file_name="tb_stvel_p.csv"):

Ainsi pour chaque appel à la lecture d'un fichier, on indiquera le path de celui-ci grâce à l'appel de config.py

Faire de même pour le chargement et l'export de model (cluster.py) et pour l'obtention de la météo dans features_factory.py.

Erreur de Timezone dans la lecture / écriture de station_control

2021-04-07T08:08:50.090167+00:00 app[web.1]: In station_controle !
2021-04-07T08:08:50.505007+00:00 app[web.1]: Exception on / [GET]
2021-04-07T08:08:50.505019+00:00 app[web.1]: Traceback (most recent call last):
2021-04-07T08:08:50.505020+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.8/site-packages/pandas/core/arrays/datetimes.py", line 2054, in objects_to_datetime64ns
2021-04-07T08:08:50.505020+00:00 app[web.1]: values, tz_parsed = conversion.datetime_to_datetime64(data)
2021-04-07T08:08:50.505040+00:00 app[web.1]: File "pandas/_libs/tslibs/conversion.pyx", line 335, in pandas._libs.tslibs.conversion.datetime_to_datetime64
2021-04-07T08:08:50.505040+00:00 app[web.1]: ValueError: Array must be all same time zone
2021-04-07T08:08:50.505041+00:00 app[web.1]:
2021-04-07T08:08:50.505041+00:00 app[web.1]: During handling of the above exception, another exception occurred:
2021-04-07T08:08:50.505042+00:00 app[web.1]:
2021-04-07T08:08:50.505042+00:00 app[web.1]: Traceback (most recent call last):
2021-04-07T08:08:50.505043+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.8/site-packages/flask/app.py", line 2447, in wsgi_app
2021-04-07T08:08:50.505043+00:00 app[web.1]: response = self.full_dispatch_request()
2021-04-07T08:08:50.505044+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.8/site-packages/flask/app.py", line 1952, in full_dispatch_request
2021-04-07T08:08:50.505044+00:00 app[web.1]: rv = self.handle_user_exception(e)
2021-04-07T08:08:50.505044+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.8/site-packages/flask/app.py", line 1821, in handle_user_exception
2021-04-07T08:08:50.505045+00:00 app[web.1]: reraise(exc_type, exc_value, tb)
2021-04-07T08:08:50.505045+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.8/site-packages/flask/_compat.py", line 39, in reraise
2021-04-07T08:08:50.505045+00:00 app[web.1]: raise value
2021-04-07T08:08:50.505046+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.8/site-packages/flask/app.py", line 1950, in full_dispatch_request
2021-04-07T08:08:50.505046+00:00 app[web.1]: rv = self.dispatch_request()
2021-04-07T08:08:50.505047+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.8/site-packages/flask/app.py", line 1936, in dispatch_request
2021-04-07T08:08:50.505047+00:00 app[web.1]: return self.view_functions[rule.endpoint](**req.view_args)
2021-04-07T08:08:50.505047+00:00 app[web.1]: File "/app/vcub_watcher/app.py", line 83, in station_controle
2021-04-07T08:08:50.505048+00:00 app[web.1]: app.layout = station_controler.station_controler()
2021-04-07T08:08:50.505048+00:00 app[web.1]: File "/app/vcub_watcher/apps/station_controler.py", line 237, in station_controler
2021-04-07T08:08:50.505049+00:00 app[web.1]: station_control = read_station_control_from_s3()
2021-04-07T08:08:50.505049+00:00 app[web.1]: File "/app/vcub_watcher/utils_station_control.py", line 94, in read_station_control_from_s3
2021-04-07T08:08:50.505049+00:00 app[web.1]: pd.to_datetime(station_control['last_date_anomaly'])
2021-04-07T08:08:50.505058+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.8/site-packages/pandas/core/tools/datetimes.py", line 799, in to_datetime
2021-04-07T08:08:50.505059+00:00 app[web.1]: cache_array = _maybe_cache(arg, format, cache, convert_listlike)
2021-04-07T08:08:50.505059+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.8/site-packages/pandas/core/tools/datetimes.py", line 170, in _maybe_cache
2021-04-07T08:08:50.505060+00:00 app[web.1]: cache_dates = convert_listlike(unique_dates, format)
2021-04-07T08:08:50.505061+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.8/site-packages/pandas/core/tools/datetimes.py", line 459, in _convert_listlike_datetimes
2021-04-07T08:08:50.505062+00:00 app[web.1]: result, tz_parsed = objects_to_datetime64ns(
2021-04-07T08:08:50.505062+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.8/site-packages/pandas/core/arrays/datetimes.py", line 2059, in objects_to_datetime64ns
2021-04-07T08:08:50.505062+00:00 app[web.1]: raise e
2021-04-07T08:08:50.505063+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.8/site-packages/pandas/core/arrays/datetimes.py", line 2044, in objects_to_datetime64ns
2021-04-07T08:08:50.505063+00:00 app[web.1]: result, tz_parsed = tslib.array_to_datetime(
2021-04-07T08:08:50.505063+00:00 app[web.1]: File "pandas/_libs/tslib.pyx", line 352, in pandas._libs.tslib.array_to_datetime
2021-04-07T08:08:50.505064+00:00 app[web.1]: File "pandas/_libs/tslib.pyx", line 435, in pandas._libs.tslib.array_to_datetime
2021-04-07T08:08:50.505064+00:00 app[web.1]: ValueError: Tz-aware datetime.datetime cannot be converted to datetime64 unless utc=True
2021-04-07T08:08:50.506574+00:00 app[web.1]: 10.12.198.80 - - [07/Apr/2021:08:08:50 +0000] "GET / HTTP/1.1" 500 290 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36"
2021-04-07T08:08:50.506846+00:00 heroku[router]: at=info method=GET path="/" host=vcubwatcher.herokuapp.com request_id=821413d1-dd4e-41cc-b5ac-680251d7ef8b fwd="31.36.90.167" dyno=web.1 connect=1ms service=494ms status=500 bytes=504 protocol=https

Et aussi durant le bach toutes les 10 minutes :

2021-04-07T08:12:45.678831+00:00 app[api]: Starting process with command `python vcub_watcher/detect_anomaly.py` by user [e-mail]
2021-04-07T08:13:00.358455+00:00 heroku[scheduler.9626]: Starting process with command `python vcub_watcher/detect_anomaly.py`
2021-04-07T08:13:00.980086+00:00 heroku[scheduler.9626]: State changed from starting to up
2021-04-07T08:13:14.357693+00:00 heroku[scheduler.9626]: Process exited with status 1
2021-04-07T08:13:14.409938+00:00 heroku[scheduler.9626]: State changed from up to complete
2021-04-07T08:13:14.145041+00:00 app[scheduler.9626]: Traceback (most recent call last):
2021-04-07T08:13:14.145063+00:00 app[scheduler.9626]: File "/app/.heroku/python/lib/python3.8/site-packages/pandas/core/arrays/datetimes.py", line 2054, in objects_to_datetime64ns
2021-04-07T08:13:14.145733+00:00 app[scheduler.9626]: values, tz_parsed = conversion.datetime_to_datetime64(data)
2021-04-07T08:13:14.145738+00:00 app[scheduler.9626]: File "pandas/_libs/tslibs/conversion.pyx", line 335, in pandas._libs.tslibs.conversion.datetime_to_datetime64
2021-04-07T08:13:14.145897+00:00 app[scheduler.9626]: ValueError: Array must be all same time zone
2021-04-07T08:13:14.145900+00:00 app[scheduler.9626]:
2021-04-07T08:13:14.145901+00:00 app[scheduler.9626]: During handling of the above exception, another exception occurred:
2021-04-07T08:13:14.145902+00:00 app[scheduler.9626]:
2021-04-07T08:13:14.145903+00:00 app[scheduler.9626]: Traceback (most recent call last):
2021-04-07T08:13:14.145920+00:00 app[scheduler.9626]: File "vcub_watcher/detect_anomaly.py", line 48, in <module>
2021-04-07T08:13:14.146037+00:00 app[scheduler.9626]: station_control = read_station_control_from_s3()
2021-04-07T08:13:14.146057+00:00 app[scheduler.9626]: File "/app/vcub_watcher/utils_station_control.py", line 94, in read_station_control_from_s3
2021-04-07T08:13:14.146175+00:00 app[scheduler.9626]: pd.to_datetime(station_control['last_date_anomaly'])
2021-04-07T08:13:14.146195+00:00 app[scheduler.9626]: File "/app/.heroku/python/lib/python3.8/site-packages/pandas/core/tools/datetimes.py", line 799, in to_datetime
2021-04-07T08:13:14.146528+00:00 app[scheduler.9626]: cache_array = _maybe_cache(arg, format, cache, convert_listlike)
2021-04-07T08:13:14.146549+00:00 app[scheduler.9626]: File "/app/.heroku/python/lib/python3.8/site-packages/pandas/core/tools/datetimes.py", line 170, in _maybe_cache
2021-04-07T08:13:14.146673+00:00 app[scheduler.9626]: cache_dates = convert_listlike(unique_dates, format)
2021-04-07T08:13:14.146695+00:00 app[scheduler.9626]: File "/app/.heroku/python/lib/python3.8/site-packages/pandas/core/tools/datetimes.py", line 459, in _convert_listlike_datetimes
2021-04-07T08:13:14.146885+00:00 app[scheduler.9626]: result, tz_parsed = objects_to_datetime64ns(
2021-04-07T08:13:14.146907+00:00 app[scheduler.9626]: File "/app/.heroku/python/lib/python3.8/site-packages/pandas/core/arrays/datetimes.py", line 2059, in objects_to_datetime64ns
2021-04-07T08:13:14.147490+00:00 app[scheduler.9626]: raise e
2021-04-07T08:13:14.147493+00:00 app[scheduler.9626]: File "/app/.heroku/python/lib/python3.8/site-packages/pandas/core/arrays/datetimes.py", line 2044, in objects_to_datetime64ns
2021-04-07T08:13:14.148098+00:00 app[scheduler.9626]: result, tz_parsed = tslib.array_to_datetime(
2021-04-07T08:13:14.148118+00:00 app[scheduler.9626]: File "pandas/_libs/tslib.pyx", line 352, in pandas._libs.tslib.array_to_datetime
2021-04-07T08:13:14.148230+00:00 app[scheduler.9626]: File "pandas/_libs/tslib.pyx", line 435, in pandas._libs.tslib.array_to_datetime
2021-04-07T08:13:14.148328+00:00 app[scheduler.9626]: ValueError: Tz-aware datetime.datetime cannot be converted to datetime64 unless utc=True

Nouvelle données d'activité sur les stations

En attente d'un plus gros et plus récent fichiers sur l'activité des stations de Bordeaux.

Celui-ci va remplacer le fichier data/bordeaux.csv

Modification des stations Vcub

Certaines stations ont changé de noms, fermé etc :

• La station "Le Bouscat Mairie" (n°49) devient "Emile Zola" : source
• Nouvelle station "Mairie du Bouscat" (n°181) près de la station tram du même nom : source

Nombre de transaction de type ajout de vélo pour une même stations

Création d'une nouvelle feature afin de connaitre le nombre d'ajout de vélo qu'il y a eu entre 2 points de données pour une même station.

#2

Ajout de données météo

Ajout de données météo par jours (ou plus). La pluie joue un rôle important dans l'activité des stations Vcub.

Idées :

• https://api.meteo-concept.com/

Granularité de la météo à l'heure

L'activité des stations Vcub est fortement liée au temps (température / pluie etc...).

Actuellement, les données météo sont à la journée (#24) :

	date	min_temp	mean_teamp	max_temp	pressure_mean	humidity_mean	precipitation
652	2020-09-12 00:00:00	14.4	21.1	30	1012.3	65	0
653	2020-09-13 00:00:00	14.6	23.5	33.6	1014	48.3	0
654	2020-09-14 00:00:00	19.2	26.6	37.2	1011	40	0
655	2020-09-15 00:00:00	17.9	23.9	31.9	1011.7	66.5	0.5
656	2020-09-16 00:00:00	17.6	23.7	31.9	1012	67.1	0

Dans la recherche de stations en anomalie, il est difficile de savoir si à une certaine heure il n'y a pas eu d'activité (manque d'activité sur la station suspect) car il y avait du mauvais temps (à ce moment précis) ou parce que la station était HS (impossible de pouvoir prendre un Vcub).

Objectif

Recherché des données météo plus fine (à l'heure). Impact #25

Modification du pipeline de l'API activité stations

Il est possible d'avoir plusieurs stations en un seul call d'API.

Actuellement :

station_id : str -> 102

Nouveau :

station_id peut être une list qu'il va falloir modifier en str -> 102, 105, 22

Déconnection non désirée des stations Vcub

Il arrive assez souvent qu'une station soit déconnectée sur un point de temps (10 min). Cela empêche le calcul correct de consecutive_no_transactions_out car remis à 0 avec #20

lié aussi #17

Afficher l'activité d'une stations sous forme graphique

Permettre d'afficher simplement l'activité d'une ou plusieurs stations sous forme de graphique.

Joindre les données d'activités des stations à la météo

Obtenir les données de température, pluie, humidité pour chaque date (à la journée) de l'activité des stations.

Données météo #24

WIP

Permet de copier les photos / screen sur Git pour les utiliser par la suite :

Recherche de stations HS avec les données de 2017

Objectif

Rechercher à partir des données existantes (uniquement 2017 pour l'instant) des stations qui sont hors service et analyser en amont leurs activités.

Problème de ROOT_DIR dans l'app en production

Cf issue github

Resample les données d'activité des stations

Les données actuelles (veille de 2017) n'ont pas une temporalité fixe (le point de donnée fait +/- 5 minutes). Celui-ci dépend des stations :

• Resampler le DataFrame sur 10 minutes. Attention sur agrégation des features et à leurs sens
• Création d'une fonction qui crée ce dataset (en plus de lire le fichier original).

Modification du fichier de référence des stations

Le fichier stations.csv récupéré avec #12 n'a pas le même format.

Modification de la function de lecture read_stations_attributes()

Erreur backend dans l'application

020-10-28T19:59:20.998672+00:00 app[web.1]: from vcub_keeper.production.data import (get_data_from_api_by_station,
2020-10-28T19:59:20.998672+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.8/site-packages/vcub_keeper/production/data.py", line 4, in <module>
2020-10-28T19:59:20.998673+00:00 app[web.1]: from vcub_keeper.transform.features_factory import *
2020-10-28T19:59:20.998674+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.8/site-packages/vcub_keeper/transform/features_factory.py", line 5, in <module>
2020-10-28T19:59:20.998675+00:00 app[web.1]: from vcub_keeper.reader.reader import read_meteo
2020-10-28T19:59:20.998675+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.8/site-packages/vcub_keeper/reader/reader.py", line 4, in <module>
2020-10-28T19:59:20.998675+00:00 app[web.1]: from vcub_keeper.config import ROOT_DATA_RAW, ROOT_DATA_REF, ROOT_DATA_CLEAN
2020-10-28T19:59:20.998676+00:00 app[web.1]: File "/app/.heroku/python/lib/python3.8/site-packages/vcub_keeper/config.py", line 22, in <module>
2020-10-28T19:59:20.998676+00:00 app[web.1]: os.mkdir(ROOT_DATA_CLEAN)
2020-10-28T19:59:20.998677+00:00 app[web.1]: FileExistsError: [Errno 17] File exists: '/app/data/clean/'
2020-10-28T19:59:20.998835+00:00 app[web.1]: [2020-10-28 19:59:20 +0000] [10] [INFO] Worker exiting (pid: 10)
2020-10-28T19:59:25.883086+00:00 app[web.1]: [2020-10-28 19:59:25 +0000] [9] [INFO] Worker exiting (pid: 9)
2020-10-28T19:59:25.888465+00:00 heroku[router]: at=error code=H13 desc="Connection closed without response" method=GET path="/favicon.ico" host=vcubwatcher.herokuapp.com request_id=a512a440-84b8-4f7a-8dc9-3c261d869e29 fwd="91.165.156.207" dyno=web.1 connect=0ms service=4738ms status=503 bytes=0 protocol=https
2020-10-28T19:59:26.194465+00:00 app[web.1]: [2020-10-28 19:59:26 +0000] [4] [INFO] Shutting down: Master
2020-10-28T19:59:26.194569+00:00 app[web.1]: [2020-10-28 19:59:26 +0000] [4] [INFO] Reason: Worker failed to boot.
2020-10-28T19:59:26.351938+00:00 heroku[web.1]: Process exited with status 3
2020-10-28T19:59:26.383885+00:00 heroku[web.1]: State changed from up to crashed
2020-10-28T20:00:13.472116+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/station/105" host=vcubwatcher.herokuapp.com request_id=f2e178d1-4f5a-4338-a2a9-9723da506fd4 fwd="91.165.156.207" dyno= connect= service= status=503 bytes= protocol=https

Erreur lié au fichier config.py et à la création automatique de répertoire en production alors que l'application est installer.

Nombre de transactions entre 2 points de données pour une stations

Création d'une nouvelle feature afin de connaitre le nombre de transactions qu'il y a eu entre 2 points de données pour une même station.

Une transaction peut être un dépôt de vélo ou une prise de vélo.

Naming transactions_depot -> transactions_out

Afin d'avoir une meilleur compréhension. La prise d'un vélo dans une station sera quantifier par transaction_out (au lieu de transaction_depot, mauvais vocabulaire).

#3

Nombre de vélos minimum dispo dans une station pour consecutive_no_transactions_out

Afin de calculer le nombre de temps où la station est inactive au niveau des prises de vélo, on ne prend pas en compte pour l'instant le nombre de vélos disponibles sur la station.

Ainsi une station peut avoir un nombre important de consecutive_no_transactions_out alors qu'il n'y a pas de vélo disponible...

Avoir au minimum 2 vélos disponible sur la stations pour déclencher le compte de consecutive_no_transactions_out (vélos HS, bornes HS etc...)

Cf #10

Refactoring de l'organisation du répertoire data

Mettre en un peu d'ordre dans le répertoire /data.

• Ajout d'un fichier de configuration afin de faciliter le développement.
• Mise à jours de function avec les variables présentes dans le fichiers de configuration.

L'affichage des anomalies n'est pas correct lorsqu'il y a 2 anomalies sur le même jour

Reproduce :

station_id=39
start_date='2020-10-15'
stop_date='2020-10-21'

station_json = get_data_from_api_by_station(station_id=station_id, 
                                            start_date=start_date,
                                            stop_date=stop_date)

station_df = transform_json_station_data_to_df(station_json)

# Load clf 
clf = load_model(station_id=station_id)

# Faire une prédiction d'une station
station_pred = predict_anomalies_station(data=station_df, clf=clf, station_id=station_id)

plot_station_anomalies(data=station_df, clf=clf, station_id=station_id)

Anomalie de 8h10 à 8h20 puis à 13h40 à 13h10 le 20/10/20 pour la station n°39.

Il devrait y avoir 2 bandes rouges et non une seul.

Problème :

Dans plot_station_anomalies()

data_pred['date_day'] = data_pred['date'].dt.date
    grp = \
        data_pred[data_pred['anomaly'] == -1].groupby('date_day',
                                                      as_index=False)['date'].agg({'min' : 'min',
                                                                                   'max' : 'max'})

	date_day	min	max
0	2020-10-15	2020-10-15 06:40:00	2020-10-15 06:50:00
1	2020-10-20	2020-10-20 08:10:00	2020-10-20 14:10:00

Le groupby se fait sur la journée ce qui induit une perte d'information lorsqu'il y a plusieurs anomalies dans la journée.

Stations réellement HS et observation de l'application

Recenser les stations signalées HS par les usagers et observer comment se comporte l'application :

• Station de la Gare de Cenon HS le 07/10 vers 8h source Twitter : Anomalie détectée dès 6h10 par l'application

• Station de la Victoire HS vers 23h50 le 07/10 source Twitter : Anomalie détectée à 02h40 (le 08/10) par l'application

Merging des données activité avec les attributs des stations

Faire le merge entre la time serie de l'activité des stations et la table de référence des stations (#16 ).

Il semble que les station_id (activité) ne match pas avec le référentiel.

• Activite : présence de station_id : [180, 177, 176, 175, 250, 178, 181, 183, 251, 179, 244, 249, 182]
• Référentiel stations : 174 est la station_id la plus récente.

Possibilité : Mauvaise id lors de l'extraction des fichiers sur la BDD ?

Gestion des transactions lorsque que l'on à pas de données

Il manque des données d'activités des stations à certaines dates (cf #18). Cela impact la feature consecutive_no_transactions_out :

consecutive_no_transactions_out continue de grandir même sans données sur la station. Cela ne doit pas être le cas.

Erreur dans les données source available_stands & available_bikes

Dans certains cas on peut voir que consecutive_no_transactions_out (#10 ) a quelques erreurs :

Malgré que la station passe 40 à 39 vélos disponibles sur la station (available_bikes), consecutive_no_transactions_out continue à s'incrémenter. transactions_out (#3 ) est à 0 à ce moment (variable qui est en relation avec consecutive_no_transactions_out) alors qu'elle devrait être naturellement à 1.

C'est parce que available_stands reste à 0 alors qu'il devrait passer à 1 (40 bornes sur cette station).

Ce cas doit aussi ce produire pour transactions_in(#4 ) et available_bikes.

Absence cumulée de prise de vélo sur une station

Faire une feature afin de calculer le nombre de lignes (points de données) qu'il n'y a pas eu de prise de vélo sur la station.

Si cela fait 15 lignes (points de données) qu'aucun vélo n'a été pris sur cette station alors la feature devra être à 15 (14 la ligne en amont) etc...

Permets d'aider pour #1

Refactoring dans l'organisation des notebooks

Granularité des transactions dans les station

Avec la granularité actuelle des données d'activité des stations, il n'est pas possible de savoir s'il y a eu des dépôt et/ou une prise de vélo dans une station dans certains cas.

Si entre 2 points temporels, il y a un ajout et une prise de vélo (l'ajout et la prise de vélo doivent avoir la même valeur). available_stand et available_bike seront identiques à la ligne précédentes. De même si il y a 2 ajouts et une prise de vélo durant ces 5 minutes, on ne verra qu'un 1 seul ajout sur la station.

Sans d'autres données plus fines (liées aux Vcub), il n'est pas possible de régler ce problème.

Statut : En attente d'autres données

Visualisation du profile d'une station (journée / heure) selon une variable

Pouvoir observer l'activité d'une station selon une variable à partir des journées de la semaine et des heures.

Gestion des transactions lorsque que la station est déconnecté

Lorsqu'une station est déconnectée status == 0. consecutive_no_transactions_out ne devrait pas continuer à augmenter, car les utilisateurs ne peuvent pas prendre de Vcub durant cette période.

Faciliter le dev en mode pré prod

Modification du fichier config.py afin de faciliter le travail lorsque l'on installe la lib dans un environnement de projet.

Données de production (API) différentes des données de learning

Les données de production (via API privé) ne sont pas identiques aux données de learning.

• Absence de variable status qui permet de connaitre si la station est en activité ou non (#17)

Cela pose problème lors que la construction de la variable consecutive_no_transactions_out #10. De plus cela empêche pour la production de ne pas effectuer de prédictions sur une station qui n'est pas active (déconnecté du réseau par TBC).

Clustering non supervisé de l'activité des stations

Idées :

ML

• Clustering de type DBSCAN
• Quelques idées Medium
• Papier de use-case en industrie CNN & RNN
• Outlier detection Scikit
• papier sur détection anomalie pour la qualité de l'eau
• papier sur Isolation Forest en stream de data

Features reduction :

• Peut etre mieux que le PCA -> MDS
• [Autres méthode Scikit](https://scikit-learn.org/stable/auto_examples/manifold/plot_compare_methods.html#sphx-glr-(auto-examples-manifold-plot-compare-methods-py)
• Manifold learning
• Par distance non normalisé

Process :

• Ne pas prendre en compte certaines périodes particulières (Cf Covid).
• Faire attention à ce que le cumul de temps sans prise de Vcub ne soit pas dû à 0 Vcub dispo.

Iso forest :

• Mettre un taux de contamination suivant un le type de stations. Doit-on modifier ce taux de contamination suivant le profile de la station ou l'on estime que toutes les stations sont sur le même potentiel d'être HS ?

Graphique de type map afin de visualiser les station HS ou non ainsi que le nombre de vélo dispo

Création d'une map afin de pouvoir :

• Observer les stations actives, inactives et HS (lié aux prédictions des algo).
• Connaitre les nombres de vélos dispo sur chaque station.
• Pouvoir réutiliser cette fonction sur vcub_watcher. Utiliser les données en provenance de station_control.csv (dans vcub_watcher) :

	station_id	mean_activity	is_anomaly	is_inactive	last_date_anomaly	anomaly_since
0	181	0	0	0	NaT	NaT
144	6	0.4	0	0	2021-04-07 11:40:00+02:00	NaT
174	102	0.63	0	0	NaT	NaT

Obtenir les données de production et pouvoir faire des prédictions desssus

• Obtenir les données d'activité des stations via l'API privé.
• Travail de structuration / naming / resample afin que ces données soit identique à create/creator.py create_activity_time_series() durant la phase de learning (#11).
• Chargement du pipeline cluster dédié à la station.
• Faire des prédictions d'anomalies sur la station sur une plage de temps récent (prendre les 7 derniers jours).

Update du .gitignore pour cacher le code lié à l'API privé.

Mauvaise stations dans le fichier station_profile.csv

Certaines stations dans le fichier station_profile.csv (cf #28) ne sont pas des vraies stations (stations de test etc...). D'ailleurs, elles ne sont pas renseignées dans le fichier des attributs des stations (cf #22).

• Ne pas prendre en compte la période de confinement lié au COVID qui pollue l'analyse.
• Filtrer ces stations pour avoir un profile d'activité des stations plus qualitatif.

Différence de rendu dans le graphique d'analyse des anomalies

Il y a une différence de rendu entre Notebook & Dash pour le graphique d'analyse des anomalies des stations :

Ask some help here

Prendre en compte qu'une station puisse être déconnecté dans la recherche de station HS

La feature consecutive_no_transactions_out (#10) qui permet la recherche de station HS (#1) doit elle etre sensible à ce que la station soit connecté ou déconnecté ('state) ?

À réfléchir

Permetre de ne pas afficher le titre dans la function graphique plot_station_anomalies

Via un argument, permettre de ne pas afficher de titre sur le graphique. Par défaut l'argument sera à True.

Naming transactions_ajout -> transactions_in

Afin d'avoir une meilleur compréhension. L'ajout d'un vélo dans une station sera quantifier par transaction_in (au lieu de transaction_ajout).

#4

Environnement Conda & pip requirement.txt

Travaillant dans un environnement Conda, il faut installer nb_conda (conda install nb_conda) mais lors de la création / mise à jour du fichier requirement.txt (pip freeze) cela ajoute des lignes dans le fichier :

nb-conda==2.2.1
nb-conda-kernels==2.3.0

pip n'est pas capable d'installer ces librairies.

ERROR: Could not find a version that satisfies the requirement nb-conda==2.2.1 (from -r /tmp/build_edfc2c82_/requirements.txt (line 42)) (from versions: none)
ERROR: No matching distribution found for nb-conda==2.2.1 (from -r /tmp/build_edfc2c82_/requirements.txt (line 42))
 !     Push rejected, failed to compile Python app.
 !     Push failed

Création d'un fichier lié aux activités des stations

Suite à #12 et l'obtention de 3 fichiers.

• Regrouper ces 3 fichiers en 1 seul.
• Vérification des données (doublons etc...).
• Ajout des features de transaction (avec le resampling) #2 #3 #4
• #11 Resampling de ces données
• Export du résultat dans le répertoire /data/clean/
• Function de lecture du fichier

graphique qui permet de visualiser les anomalies d'une station

Faire comme #5 mais sur 2 axes 'y', le second axe sera pour la variable 'consecutive_no_transactions_out`. Les autres seront sur l'axe 1.

Pour l'affichage des anomalies, faire des rectangles lorsque la stations est en anomalie sur l'axe des dates.