Witajcie,
mam następujący problem z drożnością jednej z głównych ulic w Zielonce pod Warszawą.
Chodzi o ulicę Marecką. Niedrożne jest skrzyżowanie z ulicą Mazowiecką.
sprawdzałem “connectivity” i wszystko jest ok (pomarańczowe i zielone oznaczenia w każdej konfiguracji)
zrobiłem “enable all turns” na tym skrzyżowaniu na wszelki wypadek
Niestety dalej jest nieprzejezdne i waze kieruje jakimś chorym objazdem.
Sprawdzałem z warstwą “restricted turns” i tam pojawia się coś dziwnego. Na samym skrzyżowaniu nie ma żadnej czerwonej strzałki, ale parę metrów na wschód jest czerwona strzałka mimo, że nie ma skrzyżowania.
Czy ktoś mógłby pomóc? Dodam, że zmian dokonywałem jakiś tydzień temu, więc chyba zmiany powinny być już w live map? Ale skąd ta strzałka?
Nie widzę tu nic nieprawidłowego oprócz tej strzałki, ale ona raczej nie ma znaczenia. Moim zdaniem coś jest nie tak z węzłem. Udało mi się tym węźle zobaczyć też błąd 26.
Pomajstrowałem trochę przy tym skrzyżowaniu - odpiąłem Mazowiecką, usunąłem węzeł i stworzyłem nowy w tym samym miejscu.
Jak to nie pomoże to IMHO trzeba pisać do supportu.
Poprawiłem Mazowiecką na pozostałej jej części - była niedopięta do kolejnego skrzyżowania, a potem jednokierunkowa na jednym z węzłów. Radosne objazdy mogą być spowodowane czym innym - waze być może ma statystyki prędkości, które każą mu szukać innych dróg. To samo miałem w Markach, na Piłsudskiego - jak się domyślam, większość wazerów jeździ tamtędy z i do pracy, czyli w porach największych korków. Ja jeździłem głównie albo w południe, czy nocą, a więc po pustych drogach, albo w przeciwną stronę, niż bieżące korki, a i tak ponad miesiąc trwało, nim się nauczyło, że można prowadzić tą ulicą prosto (łojezu, jakie zygzaki mi proponowało!). A żadnych problemów z przejezdnością węzłów tam nie było, które uniemożliwiałyby trasowanie na wprost…
Sądzę, że trzeba trochę poczekać, jest szansa, że po kilkudziesięciu przejazdach “załapie”…
To są błędy programowe albo w Cartouche, albo w serwerach waze’a. Wygląda na to, że jeśli edytujesz jakiś odcinek drogi, przesuwając jeden z końców, to czasem odcinek sąsiadujący z nim nie w całości i nie w każdym podsystemie załapuje, że jego koniec też się przesunął. Na mapach wszystko wygląda poprawnie, ale nawigacja przestaje działać. Pisałem o tym tu: http://world.waze.com/forum/viewtopic.php?f=10&t=9421 oraz zgłaszałem supportowi jeden konkretny przypadek. Nie wiem czy znaleźli przyczynę i naprawili, czy każdy przypadek zamierzają i zalecają rozwiązywać oddzielnie, to znaczy naprawiać skutki, a nie przyczyny problemów. Obawiam się, że jednak prawdziwe jest to drugie.
Możesz mieć też włączoną opcję “Preferuj żucie asfaltu”. Jeśli nie masz, to rzeczywiście są takie możliwości, że:
są dziury w mapach,
statystyki pokazują, że są korki, chociaż w tym konkretnym momencie nie ma,
albo waze pokazuje lepszą drogę, niż Ty byś znalazł.
A propos statystyk korków: ostatnio dowiedziałem się od supportu, że waze zbiera statystyki zależne od pory dnia, więc nie ma tak, że skoro w dzień są korki, to w nocy też każe je omijać.
Nienienienie… Nie tak… Jako programista, podchodzę z zawodową podejrzliwością do wszelkiej maści softu. Sprawdzałem: żucie wyłączone, szukanie najkrótszej - nadal próbowało prowadzić opłotkami. I to takimi, że hej! Po kilometr w bok - a co! Dziur w mapie nie było, sprawdziłem już pierwszego dnia. Aktualizacje wtedy odbywały się całkiem często - ale po dwóch tygodniach nadal prowadziło źle. Jeździłem uparcie prosto, aż w pewnym momencie załapało - teraz już wie. I już samo zawsze tak prowadzi.
Co do statystyk odnośnie pory dnia. Sądzę, że dopóki nie ma wystarczająco pewnych danych z różnych pór, to, co zostało zgromadzone, ma wpływ na sąsiednie kwanty doby. Więc jeśli jest mnóstwo informacji, że od siódmej do dziesiątej jest korek, to Waze zakłada, że korek może być również i o szóstej, i o 11:30… Póki ktoś, jeżdżąc, nie przekona go, że tak nie jest. To rozsądne podejście, bo prowadzi szybciej do sensowniejszych statystyk, niż zakładanie a’priori, że wszędzie zawsze korków nie ma i dodawanie ich w miarę pojawiających się informacji, bowiem zmiany obciążenia dróg znacznie częściej są płynne, niż skokowe. Przy większej liczbie użytkowników statystyki szybko stają się wiarygodne, to tylko samemu trzeba jeździć tygodniami…
Panowie, gdzie Wy macie opcję “preferuj żucie asfaltu” w Cartouche? Co mają do tego statystyki prędkości na odcnku? Przecież widać w highligt connectivity, że droga jest przejezdna. Jeśli średnia prędkość na odcinku byłaby 0km/h lub na/na to i tak Wam wyliczy tą drogą bo jest 200m a nie nakładając 1km… Dla testu możesz odpiąć dalsze skrzyżowania i zobaczyć czy wyliczy.
Z tymi strzałkami to stary bug. Nie wiem czy go naprawili, czy też nie ale swego czasu pisali, żeby nie korzystać z tej opcji tylko z highlight connectivity.
Nic tylko pisać do supportu, daj im permlink i naprawią.
Jako programista z ponad dwudziestoletnim stażem mogę powiedzieć, że widziałem od cholery niedopracowanego softu, sam takiego nasiałem też mnóstwo. I już nic mnie nie wkurza, najwyżej powoduje ciężkie westchnienie. ;-D Zaś co do cartouche, to nic nie jest bardziej przyłamujące, niż tunele podprzestrzenne, które on sobie czasem potrafi utworzyć. Z jednym miesiąc walczyłem. Skończyło się na narysowaniu drogi od nowa.
Jako programista z pięćdziesięcioletnim doświadczeniem…
A tak na serio - bardzo Wam dziękuję za pomoc. Będę testował i dam Wam znać, jeśli dalej będzie problem.
Ja testuję drożność też na Live Map na kompie. Ustawiam origin przed skrzyżowaniem i destination po skrzyżowaniu i sprawdzam. Choćby nie wiem jak duże korki byłyby notowane na tym odcinku, to kierowanie objazdem dwukilometrowym zamiast 200 m na wprost świadczy o braku drożności przez to skrzyżowanie, a nie błędnymi zapisami prędkości.
Taaak? To co powiesz na to? Ja to nazywam właśnie tunelem podprzestrzennym. A świadczy to o tym, że waze przechowuje dane w wewnętrznej reprezentacji zupełnie innej, której wielowymiarowość nie zawsze jest dostrzegalna na płaskim rysunku. I wtedy dzieją się cuda.
Hej wszystkim!
Mam dobrą wiadomość - dziś jechałem tą trasą i wszystko było ok - poprowadził mnie prawidłowo przez to skrzyżowanie. Dziękuję wszystkim, którzy przyczynili się do rozwiązania tego problemu.
To fajnie, że ten konkretny problem jest naprawiony, ale wygląda na to, że tego typu problemów powinniśmy się spodziewać częściej.
Chodziło o klienta mobilnego, nie Cartouche.
No właśnie mają, bo chodzi o wyznaczenie najszybszej drogi, a nie najkrótszej. Ale nie to było przyczyną w tym przypadku.
Właśnie chodzi o buga polegającego na tym, że highlight connectivity pokazuje drogę jako przejezdną, ale faktycznie przejezdna nie jest, bo podsystem wyznaczający trasę widzi to inaczej.
Znam tę sprawę, ale tym razem nie chodziło mi o to, że warstwa Restricted Turns pokazuje zakaz skrętu, którego faktycznie nie ma, tylko że pokazuje go w miejscu, gdzie w ogóle nie ma skrzyżowania. Ale może to też się mieści w pojęciu starego buga. Nowy polega na czymś innym: na tym, że podsystem wyznaczania drogi ma inne kształty dróg, niż my je widzimy w Cartouche, czy w ogóle gdziekolwiek. W szczególności gdzie indziej widzi końce odcinków drogi i nie zawsze kojarzy je ze skrzyżowaniami.
Właśnie obawiam się, że tak to zrozumieli. Naprawić mapy możemy sami, ale jeśli są błędy software’owe, polegające na tym, że my mapę naprawiamy, a podsystem wyznaczania tras dostaje mapę zepsutą - nie że starą wersję sprzed naprawy, tylko coś zupełnie innego - to nikt z nas tego nie naprawi.
To akurat jest feature, a nie bug, przynajmniej zdaniem autorów. Zrobili tak celowo, żeby mapa szybciej się odświeżała. Skutek jest taki, że po każdym zapisaniu trzeba zrobić zoom in/out, żeby odświeżyć mapę, przynajmniej ja tak robię.
Chodzi Ci o węzły, które gdzieś tam zostają? To akurat mały problem, bo wprawdzie zaśmiecają, ale nie wpływają na nic.
To też jest niewielki problem, bo węzeł puszcza pod prąd, ale droga już nie. Żeby waze puścił Cię pod prąd, musi na to pozwalać i droga, i węzeł. Jeśli pozwala tylko węzeł, to waze Cię nie puści.
Co do bugów - jako programista… mniejsza o szczegóły, ale kilka lat zawodowego życia zmarnowałem na robienie tego typu bugów, więc znam to od drugiej strony. Pierwszą przyczyną problemów jest założenie “zrobimy software najtaniej i najszybciej na świecie”. Kończy się tak, że oryginalni autorzy odchodzą do lepszych pracodawców, ich następcy kompletnie nie wiedzą o co chodzi, a sytuację ratuje dział PR, ukrywając wszelkie objawy błędów - na przykład poprawiając nieprzejezdne drogi. Poprawienie software’u jest niemożliwe, bo na tym etapie już nikt nie wie jak on działa.
Piękny okaz buga :!: Ja tu widzę raczej niespójność bazy danych: geometria drogi jest opisana w kilku miejscach i teoretycznie we wszystkich powinna być opisana identycznie, ale wskutek jakichś problemów (błąd algorytmu przetwarzającego, brak miejsca na dysku, zignorowany timeout podczas kopiowania) nie jest. Najchętniej wysłałbym autorów do szkoły, niestety mogę tylko ponarzekać.
Ja to nazywam właśnie tunelem podprzestrzennym. A świadczy to o tym, że waze przechowuje dane w wewnętrznej reprezentacji zupełnie innej, której wielowymiarowość nie zawsze jest dostrzegalna na płaskim rysunku. I wtedy dzieją się cuda.
