Problème de retour des chemins de ligne

[Diplay]

Bonjour,

Je créer ce topic afin de vous signaler un problème qui dure depuis maintenant quelques temps concernant la couche `SV_CHEM_L`, qui, à certains moments, ne retourne pas tout le temps tous les chemins d’une ligne ; je m’explique. Prenons l’exemple de la Lianes 9, qui a pour tronçon principal Brandenburg - Gare Saint Jean, cependant elle a un terminus partiel situé à Barrière d’Ornano, qui est en service notamment le dimanche soir pour les renforts Gare <—> Ornano. De plus, elle a également un autre terminus situé à Base sous-marine (j’imagine pour la régulation, notamment avec le CEL situé juste à côté). Cela fait donc quelques temps que quand on appelle la couche `SV_CHEM_L` avec le paramètre `filter={“rs_sv_ligne_a“:9}`, au lieu de recevoir les chemins portant les IDs suivants : 263419, 263412, 263418, 263425, 263420, 263426, 263424, à certains moments je ne reçois que les IDs suivants : 263420, 263426, 263424. J’ai l’impression qu’on à peu près 1 chance sur 2 de tomber sur une réponse de 3 IDs, au lieu d’avoir la totalité. Également, cela ne se produit pas uniquement sur la Lianes 9, j’ai pu remarquer le même genre de comportement pour la Lianes 3.

Un autre problème, qui a de fortes chances d’avoir un lien avec celui-là, concerne cette fois-ci le process `saeiv_arret_passages`. Quand j’appelle notamment, pour rester sur le même sujet, l’arrêt `B_PMA09_A` pour avoir les passages de la Lianes 9 en direction de Brandenburg, qui est un service que j’appelle environ toutes les 45 secondes afin de récupérer les passages en temps réel, j’ai à certains moments tous les prochains passages de retournés, mais à d’autres moments, je n’ai aucun résultat (le service retourne un tableau vide).

J’en profite pour vous faire part d’un autre problème en rapport avec les prochains passages retournés par le process `saeiv_arret_passages`. Cela se produit sur le Tram C, quand on prend par exemple l’arrêt « Places Ravezies - Le Bouscat » (“arret_id“:“T_RAVESI_R“}, qui est en direction de Gare de Bègles/Villenave Pyrénées, le service nous retourne uniquement les passages qui ont pour terminus « Gare de Bègles », et il n’y a pas de passage pour « Villenave Pyrénées », alors que la station Place Ravezies est bien situé sur le tronçon principal.

En espérant que vous pourrez donner suite à ces problèmes.
Bonne journée à vous,
HU Jacques.

[Rémi Gousse]

Bonjour Jacques,

J'ai bien noté le dernier souci remonté, à savoir les trams ayant pour terminus Villenave Pyrénées, qui ne remontent pas.
On va regarde ça rapidement.

Par contre, je ne parviens pas à reproduire les deux soucis précédents. Est-ce toujours le cas de votre côté ?

Rémi

[Diplay]

Bonjour Rémi,

Je vous remercie pour votre réponse. Pourriez-vous me tenir au courant, et m’indiquer quand le problème sera réglé svp ?

Pour revenir sur les deux premiers soucis, ils n’ont plus l’air d’être d’actualité. Cela dit, j’en profite, car il y en a d’autres qui sont apparus depuis, avec la couche `sv_vehic_p` concernant la position des véhicules. Pour représenter le problème avec un cas, on va prendre une situation où par exemple je suis au niveau de la Victoire, avec le véhicule n°1871 qui passe devant mes yeux, en direction de la Gare Saint Jean. Quand j’appelle la couche `sv_vehic_p`, je suis censé retrouver le véhicule 1871 avec pour propriété `terminus`, « Gare Saint Jean » et les `coordinates` sont censé me donner une localisation au niveau de la Place de la Victoire. Au lieu de ça, j’ai l’impression que les données qui me sont renvoyées, sont un peu aléatoires. Je peux très bien, par exemple, pour ce véhicule 1871, le trouver en direction de la gare, mais au niveau de Gambetta, et ré-appeler la couche `sv_vehic_p` 20 secondes après, et trouver ce même véhicule au niveau des Capucins, mais cette fois-ci en direction de Mérignac Beaudésert. Ce même comportement s’applique à, j’ai l’impression, tous les véhicules du réseau, sauf le soir, où j’ai l’impression que c’est un peu plus stable. À titre indicatif, ce problème est présent depuis environ 2/3 semaines.

