Wyświetlanie na domyślnej mapie

I wtedy w co gęściej zaludnionych miejscach mapa składa się prawie wyłącznie z nachodzących na siebie kropek z nazwami?

No to po co dodawać POI z których nie korzysta flagowa mapa? Ja tam nie widzę problemów - ponieważ POI i tak są wyświetlane praktycznie w kaflach od 17 i więcej - więc zagęszczenia kropek bym się bał. A tak mamy niby oficjalne i zatwierdzone tagi, ale na mapie nie są wyświetlane “bo nie”.
Ktoś może powiedzieć, że OSM to nie “wyświetlanie mapy” tylko, że jest to tak naprawdę baza danych - tylko wtedy może, trzeba by zmienić nazwę projektu na np. Open Street Database :slight_smile:

Do innych map i aplikacji - dobry przykład to choćby hydranty. Jeśli coś nie jest flagowe, to jest zbędne?

POI są wyświetlane nawet wcześniej, ale tylko ich część. z17 jest już zatłoczone, dlatego staram się część POI przesuwać na dalsze poziomy.

W tej chwili akurat jest na tapecie dodanie wyświetlania obiektów typu office=*, ale to też nie są wszystkie POI i szukamy sposobu, żeby chociaż kolorem kropki zaznaczyć co to może być za podtyp, a pewnie do niektórych powstaną ikony (np. pewnie dla prawników):

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

A kto tak uzasadnia? Jestem “inkluzjonistą”, ale nie widzę opcji, żeby na flagowej mapie wyświetlać wszystkie dane - to nie jest wizualny zrzut bazy. Mapa ma być przede wszystkim do oglądania, a nie do czytania.

Mapa “flagowa” jest mapą ogólną a nie specjalistyczną mapą POI.
Na osm.org masz też “flagowy” edytor iD, który ładnie wyświetla każde POI.

Może mieć dowolne zagęszczenie kropek widoczne nawet w skali kraju - wystarczy użyć do tego mapy generowanej przez overpassa.

Mało który z nich jest zatwierdzony, a nawet te zatwierdzone bałbym się nazwać oficjalnymi.
Niewiele też POI nie wyświetla się, bo padło “nie”. W wielu przypadkach nie było dyskusji lub nie było chętnego do zrealizowania ich wyświetlania.

Nie jest to też Open POI Map :slight_smile:

Witam.

Zauważyłem ostatnio, ze drogi ‘tertiary’ są teraz renderowane na biało, przez co wyglądają tak samo jak np. drogi osiedlowe. Czy to bug czy planowana zmiana? Czy według Was tak jest lepiej?

Pozdr.

To już prawie 3 lata… :slight_smile: Próbowałem za ideą Zbyszka z forum zmienić na żółto, ale nie sprawdziło się niestety:

https://github.com/gravitystorm/openstreetmap-carto/pull/2228#issuecomment-236075503

Według mnie jest gorzej, a owa zmiana jest częścią trendu spłaszczania kolorystyki w domyślnym stylu, o którym pisałem tutaj: https://forum.openstreetmap.org/viewtopic.php?pid=669807#p669807

Drogi tertiary są szersze od osiedlowych, wprawne oko dostrzeże tę różnicę.

Ciekawe, że edytor ID w trakcie edycji właściwie koloruje drogi.

Myślę, że “wprawne oko” nie będzie potrzebne. Różnicę widać “gołym okiem” :wink:

Czy własnie przypadkiem nie przyznałeś mi racji?

Mapa powinna być czytelna bez “wprawnego oka”. Jak patrze teraz na mapę Poznania, to szczerze mówiąc nie wiedziałbym, którędy jechać, a w praktyce osiedlowa uliczka z progami spowalniającymi wygląda niemal identycznie jak ulica Solna - dwujezdniowa droga stanowiąca obwodnice centrum.

A wszystko dlatego, że ktoś uznał, że w Londynie czy innym Nowym Jorku siatka dróg jest wizualnie za gęsto i trzeba coś z tym zrobić… Dla mnie jako kierowcy mapa z osm.org dawno temu przestała być użyteczna. Jedyną dobrą zmianą było wywalenie niebieskiego z autostrad, a dalej to już tylko równia pochyła.

A zielone drogi w lasach ci nie przeszkadzały? :slight_smile:

Mniej niż niewidoczne drogi primary, secondary i tertiary obecnie.

