Tagowanie pasów jezdni

Sam sobie przeczysz, a pytanie zostało odpowiedziane wielokrotnie: tam gdzie wynika z oznakowania - wprowadzać.

Nie przeczę bynajmniej sobie a jedynie usiłuje dociec moim ograniczonym umysłem dlaczego kolega popej twierdzi, że przypadek skrzyżowania
http://map.project-osrm.org/?hl=pl&loc=50.021969,21.983281&loc=50.021838,21.983257&z=18&center=50.021969,21.982886&alt=0&df=0&re=0&ly=-1171809665
jest poprawnie rozrysowany, skoro nie ma na nim żadnych restrykcji i wytyczenie trasy za pomocą OSRM pokazuje absurd istniejącego stanu. Na podanym skrzyżowaniu są znaki poziome i pionowe - restrykcji brak.

Wg mnie to popej tylko twierdzi że niektóre sprytniejsze nawigacje jakoś sobie interpolują że nie można zawracać, ale nigdzie nie twierdzi że dodanie restrykcji to błąd.

Znaki poziome to też znaki. A co do cytowanego przypadku, to moja opinia była inna niż sugerujesz, napisałem: “pewnie zarówno wariant bez jak i z restrykcjami byłby do zaakceptowania.”

Zastanów się, jakbyś wyznaczył tę trasę sam, tak ręcznie długopisem, gdybyś miał do dyspozycji jedynie wydruk mapy.

Wg mnie przeciętny kierowca nie rozważałby zawrócenia na rozjeździe pasów ruchu natomiast zastanawiałby się, czy można wykorzystać boczną drogę. I z tego wynikają konsekwencja dla mapowania OSM. Brak restrykcji przy skręcie w boczną drogę jest błędem. Natomiast brak restrykcji dookoła wysepki jest podejściem zdroworozsądkowym. Takich miejsc jest zapewne tysiące lub dziesiątki tysięcy. Można by wrzucić restrykcje z automatu, ale dla mnie to właśnie jest argument za tym, żeby tego nie robić, bo to oznacza, że restrykcja nie wnosi nowych informacji do danych mapy.

To jest błędna rada, niezgodna z opisem wiki: http://wiki.openstreetmap.org/wiki/Tag:highway=trunk_link
Link to jest specyficznym połączeniem między drogami różnych klas. Może warto przetłumaczyć tę stronę, skoro użycie tagu budzi wątpliwości?

Zamieńmy to na przykład: mamy dwie drogi typu motorway czy trunk, które powinny być połączone przez link. Wstawienie zbyt niskiej kategorii połączenia mogłoby oznaczać użycie tertiarty-link lub drogi tertiary. Wg mnie, jeżeli to będzie tertiary-link, to nawigacja może zignorować niską klasę ale jeżeli to będzie droga tertiary, to w wielu przypadkach może ją pominąć w wyznaczaniu drogi.

W praktyce, przy tworzeniu moich map z danych OSM podwyższam sztucznie klasy linków, bo wtedy uzyskuję lepszy routing, przy niewielkim dodanym narzucie na czas obliczeń. Mogę to zrobić, bo linki są specyficznym rodzajem drogi. Jak zamiast linków wyrysujesz zwykłe drogi, to taka optymalizacja się nie uda.

Robię też inne mapy, z danych komercyjnych. Tam mam większy wpływ na optymalizację, bo robię to przy pomocy własnego oprogramowania. Jednym z etapów optymalizacji jest dostosowanie klasy linków do klasy dróg, które te linki łączą. I ponownie stwierdzam - bez linków, optymalizacja klas dróg byłaby znacznie trudniejsza.

Ostatni wpis 126 popeja jest dla mnie zrozumiały i się z nim zgadzam.
Przypomnę jednak to o czym pisałem w postach 94 i 100. Podane przykłady zostały celowo wybrane aby przejaskrawić problem. Do ich wizualizacji zostało użyte narzędzie OSRM - rozumie, że tworzone m.in. z myślą o możliwości obrazowania narysowanych map OSM pod kątem ich błędów. Skoro OSRM pokazuje trasę w dany sposób, to przyjmuję że nawigacja zrobi to tak samo.** W/w przykłady pokazano za pomocą OSRM -nie programu mapowego.**
Z bazy danych OSM zeszliśmy niepotrzebnie na wątek programów nawigacyjnych Garmina czy Navigatora Free dopuszczających wykorzystanie owych map. I pojawiła się polemika nie o meritum tj. właściwym tagowaniu OSM a o tym, że dany program mapowy jest sprytniejszy od drugiego ponieważ wyznacza drogą tak a nie inaczej (tak nawiasem mówiąc do Navigatora Free można wykupić mapy komercyjne - rozumie, że sam algorytm wyznaczania trasy przez Navigatora pozostaje taki sam). Odwracając intencje popeja: “nie wolno pisać OSM pod konkretny program mapowy” można równie dobrze przyjąć, że został OSM została napisana pod Garmina ponieważ radzi sobie lepiej z nawigowaniem niż inny program. Dyskusja tutaj o programach nawigacyjnych wypacza sens istnienia tego forum.
OSM w założeniu (jak mniemam) ma być uniwersalny czyli dowolny program mapowy powinien pokazywać w sposób nie budzący wątpliwości.

