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.
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:
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
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)
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.
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).
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?
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?