Właśnie zauważyłem, że nowy styl wyświetlania ścieżek nie dość, że jest nieczytelny i całkowicie niespójny zarówno ze standardami kartografii, jak i z całą resztą mapy, to dodatkowo zawiera w sobie jeden istotny błąd. Mianowicie ścieżki bez ustalonej nawierzchni wyświetlane są tak, jakby miały nawierzchnię lepszą, niż te z nawierzchnią surface=ground. Błąd polega na zakładaniu lepszej jakości przy braku jakichkolwiek danych - przedtem ten błąd był tylko podczas wyświetlania highway=track bez podanego tracktype (które były wyświetlane tak jak tracktype=grade1, podczas gdy powinny być wyświetlane jak tracktype=grade5). Ogólnie, jeśli brakuje jakichś danych koniecznych do wyboru stylu wyświetlania, to należy zakładać najgorszą możliwość - wtedy ewentualne szkody wynikłe z wprowadzenia kogoś w błąd są najmniejsze.
Piszecie tu (nie chce mi się szukać gdzie), że dla przeciętnego użytkownika różnica pomiędzy ścieżką wydeptaną a utwardzonym chodnikiem objawia się tylko, gdy chce się omijać błoto itp. To nie prawda. Różnica ta jest bardzo istotna dla osób wybierających się na spacer z wózkiem dziecięcym - który po chodniku przejedzie zawsze, a po ścieżce tylko niekiedy (np. ścieżka w lesie może mieć wystające korzenie, na terenie górzystym może nie dać się jechać ze względu na połączenie kamienistej nawierzchni z nachyleniem terenu). Oczywiście są inne tagi, które mogą to sugerować (surface lub wheelchair), ale jeśli ich nie ma, to wyświetlanie powinno wyglądać tak, jakby była najgorsza możliwość. Ścieżka nieutwardzona to ewidentnie coś gorszego, niż utwardzony chodnik.
No ok ale wszystkie te informacje można podać w dodatkowych tagach. Nie rozumiem rozbicia na pedestrian, footway i path ze względu na to, że i nawierzchnię i szerokość oraz dostępność można określić dodatkowymi tagami.
Co mi jeszcze przychodzi na myśl to np. takie definicje. Path - stricte dla wąskich ścieżek leśnych nieutwardzonych (defaultowo nieutwardzona). Footway (defaultowo utwardzona). Pedestrian nigdy nie używałem i wydaje mi się zbędne.
Chociaż i tak sądzę, że spokojnie wystarczy jedna kategoria typu “footway” i nie ma potrzeby rozbijania. Keep it simple. Od przeznaczenia, szerokości, dostępności i nawierzchni mamy inne tagi (jak już wspomniałem wcześniej).
E tam, bez przesady z tym upraszczaniem. Równie dobrze moglibyśmy wszystkie drogi tagować jako highway=road a różnicować jest tylko tagami surface, width, smoothness, importance itp.
Tak, na tym polega probem - path i footway bez surface wyglądają lepiej niż path i footway z surface=unpaved. Jednocześnie wydają się być identyczne jak footway z poprzedniej wersji osm-carto.
Wygląda to tak, że ten path,który jest nie wiadomo czym, dostał awans w wyświetlaniu. Jednocześnie footway zachował swoją pozycję.
Podzielam Twoje zdanie. Mało tego, uważam, takie ujednolicenie za krok wstecz. Mapa powinna być narzędziem uniwersalnym, wykorzystującym to, że ścieżki i chodniki są opisane innymi tagami. Nie wiem z czym jest problem, od początku mapowania rozumiałem path jako wydeptaną ścieżkę (polną, leśną, osiedlową na skróty), a footway jako chodnik (czasem lepszy, czasem gorszy). Tak wskazywały “wszystkie znaki na mapie i na wiki”, na których się wzorowałem.
Na podstawowym renderingu (Mapniku) powinno być widoczne rozróżnienie funkcjonalności bez niuansów typu “ciut jaśniejsza obwódka”. Jeśli widzę na mapie path przebiegającą na skróty wobec footway, więc do mnie należy decyzja co wybiorę do spaceru. Dopisywanie tagów do ścieżek o szerokości, i nawierzchni jest na chwilę obecną, nawet wykorzystując automatyzację, dodatkową pracą, gdy można się skupiać na innych poważniejszych brakach z różnych kategorii całości OSM.
Czy wobec nowych wytycznych twierdzących, że path i footway to to samo, do każdego chodnika oznaczonego jako highway=footway należy obok tagu surface dodać też bicycle=no? Bo rowerem po path można, ale footway dotychczas trakowało się jako wyłacznie dla pieszych.
To nie jest błąd, tylko zamysł projektanta. Myślę, że lepiej tak niż odwrotnie, bo trzeba by wszystkim utwardzonym chodnikom dodać tag surface.
Tutaj winę mają dane, któtszy odcinek z jakiegoś powodu nie ma tagu surface co jest niezrozumiałe skoro ktoś dodał mu tag wheelchair=no to dlaczego nie mógl od razu surface który jest bardziej podstawowy. Dzięki renderingowi błąd jest łatwo zauważalny więc pewnie szybko zostanie naprawiony.
Ciągle zapomina się tutaj, że tag highway, niezależnie który, służy do opisywania funkcji drogi a nie jej parametrów technicznych. W obu przypadkach, footway i path, funkcją jest poruszanie się pieszo, a reszta, zaczynając od surface, width czy smoothness powinna trafić do dedykowanych tagów.
Na pewno nie trzeba dodawać do footwaya bicycle=no. Nikt nie powiedział, że tag path został wycofany, choć bardzo możliwe, że otrzyma deprecated.
Właśnie sprawdziłem, że kombinacja highway=footway + bicycle=designated (zamiast highway=path + bicycle=designated) renderuje się jak zwykły footway na czerwono a nie na niebiesko więc w tej sytuacji przynajmniej na razie trzeba korzystać z h:path.
Funkcja to nie tylko samo chodzenie - jak w drogach jeżdżenie. Oczywiście nie sprowadzajmy analogii do absurdu w mnożeniu rodzajów chodzenia. Trójpodział dla pieszego: pedestrian/footway/path wg mnie jest dobry i powinien zostać.
Zbigniew bardzo dobrze to wyłożył. Zamiast stosować np. unclassified, residential, tertiary i dalej “wzwyż” można byłoby zastosować road i opisywać tagami (z refami byłoby wiadomo czy to tertiary czy secondary). I analogicznie wśród chodzenia jest coś, co może być trunkiem bądź trackiem - tyle, że dla pieszych.
Nie chodzi tu o wymyślanie własnych teorii ale zrozumienie jak to w OSM działa, po co dane zagadnienie zostało wymyślone i opracowane tak a nie inaczej.
Przypomnę, że zgodnie z tematem wątku tutaj rozmawiamy o sposobie wyświetlania istniejących tagów, nie o ich znaczeniu ani o możliwości zastąpienia pewnych kombinacji tagów innymi. Przypominam również, że wiki w osm to nie jest żadna wyrocznia, lecz tylko sugestia, a faktyczne głosowanie odbywa się danymi. Dane natomiast mówią, że footway to utwardzony chodnik, a path to nieutwardzona ścieżka, ze wyjątkiem nieszczęsnego highway=path + bicycle=designated itp. dla DDR. Jeśli jednak taka była koncepcja zmian w wyświetlaniu, to domagam się wyjaśnienia, dlaczego drogi highway=road nie są nadal wyświetlane tak, jak autostrady - byłby to dokładnie taki sam przypadek, jak highway=path bez dodatkowych danych (brak szczegółowszych danych o klasie/jakości drogi).
Nigdy nie było takiego rozróżnienia, jedynie wielu maperów wszelkie utwardzone drogi dla pieszych dawało jako footway a pozostałe jako path. Byli jednak i tacy, co się tego nie trzymali. Tutaj https://github.com/gravitystorm/openstreetmap-carto/pull/1713 ktoś podał statystkę dla footway i path które mają surface. Jest stosunek 3:1 dla footway z paved wobec unpaved i 1:3 dla path z paved/unpaved.
Są w tym linku i inne liczby. Jest 3 miliony path bez surface i 4.5 miliona footway. Poprawa tego zajmie lata.
Nie wiem do czego pijesz, ale ja nowych teorii nie wymyślam. Ktoś wymyślił path (może o co innego mu chodziło - nie wiem jaką miał swoją wymyśloną teorię). Logiczne i funkcjonalne dla mnie jest to, że footway to chodnik, a path - ścieżka. Nad wieloma wartościami tagów się zastanawiałem, ale to akurat jest proste jak drut. Różnica w funkcjonalności takiego highwaya jest zasadnicza. I powinna być zróżnicowana (IMHO) na wszelkich renderingach bez dodatkowych tagów (póki ich nie ma).
To jest inny typ highwaya i kropka Dlaczego jeżdżenie może mieć pisiont tagów (rodzących dyskusje jak z track i trunk) a chodzenie, gdzie podział jest po wielokroć klarowniejszy, trzy - to już za dużo?
Podział path/footway jest prosty, logiczny i intuicyjny, stąd miliony narysowanych tak dróg, po co to ruszać? @marcin_b - pełna zgoda.
Będziemy mieli powtórkę z rozrywki?
Drogi przeznaczone dla samochodów pełnią konkretne funkcje, można poczytać na Wiki. Dla pieszych na ten moment widzę dwie funkcje:
highway=pedestrian: spacerowa, reprezentacyjny deptak miejski, najcześciej zamknięta dla ruchu samochodowego, ale dopuszcza ich wjazd na specjalnych warunkach
highway=footway: droga dla pieszych, pieszy jak wiadomo zawsze wybiera najkrótszą drogę (poza szczególnymi przypadkami jak jazda wózkiem, omijanie błota które załatwia surface, width, smoothness)
Czy potrzeba innego tagu?
Jakie korzyści widzę
jeden tag zamiast dwóch co zawsze jest dobre dla bazy danych
zmiana w renderingu zachęca do tagowania surface
Zaakcentowanie, ze highway=path nie jest dla samochodów, co nie zawsze było stosowane. Często widziałem, h:path, które powinno mieć h:track z tracktype:grade5
Wymyślanie, że h:path jest przeznaczony dla dróg pieszych nieutwardzonych przypomina mi przepychanie na siłę swego czasu, że highway=track służy do oznaczania dróg nieutwardzonych. Jest to tagowanie pod rendering, którego powinno się unikać. W tagu highway nie umieszczamy informacji o parametrach technicznych drogi a jej funkcję.
Jestem podobnego zdania, podział był logiczny, teraz muszę się domyślać czy wzdłuż drogi biegnie wydeptana ścieżka czy chodnik, bo zwykle jak ktoś dawał path to raczej nie używał surface, bo to wynikało z samego tagu, tak jak highway = track.
Zbywanie dyskusji, że tagujemy pod rendering uważam za niestosowne (i na forum po wielokroć nieuprawnione). I zdarza się, że rzeczywiście ktoś coś zrobi pod render, ale przeważnie dlatego że to render jest - niestety - albo głupi, albo nieadekwatny. I ktoś kombinuje. W omawianej zmianie następuje unifikacja oznaczenia.
W przypadku stosowania footway/path - i nawet wiki (choć nie wiem jak mam podejść, bo jeden z dyskutantów powołuje się na wiki, pytanie polską czy angielską [?], a drugi o tym, że nie jest wyrocznią… ale dobra…) więc wiki o tym wspomina - że jeśli po footwayu można jeździć rowerem to należy korzystać z path. Czy to ścieżka leśna, śródpolna, czy na skróty przez osiedle zazwyczaj da się przejechać rowerem. Mało tego, nie wiadomo kto będzie winny jak będzie kolizja z pieszym. Czego o chodniku nie można powiedzieć. Tak więc można uznać to z FUNKCJONALNIE określony tag highwaya, który nie wymaga nawet dodatkowego tagowania. No i JEST, niczego NOWEGO nie wymyślamy.
Dlatego pozwolę sobie rozwinąć Twoją… teorię:
highway=pedestrian: spacerowa, reprezentacyjny deptak miejski, najcześciej zamknięta dla ruchu samochodowego, ale dopuszcza ich wjazd na specjalnych warunkach
highway=footway: usankcjonowana i wykonana droga dla pieszych o określonych parametrach - pieszy wybiera drogę jaką chce
highway=path: droga wykorzystywana przez pieszych i do jazdy rowerem (czasem z zakazem), zazwyczaj dzika i bez sprecyzowanych parametrów fizycznych, najczęściej spotykana w lasach, gospodarstwach i uprawach rolnych, obszarach naturalnych.
PS. W takim razie tracki można zastąpić unclassified z tagami acces i surface, podobnie living_street z residentialami. Jak upraszczać, to upraszczać.
Nazywanie rzeczy po imieniu niestosowne? Jest to nie tylko tagowanie pod rendering, czyli osiąganie określonej wizualizacji poprzez manipulację danymi ale do tego niezgodne z definicją:
Od oznaczania nawierzchni jest surface, który ponadto teraz jest renderowany (a nie zawsze mamy ten komfort) więc można być tylko z tego zadowolonym.
To tylko potwierdza, że nie są potrzebne oba… Nie wskazałeś innych różnic niż parametry techniczne.
Tracki to drogi dojazdowe do pól i lasów, nie przeznaczone dla samochodów osobowych w typowych sytuacjach. Unclassified to najniższa z kategorii siatki dróg. Widzę wyraźne różnice w funkcji.
Tutaj różnica jest rzeczywiście mała, ale jednak living_street ma dodatkową funkcję, możesz na niej spotkać pieszych, dzieci grające w piłkę, mają oni pierwszeństwo nad samochodami.
w tym przypadku mamy inną funkcję tej drogi, o czym świadczy nawet Wiki na którą się powołujesz. Tylko nie pierwsze zdanie, tylko ogląd całego artykułu (!)
póki co są to path zunifikowane renderingiem z footway - więc w tym przypadku nikt jeszcze nie zdążył zrobić “pod render”
Mapa to system oznaczeń który widzimy (rendering na ekranie, albo papierze), do tej pory ten rendering w zakresie rozróżnienia ścieżki od chodnika (charakteru i funkcji) IMHO się sprawdzał. Tym bardziej, że piesi nie korzystają z nawigacji drogowej (która może wyciągać ukryte w bazie OSM surface i inne) tylko patrzą się na render i widzą rozróżnienie.
Dziwne, że piszesz o rezygnacji z path, posiłkując się z Wiki tego hasła. Rozumiałbym, gdyby to było z opisu footway. Oznacza to, że jest ten tag potrzebny A skoro jest i różni się z footway, powinien (moim zdaniem) różnić się od footway. Uważam za błędną i idącą w złym kierunku teorię, że jeśli może mieć różne surface i można tam chodzić to należy rezygnować z path. No, ale to moje zdanie, z którym się możesz nie zgadzać. Wykładam po prostu swoją argumentację.
Wiesz, nie mam zamiaru żonglować przypisywaniem funkcji do jakiegoś elementu w OSM, która jest na tyle dyskusyjna, że możemy się sprzeczać w nieskończoność. Funkcja to nie tylko chodzenie ale rodzaj i charakter chodzenia. Nie wmówisz (wpiszesz) mi, że spacer kamienistą drogą przez las i chodnik przy ulicy albo na osiedlu (choć opisany pięcioma dodatkowymi tagami) ma taką samą funkcję. I funkcjonalność.
Nie kwestionuję tagu (dla mnie track ma określoną funkcję tak jak i path), tylko pokazuję analogię do możliwości rezygnacji z tagowania. Tym tokiem rozumowania tracki też mogą być siatką dróg dojazdowych z zakresu unclassified albo lepiej - service, do opisania accessem forestry czy agiculltural (i funkcja załatwiona) oraz odpowiednimi surfaceami. Zrezygnujmy zatem z tracków
Dla mnie jest też to oczywiste. Ale wyobrażam sobie, że za jakiś czas będzie unifikacja i residential będzie z tagiem foot=designated.
- byłby to dokładnie taki sam przypadek, jak highway=path bez dodatkowych danych (brak szczegółowszych danych o klasie/jakości drogi).
Dlaczego jeżdżenie może mieć pisiont tagów (rodzących dyskusje jak z track i trunk) a chodzenie, gdzie podział jest po wielokroć klarowniejszy, trzy - to już za dużo?