Wyświetlanie na domyślnej mapie

Nowa wersja stylu została wydana wczoraj - poza poprawką wyżej wspomnianego błędu amenity/office zmieniliśmy wreszcie ikonki źródeł, dodaliśmy obszary dla policji, straży, dworców autobusowych taksówek, zostały ukryte podziemne perony, a bramy i inne barierki, światła drogowe oraz obszar zabudowany na z12 nie rzucają się już tak mocno w oczy:

https://www.openstreetmap.org/user/kocio/diary/43902

Na serwerach OSMF wdrożenie jeszcze się nawet nie zaczęło, za to różne niemieckie forki już wyświetlają zmiany (można sobie poprzełączać skórki):

https://www.openstreetmap.de/karte.html
https://tile.iosb.fraunhofer.de

Wdrożenie v4.11.0 na serwerach OSMF ruszyło w końcu wczoraj.

Produkcyjna wersja serwera z osm-carto w postaci kontenera Dockera:

https://www.reddit.com/r/openstreetmap/comments/8i07jl/i_created_an_uptodate_docker_file_to_run_your_own/

Wypuściłem w piątek nową wersję v4.12.0:

https://www.openstreetmap.org/user/kocio/diary/44222

ale na razie nie jest ona jeszcze wdrożona na serwerach OSMF i o ile zrozumiałem może to potrwać nawet kilka tygodni:

https://github.com/openstreetmap/chef/issues/168#issuecomment-399461921

Największą zmianą jest wyświetlanie nawierzchni dróg (jeden z najstarszych bilecików i bardzo oczekiwany), ale też dodaliśmy kilka nowych typów wież, bramę miejską, wyświetlanie nazwy place=quarter (czyli brakującego elementu między dzielnicą a osiedlem), pojawiły się nazwy śluz, punkty informacyjne są wreszcie zróżnicowane i nie wszystkie wyświetlają się tak wcześnie jak dotąd, nazwy strumieni i rowów melioracyjnych wyświetlają się obok linii, a nie na niej, a schronienia są wyświetlane na brązowo, inaczej niż miejsca do noclegu - plus jeszcze kilka innych zmian.

Niemiecki fork zwykle szybko to wdrażał niezależnie od OSMF, ale tym razem Sven Geggus poczuł się zaskoczony, bo główną zmianą jest sposób wyświetlania dróg, a w związku z wyświetlaniem nawierzchni ten kod się zmienił. Chyba nawet się wkurzył, ale dziwi mnie to, bo nad tym kodem pracowaliśmy ponad rok, więc miał szansę nie tylko zauważyć, ale też się wypowiedzieć:

https://lists.openstreetmap.org/pipermail/dev/2018-June/030287.html

Psy szczekają, karawana jedzie dalej :stuck_out_tongue: Kiedy wdrożenie?

Myślę, że mając rendering unpaved można snuć bardziej konkretne plany poprawy wielu tracków, które są tak otagowane tylko z powodu nieutwardzenia, bo naprawdę są unclassified/residential.

Byłby to duży projekt, ale bardzo potrzebny. Niektóre rejony są w kiepskim stanie.

Z wdrożeniem jest jakiś dziwny problem, bo podobno jest dużo gorsza wydajność na niskich poziomach (rzędu 20x!), choć teoretycznie powinna być właśnie lepsza z powodu zmniejszenia dokładności (obszary poniżej piksela nie są uwzględniane na danym poziomie przybliżenia) i uaktualnionych indeksów:

https://github.com/openstreetmap/chef/issues/168#issuecomment-400232261
https://github.com/gravitystorm/openstreetmap-carto/pull/2874

Właśnie szukamy gdzie może leżeć przyczyna, jeśli ktoś może pomóc, to zapraszam.

Mam pytanie - czy jest planowane wprowadzenie jakiegokolwiek renderingu dla obszarów landuse=greenfield ?
W tej chwili renderuje się praktycznie większość landuse w tym te powiązane z budową w toku (construction) jak i obszary poprzemysłowe (brownfield).
Z kolei brak renderingu dla landuse=greenfield powoduje niestety często że obszary przewidziane dopiero w przyszłości pod zabudowę przemysłową są od razu zaznaczane jako industrial (bo ten obszar się renderuje), mimo że nie ma na nich praktycznie śladu jakiejkolwiek aktywności przemysłowej (a często nawet ani jednego budynku), kilka przykładów:

Takie obszary (want to be) industrial potrafią w tym stanie istnieć bez zmian od lat - jak np. tutaj :frowning:

Planów teraz nie ma. Kiedyś było wyświetlane tak samo jak tereny budowlane i brownfield, ale zostało usunięte z braku pomysłu jak powinno wyglądać - tu jest opis sprawy:

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

Moim zdaniem takie strefy nalepiej byłoby oznaczać poprzez boundary.

