SIEL pour les bus à Paris : c'est de pire en pire ?

par **Prince des Tenebres** le Lun 25 Oct 2010 - 16:03

Rappel du premier message :

Bonjour

Est-ce que je suis le seul à penser que c'est n'importe quoi l'affichage de SIEL pour les bus à Paris ?

Hier soir Gare de l'Est : le N02 est annoncé à 30 minutes, donc je pars à pied, 5 minutes plus tard ya un N02 qui me double.

Avant hier, St Michel : le N14 annoncé à 10 minutes, il me faut 3 minutes pour aller jusqu'à l'arrêt et je vois le N14 qui se barre devant moi.

Très souvent : le compteur indique 2 mn, 1mn, 0.... toujours pas de bus... puis hop il se remet à 9 minutes

Si c'est pour faire ça, il vaudrait peut-être mieux supprimer le système non ?

Je veux bien admettre que la circulation etc rend difficile d'être très précis mais on doit quand même pouvoir faire mieux !!!

Quand pensez-vous

?

par **Christobal** le Sam 30 Oct 2010 - 21:12

D'une manière générale, aller sur le site de la STIB : http://www.stib.be

Rubrique "Horaires".

Sélectionner la ligne.

Sélectionner la destination.

Cliquer sur "Position des véhicules temps réel".

par **JM-C** le Sam 30 Oct 2010 - 22:02

Pour bien connaître les deux systèmes, Visulys et Siel utilisent à peu près les mêmes principes et Visulys fonctionne globalement plus mal que Siel (mais il faut prendre le bus souvent pour pouvoir faire la comparaison et je ne suis pas sûr que ce soit le cas de nos touristes ...).
Il arrive que Visulys affiche ARRET NON DESSERVI alors qu'un bus est à l'arrêt !

