Este norml sa lucrezi dupa programul de circulatie, persoana care vrea sa ajunga undeva maine la o anumita ora va introduce sursa si destinatia in Google Maps plus sosirea maine la ora dorita si va obtine itinerariul; de asemenea daca face invers si stie dinainte ora la care poate porni va introduce asta ca ora de plecare si va afla cand va ajunge; mai exista si functia de "last available".
Asta inseamna transport public civilizat si se aplica in toate orasele civilizate, si acolo este locul unde Google Maps trebuie sa functioneze bine, ca STB nu este civilizat inseamna ca trebuie sa devina civilizat nu ca Google Maps este prost.

Am vazut si eu ciudatenii pe trasee pe Google Maps, cred ca Google Maps primeste statiile si el stabileste traseul minim intre ele, poate ca ar trebui sa se transmita si puncte intermediare ca traseul sa fie clar.

Problema cu linia 61 și în general cu liniile de pe Elisabeta și Dorobanți este că Maps nu înțelege că acele străzi, deși sunt cu sens unic pentru traficul general, sunt totuși deschise în dublu sens pentru transportul public. Astfel că, atunci când rutează între stații pe sensul opus celui unic pentru traficul general, se generează acele anomalii de trasee.

Google Maps poate intelege ca o strada este complet inchisa traficului auto (cu bariera), dar deschisa transportului in comun (bariera se ridica pentru autobuze), in Oslo. Deci si aici, unde sensul unic este "cu exceptia transportului public", este o situatie pe care Google Maps o poate intelege si integra in algoritmul sau, daca este modelata corect in harta de catre cei care furnizeaza datele pentru transportul public.

Modelarea sensului unic nu cred că ține de furnizorul datelor API pentru transportul public, ci hărții în general. Dacă acel link nu este modelat ca fiind sens unic cu excepția transportului public, atunci datele din API se bat cap în cap cu cele din hartă și rezultă rutări anormale.

Dar culmea ca la inceputuri arata corect traseul, 90-ul stiu sigur ca nu avea ocolul de acum.

Legat de disponibilitatea informațiilor în timp real la capăt de linie, ai identificat o problemă reală @Albert dar ai ilustrat-o parțial corect. Mai exact, există 2 moduri de a transmite "legarea" a 2 sau mai multe semicurse între ele pentru a propaga informațiile privind întârzierea "peste capăt". Varianta preferată și care funcționează cel mai bine este transmiterea interdependenței între semicurse deodată cu orarul static - în acest moment în București se întâmplă asta doar pentru liniile 1 și 10 la Banu Manta (deci ce ai reclamat legat de 331 și 301 este corect) pentru că este un traseu cu adevărat circular și a fost prevăzut acest lucru ca excepție, și tocmai de asta acolo funcționează corespunzător (orele/minutele sunt actualizate pentru plecările din Banu Manta dar vehiculele nu apar ca în mijlocul unui traseu, acolo e decizia de UI/UX a Google): Poate observați o problemă în captura de ecran. Această legătură permanentă între semicurse are ca efect secundar indicarea către utilizatori a faptului că pot rămâne în vehicul la capăt pentru a efectua transferul. Teoretic nu ar trebui să se întâmple, deoarece legarea semicurselor între ele la nivel operațional și regulile de transfer între acestea pentru călători sunt aspecte distincte modelate în structura de date (cele din urmă fiind folosite cu succes la calcularea tarifului de exemplu), dar totuși se întâmplă. Pentru liniile 1 și 10 este perfect adevărat, dar dacă s-ar transmite acest parametru conform cu graficele de circulație pentru toate liniile din București, s-ar putea sugera rămânerea în vehicul la capăt și în situații când acest lucru nu este posibil. Deci a existat o decizie deliberată de a nu transmite aceste date, însă ca și compromis se transmit întârzierile ca mesaje de actualizare în timp real pentru semicursele următoare din graficul de circulație al fiecărui vehicul, dar acest aspect se supune regulilor de validare pentru ambele semicurse - deci dacă se întârzie peste 30 de minute sau pleacă vehiculele într-o ordine contrară secvenței așteptate de la capăt, nu doar semicursa curentă e afișată eronat, dar datele în timp real lipsesc și pentru următoarea din secvență pentru acel vehicul, putând astfel să se ajungă în situația oarecum absurdă în care este afișată o plecare "teoretică" din capăt asociată cu un vehicul care încă este departe pe traseu, în întârziere atât de mare încât datele au fost invalidate iar legătura "permanentă" între semicurse lipsind pentru a preîntâmpina situația în care s-ar sugera eronat rămânerea în vehicul pentru liniile unde acest lucru nu se aplică. Poate e o decizie asupra căreia s-ar putea reveni. Oricum, au mai fost și alte aspecte luate în calcul, nu doar riscul menționat. Precum faptul că în diagramele actuale care descriu programul operațional STB, nu se menționează din ce linie în ce linie au loc aceste schimburi, deci nu se poate determina programatic într-un mod ferm, e fie o determinare "fuzzy" bazată pe orarul din stația de capăt și interpretarea parțială a diagramelor menționate, cu riscul apariției unor curse legate în mod fals pozitiv, fie o regulă de tip excepție care se definește de mână pentru import, așa cum s-a făcut doar pentru 1 și 10.