Tak sobie myślę, że po tym jak parkingi przestały tak świecić żółcią, można znów spróbować - tylko zastanowić się jak to się ma do secondary w tunelu, która jest praktycznie taka sama w kolorze. Ale ja już się za to nie biorę, bo dla mnie różnica szerokości jest wyraźna (tertiary/service/podjazd: rozróżniam je bezbłędnie na pierwszy rzut oka) i wolę ten czas poświęcić na inne problemy. Ćwiczenie dla chętnych - o tyle prostsze, że podstawowy kod już jest i nie trzeba zgadywać gdzie to zmieniać.

A co to znaczy “właściwie” - że się przyczepię sformułowania? To jego własna inicjatywa, że tak powiem, bo takich kolorów nie było na osm-carto, więc trudno mówić o wzorcu - jasnożółta droga jest faktycznie podobna do starej wersji, ale żółta była pomarańczowa, a pomarańczowa była czerwona:

http://tile.enaikoon.de/?zoom=17&lat=52.55513&lon=16.08503&layers=B

A propos kolorów dróg -jakiś czas temu zrobiłem w miarę moich możliwości (Photoshop) analizę kolorystyki dróg w różnych stylach korzystających z OSM. Styl Carto wypada na ich tle dosłownie “blado”. Byłbym za zjaskrawieniem dróg w stylu domyślnym.
Po prawej stronie pierwszej grafiki moje ulubione odcienie z całej “puli”; kolor autostrad był dla mnie wszędzie zbyt różowy, więc dodałem moją propozycję w stronę czerwieni. Niżej wizualizacje takiej kolorystyki na kilku przykładach. Wiem, że kiepski z tego “test rendering” i potrzeba o wiele więcej lokacji, ale zawsze to coś :slight_smile:





Również uważam że drogi mógłby być bardziej widoczne.

Drążąc jeszcze temat rozwiązań w edytorze ID…

Widać wyraźnie różnicę pomiędzy drogami utwardzonymi(np asfalt albo wartość domyślna) a drogami nie utwardzonymi z wartością np: surface=unpawed albo tracktype=grade2 (tracktype=grade1 jest przedstawiana jako droga utwardzona).

Zmiana kolorów dróg to był długi i burzliwy proces (polecam zwłaszcza lekturę komentarzy):

https://blog.openstreetmap.org/2015/10/30/openstreetmap-org-map-changing/
https://github.com/gravitystorm/openstreetmap-carto/pull/1736
https://github.com/gravitystorm/openstreetmap-carto/compare/v2.35.0…v2.36.0

ale w efekcie mamy teraz kod przystosowany do łatwiejszego eksperymentowania, więc zainstaluj środowisko testowe (proponuję Dockerowe, bo chyba najprościej - https://github.com/gravitystorm/openstreetmap-carto/blob/master/DOCKER.md ) i popróbuj z różnymi wartościami.

Standardowo generuje się to z automatu, żeby kolory były możliwie równo rozłożone: road-colors.yaml to dane do skryptu scripts/generate_road_colours.py , który generuje docelowy pliczek road-colors-generated.mss . Oczywiście można ominąć automat i ręcznie modyfikować road-colors-generated.mss .

Jest jeszcze narzędzie do robienia podglądów porównawczych, z którego Mateusz korzystał, ale mnie się nie udało zacząć, bo wymaga trochę programowania:
https://github.com/matkoniecz/CartoCSSHelper

Mogę jeszcze polecić niemiecki fork, który jest bardziej drogocentryczny - mam jednak do niego dystans, bo nie chciałbym, żeby domyślna mapa była przede wszystkim dla samochodów, ale bardziej uniwersalna i zrównoważona:
https://github.com/giggls/openstreetmap-carto-de

Zachęcam do takiej zabawy, może coś ciekawego z tego wyniknie? Obecny system podoba mi się bardziej niż poprzedni i nie mam z nim problemów, ale nie jestem do niego przyspawany i rozumiem, ze dla niektórych osób sprawia problemy.

Wyświetlanie nieutwardzonych dróg to temat stary jak świat (35 uczestników napisało 237 komentarzy od 2013!), ale dosłownie dziś pojawił się promyk nadziei jak to zrobić:

https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-367473979

i nawet wstępny kod do dyskusji:

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

Zasadniczo jest to podobne do obecnego sposobu wyświetlania dróg w budowie. Ja bym był za tym, żeby drogi w budowie zmienić, bo tam nie jest tak ważne, żeby każda miała widoczny typ, natomiast próby wyświetlania nieutwardzonych dróg na razie były dwie duże i zasadniczo utknęły na manowcach, więc może wcale nie warto tak kombinować:

https://github.com/gravitystorm/openstreetmap-carto/pull/2621
https://github.com/gravitystorm/openstreetmap-carto/pull/2640