@marek kleciak: Marek, tak sobie pomyślałem, że skoro jesteś autorem propozycji “street area”, to może masz do niej jakiś aktualny komentarz? W sensie jakie ma mocne strony, co trzeba jeszcze przemyśleć oraz co byś chciał zrobić inaczej, gdybyś pisał ją teraz. Chętnie spróbuję ją pociągnąć, ale na razie odzewu od społeczności (a zwłaszcza deweloperów osm-carto) praktycznie nie słyszę, więc chcę się lepiej przygotować.
Komentarz jest taki:
Ludzie mapują najchętniej to, co mogą zobaczyć na mapie. Jeśli powstanie rendering uwzlędniający tą kategorię to ludzie zaczną tego masowo używać bo jest to po prostu pomocne.
Mz nadal renderujemy siatkę grafów która niekiedy musi zostać nagięta tak, by był logiczny routing, węc musimy iść na kompromisy. Przykład tutaj: http://www.openstreetmap.org/node/1274183469
Mocna strona to pryede wszystkim dokładniejsze odzwierciedlenie rzeczywistości. Mapa mająca w nazwie street akurat najgorzej odzwierciedla ulice.
Inny parszywy przykład renderingu: http://www.openstreetmap.org/#map=19/50.94114/6.96540
Most w Kolonii. Na mapie odzwieriedlany przez wiele linii kolejowych które są być rysowane oddzielnie by dobrze działał routing. Mógł by to być jeden obszar.
Cele i problemy są dla mnie całkowicie jasne, ale chodziło mi o techniczne detale propozycji - czy taka, jak napisałeś, jest twoim zdaniem gotowa do wdrożenia, czy coś z nią trzeba jeszcze trzeba zrobić zanim się weźmie za próbę renderowania?
Propozycja opisana tutaj: http://wiki.osm.org/wiki/Street_area jest w zasadzie domknięta i gotowa do wdrożenia.
Można dyskutować jedynie czy jest jakiś sensowniejszy syntaks zamiast proponowanego.
Propozycja wyświetlania powierzchni mostu wisi jako osobny bilecik:
https://github.com/gravitystorm/openstreetmap-carto/issues/612
Też się dopisałem, bo jakoś nikt się dotąd nie wypowiedział w kwestii kodu/wdrożenia, a takich obiektów mamy na świecie ponad 2 miliony…
No to rób lobbying. Z góry wielkie dzięki za to!
Marek
kiedyś padła tu propozycja żeby w przypadku chodników jako obszarów były renderowane tylko obszary, bez głównej linii, tak jak ma to miejsce w przypadku rzek i ich powierzchni - czy wie ktoś czy jest już “bilecik” w tej sprawie? a jeśli nie to czy ktoś mógłby takowy dodać bo ja nawet nie wiem jak to zrobić
ps. nikt nie odpisał mi na pytanie o mapowanie schodów kilka postów wyżej 
Tak, to ewidentny błąd. Powtórzenie ma jakiś sens tylko, jeśli schody są naprawdę olbrzymie i na końcu nich jest kilka głównych ciągów komunikacyjnych (tak jak w Twoim przykładzie o którym pisałeś “prowadzą w 2 strony”), wtedy ewentualnie można poprowadzić schody od każdego z tych głównych ciągów komunikacyjnych.
Schody: Zrobiłem proposal rozwiązujący problem o którym piszesz:
https://wiki.openstreetmap.org/wiki/User:Marek_kleciak/Stairs_modelling
A tak konkretniej, to ten fragment:
https://wiki.openstreetmap.org/wiki/User:Marek_kleciak/Stairs_modelling#Start-_and_end_line
Też czeka na implementację…
Kocio, może mógłbyś robić także tutaj lobbying?
Gorąco popieram ideę schodów 2/3D (zamiast 1D) i chętnie ją poprę ewentualnie doprecyzuję! Bilecik należy założyć na GitHubie (trzeba tylko zamieć tam konto):
https://github.com/gravitystorm/openstreetmap-carto/issues
bo nie znalazłem żadnego wcześniejszego na ten temat. @Tomasz_W: spróbujesz? Bo ja się boję, że za bardzo się rozproszę.
Marek, a ja mam jeszcze wątpliwości co do mapowania pasów na jezdniach - dopóki obszar jest stałej szerokości wszystko jest łatwe: dzielimy z automatu obszar na równe pasy i malujemy granice, ale jak się zmienia szerokość, pas się pojawia, znika, jest namalowany obszar zakazany dla ruchu tudzież łączą się dwa odcinki drogi (jeden oznaczony jako dwupasmowy, a drugi - trzypasmowy), to już zonk. Trzeba chyba ręcznie oznaczać przebieg pasów na obszarach - dobrze rozumiem?
Jest w tym kierunku specyfikacja. Po to spotykalismy sie w styczniu w Erlangen.
Hehe, bardziej parszywym przykładem są punkty poboru opłat na autostradach, gdzie na przykład jedna jezdnia rozwidla sie do dzięsięciu jezdni:
http://www.openstreetmap.org/#map=19/52.15210/18.27913
przywykłem że w miejscach gdzie ulica przecina chodnik ale nie ma tam pasów rozdzielam linię z chodnikiem do krawężników, no i chciałbym się upewnić czy aby napewno dobrze robię, bo z jednej strony wyrysowanie przez te ulice chodnika byłoby mapowaniem czegoś co nie istnieje (chociaż w miejscach bardzo słabo zmapowanych taki skrót myślowy jest raczej ok), ale z drugiej być może powoduje to jakieś problemy, np. w nawigacji rowereowej (nigdy nie używałem więc nie wiem), jeśli taka przerwa jest problemem to myślę że rozwiązaniem takiej “białej plamy” będzie za jakiś czas nieunikniowe wdrożenie “obszaru drogi”
przykład:
w terenie: https://www.google.pl/maps/@52.390256,16.979807,3a,75y,332.22h,79.67t/data=!3m4!1e1!3m2!1sAGi1ee4reS9mA7RD7dpLRA!2e0
w OSM: http://osmapa.pl/#lat=52.39026&lon=16.97980&z=18&m=ma
Moim zdaniem to naprawdę nieuniknione, ale jakoś nie widzę szerokiego poparcia w tym względzie. Na razie istnieje szansa, że przynajmniej na głównej mapie różne typy dróg pieszych zaczną być do siebie bardziej podobne i pozbędziemy się czerwonych kropek powszechnie używanych do wyświetlania chodników:
https://github.com/gravitystorm/openstreetmap-carto/pull/1327
No nie, takie nieciągłości po prostu muszą wywalać routing dla pieszych albo inny, który chciałby prowadzić po chodniku. Nawigacja opiera się na sieci połączonych dróg i węzłów.
Przede wszystkim, spróbuj pomyśleć, że footway to nie jest chodnik, tylko droga albo wręcz trasa, którą mogą poruszać się piesi. Tak samo, highway to też przede wszystkim jakaś droga, a nie jezdnia. Droga dla pieszych przekraczając ulicę nie prowadzi chwilowo chodnikiem, tylko w poprzek jezdni, ale jako droga cały czas istnieje. Analogicznie, są miejsca, gdzie stosuje się takie środki uspokojenia ruchu, że można powiedzieć, że to jezdnia na moment znika, a samochody nią jadące pokonują krawężnik, by przejechać w poprzek chodnika; mimo to nikt w takiej sytuacji nie zostawia przerw w obiekcie highway.
Na dodatek, wprowadzenie obszarów drogi nie rozwiązałoby wcale tej sprawy. Jak wspomniałem, nawigacje generalnie korzystają z liniowej reprezentacji dróg i konieczność dopowiadania sobie pewnych danych na postawie obszarów to co najmniej poważne utrudnienie.
Oczywiście, jest zagadnieniem znacznie mniej jednoznacznym, jak dokładnie rysować przejścia przez jezdnie w miejscach, gdzie nie ma żadnych oznaczeń. Potrzebne jest tu chyba za każdym razem nieco subiektywnej oceny. Są małe ulice, gdzie w praktyce przechodzi się na drugą stronę w dowolnym miejscu - tego rzecz jasna narysować się nie da. Jest prawo o ruchu drogowym, które pozwala przechodzić przez jezdnie w nieoznaczonych miejscach pod pewnymi konkretnymi warunkami. Moim zdaniem, istotna jest tu szczególnie regulacja o przechodzeniu przez jezdnię na skrzyżowaniu, nawet jeśli nie ma na nim oznaczonego przejścia. Są w końcu lokalne zwyczaje, nieraz nawet uwidocznione w terenie przez jakieś przedepty. Czy należy takie przejścia wrysowywać, jeśli ich miejsce jest niezgodne z przepisami?
W takim przypadku, jak ten, gdzie ta “ulica” nie jest chyba nawet drogą publiczną, w ogóle jednak nie miałbym oporów przed pociągnięciem liniowego footwaya przez jezdnię. W najgorszym razie łapie się na przepis o przejściu na skrzyżowaniu, choć optycznie nie rożni się to dla mnie wcale od przecięcia chodnika z wjazdem na posesję. Jeśli jednak chcesz ten dojazd pod kościół traktować jako ulicę, możesz odcinek footwaya prowadzący przez jezdnię oznaczyć jako przejście dla pieszych. Będzie to osobny obiekt z tagami highway=footway i footway=crossing. Na węźle przecięcia z highway=service dajesz dodatkowo highway=crossing i crossing=unmarked, co jednoznacznie pokazuje, że przejście dla pieszych nie jest oznaczone w terenie.
Zastanawiam się, czy jest możliwy algorytm dla rendera, który nie pozwala wytyczyć trasy dla pieszego w poprzek ulicy, poza oznaczonymi przejściami dla pieszych.
Zaś poza miastem, czyli kiedy znak pokazuje minięcie terenu zabudowanego, wytycza trasę w poprzek drogi dla ruchu kołowego w każdym punkcje najbliższym.
Zawsze myślałem że w OSM mapuje się tylko to co jest w terenie, bo im więcej miejsca na interpretację użytkowników tym więcej potencjalnych błędów, ale faktycznie jest coś takiego na Wiki więc dostosuję się 
a jeszcze co do dróg jako obszarów, widzę że przyjęło się już mapowanie dróg na stacjach paliw jako “highway=service” + “area=yes”, a szablon tagowania [ http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area#Tagging ] który prawdopodobnie kiedyś zostanie przyjęty zakłada z kolei taki sam tag dla wszystkich rodzajów dróg (i słusznie, bo już teraz zmienianie błędnych kategorii dróg jest irytujące, a gdyby do tego doszło zmienianie tagu w obszarze to byłoby 2x tyle pracy), mam nadzieję że instnieje opcja że w razie czego przeleci przez to jakaś maszynka i dostosuje tę kombinację do nowego standardu bo inaczej może się zrobić bałagan
Bardzo ciekawe ujęcie problemu - podoba mi się!
Po tym, jak niedawno przyjrzałem się uważnie koncepcji Marka (drogi jako obszary), uważam, że są to dwa uzupełniające się rodzaje danych: obszar (skala mikro) nie zastąpi linii trasowania, ale redukcja do linii przejazdu/przejścia (skala makro) całkiem gubi geometrię, a czasem nawet zniekształca trasowanie. Wniosek: potrzebne są oba rodzaje - fizyczny obszar i niefizyczne trasy, przez analogię do np. tras komunikacji miejskiej czy szlaków turystycznych, które są szczególnym przypadkiem rozdziału trasy od fizycznego przebiegu dróg.
Wydaje się to może nadmiarowym rozwiązaniem, ale:
- mamy już dużo zmapowane, dużo mapowiczów i dobre zdjęcia, więc są wystarczające zasoby do uszczegółowiania,
- algorytmy trasowania nie są proste ani jednoznaczne (stąd różne trasy z różnych serwisów), więc chyba należy po części podpowiadać przebieg tras ręcznie,
- są to inne obszary zastosowań, więc można ukrywać trasy na mapach i nie uwzględniać geometrii przy trasowaniu - nie będą się gryzły.
Ogólnie nie jest problemem zrobienie routingu po obszarach, ale musicie pamiętać, że routing obszarowy nie nadaje się do wszystkiego i jest trudniejszy w implementacji oraz obliczeniach. Ogólnie wydaje mi się, że lepiej aby obszary zostały graficzną reprezentacją terenu, a linie służyły do routingu.