Wyświetlanie na domyślnej mapie

Myślę, że dla mapy to nie jest dobry pomysł. Może i byłoby mniej “boring”, ale za to jeszcze bardziej pstrokato, a tym samym mniej czytelnie.

Litości… Taka mapa bylaby zupelnie nieczytelna. Niektorzy z tego korzystaja w praktyce :slight_smile:

oj tam, oj tam, wystarczyłoby jakieś 20% pokrycia tego efektu z obrazka żeby było to minimalnie widoczne, a znikałoby zaraz na mniejszych zoomach, więc nie sądzę żeby aż tak zawaliło czytelność :slight_smile:

edit: taka mała wizualizacja na szybko

Fajne, ale tylko pod warunkiem, że w miejscy przejścia dla pieszych będą biegały tam i z powrotem przez jezdnię krasnoludki (żeby było jeszcze mniej nudno :slight_smile: ). A bardziej serio - dlaczego wizualizacja mapy miałaby sugerować, że płaska w rzeczywistości droga jest wypukłą “rurą”? To już znacznie lepiej forsować renederowanie dla obszarów dróg (propozycja Marka) - z tego byłaby przynajmniej jakaś realna wartość dodana.

Nie widzę w tym żadnego sensu - jeśli miałoby uatrakcyjnić i się przydać, to program trasujący 3D z niskiego kąta, jak w klasycznych GPS-ach, bo daje lepsze wyobrażenie o tym, jak droga wygląda, niż mapowy rzut z góry.

na tak niskich zoomach to zdecydowanie ważniejsze jest by wyświetlany był przede wszystkim obszar drogi, gdyż przy samych kreskach nagle pojawiają się nam dziury w zagospodarowaniu terenu. Sam pomysł jednak nie głupi kwestia odpowiedniej implementacji, choć raczej widział bym go nie na głównej jak raczej na całkiem osobnej warstwie która liczę kiedyś się pojawi a będzie nam przestawiała również inne obiekty w formie mniej schematu a czegoś właśnie 2D/3D.

Tak na marginesie czemu na głównej nie wyświetlają się narciarskie trasy zjazdowe? Przecież taki obszar w wielu przypadkach pozostaje wówczas pusty a nie jest tak, że jego wyświetlanie w danym miejscu przesłoni nam zupełnie inny obszar a już na pewno nie parking czy budynek :wink:

Nie mam pojęcia, ale brzmi sensowne - możesz w tej sprawie po prostu założyć bilecik na https://github.com/gravitystorm/openstreetmap-carto/issues.

By stworzyć bilecik którym się ktoś zajmie pasowało by wpierw go dobrze przemyśleć znając szerszy kontekst oraz możliwe trasy jakie chcemy wyświetlać a tu aż takiego doświadczenia nie mam, ale pomysłów kilka mogę podrzucić :wink:
Po pierwsze ta sama trasa może służyć narciarzom w zimie a rowerzystom górskim w lecie jak choćby jest na kawałku trasy która dodałem http://www.posir.pl/przemysl-stok/pliki/mapa2010.jpg. Z kolei jeśli w lecie trasa narciarska jest nieczynna można by wyświetlać jak proponowane drogi czyli z pewną przeźroczystością co by otworzyło drogę do wyświetlania traw czy skał które wówczas będą w tym miejscu.

Osiągnął bym to poprzez renderowanie obszaru z tagami route=piste oraz sport=skiing w kolorze białym [kolor do przemyślenia gdyż na lodowcach pewnie było by to słabo widoczne]. By trasa wyświetlała się w pełni jedynie w okresie kiedy mamy sezon skorzystał bym z kolei z tagów http://wiki.openstreetmap.org/wiki/Proposed_features/temporary temporary:date_on=* oraz temporary:date_off=* gdzie pewnie można by wpisywać miesiąc otwarcia i zamknięcia gdyż pewnie daty bez roku mogły by dla rendera być mylne. Brak tagu temporary oznacza, że wyświetlamy trasę przez cały rok. Poza tym okresem wyświetlamy jako przezroczysta co z kolei mogło by umożliwić wyświetlanie np. natural=grassland jeśli ktoś w tym rejonie coś podobnego również oznaczył.

Jeśli liczba możliwych rodzajów tras była by spora a co za tym idzie również spowodowało by to niepotrzebnie dużo pracy przy wymyślaniu kolorów które niekoniecznie przeglądający stronę mogli by zrozumieć bez zaglądania w legendę można by po prostu wyświetlać je wszystkie w tych samych kolorach co np. landuse=recreation_ground co dla mnie osobiście było by wystarczające.

