Po to mamy wiki żeby wiedzieć jaki tag jakie ma znaczenie i nie ma sensu zmieniać nazwy tagów dla powszechnie używanych, w zależności od popularności/ewolucji znaczeń, czy statystyk krajów których dotyczą dane (w zasadzie z powodu czegokolwiek).
Zrobiłby się gigantyczny bajzel programistyczny.
Wrcajac do tematu głównego…
Wryuciłem pare szkicy w Przykład współzależności rysowania osi, płaszczyzn i taggingu pasów jezdni
na stronce roboczej
Czemu to skrzyżowanie z tego opisu na wiki jest tak beznadziejnie wyrysowane?
Bo to jakis kretyn z Paryza rysowal. Wzialem to jako beznadziejny przyklad jak nie nalezy robic, bo gdy do tego dorysuje brakujace obrazki w postaci lane navigation które by wyszlo na podstawie tego schematu, to bedzie widac ze wszystko sie sypnie. No ale to jeszcze jest w robocie…
Sugerowalbym tagi crossable i itp. wzbogacic o slowo lane, zeby bylo wiadomo do czego odnosi sie to crossable. Inaczej moze byc interpretowane np. jako informacja czy droge mozna przekroczyc pieszo czy cos takiego.
Podzial lini w miejscu 2/3 spowoduje, ze trzebaby zmienic istniejace juz zasady, bo dotychczas przyjmowalo sie, ze linie na drogach nie wplywaja na geometrie drog w OSM, a tylko fizyczne rozdzielenie lub brak jego.
EDIT: ups odpowiedzialem na posty z poprzedniej strony watku 
Popieram. Wtedy wszystkie tagi mają wspólną część “:lanes”. Ułatwi to życie walidatorom i nam.
Jedna z propozycji rysowania skomplikowanych skrzyzowan wyglada wlasnie tak. Wedlug mnie kiepska, chociaz na SOTM w tym roku byli ludzie z ktoregos niemieckiego producenta samochodow, ludzie zajmujacy sie routingiem i przedstawiali automatyczne wykrywanie skomplikowanych skrzyzowan i kompresowanie ich do jednego wezla jako jedno z ich osiagniec. Stosuja to przy wyswietlaniu siatki drog na malych zoomach i do wyznaczania dlugich tras. (tez raczej jest to obejscie problemu niz rozwiazanie go, ale na plus publikuja swoj kod zrodlowy na wolnych licencjach)
Moze to troche offtopic, ale OSMF ma wspierac OSM od strony prawnej, ew. finansowej (chociaz dotychczas to glownie sponsorzy sprzetu wspieraja OSM), a tagowaniem sie nie zajmuje i nie ma wladzy podejmowac takich decyzji. Nie ma tez wcale szczegolnych zdolnosci technicznych, wiekszych od reszty OSM. Jesli chcesz zrobic jakas operacje poza normalnym API edycyjnym to najwiekszym zadaniem jest z reguly przekonanie admina (Toma Hughesa) i zaimplementowanie tego co chcesz zrobic 
Zabieram się powoli za stworzenie renderingu, który rysowałby pasy jezdni.
Będzie on prawdopodobnie uwzględniał 2 schematy tagowania:
- http://wiki.openstreetmap.org/wiki/Proposed_features/Lane_group
- http://wiki.openstreetmap.org/wiki/Lanes
Na sam start pojawiły się pytania. Czy jeśli mamy kontrapas to w lanes=* jest uwzględniany?
Wyslij pytanko do tego kolegi: http://wiki.openstreetmap.org/wiki/User:Imagic
On siedzial dosc mocno w detalach…
Wlasnie z podanego powodu jest ok.:
Nawigacja daje wczesnie informacje ze trzeba zmienic pas. Kalkulacja nowej trasy przy tej dokladnosci GPS jaka jest obecnie powoduje, ze nowa kalkulacja trasy odbywa sie dopiero wtedy, gdy kierowca skreci w zla strone. W przypadku poruszania sie po równoleglej nitce nie gra to roli bo wewnetrzne zaokraglanie pozycji jest spore.
O wiele wieksza wartoscia dla kierowcy jest podanie w odpowiednim czasie informacji, ze musi znalezc sie na lewym pasie jezdni by móc skrecic w lewo. Kiedy przegapi i ma ciagla bo informacja z nawigacji go nie ostrzegla, to wtedy wlasnie robi wycieczke.
Pokazany na powyzszym przykladzie system jest stosowany praktyznie przez wszystkich liczacych sie producentów danych do nawigacji jak Nokia, TomTom, Mapquest.
Co do wyznaczenia pasa ruchu na którym należy się znaleźć, w większości wypadków wystarczy podać
http://wiki.openstreetmap.org/wiki/Key:turn:lanes, czy podać lanes (http://wiki.openstreetmap.org/wiki/Lanes) na drogach. Zadziwiająco dobrą implementacje tego (chyba) ma OsmAnd już teraz.
W (nielicznych) bardziej skomplikowanych przypadkach należałoby używać czegoś podobnego do rozdziału Lane connectivity na http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension/ProposalPreVoting.
Ale nie mieszajmy do wyboru pasa ruchu wirtualnych highway.
EDIT: Wyjaśnienie: lanes = http://wiki.openstreetmap.org/wiki/Lanes
Ja używam http://wiki.openstreetmap.org/wiki/Lanes i stylu do JOSM http://josm.openstreetmap.de/wiki/Styles/Lane_and_Road_Attributes
Marek, a mógłbyś doprecyzować na
http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area/pl#Skomplikowane_skrzy.C5.BCowania_a_nawigacja_pod_OSM
że lewoskręty i prawoskręty (w punktach C-E) o ile nie istniają fizycznie jako oddzielne jezdnie, mapujemy jako “coś innego” niż highway?
Bo powyższy url został podany jako powód takiego, a nie innego mapowania…
Sorry umknęła mi ta uwaga.
Jest tak: Powinna to być jakaś nowa kategoria, która jest uwzględniana w nawigacji a która nie jest renderowana na mapie bo optycznie robi się kaszana.
W wewnętrznej dyskusji z OSMF używam pojęcia “street connector”.
Pozwoliłem to sobie wrzucić na polskie forum by zainteresowac Was tą tematyką. Stoi tam jednak jak byk, że strona w wersji roboczej a więc nie jest to approved.
Myśle ze podejście to ułatwilo by wiele spraw z tagowaniem i dyskusją nad skomplikowanymi skrzyżowaniami, no ale poczekajmy na workshop z producentami aut.
Jak juz pisałem w innym miejscu chciałbym od nich finansowania rozwoju OSM tam, gdzie to jest nam potrzebne.
W zamian mieli by prawo wyrazić swoje uwagi / punkt widzenia / doświadczenia w obszarze takim jak wlasnie ten.
Wrzuciłem na stronke w wymienionym fragmencie wskazówkę, że nad tym modelem dopiero się pracuje.
Dzięki za cenną uwage!
Pozdrowienia,
Marek
Dokładnie.
Jak już pisałem jest propozycja relacji analogicznej do relacji zakazów (skrętu) tutaj:
http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension/ProposalPreVoting#Lane_connectivity. Sekcja “Lane_connectivity”
W związku z tym że taka relacja zawsze łączyłaby dwa punkty w drogach, oraz musiała odnosić się bezpośrednio do lanes prościej wg mnie użyć zwykły way z lanes_connection=yes i lanes_from=1-3 lanes_to=3-6, a relacja to overkill.
Swoją drogą to chciałbym zobaczyć przykład, gdzie to jest na prawdę koniecznie, a nie da się tego obliczyć z lanes i turn:lanes ;).
Ach, user Imagic poszalał 
Wiesz, chodzi o to, by nawigacja odpowiednio wcześnie pokazywała na którym pasie się ustawić i jak przez skomplikowane skrzużowanie przejechać.
Wpadłem na to w tym miejscu : http://www.openstreetmap.org/#map=19/53.55538/10.04137
Kiedy ktoś jechał, nawet z nawigacją, ale taką bez lanes i lane divider, z Sievekingsdamm i miał jechać w Grevenweg, to na 100% jechał w Borgfelder Strasse bo informacja była podawana tak późno, że siedziało się już na pasie oddzielonym linią ciągła i nakazem jazdy prosto.
Oczywiście, na zdrowy chłopski rozum jak ktoś jechał, to wcześnie się ustawiał na skrajnym pasie nie czekając co nawigacja powie.
Niestety jest tak, że coraz więcej ludzi jest zdania, że nawigacja powinna myśleć za nich i jeżdżą jak woły. Dlatego też wszyscy producenci typu Daimler, BMW, Audi itd nie bedą nigdy używać danych które tego problemu nie rozwiązują.
Czy mamy jakieś zalecenie co to tagowania wyznaczonego miejsce na jezdni (zygzak) jako zatrzymanie dla autobusów?
Czy też na razie sobie to odpuszczamy.
Na początek przykład skrzyżowania:
http://www.openstreetmap.org/#map=19/52.20186/21.03489
Wygląda to dość dziwnie, a ja bym conajmniej odwrócił kierunki dróg biegnących po “przekątnej” by to miało jakiś sens.
Nie wiem, czy to jest próba pokazania na mapie organizacji ruchu na skrzyżowaniu sugerującej mijanie się prawymi stronami przy skręcie w lewo (“bezkolizyjne trasy”)?
Na Wikipedii nie znalazłem aktualnego wzoru tabliczki pod znakiem, którą mam na myśli, więc nie wiem, czy to jeszcze aktualne. Ale może znajdę coś w terenie by zobrazować.
A tymczasem - co z takim kwiatkiem zrobić?