Wyświetlanie na domyślnej mapie

Ja tam również jestem z tego zadowolony gdyż co by nie powiedzieć jest to kroczek naprzód. Sam ich zresztą ostatnio sporo dodałem jak np. tu http://www.openstreetmap.org/#map=18/49.78333/22.74911 przy okazji generalnego wzięcia się za poprawę miasta Przemyśl które praktycznie całe skalibrowane było pod Binga z szeregiem kolejnych mniejszych lub większych grzeszków ;). Roboty tam nadal jest na co najmniej kwartał

Co do torów to zonk z tym wyświetlaniem, ale raczej nie do uniknięcia przy tak ogromnej liczbie tagów i ich wartości. Jak się optymalizuje skrypty w takiej sytuacji zawsze się okaże że się zoptymalizuje za dużo. Pech chciał akurat trafiło na nie

Obszary szkół generalnie są widoczne od zbliżenia 16 i ich nazwa wyświetla się nawet gdy musi być wyświetlona poza obszar przez nią zajmowany. Wyjątkiem od tej reguły jest jednak moment gdy na obszarze szkoły umieścimy większą ilość parkingów wówczas nazwa ta się pojawia później zależnie od ich ilości. W przypadku poniżej dopiero przy z19. Można by pomyśleć nad tym by parkingi nie były aż tak eksponowane jeśli wpisane są w obszar szkoły czy uniwersytetu.
http://www.openstreetmap.org/#map=19/49.77402/22.78944

Mateusz właśnie zaproponował zmniejszenie ważności parkingów w ogóle (nie tylko na terenie szkół), więc powinno się niedługo poprawić.

W następnej wersji będzie moja poprawka traktująca parkingi jako mniej istotne ( https://github.com/gravitystorm/openstreetmap-carto/pull/1364 ).

Ogólny problem z ikonkami blokującymi istotne napisy jest na razie nierozwiązany ale planowanie trwa na https://github.com/gravitystorm/openstreetmap-carto/issues/964

Znikające tory - znany bug który będzie poprawiony w następnej wersji, może nawet szybciej.

O, właśnie poszedł hotfix dla torów - w ciągu 48 godzin powinny się pojawić (parkingi i drzewa nieblokujące napisów będą w najbliższej wersji).

Źródło: https://git.openstreetmap.org/chef.git/

oprócz okiełznania mapnikowych kolorów dróg dobrym odświeżeniem byłoby dodanie do nich efektu trójwymiarowości, coś w ten deseń:

co o tym myślicie?

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.