mieszamy ze soba opis destination i linii dzielacych pasy jezdni.
Minus pomyslu 1:
Przy bardziej skomplikowanych wielopasmówkach latwiej sie pogubic i zle otagowac. Trzeba uwazac na kierunek narysowanego wektora, zeby pasy jezdni i dzielace linie sie ze soba zgadzaly.
Pomysł 1 bardziej mi się podoba. Nikt się nie pogubi jeśli będzie wygodne narzędzie, a wygląda to rozsądniej. Spłaszczanie różnych danych do jednego tagu to złe rozwiązanie.
Dlatego bardziej mi się podoba gdy się stosuje tagi:
highway:lanes=cycleway|tertiary|tertiary
bicycle:lanes=yes|yes|no
maxspeed:lanes=30|50|80
itd.
Zgadza sie, jest czystsze w zapisie.
Mamy nawet prototyp takiego softu napisany przez Rafala JAchowicza.
Jesli ludziom si espodoba, warto by to bylo zaadaptowac zeby to wyszlo z Polski.
Problem polega na tym, ze Rafal teraz zasuwa nad doktoratem i nie ma czasu.
Moze ktos by sie temu u nas przyjrzal?
tordanik rzucil propozycje taggingu:
destination:lanes=A|A|B|B
type:divider = solid|dashed|double_solid|dashed|solid
pokrywa sie to z powyzsza propozycja…
Tak w temacie bardziej rysowania niż tagowania.
Czytając sobie artykuł http://wiki.openstreetmap.org/wiki/Lanes doszedłem do wniosku, że w zamieszczonym tam bardzo fajnym poglądowym rysunku http://wiki.openstreetmap.org/wiki/File:Lanes_Example_2.png brakuje informacji jak powinny przebiegać drogi opisywane poniżej bardzo precyzyjnie poszczególnymi tagami. Czy drogi powinny być wyrysowane w ten sposób (na niebiesko):
czy też da się jakoś lepiej wycyrklować kształt tej przykładowej ulicy?
Jak widać, w tej sytuacji nawigacje w punkcie 5/6 prawdopodobnie będą sugerować “skręć lekko w prawo/lewo”, podczas gdy droga w terenie przebiega praktycznie na wprost.
Rozumiem, że w obszarze [5] mamy cztery pasy z podwójną ciągłą pomiędzy AA i BB. Jeszcze gorsza będzie sytuacja, gdy w pewnym momencie zamiast linii pojawi się w terenie stała bariera rozdzielająca pasy. Zgodnie z regułami powinno się wtedy rozdzielić drogę na dwie, co będzie skutkowało wirtualnymi zakrętami.
O połamanym renderingu w dużych przybliżeniach nie wspomnę.
Przygotowuję korektę tego tematu. Opis również uważam za błędny na chwilę obecną, zaś podział (linie niebieskie) powinien odbyć się w miejscu oznaczonym 2/3 a nie 4/5, bo inaczej np. nawigacja zbyt pózno zareaguje ani nie da się dobrze wyrenderować na tej podstawie rysunku.
Też miałem właśnie pisać, że niebieska linia jest źle poprowadzona i powinna się rozwidlać na styku 2-3. Przyznam, że często spotykam tak rysowane drogi i potwierdzam, że potem skutkuje to niepotrzebnymi/mylącymi komunikatami ze strony nawigacji.
Z jednej strony wcześniejsze rozdzielenie dróg pomoże nawigacji, ale z drugiej - tak jak opisano w artykule i tak jak narysowałem drogi - rozdzielenie w punkcie 5/6 lepiej odpowiada rzeczywistości. Jeżeli rozdzielimy drogi w punkcie 2/3 to uniemożliwimy zmianę pasa w obszarze 4, co - jak wynika z rysunku - jest jak najbardziej możliwe.
Owszem, jest to możliwe fizycznie, ale w praktyce już w tym miejscu nie zmienisz pasa, bo (prawdopodobnie) jest tam wyrysowana linia ciągła, którą kierowca powinien respektować.
Teoretycznie nawet jeśli nie było by tam pasa ciągłego, to taką drobną niedokładność danych dopuszcza się, jeśli dany odcinek nie jest dużo dłuższy niż kilkanaście metrów wychodząc z założenia że po pierwsze kierowca powinien kierować się faktycznym stanem ulicy, po drugie fizycznie trudno wykonać taki manewr na skomplikowanych skrzyżowaniach gdy jest duży ruch a po trzecie i najważniejsze skoro ktoś wybiera jakiś cel kierując się ku temu nawigacją, to prawdopodobnie nie wpadnie w ostatniej chwili na to, by nagle zmieniac cel i jechać w innym kierunku. Nawiasem mówiąc w branży profesjonalnej nawigacji tak się z tego typu danymi postępuje.
Co do tagowania pasów jezdni to toczyliśmy rozmowę z użytkownikiem Imagic z Austrii twórcą obecnego schematu. Jesteśmy zdania, że bez porządnego edytora będzie trudno ten schemat realizować bo w miejscach, gdzie jest to oczywiste proste klikanie może być nudne, zaś w miejscach gdzie jest to najbardziej potrzebne by poprawić jakość nawigacji może łatwo dochodzić do błędów edycyjnych.
W JOSM napisanie PlugIna jest w sumie do zrobienia, temat ugryzł już Rafał, ale kłopotem może być Potlatch2. Mam nadzieję że uda mi się znależć osoby gotowe zabrać się za implementację w Javie i w Perlu. Niestety Łódź robi teraz doktoraty a u nas reszta ekipy i tak pracuje na wysokich obrotach. Mam kontakty na Ukrainie i w Rosji, być może tam się ktoś za to zabierze. No chyba że ma ktoś z Was znajomego chętnego na taki projekt.
Torchę potagowałem lanes i turn:lanes i dochodzę do wniosku że w wielu przypadkach dla prostych skrzyżowań czy szczególnie rozwidleń lub pasów rozbiegowych nie ma potrzeby dodawania turn:lanes, gdyż taką informację zawiera sama informacja o liczbie pasów.
Co do podziału drogi na powyższym rysunku, podzieliłbym te drogi w miejscu gdzie zaczyna się linia ciągła pomimo że ciągle jest to jeszcze jedna jezdnia.
Generalnie czasem trzeba bardzo uważać z podziałami dróg na odcinki, niedawno poprawiłem połączenie DTŚ z DK79 http://osm.org/go/0LeVXSgmJ– ponieważ routing proponował łamanie przepisów - jest tam właśnie linia ciągła i np jadąc z estakady DTŚ nie można odbić w prawo w kierunku Baildona. W miejscu gdzie są teraz narysowane dwie drogi (2x2 oddzielone ciągłą) mogłaby być narysowana jedna co byłoby bliższe rzeczywistości + odpowiednie otagowanie linii na jezdni, lecz nie wiem które rozwiązanie jest lepsze. W tej chwili routing prowadzi prawidłowo a tagowania linii pewnie nie obsłuży od razu.
Narysowałem podział w punkcie 5/6 bo tak sugerują opisy tagów pod rysunkiem - dopiero w obszarze 6 są dwie drogi. Jeśli zgodzimy się, że rozdział powinien być tam, gdzie zaczyna się linia ciągła, to należy go przesunąć do punktu 4/5 (na oryginalnym rysunku w obszarze 4 jest jeszcze linia przerywana, moja linia zasłoniła ją). Na odcinkach 1-4 nawigacja powinna po prostu sugerować wybór pasa w zależności od tagowania pasów zgodnie z artykułem.
SOCool, wszystko sie zgadza. Zodnie z opisem ze strony postapiles prawidlowo i sam na poczatku tak interpretowalem. W momencie gdy zaczynamy nawigowanie z uzyciem ilosci pasów, fizycznie rozdzial powinien byc najpózniej tam, gdzie zaczyna sie linia ciągła. Powodem ku temu jest planowany fakt użycia płaszczyzn do bardziej precyzyjnego rysowania obszarów ulic.
Pytanie.
Czy jest możliwe, aby globalnie, zamienić nazwą klucza highway na** road** (droga).
Jest bardzo mylące, gdyż highway jest rozumiany jako autostrada.
Zdaję sobie sprawę, że highway jest najczęściej używanym kluczem, ale, jak zauważyłem, OSM “dopiero wychodzi na prostą”.
Więc warto by było, “wychodzić” w formie międzynarodowej.
Ja to rozumiem, że zostało to rozpoczęte przez Brytyjczyków i następnie narzucone jako standard.
Ale komputeryzacja i turystyka nie szła w parze z rozwojem języka angielskiego.
Myślę, że każdy kto zna minimum angielskiego, wie co znaczy 'road", czy “floor”, a nie bardzo zrozumie “highway” czy “flat”
Również ilość American+International w stosunku do British na OSM, też chyba jest duża.
W Europie raczej używa się Brytyjskiego, a biorąc pod uwagę, że Europa stanowi 70% danych ma to jakieś uzasadnienie. Wg mnie jako, że projekt został rozpoczęty na wyspach ma prawo wyglądać to w ten sposób.
To trzeba by do OSMF napisać bo tylko oni są w stanie taką operację przeprowadzić.
