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.
Dokladnie tak
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.
Tzn wektor=segment który wyleciał s OSM, a polilinia=way , tak ?
No to taki segment to przecież taka polilinia która ma tylko dwa wezły?
Widać juz gdzieś w OSM efekt działania owego plugina ?
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)
Z tego, co widzę, to mój pomysł i ta propozycja mają sporo wspólnego, z tym, że nie przewidziałem “lane relations”.
Relacja zastępująca drogę byłaby sensowna np. wtedy, gdy nie chcemy się powtarzać (DRY). Mając “lane way”, i “drogę bazową” mamy bardziej skomplikowany routing: nie można używać drogi “bazowej”, bo oddzielne “lane way” mogą mieć różny przebieg, różne światła i łączyć się z różnymi istniejącymi drogami.
Bez drogi bazowej jako way, “lane way” zachowują się jak do tej pory.
Wydaje mi się, że istniejące programy i tak wymagałyby modyfikacji.
No tak, ale mi sie wydaje, ze modyfikacja polegalaby tylko na tym, ze programy obslugujace nawigacje po pasach, musialyby zignorowac istnienie tych drog, ktore sa w relacji, i to wszystko. Z kolei te ktore nie znaja tagu lane zachowywalyby sie tak jak dotychczas.
Co prawda to prawda.
Zwróć jednak uwagę na to, że wygodniej się edytuje, gdy nie trzeba nanosić danych dwa razy na te same miejsce. Myślę, że sporo ludzi dałoby sobie spokój z prawidłowym oznaczaniem dróg, skoro już są pasy.
W każdym razie propozycja jeszcze na pewno się zmieni tak, żeby zmniejszyć wagę tego problemu, a jest wystarczająco dobra do implementacji według mnie.
Pozwolę sobie odświeżyć temat. Jeśli chodzi o topologie “tytułowego” skrzyżowania to aktualnie preferowałbym stary opis, nie przecinanie się przecinających się dróg jest trudne do zaakceptowania. Co do kwestii świateł, zastanawiałem się ostatnio co byłoby gdyby ustawiać je w ich fizycznym miejscu (przed wjazdem na skrzyżowanie, nie w punkcie wspólnym). I okazuję się, że gdy skrzyżowanie składa się jedynie z wektorów jednokierunkowych to działa (czyli większość trudniejszych). Można by to już obecnie stosować gdzie się da. Problem jest tylko jeśli występuje droga dwukierunkowa. Obejściem byłoby rozdzielenie jej na dwie jednokierunkowe w obrębie skrzyżowania, albo wypracować jakaś inną metodę (określanie kierunkowości? relacja?), która i tak w przyszłości będzie potrzebna.
Teraz widzę, że Yarl zrobił tak: http://osm.org/go/0OPjcv8LL– - światła z tagiem, że też przejście (nie wiem czy nie lepiej byłoby to w różnych punktach zrobić). Widzicie jakieś problemy z tą metodą?
Zauważyłem, że w trakcie dyskusji na temat skrzyżowań nie poruszono tematu klucza lanes=x. Używając go można zachować stary układ, że wektor idzie w osi jezdni, a rozdzielać dopiero w momencie, gdy pasy faktycznie oddzielają się od wspólnej osi i prowadzą w innym kierunku.