gtfs: Add the possibility to infer frequency based schedules at import

[tahini]

fixes #718

If the option is selected, instead of importing exact trips from the GTFS, it will try to infer a frequency based schedule from the trips in the period.

For each direction, it calculates the possible frequency as (time of the last trip - time of the first trip) / (number of trips - 1) or 60 seconds if there is only one trip.

Custom start and end time will be used respectively if the time between first trip and last trip and the period boundary is superior than the frequency. Otherwise, it uses the period's official boundary for start or end.

If more than one path is used by the schedule for a direction, the most frequent one will be used for the whole schedule.

[tahini]

@tibobliss Tentative d'import pour inférer des fréquences. C'est peut-être pas parfait, mais ce serait un point de départ pour tester.

Ce que j'observe:

1. Par défaut, les horaires sont à la seconde, donc ici, on a des horaires à la seconde, peut-être pas désiré. Soit il faudrait pouvoir le configurer, soit mettre à la minute par défaut.
2. On utilise les temps GTFS (custom) seulement si la différence entre le temps en question et la frontière de la période est supérieure à la fréquence, sinon, on prend la frontière de la période. Le jour où on va mieux gérer les transitions entre les périodes d'horaire, ça va magiquement en profiter, mais en attendant, le premier trajet sera au temps de départ (genre 6h pour la péreiode 6-9)

Vous trouverez beaucoup d'autres problèmes, j'imagine, mais là, on jase...

[tahini]

Est-ce que cette fonctionnalité devrait refuser de générer des intervalles dans des cas extrêmes d'asymétrie ou qui générerait trop de voyages dans une période?

Par exemple:

Période de 9 à 15h:

• Dans la direction aller, il y a 3 voyages à 9h, 9h20 et 9h40 (donc fréquence de 20 minutes de 9h à 9h40)
• Dans la direction retour, il y a 3 voyages à 14h, 14h20, 14h40 (donc fréquence de 20 minutes de 14h à 15h).
• Cette période, comme c'est implémenté ici, générera une fréquence aux 20 minutes de 9h à 15h, symétriques, donc 36 voyages au lieu de 6.
• Il n'y a pas de solution miracle ayant comme résultat une seule période de 9h à 15h avec une seule fréquence. Faut-il interdire alors ça? Ou fixer rapidement des issues qui rendront ça moins problématique (détection automatique de période, générant un nombre potentiellement élevé de périodes distinctes et des périodes aux heures différentes selon les lignes, etc, j'ai aucune idée comment Transition va réagir à ça, genre)

@tibobliss @kaligrafy des idées? Est-ce suffisant pour que ce soit un no-go sur cette PR? Devrait-on trouver le moyen de sauvegarder des logs sur le trajet, permettant de mettre ce warning en qq part dans le path?

[kaligrafy]

C'est ce qu'on avait dit, que ça allait cérer des distortions pour les lignes peu fréquentes ou qui fonctionnent seulement pendant quelques heures par jour. C'est ok pour l'instant, car ça ne devrait pas affecter un grand pourcentage des lignes, qui sont plutôt régulières. De toute façon, c'est de la planif, on ne planifie pas des lignes comme ça avec 3 passages puis plus rien pendant des heures. C'est trop pointu et ça sent le "manque de chauffeurs" ou "manque de véhicules" ou "doit renvoyer le bus au garage pour interlignage" ou "cette usine ne change pas de shift à ces heures, donc on passe pas là", ce qui est de l'opération pointue!

[tibobliss]

@tahini On est très enthousiastes, ici! On a hâte de tester la fonctionnalité.

Ce que je comprends, c'est que l'horaire sera généré avec un intervalle fixe en utilisant les bornes de la période (ex.: 6h00 à 8h59) et non pas les bornes du service actuel (ex.: 6h25 à 8h52)?

[tahini]

@tibobliss Vous pourrez tester dès aujourd'hui et nous donner du feedback.

Ce que je comprends, c'est que l'horaire sera généré avec un intervalle fixe en utilisant les bornes de la période (ex.: 6h00 à 8h59) et non pas les bornes du service actuel (ex.: 6h25 à 8h52)?

Si le temps entre la borne de votre service et la borne de la période est supérieure à la fréquence, on utilise la borne de votre service actuel, sinon, on prend celle de la période. Ceci pour s'assurer que quand on regénère des horaires, on n'a pas de trou non désiré entre 8h52 et 9h07 genre

[tahini]

Mais ouais, il va falloir réfléchir à l'heure du premier départ de la première période. J'imagine que même en Suisse, toutes les bus ne débutent pas à 6h pile. @kaligrafy?

[tibobliss]

Mais si on prend les premiers et derniers départs réels pour chaque période, on ne retrouvera pas de trous non désirés, logiquement, puisque l'intervalle entre les deux sera l'intervalle réel entre les deux.

