Kod dla wież przygotowany i niemalże gotowy.
https://github.com/gravitystorm/openstreetmap-carto/issues/2556#issuecomment-278262720
Ze względu na wykorzystanie tagów height oraz tower:construction które w stylu dotychczas nie istniały konieczne jest przeładowanie bazy, więc pewnie nie zostanie z tego powodu użyty przynajmniej przez jakiś czas, ale zobaczymy. Ciekaw jestem komentarzy 
zawężyłem na kilku osiedlach obrysy landuse=residential do części mieszkalnych (tak, żeby nie obejmowały np. parków czy polan), a granice tych osiedli wyznaczyłem w relacjach type=boundary + place=neighbourhood i tam też przeniosłem nazwy osiedli, teraz widzę że po takim zabiegu zaczęły one zanikać; jak dla mnie to błąd logiczny - budynki mieszkalne mogą przecież stanowić tylko część osiedla, a w wielu miejscach jako residential zaznacza się całe osiedla, prawdopodobnie tylko po to, żeby mapa raczyła wyświetlić ich nazwę, to place=neighbourhood powinno mieć tutaj pierwszeństwo (tzn. w ogóle powinno być wyświetlane, bo z tego co rozumiem, to teraz nie jest) jako obrys bardziej administracyjny niż uznaniowy
Hm, nie sprawdzałem tego, ale chyba jest wyświetlane:
https://github.com/gravitystorm/openstreetmap-carto/blob/master/placenames.mss#L375
Sprawdziłem - wyświetla się:
węzły się wyświetlają, mój problem dotyczy relacji (które w tym przypadku pełnią rolę obrysów place=neighbourhood), kojarzę że jest coś takiego jak rola “label” w relacji, ale w tym przypadku oznacza to dublowanie informacji z relacji do osobnego węzła, prostszym rozwiązaniem byłoby wyświetlanie nazwy relacji w środku obrysu który wyznaczają członkowie outer
chodzi o tę dzielnicę, tam gdzie edycja się zrenderowała, nie ma już nazw osiedli
http://www.openstreetmap.org/#map=15/52.3853/16.9636
Trudno mi powiedzieć czemu tak jest i co poprawić. Polecam założenie bilecika, to wtedy jest szansa coś z tym zrobić.
założyłem, https://github.com/gravitystorm/openstreetmap-carto/issues/2566
mam nadzieję że nic przy tym nie sknociłem 
Edit:
Jest to większy problem z relacjami granic na wszystkich szczeblach. Tutaj jest poruszający ten problem bilecik:
https://github.com/gravitystorm/openstreetmap-carto/issues/103
Zalew Szczeciński - Trzebież. Wyspa refluacyjna i Chełminek na zoom 12 są widoczne powyżej coś jest nie tak z wyświetlaniem ich chyba?
https://www.openstreetmap.org/#map=12/53.6604/14.5751&layers=N
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:
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:
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.