Wyświetlanie na domyślnej mapie

no tak poprawek w wyświetlaniu drzew to nijak się nie dało przewalczyć, więc jak najlepiej pozbyć się problemu szybko go całkiem usuwając i to po pojedynczym komentarzu https://github.com/gravitystorm/openstreetmap-carto/pull/2789. Za to moją propozycją by sytuację poprawić zmieniając rozmiar wyświetlanych drzew by mapa nie wyglądała jak zakażona świnką zależnie od podanych danych to nie zajął się nikt :confused:

O pytanie - a jak się ma wyświetlanie na głównej miejsc z siłowniami pod chmurką?

@wmyrda: Na z16-z17 były tylko zielone kropki, ale to i tak było za dużo jak się zmapuje dokładnie osiedle czy park, więc żadna manipulacja wielkością by tego nie uratowała. To nie było oczywiste kiedy kod drzew był dodawany, ale teraz już to widać w praktyce. Ba, nawet z18 i z19 wyglądają trochę za mocno. ale być może wystarczy rozjaśnić koronę - kto wie, właśnie mi to wpadło do głowy i trzeba to przetestować. Natomiast już potem zauważyłem, że nazwane drzewa mogą się nadal wyświetlać od z16, bo jest ich mało, więc to będzie następny krok.

O ile pamiętam próbowałeś od razu za dużo pozmieniać i ani nikt inny za tobą nie nadążył, ani sam nie znalazłeś czasu na zmiany i testowanie - czyli na najważniejszą część pracy (tak, tak!). Polecam jednak metodę mniejszych kroków i prowadzenie samemu swojego pomysłu - nikt za ciebie nie zadba o to, co jest dla ciebie najważniejsze. Ja poza drzewami widzę jeszcze większe problemy - dosłownie z ostatnich dni to choćby blade nazwy rzek, szczytów górskich i zbyt późne wyświetlanie nazwy wielkich jezior.

@d3mol3k: Testowałem niedawno tę ikonkę, ale o ile jeszcze przy projektowaniu to wyglądało nieźle, to na mapie niestety kiepsko.

Od początku pisałem, że nie jestem programistą i to co napisałem to były jedynie propozycje i nic nie stało na przeszkodzie by inni lepsi ode mnie napisali to zupełnie inaczej. Zresztą mój kod to było raptem kilka linijek, a reszta to powielenia. To nie jest aż tyle to nie było można przeczytać

To źle pamiętasz. Miesiąc czasu poświeciłem na to. To ty uznałeś, że nie miałem do tego chęci. Jak wówczas odpowiedziałem po prostu nie umiałem stworzyć lepszego/prawidłowego.
Jak dla mnie to dość znamienne by dyskutować szereg czasu nad problemem, gdzie de facto nikt nawet nie wspomniał że drzew na mapie jest za dużo i należy ich nie wyświetlać. Obiekcje były na zupełnie innej płaszczyźnie (głównie o zbyt rozbudowany kod), a miesiąc czy dwa później bez żadnej dyskusji się je praktycznie usuwa i to bez takowego problemu zgłoszone przez użytkowników mapy.

I co by to miało znaczyć? Że będziemy iść beż dyskusji całkowicie w sprzeczności z propozycjami jeśli nie mają gotowego kodu?

Drzewa mają to do siebie, że zajmują przestrzeń i je widać z dużej odległości także nie rozumiem czemu miały by być ledwo widoczne na mapie jeśli jednak je ktoś swego czasu na mapę wprowadził. Jakie wówczas prześwietlały temu argumenty?

To była jedna z moich propozycji w przedstawionym kodzie by drzewa o określonym rozmiarze wyświetlać wcześniej. Dodatkowo można było ich ilość ograniczyć nie tylko nazwą, ale i oznaczeniem jako pomnik przyrody co również zaproponowałem.

Pojawiła się jakaś gradacja w ważności linii energetycznych? Trochę niespodziewanie to wygląda jak słupy jednej z linii widac już na z14, a w innej tylko słupy zaś sama linia widoczna jest dopiero od z16 http://www.openstreetmap.org/#map=15/49.6254/21.7992

Nie widzę żadnego uzasadnienia do pokazywania na jakimkolwiek zoomie samych słupów bez linii.