Myślę, że temat można zakończyć…

Jeszcze jedna refleksja do zawracaniu na skrzyżowaniach.
Wystarczy krzyżujących się dróg (o ile to możliwe) nie łączyć w pkt i bez restrykcji OSRM nie wytyczy zawrócenia na środku. Oto przykład:
http://map.project-osrm.org/?hl=pl&loc=50.021592,22.016507&loc=50.021614,22.016189&z=18&center=50.022444,22.015834&alt=0&df=0&re=0&ly=-1171809665
Pytanie czy taki sposób rysowania jest poprawny (JOSM wyświetla ostrzeżenie w takich przypadkach)?
Pozdrawiam

Witam,
Mam pytania dot. poprawnego tagowania bus-pasów i pasa dla rowerów. Jak właściwie to robić jeśli mamy następujące sytuacje:

  1. Bus pas wydzielono z prawej strony; w sumie jest 3 pasy z czego 1 skrajny dla autobusów. Jakich tagów użyć:
    a) access=yes|yes|designated + bus:lanes=yes|yes|designated
    b) czy też wystarczy lanes=3 + busway:right=lane
  2. Pas dla rowerów z prawej strony (wąski); w sumie jest 3 pasy z czego 1 wąski dla rowerów. Jakich tagów użyć:
    a) lanes=3 + cycleway:right=lane czy też
    b) lanes=3 + cycleway:right=lane + access=yes|yes|designated
    c) czy dodatkowo użyć tag width:lanes=…|…|1.5 (o ile dopuszczalna jest taka kombinacja)

Ja do tego drugiego przykładu wolę bicycle:lanes=no|no|designated

Czyli do pkt 2 stosować:
access=yes|yes|designated + bicycle:lanes=no|no|designated

W nawiązaniu do wizualizacji pasów i po sprawdzeniu w JOSM, okazuje się, że zastosowanie turn:lanes dla dróg dwukierunkowych jest błędem. Piszę o takim przypadku (DK 11):

Są tu dwa fragmenty, które w tym momencie działają dobrze. Przy próbie odwrócenia kierunku way tagi maxspeed: *z forward i backward zostały przez program wskazywane jako możliwe/konieczne do zmiany. turn:lanes nie.

Czy dobrze rozumuję? Jeśli tak, proszę zwrócić na to uwagę przy wprowadzaniu/poprawianiu pasów.

Jest. Należy używać turn:lanes:forward lub turn:lanes:backward.

Chodzi oczywiście o drogę numer 11, nie o 432 (która na skrzyżowaniu jest akurat podzielona na jednokierunkowe odcinki). Okazuje się przy tym, że rozróżnienie kolorów dla turn:lanes i turn:lanes:forward/backward na wizualizacji ma sens, brawo (do tej pory byłem przekonany, że kolory są po to, aby denerwować wszystkich tych, którzy nie rozróżniają tak po prostu liliowego od łososiowego, lub dokładniej: rozróżniają, ale nia mają pojęcia, który jest który).

Tak, pisałem o tych liniach bez strzałek.

A jest możliwość dodania również buspasów oraz pasów rowerowych? Np. inny kolor jezdni

Gdyby chociaż ktoś zebrał tagowanie (na jakimś padzie), na które trzeba/warto zwrócić uwagę, możemy spróbować.

Ja mapuję wg https://josm.openstreetmap.de/wiki/Styles/Lane_and_Road_Attributes ale jeśli chcesz to mogę to spisać gdzieś.

Witam,
Kilka dni temu otrzymałem mail, którego treść załączam:
Hi!

After some comments and research I replaced in the proposal the key destination:sign by the key destination:symbol. I’m updating my tagging right now and want to ask you if you mind if I update your tags also?

Best regards, Martin
Nadawca: m-443493-6d0c42@messages.openstreetmap.org
Czy ktoś coś wie nt. tej inicjatywy?

Dałbym:
lanes=3
lanes:psv=1
motor_vehicle:lanes=yes|yes|no
psv:lanes=yes|yes|designated

Klucz bus oznacza wszystkie autobusy, również turystyczne. Natomiast psv oznacza wszelkie środki komunikacji miejskiej, również taksówki (zazwyczaj moga po buspasie). Oparte jest to nie na schemacie busway, ale na prostym weług mnie *lanes *i access, jest on duży bardziej wszechstronny.
Jeśli rowery również mogą się poruszać po takim pasie, to:
cycleway:right=shared_lane

Ten mail, pewno dlatego bo moze niedawno dodałeś coś z destination?
Prosta zmiana z sign na symbol. Chyba nic do tej pory nie wykorzystuje ‘destination’ kluczy?

W przypadku dodania cycleway:right=shared_lane dałbym też cycleway=shared_lane

Dlaczego?