Spróbuj zrobić nagrobki w kolorze: #678e6c
Czyli trochę ciemniejsza zieleń.
coś ten tag http://wiki.openstreetmap.org/wiki/Key:parking:lane na podstawie którego odrzucono poprawkę dosyć skomplikowany i trudny w użyciu i wygląda na to by się odnosił do odcinka drogi na tyle szerokiego wzdłuż którego można zaparkować, a nie do samego obszaru poza drogą (patrz zdjęcie na wiki) co nijak nie współgra z micromappingiem. Może się mylę także chętnie bym zobaczył poprawione oznaczenia dla parkingów wzdłuż tej drogi http://www.openstreetmap.org/way/263069450
Co do kolorów to mapa w takim przypadku była by czytelniejsza gdyby była choćby odrobinę bardziej kontrastowa. Gnome zwiększa kontrast dla tych ze słabszym wzrokiem by była dla nich czytelniejsza https://developer.gnome.org/hig-book/unstable/icons-design-accessible.html.en “The GNOME desktop includes a high contrast theme that make the desktop and the applications running on it accessible to users with a range of visual impairments”. Z jakiegoś dziwnego powodu w OSM uznaje się dokładnie odwrotnie, że to mało kontrastowe kolory są czytelniejsze
EDIT: Ewentualnie może cmentarze mogły by mieć http://www.color-hex.com/color/54945f
Nie wiem na jakiej podstawie moja propozycja została odrzucona - to by trzeba zapytać bezpośrednio Matthijsa. A parking:lane dla mnie ewidentnie nie dotyczy obszaru, tylko właściwości drogi.
Kontrastowe kolory są fajne dopóki jest niewiele elementów. Jak mamy ich tyle (kolory obszarów, legenda całości), to przestrzeń na mapie “krzyczy” i drobniejsze elementy praktycznie robią się niewidoczne. Słowem to jest dobre dopóki w grę nie wchodzą szczegóły i mikromapowanie. Wystarczy pomyśleć, do czego można wykorzystać czarno-biały (maksymalny kontrast) motyw Toner, a kiedy jego użyteczność się kończy:
Cmentarz: #54945f
Nagrobki: #678e6c
No nie powiem kolor cmentarza co najmniej średnio wygląda do reszty, rzec by można totalne bezguście 
Tak sobie myślę, że na zbliżeniach z>16 nawet małe cmentarze widoczne są dość dobrze i w zasadzie tam nie ma co tam zmieniać. W wątku o kolorach obszarów który przytoczyłeś mowa jest o tym, że ważniejsze jest by uwypuklić mniejsze elementy mapy ciemniejszym kolorem na jaśniejszym obszarze. Jest to dokładnie to co ja doświadczyłem podając swój przykład na z14. Przy tym zbliżeniu ten konkretny obszar staje się na tyle mały, że nie mieści się na nim nawet jedna tarczka nagrobka przez co zlewa on się z lasem. W Berlinie - mieście otoczonym obszarem residential a nie lasem - jak na twoim zdjęciu http://www.openstreetmap.org/#map=14/52.4767/13.4158 , gdzie te obszary są również większe tego problemu nie ma.
Pytanie czy da się podbić nieco kolor cmentarza na z14/15 w obrębie lasu czy też na jego stycznej a najlepiej jeszcze tylko poza granicami miasta
Może przy z14/15 małe cmentarze powinny być reprezentowane ikoną? No ale w niskich zoomach obowiązują tylko kolorki.
Ikony to lotnisko od 13, szpitale od 15, kościoły od 16-tego.
Czy rezygnacja z wszystkich ikon gdy obszar zabudowany wypełnia cały obszar monitora, ma służyć czytelności mapy to nie wiem.
Taka eliminacja ikon może ma sens na dużym ekranie ale ikony mają zrobić mapę czytelną i przyśpieszyć wyszukiwanie a to ma znaczenie podczas podróży gdzie ekran smartfona zawiera niewielki wycinek miasta. Zatem aby znaleźć jakieś obiekty trzeba przeglądnąć kilkanaście lub kilkadziesiąt ekranów telefonu.
Oczywiście zdaję sobie sprawę, że style mobilne przesuwają poziom ikon o1-2 zoomy, ale nie wiem dlaczego ktoś boi się przeładowania ikonami na stylu stacjonarnym. Tu dobrym przykładem jest nasza osmapa, która np. kościoły renderuje dużo lepiej , bo aż o 3 zoomy wcześniej niż styl podstawowy. Na osmapie na 13 zoomie jest jeszcze dużo miejsca na ikony nawet na starówkach .Zresztą ikony na 12 czy 13 zoomie nie muszą być tak czytelne jak na wyższych zoomach więc mogłyby być mniejsze ale wykorzystywać całą paletę barw i nasyceń a nawet składać się z połączenia dwóch kolorów, bo mózg ma pewną właściwość pokazywaną niedawno na discovery że dodaje sobie brakujące czy niewidoczne części.
Na starych mapach cmentarze były czytelne dzięki krzyżykom.Nie wiem czy to miało związek z chrześcijaństwem ale jeśli, to przecież cmentarze otagowane inaczej niż chrześcijańskie mogą się renderować inaczej.Krzyżyki w małych zoomach układają się w siateczkę zatem są czytelne nawet gdy są mikroskopijne.
Całe zamieszanie z zielonymi kolorami wzięło się z niepotrzebnego renderowania trawników, łąk, pastwisk itd.,które jeśli już muszą być zielone to mogłyby być ledwo widoczne.Zieleń powinna służyć do stopniowania wysokości roślin czyli im starsze lub wyższe tym zieleń ciemniejsza.
Czy na 13-tym zoomie są potrzebne ikony na lasach?
Na sadach ikony są niewidoczne nawet na 14-tym zoomie a ikony scrub są wyrzucone z 13 zooma.
Trawę renderowałbym dopiero na 15 lub jeszcze później, to na niskich zoomach byłaby większa mozliwosc manewru.
Nie widzę też powodu aby nie podbijać nasycenia cmentarzy na tych zoomach gdzie ikony stają się nieczytelne a ustawić zgodne z legendą na zoomie praktycznym do czytania treści cmentarza.
Można też na niskich zoomach dawać kontrastową cienką obwódkę, która by przyciągała wzrok i zachęcała do powiększenia obiektu aby sprawdzić czym ta część lasu różni się od pozostałych.
W tej chwili nie mamy mechanizmu rozróżniającego otoczenie obiektów - nie mamy jak stwierdzić, czy to np. w mieście, czy w lesie. Natomiast znalazł się jeden chętny, który testuje takie możliwości:
https://github.com/gravitystorm/openstreetmap-carto/issues/1957#issuecomment-226950761
Wraca sprawa żółtych tertiary w nowej odsłonie, bo pojawił się człowiek, który radzi sobie z tym kodem. Teraz mamy dwie opcje - propozycja Zbyszka, czyli dodajemy ręcznie jeden kolor i tyle, a także nowe rozwiązanie, w którym dodajemy tertiary do skryptu generującego kolory dróg.
W pierwszej opcji jest prościej, ale za to różnica między secondary i tertiary jest mniejsza niż między pozostałymi kolorami (czyli najtrudniej je rozróżnić). W drugiej kolory dróg są równomiernie rozłożone i łatwo rozróżnić je wszystkie, ale za to zmieniają się wszystkie kolory pośrednie między motorway a tertiary (najbardziej secondary), czyli robi się znów mała rewolucja, wymagająca szerszej dyskusji.
Na tym obrazku jest kolejno: (1) bieżąca sytuacja, (2) propozycja Zbyszka, (3) proste dodanie tertiary do skryptu i (4) nowa propozycja (skrypt, ale nieco podkręcony).
I przykład nowej propozycji z widocznymi primary/secondary/tertiary (to jest ten obszar):
Jestem za wariantem (2).
Ja na razie też - musiałbym zobaczyć więcej zrzutów z różnych miejsc, żeby wyrobić sobie zdanie o tej nowej.
Można się włączyć do dyskusji tutaj:
https://github.com/gravitystorm/openstreetmap-carto/issues/1974
Na razie został przygotowany PR z wyczyszczonym kodem i łatwiej będzie sobie zmieniać kolory dróg:
https://github.com/gravitystorm/openstreetmap-carto/pull/2220
Nowa wersja stylu (v2.41.0) właśnie się wdraża na serwerach:
https://lists.openstreetmap.org/pipermail/talk/2016-July/076381.html
https://github.com/gravitystorm/openstreetmap-carto/compare/v2.40.0…v2.41.0
Najbardziej widoczne zmiany to inny, jasny kolor stadionów, bardziej jednolity styl wyświetlania nazw POI, wyświetlanie wzorka w parkach dla psów i wyświetlanie obelisków (tak samo jak monumentów). Z rzeczy niewidocznych - w kodzie są już zmiany ułatwiające zmiany kolorów dróg.
WTF dog_park na domyślnej mapie??? To ja poproszę landuse=religious którego jest dwa razy więcej wystąpień i bez którego szereg terenów w centrach miast to białe plamy oraz landuse=plant_nursery z trzykrotnie większą ilością wystąpień
Nie sprawdzam ile jest wież i masztów.
Od średniowiecza podstawowymi obiektami na mapach były wieże (wtedy głównie kościołów) i dominujące szczyty.
Potem do tego dodano rzeźbę terenu i brody (u nas brak) i nie potrzeba było do tego poziomic a wystarczyło kreskowanie, a mimo jednego koloru (tego od Forda) na mapach było więcej istotnych treści niż dziś.
Ktoś na “górze OSM” zadecydował, że OSM nie ma być mapą, a programem, czyli głównie nawigacją.
Wiadomo, że urządzenie nawigacyjne ma GPS, więc mapa jako taka do orientowania się w terenie na podstawie dominujących w krajobrazie elementów jest “zbędna”.
Tymczasem obecne urządzenia nawet z GPS bardzo źle się sprawują do orientowania azymutu, więc orientuje się głównie do odcinka drogi, a gdy ta kręta to jest to kłopotliwe.
Na rozmaitych węzłach komunikacyjnych, im są większe tym więcej mają wylotów i tym bardziej pozakręcane zjazdy. Używanie tam OSM przy wyłączonej nawigacji powoduje takie problemy, że pieszy zdąży wyłapać błąd, ale rowerzysta nie mogący się swobodnie poruszać po drogach szybkiego ruchu gdzie musi się szybko z nich ewakuować, ma do dyspozycji głównie astronawigację na słonce. Te 21 czerwca jest ok 60 stopni dalej niż o innej porze roku. Jeśli zjazdów z węzłów i leżących przy nich minirond dla ruchu lokalnego jest więcej niż 4 to dopiero po chwili można się zorientować do złego kierunku jazdy. Dodatkowo widoczność przesłaniają wysokie nasypy.
To głupie jest, bo przy takich węzłach z reguły stoją maszty GSM i są najlepszym drogowskazem (lepszym niż słońce za plecami) .
W terenie górskim lekko pofałdowanym, maszty umieszczone średnio co 2-3 km leżą w idealnych odstępach od siebie aby w zasięgu wzroku były 2-3 (lub jeden z nich), zaś do najbliższego było 1-2 km. Właśnie te odległości korespondują z typową częstotliwością spoglądania na mapę przez pieszych i rowerzystów, a im dłużej taki maszt jest w zasięgu wzroku tym rzadziej trzeba spoglądać na mapę dla utrzymania kierunku czy orientacji swego położenia. Zatem są elementy o decydującym znaczeniu na mapach w przeciwieństwie do setek np. POI, które wyszukujemy sporadycznie i zwykle po zatrzymaniu, zatem mając więcej czasu rzadziej popełniamy błędy.
Związany z tym temat to zmiana generowania napisów wraz ze zmianą orientacji mapy. Niestety temat dla mnie nieznany i nie wiem czy są sensowne rozwiązania, natomiast ja coraz częściej rezygnuję z OSM do szybkiej orientacji i korzystam na powrót z map papierowych. Tracę nadzieję, że OSM będzie mapą tzn. korzystanie z niej będzie równie łatwe co z map papierowych, a na ekranie zobaczę dane dopasowane do skali mapy i prędkości poruszania się. Dziś rozmiary 3-4 calowych smartfonów pozwalają na wskazanie gdzie się znajdujemy ale już nie pokazują co interesującego mijamy a wychodzi poza ekran.
Wynika to z wielu błędów np. nadmiaru ikon, niedopasowania rozdzielczości ikony w px w zależności od zooma, zrównania dupereli z ważnymi pod względem atrakcyjności obiektami itd.
Szkoda nawet gadać.
Nie ma miejsca na zamek czy wieże, a jest na każde drzewo.Czekam na render latarni ulicznych, koszy na śmieci i dekli studzienek ulicznych.
To te problemy decydują o popularności OSM.
Ograniczenia każdy rozumie ale w znaczeniu, że przy tylu zoomach ograniczeniem powinien być tylko czas wdrażania.
Natomiast nikt nie rozumie kierunku rozwoju czyli wolnego tempa wdrażania zmian przy tłumaczeniu, że wszytko się nie zmieści.
W tej sytuacji smuci, że tyle energii poświeca się na walkę z omijaniem ograniczeń co często mylnie nazywamy mapowaniem pod render.
To jedynie przerabianie nawigacji na mapę OSM, bo to nie ograniczenia techniczne są problemem a chyba to, że interfejs i render robią informatycy, a ci zwykle mają mały kontakt z naturą i nie bardzo wiedzą do czego używa się map.
Wniosek ,OSM coraz bardziej będzie z mapy zmieniać się w program, bo co widać nawet po dyskusjach, informatykom nie przeszkadza że po 12 latach brak większości budynków a ważne dla nich aby np 2 budynki nie wchodziły na siebie na 10-20 cm.
Czy budowle z cementu lub kamienia typu nadbrzeża, tamy, jazy, schody, groby, pomniki, postumenty, rampy, platformy itd., jeśli mają się renderować jako obiekty pokrycia terenu co oznacza głownie bariery lub elementy widoczne (do orientacji), to mogą być tagowane najbliższym tagiem building, czy lepiej niech będą białą plamą aby nie psuć statystyk budynków, których nie ma, bo są psu na budę.
Systematyczne komplikowanie tagowania, nadmiar linii np na wioskach zbyt wiele landuse=residential sklejanie obiektów i nadużywanie relacji prowadzi do robienia takich “ażurów” że nawet doświadczeni maperzy psują gdy chcą zmienić jeden element.Tymczasem OSM jest proste jak tradycyjne malowanie mapy pędzlem, gdzie małe maluje sie na dużym. Widziałem wczoraj malutkie landuse=residential (kwartał w mieście) edytowane ponad 100 razy a jakiś maper jeszcze to dzieli na mniejsze.Skończy się chaosem linii jak przy podkładach geodezyjnych gdzie infrastruktura naziemna powoduje, że trudno sie połapać w infrastrukturze nadziemnej.
Na koniec prosty przykład.
Ważne POI nie renderuje się jako node gdy name dodane jest do punktu adresowego (i innych node). Nie do rozwiązania prawda?
Albo częste stosowanie landuse=school co jest wszak intuicyjne itd.
Jakiś kod w OSM to wygląda, że jednak jest już teraz. Patrząc na grubość strumienia to ewidentnie te w lasach są grubsze niż poza nimi na z13/z14 http://imgur.com/3WUhJ7A mimo, że ani ten biegnąc obok czerwonej linii jak i żaden z tych lesie nie ma żadnych innych wskazań co do szerokości obiektu
Tak swoją drogą to grubość strumieni powoduje, że mapa wygląda jak pajęczyna na z13 http://www.openstreetmap.org/#map=13/49.7161/22.5017 Połowa tej grubości by wystarczyła. O ile dobrze pamiętam to chyba kiedyś pisałem, że wyglądają jak by miały być szerokości drogi
@wmyrda: a czemu nie, skoro znalazł się ktoś, kto wymyślił dla dog_park coś, co jest sensowne i nie powoduje konfliktów z innymi rzeczami?
Masz słuszne postulaty - wyświetlanie landuse=religious oraz innych takich terenów jest w fazie dyskusji (https://github.com/gravitystorm/openstreetmap-carto/issues/2087), tylko problem jest trudniejszy i nikt jeszcze nie wymyślił wystarczająco dobrego rozwiązania, a jesli chodzi o landuse=plant_nursery, to nawet jeszcze nikt nie zaproponował że to jest potrzebne, a tym bardziej jak to powinno wyglądać.
Generalnie to zgadzam się z tym, że jeśli dany obiekt nie konfliktuje z innymi to nic nie stoi na przeszkodzie by się na mapie znalazł, ale zbyt dużo razy słyszałem, że dany element nie pasuje na główną mapę widoczny powinien być jedynie na stosownej mapie tematycznej by coś tak abstrakcyjnego i rzadkiego nagle nikomu nie przeszkadzało i widoczne być powinno. Mnie te dwie wizje wzajemnie się wykluczają i nie bardzo rozumiem regułę która powoduje że niektóre obiekty jednak trafiają na mapę a inne nie.
Podając propozycję myślę, że takie obszary mogły by być w kolorze pola uprawnego i mieć tak jak las ikonki na swojej powierzchni tylko zamiast drzew to konewki. Ewentualnie jakąś inną wariację jak kolor lasu i jego ikonki ale o połowę mniejsze niż normalny las. Propozycji może być kilka i to tylko korzystając z wyświetlanych już na mapie kolorów, obrazków by nie zwiększać pstrokacizny
Cokolwiek to jest ze strumieniem w lesie, to kod dla strumienia nie wskazuje na wykrywanie otoczenia:
https://github.com/gravitystorm/openstreetmap-carto/blob/master/water.mss
Na oko wygląda mi to na jakąś poświatę wokół krawędzi, która widoczna jest dopiero na kontrastowym tle, ale nie upieram się.
Cóż, reguł ścisłych nie ma i próby stworzenia ich w naszym niewielkim gronie spaliły na panewce jak dotąd (https://github.com/gravitystorm/openstreetmap-carto/issues/1630). Natomiast swoje propozycje najlepiej wrzucaj od razu tam, gdzie coś może z dyskusji wyniknąć konkretnego:
@wmyrda A dlaczego nie najprościej czyli intuicyjnie brązowe obszary z ikonkami drzewek jak na lesie lub krzakach?
Generalnie sama roślinność powinna dostać minimum 3 poziomy.
Z krzaków bym zrezygnował, skoro rendery nie odróżniają nawet lasu iglastego od liściastego a niektóre drzewa niewiele różnią się od krzaków.
Te 3 wysokości (piętra lasu) powinny dać się ze sobą mieszać np krzaki wzdłuż rowu pomieszane z drzewami. Bywa że stary las jest częściowo wyrąbany, bo dziś zostawia się część starodrzewia aby zachować różnorodność dla ptaków i zwierząt, a na wyrębie sadzi się małe sadzonki.Czyli taki poprzerzedzany las różnokolorowo lub w zależności od otagowanego tagu w %, różne wypełnienie ikonkami dużych drzew i tych ptaszków ze scrub.
Dziś nie mamy rozróżnienia między lasem 15-25 letnim gdzie tyczkowina tak gęsta, że trudno się poruszać, a przepięknymi borami z ponad 80 letnimi drzewami. Na mapach wojskowych podają grubość pni, gatunek i typowy rozstaw drzew, więc kolorystyka może być tam skąpa.
Nie rozumiem dlaczego zielonego nie można zarezerwować tylko dla drzew i połączyć 3-4 odcieniami aby zaprezentować wiek/wysokość a poszerzyć render o różne ikonki. No chyba lasy są tak powszechne że mogłyby dawno doczekać ikonek iglaste/liściaste/mieszane a jeśli nie kolor to same ikonki mogłyby swą wielkością demonstrować rozmiar i rozstaw drzew i nie musiałoby to dotyczyć wszystkich zoomów.
Dalmierze kosztują już od 40-50 zł a i bez nich z map leśniczych można poznać wiek czy wielkość drzew na każdej działce, bo leśnicy mają systematyczne inwentaryzacje do pomiarów ilości drewna, więc dlatego mają małe działki aby szacunek był wiarygodny i po części robiony automatycznie bo wiadomo w jakim tempie zwiększa się obwód każdego gatunku.
Na mapach leśników dostępnych zdaje się online, jest nawet procentowy udział głównego gatunku na danej działce, więc mielibyśmy frajdę z kolorowania lasu w oparciu o wiarygodne dane
To by była nowa jakość dla OSM gdzie rzut oka na mapę pokazywałby, który las jest stary, gdzie są białe lasy brzozowe czy czerwone bukowe.
Po co marnować jeden odcień zieleni na łąki leśne? Dla mnie mogą być białe.
W pracy mam styczność z ludźmi którzy potrzebują krótkich zwięzłych komunikatów i do rzeczy jak w wojsku co zauważam przynosi najlepszy skutek. Nie przywykłem do rozwlekania tematów na takie elaboraty jak w tym wątku gdyż to rozmywa problem na wiele aspektów niekoniecznie równie istotnych. Dlatego ograniczam się do krótkiego przedstawienia konkretnego problemu, ewentualnie prostej propozycji jego rozwiązania i liczę że wystarczy to by problem odnalazł rozwiązanie w kodzie. Oczywiście mógłbym do tego ograniczyć się na githubie, ale rozdrabnianie się w detale i bronienie konkretnych wizji na milion sposobów to nie dla mnie…