Raport: Kiedy mapa staje się gęsta

Po kilku tygodniach mapowania centrum Poznania w zeszłym roku, następnie obrażeniu się na OSM , powrocie do mapowania w czerwcu tego roku i kolejnych kilku miesiącach rysowania skończyłem moje prace nad dzielnicą Stare Miasto.
http://www.openstreetmap.org/relation/1849136

Przez ten czas spisywałem wszystkie moje uwagi co do wyświetlania na głównej mapie, z czym chciałbym się z Wami podzielić i podyskutować. Kolejność przypadkowa, ale pogrupowałem to żeby było wiadomo gdzie w czym problem. Uwagi do projektu area:highway przedstawiłem w osobnym wątku, więc tutaj nie będę już o tym pisał.

  1. **Bałagan tagowy **(w bazie OSM jest już tyle tagów wychodzących z różnych grup obiektów, że nawet osoby mapujące po kilka lat się w tym gubią, lub nie wiedzą o istnieniu części tagów, dlatego wypadałoby zrobić na tym etapie inwentaryzację i porządki):

    a) tagi tunnel i covered można by połączyć do grupy covered ponieważ “pokrycie” obejmuje też i tunele, co uprościłoby sprawę
    b) tagi landuse i natural oraz część tagów z grupy leisure połączyć do jednej grupy zawierającej fizyczne pokrycia terenu
    c) tagi z grup traffic_calmig i bridge:support spokojnie mogłyby być w grupie barriers (a traffic calming też w area:highway)
    d) w specyfikacji area:highway z tego co pamiętam jest przewidziany tag dla mostów, to dobrze, bo obecnie używany tag man_made przeznaczony jest raczej do przypadków beznadziejnych, niepasujących do żadnych innych grup i w tym wypadku jest nieintuicyjny

  2. **Hierarchia wyświetlania **(czasem nawet w miejscach “płaskich”, jednowarstwowych pojawia się problem z wyświetlaniem i czytelnością mapy , natomiast tam gdzie dokładnie zmapuje się kilka warstw przestrzeni - np. okolice mostów i tuneli - to już kompletny chaos i tragedia):

    a) mosty proponuję wyświetlać jako ciemny prostokąt, który w przypadku zmapowania też na moście obszarów chodników, dróg, wysepek itp. (wszystko to z tagiem layer=1) zamieni się w ciemny obrys kształtu mostu, który działając niczym rentgen nakładające się rzeczy z niższym tagiem layer będzie wyświetlał jako półprzezroczyste - nie mam możliwości sprawdzenia tej propozycji na wizualizacji ale myślę że takie rozwiązanie powinno rozróżnić poszczególne warstwy
    b) to samo z tunelami ale jakby…odwrotnie, tzn. zaznacza się obiekty położone niżej tagiem layer=-1, a obrys tunelu to lekka linia przerywana, natomiast tak jak w propozycji na mosty, obiekty położone niżej w granicach tunelu wyświetlałyby z półprzezroczystością
    c) budynki oznaczone jako roof również dla porządku powinny być półprzezroczyste (takie ich odróżnienie od normalnych budynków jest chyba najlepsze), to samo rozwiązanie nadaje się do tagów covered=arcade i colonnade, gdzie obecnie po wyrysowaniu chodnika pod arkadą budynek w tym miejscu “znika”
    d) to wiąże się z nielogiczną hierarchią chodników i deptaków nad częścią obiektów:
    -budynkami (to budynek jest na chodniku a nie odwrotnie, więc taka też powinna być hierarchia rendera)
    -wiatami przystankowymi (i resztą obiektów z grupy amenity=shelter, -||-)
    -pomostami (są takie przypadki kiedy np. na chodniku jest pomost pozwalający wejść na fontannę)
    -barierami (to chyba mój ulubiony absurd OSM i cytując klasyka “szkoda strzępić ryja”)
    e) landuse=residential wyświetla się nad landuse=meadow, co jest absurdem, bo ten pierwszy tag przeznaczony jest do obszarów umownych, a drugi do fizycznych, czyli takich których granice można bez problemu wyznaczyć (dlatego nie powinny być w jednej grupie o czym pisałem w części o bałaganie tagowym)
    f) wśród tagów prezentujących roślinność itp. hierarchia też powinna być naturalna, czyli w uproszczeniu trawa<polana<las (a spotkałem się z przypadkiem gdzie las na polanie wyświetlał się tylko za pomocą ikonek bez koloru)
    g) obecnie kampusy (chyba pod taką nazwą to funkcjonuje i nie chodzi o tylko o kampusy studenckie, ale rozmaite zbiory obiektów, np. Szkoły, centra sportowe, obszary przemysłowe, szpitale) są renderowane jako żółta lub fioletowa podkładka, jednak w dobie rysowania wszystkich chodników, trawników itp. Takie oznaczenie ginie i na wierzchu zostaje tylko napis, więc te “podkładki” powinny stać się “nakładkami” na zespoły obiektów
    h) to samo tyczy się obszarów muzeów, przy czym w ich przypadku obecnie nie jest wyświetlana nawet podkładka
    i) po dodaniu na terenie cmentarza pomników (nie grobów) jego nazwa ginie, a to cmentarz jest nadrzędny względem pomników, tak więc na mniejszych zoomach on powinien mieć pierwszeństwo
    j) pomosty nad obszary wód, nie zawsze jest to przewidziane (np. Przy landuse=reservoir)

  3. Kolorystyka, kształty itp.

    a) rozróżnienie wyświetlania grass, meadow i garden, to zupełnie inne pokrycie powierzchni a na mapie jest ujednolicone, co - używając OSM w terenie - może doprowadzić do nieprzyjemności
    b) należałoby zgrać między sobą wszystkie występujące na mapie odcienie zieleni, pochodzą one z innych grup, dlatego np. zielenie z landuse są z zupełnie innej parafii niż te z leisure, co na jednej mapie nie wygląda za dobrze
    c) po pewnych zmianach linie highway=path, footway i track niepotrzebnie pozmieniano, path (czyli wydeptana dróżka) nie różni się niczym od otwardzonego chodnika, natomiast w track rozróżniono tracktype, problem w tym że rozróżnienie to jest raczej niepotrzebne i zmniejsza czytelność, a drogi bez tego tagu byłoby lepiej renderować tak jak obecnie renderowany jest tracktype=grade3 (jakość pośrodku)
    d) obszary fontann powinny być renderowane jako woda a nie tylko ikona, i tak ludzie obchodzą to tagując fontanny jako landuse=reservoir
    e) tam gdzie coś jest obszarem i posiada tag surface=wood lub material=wood mogłoby być renderowane jako wzorek (pattern) drewna, to często ułatwiłoby poprawną interpretację treści mapy
    f) pomosty z racji na to że w większości przypadków są z drewna domyślnie mogłyby być renderowane jako drewniane
    g) zepsuto wyświetlanie stadionów i trybun (leisure=stadium), było dobrze, ale z nieznanych mi powodów z mocnego zielonego zmieniono to na żółty tak jasny, że prawie niewidoczny i w tym przypadku nieintuicyjny
    h) propos stadionów fajnym rozwiązaniem byłoby rysowanie na boiskach wzoru w zależności od tagu sport, takie coś funkcjonuje już na mapie 3D F4 i wygląda bardzo sympatycznie
    i) bardziej jaskrawsze wody “unowocześniłyby” wygląd mapy, jest w tej kwestii już bilecik nad którym pracuje Kocio, trzeba to cisnąć dalej

  4. Brak wyświetlania:

    a) ruins=yes (powinno dodawać jakiś efekt na zniszczone obiekty, np. pattern drobnych czerwonych kresek lub chropowatość, tak żeby było widać że obiekt jest opuszczony/ zniszczony)
    b) pomniki jako obszary (obecnie wyrysowanie dużego pomnika jako obszaru daje dziurę w mapie, może takie obszary lepiej wyglądałyby jako lekki pattern marmuru)
    c) traffic_calming=island (to pewnie wcześniej czy później zostanie rozwiązane wraz z area:highway)
    d) amenity=fitness_station (czyli osiedlowe siłownie, w terenie jest ich sporo a na mapie brak, zarówno jako obszary i ikonki)
    e) amenity=waste_disposal (śmietniki, zarówno jako obszary i ikonki)
    f) amenity=vending_machine (biletomaty, paczkomaty, automaty parkingowe, chociaż w przypadku tej grupy kwestią dyskusyjną jest czy powinny być wyświetlane)
    g) tourism=artwork jako linia (dokleiłem ostatnio do krawędzi budynku linię z informacjami o muralu namalowanym na jego scianie, niestety wtedy oznaczenie dzieła sztuki znika z mapy)
    h) amenity=outdoor_seating (brak ikonki i renderowania obszarów, podobnie jak w przypadku pomostów, zaznaczone jako obszar mogłyby mieć domyślnie wzorek drewna z których wykonana jest większość “ogródków piwnych”)
    i) barrier=wall i retaining_wall jako obszary (obecnie tak samo wyświetla się zamknięty dookoła mur, jak i obszar grubego muru z tagiem area=yes, co może wprowadzać w błąd)
    j) advertising=column (słupy ogłoszeniowe)

  5. JOSM:

    a) brak narzędzia przyklejającego obszar do obszaru przesuwając tylko wzdłuż niego mysz (dokładne mapowanie wymaga często sklejania ze sobą obszarów, takie narzędzie znacznie przyspieszyłoby pracę)
    b) relacje multipolygon (uważam że sposób w jaki przedstawione są w JOSM wielokąty złożone jest źródłem wielu problemów, szczególnie wśród mniej doświadczonych użytkowników, sekcję realcje zostawiłbym dla wszystkich innych relacji typu szlaki turystyczne, linie komunikacji miejskiej, sieci obiektów itd. zwykłe kształty tam nie pasują, a gdyby zostawić je tylko w sekcji “Geografia…” i dodać tam funkcję strzałki z rozwijaniem listy wszystkich członków outer/inner kształtu ułatwiłoby wielu ludziom ogarnięcie wielokątów złożonych

Jako ciekawostkę dodaję fakt że spisałem sobie też wszystkie te miejsca gdzie mają miejsce remonty lub ortofoto jest już nieaktualne, więc po jego aktualizacji będę odrazu wiedział do których miejsc trzeba wrócić. Jeśli poza tematem listy moich propozycji macie jakieś pytania o sposoby mapowania, lub uwagi co do prawidłowości edycji to dawajcie :slight_smile:

Polecam ten PlugIn:
http://wiki.openstreetmap.org/wiki/JOSM/Plugins/ContourMerge

Mapowanie trawy na OSM jest poważnym błędem.
Trawa jest tak wszędobylska że równie dobrze można by mapować ziemię, kamyki, beton.
Trawa nie jest żadną barierą ani nie niesie żadnej informacji np. co do zagospodarowania terenu.Trawa rośnie na drogach i tam może przeszkadzać a jej nie mapujemy.
Trawa nie tylko zabiera zielony ale czyni mapę nieczytelną bo maskuje ważne elementy jak roślinność średnią i wysoką.
Mnożenie zielonych obiektów przy tak małej palecie odcieni zielonych prowadzi do absurdów.Wprawdzie w miastach można malować trawniczki ale to zabiera czas i powoduje że trawniczki stają sie ważniejsze niż drzewa, skalniaki, żywopłoty, parki.
Malowanie trawy w terenach górskich to bujda, bo tam co jakiś czas sie orze a potem pozostawia jako łąkę czy nieużytek
Po co malować polanki leśne? W czym przeszkadza biały kolor?
Jak patrzę na niektóre tereny to mnie mdli od tych zawijasów w rozmaitych odcieniach zieleni
Co do zasłaniania się wzajemnie landuse to chyba popełniasz błąd bo zwykle mniejszy poligon zasłania większy
Co do kłopotów ze znalezieniu właściwych kluczy gdy znamy wartości to można by to naprawić wrzucając np wszystkie poligony do landuse lub przerobienie JOSM aby do wartości wyszukiwał właściwy klucz.Porobiono jakieś leisure i natural aby np mały poligon nie leżał na dużym mając te same klucze. Można by zarezerwować landuse dla poligonów a leisure może pozostać dla node.Wydłużenie listy nie byłoby problemem gdyby tagi były tłumaczone na języki narodowe to nowi chętnie by korzystali z JOSMa i szybko uczyli sie palety obiektów. Zły rendering mostów gdy drogi nan im rysujemy liniowo to kompromitacja OSM. Po to jest layer aby dla każdej warstwy nadać poziom. A tak to walidadory krzyczą a render kreśli 3-5 równoległych mostów.

Piszesz o renderowaniu daszków a przecież nie renderujemy zamków, pałaców, dworów. Nie rozróżniamy kolorem ikon obiektów odrestaurowanych od zrujnowanych. Zabytkowych kościołów od zwykłych
Render ruin jest archaiczny bez uwzględniania klasy obiektów zatem i Koloseum i kurnik renderuje się tak samo.
Po co dyskutować i wskazywać detale skoro trzeba jasno powiedzieć że OSM to mapa drogowa i nikomu nie zależy aby upodobniła się ona do map papierowych gdzie render ważnych obiektów jest zoptymalizowany.

Maperzy muszą dostać możliwość decydowania o osadzeniu napisów a być może o ich wielkości, kolorze, przezroczystości czy skosie.

Jakoś nic nie piszemy o rzeczach najistotniejszych czyli konflikcie adresów z ikonami czy name.
Ikony pojawiają się nagle a powinny na mniejszych zoomach być zasygnalizowane kropkami.To samo z name czy atrakcjami.

Obiekty powinny być podzielone na nieistotne z punktu widzenia podróżnika w ruchu, jak i na te które należy uwypuklić.Czyli np sklep spożywczy powinien się renderować przed sklepem wędkarskim czy stomatologiem.Należy czerpać z doświadczeń setek lat kartografii a my mając tyle zoomów nie potrafimy dogonić map papierowych.
Jak tu nie zauważać celowego działania?

no tak, ale nie ma co zaklinać rzeczywistości. landuse=grass występuje w bazie danych ponad dwa miliony razy.

Co do reszty uwag to zgoda: przygotuj listę, co byś widział na jakim stopniu zoomu, przedyskutujemy to wspólnie z uwagami Tomka i innych kolegów a potem zrobimy głosowanie.

Wyniki możemy najpierw zrealizować na Osmapie.

Co do określenia że rendering jest gdzieś porażką:
Kolega Mateusz Korniak bardzo się napracował by coś w ogóle ruszyło.
Należy mu podziękować, bo mapa jest teraz lepsza.

Potraktujmy tą dyskusję jako kolejną rundę ulepszeń po prostu.

@Tomasz_W
Generalnie się zgadzam niemalże w pełni. W szczegółach to w zasadzie kwestia użycia kolorów jak różnice zielony/zółty przy stadionach. W sumie to wolę obecny kolor gdyż wydaje się mnie on “mniej gryzący”.

Nie zgadzam się natomiast co do tego że kwestią dyskusyjną jest wyświetlanie amenity=vending_machine. Jak dla mnie to nie ma o czym rozmawiać. Mapa winna być klikalna i mieć możliwość włączenia widoku dodatkowych opcji domyślnie niewyświetlanych jak craft=, office= czy wspomniany vending_machine

Boli koncentrowanie się nad irracjonalnymi szczegółami jak dog_park co mnie dobiło gdzie jest cała masa innych istotnych obiektów czy obszarów ze zdecydowanie większa ilością użyć, które nie mogą się doczekać wyświetlania a są istotne jak np. landuse=religious. Inne czemu nie są wprowadzane? Mają mało użyć. Tak gdyż ludzie tagują pod render. Jestem pewien, że gdyby np. wyświetlane były stacje fitness wówczas nie było by ich 4000 a kilka razy tyle http://taginfo.openstreetmap.org/tags/?key=leisure&value=fitness_station

Generalnie to szkoda, że zaś pojawia się wątek ze spora ilością dobrych pomysłów a nie przekuje się to na efekt końcowy. Osobiście co spojrzę na mapę to mnie krew zalewa jak wyglądają strumienie. Niby ileś pracy wykonane, kod gotowy, ale kolor okazuje się jest “zbyt kreskówkowy”.

@Tomasz_W: Bardzo dużo spraw poruszyłeś, postaram się to przejrzeć w wolnej chwili. Doskonale cię rozumiem, bo ja też zaczynałem od jakiegoś konkretnego obszaru i patrzyłem na OSM jako narzędzia, żeby on się dał sensownie opisać (vide problemy z definicją baru mlecznego) i pokazać (np. brak ikonki dla delikatesów). Z perspektywy mikromapowania więcej takich problemów widać.

Na bieżąco mogę odpowiedzieć na 3 d), bo akurat sam się tym zajmowałem:
https://github.com/gravitystorm/openstreetmap-carto/issues/705