@wmyrda: Wybacz jeśli źle pamiętam - bardzo możliwe, że tak było jak mówisz, ale tego teraz nie sprawdzę. Pisałem ci, że też nie jestem programistą i nawet nie znam prawie SQL, ale jak widać da się to opanować w zakresie potrzebnym do rozwijania osm-carto, ale jeszcze ważniejsza umiejętność to cierpliwość i dzielenie problemów na mniejsze. Z tego co teraz piszesz wynika, że ktoś ma to czytać i poprawiać, bo jest “lepszy” - jeśli tobie zależy, to ty jesteś “najlepszy”. Żadne propozycje nie są wiążące - mamy prawie 400 propozycji na różne tematy i dopóki nie ma kodu i etapu poprawek i testowania oraz ostatecznej decyzji, to pewnie pozostaną na e-papierze.

Drzewa są reprezentowane na 3 sposoby - jako pojedyncze sztuki, szpalery oraz jako obszary. Szpalery to specjalny przypadek, ale pojedyncze sztuki to kwestia największych skal, a generalizuje się je za pomocą obszarów i te wyświetla się na mniejszych skalach (od z8). Detale powinny ginąć przy oddalaniu, inaczej mapa zamienia się w wizualny śmietnik.

Obiekcje do twojego kodu to osobna dyskusja. Problem z nadmiernym zagęszczeniem pojedynczych drzew zauważyłem niezależnie od tego.

A w praktyce - jeśli chcesz coś zmienić to zaproponuj jedną, prostą zmianę. Nie zestaw zmian, nie do doczytania i do powielenia, tylko gotową według ciebie do wdrożenia. A następnie ją prowadź. A potem następną, jeśli zechcesz. To działa, choć jak patrzę na moje propozycje, to tylko około połowy dotrwało do wdrożenia, reszta została odrzucona, ale lepszego sposobu nie znam, dlatego właśnie ten polecam.

Generalnie to zgadzam się z założeniami jakie przedstawiasz i również uważam, że jest to najlepsza droga. Natomiast nie uważam by każdy na siłę musiał nią podążać, gdyż ważniejsze jest by każdy zajął się tym co mu najlepiej wychodzi. Mnie zdecydowanie lepiej i wydajniej wychodzi edytowanie dlatego lepiej będzie dla OSM jak zostanę przy tym. Dla przykładu w ciągu ostatniego miesiąca poprawiłem setki danych wiki ze skryptów Mateusza na terenie całego kraju. Z kolei na Podkarpaciu uzupełniłem bazę o brakujące muzea, czy komplet atrybutów dla tych już istniejących, jestem w połowie uzupełniania tychże również dla obiektów sakralnych. Porównując to do bawienia się nad carto co mnie również miesiąc zajęło i nic z tego nie wynikło wolę pozostać przy tym co robię.

Co do drzew może i faktycznie są nazbyt widoczne jak na mapę podstawową, ale brak jakiejkolwiek dyskusji nad tym problemem, brak takiego zgłoszenia od użytkowników jako problem i jak na carto błyskawiczne wprost przejście od słów do czynów było co jak dla mnie zaskakujące. Ja jestem przeciwny tej zmianie no chyba że faktycznie szykuje się warstwa typowo turystyczna coś na kształt historycznej http://gk.historic.place/historische_objekte/translate/en/index-en.html

Nikt nie musi, oczywiście i cieszę się, że robisz różne rzeczy, których mnie z kolei by się nie chciało. :slight_smile: Nie o to chodzi, żebyśmy wszyscy robili to samo, tylko jak rezygnujesz, to w konsekwencji rozwój stylu idzie inną drogą i tyle.

Faktycznie z drzewami szybko to poszło, ale zwykle dyskusje grzęzną w detalach na długie miesiące (najstarsze bileciki mają po 4 lata!), bo nie udaje się ustalić wspólnego stanowiska. Ja akurat wolę zmieniać po kawałku, ale skutecznie, żeby tego marazmu uniknąć. Wdrożenie tej zmiany nie oznacza, że już nic w drzewach nie będzie można poprawić, ale na razie mam pomysł tylko na przywrócenie wyświetlania dla nazwanych drzew.

Teraz jednak zajmuję się innymi rzeczami, które wydają mi się ważniejsze, zwłaszcza szukaniem rozwiązań na wyświetlanie w skali globu. Właśnie wykombinowałem regułę wyświetlania nazw dla największych obiektów (typu oceany, kontynenty czy wielkie pasma górskie), których w ogóle nie widać na naszej mapie (!) i mam nadzieję, że to się uda wdrożyć w rozsądnym czasie.

