Wyświetlanie typów boisk i to bez przeniesienia kodu ze stylu francuskiego:
http://www.openstreetmap.org/#map=19/53.16112/17.91507
Kiedyś zoom 14 i 13 renderował się jako pierwszy, praktycznie nigdy dłużej niż 1 minutę.
Teraz mi się wydawało, że brakuje kafli sprzed 3 dni mimo wielokrotnego odświeżania ale przełączyłem się na firefoxa i widzę, że problem dotyczy chrome, które jakoś mocno trzyma kafle w cache-u.
Jak problem obejść?
Po dłuższej przerwie domyślna mapka aktualizuje się do stylu OpenStreetMap Carto v3.3.0 - wersja 3.2.0 została pominięta z powodu problemów z dyskiem na jednym z serwerów renderujących, a i styl miał niedawno po prostu przestój w rozwoju.
Ważniejsze ostatnie zmiany:
- budynki terminali lotniczych wyświetlają się jak budynki dworców kolejowych i innych budynków “specjalnych” (ciemny brąz)
- przestarzałe tagowanie landuse=farm nie jest już wyświetlane
- dodane wyświetlanie arts_centre (ikonka m.in. dla domów kultury), fitness_centre (tak samo jak sports_centre), plant_nursery (wzorek dla szkółek jest podobny jak dla sadów), aerialway=mixed_lift (tak samo jak kolejka gondolowa)
- zmiana wyświetlania wetland=fen
- bardziej dyskretna obwódka dla terenów szkół, szpitali, centrów sportowych itp.
- większość ikonek sklepów wyświetla się teraz od z18, na z17 symbolizują je fioletowe kropki
Kolejne wydanie ma być podwójne - 3.3.1/4.0.0. Wizualnie nie powinny się różnić, natomiast seria 4.x wprowadzi transformacje lua. Ten kod pozwoli na korzystanie z hstore, czyli na długo oczekiwane odświeżenie “podręcznej” bazy danych używanej do wyświetlania domyślnej mapki. Obecnie ta baza jest okrojona do wybranych tagów, użycie hstore da nam wreszcie dostęp wszystkich tagów, co pozwoli na załatwienie różnych problemów.
w miejscu które od jakiegoś czasu mapuję część kafelków zaczęła przy zoomowaniu pokazywać stan sprzed kilku miesięcy, czy ma to związek z aktualizacją stylu, a jeśli tak, to dlaczego i kiedy się to unormuje?
http://www.openstreetmap.org/#map=17/52.39058/16.94503
@Tomasz_W jednego w tym wszystkim nie rozumiem dlaczego np. ten chodnik jest oznaczony jako highway=footway, a nie area:highway=footway
Sądząc po ikonkach sklepów (czyli fioletowych kropkach na z17) jest to z pewnością świeże renderowanie z nowym stylem, a nie jakieś zapyziałe kafelki. Wobec tego jest to problem danych jakimi karmią się serwery renderowania. Jeden z nich miał przez wiele dni laga w aktualizacji danych (w związku z wymianą zepsutego dysku), ale wygląda na to, że już ma aktualne dane:
https://github.com/openstreetmap/operations/issues/143
https://munin.openstreetmap.org/openstreetmap/yevaud.openstreetmap/replication_delay.html
więc nie wiem w czym jeszcze może tkwić problem. Pewnie takie problemy (nie związane z samym stylem) należy zgłaszać właśnie w projekcie operations.
http://www.openstreetmap.org/note/1015832#map=19/50.86316/17.46451
Wyświetlanie shop=mall jest w obecnym wydaniu popsute.
Czy jest jakakolwiek szansa na to, żeby highway=track był wyświetlany tak jak inne drogi - dwuwymiarowo? Obecnie trudno jest takie drogi odróżnić od granic administracyjnych. A nie daj Boże jak taka droga biegnie wzdłuż granicy. Wtedy to już w ogóle wygląda badziewnie 
@Azquoir: Nic mi nie wiadomo o takich planach i nie słyszałem jeszcze o takim problemie, więc szansa leży w twoich rękach.
Tymczasem jest gotowy konkretny kod który ma poprawić czytelność w średnich skalach domyślnej mapy, przy czym Matthijs chciałby od razu zmienić kolor wody na taki, który udało się wspólnie ugadać przy innej okazji:
https://github.com/gravitystorm/openstreetmap-carto/pull/2654
Zapraszam do dyskusji na GitHubie, bo to naprawdę spora zmiana.
To nie tracki trzeba wyróźniać tylko zmniejszyć kłucie po oczach granicami administracyjnymi.
Gdy ludzie dopraszają się renderu obiektów pomocnych w nawigacji to tłumaczenia są pokrętne a najczęstsze z nich to wygeneruj sobie własna mapę albo, że mapa ogólnotematyczna nie może zawierać wszystkiego.
Ciekawe dlaczego rozmaite granice administracyjne nie mogą trafić na tematyczną mapę granic?
Podstawowe funkcje mapy to:
- nawigacja czyli wskazane istniejącej siatki dróg aby oczyma lub programowo wybrać optymalną trasę.
- wskazanie interesujących obiektów w pobliżu pokonywanej lub planowanej trasy, czyli funkcja krajoznawcza oraz skorzystanie z rozmaitych POI.
Nie bardzo sobie wyobrażam aby ktoś poruszał się wzdłuż jakiejś granicy albo aby kogoś zaciekawiło, że jedną nogą jest w jednej gminie a drugą w innej.
Oczywiscie zmapowane granice dają wiele możliwości ale głównie programowych zatem nic nie usprawiedliwia takiego bicia po oczach.
Tam gdzie są potrzebne granice np. w skalach przydatnych do przeglądania “globusa politycznego” trudno rozróżnić granice krajów.
Render dróg poślednich jak track i path wynika z tradycji kartograficznych i odchodzenie od tego powodowałoby nieczytelność map OSM u osób obeznanych z innymi mapami. Wypełnienie czyli stosunek przerw do kresek niesie informacje o klasie tracka.OSM ma 4-5 kreskowań tracków a lepsze mapy np. topograficzne-wojskowe mają kilkanascie,Gdyby tracki miały obwódki to wypełnienie stawałoby się mniej czytelne.Obwódki są rezerwowane do zwizualizowania kilku parametrów na jednej drodze.Dziś nie wiadomo jakie parametry, bo jest ich wiele, należałoby renderować.Obwódka najlepiej wizualizowałaby szerokosć ale akurat w podróży ten parametr jest mało potrzebny.
Access można prezentować kolorem.
Zatem obwódki mogłyby wizualizować komfort jazdy czyli jakiś algorytm łączący kilka cech drogi jak rodzaj nawierzchni, równość itp.
Rozumiem. Jak najdzie mnie wena to może coś podziałam (jeśli nie zmienię zdania 
)
Z tym, że mnie nie chodzi o wyróżnianie a wręcz przeciwnie - żeby były wyświetlane tak jak reszta dróg.
Wiadomo, że wszystkim się nie dogodzi. Najlepszym rozwiązaniem byłoby zaakceptowanie area:highway i używanie tego tagu przez render jednocześnie “degradując” **highway= ** do roli navigation-only
To nic nie da. Nie tylko traków nie widać na granicach ale również residential. Dla przykładu ta droga http://www.openstreetmap.org/way/315881194 jest tak samo nie widoczna na z13 i z14 jak i track mimo że oba rodzaje dróg na obu poziomach są wyświetlane a chyba nie chcemy by track i residential na tych zoomach miały szerokość unclassified by je uwidocznić. Do tego na obszarze obfitującym w tracki jak ten http://www.openstreetmap.org/#map=13/49.8567/22.2094 nie chciał bym by nagle stały się one jakoś ekstra widoczne na mapie, gdyż nie jest to taki istotny element. Niniejszym niejako przychylam się do zdania rowers2a że jedynym sposobem na pokazanie lepiej tych dróg jest zmniejszenie widoczności granic z tym że nie usuwał bym ich całkiem.
Być może sensowne było by zmniejszenie grubości granic by nie odbiegały nią od obecnej grubości tracków i zmianę na linie ciągłe. Pozostawiając obecny kolor nie będzie się on z niczym mylił. Wówczas można by myśleć nad zmianą wyświetlania tracków.
Zaproponowałem, żeby amenity=childcare (żłobki itp.) wyświetlało się podobnie jak przedszkola:
https://github.com/gravitystorm/openstreetmap-carto/issues/2657
Gdzieś w odmętach Wiki czy innym miejscu widziałem przytoczone słowa jakiejś kobiety (z prelekcji SOTM lub podobnej) dot. efektów tego, że mapują w większości faceci i stąd nie widzą różnicy między żłobkiem i przedszkolem, bo nie zajmują się dziećmi.
Ja bym stawiał na to, że są nieogarnięci. Żłobek to żłobek, przedszkole to przedszkole.
Randomowy komentarz z forum gazety.pl
Dla mnie intuicyjne było zanim to znalazłem, że żłobek to miejsce dla bardzo małych dzieci, które wymagają większej opieki.
Tu jest mowa o genderowym przechyle w OSM (i link do nagrania wideo na ten temat):
https://wiki.openstreetmap.org/wiki/Proposed_features/childcare#Post-mortem
Być może warto poprawić definicję przedszkola i childcare (bo to może nie tylko żłobki?), żeby było jaśniej. Wygląda na to, że warto zainwestować w ten tag, bo maperzy zagłosowali już na niego nogami. 
w ostatnim czasie zmapowałem jako obszary 3 rodzaje amenity, które również się nie wyświetlają:
-dom spokojnej starości: http://www.openstreetmap.org/way/490536652
-dom opieki: http://www.openstreetmap.org/way/498898213
-akademiki: http://www.openstreetmap.org/way/236631228
Co myślisz, @Kocio?
Dwa pierwsze są przestarzałe - mają wprost napisane na wiki, żeby zamiast nich zastosować amenity=social_facility z odpowiednimi dodatkami, i wtedy zaczną się wyświetlać nazwy wraz z ikonką:
https://wiki.openstreetmap.org/wiki/Tag:amenity=retirement%20home
https://wiki.openstreetmap.org/wiki/Tag:amenity=nursing%20home
Natomiast akademiki znam tylko jako pojedyncze building/amenity=dormitory. Obecny tag jest rzadko używany i nawet go nie znałem. Ja tereny uniwersyteckie oznaczam po prostu jako amenity=university. Wtedy się wyświetli oczywiście z odpowiednią nazwą.
Zdaje się, że właśnie wdraża się na serwerach osm-carto w wersji 4.0.0. Na oko nie różni się prawie od 3.3.1 (czyli 3.3 plus poprawki wyświetlania rzek okresowych) - celowo, bo duże zmiany są w kodzie i chodziło o możliwie gładką migrację.
Są jednak pewne różnice - na przykład jeśli idzie o wielokąty starego typu, ale większość z nich udało się już przerobić w ekspresowym tempie. Teraz na tapecie są wielokąty złożone, które mają tagowanie nie tylko w relacji, ale także na obrysach zewnętrznych lub wewnętrznych. To błąd tagowania (tagi wielokąta złożonego powinny być tylko w relacji), ale dopiero teraz go widać. W związku z tym zaczęła się akcja naprawiania tych błędów (jest ich około 50 tysięcy):
Zrobiłem dużą ilość renderów do porównania obecnego kodu z propozycją zmian na średnich poziomach przybliżenia - mile widziane komentarze jak to widzicie:
https://github.com/gravitystorm/openstreetmap-carto/pull/2654#issuecomment-312505455