Otóż ikona jest celowo bez wody, bo nie wszystkie fontanny mają basenik, znam takie, gdzie są tylko dysze wbudowane w podłoże. Inna sprawa, że nie doszedłem do tego, jak tagować same dysze, rzeźby, baseny i reflektory należące do złożonej fontanny. Jeśli masz jakiś pomysł, to chętnie usłyszę.

W OSM nie ma ośrodka decyzyjnego, który mógłby przeprowadzić porządki.
Możesz co prawda sobie sam przeorganizować tagi, jak chcesz i je stosować. Ale nie masz co liczyć na to, że twórcy map i oprogramowania się do tego zastosują. a nikt ich do tego nie zmusi. Dla nich zmiany w tagach to tylko koszty.

2 c) - Andy Allan jest przeciwny używaniu przeźroczystości w osm-carto, a problem z budynkami i chodnikami jest na tyle złożony, że wymiękłem - w każdym razie nie ma globalnych warstw, tylko dla danego typu obiektu:

https://github.com/gravitystorm/openstreetmap-carto/issues/688#issuecomment-232675998

Można zawsze lobbować różne rozwiązania na liście Tagging, co nie jest łatwe, ale tu nie widzę w ogóle prostego rozwiązania.

2 e) - to zależy od ich wielkości: mniejszy obszar landuse jest wyświetlany na większym (nie pamiętam jak to jest gdy tylko na siebie nachodzą, a nie mniejszy się zawiera w większym).