Można tak, ale można też podrzucić problem i omawiać go przy bileciku. Zasadniczo gwarancji sukcesu nie ma i tak, ale jak tam nie napiszesz, to prawie na pewno problem nie będzie ruszony.

Mam pytanie częściowo związane z wyświetlaniem na domyślnej mapie. Chodzi mi o mapowanie obszarów pieszych (highway=pedestrian + area=yes) i dróg pieszych (highway=footway) oraz relacji pomiędzy nimi. Widzę dwie szkoły, jedni, do których ja należę, mapują tak, że footway kończy się na obszarze pedestrian i nie przechodzi przez niego, drudzy rysują footwaye przechodzące przez przez obszary pedestrian a one renderują się (tak, nie mapujemy pod render) na obszarze pedestrian na stronie głównej, co moim zdaniem wygląda kiepsko. Pytanie brzmi, czy jest jakieś uzasadnienie, żeby rysować footwaye przechodzące przez obszary pedestrian, może jest to wymagane do jakiegoś routingu, który nie radzi sobie z obszarami? Jeśli takie działanie jest uzasadnione, to może dałoby się spowodować, żeby te footwaye się nie renderowały na obszarach pedestrian?

jeśli obszar to pedestrian (place, deptaki) to powinna przechodzić przez niego linia pedestrian, a jeśli obszar to footway (chodniki) to powinna przechodzić przez niego linia footway, a co do renderowania chodników to tu się toczy dyskusja na ten temat https://github.com/gravitystorm/openstreetmap-carto/pull/1359 i ukrycie linii na obszarze też jest przewidziane

http://osmapa.pl/#lat=52.38337&lon=16.83407&z=19&m=ma
dodałem szczegóły takie jak trawniki i obszary chodników do pewnej pętli tramwajowej gdzie pierwotnie był tylko “building=roof” i można powiedzieć że wszystko się posypało, po pierwsze nie wiem czemu mapnik renderuje wiaty tak samo jak budynki - wg mnie to powinno być renderowane np. jako półprzezroczyste budynki, a po drugie to algorytm hierarhii jest nieźle spieprzony skoro chodniki i platformy są nad wiatą

Problem urodził się kilka miesięcy temu, zdaje się wraz z uznaniem, że priorytetem domyślnej mapy są chodniki i że precz z przeźroczystością:

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

Andy Allan, czyli prowadzący osm-carto, ma chyba przeźroczystości za złe to, że robi za kolejny kolor - tu jak rzadko wypowiedział się detalicznie co sądzi na ten temat:

https://github.com/gravitystorm/openstreetmap-carto/issues/552#issuecomment-76158611

Jak poczytasz te bileciki, to widać, że te dwie rzeczy związane z oddawaniem warstw 3D na mapie 2D (narzucona kolejność warstw oraz brak przeźroczystość) psują zwłaszcza dworce - a im większe, tym gorszy efekt. Ja to zauważyłem na Dworcu Centralnym w Warszawie, ale berliński Hauptbahnhof wyszedł na tym jeszcze gorzej - jest kompletnie nieczytelny, bo ma wiele poziomów.

OsmAnd potrafi jedynie poprowadzić po obrysie obszaru. Routing przez obszar “is very hard to fix technically. Because routing engine doesn’t support routing via areas.” Brouter, świetny silnik rutujący dla pieszych i rowerzystów nie wspiera obszarów nawet po obrysach. Zatem urywanie footway na krawędzi area ma fatalne skutki. A sądząc po “is very hard to fix technically”, to sytuacja nie prędko ulegnie zmianie. O ile to w ogóle nastąpi, w zauważalnej liczbie silników rutujących.

i dlatego jestem za zwiększeniem liczby osób z większym wpływem na OSM - stwierdzi sobie taki Pan Allan że jemu przezroczystość nie pasuje i temat jest właściwie zamknięty, a w obecnej wersji renderowania tak jak w moim przykładzie chodnik lata sobie nad dachem