[tahini]

Mais si on prend les premiers et derniers départs réels pour chaque période, on ne retrouvera pas de trous non désirés, logiquement, puisque l'intervalle entre les deux sera l'intervalle réel entre les deux.

Ce serait vrai pour les horaires importés, mais quand on en regénère, ou qu'on change mettons la fréquence manuellement, c'est là que les trous vont apparaître. Ça pourrait être discuté dans un issue pour voir l'implémentation à prévoir dans Transition.

[tibobliss]

Si on change la fréquence manuellement, on pourra justement intervenir pour éviter la situation en question donc ça ne me semble pas être un enjeu.

Quand on regénère automatiquement, il me semble que c'est au contraire la manière la plus fiable de s'assurer qu'on n'a pas de "trou" puisqu'on respecte l'écart réel entre le dernier voyage de la période A et le premier de la période B.

Dans tous les cas, il me semble qu'on introduit davantage de distorsions en n'utilisant pas les premiers et derniers départs réels que le bénéfice obtenu sur le edge case des possibles "trous" inter-périodes.

[tibobliss]

Je remarque d'ailleurs que, dans ce cas-ci (180-E, semaine), on introduit artificiellement un intervalle de 17 minutes entre deux périodes à intervalle de 30 minutes, justement parce que les bornes observées ne sont pas utilisées. Donc, on dirait que pour éviter de créer des "trous", on crée au contraire des intervalles artificiellement faibles.

[tahini]

Est-ce que fixer #681 réglerait le problème?

Il ne faut pas oublier que la fréquence calculée est une moyenne sur la période et ne correspondra pas nécessairement au temps entre les dernier et premier départs des 2 périodes. Mettons que Transition a calculé des fréquences moyennes sur la période A de 20 minutes et 15 minutes sur la période B mais que le temps entre les 2 départs s'adonnait à être 30 minutes, les horaires générerait un bris de service entre les périodes.

[tibobliss]

C'est quand même improbable que l'horaire soit monté de telle manière dans la réalité. Mais même si c'est théoriquement possible, c'est statistiquement moins probable que la distorsion inverse qui est actuellement créée.

[tahini]

Mais en fixant #681, le premier départ de la 2e période serait à 14h43:13 + 1584 secondes, quoi que ça fasse, donc cette distorsion ne sera plus là.

[tibobliss]

En effet, mais ça me semble être plus complexe à faire pour un gain marginal de précision, non?

Et surtout, le fait d'utiliser systématiquement le premier et le dernier départ est plus cohérent. En ce moment, si je comprends bien, les paramètres sont utilisés de la manière suivante:

• Si un seul départ: début = premier départ observé ; fin = dernier départ observé + 1 min
• Si plusieurs départs: début = début de la période; fin =
• • si le nombre de départs générés (N') correspond au nombre de départs observés (N), fin = non rempli
• • si N' > N, fin = dernier départ observé

C'est difficile à gérer comme comportement parce que c'est un peu imprévisible et que les paramètres ne sont pas renseignés partout. Si, par exemple, on veut connaître l'heure de fin d'une période où le paramètre n'est pas utilisé (parce que N' = N), il faut scroller jusqu'au dernier départ.

[tahini]

Je vais fixer #681 parce que dans tous les cas, il le faut, et on se reparlera des menus détails après.

Pour le plusieurs départs, voici les paramètres comme c'est implémenté actuellement

t_0: début de la période t_n: fin de la période t'_0: heure du premier départ observé t'_n: heure du dernier départ observé F = Fréquence inférée = (t'_n - t'_0) / (nombre de voyages - 1) début = Si t'_0 - t_0 > F alors t'_0 sinon t_0 fin = Si t_n - t'_n > F alors t'_n sinon t_n

[tibobliss]

Mais à mon sens, c'est plus cohérent et transparent d'utiliser systématiquement t'_0 et t'_n. Il n'y a pas d'interprétation à faire pour l'usager, contrairement à la solution actuelle qui doit être documentée en-dehors du logiciel et qui n'est pas intuitive pour un usager qui n'a pas d'accès privilégié à l'équipe de dev.

[tibobliss]

Après, le fix de #681 pourrait (devrait) être optionnel.

Dans QGIS, par exemple, quand on regroupe des données en classes pour faire une carte thématique, on a une option intitulée Lier les limites de classes, mais on a l'option de ne pas le faire si on a besoin de faire des classes qui ne sont pas liées ensemble.

Par exemple, on pourrait vouloir un gap entre deux périodes pour une raison XYZ, il ne faudrait pas forcer le lien entre les périodes.

[tahini]

@kaligrafy, besoin d'un 3e avis ici! :D

[kaligrafy]

Laissez-moi le temps de tout lire ça, je vous reviens!