3 a) - zielenie były ujednolicane celowo, np. tu:

https://github.com/gravitystorm/openstreetmap-carto/pull/1655

2 g) - tak, sam znam taki przypadek. Generalnie można pójść w obrysy jak w zoo:

https://github.com/gravitystorm/openstreetmap-carto/issues/1624

ale zasadniczo kłania się chyba kulawa generalizacja całego modelu tagowanie/wyświetlanie. Przy pewnym oddaleniu po prostu park powinien być pokazywany bez wszystkich obszarów trawy, podobnie cmentarz bez alejek, obszary szkół bez boisk itp. Ale w tagach nie widać, że ten trawnik należy do parku i w szerszym widoku powinien być “zniknięty”, żeby nie zasłaniał istoty rzeczy, natomiast ten drugi jest samodzielny i nie powinien znikać, bo nic nie zakrywa.

Ale z uwzględnianiem kontekstu jest problem nawet na znacznie prostszym przykładzie, czyli jeśli chodzi o inne wyświetlanie w zależności od tego, czy teren jest zabudowany, czy poza nim (bo restauracja przy autostradzie albo stacja benzynowa powinny być widoczne wcześniej niż w mieście):
https://github.com/gravitystorm/openstreetmap-carto/issues/1705
https://github.com/gravitystorm/openstreetmap-carto/issues/1957