Legat de traseul între stații, transmiterea lui în mod explicit (coordonate intermediare constând în parcursul pe șosea) este opțională, așa că Google are capacitatea să îl genereze și în mod automat. Cu toate acestea, pentru București aceste date sunt transmise corect către Google Maps. Problema apare atunci când forma transmisă pentru traseu diferă prea mult de cea la care se așteaptă aplicația, așa că are loc o intervenție forțată și datele sunt suprascrise. Din păcate aceste modificări sunt în mare parte inutile și greșite în cazul Bucureștiului. Toate exemplele date de voi cu devieri inexistente în realitate intră în această categorie și mai am eu câteva exemple, cum a fost comasarea accidentală a stației "Autogara Militari" de pe bd. Iuliu Maniu cu terminalul de autocare "Autogara Militari" atunci când acesta a fost inclus în datele transmise de Flixbus pentru rutele lor internaționale care pleacă de acolo, aparent operatorul cu aria geografică de deservire mai mare având prioritate în automatizarea de "corectare" a datelor de la Google (problema aceasta a fost rezolvată). Puteți vedea mai jos cum diferă datele afișate de cele transmise de la sursă: Motivul pentru care Google Maps nu cunoaște sau nu înțelege existența benzilor dedicate pe străzi cu sens unic nu îl cunosc. Poate e ceva ce Google nu a reușit să determine automat din sursele lor de date (eg. citirea semnelor de circulație de către mașinile street-view) și ar trebui cumva furnizat de autoritățile responsabile de administrarea infrastructurii rutiere (așa cum sunt transmise și închiderile străzilor cu ocazia diferitelor evenimente, etc, oricum e ceva separat de această interfață API pentru datele legate de transportul public), iar acest lucru nu s-a întâmplat. Oarecum ironic este că în pipeline-ul de automatizare a publicării datelor forma pe șosea a traseului desenată de STB este și ea corectată în mod automat printr-un algoritm de "snap-to-road" bazat pe datele gratuite și deschise de la OpenStreetMap, iar acele date conțin benzile de bus definite pe direcțiile corecte, așa că formele rezultate sunt corecte.
Aceste situații nu se întâmplă doar în București. Am întâlnit personal în Praga și Copenhaga. Până la urmă, între stații m-a interesat mai puțin acuratețea liniei figurate pe hartă, important era să știu unde să aștept autobuzul.
Tratarea acestor intervenții eronate asupra datelor corecte se face manual, dând mail la suportul Google cu detaliile. De câte ori le semnalați aici sau prin sesizări la TPBI, se iau toate măsurile pentru a corecta, dar din păcate multe dintre probleme revin. De exemplu traseul liniei 61 a mai fost corectat o dată prin această procedură în decembrie 2024, iar acum este din nou deviat eronat, așa că am adus din nou problema în discuție cu reprezentanții de la suportul Google.

Ca fapt divers, plecările duplicate / fantomă în care un vehicul la timp/în avans e afișat live, iar după el e și plecarea din orarul teoretic se mai întâmplă și pe InfoTB. O situație am întâmpinat-o eu azi. Probabil vehiculul nu a fost alocat pe grafic/semicursă, așa că aplicația nu are de ce să îmbine cele 2 elemente. În acest caz particular pe Maps apărea corect, fiind un traseu simplu cu puține vehicule în parcurs, complexitatea pentru a "ghici" care efectuează ce grafic fiind redusă.
La finalul zilei, Google Maps e foarte util ca aplicație deja existentă pe telefoanele vastei majorități, chiar și cu aspectele care pot să fie limitări în situația actuală din București. E și foarte util ca punct de plecare pentru a obține un itinerariu cu toate opțiunile de transport comparate între ele sau pentru planificarea unei călătorii cu metroul, având și pentru acesta orarul static introdus, împreună cu toate gurile de acces în stații figurate. Pentru un simplu count-down până la următoarea plecare din stație a transportului de suprafață pe o rută cunoscută, InfoTB cu siguranță e în continuare cel mai apropiat de realitate prin simplul fapt că e cu un intermediar în minus față de restul aplicațiilor, iar pentru urmărirea progresului în timpul unei călătorii Transit și Citymapper oferă o experiență foarte bună. Transit funcționează și în multe alte orașe din România.
Pe cei de la Moovit nu-i voi recomanda personal vreodată pentru că au reclame foarte agresive la diferite jocuri de noroc și case de pariuri, full-screen între interogări în aplicație.

