chciałbym zapytać o Waszą opinię nt. topologii skrzyżowań dwujezdniowych. Ostatnio postanowiłem zmodyfikować pewne skrzyżowanie przy pomocy ortofotomapy. Stara topologia, bardzo uproszczona, wyglądała tak:
Tak wygląda nowa topologia na tle zdjęcia:
Ma tą zaletę, że stara topologia teoretycznie pozwalała na zawracanie, podczas gdy faktycznie nie jest to dozwolone. Plus, oczywiście znacznie wierniej odzwierciedla rzeczywistą topologię. Wadą jest to, że drogi przecinają się bez węzłów, czemu sprzeciwia się validator w JOSMie. Nie można oczywiście po prostu wstawić węzłów, bo routing by oszalał wyznaczając niedozwolone trasy.
Nowa topologia jaka stosujesz, jest coraz czesciej stosowana i sklania sie ku niej community z RFN a jak wiadomo maja sile przelozenia.
Chodzi o kwestie praktyczne:
Przy starej topologii trzeba b. uwazac przy relacjach typu restriction, niedoswiadczeni userzy czesto popelniaja bledy w opisie.
OSM jest juz na zachodzie w takim miejcu rozwoju, ze slabym punktem zaczynaja byc drogi: Coraz wiecej jest miejsc gdzie rysowane sa wszystkie wysepki dla pieszych, obszary zieleni dzielace poszczególne pasy i obszary jezdni, pojedncze miejsca parkigowe. Kiepsko wyglądają przy tym ulice.
W tej sytuacji powstaje dylemat: Z jednej strony obecny rendering map powoduje ze w miejscu skomplikowanych skrzyzowań powstaje na przynajmniej dwóch przedostatnich poziomach renderingu mapy nieprzejrzysty obraz. Z drugiej strony na najwyższym poziomie zoomu (a nie jest powiedziane, ze na nim sie skonczy- osobiscie zamierzam lobbowac, by wprowadzic jeszcze jeden wiekszy zoom), obraz powstajacy w wyniku uzycia “starej” topologii po prostu odbiega od stanu rzeczywistego. Poprawnie wygląda całe otoczenie, ale sama ulica już nie. Efekt drażni i jest niezrozumiały.
Dyskutuje sie w OSM nad wprowadzeniem generycznych tekstur dla rysowania ulic: linia ciagla i linia przyrywana musza byc wtedy w jakis sposób mierzone by rysowac je dobrze. Byłem promotorem jedenej pracy dyplomowej, która to przetestowała. Inna praca dyplomowa która dałęm zrobić: Plug In pod JOSM dający możliwość dokładnego rysowania skomplikowanych ulic składających się z wielu pasów jezdni. Obecnie plug in jest przerabiany pod C++ tak, aby dzialal pod Potlatch 2.0.
Slaba strona firm takich jak Navteq i Teleatlas jest fakt, ze co prawda uzywaja juz tagów do generycznych tekstur, ale robia duuzy łuk jesli chodzi o skomplikowane skrzyzowania. Sa one upraszczane wg starego schematu, bo pozwala to rzsowac mniej wektorów. Z drugiej strony konsorcjum przemyslowe NDS (Nokia, Daimler, Bosch, Harman, Elektrobit, Mitsubishi i kilkanascie innych poteznych firm) rozwija wlasnie specyfikacje nowego formatu dla autonawigacji który zawiera wlasnie dokladne rysowanie poszczególnych pasów jezdni i skryzowan.
Dokladne rysowanie skrzyzowan jest wiec szansa dla OSM. Jedyna firma która do tego obecnie podchodzi sczczególowo i posiada taka baze danych jest japonski Zenrin mierzący ulice autkiem z systemem o nazwie Tigereye. Jednak nawet oni nie sa na tyle dobrzy, by rysowac wszystko tak, jak powinno wyglądać. W pewnych miejscach po prostu wrzucaja wartwe ze zrenderowanymi bitmapami a pod tym ukrywa sie uproszczone skrzyżowanie. Chcecie to Wam wrzuce specyfikacje w siec jak by to nalezalo robić.
Sa miejsca gdzie uproszczenia sa naprawde katastrofalne dla systemów nawigacji. Przykładowo ruch kołowy wokół łuku Triumfalnego w Paryżu. Dopiero takie rysowanie pas po pasie pozwala na poprawny topologicyne opis. Wyobrazcie sobie: ruch kolowy po osmiu pasach :O)
Trzecia argument: Nawet rysujacy po 8 godzin dziennie i robiacy atrybuty ludzie z Teleatlas i Navteq popelniaja czesto razace bledy kiedy musza dokonywac generalizacji skrzyzowan. Poprawiali to moi wspólpracownicy robiacy im kontrole jakosci (Harman Becker) i co prawda dalo sie wielu ludzi “wychowac” tak, ze jakosc danych byla lepsza, ale w przypadku community gdzie mamy wielu niedoswiadczonych uzytkowników jest o wiele latwiej rysowac stan faktyczny bo bedzie mniej popelnianych przez nich bledów topologicznych.
Ja tez bym sie sklanial ku wiernemu oddaniu rzeczywistosci (wydaje mi sie, ze pierwszyprzyklad lepiej ja oddawal), a jesli na skrzyzowaniu sa zakazy zawracania to powinny odpowiadac im relacje. Oczywiscie kazda sytuacje da sie obejsc bez relacji, ale po to one sa zeby nie trzeba bylo tego obchodzic. W rzeczywistosci program routujacy taki jak Gosmore tak czy tak przerabia to na odpowiedni graf bez relacji, dodajac sobie jakies witualne wezly i tagi oneway.
Wierne oddanie geometrii to naturalnie podstawa. Relacje sa takze wazne z innego ciekawego powodu: Tam gdzie pasy ruchu i ich oznakowanie buduje sie wg. zasad obowiazujacych w budowie dróg jest tak, ze naroznik gdzie nie wolno skrecac jest katem ostrym zas ten gdzie wolno, przebieg jezdni jest lekko zaokraglany. W nowej generacji wizualizacji skrzyzowan mozna ta heurystyke dobrze wykorzystac by otrzymac efekt bardziej zblizony do rzeczywistosci bez potrzeby obmalowywania wszystkiego multipoligonem. Jak mnie nauczycie jak tu sie wrzuca obrazki, to pokaze screenshoty :O)
Interesujaca jest problematyka true lane navigation takze z powodu pasów wydzielonych i to nie tylko czegos takiego jak np. pasów dozwolonych tylko dla komunikacji publicznej i taksówek itd itp. Sa np. kraje gdzie pewne pasy ruchu maja nakazana predkosc minimalna lub np nakaz jazdy mimimum 2 osób w pojezdzie.
Co do rysunku Mariusza, to ten nowy szkic odpowiada np. specyfikacji z jaka pracuje Navteq
Zawsze przy takich sytuacjach zastanawia mnie jedno: co ze światłami? Nie podoba mi się umieszczanie ich ani obok węzłów (bo wtedy są oddzielone od skrzyżowań), ani na węzłach (bo nie wiadomo, do którego kierunku się odnoszą). W obu przypadkach przejazd po najprostszym skrzyżowaniu to pokonanie kilku węzłów z tagiem traffic_lights.
Czy jest jakiś standardowy sposób, który nie ma tych wad?
Niemcy uzywaja umieszczanie ich na wezlach, jakkolwiek nie wiadomo do jakiego kierunku sie odnosza. Wlasciwie powinno sie je dodatkowo tagowac np. main_direction / nazwa ulicy, secon_direction/ nazwa ulicy… tym bardziej ze np. Hamburg, duza czesc Bawarii i Badenii-Wirtnbergii ma juz wprowadzone przez community jako tagi numery id systemu TMC. Oznacza to, ze majac dostep do informacji z komputera miejskiego który swiatlami centralnie kieruje, mozna kierowcy w czasie rzeczywistym pokazywac jak zmieniaja sie swiatla. Dla systemu nawigacji super sprawa bo mozna okazywac zielona fale. Tylko czekam, kto pierwszy wpadnie na pomysl, by ta funkcje zaimplementowac w system nawigacji… Bylo nie bylo: by taka funcja mogla zadzialac, swiatla musza stac na wezlach…
Dodawać dodatkowy wezęł na drodze w miejscu gdzie faktycznie są światła ?
Pozostaje określenie na drogach dwukierunkowych którego kierunku dotyczą światła.
Zgadzam sie kompletnie, ze mapowanie pasow ruchu to przyszlosc, ale drogi z tagiem highway nie oznaczaja pasow ruchu, tylko osie jezdni, i tak interpretuja baze danych OSM rowniez progrsmy do nawigacji. Wiec ten nowy uklad troche przeczy rzeczywistosci.
Co do sygnalizacji swietlnej (highway=traffic_singals), znakow stop (highway=stop) itp, to byla kiedys dyskusja na temat pomyslu podawania w tagach kierunkow geograficznych ruchu samochodow przy ktorych obowiazuje znak, i chyba juz jest to w uzyciu i gdzies na wiki. Oczywiscie tu jest ten sam problem pasy ruchu vs. jezdnie, bo czesto na duzych skrzyzowaniach sa oddzielne swiatla dla kazdego z trzech pasow, na przyklad.
Tutaj wklejam do dyskusji schematy skrzyzowan Marka, ktore mi przeslal jakis czas temu:
Ku informacji>
Rys 1. Początki OSM: Kazda droga to jeden wektor.
Rys 2. Decyzja wspólnoty: jeśłi między pasami jest przegroda - physical devieses - jak np. pas zieleni, przystanek tramwajowy z terenem dla pieszych- to rysujemy dwa wektory.
Rys 3. Propozycja rozwoju OSM: Rysujemy dwa odrębne wektory od miejsca gdzie jest road junction - tj. gdzie pasy ruchu rozdzielają się trwale.
Rys 4. Efekt zrenderowany w OSM. Uwaga: Programik trzeba napisac. JEst specyfikacja, wiadomo co zrobic i jak. Fantastyczna praca dyplomowa badz projekt na studiach. Jak już pisałem, mogę byc promotorem pracy. Służę wszelką pomocą w tym temacie. Jeśli ktoś się pisze dajcie znać. Ktoś kto to napisze wprowadzi OSM na nowy etap rozwoju.
Marek
Problem jest według mnie w tym, że pojęcie “osi jezdni” traci sens na skrzyżowaniu. Rozumiem, że taka topologia byłaby lepsza:
Taką topologię, z czworobokiem w środku, ma większość skrzyżowań dwujezdniowych, które widziałem. Jednak między drogami w czworoboku nie ma żadnych “fizycznych barier”, więc trudno nazwać je jezdniami. Swoją drogą z tego powodu ktoś we Wrocławiu forsował model z czworobokiem posiadającym tag area=yes.
Dziękuję wszystkim za cenne uwagi. Skłaniam się teraz jednak za topologią “z czworobokiem”. Przynajmniej do czasu aż nie zmienią się rekomendacje w tym względzie.
Marek myślę, że przydało by się coś co by pomogło w upowszechnieniu zapisu skrzyżowań, może da się takie coś w mapniku zrobić? jakby było widać efekty i które skrzyżowania są dobrze zrobione, a które jeszcze nie na pewno łatwiej było by o edycję. To było by świetne jakby się udało się wyrenderować coś w stylu ostatniego obrazka wystawionego przez balrog-kun. Wg mnie, jeżeli OSM ma być coraz popularniejsze to musi iść w innym kierunku niż np. google maps - i to z pewnością jest jeden z takich kierunków.
A skąd będzie wiadomo czy dane pasy ruchu ( idące obok siebie) są fragmentem jednej jezdni i dzeli je tylko linia ciągła, czy jednak dzilą je fizycznie krawężniki plus zieleń ?
Chyba taka informacja byłaby konieczna … relacja że dane drogi są fizycznie jedną jezdnią, albo na fizczne drogi nannieść wektory przebiegu pasów ruchu …
Dalej nie rozumiem czemu nie umieszczać znaków / swiateł na weźle należącym tylko do jednej drogi (a nie na weźle przecięcia dróg)? Wtedy wystarczy ustalić czy światła są ustawione zgodnie czy nie z kierunkiem drogi ( analogicznie jak tag oneway).
Na pewnoe widziałem skrzyżownie mające 6 wlotów i na każdym “all way” stop, ciekawe jak wtedy z kierunkami geograficznymi
Rozmyślałem kiedyś nad zapisem równoległych pasów w bazie OSM i wpadłem na taki pomysł: rysować wektory równoległe, łączyć je w relacje i każdemu nadawać kolejny numer (odległość?) względem ustalonego kierunku, np dla dróg wschód-zachód:
Baza=N # od tego kierunku liczona odległość
Droga Wartość
1 0m # od północnej krawędzi połączonych dróg
2 5m
3 10m
4 12m
W ten sposób mamy 3 pasy/jezdnie po 5m od siebie i jeden (np. chodnik) 2m od ostatniego z trzech.
Problem w tym, że mamy właściwie jedną drogę i masę wektorów.
W ramach pracy dyplomowej finansowanej przez firme w której obecnie pracuje ( Neusoft Technology Solutions GmbH) powstal plug in pod JOSMá który zaproponowalem. Rysujac jeden wektor, otwiera sie edytor graficzny pozwalajacy na opisanie calej tej problematyki:
Pojedynczych pasów, linii miedzy nimi i tego, co nazywam z przyzwyczajenia physical devices: róg rowerowych miedzy pasami, pasów zieleni itd itp… Bardzo fajna praca dyplomowa z tego powstala - notabene w Polsce.
A teraz 2 problemy:
Mój szef chce by na plug-inie bylo napisane: “Powered by Neusoft”, co nie jest chyba az tak straszne- w koncu szefowi sie nalezy jak zaplacil za 9 miesiecy roboty
Widac, ze dobrze by bylo wrócic do zarzuconej bodajze w 2005 czy2006 r stuktury OSM:
Edycji kazdego pojedynczego wektora w ramach jednej polyline.
Na poczatku w OSM byl punkt, wektor, polilinia i zamknieta polilinia czyli plaszczyzna.
Do robienia 3D czy porzadnego GIS tez by to sie b.b.b. przydalo. Wtedy struktura jest bardziej gietka i wiecej mozna robic.
Bylo nie bylo: Z lug inem da sie pracowac, ale trzeba manualnie dzielic droge na mniejsze odcinki: Od skrzyzowania do skrzyzowania.
Kiedy kolega który to napisal wrzuci juz do plug Ina logo, przekaze Wam to do sciagniecia i wypróbowania.
Oczywiscie kod jest ogólnodostepny i plug in wolno rozwijac dalej; nie wszystkie omysly udalo sie nam (tj. Rafalowi który to pisal) zimplementowac.
Do zrobienia jest jeszcze przepisanie tego w C++ tak, aby to chodzilo w Potlatch 2.0 Jakby ktos sie pisal to dajie znac.
Chyba przesadizlem z tym, ze kierunki geograficzne sa juz w uzyciu. Dyskusja, ktora czytalem byla tu i jedna z propozycji jest dokladnie taka jak mowisz.
Ja mysle ze relacja nie powinna zastepowac drogi oznaczajacej jezdnie, bo z tego korzystaja juz rozne narzedzia, ale przydalaby sie relacja laczaca pasy i jezdnie. Jest jeszcze wiecej poziomow szczegolowsci (np. obrysy ulic, obrysy pasow ruchu) i niestety zaden nie jest w stanie zastapic pozostalych.
http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group jest sensowna propozycja mapowania pasow ruchu zwlaszcza dla skomplikowanych skrzyzowan. O ile rozumiem to propozycja polega na tym, zeby osie jezdni nadal mialy tag highway=cokolwiek, a pasy tag lane=vehicle_lane, lane=bus_lane itp. (nie bardzo rozumiem po co “lane” powtarza sie w kluczu i wartosci)