Właśnie tym tropem idzie moje myślenie ostatnio. Wątek z ikonkami pokazał mi nieoczekiwanie, że właściwie to pewnie nawet większość aktywnych uczestników chce czegoś (więcej ikonek do różnych POI), ale Andy akurat nie - i nawet nie dyskutuje, tylko nie wiadomo, czy warto się wysilać, skoro może to zwyczajnie olać z góry. I to nie jest kwestia tylko osobistych preferencji jednego człowieka, tylko że ten jeden człowiek jest wąskim gardłem całego ekosystemu - bo przecież domyślna mapa jest wizytówką całego OSM. No ale trzeba też uczciwie powiedzieć, że nie ma specjalnie konkurencji - ze 3-4 aktywne osoby to jednak mało: https://github.com/gravitystorm/openstreetmap-carto/graphs/contributors… Dlatego zachęcam do zgłaszania własnych bilecików i uczestnictwa w dyskusjach pod nimi, a sam próbuję się włączyć w robienie poprawek, żeby było nas więcej, a więc żeby ten podprojekt stał się zdrowszy (mniej subiektywny, bardziej społecznościowy).

Na razie największą przeszkodą wydaje się środowisko do testowania łatek - jest szansa, że za drugim podejściem mi się uda je postawić, ale to nie powinno być w ogóle tak skomplikowane, bo wiele osób sobie to w ogóle odpuści, a testowanie staje się coraz ważniejsze, bo łatwo coś niechcący popsuć na dużą skalę. W tej sprawie zresztą chyba nikt nie jest przeciw - Andy też chętnie podlinkuje w dokumentacji narzędzia pozwalające na szybkie i łatwe stawianie środowiska testowego, a Mateusz założył bilecik o skrypcie instalacyjnym:

https://github.com/gravitystorm/openstreetmap-carto/pull/1342
https://github.com/gravitystorm/openstreetmap-carto/issues/657

Nie ma jeszcze dokładnego rozwiązania, ale widać, że problem jest kluczowy i są ogólne pomysły jak się do tego zabrać, żeby było niezależne od systemu operacyjnego (Vagrant, Salt, Docker).

Dlatego chciałbym zapytać - na razie na polskim forum - komu z was takie narzędzia są potrzebne lub zachęciłyby was do poprawiania domyślnego stylu wyświetlania mapy? Chodzi o to, że jeśli takich osób jest więcej, to wystarczy się skupić nad takim skryptem i tyle - natomiast jeśli mało, to trzeba się zastanowić co jeszcze wstrzymuje ludzi przed szerszym uczestnictwem w osm-carto, bo może coś innego jest pilniejsze. Jeśli macie tego typu problemy, to też dajcie znać.

Dzięki za wyczerpujące wyjaśnienia.

jeśli chodzi o zmienianie Mapnika to ja mogę od siebie zaproponować projektowanie ikonek i wzorków (patternów), kodować nie potrafię, ale że trochę zajmuję się grafikami to może na coś się przydam :slight_smile:

Produkcję ikonek robi obecnie nebulon42. Zamówienia poczyniłem takie:

https://github.com/gravitystorm/openstreetmap-carto/issues/1402
https://github.com/gravitystorm/openstreetmap-carto/issues/1460

i część jego projektów jest w propozycjach detalicznych, część jest do obejrzenia tu:

https://github.com/nebulon42/osmic

Zasadniczo chodzi o ikonki SVG projektowane np. w Inkscape bez grupowania (wszystko w jednej warstwie) i z dopasowaniem do siatki 16x16 (żeby wektory się ładnie dopasowywały do rastra o tych rozmiarach po konwersji do PNG). Konkretne zalecenia są tu:

https://github.com/nebulon42/osmic/blob/master/CONTRIBUTING.md

więc możesz się skupić tylko na współpracy z nim bezpośrednio i dorzucać tam nowe ikonki. Pewnie najpierw dobrze by było mieć konto w GitHubie, żeby się sprawniej kontaktować. Może być taka instrukcja, czy jeszcze coś potrzebujesz wiedzieć?

Kombinuję nad ikonką kiosku, bo to najbardziej potrzebujący ikony typ sklepu (45 tys. użyć), a ikonka zaproponowana przez nebulon42 jest moim zdaniem zbyt odjechana. W tym celu zdołałem się nauczyć podstaw Inkscape’a na tyle, że wyprodukowałem kilkanaście wersji ikonki, ale odzew jest jakiś marny - niechby nawet i krytyczny, byle coś się ruszyło naprzód. Jeśli macie jakieś uwagi które się nadają estetycznie i co do czytelności oraz jak je można poprawić, to dajcie znać:

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