In API-ul lor exista si numarul de inmatriculare pentru fiecare vehicul, doar ca au optat sa nu il afiseze si in pagina.

O intamplare de adineauri, veneam la Victoriei sa iau 381 spre Clabucet si pana sa ajung in statie trec 2 381 trenulet, nu le prind, lasand laoparte de ce se circula trenulet la ora 21 la succedere de 9 minute(sau cat o fi) si ca am mai prins si luna trecuta acelasi lucru cam pe la aceeasi ora, ajung in statie, deschid Google Maps, urmatoarea sosire in 4 minute la timp, ma gandesc ca o fi cel de la trenulet si sistemul nu functioneaza dar sosirile urmatoare figureaza cu diferite intarzieri de 1 sau 2 minute si diferite estimari de aglomerare, deci banuiesc ca sistemul functioneaza, astept, sosirea ajunge pe Now si apoi dispare fara sa vina masina, urmatoarea masina ajunge la timp sincronizat cu aplicatia, deci ori datele acelea de intarzieri din Google Maps sunt bagate din burta ori se intampla altceva.

Mi s-a întâmplat și mie ca aplicația să fie atât de inteligentă încât să afișeze următoarele 2 opriri ca fiind cea din orar și cea din realitate. Evident că în realitate venea o singură mașină.

Nu știu sigur dacă la asta te referi...

Eu ma gandeam ca face soferul vreo smecherie cand merge inaintea programului cum ar fi sa scoata mufa de la antena GPS sau antena 3G si o baga la loc la cand intra corect in semicursa urmatoare.
Defapt are sens ce spui, daca gandesc ca un programtor Google Maps, mersul intentionat inaintea programului este un fenomen de tara bananiera, el nu are cum sa apara intr-o tara civilizata, intr-o tara civilizata soferul pleaca in cursa la ora corecta si daca vede ca depaseste programul sta in prima statie pana la ora de plecare corecta, altfel este concediat, de aceea nu are sens sa implementezi un mesaj "vine cu 5 minute inaintea programului" in situatia de ora_estimata_sosire - ora_program_sosire < 0 minute, ce ar fi logic sa implementezi ar fi ori ignora diferenta ca fiind o mica depasire ce va fi reglata prin asteptarea in statia urmatoare pana la ora de plecare corecta, ori, daca este o eroare mai mare de cateva minute, presupune ca operatorul a introdus o masina in plus fata de program si o afiseaza ca o cursa separata care vine la ora estimata si mereu la timp(pentru ca nu este in program) iar cursa corecta devine o cursa la care s-a pierdut semnalul de la masina deci si ea este afisata din burta ca venind la timp.

WT_fan06 wrote here:
Mi s-a întâmplat și mie ca aplicația să fie atât de inteligentă încât să afișeze următoarele 2 opriri ca fiind cea din orar și cea din realitate. Evident că în realitate venea o singură mașină.

Nu știu sigur dacă la asta te referi...

Sistemul de la Telelink permite șoferilor să "duplice" o plecare, în cazul în care este nevoie de două mașini pentru o singură plecare, dar dacă unul dintre șoferi nu intră în sistem atunci aplicația indică două plecări: cea programată și cea real-time. Mă gândesc că șoferul ar fi făcut ceva similar din greșeala...?

Nu are nicio legătură cu șoferul în acest caz, pur și simplu aplicația îmi arată, în anumite situații, atât minutele până la următoarea oprire din orar cât și minutele până la următoarea oprire reală a vehiculului de pe traseu.

După un update al aplicației InfoTB (varianta pentru telefon) a fost schimbată forma pictogramelor care reprezintă vehiculele.

Si tot nu afiseaza numarul de parc... Nu vad rostul largirii pictogramelor. Cum era mai inainte era mai placut de vizualizat, era mai compact. Acum ca sa apesi pe detalile unei statii, trebuie sa faci un zoom-in mai mare din cauza ca pictograma acopera foarte mult din butonul pt. statie. Acum imi pare rau ca am descarcat actualizarea.  

