Ten problem z etykietami jest naprawdę intrygujący. Ciekaw jestem, co go spowodowało (wersja dla niewidzących - bardzo małe landuse i amenity wyświetlają się już na z12). Czyżby problem z PostGIS i way_area albo czymś?
A w ogóle którą wersję osm-carto używasz? Obecnie na serwerach jest wdrożona wersja v3.0.1. Ale faktycznie dziwne z tymi nazwami obiektów wyświetlanymi tak wcześnie.
Pełna lista zainstalowanego softu
dev-db/postgresql-9.6.1-r1
dev-db/postgis-2.3.1
sci-geosciences/mapnik-3.0.9999 [najnowszy git z gałęzi 3.0.x]
sci-geosciences/python-mapnik-0.1.9999 [ostatnia werja współpracująca z mapnik 3.0 czyli git commit ea5fd11]
sci-geosciences/openstreetmap-carto-9999 [najnowszy git dla stylu osm, w sumie z master a nie gałęzi 3.0]
sci-geosciences/carto-9999 [najnowszy git dla softu przygotowującego xml pod www]
sci-geosciences/osm2pgsql-0.92.0
net-libs/nodejs-7.3.0 z modułami współpracującymi z tą wersją do uruchomienia carto
Patrząc po wersjach to może faktycznie problem w tym, że do carto użyłem git z master a nie z gałęzi 3.0. Może również być kwestia translacji projektu na xmla, choć by nie wiem jaka wersja była to tak samo od siebie raczej zrobić nie powinno by te małe obszary tak szybko wyświetlać 
Faktycznie bardziej to skomplikowane niż sobie wyobrażałem. Miałem nadzieję, że za pomocą sed podmienię hurtem wszystkie wartości [name] w plikach mms na coś co przyniesie pożądany efekt, ale jak oglądam https://github.com/cquest/osmfr-cartocss/blob/master/project.mml to takie zapytania sql to już wyższa szkoła jazdy i dość diametralnie różnią się pomiędzy stylami dla takiego samego przypadku czyli “name”: “placenames-medium”
francuski
"table": " /* placenames-medium */ (select way,place,coalesce(tags->'name:fr',tags->'int_name',name) as name, replace(replace(replace(coalesce(tags->'short_name:fr',tags->'short_name', tags->'name:fr',tags->'int_name', name),'Saint-','Sᵗ-'),'Sainte-','Sᵗᵉ-'),'-sous-','-ss-') as nom, to_int(population) as pop, tags->'is_capital' as is_capital, 0 as nbtags from planet_osm_point where place is not null and place in ('city','town') order by coalesce(admin_level, capital,'9'), place, pop desc ) as placenames",
carto
table: |-
(SELECT
way,
name,
score,
CASE
WHEN (place = 'city') THEN 1
ELSE 2
END as category,
round(ascii(md5(osm_id::text)) / 55) AS dir -- base direction factor on geometry to be consistent across metatiles
FROM
(SELECT
osm_id,
way,
place,
name,
(
(CASE
WHEN (population ~ '^[0-9]{1,8}$') THEN population::INTEGER
WHEN (place = 'city') THEN 100000
WHEN (place = 'town') THEN 1000
ELSE 1
END)
*
(CASE
WHEN (capital = '4') THEN 2
ELSE 1
END)
) AS score
FROM planet_osm_point
WHERE place IN ('city', 'town')
AND name IS NOT NULL
AND (capital IS NULL OR capital != 'yes')
) as p
ORDER BY score DESC, length(name) DESC, name
) AS placenames_medium
EDIT
Niektóre to mnie się nawet spodobały, ale “Pole kwolka” https://justpaste.it/12ppt pod Jarosławiem na z10 to dopiero robi furorę 
A tak swoją drogą nie chcą mnie się generować kafle na z9 i wcześniejszych
PS Chętnych do przyglądnięcia się stylowi zapraszam na bigvo.hopto.org/osm. Generalnie mam na celu testowanie tu rozwiązań które miały by wcześniej czy później trafić do carto no może po za nazewnictwem gdzie jasna sprawa pole “name” nie ulegnie zmianie.
Francuski fork nastąpił dawno temu i dlatego nie ma najnowszych zmian w wyświetlaniu miejscowości/stolic, które bardzo poprawiły wygląd na niskich i średnich poziomach.
Niemiecki fork jest dla mnie zagadką - podobno jest używany w niemieckim stylu:
https://www.openstreetmap.de/karte.html
ale w kodzie nie zauważyłem myku z nazwami:
https://github.com/giggls/openstreetmap-carto-de
Hm, być może oni łączą kolumny danych zanim trafią do renderowania, co ma tę zaletę, że łatwiej utrzymać zgodność z oryginalnym stylem.
List z innymi stylami na których można bazować znalazłem parę
http://wiki.openstreetmap.org/wiki/List_of_CartoCSS_projects
https://github.com/trending/cartocss
nawet bardzo obszerne instrukcje
https://tilemill-project.github.io/tilemill/docs/manual/carto/
https://www.mapbox.com/blog/create-a-custom-map-of-your-city-in-30-minutes-with-tilemill-and-openstreetmap/
ale mam wrażenie, że tu raczej należy się edukować z postgresa i zadać mu tak pytanie sql by to on wydobył odpowiednią wartość z bazy a po tym jedynie wstawił kolejny dostępny język w pole name.
EDIT
PS Przyszło mnie na myśl pobawić się kosmitikiem. Przyznam, że sposób licencjonowania programu spowodował, że jest to pierwsza licecja jaką przeczytałem od deski do deski 
https://github.com/kosmtik/kosmtik/commit/035bbf4c17a02bbafbedbff87e7c9145f7252882
TileMill zadziała dopiero w wersji z Gita. Stara binarka potrzebowala pliku project.mml w innym formacie i dlatego YAML trzeba było za każdym razem konwertować skryptem.
A jak ci wyszło z Kosmtikiem? Chodzi mi głównie o te nazwy obiektów, które się wyświetlają zbyt wcześnie. Też mi się wydaje, że to musi być sprawa z nieprawidłowym odczytem way area (way_pixels) z bazy.
Kosmitika jeszcze nie uruchomiłem (standardowa instalacja za pomocą npm coś nie do końca mnie zadziałała, albo co bardziej prawdopodobne coś nie umiałem zrobić). Sporo zależności z nodejs do okiełznania jak chce się by pakiety instalowały się globalnie za pomocą systemowego instalatora.
PS. Przygotowałem za to nowszą wersję skryptów do Gentoo http://bigvo.hopto.org/osm-extra/overlay/geo-2017-01-24.tar.xz
Problem z nazwami rozwiązał się można powiedzieć sam. Otóż powtórzyłem operację wgrywania pliku pbf do bazy identyczną komendą tylko, że kilka dni nowszego po czym wygenerowany plik xml bym o 1/3 mniejszy a różnice wykazane poprzez diff faktycznie dotyczyły way_pixels. Nie wiem czy plik pbf sprzed kilku dni okazał się felerny czy też wystąpił jakiś błąd przy jej imporcie niemniej żadnej aplikacji nie wymieniałem.
Zastanawiało mnie również czemu plik xml generuje się aż ponad 7 minut skoro mamy tylko ze zwykłą zmianą formatu to teraz jest to dużo szybsze i trwa ok 12s.
Jak by ktoś był zainteresowany to może rzucić okiem na patche ze zmianami do stylu pod adres http://bigvo.hopto.org/osm-extra/carto-patches/ gdzie będę wrzucał swoje poprawki. Mimo, że to bardziej zabawa niż cokolwiek to jednak kilka prostych zmian wydaje się bardzo sensownych
- wydłużenie kresek dla okresowych potoków z 4/3 na 5/3 tak by było wiadomo w którym kierunku idą w ich gęstwinie
- zwężenie potoków by nie miały szerokości rzeki na wcześniejszych zoomach
- dodałem również wyświetlanie landuse=religious, które jak patrzę w kolorze z place_of_worship również wygląda dobrze
- rozdzielenie koloru obszarów wodnych od tych oznaczonych liniami.
- rozjaśnienie koloru trawy by zbliżyć ją bardziej do koloru ziemi niż czegokolwiek więcej co by się tak nie rzucała w oczy
- man_made=cross - podniesienie o poziom jest zasadne, gdyż jak dla mnie są to obiekty co najmniej wielkości “Krzyży Milenijnych” stąd będące dobrymi punktami orientacyjnymi i warto by im przygotować powiększoną ikonkę krzyża, choć pewnie zdania mogą się tu różnić
Nad kolorystyką pozostałych elementów mówiąc oględnie to można by jeszcze popracować 
Mile widziane propozycje najlepiej z patchami gdyż dodam nie znam się na tym na tyle by coś rewolucyjnego przygotować 
EDIT:
Być może kosmitik czy tilemill robią to lepiej niemniej drobne udogodnienie w postaci kolorowania składni dla edytora nano https://justpaste.it/12te5 dla tych co chcą się przyglądnąć kodowi dla edytowanego stylu. Do pobrania pod http://bigvo.hopto.org/osm-extra/nanosyntax/
Przyjrzałem się temu kodowi nieco dokładniej (co by człowiek zrobił bez sed ;)) i dostrzegłem tam w pliku project.mml m.in taki zapis https://github.com/cquest/osmfr-cartocss/blob/master/project.mml#L370
Co to konkretnie oznacza? Czy to łączy podane pola w jedno i wyświetla je wszystkie w name, czy też raczej bierze kolejno pola zgodnie z podaną w kolejności listą i pierwszą napotkaną wartość wrzuca do name?
EDIT
Znalazłem, wybrana jest pierwsza wartość która nie jest pusta. https://www.postgresql.org/docs/9.6/static/functions-conditional.html#9.17.2
Uch, ależ teraz lasy i woda walą po oczach!.. Polecam te dwa bileciki na temat kontrastu lasu z wodą oraz jak to powinno wyglądać na średnich poziomach zooma:
Kwestia gustu, choć zgadzam się są bardzo nasycone dlatego wcześniej napisałem
https://github.com/gravitystorm/openstreetmap-carto/issues/2194#issuecomment-265316515
no nie wiem las ciężko od trawy odróżnić 
Co bym nie robił non stop dostaję albo błąd składni albo informację, że obiekt nie istnieje
renderd[621]: An error occurred while loading the map layer 'default': Postgis Plugin: BŁĄD: błąd składni w lub blisko ","
LINE 2: way,
^
in executeQuery Full sql was: 'SELECT * FROM (SELECTOD
way,
COALESCE('name_pl', 'name_en', 'name_es', 'name_fr', 'int_name', 'name') AS name,
religion, way_pixels,
a próbowałem już chyba wszystkich możliwych kombinacji ‘name_pl’, ‘name:pl’, “name_pl”, “name:pl”, name_pl, name:pl
do pliku openstreetmap-carto.style dodałem
node,way name text linear
node,way name:en text linear
node,way name:es text linear
node,way name:fr text linear
node,way name:pl text linear
node,way int_name text linear
Coś jeszcze potrzeba??
Po zmianie w openstreetmap-carto.style musisz wykonać import ponownie.
A czasem nie ma tych tagów już teraz w kolumnie hstore? Tam powinny wylądować wszystkie pozostałe tagi dla obiektów które załapały się poprzez zwykłe kolumny, a tagi te nie są jednocześnie na czarnej liście (source, created_by i inne metadane)
Spróbuj zrobić select(*) na czymś co wiesz że posiada name:pl i popatrz na wynik kwerendy.
To akurat robię, a moja komenda to
time osm2pgsql --create --slim \
--cache 500 --number-processes 4 --hstore -m \
--style /opt/osm/local_style/openstreetmap-carto.style --multi-geometry \
-U psql -c -d gis \
--bbox 21,48.9,24,50.9 \
/mnt/4tb/nagrania/osm/podkarpackie-latest.osm.pbf
Też czytałem, że tak to powinno działać, ale jeśli są to jak rozumiem zapytanie o ‘name:pl’ powinno je stamtąd wydobyć?
No nie. Skąd się to tam znalazło wtym jednym polu to ja nie zgadnę. Błędy wcale nie dotyczyły pól name a SELECTOD. Skąd się tam wzięło to extra OD to nigdy nie zgadnę.
- id: landcover
name: landcover
geometry: polygon
<<: *extents
Datasource:
<<: *osm2pgsql
table: |-
(SELECTOD
way,
COALESCE('name_pl', 'name_en', 'name_es', 'name_fr', 'int_name', 'name') AS name,
religion, way_pixels,
COALESCE(aeroway, amenity, wetland, power, landuse, leisure, military, "natural", tourism, highway, railway) AS feature
FROM (SELECT
way, COALESCE('name_pl', 'name_en', 'name_es', 'name_fr', 'int_name', 'name') AS name,
('aeroway_' || (CASE WHEN aeroway IN ('apron', 'aerodrome') THEN aeroway ELSE NULL END)) AS aeroway,
Po usunięciu OD ruszyło z ‘name:pl’, ‘name:en’, …
hstore to key/value store, a nie zwykła kolumna, trzeba się odnieść strzałką:
https://www.postgresql.org/docs/9.5/static/hstore.html
no fakt. Samo wskazanie ‘name_pl’ spowodowało jedynie tyle, że nazwy obiektów zostały zastąpione i wszystkie obecnie nazywają się name:pl
Przydał by się przykład z życia wzięty, gdyż jak bym nie próbowałem skorzystać z tej formy już na kilka sposobów jak ten
COALESCE(“name:pl”=>name_pl, “name:en”=>name_en, name) AS name,
i nic to nie daje gdyż cały nawet po odświeżeniu kafli nazwa, która w bazie po polsku jest zapisana w name:pl nadal wyświetla się jedynie jako standardowy wpis z pola name np http://bigvo.hopto.org/osm/?zoom=15&lat=49.82472&lon=22.98724&layers=B0
Znalazłem przy okazji dość aktualne instrukcje pod Ubuntu 16.04:
https://www.linuxbabe.com/linux-server/openstreetmap-tile-server-ubuntu-16-04
Cześć, jakiś czas temu też zajmowałem się tym tematem. Zabawę z titlami chyba najprzyjemniej zacząć z TileMillem i https://github.com/mapbox/osm-bright.
U mnie to wygląda mniej więcej tak:
Na Windows mam:
- TileMilla
- styl osm-bright
- python
Na wirtualce ubuntu 14.04 LTS:
- PostgreSQL & PostGIS
- plik .pbf europy / polski z http://download.geofabrik.de
- zaimportowany do PostgreSQL przez osm2pgsql
- Ogólnie zaczynamy od postawienia linuxa i wgrania do nich map
- Instalujemy TM
- Konfigurujemy plik configuration w stylu osm-bright
3.1 Pobieramy potrzebne pliki .shp i je dodajemy do odpowiednich katalogów. - Instalujemy z poziomu pythona nasz styl do TM
- Odpalamy TM i nasz styl i możemy się bawić:)
Jak chcemy postawić serwer titli to najlepiej wyeksportować je do formatu .mbtiles i odpalić jakiś serwer do tego formatu.
Ogólnie dla europy powinniśmy mieć jakieś 300gb wolnego miejsca najlepiej więcej. I dosyć dobry sprzęt bo inaczej będzie to długo trwało.
Pierwszy tak dogłębny opis jaki widziałem. Wyjaśnił również, że kafelki to przygotowywane są zawczasu za pomocą render_list. Dotychczas na podstawie wcześniej podanych tu informacji zachodziłem w głowę jak to tego zmusić renderd. Jak widać to nie on renderd a inna aplikacja z tego samego pakietu mod_tile do tego służy
Ciekawa koncepcja. Jak by kolega mógł udzielić na ten temat nieco więcej szczegółów mogło by to być bardzo pomocne
Jeśli chodzi o format .mbtiles to jest to ogólnie sql-lite przystosowany do przechowywania titli. Ja wykorzystywałem jako serwer chyba ten projekt w javie: https://github.com/jtreml/mbtiles4j ale można znaleźć wersję pod inne języki np. php, node.js, python.
W moim przypadku musiałem pobrać projekt serwera w javie i zaimportować go w eclipse. Ustawić plik konfiguracyjny gdzie podałem path do pliku z titlami i odpalić aplikacje. Możesz także zbudować sobie z tego jar`a i umieścić na swoim serwerze wraz z plikiem z titlami.
W razie potrzeby mogę przygotować jar`a i instrukcje.
Osobiście pewnie nie skorzystam, przynajmniej nie na tym etapie, ale dla kompletności wątku domniemam, że nie będę jedyny który sądzi by taki opis się przydał.
Natomiast tak się zastanawiam nad problemem dodania kodu dla wież. Otóż kod ten http://bigvo.hopto.org/osm-extra/carto-patches/013-towers_v3.patch aplikowany do carto ładnie startuje po czym kafelki nie renderują się dla poziomów na których powinny być widoczne wieże a log pokazuje m.in. następujący komunikat
renderd[24413]: reason: Postgis Plugin: BŁĄD: kolumna "tower_construction" nie istnieje
Ponieważ równie dobrze mogło by się wywalić na “tower:type” zacząłem się zastanawiać i szukać głębiej. Otóż okazuje się, że dla województwa Podkarpackiego dla którego postawiłem bazę testową nie ma w ogóle ani jednego obiektu co by był oznaczony w ten sposób. Możliwe jest by to było przyczyną problemów?