Un autre problème concerne le service `saeiv_arret_passages` qui retourne les prochains passages, mais qui ne sont pas en temps réel (par ça, j’entends que l’horaire estimé est strictement identique à l’horaire théorique + valeur `rs_sv_vehic_p` à null), alors que quand je me place, sur infotbm.com, au même arrêt, pour la même ligne, dans la même direction, j’obtiens les prochains passages en temps réel + la position des bus en question. Pour préciser, et donner un cas plus concret, si je veux voir, en direction des Quinconces, mes prochains passages à l’arrêt Moulin de Gajac, j’appelle donc le service `saeiv_arret_passages`, avec `"arret_id":"B_MGA82_R"`, j’obtiens des passages, pour la Lianes 3, qui sont théoriques, et avec le champ `rs_sv_vehic_p`à null, alors qu’avec ce lien (https://www.infotbm.com/fr/horaires/detail/03/route%3ATBB%3A03_R/stop_point%3ATBB%3ASP%3A3039), j’ai bien les passages en temps réel, avec la position des bus. Je tiens également à préciser, que j’ai l’impression que ce problème se produit sur d’autres arrêts, mais qu’à certains moments, je peux très réappeler le même service dans 20 secondes, et que ce soit fonctionnel. Il ne serait pas improbable que ce problème soit lié au premier, vu que les positions des véhicules sont erronées.

Voilà tout, j’ai essayé d’être le plus clair et précis possible, bien sûr, s’il faut plus de détails, je ferais de mon mieux pour vous les fournir. Merci beaucoup de votre aide.

Cordialement,
HU Jacques

[Mathieu Wolfarth]

Bonjour Jacques,

Merci pour la remontée de ces 2 nouvelles d'anomalies.
Nous allons tenter de reproduire les reproduire de notre côté et de vous apporter les éventuelles corrections rapidement.

Bien à vous.

Mathieu

[Mathieu Wolfarth]

Bonjour,

Concernant la problématique de position potentiellement aberrante de véhicule lors d'un trajet, nous ne reproduisons pas l'erreur que vous remontez.
J'ai fait un test cette après-midi avec un véhicule sur la ligne 1 et le véhicule 1871 auquel vous faites référence dans votre exemple et qui est toujours sur la ligne 9 aujourd'hui.

Positions (toute les minutes) du véhicule 1871 sur la ligne 9 entre 14h14 et 15h32

2024-01-12 16_20_14-FME Data Inspector - 2022.2.png (88.03 Kio) Vu 90738 fois

Pouvez-vous nous donner un véhicule et une plage de date sur laquelle vous détectez cette problématique ?

Bien à vous,

Mathieu

PS : Pour rappel du problème :

Problème avec la couche sv_vehic_p concernant la position des véhicules. Pour représenter le problème avec un cas, on va prendre une situation où par exemple je suis au niveau de la Victoire, avec le véhicule n°1871 qui passe devant mes yeux, en direction de la Gare Saint Jean. Quand j’appelle la couche `sv_vehic_p`, je suis censé retrouver le véhicule 1871 avec pour propriété `terminus`, « Gare Saint Jean » et les `coordinates` sont censé me donner une localisation au niveau de la Place de la Victoire. Au lieu de ça, j’ai l’impression que les données qui me sont renvoyées, sont un peu aléatoires. Je peux très bien, par exemple, pour ce véhicule 1871, le trouver en direction de la gare, mais au niveau de Gambetta, et ré-appeler la couche `sv_vehic_p` 20 secondes après, et trouver ce même véhicule au niveau des Capucins, mais cette fois-ci en direction de Mérignac Beaudésert. Ce même comportement s’applique à, j’ai l’impression, tous les véhicules du réseau, sauf le soir, où j’ai l’impression que c’est un peu plus stable. À titre indicatif, ce problème est présent depuis environ 2/3 semaines.

[Diplay]

Bonsoir,

Par rapport à ce problème, on cherche trop à se compliquer la vie. Je viens de regarder les données reçues, et après pas mal de réflexion, je me suis rendu compte que le problème venait simplement du fait que les données retournées ne datent absolument pas du moment où l'appel est effectué. Exemple : il est 21h24 et j'appelle donc la couche `sv_vehic_p`, et le premier résultat que je prends, indique `"mdate": "2024-01-12T20:08:52+01:00"`. Ces données datent d'il y a 75 minutes

Je pense que le problème est tel, et que forcément, il y a 75 minutes, le véhicule n'était pas à la position à laquelle on croit qu'il est actuellement ^^

Cordialement,
HU Jacques

[Diplay]

Bonsoir,

J'écris ce post afin de vous faire un point sur la situation. Le problème semble donc avoir été réglé pendant, le week-end, les positions retournées sont justes. Je continuerai cette semaine à surveiller l'évolution de la situation, et reviendrai ici si besoin est. Néanmoins, le problème concernant les trams C ayant pour terminus Villenave Pyrénées qui n'apparaissent pas, ne semble toujours pas avoir été réglé

Cordialement,
HU Jacques

EDIT : Le problème ne semble pas s’être produit ce week-end, cependant il semble être de retour depuis ce lundi matin.

[Mathieu Wolfarth]

Bonjour Jacques,

Jamais simple ces problématiques d'objets temps réel...

Pour rappel : l'ensemble des positions des véhicules sont historisées dans nos entrepôts de données. La position d'un véhicule à un instant T est requêtable via notre webservice geojson sur le endpoint "feature" et avec le paramètre "backintime" (cf doc swagger : https://data.bordeaux-metropole.fr/geojson/help/#/).
Il suffi alors de boucler sur un pas de temps pour construire l'historique des positions du véhicule.


Suite l'édition de votre poste ce matin sur le retour du problème, j'ai refait un test (vers 9h20) sur le bus 1870 (ligne 9) en récupérant l'historique des positions minutes par minutes entre 7h20 et 9h20.
Les positions historisées semblent cohérentes (cf image).
J'ai ensuite pris une position pour vérifier la cohérence de la date de mesure (mdate = 2024-01-15T08:05:29+01:00) avec les horaires théoriques et réalisés de la table des Horaires (sv_arret_p) pour l'arrêt "Brun" qui semble le plus proche de la position du véhicule à cette date ==> On a bien un horaire réalisé (et théorique) à 8h05 en adéquation avec le mdate de la position du bus dans sv_vehic_p.
Horaire du bus à l'arrêt "Brun" : https://opendata.bordeaux-metropole.fr/explore/dataset/sv_horai_a/table/?sort=-rs_sv_arret_p&q=rs_sv_cours_a%3D734608+and+rs_sv_arret_p%3D255

Test (vers 9h20) sur le bus 1870 (ligne 9) en récupérant l'historique des positions minutes par minutes entre 7h20 et 9h20. Position du bus à 8h05 surlignée en bleu et en jaune sur la carte

2024-01-15 11_15_05-Window.png (69.21 Kio) Vu 90701 fois

J'ai réalisé un second test pour récupérer l'historique des positions du bus 1871 (ligne 9), vendredi 12/01 entre 20h et 22h, plage horaire sur laquelle vous aviez rencontré des délais de 75 min.
Là encore je ne retrouve pas votre problématique, je constate bien que le véhicule se déplace régulièrement sur la ligne 9.

Test du bus 1871 (ligne 9), vendredi 12/01 entre 20h et 22h

2024-01-15 11_45_25-Window.png (66.27 Kio) Vu 90701 fois

Cordialement,

Mathieu

[Hackoris]

Bonjour,

Je me permets de répondre car je rencontre la même problématique que Diplay.
Le soucis ne réside pas dans les données en eux-mêmes. En effet, vous avez raison, les données reçues sont totalement correctes.

Le soucis est dans le délai qu'il existe entre l'heure de l'appel et l'heure des véhicules reçus. Je m'explique :

Nous sommes le 15/01/2024, il est 12:25:30. Si je fais un appel à l'adresse : https://data.bordeaux-metropole.fr/wfs?key=XXX(avec le paramètre layerName à 'SV_VEHIC_P').
La liste des véhicules que je reçoit sont datés du 15/01/2024 11:41:53. Pour info, j'ai bien 366 véhicules retournés (278 bus - 86 trams - 2 bateaux).

Les tests que vous effectuez sont en recherchant l'historique de véhicules. Or, il faudrait qu'à un instant T, vous faites un appel et regardez la valeur m_date la plus récente des véhicules retournés. Je pense que vous constaterez le délai qu'il existe.

D'après ce que j'ai vu la semaine dernière, le soucis arrive en début de journée (7h environ) jusqu'en soirée (20h). Le délai constaté est entre une demi-heure et parfois jusqu'à une heure. Comme constaté par Diplay, il n'y a eu aucun soucis ce week-end, y compris en journée, les données reçues correspondaient bien à l'heure à laquelle on fait l'appel (environ 10s de décalage).

Je reste disponible pour toutes informations complémentaires.

Cordialement,

[Sébastien Cart-Lamy]

Bonjour,
Il semble y avoir du lag sur nos bases de réplications lors de fort trafic de data sur les données temps réel - donc le week end, moins de bus, moins de trafic - dans tous les sens du terme

Nous allons voir comment résoudre ce ralentissement