PS: Bug-ul din versiunea web, in care pe unele statii nu se intampla nimic cand dai click (decat cu un zoom-in aproape maximum) a ramas in continuare. E bine ca modifica aiurea pictogramele dar nu rezolva problemele reale.  

La mine în aplicație apar  normal pictogramele.

Trebuie sa ii faci update aplicatiei.

Legat de problemele semnalate de @shoppy și @WT_fan06 cu privire la Google Maps, vă pot da câteva detalii privind posibile cauze.

Spre deosebire de estimările "liniare" făcute de InfoTB care indică următoarele plecări (prima pe fiecare linie sau următoarele 3 pentru o linie selectată) pe baza unei formule care ia în calcul distanța pe traseu a vehiculului și numărul de opriri intermediare până la punctul interogării, fără a ține cont de structura orarului de circulație planificat sau de semicurse (deci dacă vin 2 autobuze unul după celălalt, pot apărea ambele ca venind succesiv într-un minut, etc.), în Google Maps informația care apare ca avans/la timp/întârziere se poate transmite doar prin referință la o semicursă aflată în circulație.

Este o abordare ceva mai rigidă care provine din domeniul feroviar, unde chiar dacă trenul acumulează întârziere, se face referire la el cu ora originală. Adică fiecare plecare programată din capăt a fiecărui traseu are un identificator unic. Acestea sunt în mod implicit afișate ca "Programat" / "Scheduled" în absența datelor în timp real sau dacă se face o interogare de traseu pentru o altă zi decât cea curentă. Pentru ca una din aceste semicurse să devină live și să se coloreze în roșu/verde specific "Early"/"On Time"/"Delayed", Google Maps trebuie să primească o informație privind devierea comparativă față de orar, cu tot cu ora la care ea a fost înregistrată, printr-un mesaj de forma "la ora --:-- vehiculul -- efectuează semicursa -- cu o deviere de +/- x față de orar, are un progres în trafic rapid/normal/întârziat, (dacă există informația) are un grad de încărcare -- (aproape gol / locuri pe scaun disponibile / locuri în picioare disponibile / plin)".

Într-o rețea de transport cum e cea de suprafață din București, unde circulă vehicule cu diferite echipări informatice care transmit date de profunzime diferită și la interval diferit, pentru ca acest sistem să funcționeze se încearcă urmărirea comparativ cu graficul de circulație (secvența semicurselor efectuate de același vehicul). Adică fiecare vehicul care pleacă pe traseu la începutul activității este asociat cu graficul de circulație, fie prin corespondența între semicursa alocată din dispecerizare și graficul din care ea face parte, fie luând la rând toate graficele încă nealocate și găsind care i se potrivește cel mai bine dată fiind ora și locația. Având în vedere că acest lucru nu este întocmai o știință exactă, pot apărea următoarele anomalii:

• Vehiculul este alocat "ferm" pe un grafic de circulație, dar pleacă mai devreme decât activitatea lui următoare conform orarului sau vehiculul nu este alocat dar pleacă dintr-un capăt de linie exact între 2 semicurse -> se creează o semicursă "adițională", ca serviciu de transport suplimentar. Aceasta apare în aplicație doar ca "Live", nu Early/On Time/Delayed și cauzează o altă semicursă să apară doar "Scheduled", însă orele lor nu se vor suprapune;
• Vehiculul este alocat "naiv" (ghicit/intuit) pe un grafic de circulație, dar acumulează o întârziere îndeajuns de mare încât ora la care se află în traseu se suprapune cu alt grafic/semicursă în poziția în care se află -> declanșează o încercare de re-alocare pentru mașina respectivă și eliberează graficul respectiv -> poate cauza "inversarea" în lista de plecări din stație a vehiculelor de pe un traseu și schimbarea eronată a valorilor de întârziere între acestea;
• Vehiculul a fost alocat corect inițial, dar ceva rămâne blocat la sursa de date și deși el circulă aproximativ la timp și transmite date GPS corecte, este transmis cu sensul greșit sau cu referință la o semicursă încheiată (starea în care se poate găsi afișajul interior blocat) sau sunt schimbate vehicule între grafice în timpul programului fără a se actualiza în dispecerizare -> este transmis către Google Maps cu poziția corectă dar o valoare a întârzierii neverosimil de mare, prin urmare el este considerat tot ca fiind o semicursă "adițională", iar aceasta este situația în care apare o plecare din orar în câteva minute și o plecare live în aceleași minute, deoarece semicursa alocată prin care se face referire în mesajele acelui vehicul nu este cea pe care se află în realitate;
• Poziționarea vehiculului s-a oprit (acesta nu stă pe loc neapărat, ci are o ultimă poziție în mișcare, după care s-a întrerupt transmiterea) -> în acest caz va apărea o discrepanță între InfoTB și Google Maps în stațiile ce vin după ultima poziție cunoscută, deoarece pe InfoTB timpul va "sta", din moment ce poziția nu se mai apropie de punctul interogării, însă pe Google Maps, până la un time-out de 5 minute, se vor afișa trecerile prin stație ale vehiculului relativ la ultima întârziere cunoscută, fiind astfel posibil să apară "Now" pentru un vehicul care nu se mai mișcă sau care a deviat de la traseu, dacă acesta nu continuă să trimită date asociate semicursei respective.