http://www.openstreetmap.org/#map=18/50.14135/21.58865
Czy to tylko ja tak mam czy algorytm generujący obszar cmentarza na z18 w tym miejscu posiada różnorodne podejście co do części północnej (duże zagęszczenie krzyży) do części południowej ( zdecydowanie mniejsze zagęszczenie krzyży, które jeszcze są nieco większe). Dobrze by było gdyby wyświetlał się identycznie na całym obszarze

Rozłożenie jest równomierne (przyłożyłem długopis zamiast linijki w poziomie i w pionie), a wielkość krzyży taka sama , ale jak są drogi czy budynki, to zasłaniają trochę wzorka i to zmienia wygląd.

wygląda mi to na nie przerenderowany kafelek po zmianach w stylu

Może faktycznie. Dlatego odświeżałem kilkukrotnie nim napisałem. Jak widać nie wystarczyło

Widocznie nikt tam dawno nie zaglądał, bo nowy wzorek pojawił się miesiąc temu, w wersji v4.2.0. Mnie się też czasem zdarza trafić na kafelek ze starym kolorem wody.

Są problemy z umieszczaniem napisów (nazw obiektów) w przypadku wielokątów i to nie jest problem osm-carto, tylko Mapnika. Zdaje się, że odpowiedni kod znajduje się tu:

https://github.com/mapnik/mapnik/blob/40c51c469ca7fe5d598428099799634e08c457a8/include/mapnik/geom_util.hpp#L524-L593

Było to już kiedyś poprawiane:

https://github.com/mapnik/mapnik/issues/2137

ale nadal nie wszystko jest w porządku i to wychodzi przy różnych typach obiektów:

https://github.com/gravitystorm/openstreetmap-carto/issues/1465
https://github.com/gravitystorm/openstreetmap-carto/issues/2511
https://github.com/gravitystorm/openstreetmap-carto/issues/2613
https://user-images.githubusercontent.com/5439713/30748134-98dadb82-9faf-11e7-86c1-1ae712a69330.png

Czy ktoś parający się programowaniem mógłby to poprawić? Wersja minimum to sprawdzanie, żeby napis nie wychodził poza granice zewnętrznego prostokąta, bo jak widać to się zdarza (wtedy można choćby na siłę umieścić w jego geometrycznym środku), a docelowo dobrze by było, żeby pozycja napisu zawsze znajdowała się w obrysie wielokąta, oczywiście najlepiej w miejscu o największym polu.

Nie mam pojęcia czy obecne problemy to wina kodu czy algorytmu.

Tu jest pomysł na poprawkę algorytmu (w Postgresie, ale nie chodzi o tę konkretną implementację, tylko o ideę):

https://gis.stackexchange.com/questions/724/how-can-i-find-a-point-inside-a-polygon-in-postgis/31606#31606

Nowa wersja osm-carto v4.4.0 właśnie się zaczęła wdrażać na serwerach:

http://www.openstreetmap.org/user/kocio/diary/42541
https://munin.openstreetmap.org/openstreetmap/render.openstreetmap/index.html#renderd

Najważniejsze zmiany to wyświetlanie obszarów wody od samego początku, a także wcześniejsze wyświetlanie nazw zbiorników wodnych i wysp, już na poziomie kontynentów i świata. Pozostałe istotne zmiany to wyświetlanie ikony targowiska (amenity=marketplace), landuse=religious, shop=pastry, addr:unit, wcześniejsze wyświetlanie natural=bare_rock czy wyświetlanie wysokości dla obszarów alpine_hut i shelter (czyli wyrysowanych jako budynek).

Skoro osm-carto poszło w kierunku pastelowej palety kolorów, to nie ma się co dziwić, że ich brakuje.

Znajdź styl, który pokazuje tyle typów obiektów, to pogadamy o odcieniach i jakie kolory są jeszcze wolne:

https://wiki.openstreetmap.org/wiki/Standard_tile_layer/Key

Dla mnie sprawa jest prosta i tylko do tego się odnoszę: jeśli spłaszczasz wszystkie kolory w kierunku bieli, to siłą rzeczy masz ich mniej do dyspozycji. Dla mnie obecny styl jest nieużyteczny - szczególnie na poziomach z7-13 - i gdy tylko mogę, to z niego nie korzystam.