Tak, stały offset. Dałoby się używać dodatkowych wartości, gdyby było obsługiwane text-placement-type: list, ale jak można zobaczyć - [1] i [2] - problem jest znany i na razie brak sensownego rozwiązania.
Tu chodziło mi o użycie [name] i jako alternatywnego tekstu [short_name] przy wykorzystaniu wyżej wymienionego rodzaju rozmieszczania “list”. W short_name u nas jest właśnie województwo bez “województwa”.
Wydzieliłem wątek na temat nazw województw do osobnego wątku:
Wygląda na to, że jest inny sensowny algorytm (typu “umieść gdziekolwiek wewnątrz granic”), i to nawet używany w czeskim forku, tylko trzeba zachęcić talaja, żeby go wrzucił do standardowego Mapnika 
(a potem jeszcze wdrożyć w Carto CSS) :
https://github.com/mapycz/mapnik/blob/master/docs/features/placement-grid.md
https://github.com/mapnik/mapnik/pull/3780#issuecomment-347098875
Jeszcze jedno fajne porównanie obrazków… Był sobie wykład niejakiego Maxima Rylova (Uniwersytet w Heidelbergu) na SotM EU 2014 o tym, jak zoptymalizować ilość etykietek z nazwami, można nawet obejrzeć nagranie i pobrać slajdy z tego wystąpienia:
http://sotm-eu.org/en/slots/16
Na przykładzie Sycylii różnica między OSM Carto a GMaps była jak 5 do 54. Tymczasem jak sprawdziłem teraz, różnica jest jak 9 do 27:
https://github.com/gravitystorm/openstreetmap-carto/issues/1069#issuecomment-347573622
Wniosek - nie zawsze więcej znaczy lepiej i oba style zyskały na tym, że zbliżyły się do środka. 
Widać tam przykrywanie przez nazwę administracyjną nazwy wyspy, z “przemianą” nazw między z8 i z9. Już wcześniej widziałem taki dziwny efekt przy innych wyspach.
Okazuje się, że jest nadzieja na przesuwanie etykiet w ramach całego dostępnego obszaru! Wspominałem, że taki kod istnieje w czeskim forku Mapnika - zdaje się nawet jest z powodzeniem używany do zmieszczenia etykietek Hiszpania/Madryt (klasyczny układ, kiedy stolica jest w geometrycznym centrum obszaru):
https://en.mapy.cz/zakladni?x=-2.7414449&y=40.1327747&z=6&source=osm&id=34811795&q=madryt
Przy okazji dowiedziałem się, że na ten problem Mateusz założył bilecik zanim jeszcze zacząłem działać w projekcie:
https://github.com/gravitystorm/openstreetmap-carto/issues/1069
Kod algorytmu grid jest opisany w Mapnik CZ:
https://github.com/talaj/mapnik/blob/master/docs/features/placement-grid.md
i nawet autor zgodził się, żeby go dodać do oryginalnego Mapnika. Nie zrobił tego wcześniej, bo nie spodziewał się, że komuś to może być potrzebne - przecież to są podstawowe sprawy i pewnie od dawna jest to jakoś rozwiązane… Kolejny kamyczek do ogródka braku komunikacji między projektami OSM! Zaprosiłem go na SotM PL, byłoby fajnie pogadać na żywo, zwłaszcza razem z Mateuszem i Matthijsem, gdyby też się tam wybierał (ping?).
Być może jest więcej przydatnych rzeczy w tym czeskim forku, dlatego założyłem na to osobny bilecik:
https://github.com/gravitystorm/openstreetmap-carto/issues/2962
Tam też omówiłem z grubsza jakie są problemy z łańcuchami zależności między projektami. Nie wystarczy, że talaj zrobi PR w Mapniku i ten kod zostanie zaakceptowany, a nawet gdy Mapnik wyda nową wersję z tym kodem. Dalej są kwestie obsługi w CartoCSS i Kosmtiku oraz pakietowanie tego wszystkiego w różnych formatach - npm, mason, deb (najpierw Debian, a potem Ubuntu), ewentualnie problemy z wersjami NodeJS i npm…
Ciekawe to jest nawet, ale naprawienie drobnego problemu z nazwami województw zasłaniającymi nazwy miast wojewódzkich może potrwać wiele miesięcy zanim efekt pojawi się na OSM.org, nawet jeśli po drodze nie będzie dodatkowych trudności!
Wznowiła się nieoczekiwanie dyskusja na temat wyświetlania boundary=protected_area:
https://github.com/gravitystorm/openstreetmap-carto/issues/603#issuecomment-347879897
Tym razem wygląda na to, że dochodzimy do jakichś wniosków - wygląda na to, że w większości przypadków taguje się obszary chronione na oba sposoby - jako boundary=, ale też jako leisure=nature_reserve, czyli zapewne jedno bo słuszne, a drugie bo się wyświetla. W Polsce jak z 9249 tych leisure wykluczyłem boundary=, to zostało ledwie 1492 (16%), a jak jeszcze wykluczyłem protect_class=*, to zostało tylko 56 (0.6%). W Niemczech tych unikalnych przy obu wykluczeniach było 34%, ale to nadal oznacza, że większość jest otagowana podwójnie.
W związku z tym prawdopodobnie wyrzucę wyświetlanie leisure jako zbyt ogólne i po prostu nadmiarowe. Boundary pozwoli natomiast na wyświetlanie na początek (z8) tylko parków narodowych (w obu schematach), co zmniejszy bajzel wizualny, a np. rezerwaty ścisłe będzie można wyświetlać podobnie jak obszary wojskowe, ale oczywiście na zielono.
o parkingi zmieniły kolorek z żółtego na szary jak highway=living_street? czy u mnie coś się wywaliło z grafiką?
Parkingi zmieniły kolor:
https://github.com/gravitystorm/openstreetmap-carto/issues/2904
https://github.com/gravitystorm/openstreetmap-carto/issues/2947
Od około dwóch tygodni. Na początku sam pomyślałem że to błąd
Lista zmian:
https://github.com/gravitystorm/openstreetmap-carto/blob/master/CHANGELOG.md
Dyskusja:
https://github.com/gravitystorm/openstreetmap-carto/issues/2904
Zmieniły.
Myślę nad tym jak wyświetlać obszary chronione i po wymianie zdań ze społecznością mam już zdanie na temat tagowania oraz co z tego wynika dla pokazywania ich na domyślnej mapie:
Heh, właśnie znalazłem dość nietypowe zastosowanie dla osm-carto - używa go jako domyślnego stylu także projekt Open Geofiction. Przykład fikcyjnego, ale dość dokładnie zmapowanego miasta Ostrina w OGF:
http://opengeofiction.net/#map=17/40.05166/85.40216
Tagging for rendering na budynkach aż miło… 
Chciałbym je zobaczyć w 3D z góry wygląda to fantastycznie - budynki i ich zarysy.
Myślę, że w 3D wygląda to bardzo źle , bo to nie jest zrobione przez wizualizację building:part (ten bilecik został niestety odrzucony), tylko przez rysowanie barier… Jak wiadomo to się sprawdza tylko dla wyświetlania konkretnie w 2D pod osm-carto.
myślałem że jako building:part :(.
Widzę, że kolor ogródków (leisure=garden) został zmieniony na parkowy. Rozumiem, że opierało się to na założeniu, że skoro to “leisure” to powinno mieć inny kolor niż “landuse”. O ile byłem zawsze za rozróżnieniem na mapie różnych rodzajów pokrycia terenu (trawa/ ogród/ łąka), to nie rozumiem tu wybrania dla ogródków koloru parków. Jako ogród zalicza się przecież nie tylko przestrzeń gdzie ludzie hodują kwiatki dla rekreacji (leisure), ale także drobne miejskie kawałki zieleni, gdzie wynajęte firmy/ właściciele terenu komercyjnie dbają o rozwój i przycinanie roślinek. Takie małe kawałki zadbanej zieleni w miastach, które teraz na mapie mają kolor parków, wyglądają co najmniej dziwnie (nie komponują się z resztą), a mogą też wprowadzać w błąd (np. klasztorny ogród =/= park)
Przykłady:
http://www.openstreetmap.org/#map=19/52.40909/16.95734
http://www.openstreetmap.org/#map=19/52.38870/16.94303
http://www.openstreetmap.org/#map=19/52.40681/16.91801
http://www.openstreetmap.org/#map=19/52.41329/16.93124
Proponowałbym, że do ogródków lepiej nadawałby się pattern z kolorem trawnika i bladymi kolorowymi kropkami, symbolizującymi kwiatki.
Jest jeszcze landuse=flowerbed https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dflowerbed https://wiki.openstreetmap.org/wiki/Proposed_features/flowerbed niestety jeszcze się nie renderuje. Stworzony typowo w celu oznaczenia terenów jakie opisałeś.
Akurat nie chodziło o nazwy kluczy. Oparłem to na spostrzeżeniu, że pojęcia “ogród” i “park” są bliskoznaczne (często stosowane wymiennie), natomiast “ogród” i “trawnik” dużo mniej. Pozwala to też pokazywać części ogrodu porośnięte trawą, ponieważ ogród i park to obiekty złożone, natomiast trawniki - proste.
Z tymi małymi kawałkami zieleni jest duży problem. Jeśli to są klomby, to mamy tag flowerbed, natomiast są rozmaite formy zieleni, które są fatalnie otagowane jako village green, co ma zasadniczo zupełnie inne znaczenie. Jak o tym ostatnio dyskutowaliśmy na listach, to sugerowaliśmy np. landcover=mixed_vegetation, vegatation, green… Nie jestem pewien jaka to funkcja (landuse), wręcz może ich być dużo i kilka na raz, dlatego wydaje mi się, że lepsze jest landcover, czyli czym powierzchnia jest pokryta.