area:highway

Ku mojemu zaskoczeniu temat ma się dobrze. Zbliżamy się do liczby 80000 elementów area:highway na mapie
(78161 na dzisiaj).

Fajnie

Area:highway=path - czyli ciąg pieszo rowerowy(o ile dobrze się orientuję.
Pytanie:

Czy można stworzyć podstawową wizualizację bez surface=x coś na kształt area:highway=service z tym żeby dominującym kolorem szarości była czerwień? W a:h=service jest to taki szary brązowy.

nierozdzielony ciąg pieszo-rowerowy to a:h=footway z tagiem bicycle=yes/ designated w linii (w obszarze chyba też można dodać, ale niech lepiej Marek rozwieje wątpliwości), rozdzielone ciągi piesze i rowerowe to oczywiście osobne obrysy a:h=footway i a:h=cycleway

Tomku, masz rację, dokładnie tak.
Pozdrowienia!
Marek

Nie istnieje coś takiego jak rozdzielony czy nierozdzielony cpr.
Cpr to cpr i jest to określenie stosowane w prawie budowlanym a nie drogowym.

Nierozdzielona to może być tylko “droga dla rowerów i pieszych” choć i tu od 2 lat takie określenie straciło rację bytu wobec zlikwidowania rozdzielonych “ddrip”.

Pomijam tu bug kodeksowy, który po zmianie ustawy PORD i doprecyzowaniu jej nowym rozporządzeniem o znakach, pozostawia stare nazwy znaków ddrip dla trzech znaków na dodatek oznaczonych tym samym symbolem C13/C16 co często prowadzi do pomyłek.
Po zmianach prawa nazwa znaku z pionową kreską może prowadzić do niewłaściwego zachowania tzn. nie stosowanie się do obowiązku jazdy czy ustępowania pierwszeństwa pieszym gdy to oni takie pierwszeństwo rowerom mają oddawać na części rowerowej.

Zatem dopuszcza się stosowanie określenia rozdzielona ddrip do czasu uporządkowania nazw znaków, a gdy to nastąpi będą tylko drogi dla rowerów, drogi dla rowerów i pieszych, pasy rowerowe. Są projekty zmian tych nazw na nowe ale w tym całym bałaganie nie wiadomo która regulacja najskuteczniej przetnie wszystkie zaszłości. Stąd moja prośba o stosowanie przez nas jednoznacznych reguł abyśmy tego chaosu nie kultywowali.

Zatem nierozdzieloną (nieseparowaną) ddrip oznaczmy na OSM jako highway=path + tagi designated i należy unikać wszelkich innych kombinacji tagów footway czy bicycle=yes i po prostu poprzerabiać na szablon od zawsze podawany na wiki i w JOSMIE jeśli iD nie forsuje swoich odmiennych rozwiązań (co mu się już zdarzało w innych tematach).
Stosowanie wielu szablonów do jednego rodzaju obiektu, który w Polsce nie ma żadnych odmian znacznie komplikuje rozmaite wizualizacje.

Zatem wprowadzanie takich wyjątków do a:h tylko zwiększy chaos, bo złe tagowanie będzie powielane przez nowych maperów i potem nie będzie miał kto sprzątać całego kraju, a każda aplikacja będzie wyświetlała drogi rowerowe inaczej.

skoro highway=path to analogicznie area:highway=path. Dlatego moja prośba o zmianę odcienia area:highway=path by rozróżnić ją od area:highway=secondary (itp). Pierwsze słyszę (mało więc czytałem) o robieniu takiego “bałlaganu” w tagowaniu wspólnych ciągów pieszo-rowerowch.

Co do tagowania to mogę jedynie potwierdzić, że linię oznaczamy jako highway=path + tagi designated. A obszar jako area:highway=path bez żadnych dodatkowych tagów typu bicycle=yes czy bicycle=designated.

Natomiast jeśli chodzi o wizualizację to teoretycznie byłaby to prosta zmiana, ale z tego co wiem to nikt się tą wizualizacją już nie zajmuje, więc po prostu nie ma osoby, która mogłaby takiej zmiany dokonać.

Dzięki Darku za info. Szkoda że nie ma kogoś kto mógłbyto z lekka dopracować. Tak jeśli nie odznaczymy warstwy surface, highway ma kolor taki sam jak path :(.

Osoba jest, raczej czasu brakuje.
Jeśli to prosta zmiana, to proszę w prosty sposób opisać co na co ma być zmienione - najlepiej z przykładem. Można też podać kolor (#rrggbb) jakiego trzeba użyć.

@marmil - mam na myśli coś takiego w stosunku do wersji dla oznaczenia area:highway=path

Obecnie dla area:highway=primary (i inne z tej “rodziny”) wygląd ulicy jak i ciągu pieszorowerowego area:highway=path ma taka kolorystykę:

moja propozycja (do rozważenia) kolorystyki dla area:highway=path to taki wygląd:

zwiększyłem w podstawowym kolorze area:highway=primary (i inne z tej “rodziny”) kolor czerwony o 40 %. Pozwoliło by to odróżnic gdzie jest ulica a gdzie ciąg pieszorowerowy biegnący przy samej jezdni, i nie tylko. Obecnie obie powierzchnie zlewają sie ze sobą tworząc jednakowa “strukturę”.

Marimil wyrenderował oznakowanie poziome to wydaje się łatwe wyrenderowanie kontrapasów rowerowych (i pasów) o śluzach nie wspominam.
Żadna mapa dobrze dróg rowerowych w jezdni nie renderuje a dziś to podstawa budowy ścieżek.
Wrocław, Gdańsk, Radom a za tym inne miasta wprowadzą kontraruch na większości jednokierunkowych ulic.
Tymczsem dziś trudno jeździć rowerem z OSM gdy drogi są renderowane jak jednokierunkowe.

@rowers2 - mi nie chodzi o kontrapasy rowerowe. Mi chodzi o ciągi pieszorowerowe biegnące wzdłuż ulicy ale obok niej (chodnik+ddr) tagowane jako highway=path gdzie w a:h powinny byc tagowane jako a:h=path.

No jest to problem który trudno rozwiązać bo taki kontrapas rowerowy jest dodawany do linii highway a nie jako oddzielnie biegnąca droga dla rowerów po lewej stronie jezdni (patrząc zgodnie z kierunkiem ruchu na ulicy jednokierunkowej). Swego czasu chciałem tak zrobić i wyrysowałem ww area:highway kontrapas rowerowy ale kiedy dodałem w osm taką jednokierunkową drogę dla rowerów zostałem poinformowany że to zostało źle zrobione (czy coś takiego - nie pamiętam dokładnie teraz) i wprowadzono dane do linii highway. W Szczecinie jest kilka odcinków kontrapasów rowerowych w a:h jako oddzielne elementy a:h w jezdni, ale dane o nich przypisane są do linii highway.

http://osmapa.pl/w/area/?lat=53.44306&lon=14.50225&zoom=19&ol=QqGFEPoBAR
http://osmapa.pl/w/area/?lat=53.42684&lon=14.53243&zoom=18&ol=QqGFEPoBAR

Tak rozumiem.Przestałem rysować chodniki w a:h wobec braków jezdni i dróg rowerowych oraz błędu w specyfikacji do wizualizacji, która zgłasza błąd junction na każdym przecięciu chodniczków. Znudziło mi się robienie łatek o wymiarach 2x2 m na każdym osiedlu gdzie chodniczki przecinają się kilka razy wokół małego trawniczka.
Zatem nie pamiętam nawet na ile podobny jest render path i footway. Rozumem że chcesz jakimś kolorem odznaczyć path szczególnie te wzdłuż jedni to by znaczyło że patch jest ciemna jak jezdnia.
Odpuściłem sobie rysowanie ddrip skoro ten twór krzyżuje się co 15 m z chodnikami .Będzie render w stronę ddrów to będę mapował.Teraz priorytet mają jezdnie i ddry. Robie w 3D i wkurzaja mnie a:h=footway poprzyklejane do fasad .

Kiedyś klinąłem tracerem nadajac nowy obrys budynkowi to jeden maper chciał mnie zabić bo narożnik zrobił się w pętelkę niewidoczną gołym okiem bo był sklejony z a:h i może nie trafiłem w noda .Kto to wie . Wystarczyło zaznaczyć dwa nody z mikroprzesunięciem aby je scalić i pętelkę zlikwidować ale maper wolał jęczeć w komentarzach do changesetu i rozsiewał idiotyczne notatki jakby człowiek mu to zrobił specjalnie.

Zatem nie chce mi się odklejać a:h od budynków a często muszę bo rysuję dachy wystające poza fasady to muszę dorysować fundament szerszy niż obrys ścian.

Pewnie by się to komuś nie podobało gdyby takie obrysy wchodziły choć troszkę na chodniki w a:h
Podobnych problemów w specyfikacji jest więcej jak a:h na jezdni wzdłuż niskiej zabudowy gdzie co 15 -20 m są z obu stron podjazdy co wymusza skrzyżowania a wizualizacja błędów na osmapie się robi czerwona ze złości.
Bez sensu taka specyfikacja skoro te podjazdy to nie są drogi publiczne więc nie am tam skrzyżowań. Każde sprowadzenie chodnika czy path do osi jezdni już zgłasza błąd.
Nie dogadaliśmy specyfikacji a:h i marnujemy czas na pierdoły więc odpuściłem, a gdybym sie w to nie bawił kiedyś to dziś miałbym a:h pokryte dwa razy więcej .Będzie sensowny render path to się ucieszę, bo tym można dotrzeć do środowiska rowerzystów aby np zrzuty naszej wizualizacji wykorzystywali do artykułów.

Dlatego, że mapy słabo renderują pasy rowerowe np rowerowa mapa na osm.org daje obwódki do jezdni miałoby sens rysowanie na czerwono na jezdni kontrapasów czy pasów. Jest podawana strona po której leży pas czy kontrapas więc co za problem wizualizować pasy dla aut i rowerowy zgodnie z ich szerokością? Pas rowerowy ma 1,5 m wiec skro można podzielić jezdnie aby renderować strzałki dla pasów to chyba ważniejsze byłoby renderowanie pasów rowerowych na czerwono?
wreszcie na wizualizacji w kilku zoomach byłoby widać na czerwono gdzie są drogi rowerowe.Jeśli by do tego dodać ddrip to obraz byłby jeszcze pełniejszy. Zatem gdy ty monitujesz od ddrip to ja pytam w dlaczego nie wszystkie drogi rowerowe?
Teraz już się praktycznie nie będzie budować ddrów i ddrip na chodnikach tzn., że dziury na mapach będą coraz większe a rowerzyści będą odrzucać osm, bo jak wytłumaczyć że osm renderuje tylko ścieżki chodnikowe a na jezdni wprowadza w błąd renderując strzałki o jednokierunkowości? Skoro pasy i kontrapsy są jednokierunkowe to powinny być na nich strzałki a kolor może być ten sam.
Dałbym nawet czerwony kolor dla kontraruchu.
Moglibyśmy do a:h dodać też śluzy, bo one się pięknie renderują i ich sens jest większy niż zatok autobusowych czy taxi.
Jednak najpierw zepnijmy sieć ścieżek

Jak pracować nad a:h skoro trudno jest ostatnio sprawdzić co i jak wygląda

Jest znaczna poprawa, bo walidador ma tylko 2-3 godzinne opóźnienia a może jeszcze mniejsze, bo może jest w czasie lokalnym a nie UTC.
Pewnie że przydałoby się aby chodził jak kiedyś tzn błędy uaktualniałby co godzinę a wizualizował nowe area:highway jakieś 20 minut po odczytaniu diffa godzinnego czyli średnio droga wrysowana widoczna byłaby po mniej niż godzinie.
Kilkugodzinne opóźnienia powodują że trzeba się przenosić na te 2-3 gdoziny w inny rejon aby nie sprzątać tego co już posprzątane.
Zatem robota skokowa nie jest systematyczna i spada wydajność i zadowolenie z pracy.

Ale gdzie byśmy byli gdyby nie talent i praca marimila. Choć już dziękowałem nie ustaję w podziękowaniach.

Są jednak rzeczy ktorych nie rozumiem. W ostatnich dniach poprawiłem tysiące a:h i jeszcze sporo pracy mnie czeka, ale jest kilkanaście a:h, które sprawdzałem kilkakrotnie i wydają się wrysowane dobrze a mimo to walidador nie chce ich wygasić.

Nie wiem jak marimil budował bazę tych wadliwych poligonów i czy co jakiś czas odświeża bazę w całości a nie z diffów, bo coś mi to wygląda na błędy w bazie i nie nie wiem jak wymusić zmiany w bazie tzn. czy zmienić geometrię poligonów, czy dodać jakieś nody aby baza OSM uznała, że obiekt został zmodyfikowany i wykazała to w diffie, a może po prostu poczekać tydzień (oby nie miesiąc) aż marimil bazę odświeży?

Teoretycznie wszytki błędy jakie się nie chcą skasować mógłbym wywalić do kosza i wrysować nowe a:h co się szybko zwizualizuje, ale to sposób znachorski i przydałoby się wyjaśnić wszystkim aby się nie denerwowali, że nie mogą znaleźć błędu.

Bardzo dobra wiadomość! Wycofałem się z mapowaniem z Polski do Nepalu bo były właśnie kłopoty z aktualizacją mapy. Teraz będę miał motywację by znów działać w Polsce. Dzięki dla Marimila.

rowers - jak to pisałem to dane odświeżane nie były chyba od miesiąca i ich aktualiazacja trwałą drugie tyle. Dziś fakt jest zajefajnei super robisz idziesz zjeść obiad czy kolacje wracasz a tu Twoja praca jest widoczna.
Co do błedów które są i nie wiadomo gdzie - sam kiedys walczyłem z własnymi okazywało się że na syku dwu area:highway=tertiary (załóżmy) w miejscu styku z linia highway=tertiary jedno a:h=tertiary nie ma tego punktu wspólnego.

Mówisz o sytuacji oczywistej sygnalizowanej przez walidador czerwonym błędem.
To przecięcie jest na z linii dróg która nie ma punktu wspólnego z poligonem a:h.
To jeden z najczęstszych błędów bo nod jest przyklejony do sąsiedniego poligonu a wygląda jakby był przyklejony do dwóch a:h.
Sprawę pogarsza jeśli styk poligonów wypada na krawędzi mostu bo wtedy w jednym miejscu spotykają się czy poligony.
Ale to przecież łatwo się sprawdza ciągnąc myszką noda we wszystkie strony aż się zauważy że krawędzie poligonów się rozjeżdżają względem siebie.
Takich błędów poprawiłem w weekend i wczoraj ponad tysiąc więc raczej wprawę i wiedzę gdzie są miejsca najczęstszych błędów mam.
Są jednak proste poligony złożone z mnij niż 10 nodów przez które nie przechodzi żadna doga typu proposed czy construction i mimo że 2-3 drogi wychodzące z poligonu mają z nim punkty wspólne, obiekt dalej jest czerwony.
Ten sam problem dotyczy poligonów pomarańczowych czyli zwykle nie posiadających tagu junction.
Czyli poligon ma junction a dalej wisi jako pomarańczowy.Tak samo ale rzadziej problem dotyczy błędów żółtych tzn pojedyncza linia przechodząca przez poligon jest przecięta co oznacza że z jednego poligonu wychodzą dwie linie.
Czyli takie niby skrzyzowanie. Oczywiscie rozwiązaniem jest albo scalenie lniii albo przecięcie w tym miejscu poligonu a:h na dwa mniejsze.
Czyli mimo dobrych działań naprawczych takie błędy nie zawsze znikają.
Z niektórymi błędami walczyłem bezskutecznie 2 tygodnie , ale wiekszosc z nich chyba z czasem zniknęła sama tzn tak jakby baza była zbudowana na nowo
Ok 1-2 % zostaje

Niby nic strasznego ale jeśli w miescie wisi 20 takich błędów to można nie zauważyć, że doszły nowe błęsy bo koś dodał jakąś drogę przecinajaca a:h.

Te wiszące błędy to zwykle bardzo małe poligony góra wielkości średniego skrzyzowania. Na odcinakach prostych dotyczą kawałków drogi bardzo małych powiedzmy 10-20 m toteż to może być jakaś wskazówka.
Jednak dziś rano widziałem kilka długich odcinków dróg a przecież walidador miał całą noc aby ewentualne poprawki błędów z wieczora wyczyścić.

a:h=emergency na wizualizacji marimila wspaniale obsługuje tag direction=(azymut)
nadający kierunek kreskom farby

jak go dokładnie stosować?