Natomiast nie wiem jakby miałby się renderować landuse=greenfield. Wszak ten tag dotyczy przyszłości i jest nieweryfikowalny w terenie.
Renderować się tam powinno to, co jest aktualnie - las, pole, łąka itp.

No mniej więcej ten typ obaw przewija się w przytoczonej dyskusji na githubie i drugiej pokrewnej z której przebija niechęć Mateusza do tagu greenfield w ogóle jako takiego.
O ile rozumiem wątpliwości co do charakteru tagu który bardziej określa status niż realny wymiar w terenie to nie byłbym aż tak radykalny aby uznać że greenfield to „bad tagging scheme” i że najlepiej jak by go w ogóle nie było.
Uważam że ten tag niesie ze sobą użyteczną informację choć faktycznie chyba nie powinien występować samodzielnie a raczej w kombinacji z innymi (renderowanymi) tagami opisującymi teren tak jak jest on teraz („on the ground").

Jakiś czas temu poczyniłem zmiany idące w tym kierunku po wizji lokalnej w Gnieźnie, ale co w przypadku kiedy taki teren pod inwestycje jest jeszcze np. w połowie polem a w połowie już nieużytkiem (zaroślami). Mapować oddzielnie każdy kawałek i pod to każdorazowo podpinać greenfield ? Bardziej może spinać relacją ?

Jaką wartość widziałbyś dla takiego boundary ?
Najbliżej byłaby chyba special_economic_zone ale biorąc pod uwagę statystykę taginfo nie jest to zbyt popularna wartość.
Poza tym takie boundary się nie renderuje, a co się nie renderuje to w mniemaniu wielu nie istnieje i ciężko się przebić szerzej z takim schematem tagowania …

Okazało się, że problem z wydajnością był zaszyty w kodzie do wyświetlania dróg nieutwardzonych, więc na razie ten kod został wycofany i wyszła wersja v4.12.1, która zawiera jedynie tę poprawkę. Widać jednak admini OSMF mają jakieś inne problemy, bo nadal czekamy na wdrożenie:

https://github.com/openstreetmap/chef/issues/170

I tak i nie. Klucz landuse określa obecne zagospodarowanie/przeznaczenie terenu. landuse=greenfield oznacza teren, który jest obecnie przeznaczony pod zabudowę, co wynika z obowiązującego planu miejscowego albo decyzji o warunkach zabudowy. Inaczej nie ma podstaw do stosowania tego tagu.

To, co faktycznie znajduje się na tym terenie (trawa, krzaki, drzewa), powinno być obsłużone obszaremi natural=* nałożonymi “na” landuse=greenfield.

Podobnie landuse=meadow powinien oznaczać teren faktycznie użytkowany jako łąka/pastwistko. Dla terenów po prostu porośniętych trawą jest tag natural=grassland.

Pytanie, czy na mapie ogólnej, jaką jest warstwa standardowa, powinno się renderować przeznaczanie terenu, które jest możliwe do zobaczenia tylko na planach i które pasuje bardziej do mapy specjalistycznej.

Myślałem o boundary=industrial_zone, ale special_economic_zone jest bardziej ogólne.

Widać że zainteresowanie/potrzeba widoczności na mapie głównej chyba jest, stąd też jak mniemam te wszystkie (want-to-be) landuse=industrial, gdzie na razie tylko wiatr hula :frowning:
Bo ten tag się renderuje a traktowany jak proteza pokazuje gdzie są/będą tereny inwestycyjne w gminach…

Szukamy koderów, zarówno niedoświadczonych jak i doświadczonych - Tomasz W wrzucił ogłoszenie:

https://www.openstreetmap.org/user/Tomasz_W/diary/44420

Od jakiegoś czasu przestały się wyświetlać perony na dworcu w Katowicach - https://osm.org/go/0LeVbA5t9–. Czy przestały być obsługiwane wielokąty złożone jako perony? Myślałem, że chodzi o area=yes, ale to nie to.

Pewnie chodzi o covered=yes:

https://www.openstreetmap.org/relation/4288962
https://github.com/gravitystorm/openstreetmap-carto/pull/3162

Jeśli nie cały peron jest zakryty, to wystarczy doprecyzować, np.:

https://taginfo.openstreetmap.org/tags/covered=partial

Trochę większa sprawa niż zwykle - imagico w swoim forku zaproponował zamianę koloru pól uprawnych i instytucji społecznych (szkół, szpitali itp.). Mnie to bardzo przekonuje, więc otworzyłem bilecik typu pull request z tą zmianą i z ilustracjami jak to będzie wyglądać:

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

Mnie to nie przekonuje. Obecny kolor… bardziej kojarzy się ze zbożem :wink:
Gdybyś pokazał komuś fragment nowej mapy bez kontekstu, to nie domyśliłby się, że to pole uprawne.