Wyświetlanie na domyślnej mapie

kocio · 2016-06-23T02:02:59.000Z

Koledzy by chcieli, żeby to było robione przez skrypt generate_road_colours.py, ale okazało się, że nikt poza Mateuszem go nie rozumie, więc czekam na jakąś, podstawową choćby, dokumentację:

https://github.com/gravitystorm/openstreetmap-carto/pull/2085
https://github.com/gravitystorm/openstreetmap-carto/issues/2080

Jeśli ktoś się w nim połapie, to chętnie się tym zajmę znowu.

wmyrda · 2016-07-05T19:35:25.000Z

cmentarze mogły by być nieco widoczniejsze. Po to mamy mapę by w gąszczu lasu były widoczne a nie się ukrywały lepiej niż kameleon http://www.openstreetmap.org/#map=14/49.7682/21.5864

dla ułatwienia chodzi o te
http://www.openstreetmap.org/way/373583343
http://www.openstreetmap.org/way/373583916

Poniżej jak dla mnie bardzo elegancki przykład jak by to mogło wyglądać
http://www.beskid-niski-pogorze.pl/szlaki/sciezki_dydaktyczne/cee_bierowka/cee_bierowka_trasy_mapa.png

kocio · 2016-07-06T23:10:29.000Z

@wmyrda:

Niestety ta poprawka z parkingami została właśnie odrzucona:

https://github.com/gravitystorm/openstreetmap-carto/pull/2171#issuecomment-230871852

A co do cmentarzy - jakie kolory proponujesz? Zauważ, że w tym przykładzie jest ciemna zieleń i czarne krzyże, tymczasem na naszej mapce mamy zieleń i ciemnozielone nagrobki, więc prosta zmiana tła może spowodować, że nagrobki przestaną być widoczne - tak samo jak sylwetki drzew (cmentarz w lesie w jednym z przykładów). Jak podasz jakieś konkrety, to wypróbuję je na bieżącym stylu i pokażę efekt.

marek_kleciak · 2016-07-07T06:03:38.000Z

Spróbuj zrobić nagrobki w kolorze: #678e6c
Czyli trochę ciemniejsza zieleń.

wmyrda · 2016-07-07T07:21:54.000Z

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

kocio · 2016-07-07T11:07:14.000Z

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:

http://maps.stamen.com/toner/#6/52.429/18.402

kocio · 2016-07-07T12:15:02.000Z

Cmentarz: #54945f
Nagrobki: #678e6c

FluxBB BBCode test

wmyrda · 2016-07-07T13:16:43.000Z

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

rowers2 · 2016-07-07T14:31:04.000Z

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.

kocio · 2016-07-07T14:51:45.000Z

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

kocio · 2016-07-11T13:00:31.000Z

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):

marek_kleciak · 2016-07-11T13:04:40.000Z

Jestem za wariantem (2).

kocio · 2016-07-11T13:10:01.000Z

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

kocio · 2016-07-13T23:45:58.000Z

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.

wmyrda · 2016-07-14T06:47:46.000Z

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ń

rowers2 · 2016-07-14T08:55:58.000Z

wmyrda:

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.

wmyrda · 2016-07-14T11:04:47.000Z

kocio:

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

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

kocio · 2016-07-14T11:21:47.000Z

@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ć.

wmyrda · 2016-07-14T11:47:48.000Z

kocio:

@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?

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.

kocio:

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ć.

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

kocio · 2016-07-14T12:13:43.000Z

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ę.