Nie ma znaczenia ile silników trasuje i w jaki sposób. A jeśli będzie taki jeden, to co to zmieni w prawidłowości otagowania? Nic. To jest oczywiście ważny czynnik praktyczny, ale nie zmienia faktu, że linie na obszarze to po prostu tagowanie pod trasowanie.
Przyznam, że jeszcze bardziej się zgubiłem. Kto według Ciebie ma rację?
Ja mówię o czymś takim jak np. ulica Długa w Gdańsku.
ja tam jestem ciekaw jak do tego doszło że na głównym renderze OSM zatwierdzono coś co psuje inną funkcjonalność mapy (wyznaczanie trasy), ktoś kto to podbił powinien ponieść konsekwencje, choćby dostać upomnienie
o problemie z wyznaczaniem trasy po obszarach nie chcę się wymądrzać, bo nie mam pojęcia o tworzeniu kodu mapy i obsługujących ją aplikacji, ale wydaje mi się że to przejaw zacofania i takie coś nie powinno stanowić współcześnie wielkiego problemu, to chyba raczej kwestia darmowości OSM i braku chętnych do rozwiązania tego problemu
Jest jakieś wzorcowe (sprawdzone pod ostatnie ustalenia) skrzyżowanie w Polsce zawierające prawidłowe tagowanie liniowe i obszarowe?
Coś tam na wiki widziałem ale ten przykład bardzo mnie zaskoczył więc nie wiem czy tam są niezweryfikowane błędy, czy coś się zmieniło w specyfikacji.
Czy a:h na wiki będzie spolszczone?
http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area
Czy podany tam sposób tagowania przejść dla pieszych albo dla rowerzystów jest właściwy, bo widzę wiele sposobów tagowania a nawet w przykładzie z Polski jest inaczej.
W polskim prawie przejście podzielone wysepkami azylowymi są to dwa przejścia.
Na OSM rysowanie liniowe prowadzi do wielu fikcji.
Jeśli na taki fikcyjny przebieg dróg i chodników nałożymy rysownie obszarowe to linie nie będą w osi tych obszarów.Zatem jeśli rysujemy a:h z dokładnością zbliżoną do linii znaków poziomych to pytanie czy nie pogłębiamy fikcji?
Przykładowo są po obu stronach wyżej wspomnianego przejścia dwie wysepki azylowe.
Jezdnię rysujemy tak, że przecina ona obie wysepki a my w a:h rysujemy wysepki i Strefy Bez Ruchu.
Na skomplikowanych skrzyżowaniach wywalamy pasy do skrętu gdy nie są separowane a tam gdzie pasy są separowane rysujemy jedną linię i przyklepujemy to nieodpowiadającymi a:h łączonymi z liniami na siłę?
Dyskutujecie o silniku trasującym po obszarze a rysujemy a:h na którym nawet render będzie miał problem jak rozmieścić strzałki na pasach a co dopiero trasowanie po obszarze.
Jeśli tak będziemy rysować to navi ani nie będzie prowadzić bezpiecznie po a:h ani po liniach jezdni bo osie jezdni będą prowadzone po wysepkach i SBR.
Wygląda, że a:h to tylko robienie pod render a jeśli tak to po co ta cała zabawa w łączenie a:h z siatką liniową?
Bliższe rzeczywistości byłoby przed zabraniem się za a:h porozdzielanie jezdni wokół wysepek wtedy linie byłyby w osi a:h .
Inaczej mówiąc fikcyjne zgrubne rysowanie w systemie liniowym nie razi tak jak gdybyśmy w a:h pomijali np. przeszkody i razi też gdy szkielet linowy współpracuje z a:h, bo punkty łączeń obu systemów wypadają w durnych miejscach.
Jeśli zabieramy się za pracochłonne a:h to tłumaczenie, że prowadzenie dróg po wysepkach miało służyć przyspieszeniu skończenia mapy wymusza poprawienie tego co było zrobione “po łebkach”.
Czy a:h na wiki będzie spolszczone?
Tak, jest: http://wiki.openstreetmap.org/wiki/Pl:Proposed_features/Street_area jakkolwiek właśnie je poprawiam.
Uwaga dot. wysepek jest słuszna. Ponieważ tak stanowi prawo oraz jest to tzw. physical divider, powinniśmy rysować tutaj dwie linie. Przykład:
http://www.openstreetmap.org/way/441380410
A gdy się prawo zmieni, to przerysujemy na nowo? A jak ze zmiany się wycofają, to znów przerobmy? Poza tagami access w osm raczej nie odzwierciedlamy stanu prawnego.
Prościej o logiczniej byłoby użyć jednej linii z traffic_calming=island. Tym bardziej, jeśli chcesz stosować się do stanu prawnego, bo takie wysepki nie tworzą dwóch jezdni 
@maraf24 - zawsze można przerysować uaktualnić 
- i to nie złośliwość.
Swego czasu tak zacząłem robić potem zbastowałem - choć wolałbym by w navi widzieć iż jezdnia się rozdwaja bo rząd wysepek ciągnie się przez pół wsi, albo skrzyżowanie jest już ciut większe także z wysepkami na jego początkach - ale przestałem bo poczytałem i zgłupiałem.
Zgłupiałem bo: gdzie w sumie zaznaczać traffic_calming=island na takim skrzyżowaniu kiedy robimy ją jak mówi wiki na openstreetmap jedną linią a nie dwoma jednokierunkowymi:
zaznaczać węzły w miejscu znaków nakazu?; po środku wysepki?; tylko na początkachwysepek od strony dojazdu do nich?; czy jednak podielic drogę na dwa odcinki z oneway=yes?
jest to to miejsce: http://www.openstreetmap.org/way/415291650#map=18/53.27530/14.51283
Rysujemy stan faktyczny, nie prawny. Jeśli coś się zmienia, rysujemy nowy stan faktyczny. Dobrym przykładem są tu błędne importy budynków dzielące je na kilka części. Konsens w OSM jest inny.
Myk w przypadku area:highway jest taki, że tutaj również zamierzeniem jest rysowanie stanu faktycznego, tyle, że dokładniej, niż do tej pory.
Jeżeli założymy, że celem jest
- dokładne odwzorowanie wszystkich powierzchni
- generyczne odwzorowanie pasów jezdni i strzałek
to konsekwencją jest dzielenie drogi w przypadkach wysepek.
Jeśli tego nie zrobimy, nie uda się nam osiągnąc punktu 2.
Ten rysunek pokazuje dlaczego:
http://wiki.openstreetmap.org/wiki/File:Kpoints3a.jpg
Linia żółta, to oś ulicy highway=*
Czarne punkciki na osi ulicy to punkty tej drogi.
W podanym przykładzie mamy lanes=6
Przez czarne punkty prowadzimy zielone dwusieczne kąta znajdując a ten sposób dla każdej dwusiecznej dwa punkty wspólne (na rysunku zielone) z obrysem area:highway=*
Odcinek na rysunku oznaczony jako Pi’-Pi’’ może zostać podzielony na 6 równych odcinków.
Przeprowadzając tą operację analogicznie dla każdego punktu Pn możemy przeprowadzić rendering dający wynik taki, jak na:
http://wiki.openstreetmap.org/wiki/File:Kpoints6.jpg
W czym problem oprócz tego, że jest to pracochłonna praca?
Podejście to wymaga zmiany dotychczasowego paradygmatu mapowania takich sytuacji.
Zamiast:
http://wiki.openstreetmap.org/wiki/File:Marek2Lanes0.jpg
mapujemy tak:
http://wiki.openstreetmap.org/wiki/File:Marek2Lanes2.jpg
^^ to należałoby zmienić uaktualnić podejście i i info o stylu rysowania dróg. By nie było że rysuje jako to nowe podejście a masa użytkowników będzie mówiła że psuje i zmieniam choć w wiki jest inaczej.
Dopóki ktoś nie zrobi renderingu lanes ludzie nie będą czuli bluesa. Jestem pewien, że ludzie będą w takich sytuacjach “naprawiać” elementy do stanu poprzedniego.
Z czysto formalnego punktu widzenia mamy do czynienia z proposalem, więc trzeba będzie takim osobom tłumaczyć o co chodzi. To trudne, ale nie widzę innego wyjścia.
Dlatego też tak martwi mnie brak kontaktu z Marimilem. Można by tą część pracy dać komuś do zrobienia, np. jako praca dyplomowa. Wtedy od razu było by widoczne, że coś nie gra i ludzie by to naprawiali.
Ale te przejścia są dwa nie tylko prawnie ale i faktycznie.
Wystarczy popatrzyć czy miedzy wysepkami azylowymi są pasy zebry.
Od lat tam się zebry nie maluje wiec jest to wysepka z dwoma zebrami
Jakieś crossing=traffic_calming czy czy rysowanie jezdni po wysepkach to tworzenie fikcji w dobie mikromapowania.
Pytania o rysowaniu na nowo nie rozumiem, bo dwie linie jezdni nie wynikają z prawa, że są dwie zebry, tylko z fizycznej separacji jezdni za pomocą wysepek.
W kontekście przerysowywania na nowo raczej głupio będzie przerysowywać pracochłonne a:h na nowo, gdy zdecydujemy się robić dwie jezdnie w szkielecie liniowym.
Ale prosta logika i uczciwość przy kasowaniu nakazuje konsekwencje.
Dążymy do upraszczania pasów do skrętu. Przyjęliśmy prostą zasadę że przeszkody na jezdni stanowią o ilości nitek. Jeśli na tym samym skrzyżowaniu będziemy stosować dwie wykluczające się zasady, inną dla liniowego rysowania a inną dla obszarowego, to wpadniemy w bagno gdy a:h się rozwinie o nowe elementy np. będzie renderować szerokość pasów, strzałki, latarnie itd.
Jeśli nie szokuje pas separowany wysepką w tarczy skrzyżowania, to dlaczego tak razi rozdzielanie jezdni przy wysepkach azylowych?
Wydaje się, że to nie powinno podlegać dyskusji, a takie oczko poprawia bezpieczeństwo jazdy, bo takie azyle robi się w miejscach gdzie dochodziło do wypadków.
Nie dajmy pretekstu do kpin, że mamy mikromapowanie a drogi kreślimy po Strefach Bez Ruchu .
Może przyszły render liniowy będzie rysował linie o szerokości proporcjonalnej do ilości pasów, co pozwoli szybko te dane uzupełnić aby poprawnie działał asystent pasa
+1
Dlatego zawsze rozdzielam takie odcinki drogi.
Liczby pasów. Pasy są policzalne.
Rowers2,
dzięki za zwrócenie uwagi na stan polskiej stronki area:highway.
Straszna sieczka. Zacząłem to poprawiać ale jeszcze jutro nad tym posiedzę by można było cokolwiek z tego zrozumieć.
Takie podejście się nie sprawdza - jest za mało mapujących, a ci, którzy są, wolą robić ciekawsze rzeczy niż poprawiać.
traffic_calming=island jest też stosowane w postaci linii, a nie tylko jako węzły.
W przypadku węzłów najlepiej robić tak, jak napisano na wiki - stosować je dla wysepek maksymalnie kilkumetrowych.
Zawsze uważałem, że w a:h chodzi o punkt 1. Nie wiem, kiedy i czy pojawił się 2.
Tego się nie da zrobić bez rysowania osobno pasów, przynajmniej w sytuacjach odbiegających od typowych. A tego w a:h nie ma.
I to jest istota problemu z rozdzielaniem.
Nie uda się uzyskać zgody społeczności na zmianę sposobu mapowania dróg, zwłaszcza używając argumentu, że to jest potrzebne do prawidłowego działania jakiegoś proposala. Jest to niewykonalne, bo społeczność jest konserwatywna - chce by było tak, jak jest (z bardzo różnych powodów).
Dlatego a:h nie może się gryźć z istniejącymi rozwiązaniami, musi być maksymalnie neutralne.
Cóż, jestem odmiennego zdania. To samo było najpierw z rysowaniem budynków:
Ludzie rysowali grupy budynków. Niektórzy zaczęli rysować pojedyncze budynki, zostali początkowo zakrzyczani. Znam przypadki z Niemiec, gdzie ludzie rezygnowali z mapowania z tego powodu.
Dobrze pamiętam rozmowę z jednym mapowiczem który powiedział mi, że nie mamy co marzyć o ściganiu Niemców bo nigdy nie osiągniemy porównywalnego poziomu. Zmapowałem wtedy w pojedynkę większość budynków w Łodzi.
Zmapowanie budynków otworzyło drogę do dyskusji o 3D.
Też było to na początku odrzucane.
Dlatego nie przejmuję się konserwatyzmem niektórych grup w OSM. Są na szczęscie ludzie którzy konserwatywni nie są i to oni pchają ten projekt do przodu wprowadzając nowe rozwiązania.
Gdyby tego nie było, czekał by nas efekt wikipedii: Większość artykułów została napisana, więc zaczęły się wojenki edycyjne i znaczący spadek ilości aktywnych uczestników projektu.
Gdy Zbigniew był jakiś czas temu w Niemczech, próbował w jednym dużym mieścia zmapować cokolwiek. Ale wszystko już było, nawet kosze na śmieci i latarnie 
Tak więc jestem głęboko przekonany, że potrzebne są nam nowe impulsy.
Do tego potrzeba wizji, pracowitości i zwykłego uporu/wytrwałości (jak zwał tak zwał), ale faktycznie się da.
Dobrze rozumiem, że postuluje się mapowanie nitek w przeciwne strony osobno, nawet jeśli nie są rozdzielone fizycznie?
Tak tylko wspomnę, że problem ponownego złączenia dwóch nitek w jedną jest od dawna wałkowany przez ekspertów od GIS i chyba w ogólnej postaci nie da się go rozwiązać. Nawet ArcGIS nie obsługuje trochę bardziej skomplikowanych skrzyżowań.
Uważam, że już teraz zbyt często wymagamy za wiele od konsumentów danych.
Może powinno się wprowadzić osobną kategorię dróg tylko do celu routingu a osobną do dokładnego rysowania? To mogłoby być konieczne tylko w niektórych przypadkach, np. właśnie skomplikowanych skrzyżowań.
Zapewne mrzonki i komplikacja.
Ależ po co jeszcze coś wprowadzać? Linie są do nawigacji, a obszary do oddawania geometrii. W szczególności - w prostych wypadkach - można liniami przybliżać obszary, ale w skomplikowanych nie ma na to szans.