3 h) - tak jest we francuskim stylu i technicznie to jest już możliwe (jest już Mapnik 3 na serwerach OSM), ale nie rozstrzygnęliśmy dotąd, czy to ma sens w osm-carto:

https://github.com/gravitystorm/openstreetmap-carto/issues/1126

3 c) - była propozycja zmiany wyglądu dróg dla pieszych, ale nie zyskała wyraźnej akceptacji:

https://github.com/gravitystorm/openstreetmap-carto/pull/1359

natomiast przy okazji zmiany wyświetlania dróg wyszło na to, że w praktyce nie bardzo wiadomo czym się różni path od footway:

https://github.com/gravitystorm/openstreetmap-carto/issues/1698

3 e) - ale jak wtedy byś odróżnił np. betonowy budynek od betonowego boiska?

A możnaby teoretycznie użyć tutaj is_in? W sensie, że gdyby elementom dodać tag is_in, wskazujący na park, to poniżej pewnego przybliżenia te elementy by znikały. A które to byłoby pewne przybliżenie mogłoby zależeć od wielkości parku, i.e. im większy parka, na tym niższym przybliżeniu znikają elementy otagowane is_in=park.

A nie byłoby prostszym i bardziej ogólnym rozwiązaniem, gdyby przy renderowaniu kafli, dla określonych klas obiektów liczyć, ile ich wystąpi na kaflu i na tej podstawie podejmować decyzję, czy je rysować na kaflu? Jeśli liczba obiektów danego rodzaju na kaflu jest mała, to rysujemy, jeśli większa - to nie.