Bun, sa spunem ca problemele de mapare se pot rezolva, cum ai zis si tu. Probabil trebuie mapate in Google Maps acele benzi ca fiind cu sens unic doar pentru STB. Ar mai rămâne problema legării a doua semicurse: sunt multe linii in București care au capăt artificial, așa cum se întâmplă cu 301 si 331 la Piață Romana. Nu am putea face solicitare/petiție la TPBI pentru a transmite si in acest caz interdependența dintre doua semicurse așa cum se întâmplă pentru liniile 1 si 10? In toate cazurile, la capătul artificial fac si returul, iar retragerea se face la capătul principal, nu la cel artificial, deci nu ar fi eronată informația de "a rămâne in vehicul". De asemenea, pe lângă aceste lucruri, ar mai fi o chestiune de menționat si anume faptul ca sunt multe locuri in care avem stații dublate. Exemplu concret: stația Perla unde avem o stație pentru liniile 301/331/331B/335/N119 si încă o stație pentru linia 461. Aceste doua stații ar trebui unificate, așa cum sunt trecute si in InfoTB.

Floreasca are retrageri din 301 si de la Piata Romana.

Da, caz în care se afișează greșit și în InfoTB. Adică apare ca autobuzul vine în 0 min, dar defapt el ajunge în stație, lasă călătorii și apoi pleacă la autobază, nu pot să mă urc în el ca și călător. Deci oarecum în toate cazurile sunt minusuri, dar consider ca minusul in cazul acesta este mai mic decât in cazul celălalt. Adică da, ai câteva retrageri pe zi care sunt afișate eronat în aplicație ca ajungeri în stație, dar în același timp ai zeci de plecări în semicursa legată de semicursa precedentă care sunt afișate corect.

Aplicația InfoTB devine o rușine din ce în ce mai mare când vine vorba despre oferirea de informații CORECTE și UTILE călătorilor.

De exemplu, cu toate că vehiculele apar, în majoritatea cazurilor, în mod corect ca fiind accesibile sau nu (după caz), toate plecările următoare din stații apar ca fiind accesibile, chiar și atunci când vehiculele care vin nu sunt accesibile.

Mai mult, unele plecări au chiar și wifi, cu toate că pe teren este prezent doar sub forma unor stickere anacronice.

Voi trebuie să înțelegeți că există niște programatori care s-au ocupat cu desemnarea acestor insigne pentru fiecare vehicul în parte. Să zicem că, în cazul wifi-ului, au folosit vreo bază de date furnizată de STB fără să-și dea nimeni interesul vizavi de corectitudinea informației. Dar, în ceea ce privește apariția eronată a tuturor plecărilor ca fiind accesibile, eu nu găsesc altă explicație decât implementarea deficitară a categoriei de vehicule accesibile, adică fix informația importantă pentru multiple categorii de călători.

Degeaba e țara plină de programatori, dacă nu face nimeni controlul calității...

Acel semn de WiFi este pentru a semnaliza faptul că aplicație primește date GPS de la mașina respectivă.

La mine pe telefon apar corect categoriile. Iar designul este cel vechi cu cerculețe, nu cel nou.

TTony wrote here:
Acel semn de WiFi este pentru a semnaliza faptul că aplicație primește date GPS de la mașina respectivă.

Mai exact, acea sosire estimată este bazată pe informațiile de la GPS-ul vehiculului respectiv. Dacă semnul "wifi" lipsește este vorba de sosire teoretică conform programului de circulație. Asta se întâmplă când vehiculul nu a plecat încă de la capăt, iar aplicația presupune că se va pleca conform programului. Când vehiculul se pune în mișcare și șoferul selectează semi-cursa se va actualiza cu estimarea conform GPS-ului. Din păcate această diferență nu este cunoscută de mulți utilizatori ai aplicației și apar frustrări atunci când programul nu se respectă din diverse motive.

Legat de semnul de accesibilizare, pe iOS (iPhone) aplicația arată corect vehiculele. Știu că versiunea web avea un bug și afișa ocazional toate vehiculele ca fiind accesibilizate, acolo se rezolvă cu un refresh.

Si mie imi arata corect...