Din păcate, de la implementarea inițială cu mai mulți ani în urmă și până în prezent funcționarea real-time în Google Maps pentru București s-a degradat vizibil, deși în logica și infrastructura software și transmiterea datelor nu s-a schimbat nimic. Ce s-a schimbat este că după o perioadă în care STB și-a respectat cât de cât orarul, a revenit în haos, peste care adăugăm faptul că timpii de parcurs au crescut pe teren din cauza înrăutățirii traficului sau a începerii lucrărilor la diferite șantiere, fără a fi reflectat în orarul teoretic STB, așa că semicursele programate au devenit din ce în ce mai neverosimile și probabil să fie ratate. Cu cât orarul teoretic și situația din teren devin mai deconectate, cu atât apar deficiențe în ce ține de real-time pe Maps. Aici putem adăuga și devieri descrise doar în text și ne-operate și în aplicație, etc.

Există și alte aplicații care folosesc Open Data de la TPBI și care gestionează altfel aceste edge case-uri, punând mai mult accent pe un count-down corect până la venirea în stație și mai puțin pe a respecta cu strictețe referința semicurse din orarul static - vehicule. Vă recomand să le încercați - o variantă este Transit App, care în opinia mea are o funcție de "Next departure" foarte performantă și pe lângă asta are funcții colaborative (eg. crowdsource la cât de aglomerate sunt vehiculele acolo unde nu este cunoscut acest aspect din sistem / feedback privind corectitudinea timpului de așteptare indicat) și instrucțiuni pas-cu-pas detaliate în notificări în timpul călătoriei (inclusiv la metrou, în absența semnalului GPS, folosind accelerometrul telefonului), o altă variantă este Citymapper care are și o aplicație companion pentru smartwatch-uri.

Dacă vreți să faceți o comparație pentru a vă convinge că depinde în cea mai mare parte de respectarea orarului măcar în ce privește secvența plecărilor din capăt, deschideți pentru comparație în aplicația Google Maps o stație de transport public de suprafață din București și una de transport public local din Timișoara, în timpul zilei, pe telefon. În București veți vedea unele semicurse cu date live, altele nu, câteva duplicate, etc., iar în Timișoara o să fie toate cu date live, întârzieri verosimile și în ordinea în care vin pe traseu. Soluția tehnică din spate este identică, ce diferă este temporizarea corectă a duratelor semicurselor și un minim efort privind respectarea plecărilor din capete.