Wtedy odpada kombinowanie, co jest terenem zabudowanym, a efekt pokazywania np. bankomatów wcześniej, jeśli w okolicy jest ich mało uzyskujemy automagicznie.

O ile rozumiem is_in dotyczy konkretnych obiektów, a nie typu. Ja to widzę tak, jak tag parking_aisle, który wskazuje, że to jest droga parkingowa, ale nie że jest częścią parkingu o nazwie FooBar. I o takich uzupełnieniach myślę - tudzież od razu tag typu highway=corridor (czyli wiemy, że “należy do budynku”), który pozwoli wyświetlać korytarze w budynkach znacznie później niż ogólne drogi dla pieszych, o których nic dokładniej nie wiemy:

https://github.com/gravitystorm/openstreetmap-carto/issues/2332

Dla trawników i innych obiektów w parku to może być problem wymyślić odpowiedni tag, a relacja to by było chyba za ciężkie. Musiałby chyba Mapnik dawać taką funkcję jak wykrywanie kontekstu, a może jakimś SQL-em? Tak czy owak to już poważna zabawa, bo kod osm-carto już jest ogromny i pewnie nikt go już nie ogarnia w całości.

W tej chwili mamy tylko parametr odpowiedzialny za minimalny odstęp między ikonami (jak będzie gęściej, to nie wszystkie się wyświetlą) oraz możemy uwzględniać powierzchnię (way_area), żeby móc inaczej traktować obiekty większe, a inaczej mniejsze. To chyba wszystko co mamy jeśli idzie o kontekst. Jak rozumiem to pierwsze nie wystarczy, żeby coś wyświetlić na wcześniejszym zbliżeniu, to działa tylko w bieżącym.