Car il ne faut pas oublier une chose importante, c'est que pour qu'un SIV fonctionne, il faut qu'il détecte les bus. Et pour des tas de raisons, il y en a qui ne le sont pas (perte du signal radio, émetteur en panne, voiture mal codée par le MR, bus pas équipé ...) et donc Visulys se recale sur le TM théorique. Si c'est une perte passagère du signal GPS (par exemple à cause d'un obstacle) et quand l'info revient, il peut y avoir une différence et donc le temps d'attente varie brusquement. Et puis il y a le problème du livreur qui s'arrête brusquement et bloque le bus.

Un autre exemple, à Lyon: les trams plantent régulièrement les bornes de C3 parce que si un trolley est à 100 mètres, Visulys l'annonce dans une minute et si par hasard, un tram arrive, le feu passe au rouge pendant 2 minutes s'il est loin et s'il en croise un autre. Et donc avec deux carrefours avec le tram (Cours Lafayette), on peut passer de 1 minutes à 5 ! Et ça se répercute sur les arrêts suivants alors que le C3 suivant peut très bien arriver sans être bloqué et à faible charge (le précédent ayant tout ramassé) si bien qu'il va rattraper le précédent alors que Visulys avait prévu le même temps de trajet !

par **Prince des Tenebres** le Sam 30 Oct 2010 - 22:32

Métronome a écrit:
de bêtes temps d'attentes, imprécis, et issus d'une estimation

.... et issus d'un algorithme de calcul déficient, incapable de prendre en compte la moitié des données disponibles !!

Métronome a écrit:
un plan synoptique, présente pour chaque station et interstation une diode

Moui, pas idiot. Sauf que là on parlait des bus à Paris, et ça veut dire qu'il faudrait mettre un panneau plein de LEDs sur chaque arrêt, c'est à dire en extérieur, et sur beaucoup d'arrêts il n'y a pas la place (ceux où il n'ya pas d'abribus), sans parler du prix de l'équipement et des frais liés à la maintenance (ou au vandalisme...).

Moi ce que j'aimerais bien c'est avoir accès aux données brutes (positions des bus en temps réel) et je fais le pari que je pourrais sortir un algorithme plus performant que celui qui existe. (Sans parler des possibilités d'applications iPhone).

Christobal, ton mystérieux inconnu pourrait-il faire quelque chose pour moi ?

par **Christobal** le Sam 30 Oct 2010 - 22:44

Ben tu as beau dire ce que tu veux, mais la seule connaissance de la position des véhicules en temps réel ne serait certainement pas suffisante...

Car le paramètre géographique seul n'apporte pas grand chose, il te manquerait le paramètre "vitesse" pour pouvoir en déduire un temps.

L'équation est bien connue : V = d / t, avec les combinaisons possibles d = V . t et t = d / V.

À moins que tu ne sois magicien, si tu ne disposes pas au moins de deux paramètres, je ne vois pas trop comment tu peux faire...

Et sachant que le paramètre "vitesse" est susceptible de variations totalement aléatoires et imprévisibles, ça ne facilite pas la chose !

Mais vu que tu sembles t'y connaître, peut-être pourrais-tu nous éclairer sur la façon dont tu pourrais traiter le problème ?

PS : pour répondre à ta question : "Non"...

par **Prince des Tenebres** le Sam 30 Oct 2010 - 22:48

JM-C a écrit:
il faut qu'il détecte les bus. Et pour des tas de raisons, il y en a qui ne le sont pas (perte du signal radio, émetteur en panne, voiture mal codée par le MR, bus pas équipé ...)

Ok, là on ne peut pas faire grand chose.

JM-C a écrit:
Si c'est une perte passagère du signal GPS (par exemple à cause d'un obstacle) et quand l'info revient, il peut y avoir une différence et donc le temps d'attente varie brusquement.

Oui d'accord ça doit pouvoir perturber le système. Mais moi dans Paris je ne perds jamais mon signal GPS, sauf dans les tunnels. Les problèmes que j'ai constatés étaient sur des parcours sans tunnels.

JM-C a écrit:
Et puis il y a le problème du livreur qui s'arrête brusquement et bloque le bus.

Dans ce cas je pense que l'estimation du temps de parcours devrait rester figée.
Par exemple un bus est à 5mn de l'arrêt, puis 4, et là... livraison !! L'affichage devrait donc rester sur 4 minutes.
En effet c'est le temps de parcours qu'il faudra lorsque le livreur aura fini, et on ne sait pas combien de temps il va durer donc on ne peut pas faire mieux.

JM-C a écrit:
Un autre exemple, à Lyon: les trams plantent régulièrement les bornes de C3 parce que si un trolley est à 100 mètres, Visulys l'annonce dans une minute et si par hasard, un tram arrive, le feu passe au rouge pendant 2 minutes s'il est loin et s'il en croise un autre. Et donc avec deux carrefours avec le tram (Cours Lafayette), on peut passer de 1 minutes à 5 ! Et ça se répercute sur les arrêts suivants alors que le C3 suivant peut très bien arriver sans être bloqué et à faible charge (le précédent ayant tout ramassé) si bien qu'il va rattraper le précédent alors que Visulys avait prévu le même temps de trajet !

Oui mais si on dispose des positions exactes en temps réel un bon algorithme doit en tenir compte. Quitte à afficher 2 minutes pour chacun des 2 bus qui sont maintenant cul à cul.

Pour résumer: je reconnais qu'on ne peut pas faire de prévision exacte.
Mais entre prévision approximative et prévision débile, il y a une ligne dont SIEL ne s'approche même pas? En effet indiquer 2 minutes alors que le bus est à l'arrêt, et on le sait, car on reçoit sa position indiquant qu'il est à l'arrêt, là, je ne vois pas d'excuse.

Ou alors ce sont des bus non équipés? Mais dans ce cas, yen a beaucoup, puisque ce genre de problème arrive régulièrement, et dans ce cas si on ne veut pas équiper, alors arrêtons aussi d'équiper les arrêts !!

par **Prince des Tenebres** le Sam 30 Oct 2010 - 22:59

Christobal a écrit:
Car le paramètre géographique seul n'apporte pas grand chose, il te manquerait le paramètre "vitesse" pour pouvoir en déduire un temps.

L'équation est bien connue : V = d / t, avec les combinaisons possibles d = V . t et t = d / V.

À moins que tu ne sois magicien, si tu ne disposes pas au moins de deux paramètres, je ne vois pas trop comment tu peux faire...

Et sachant que le paramètre "vitesse" est susceptible de variations totalement aléatoires et imprévisibles, ça ne facilite pas la chose !

Mais vu que tu sembles t'y connaître, peut-être pourrais-tu nous éclairer sur la façon dont tu pourrais traiter le problème ?

Ben ya plusieurs facteurs qui interviennent :

quelles sont les infos envoyées par les bus
tous les combien de temps

Je suppose que les infos arrivent sur un serveur quelconque.
Une autre question est donc :

à quelle fréquence les affichages sur les arrêts sont-ils remis à jour

Si un bus envoie sa position GPS exacte toutes les 10 secondes, le serveur a donc une assez bonne idée
de sa vitesse, en faisant par exemple une moyenne glissante sur les 10 derniers échantillons.

Le serveur est donc capable de remettre à jour son estimation toutes les 10 secondes.
Si l'arrêt va chercher les infos toutes les 30 secondes disons, ça veut dire qu'on peut avoir une info
remise à jour au pire toutes les 40 secondes. C'est déjà pas mal.

La difficulté est ensuite de faire un mix correct entre les estimations ainsi obtenues, et la position réelle.
En tout cas je garantis que mon algo n'indiquera pas 2 minutes d'attente si le bus est à l'arrêt !!!

Maintenant si les bus ne transmettent que toutes les minutes, là on a un problème.

Mais à la RATP on aime bien savoir où sont les bus donc ça doit être plus souvent que ça (enfin j'espère).
Je vais aller les voir tiens.

par **Christobal** le Sam 30 Oct 2010 - 23:18

Aux heures de pointe, il doit y avoir environ 3.800 bus en circulation. J'ose pas imaginer la taille du serveur si tous ces bus lui envoyaient leurs informations à une fréquence inférieure à 10 secondes !

Après, je reviendrai quelques instants sur les contraintes techniques évoquées par JM-C.

Le bus est équipé d'un système lui permettant de définir sa position via le GPS. Il lui faut ensuite transmettre cette information au serveur. Ça nécessite donc que le système de localisation fonctionne, et que toute la connectique soit bonne pour envoyer les informations via son antenne.

En ce qui concerne SIEL, la transmission se fait a priori par liaison radio, si j'ai bien tout compris. Avec les risques de perturbations inhérents à ce mode de transmission.

Quand le signal parvient au serveur, il est mouliné avec tous les autres. Vu le volume d'informations à traiter, ça doit quand même prendre quelques secondes... L'information sur les temps d'attente repart ensuite, toujours par radio, vers les écrans aux arrêts. Avec de nouveau les possibles aléas sur la transmission de l'information...

Maintenant, depuis le début, je n'entends parler que des jours où ça ne fonctionne pas correctement. Mais en ce qui me concerne, d'une manière générale, je trouve tout de même que ça marche plutôt bien...

par **Prince des Tenebres** le Dim 31 Oct 2010 - 18:11

Christobal a écrit:
Aux heures de pointe, il doit y avoir environ 3.800 bus en circulation. J'ose pas imaginer la taille du serveur si tous ces bus lui envoyaient leurs informations à une fréquence inférieure à 10 secondes !

Il faudrait savoir exactement quelles sont les données transmises.
Mais supposons :
4 octets pour le n° de voiture ce qui est énorme
4 octets pour le n° de ligne ce qui est gigantesque
8 octets pour la position GPS (2 nombres en virgule flottante sur 32 bits)
on est rendu à 16 octets à envoyer.

Ajoutons les entêtes, les cochonneries habituelles; on va dire 64 octets à envoyer par bus, c'est compté large.
Donc : 3800 * 64 = 243200 octets soit 240ko toutes les 10 secondes à recevoir par le serveur.
Ca ne me semble pas démesuré.

Ensuite bien sûr il y a le temps de calcul.
Imaginons qu'on ait 100 opérations (additions, multiplications, divisions) à faire à chaque fois.
3800 * 100 = 380 000 opérations toutes les 10 secondes soit 38 000 opérations par secondes.
Un Intel Core 2 Duo peut faire 22 GFLOPS (soit 22 000 000 000 opérations) donc ça laisse pas mal de temps
pour les tâches annexes comme recevoir les requêtes, envoyer les réponses, stocker tout ça.

Christobal a écrit:
Après, je reviendrai quelques instants sur les contraintes techniques évoquées par JM-C.

Le bus est équipé d'un système lui permettant de définir sa position via le GPS. Il lui faut ensuite transmettre cette information au serveur. Ça nécessite donc que le système de localisation fonctionne, et que toute la connectique soit bonne pour envoyer les informations via son antenne.

Oui on est d'accord, il vaut mieux que ça marche.

Christobal a écrit:
En ce qui concerne SIEL, la transmission se fait a priori par liaison radio, si j'ai bien tout compris. Avec les risques de perturbations inhérents à ce mode de transmission.

Oui, c'est forcément par liaison radio, puisqu'il n'y a pas de fil.
Il faudrait savoir quel genre de liaison radio. Du GPRS ? Un truc propriétaire? Quel est le débit ?

Christobal a écrit:
Quand le signal parvient au serveur, il est mouliné avec tous les autres. Vu le volume d'informations à traiter, ça doit quand même prendre quelques secondes... L'information sur les temps d'attente repart ensuite, toujours par radio, vers les écrans aux arrêts. Avec de nouveau les possibles aléas sur la transmission de l'information...

Voir mon calcul ci-dessus, fait à la louche, j'en conviens.

Christobal a écrit:
Maintenant, depuis le début, je n'entends parler que des jours où ça ne fonctionne pas correctement. Mais en ce qui me concerne, d'une manière générale, je trouve tout de même que ça marche plutôt bien...

Bof bof.

Je ne prends pas le bus tous les jours, mais à chaque fois que je le prends, je trouve le fonctionnement bizarre.
Si c'est dû à des perturbations, ça veut dire que la techno employée n'est pas très fiable, parce qu'alors des perturbations yen a souvent !

par **Métronome** le Lun 1 Nov 2010 - 12:30

Prince des Tenebres a écrit:Il faudrait savoir exactement quelles sont les données transmises.
Mais supposons :
4 octets pour le n° de voiture ce qui est énorme
4 octets pour le n° de ligne ce qui est gigantesque
8 octets pour la position GPS (2 nombres en virgule flottante sur 32 bits)
on est rendu à 16 octets à envoyer.

Ajoutons les entêtes, les cochonneries habituelles; on va dire 64 octets à envoyer par bus, c'est compté large.
Donc : 3800 * 64 = 243200 octets soit 240ko toutes les 10 secondes à recevoir par le serveur.
Ca ne me semble pas démesuré.

Toi tu fais sciences de l'ingénieur

Prince des Tenebres a écrit:Oui, c'est forcément par liaison radio, puisqu'il n'y a pas de fil.

Je suis pas d'accord. Il n'est nul besoin de rayonnements radio pour transmettre un signal sans fil, les possibilités sont nombreuses : satellite, infrarouge, induction magnétique, etc. Ensuite, c'est l'utilisateur qui choisit le mode de transmission le plus adapté.

par **Prince des Tenebres** le Lun 1 Nov 2010 - 16:32

Métronome a écrit:

Je suis pas d'accord. Il n'est nul besoin de rayonnements radio pour transmettre un signal sans fil, les possibilités sont nombreuses : satellite, infrarouge, induction magnétique, etc. Ensuite, c'est l'utilisateur qui choisit le mode de transmission le plus adapté.

Oui enfin je me limitais à ce qui est raisonnablement utilisable par un bus. Le satellite c'est de la radio, l'infrarouge c'est a courte distance et il faut une ligne droite entre l'émetteur et le récepteur, l'induction magnétique il faut passer près d'un capteur. Sinon tu as oublié les signaux de fumée, le tamtam, et le télégraphe de Chappe.

par **Métronome** le Mar 2 Nov 2010 - 11:51

Perso ça m'étonnerait que les bus communiquent comme ça, mais on sait jamais

par **Prince des Tenebres** le Mar 2 Nov 2010 - 12:17

Métronome a écrit:Perso ça m'étonnerait que les bus communiquent comme ça, mais on sait jamais

Ha ha , ça marcherait ptêtre un peu mieux !!

Nan, je suis méchant. Hier soir j'ai pris 2 Noctiliens et ya pas eu de problème. Ils ont dû lire ce fil.

par **Christobal** le Mar 2 Nov 2010 - 16:49

Non... C'est juste que... tu es... très mauvaise langue !

par **Métronome** le Mer 3 Nov 2010 - 9:47

Sérieusement, en général ça a son efficacité. Si pour indiquer les temps il se sert d'une moyenne étalonnée par les bus précédents, alors c'est compréhensible. Si on a l'impression que ça fonctionne mal, c'est parce que quand ça fonctionne bien, on ne fait pas de remarque ; on ne retient pas ce qui nous paraît normal, par contre on se souvient de ce qui déclenche une émotion (j'ai vu ça dans Memoquiz Noël

).

J'ai réfléchi, et finalement je me suis dit que : 1) indiquer le temps d'attente n'est pas très fiable ; 2) indiquer l'arrêt auquel le bus se trouve ne donne aucune idée de la durée : donc pourquoi ne pas donner une indication de la longueur restant à parcourir (avec éventuellement, écrit en petit, un estimation du temps nécessaire) ?

par **Christobal** le Mer 3 Nov 2010 - 13:18

Ou alors on ne se prend pas la tête : on ne donne rien du tout, comme avant...

Je me souviens d'un séjour chez des amis au Pays de Galles il y a déjà quelques années. Je vais pour prendre le bus jusqu'à la ville voisine et consulte le poteau d'information. Ne trouvant pas d'horaire, je demande à une charmante dame qui attendait également. La réponse fut simple et sans appel : "Any time !".

Avec ça...

SIEL pour les bus à Paris : c'est de pire en pire ?

SIEL pour les bus à Paris : c'est de pire en pire ?

Re: SIEL pour les bus à Paris : c'est de pire en pire ?

Re: SIEL pour les bus à Paris : c'est de pire en pire ?

Re: SIEL pour les bus à Paris : c'est de pire en pire ?

Re: SIEL pour les bus à Paris : c'est de pire en pire ?

Re: SIEL pour les bus à Paris : c'est de pire en pire ?

Re: SIEL pour les bus à Paris : c'est de pire en pire ?

Re: SIEL pour les bus à Paris : c'est de pire en pire ?

Re: SIEL pour les bus à Paris : c'est de pire en pire ?

Re: SIEL pour les bus à Paris : c'est de pire en pire ?

Re: SIEL pour les bus à Paris : c'est de pire en pire ?

Re: SIEL pour les bus à Paris : c'est de pire en pire ?

Re: SIEL pour les bus à Paris : c'est de pire en pire ?

Re: SIEL pour les bus à Paris : c'est de pire en pire ?

Re: SIEL pour les bus à Paris : c'est de pire en pire ?

Re: SIEL pour les bus à Paris : c'est de pire en pire ?