În primul rând mulțumim pentru explicațiile exacte, consider ca informațiile oferite de tine pe acest subiect sunt întotdeauna extrem de valoroase. Personal, dacă ar fi să spun o părere personală: CityMapper și Moovit afișează întotdeauna bine timpii de sosire în stații (la fel ca InfoTB). Din punctul meu de vedere, Google Maps folosește o soluție prea rigidă pentru București și pentru orice oraș cu trafic aglomerat. Sunt linii ale STB pentru care nu se face niciodată corect alocarea pe semicursa a tuturor vehiculelor de pe traseu. Și pe lângă problema aceasta, Google Maps mai are și alte probleme, cum ar fi în cazul liniilor circulare, cu un singur capăt de linie efectiv și celălalt capăt doar virtual. Cum este Banu Manta în cazul liniilor 1 și 10 sau Piata Romana in cazul liniilor 331 si 301. In aceste stații, Google Maps nu afișează niciodată informații în timp real. De ce? De exemplu în cazul liniei 301 care are traseu Piata Romana tur - Jollie Ville Retour. În Stația Piața Romana, Google Maps consideră returul Piata Romana - Jollie Ville o cursa cu totul nouă și afișează doar teoretic, fără a lua în considerare pozițiile vehiculelor de pe turul Jollie Ville Piata Romana. Deci mult prea rigid pentru un oraș mare și aglomerat . Google Maps are pretenția ca 301 să ajungă tot timpul la Piață Romana la timp exact ca în orar, ceea ce știm cu toții ca mai ales la orele de vârf e greu.  Pe lângă astea, sunt cazuri (punctuale, ce-i drept) în care liniile/statiile sunt mapate greșit. Sunt multe locuri în care există o stație pentru liniile STB, și încă una fix lângă pentru liniile regii, deși ele ar trebui unificate. Iar ca tot am vorbit de 301, la retur spre Jollie Ville în loc să apară ca luând-o direct pe Calea Dorobanti (așa cum se întâmplă în realitate), în Google Maps linia face o bucla ciudată pe niște străzi secundare.

Problema nu este la GMaps, problema este la rețeaua de transport..  Faptul că orarul teoretic este dat peste cap în asemenea hal încât algoritmul Google nu mai interpretează corect datele din teren este o dovadă a incompetenței autorităților de a asigura un transport în comun predictibil și civilizat, de ce nu se fac benzi unice, de ce nu se fac semaforizări coordonate și comandate speciale pt STB? Dacă vehiculele vin haotic, suntem în situația unei țări bananiere cu rate ce vin la nimereală, 2-3 în câteva minute și apoi stai și aștepți 40 min. altul.

Google are programatori mulți și extrem de buni, iar algoritmul lor mi se pare foarte logic, pentru că nici în STB nu cred că se fac curse ad-hoc nenotate în dispecerat, cel mult se pierd curse existente. Deci orice cursă are o fișă și un orar teoretic. Așa că vina este în totalitate a TPBI pentru că 1. nu ia măsurile de mai sus pentru fluidizare. și 2. nu adaptează orarele la realitate. La 1 este lipsă de voință politică, înțelegem. La 2 însă este frica de a nu pune pe hârtie o realitate dezastruoasă, și anume o semicursă care să dureze 100 de minute sau ceva de genul => asta ar demonstra inutilitatea transportului în comun și lipsa de motivare pentru cetățean să îl folosească, dacă stă în autobuz în trafic la fel ca și mașinile personale.

@Albert pe Google Maps sunt n situații, în prezent, în care traseul anumitor linii nu este afișat corespunzător situației „din teren”. La fel este și cu linia 61 care, conform Google Maps, după ce pleacă din stația „Piața Operei” (sens centru), face un ocol/buclă, și „circulă” pe Splaiul Independenței, stânga la Pod Hașdeu, apoi stânga pe Bd. Mihail Kogălniceanu, efectuează aceeași stație cu vehiculele care merg pe sensul către Militari, apoi o ia pe Splaiul Independenței, Str. Știrbei Vodă, Calea Plevnei, Str. Vasile Pârvan, iar abia apoi intră pe traseul obișnuit, făcând stânga pe Bd. Mihail Kogălniceanu. Evident, este eronat. Google Maps întârzie în a actualiza datele. Sunt linii care și acum, dacă nu mă înșel, apar cu trasee deviate de acum câteva luni. Țin minte că, pe Google Maps, acum ceva timp îmi afișa că 679 (cred) încă circulă pe la Romană, când de fapt, acea linie a circulat doar un weekend în 2024…