tutaj był zbliżony bilecik: https://github.com/gravitystorm/openstreetmap-carto/issues/2641
nie wiem jednak, czy traktować zamknięcie tego bilecika jako pewne zamknięcie potencjalnego bilecika o sztywnej hierarchii landuse (wiadomo już że np. @imagico byłby przeciw)
“You need to be clearer on what you think the problem is.”, “Closing this since there does not seem to be any specific suggestions on what should be changed except “leisure=park should be rendered under the landuse=forest””
Problemem w tym zamkniętym zgłoszeniu jest proponowanie dodanie jeszcze jednej zasady do skomplikowanego systemu warstw a nie rozwiązanie ogólnego problemu, nie widać by zgłaszający przemyślał jak to wpłynie na sytuację i czy nie popsuje czegoś innego.
Co innego gdyby przedstawiono ogólny problem, jak to zostanie rozwiązane i była chociaż próba przemyślenia jakie problemy to wywoła i dlaczego aktualne rozwiązanie jest gorsze.
Przy okazji, warto sprawdzić czy obszary podawane jako przykład problemów są otagowane poprawnie (patrz https://www.openstreetmap.org/note/1121136, sprawdzić czy to zielone nie jest tagowanie pod render i czy rzeczywiście jest tam coś co spełnia warunki opisane na http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dmeadow “Wildflower Grassland where plants set seed”).
Taka ciekawostka - jak wygląda bieżące obciążenie renderowaniem z podziałem na priorytety:
https://munin.openstreetmap.org/openstreetmap/render.openstreetmap/renderd_processed.html
Dodałem bilecik szerzej poruszający problem kolejności warstw. Tradycyjnie przypominam, że nie jestem informatykiem i żadnego kodu pisać nie potrafię, tak więc wszystkie moje sugestie to typowo uwagi szarego użytkownika mapy. Jeśli pojawił się w tej propozycji jakiś błąd/ niemożność techniczna - przepraszam.
https://github.com/gravitystorm/openstreetmap-carto/issues/2796
Zapraszam do dyskusji 
http://www.openstreetmap.org/#map=13/50.0783/22.0980
Dość denerwujące jest czytanie powielonych napisów o węzłach autostradowych. Wystarczył by jeden zamiast kilku. W tym przypadku 3 x można przeczytać “Rzeszów Wschód”. To problem rendera czy może nieodpowiedniego tagowania? Osobiście widział bym te punktu spięte w jakąś relację, która render by wspomogła.
Jako motorway_junction otagowany jest każdy zjazd i wjazd. To wygodne dla nawigacji i powszechnie stosowane rozwiązanie. Ma to jednak konsekwencje w renderingu.
Można się obyć też bez relacji - np. mapa transportu publicznego jakoś potrafi skojarzyć pobliskie przystanki o tej samej nazwie.
Rozwinąłem trochę artykuł na temat osm-carto na Wiki:
https://wiki.openstreetmap.org/wiki/Standard_tile_layer
Czy jest coś, co powinno tam się jeszcze znaleźć albo czy należałoby któreś informacje poszerzyć?
Czyli kolejny przykład gdzie tagowanie pod navi jest pożądane, a pod render nie 
. Skrzyżowanie jest przecież jedno, a przypomnę że “junction” w języku polskim nie oznacza zjazd z autostrady tylko właśnie skrzyżowanie.
Jak dla mnie obiekty takie jak zjazdy winny być spięte w relacje i dopiero razem tworzyć węzeł autostradowy w którym zostanie podana nazwa, którą to relację navi jak i render winno się nauczyć obsługiwać.
Mapa transportu publicznego nie wyświetla nazw węzłów wcale i nie potrafi się zadowolić wyświetleniem jedynie jednej nazwy dla tych samych przystanków http://www.openstreetmap.org/#map=17/50.04480/19.97261&layers=T także nie wiem skąd wziąłeś to stwierdzenie.
Oczywiście, że tego nie robi, każdy może się o tym przekonać.
Też nie wiem, nigdy czegoś takiego nie napisałem.
Napisałem natomiast: “potrafi skojarzyć pobliskie przystanki o tej samej nazwie.”
I tak właśnie jest. Przypatrz się uważniej.
Tu widzę kłopot. Od około roku w Gdyni przystanki autobusowe i trolejbusowe są numerowane, np. Armii Krajowej 01, Armii Krajowej 03.
Marafowi chodziło o to pojawiające się pole pomiędzy przystankami na mapie transportowej. Fakt, że mimo braku relacji mapa rozpoznaje te punkty i je ze sobą łączy jeśli identycznie się nazywają. Jak widać niuanse jak drobne zmiany nazwy powodują, że nie jest to jednak tak dobre rozwiązanie jak zastosowanie relacji, która ze swojej natury sprawdziła by się w tej sytuacji.
Dla mnie pozostaje jednie pytanie do jakiej relacji należało by te punkty przydzielić by tam przenieść nazwę i widziało ją zarówno większość renderów jak i navi.
Oczywiście, nie rozwijałem tematu, bo jest on jednak poboczny.
Istniejące rozwiązanie musi zostać dla zachowania wstecznej kompatybilności 
Samą relację należy wymyslić, zastosować na odpowiednią skalę i potem nakłonić twórców rendera, by z niej korzystali.
Jednak w przypadku mapy dla maperów, czyli osm-carto, aktualny rendering uważam za optymalny.
wcale nie powiedziałem by usunąć je z dnia na dzień, aczkolwiek docelowo należałoby
Nie wiem czy akurat trzeba cokolwiek wymyślać. Dla mnie albo zwykły multipolygon albo site nadają się w zupełności. Kwestia decyzji z którego należało by skorzystać.
Taaa. Nie wiem co optymalnego jest w wyświetlaniu się tej samej nazwy po kilka razy w tym samym miejscu obok siebie dla jednego skrzyżowania. Rzut okiem na OSM i konkurencje i widać, że mimo ta druga również jest dla maperów to na niej nie wyświetlają się podwójne nazwy dróg, ani tym bardziej podwójne nazwy węzłów, które nie wyświetlają się wcale choć tak daleko bym się nie posunął i nazwę węzła jednak wyświetlał.
http://www.openstreetmap.org/#map=13/52.1788/20.9859
https://www.google.pl/maps/@52.1847458,20.999785,12.5z
Problem jest taki, że te zjazdy mogą leżeć daleko od siebie, nawet kilkaset metrów. De facto to oznacza kierunek jazdy, a nie nazwę skrzyżowania. W dodatku znam też trudny przypadek, gdzie dwie nazwy zjazdów układają się naprzemiennie (a-b-a-b):
http://www.openstreetmap.org/#map=15/52.2682/20.9594
Być może scalanie należałoby robić na niższych poziomach (np. z12-z13) i pozwalać na dokładne wyświetlanie na wyższych? Niestety styl transportowy nie jest publicznie rozwijany, trzeba by się skontaktować z Andym Allanem (on rozpoczął osm-carto i obsługuje też mapę rowerową):
W tym przypadku jedna nazwa jest powielona czyli Marymoncka. Nie wiem jak by miało działać powielanie i czy może się gubić w takiej sytuacji gdzie mamy B pomiędzy dwoma A. Natomiast zastosowanie relacji rozwiązuje ten problem wprost czyli wskazuje dokładnie które punkty należy połączyć. Rozumiem, że wówczas w takiej sytuacji nazwa ta pokaże się w połowie drogi pomiędzy tymi punktami czyli gdzieś w okolicach http://www.openstreetmap.org/#map=19/52.27254/20.96576
Jeśli zdecydujemy się na relacje lub scalanie to rozpoczął bym już w momencie kiedy węzły się pojawiają jako numery ref czyli od z11 http://www.openstreetmap.org/#map=11/53.4476/-2.4039
Brzmi sensownie. Tylko nadal nie wiem jak to się scala.
Ja to sobie wyobrażam tak, że jeśli te wszystkie junction są w relacji, to renderer ignoruje nazwy na liniach i wyświetla je pośrodku relacji, albo w miejscu wskazanym przez również należący do relacji punkt z rolą label.
Z tym, że trzeba by jednak do tego nowy typ relacji, bo linie mogą być również w innych relacjach, więc renderer musi skądś wiedzieć, którą relację wybrać.
Jeśli to pomoże, mogę jakiemuś węzłowi taką relację dorobić.
Styl transportowy obywa się bez relacji i najbardziej mnie ciekawi jak to się dzieje, bo miejscem wyświetlania zajmie się i tak Mapnik, jak z każdym obszarem lub linią.
Na google nazwy się wyświetlają tak samo jak na OSM (oczywiście nie licząc przypadków, gdy nie są wprowadzone)
https://www.google.pl/maps/@52.1999648,20.8406549,15z
https://www.google.pl/maps/@50.2080215,19.1665546,16z
Nie widzę jeszcze zmian, ale serwerach OSM właśnie wdraża się v4.3.0:
https://lists.openstreetmap.org/pipermail/talk/2017-September/078680.html
Jest sporo mniejszych zmian tym razem. Wizualnie to przesunięcie wyświetlania pojedynczych drzew na z18+, zmiana koloru ikonek leisure (na zielono: place zabaw, parki dla psów i parki wodne - tu przy okazji powiększyłem ikonkę do normalnych rozmiarów), latarni morskich (na ciemnoszaro) i ambasad (na brązowo), pozbawienie obwódki tras promowych (co zwiększyło ich czytelność), wyświetlanie nazwy waterway=dock, ukrywanie małych parków rozrywki i zoologicznych na wcześniejszych poziomach przybliżenia, ciągłe linie dla granic np. województw na z4-z6 (są bardziej czytelne), zmiana schematu tagowania na nowy dla telefonów alarmowych i brodów oraz wzorek piasku na natural=sand, żeby się odróżniało od pól uprawnych.