Tak sme dnes dali pokus - 3x waze klient na BA-inline, z toho jeden v prednom sprievodnom aute, ostatne v dave. Tak som dufal, ze za nami pojde pekna cervena ciara a bude vidno kde zrovna sme a ktorej oblasti sa radsej vyhnut. Vysledok nic moc, sem tam sme zapchu vyrobili, ale vacsinou na to proste kaslal, tusi niekto preco, ked inokedy mi s radostou vyrobi zapchu ked niekde na chvilu zastavim? Pripadne ako to vylepsit?
tam to striedanie tras ma trapi. Cez jeden z reporterov(wazebot/egaraz) by sa to dalo nastavit manualne asi ako varovanie.
toto zavisi od priemernych rychlosti daneho segmentu kadial ste isli. A vylepsuje sa to napr. proste jazdenim po danej trase tou “normalnou” rychlostou :)…
pripadne daj nejake permalinky, kde ti vyrobi zapchu po chilkovom zastaveni
Ak ides po ceste kde zapchy su bezna vec, tak zapchu vyrobis tazko. Ale skus ist niekde mimo civilizacie a bude ti aj pri 50km/h robit zltu trasu. V Chorvatsku je tak malo wazerov, ze tam kazda jazda robila zapchy aj mimo obce. Stacilo ze som isiel serpentinami menej ako 90.
na toto som zvedavy koncom augusta :D.
Rovnako sa to da otestovat na dopsinskom kopci…
Sent from my GT-I9000 using Tapatalk 2
No minule mi napriklad vyrobil zapchu tu ked isiel vlak.
Cize vravite, ze nema zmysel to takto riesit, cervena ciara nebude? Takze jedine riesit cez reporter. Trasy nie su problem, tie su tu (klik na trasu) a v piatok okolo tretej je tam potvrdenie ci sa ide (pocasie). Ale je to take ze rozptyl 2 hodiny a pol mesta. Dufal som, ze to pojde presnejsie, kedze jeden waze klient sa pravidelne vozi v prednom sprievodnom aute 
Určite nebude, iba ak by si rôznymi operáciami zvýšil priemernú rýchlosť segmentu.
Ja mám teraz opačný “problém”. Množstvo segmentov na prejazdnom parkovisku som pospájal dohoromady a včera aj dnes som tam pri parkovaní vytvoril zápchu (22km/h). Časom sa to upraví.
No aspon konecne chapem tie divne routingy, ked ma silou mocou taha po obchvate aj ked viem, ze cez mesto by to bolo zrovna rychlejsie, proste su v meste kvoli castym zapcham nizke priemerky. Este sa mozem skusit pohrat so zdrojakmi stareho klienta. Netusi niekto, ci zapchu vyraba klient alebo len posiela poziciu a server si to dorata?
Myslim ze klient, v konfiguracnych suboroch ma nejake konstanty, na zaklade ktorych sa rozhoduje, kedy “to” uz asi je zapcha. Potom sa este asi spyta a potom uz vyfarbuje.
Obrat sa na Nocturna7, ten sa s nimi hral, aby maximalne potlacil vytvaranie zapch pri jeho jazdach. (Ja som to skusal tiez, z brucha, ale netestoval som vysledok.) Mozno by sa ti s jeho info podarilo dosiahnut opacny vysledok.
V “preferences” subore su zaujimave riadky, ktore este na 2.4.x androide (asi) fungovali, od 3.x nie, okrem guriho spesl twiikov 
Traffic Detection.Feature enabled: yes
...
Traffic Detection. Number of seconds to ask: 30
...
Traffic Detection.Speed: 15
Priatelia, nemam teraz cas, ale urcite sa k vasim klebetam vyjadrim
Ahojte priatelia,
Takze aby bolo jasno:
1.) INTL waze klient infrastruktura je v skratke tvorena dvomi oblacikmi - jeden z nich je tzv. “real-time server”, ktory bezi na AWS. Ma na starosti prihlasovanie do klienta, zobrazovanie wazerov, zobrazovanie dat (zapchy a eventy), a preberanie vsetkych informacii od klientov. Druhy oblak je tzv. “routing server”, ktory ma na starosti planovanie cesty najlepsou moznou trasou vzhladom na historicke a realtime data. Samozrejme je tam aj kopec dalsich ucelovych sucasti (ako napr. server ktory distribuuje map tiles pre klientov aj pre WME), ale to teraz nie je podstatne. [Zistene odchytavanim dat, studovanim zdrojaku, ciastocne z vyjadreni od waze]
2.) Cela infrastruktura bojuje s kapacitnymi problemami. Prakticky jedina cast ktora nimi netrpi je real-time server beziaci na AWS. Kvoli tymto problemom musia ajtaci z waze robit vela optimalizacnych opatreni. Preto im tak dlho trva implementacia novych funkcii - snazia sa aby zatial spolahlivo bezali aspon tie stare, co casto vedie az k extremnym opatreniam. Problem je, ze Waze o tomto nekomunikuje, dokonca ani s top wazermi. Vsetci dufame, ze coskoro sa to zlepsi. [Vlastne zistenia + zahmlene oficialne info]
A teraz podme k podstatnemu:
3.) Waze klient po zapnuti caka, kym dosiahnete urcitu rychlost (30? 40? km/h - neviem), cim sa potvrdi ze uz idete v aute. Az po tom reportuje real-time serveru vasu cestu. Samozrejme ak mate extremne slaby GPS signal, moze sa stat to, ze fiktivne tu rychlost dosiahnete aj ked stojite doma pri okne. [Zistene z praxe, oficialne nepotvrdene]
4.) Klient nereportuje zapchu ako taku. Klient moze reportovat iba event “zapcha”, ktory ale ma iba minimalny vplyv na routing (podla oficialnych vyjadreni zdvojnasobuje vahu zistenej rychlosti na oznacenom segmente). Co to ale vaha je, zatial oficialne nevieme a klebety tu sirit nebudem. [Zistene z praxe, dvojnasobna vaha oficialne potvrdena]
5.) Klient reportuje cas potrebny na prejdenie kazdeho segmentu na vasej trase. Ak servery uznaju, ze vypocitana rychlost na segmente je nestandardna, informuju real-time server ze ma oznacit segment farebnou ciarou. Robia to ale servery, nie klient. [Zistene z praxe a odchytavanim dat]
6.) Parametre ktore sa daju nastavit v konfiguraku bohuzial nic neriesia. Riesia iba to, kedy vam ma vyskocit okno “stojite v zapche?”, bohuzial ale to okno nerobi nic ine, nez umiestnuje zapchovy event (ktory zdvojnasobuje vahu uz zistenej rychlosti). Toto sme naposledy analyzovali vo verzii 3.0, mozno sa odvtedy nieco zmenilo. [Zistene z praxe a oficialne potvrdene]
Pekne si sa rozpísal
Dnes sa mi podarilo vytvoriť zápchu s dvomi rôznymi rýchlosťami na jednom segmente. V strede bola 14km/h a pri kraji 7km/h. Screenshot nevyšiel, zachytil som biele pozadie. Predpokladám každá z rýchlostí bola v inom smere, v tom lejaku som nemal možnosť prevádzať nejakú analýzu.
Dakujem za skvele zhrnutie.
1 a 2 som uz viac-menej vypozoroval. K zaveru bodu 2, v co dufate, ze sa zlepsi kapacita infrastruktury, alebo komunikacia Waze?
3 - ta rychlost bude zrejme mensia, kedze nie je problem vyrobit reporty na korculiach, skusim otestovat.
4 - je mi jasne, ze event zapchu nerobi, maximalne jej malicko pomoze.
5 - no a teraz to zacina byt zaujimave, co presne klient posiela? timestampy na junctions? cas za ktory presiel segment? alebo priebezne data o polohe, nech si to servre preberu same? snazim sa skompilovat 2.4 klienta (zatial neuspesne) a potom by som sa v nom rad trosku porypal a upravil ho aby vyrabal zapchy takze kazde nakopnutie pomoze
6 - hej, konfigurak som pozeral a ziadne slubne vyzerajuce parametre ani v 3.2 nie su
no a este nech zhrniem k comu som zatial dospel - neupraveny klient v prednom sprievodnom vozidle je na figu, vzhladom na priemerky co budu na segmentoch v centre (btw. kde si ich viem pozriet?) ide pomerne rychlo a potom zas stoji niekde pred krizovatkou a caka kym to “zadok” dobehne, co zjavne servre vyhodnotia ako normalnu jazdu. klienti co sme mali na korculiach/kolobezke mali dost podobne chovanie, kedze blokujeme krizovatky a potom sa snazime rychlo dostat dopredu - preto zrejme obcas zapchu hodilo, ked to rychlo nebolo dost rychlo takze skusim to v piatok (ak pocasie dopraje) spravit inak - drzat sa niekde v strede davu a ist plynulo pomaly. ak to bude fungovat a podari sa mi toho klienta skompilovat, tak ho skusim upravit aby simuloval podobne chovanie na prejdenej trase.
Kapacita, ale ta komunikacia by sa mohla tiez 
Priklad:
DATE: Tue Jun 12 16:47:19 CEST 2012
URL: /rtserver/distrib/command
IP: 85.237.224.45
WUID: 311450657 LON: 17181262 LAT: 48196322
UID,311450657,zD63DBwGgKqW2mXKM
At,17.181262,48.196322,0.000180,84,1,153039280,155825690,T
MapDisplayed,17.217212,48.206576,17.219608,48.191332,17.179260,48.194636,17.178782,48.197748,17.186872,48.196744,2789
GPSPath,Default,1339512426,12,17.178654,48.196254,180,0,17.178863,48.196228,180,1,17.179500,48.196186,180,3,17.181048,48.196
NodePath,1339512394,4,148240347,0,153039280,32
At: Tvoja poloha (kde ma zobrazit tvojho panacika), azimut, zvysok budu ID segmentov / junctions a nejake stavove info;
MapDisplayed: Vyrez 2D/3D mapy ktory mas zobrazeny (aby server vedel pre ktory vyrez ti ma poslat eventy)
GPSPath: Tvoja cesta ktoru si presiel od posledneho updatu;
NotePath: Rovnako tvoja cesta ktoru si presiel od posledneho updatu, ale s ID segmentov / junctions a zrejme poctom sekund.
Ak by si mal zaujem, mozme dat k tomu stretko.
Pre rocnik 2013 sme rozbehli nove kolo rokovani s BA-inline a Waze Supportom. Ak to vyjde, tak v priebehu jednotlivych jazd by mali byt casti ulic kratkodobo oznacovane bud ako upchate, alebo ze je na nich uzavierka-podujatie. Jednak by to konecne malo byt viditelne v klientovi a aj routing servery by tade nemali ponukat trasy, ale obchadzky okolo.
Kedze (bolo) treba dat Supportu k dispozicii zoznam ID segmentov a casovy harmonogram ich blokovania, na niekolko tyzdnov vopred (na obdobie jul - august), dohodli sme sa na ich zamknuti na L6 a odomknuti po skonceni podujatia. Potrebu pripadnych zmien tych segmentov budeme samozrejme riesit, jednotlivo. Zrejme to asi bude obcas nutne, pretoze je (bude) zamknutych mnoho hlavnych tahov v Petrzalke a Ruzinove a centre. (BA-inline na svojich strankach spomina(la) aj Trnavu, Nitru a Piestany, ale o nich sme (zatial) nediskutovali.)