Wystarczy zmienić kolejność rysowania elementów w zależności do zooma. Przy małych - najpierw trawa, potem park, przy dużych - na odwrót.

O takie rzeczy to już trzeba by zapytać Mateusza albo kogoś bardziej technicznego.

Dziękuję wszystkim, którzy odpowiedzieli, a w szczególności koledze Kocio za podlinkowanie konkretnych bilecików. Cieszę się że zgadzacie się z większością moich propozycji, lub przynajmniej dostrzegacie problemy.

Po przejrzeniu kilku dyskusji pod bilecikami i ponownym przemyśleniu sprawy, dochodzę do wniosku, że najlepszym rozwiązaniem będzie powrót do pomysłu stworzenia polskiego stylu OSM (na zasadzie np. stylu francuskiego), z area:highway włącznie. Cenię swój i wasz czas, a użeranie się na Githubie z ludźmi, którzy żadnych większych zmian nie chcą będzie tylko jego stratą. Idąc tą alternatywną drogą testowalibyśmy punkt po punkcie propozycje zmian z listy i ewentualnie proponowali je do Mapnika z gotową wizualizacją.

Ostatni raz sprawa utknęła na braku serwera, nie wiem czy od tego czasu coś się zmieniło? Co Wy o tym sądzicie i czy byliby chętni do zaangażowania się w to? (głównie mam na myśli osoby już teraz zajmujące się projektami zmian, ja niestety pisać kodu mapy nie potrafię, więc zostaje mi tylko kartograficzna analiza mapy i podsuwanie uwag)