Jak poprawnie zdefiniować pasy na takim odcinku? Mamy tu trzy pkt K
Punkty K nie mają wpływu na sposób tagowania pasów.
Nie pytam o stosowanie lanes=* dla highway tylko o określenie liczby pasów i sposobu ich malowania w a:h w pkt K z użyciem
Oczywiście nie masz racji Marku. Ja już kiedyś wspominałem o tym. To, że coś się nie przyda w Twoich lub moich zastosowaniach, to nie znaczy, że ktoś inny z tego nie skorzysta. Projekt powinien być przede wszystkim spójny, uniwersalny i umożliwiać dalszy rozwój. Miałem sposobność tworzyć lub współtworzyć trochę projektów i specyfikacji. Zadaniem projektanta nie jest wymyślenie wszystkich możliwych zastosowań danego projektu. Zadaniem projektanta jest stworzenie takiego projektu, który znajdzie zastosowanie w różnych dziedzinach i będzie umożliwiał rozbudowę w oparciu o hipotetyczne specyfikacje, które być może powstaną w przyszłości.
Mnie osobiście bardzo się spodobała pierwotna wersja Twojej specyfikacji projektu area:highway, ale szczerze mówiąc późniejsze dodawanie rozmaitych wyjątków zaczęło mnie przerażać. Stąd też niektóre moje krytyczne uwagi w wątku o a:h. Po prostu zależało mi na tym, żeby ten projekt mógł stać się kiedyś standardem.
Odnosząc się do Twojego przykładu, to jeśli droga zmienia liczbę pasów ruchu, to podział obszarów a:h na osobne fragmenty może się przydać. W przypadku gdy ktoś chciałby stworzyć rendering pasów ruchu, będzie mógł w łatwy sposób to wykonać mając jasną i spójną informację: “na danym fragmencie area:highway występują 3 pasy ruchu”. Drogi są dzielone na kawałki dlatego, że zawierają różne tagi. Projektanta nie powinno obchodzić jakie to są tagi. Powinien umożliwić łatwy dostęp do tych tagów ekipie, która zajmuje się implementacją.
Punkt K jest zazwyczaj punktem wspólnym dla dwóch obszarów a:h. Co za tym idzie dojeżdżając do punktu K dla jednego obszaru będzie to “left”, a drugiego “right”. Ja jakiś czas temu dokładnie analizowałem całą specyfikację projektu area:highway i doszedłem do wniosku, że lepiej byłoby wykorzystać już istniejący tag direction=forward/backward. Jeżeli kogoś interesuje ten temat, to mogę napisać więcej szczegółów odnośnie mojej analizy.
Myślę, że Twoje wątpliwości są spowodowane analogią tagowania highway=[kategoria drogi] => area:highway=[kategoria drogi]. Ja od początku byłem przeciwnikiem tego by w tagu area:highway umieszczać kategorię drogi, ale tak się przyjęło, powstały nawet różne tego implementacje, ma to nawet swoje plusy, więc niech już tak zostanie. Zagadnienie sprowadza się do tego jakim typem danych jest area:highway. Generalnie wyróżniamy w projekcie openstreetmap “fizyczne” typy danych: węzły, linie, relacje. Można również wyróżnić logiczne typy danych: węzły, linie, linie zamknięte, obszary. area:highway jest w tym przypadku nowym logicznym typem danych. Jest to obszar z wyznaczonym kierunkiem ruchu. Składa się z obrysu stanowiącego obszar danego fragmentu drogi oraz z linii, będącej wektorem wskazującym kierunek.
Projekt area:highway jest odwzorowaniem dotychczasowego sposobu mapowania dróg, składającego się z linii i węzłów. Te linie i węzły są odwzorowane przy pomocy obszarów. Analogicznie: linie są odwzorowane przy pomocy zwykłych obszarów, a węzły przy pomocy a:h=* + junction=*. Istnieją również obszary specjalne, niezwiązane z liniami highway, np. a:h=emergency lub area:highway=bus.
Ja zdaję sobie z tego sprawę, że może się to wydawać trudne do zrozumienia, ale nie każdy musi znać się na szczegółach jeżeli zajmuje się tylko mapowaniem, a nie implementacją.
Wracając do Twojego zarzutu odnośnie logicznego uzasadnienia: Linie w openstreetmap są cięte na kawałki dlatego, że posiadają różne tagi. Tak jak wspomniał marimil: linie mogą być podzielone ze względu na nawierzchnię/szerokość/liczbę pasów/rodzaj pasów/jakość/kolor/relacje itp. Z punktu widzenia renderingu wykorzystalibyśmy np. nawierzchnię, by podzielić obszary a:h na kawałki. Z punktu widzenia routingu wykorzystalibyśmy np. maksymalną prędkość, żeby aplikacja mogła wskazać z jaką maksymalną prędkością można się poruszać na poszczególnych pasach ruchu. Nie można przewidzieć wszystkich możliwych zastosowań, a projekt powinien być spójny, więc moim zdaniem logicznym jest przyporządkowanie linia highway → obszar highway.
Trochę trudno mi się odnieść szczegółowo do Twojego zarzutu, więc może napisz dlaczego uważasz, że ten sposób postępowania nie ma logicznego uzasadnienia. Z tym, że przymiotnik “logicznego” traktujemy jako sensu stricte, a nie w rozumieniu potocznym.
Częściowo taka wizualizacja już powstała. Razem z marimilem przygotowaliśmy rendering błędów w area:highway, oraz wyświetlanie nawierzchni drogi: http://osmapa.pl/w/area/?lat=51.11264&lon=17.03604&zoom=19&ol=se (warstwy: surface v2.1 oraz błędy w ah)
Teoretycznie jest możliwość pobrania dowolnego tagu z linii highway, ale na potrzeby renderingu wykorzystaliśmy nawierzchnię, żeby pokazać, że projekt jako całość działa, a dzielenie obszarów o którym wspomniałem - ma logiczne uzasadnienie. Można będzie w przyszłości rozbudować ten rendering np. o wyświetlanie pasów ruchu.
Ja chciałbym poprosić o przeniesienie dyskusji dotyczącej a:h do odpowiedniego działu i ewentualnie w tym temacie kontynuowanie dyskusji dotyczącej tylko tagowania pasów ruchu.
Proposal area:highway dotyczy głównie mapowania dróg jako obszary. Myślę, że tagowanie sposobu malowania pasów ruchu powinno być jako osobny proposal. Ten temat nie dotyczy area:highway, ale myślę, że mógłbyś poprosić Marka, aby w tym temacie przybliżył nieco swoją propozycję dotyczącą pasów ruchu.
To prawda. Inaczej sam będzie musiał stworzyć mechanizm dzielenia obszaru na mniejsze fragmenty. Tworząc specyfikację liczyłem się z tym, że dla większości mapowiczów podział na tak wiele elementów będzie trudny do zaakceptowania. Oczywiście ozacza to więcej pracz dla programisty.
Odnośnie pytania z #443:
a:h z dodatkowym atrybutem junction=y_junction jest wprowadzone dokładnie do takiej sytuacji jak pisałeś.
Mamy tu do czynienia z drogą główną, dajmy na to motorway, plus odchodzącym na bok zjazdem, np. motorway_link
Renderowanie ilości pasów na tym obszarze a:h ma tu się odbyć z zastosowaniem ilości pasów jezdni drogi przechodzącej prosto, tj. mającej DWA wspólne punkty k z obwodem a:h. ilość pasów jezdni drogi mającej jeden punkt wspólny k z obwodem a:h będzie ignorowany.
Jeśli rozwidlenie jest długie i obszar o różnym statusie a:h byłby zbyt długi, to można to zmapować tak, jak tutaj:
https://www.openstreetmap.org/way/375357826
Moja rozważania dot. przykładu z postu 434. Jest tam pokazany wycinek autostrady A4 przy węźle Bielany Wrocławskie. Współrzędne 51.0464579 / 16.9812895.
Z lewej strony w ciągu autostrady jest most na linią kolejową a z prawej “typowa” autostrada. Różnice w tagowaniu tych trzech highway są takie, że kolejno mamy bridge;layer=1;maxspeed=80|maxspeed=80|maxspeed=110.
Uwagi do highway:
- Odcinek środkowy ma ok 7m długości co przy jeździe autostradowej jest dla navi niezauważalne - maxspeed i zadziała z opóźnieniem z ze względu na prędkość jazdy, więc moglibyśmy ten element usunąć - scalając go z odcinkiem z prawej strony;
- Odcinek z lewej strony (bridge) mógłby teoretycznie nie posiadać tego tagu (wówczas linia kolejowa pod autostradą miałaby dodatkowo layer=0 i tunnel. W ten sposób odcinek lewy i środkowy byłyby tożsame;
- Wszystkie trzy odcinki mają ten sam główny tag highway=motorway
Uwagi do area:highway: - Obszary, w które wpisano w/w odcinki highway są opisane tagiem area:highway=motorway (most ma dodatkowo layer=1; jeśli skasujemy tag bridge dla highway nie będzie i tej różnicy; PS. Nawet jeśli go pozostawimy to przecież torowisko pod autostradą nie ma wyznaczonego obszaru a:h - a skoro “mapujemu obszarami” to można brać odniesienie tylko względem tagów a:h - a:h=motorway do a:=railway o ile takie cudo istnieje…)
- Obszary, w które wpisano w/w odcinki highway są identyczne pod względem liczby pasów jezdni, ich wykorzystania, nawierzchni;
- Do obszarów a;h nie dodaje się maxspeed;
Biorąc pod uwagę powyższe narysowanie jednego wspólnego obszaru dla tych trzech (lub więcej odcinków highway) jest poprawne i dopuszczalne, stanowi sensowne ograniczenie dla tworzenia zbędnych danych (zamiast 6,8,10 pkt K jest ich tylko 2), przyspiesza późniejszą pracę na danym obszarze (nie trzeba dodawać tych samych tagów do przytulonych do siebie 5-10 metrowych obszarów), itd.
Proszę o komentarz
Nie mapujemy pod navi ani pod render. Staramy się jak najdokładniej odwzorować rzeczywistość. Jeżeli znak ograniczenia prędkości jest przed mostem, to linia jest pocięta przed mostem, długość tego odcinka nie ma żadnego znaczenia. Navi sobie z tym poradzi.
Teoretycznie mógłby, ale widocznie ktoś uznał, że lepsze będzie użycie bridge. Poza tym w takim przypadku linia kolejowa miałaby tag layer=-1, a nie layer=0.
To prawda, mają i co w związku z tym? W tym przypadku linia została pocięta ze względu na tagi bridge, maxspeed i inne.
Są opisane tagiem area:highway=motorway, dlatego, że odcinki highway były opisane tagiem highway=motorway. Most ma tag layer=1, ponieważ przy renderingu powinien zasłonić linię kolejową posiadającą domyślny tag layer=0.
Jeśli skasujemy tag bridge to powinniśmy też skasować tag layer=1. Dzięki stosowaniu tagu layer dla obszarów a:h, możliwe będzie wyświetlenie ostrzeżenia, że wartości tagów layer dla highway i area:highway różnią się.
Tag layer nie musi być stosowany do tych samych typów danych. Z tego co wiem nie istnieje proposal dla railway. Taginfo pokazuje tylko 13 użyć.
Obszary pobierają tagi z linii, więc po pobraniu tagi obszarów również będą się różnić. W danym przypadku będą się różnić np. tagami bridge lub maxspeed.
Nie dodaje się, ponieważ ten tag już jest na linii highway. Obszar sobie ten tag pobiera z linii.
Jeśli w jednym obszarze (nie będącym skrzyżowaniem) znajdują się 3 linie, to z której linii obszar ma pobrać tagi?
Jak obszar miałby pobrać tagi np. z linii środkowej, z którą nie miałby żadnych punktów wspólnych?
Nawet jeśli pobrać tagi z losowej linii, to dlaczego mielibyśmy tracić informację z pozostałych linii?
Proszę wybaczyć moje rozważania. Usiłuję jedynie odnaleźć się w tym temacie…
Moje dywagacje do opisanego przykładu dotyczą podstaw/sensowności rysowania do każdego nawet najmniejszego odcinka highway nowego obszaru a:h.
Skoro informacje podstawowe są czerpane z wektorów highway (prędkość, szerokość, nawierzchnia, liczba pasów itp) to jeśli mamy do czynienia obok siebie z tą samą klasą drogi, inne cechy tej drogi są podobne, w danym obszarze jest jeden wektor z dwoma pkt K na wejściu i wyjściu z a:h, droga nie “przecina” się z inną (nie ma różnicy poziomów layer) to rysowanie JEDNEGO a:h dla dwóch lub więcej odcinków highway jest racjonalne.
W opisanym przeze mnie przykładzie mamy 3 odcinki: most, środek i część po prawej. Jeśli narysujemy tylko dwa obszary: “most” i “obszar wspólny po prawej” to nie dochodzi w żadnej mierze do błędu w mapowaniu - istotne dane i tak zostaną zassane z highway.
Czy innym jest obszar gdzie mamy owe trzy linie - rozumie, że są to trzy różne drogi, które w pewnym pkt mogą się zetknąć. Zakładam, że pomiędzy nimi istnieje jakaś fizyczna bariera, którą można opisać.
Nikt mi do tej pory sensownie nie uzasadnił, dlaczego tagujemy własnie w ten sposób a nie area:highway=yes
Jeśli są punkty styku K to area:highway mogłaby sobie klasę drogi wziąć właśnie z przecinającej ją drogi.
Nie przejmuj sie Zbigniewie, mi też nikt tego nie wyjaśnił. Masz w tym punkcie rację. Cóż, vox populi, vox dei.
Większość tak chciała bo niby klasa drogi jest od ręki…
Dorzuciłem podrozdział informujący, po co właściwie jest junction=y_junction:
http://wiki.openstreetmap.org/wiki/Proposed_features/area_highway/mapping_guidelines#Rendering_of_lanes
Czy jest to zrozumiałe?
Ogólne reguły powinny być proste i spójne, bez żadnych wyjątków traktowanych wedle uznania. Im więcej dowolności w mapowaniu tym trudniej się takie dane przetwarza maszynowo. Mapujący obszary a:h nie musi sprawdzać jakie tagi ma linia i dlaczego została podzielona. Jedyne co musi zrobić to wyrysować obrysy dla odcinków drogi.
Zastosowanie prostych reguł bez konieczności interpretacji tagów umożliwi w przyszłości stworzenie narzędzi do edytorów wspomagających rysowanie obszarów a:h. Jeśli reguły są niejednoznaczne, to żaden programista nie będzie się bawił w używanie algorytmów rozmytych inteligencji obliczeniowej aby stworzyć narzędzie operujące tylko na węzłach i liniach.
Ja również od początku byłem zwolennikiem stosowania area:highway=yes i pobierania klasy drogi z linii, więc sensownego uzasadnienia nie podam. Mniej sensowne uzasadnienia z jakimi się spotkałem są takie, że jest to analogia do wartości tagów highway. Drugie mniej sensowne uzasadnienie jest takie, że można to wykorzystać do uproszczonego renderingu, w którym nie ma technicznych możliwości do pobrania danych z linii.
Zaczęło się od tego, że na początku w proposalu podawanie kategorii drogi było opcjonalne, później powstał uproszczony rendering. Większość uznała, że skoro uproszczony rendering tego wymaga, to tak być musi.
Ja w swoim skrypcie zaimplementowałem częściową obsługę wartości yes. Dane są pobierane i przekazane do wyświetlenia, ale na warstwie z błędami jest wyświetlana sugestia, żeby zmienić tę wartość na pobraną z linii. Podobnie w przypadku, gdy wartość a:h jest niezgodna z highway. W takim przypadku wartość area:highway jest po prostu ignorowana.
Ja mam wrażenie, że wyważamy otwarte drzwi…
Wymyślono bowiem, że teraz rysujemy drogi nie jako wektory ale jako obszary. Nie byłoby w tym nic złego gdyby a:h stanowił doprecyzowanie danych a nie ich powielanie. Jak już pisałem w innym poście a teraz (tak mi się wydaje :)) Zbigniew_Czernik podziela mój pogląd, że a:k dotyczacy jezdni można ograniczyć jedynie do opcji a:h=yes (podział na motorway/primary/junction/itd wydaję się być zbyteczny) i obok niego mogą funkcjonować inne a:h np. emergency. Najważniejsze dane źródłowe nawi pobiera z highway - są to dane pierwotne i nadrzędne. Cały czas mam wrażenie, że a:h informuje tylko i wyłącznie o kształcie i szerokości jezdni. Za jakiś czas przyjdzie nam do głowy, że tagi do tej pory przypisywane do highway, będziemy dodawać do a:h jako zbioru dokładniejszego - a highway odejdzie w zapomnienie… Trochę mroczna wizja
Weźmy pod uwagę jeszcze jeden fakt: do mapowania w OSM wzięli się ludzie tacy jak ja, którzy nie mają nic wspólnego z informatyczno-techniczną stroną tworzenia programów mapowych czy innych temu podobnych. Moja głowa nie ogarnia wszystkiego o czym tu piszecie i podejrzewam, że nie tylko moja.
Wniosek: każdy maper po zapoznaniu się z instrukcją powienien wiedzieć o co chodzi a nie zastanawiać się dlaczego a:h zaczyna się w tym czy innym punkcie i nazywa się dla podobnych wycinków raz primary, innym razem yes, a później junction.
PS. Możliwe że jest to kwestia opracowania jednej dobrej instrukcji zawierającej zwizualizowane typowe przykłady wraz z ich otagowaniem. Każda zmiana rodzi opór - pewnie i w tym przypadku tak jest.
Otóż to. Każdy maper powinien wiedzieć o co chodzi, a nie zastanawiać się czy jeżeli tagi nawierzchni różnią się to może rysować obszar dla dwóch linii, czy trzech? Co jeśli tagi maxspeed różnią się, czy dzielić wtedy obszary? Maper, mając proste zasady, że dla osobnego obiektu linii powinien narysować jeden obszar ma ułatwione zadanie i nie musi przeglądać tagów. Postępuje w każdym przypadku analogicznie pamiętając o tej prostej zasadzie: jeden obszar ma przyporządkowaną jedną linię.
Maper nie musi już się martwić o szczegóły, tym się zajmą programiści przy implementacji (pisaniu programu).
Odnośnie przepisywania danych to aktualnie przepisuje się tylko wartość highway i layer, z czego tylko layer ma praktyczne zastosowanie. Mam nadzieję, że nikt nie wpadnie w przyszłości na pomysł przepisywania innych tagów z linii.
Otóż to! +1
Z innej beczki. Dlaczego właściwie wymyślamy całe mnóstwo nowych typów a:h (emergency, itp.), dając np. a:h=junction dla przejść dla pieszych zamiast zastosować istniejące tagi access. Np. obszar przejścia dla pieszych to a:h= + foot=designated (lub inaczej z użyciem właściwego tagu access). Czy nie byłoby to bardziej spójne z tym, co już mamy?
Obszar przejścia dla pieszych jest tak na prawdę obszarem jezdni. Przejścia dla pieszych są oznaczane przy pomocy węzła highway=crossing + opcjonalnie footway=crossing dla linii.
Ponieważ w takim obszarze znajduje się więcej niż jedna linia, to dodawany jest tag junction=yes. Jest to informacja, że tagi dla obszaru powinny być pobrane z linii o najwyższym priorytecie (czyli w tym przykładzie z jezdni, a nie z footway)
A w jakiej sytuacji tagi są pobierane z linii o nie najwyższym priorytecie?
Trochę offtopic:
Marimilu, koledzy z Niemiec proszą o renderowanie turn:lanes w powiązaniu z lanes, tak jak jest w Polsce.
Było nie było Twoja mapa jest jedynym narzędziem wizualizującym ten niezbędny do zaawansowanego routingu element OSM.
Jak kiedyś pisałem, turn:lanes kwiczy, ponieważ ciągle mam to u siebie i nie mogę przenieść na nową wersję oprogramowania. Może kiedyś.