fakt poszło dalej, ale tam na dobrą sprawę to i tak jest już niepotrzebne gdyż jak pisze w mapniku
czyli jak rozumiem w ten sposób nie używał bym carto tylko starszego mapnika.
Pytanie jak zrobić by render korzystał ze stylu carto? https://switch2osm.org/serving-tiles/manually-building-a-tile-server-14-04/ wskazuje by użyć OSM Bright, ale czy to by nie oznaczało, że zamiast carto użyje jego modyfikacji w postaci OSM Bright?
Mi się jakimś cudem udało zmusić rendering carto do współpracy jakieś pół roku temu czy dawniej. Tak więc, przynajmniej wtedy, dało się. Jedynie parę pakietów musiałem zaciągnąć w innej wersji. Może odkurzę starego netbooka i sprawdzę co dokładnie robiłem.
CartoCSS to de facto kompilator tego języka - bierze na wejściu cały styl i tworzy z niego plik XML z konfiguracją, którą Mapnik rozumie. Wystarczy zrobić ten krok za każdym razem kiedy styl się zmienił i chcesz go wdrożyć do produkcji. Tu masz przykład:
https://wiki.openstreetmap.org/wiki/CartoCSS#Converting_to_Mapnik_XML
Te przykłady wskazują na użycie /bin/carto W instalce której aplikacji znajdę tą binarkę?
Uruchomienie carto powoduje następujący błąd. Taki sam dla wersji stabilnej jak i git. Może brakuje jakiejś zależności np. tilemill?
carto
module.js:472
throw err;
^
Error: Cannot find module 'lodash'
at Function.Module._resolveFilename (module.js:470:15)
at Function.Module._load (module.js:418:25)
at Module.require (module.js:498:17)
at require (internal/module.js:20:19)
at Object.<anonymous> (/opt/osm/carto/lib/carto/parser.js:3:9)
at Module._compile (module.js:571:32)
at Object.Module._extensions..js (module.js:580:10)
at Module.load (module.js:488:32)
at tryModuleLoad (module.js:447:12)
at Function.Module._load (module.js:439:3)
Tym czasem jak by ktoś potrzebował skrypty instalacyjne dla obecnych wersji pakietów do Gentoo proponuję przetestować przygotowaną przeze mnie kolekcję http://bigvo.hopto.org/osm-extra/overlay/geo-2017-01-21.tar.bz2 która dla wygody zawiera również meta pakiet app-admin/osm-geo/osm-geo-1.0.ebuild który pozwala na instalację wymaganych programów do postawienia serwera kafli.
Pakiety instalują się poprawnie poza python-mapnik który to działa jedynie dla pythona2, a powinien dla pythona 3.4 i 3.5 również. Mile widziane propozycje jego poprawienia 
No i oczywiście jest również problem z działaniem carto o którym wspominałem wcześniej.
Od jednego extremum do drugiego 
Jak panowie od python-mapnika nie przygotowali ani jednego wydania, które można by byłowskazać jako zależność tak w wypadku lodash mamy ich na dzień dzisiejszy 380… https://github.com/lodash/lodash/releases Może jakaś podpowiedź które było by potrzebne oraz na której wersji nodejs by miało bazować?
EDIT:
okazało się, że lodash to nie wszystko i że npm może je instalować zarówno globalnie jak i lokalnie czyli w tym przypadku w katalogu gdzie zainstalowane jest carto. Instalacja lokalna pokazała, że potrzebne jest cały szereg modułów do działania carto, które doinstalowują jeszcze większą liczbę zależności
npm install lodash
@mapbox/carto@0.16.3 /opt/osm/carto
└── lodash@4.17.4
npm install chroma-js
@mapbox/carto@0.16.3 /opt/osm/carto
└── chroma-js@1.2.1
npm install js-yaml
@mapbox/carto@0.16.3 /opt/osm/carto
└─┬ js-yaml@3.7.0
├─┬ argparse@1.0.9
│ └── sprintf-js@1.0.3
└── esprima@2.7.3
npm install hsluv
@mapbox/carto@0.16.3 /opt/osm/carto
└── hsluv@0.0.1
npm install semver
@mapbox/carto@0.16.3 /opt/osm/carto
└── semver@5.3.0
npm install mapnik-reference
> mapnik-reference@8.6.1 postinstall /opt/osm/carto/node_modules/mapnik-reference
> node generate.js
@mapbox/carto@0.16.3 /opt/osm/carto
└── mapnik-reference@8.6.1
npm install yargs
@mapbox/carto@0.16.3 /opt/osm/carto
└─┬ yargs@6.6.0
├── camelcase@3.0.0
├─┬ cliui@3.2.0
│ ├─┬ strip-ansi@3.0.1
│ │ └── ansi-regex@2.1.1
│ └── wrap-ansi@2.1.0
├── decamelize@1.2.0
├── get-caller-file@1.0.2
├─┬ os-locale@1.4.0
│ └─┬ lcid@1.0.0
│ └── invert-kv@1.0.0
├─┬ read-pkg-up@1.0.1
│ ├─┬ find-up@1.1.2
│ │ ├── path-exists@2.1.0
│ │ └─┬ pinkie-promise@2.0.1
│ │ └── pinkie@2.0.4
│ └─┬ read-pkg@1.1.0
│ ├─┬ load-json-file@1.1.0
│ │ ├── graceful-fs@4.1.11
│ │ ├─┬ parse-json@2.2.0
│ │ │ └─┬ error-ex@1.3.0
│ │ │ └── is-arrayish@0.2.1
│ │ ├── pify@2.3.0
│ │ └─┬ strip-bom@2.0.0
│ │ └── is-utf8@0.2.1
│ ├─┬ normalize-package-data@2.3.5
│ │ ├── hosted-git-info@2.1.5
│ │ ├─┬ is-builtin-module@1.0.0
│ │ │ └── builtin-modules@1.1.1
│ │ └─┬ validate-npm-package-license@3.0.1
│ │ ├─┬ spdx-correct@1.0.2
│ │ │ └── spdx-license-ids@1.2.2
│ │ └── spdx-expression-parse@1.0.4
│ └── path-type@1.1.0
├── require-directory@2.1.1
├── require-main-filename@1.0.1
├── set-blocking@2.0.0
├─┬ string-width@1.0.2
│ ├── code-point-at@1.1.0
│ └─┬ is-fullwidth-code-point@1.0.0
│ └── number-is-nan@1.0.1
├── which-module@1.0.0
├── y18n@3.2.1
└── yargs-parser@4.2.1
Ja nie stawiałem sobie serwera kafelków, ale do testowania stylu zainstalowałem Kosmtika, który te wszystkie zależności (w tym Mapnika i CartoCSS) ma już zdefiniowane. To też przydatne narzędzie, więc w razie czego można skorzystać z jego konfiguracji.
Generalnie zajmuje mnie postawienie serwera sporo czasu gdyż walczę by przy tej okazji wszystkie istotne zależności wyłapać i napisać do tego skrypty instalacyjne pod Gentoo (zamieszczone przeze mnie wcześniej w linku ebuildy) by w razie jak ktoś będzie chciał serwer kiedyś postawić miał ułatwione zadanie.
Po dodaniu tych pakietów carto zaczęło śmigać i utworzyło plik osm.xml na podstawie stylu openstreetmap-carto w tym ustawienia fontów
...
<FontSet name="fontset-0">
<Font face-name="Noto Sans UI Regular"/>
<Font face-name="Noto Sans CJK JP Regular"/>
<Font face-name="Noto Sans Armenian Regular"/>
<Font face-name="Noto Sans Balinese Regular"/>
<Font face-name="Noto Sans Bamum Regular"/>
<Font face-name="Noto Sans Batak Regular"/>
<Font face-name="Noto Sans Bengali UI Regular"/>
<Font face-name="Noto Sans Buginese Regular"/>
...
tyle że renderd dziwnie na to zareagował gdyż mimo, że fonty prawidłowo załadował
renderd -f
renderd[11262]: Rendering daemon started
renderd[11262]: Initiating reqyest_queue
renderd[11262]: Parsing section renderd
renderd[11262]: Parsing render section 0
renderd[11262]: Parsing section mapnik
renderd[11262]: Parsing section default
renderd[11262]: config renderd: unix socketname=/var/run/renderd.sock
renderd[11262]: config renderd: num_threads=4
renderd[11262]: config renderd: num_slaves=0
renderd[11262]: config renderd: tile_dir=/var/lib/mod_tile
renderd[11262]: config renderd: stats_file=/var/run/renderd.stats
renderd[11262]: config mapnik: plugins_dir=/usr/lib/mapnik/input
renderd[11262]: config mapnik: font_dir=/usr/share/fonts/noto
renderd[11262]: config mapnik: font_dir_recurse=1
renderd[11262]: config renderd(0): Active
renderd[11262]: config renderd(0): unix socketname=/var/run/renderd.sock
renderd[11262]: config renderd(0): num_threads=4
renderd[11262]: config renderd(0): tile_dir=/var/lib/mod_tile
renderd[11262]: config renderd(0): stats_file=/var/run/renderd.stats
renderd[11262]: config map 0: name(default) file(/opt/osm/osm.xml) uri(/osm/) htcp() host(tile.openstreetmap.org)
renderd[11262]: Initialising unix server socket on /var/run/renderd.sock
renderd[11262]: Created server socket 4
renderd[11262]: Renderd is using mapnik version 3.0.12
renderd[11262]: DEBUG: Loading font: /usr/share/fonts/noto/NotoSerifArmenian-Regular.ttf
renderd[11262]: DEBUG: Loading font: /usr/share/fonts/noto/NotoSansGujarati-Regular.ttf
renderd[11262]: DEBUG: Loading font: /usr/share/fonts/noto/NotoSerifGujarati-Bold.ttf
renderd[11262]: DEBUG: Loading font: /usr/share/fonts/noto/NotoSansAvestan-Regular.ttf
renderd[11262]: DEBUG: Loading font: /usr/share/fonts/noto/NotoSansOsmanya-Regular.ttf
renderd[11262]: DEBUG: Loading font: /usr/share/fonts/noto/NotoSansGujarati-Bold.ttf
renderd[11262]: DEBUG: Loading font: /usr/share/fonts/noto/NotoSansBalinese-Regular.ttf
...
to jednak później poinformował, że stosownych fontów odnaleźć nie może
...
renderd[11262]: DEBUG: Loading font: /usr/share/fonts/noto/NotoSansTelugu-Regular.ttf
renderd[11262]: DEBUG: Loading font: /usr/share/fonts/noto/NotoSansTelugu-Bold.ttf
Running in foreground mode...
renderd[11262]: Starting stats thread
debug: init_storage_backend: initialising file storage backend at: /var/lib/mod_tile
renderd[11262]: Loading parameterization function for
debug: init_storage_backend: initialising file storage backend at: /var/lib/mod_tile
renderd[11262]: Loading parameterization function for
debug: init_storage_backend: initialising file storage backend at: /var/lib/mod_tile
renderd[11262]: Loading parameterization function for
debug: init_storage_backend: initialising file storage backend at: /var/lib/mod_tile
renderd[11262]: Loading parameterization function for
Mapnik LOG> 2017-01-21 18:40:12: warning: unable to find face-name 'Noto Sans UI Regular' in FontSet 'fontset-0'
Mapnik LOG> 2017-01-21 18:40:12: warning: unable to find face-name 'Noto Sans CJK JP Regular' in FontSet 'fontset-0'
Mapnik LOG> 2017-01-21 18:40:12: warning: unable to find face-name 'Noto Sans UI Regular' in FontSet 'fontset-0'
Mapnik LOG> 2017-01-21 18:40:12: warning: unable to find face-name 'Noto Sans CJK JP Regular' in FontSet 'fontset-0'
Mapnik LOG> 2017-01-21 18:40:12: warning: unable to find face-name 'Noto Sans UI Regular' in FontSet 'fontset-0'
Mapnik LOG> 2017-01-21 18:40:12: warning: unable to find face-name 'Noto Sans CJK JP Regular' in FontSet 'fontset-0'
Mapnik LOG> 2017-01-21 18:40:12: warning: unable to find face-name 'Noto Sans UI Regular' in FontSet 'fontset-0'
Mapnik LOG> 2017-01-21 18:40:12: warning: unable to find face-name 'Noto Sans CJK JP Regular' in FontSet 'fontset-0'
Mapnik LOG> 2017-01-21 18:40:12: warning: unable to find face-name 'Noto Sans Bengali UI Regular' in FontSet 'fontset-0'
Mapnik LOG> 2017-01-21 18:40:12: warning: unable to find face-name 'Noto Sans Devanagari UI Regular' in FontSet 'fontset-0'
...
Jak ten problem naprawić?
EDIT:
Problem z fontami okazał się banalny gdyż po prostu Gentoo nie instaluje wszystkich fontów ttf jakie zawierają się obecnie w pakiecie https://noto-website-2.storage.googleapis.com/pkgs/Noto-hinted.zip
Problem poważniejszy, gdyż baza jest uruchomiona
#/etc/init.d/postgresql-9.6 status
* status: started
# ps -A |grep postgr
20408 ? 00:00:00 postgres
20411 ? 00:00:00 postgres
20412 ? 00:00:00 postgres
20413 ? 00:00:00 postgres
20414 ? 00:00:00 postgres
20415 ? 00:00:00 postgres
a tym czasem wieści na które wcześniej nawet nie zwróciłem uwagi, a chyba jednak złe
renderd[30418]: An error occurred while loading the map layer 'default': Postgis Plugin: KATASTROFALNY: rola "root" nie istnieje
Connection string: ' dbname=gis connect_timeout=4'
encountered during parsing of layer 'landcover-low-zoom' in Layer at line 502 of '/mnt/4tb/nagrania/osm/wmyrda-style/wmyrda.xml'
renderd[30418]: An error occurred while loading the map layer 'default': Postgis Plugin: KATASTROFALNY: rola "root" nie istnieje
Connection string: ' dbname=gis connect_timeout=4'
encountered during parsing of layer 'landcover-low-zoom' in Layer at line 502 of '/mnt/4tb/nagrania/osm/wmyrda-style/wmyrda.xml'
renderd[30418]: An error occurred while loading the map layer 'default': Postgis Plugin: KATASTROFALNY: rola "root" nie istnieje
Connection string: ' dbname=gis connect_timeout=4'
encountered during parsing of layer 'landcover-low-zoom' in Layer at line 502 of '/mnt/4tb/nagrania/osm/wmyrda-style/wmyrda.xml'
renderd[30418]: An error occurred while loading the map layer 'default': Postgis Plugin: KATASTROFALNY: rola "root" nie istnieje
Connection string: ' dbname=gis connect_timeout=4'
encountered during parsing of layer 'landcover-low-zoom' in Layer at line 502 of '/mnt/4tb/nagrania/osm/wmyrda-style/wmyrda.xml'
Ktoś ma pomysł jak się tego pozbyć?
Strzelam, że trzeba będzie w psql zrobić CREATE ROLE root WITH login superuser;
Strzał celny!
W zasadzie wydaje się, że wszystko działa gdyż doszło do tego etapu
renderd[15838]: Using web mercator projection settings
renderd[15838]: Using web mercator projection settings
renderd[15838]: Using web mercator projection settings
renderd[15838]: Using web mercator projection settings
Tylko kiedy będą się generować kafelki? Przy odwiedzeniu strony czy da się to jakoś przyspieszyć by czekały gotowe przynajmniej dla tych najpopularniejszych zoomów?
EDIT:
W stylu jeszcze nic nie zmieniłem a tu można powiedzieć cierpię na pewien nadmiar urodzaju w nazwach 
Skąd te różnice?
https://justpaste.it/12ogg
Czy ktoś może wie jak spowodować by nazwa obiektu wpierw wyświetlała się w języku polskim[name:pl], następnie przykładowo angielskim [name:en] jeśli polski jest niedostępny i dopiero przy braku tych obu ukazywało standardowe pole [name]?
czy np. taka zmiana była by odpowiednia?
text-name: "[name]";
na
text-name: "'nazwa'";[id=~'.*0$'] {text-name: "[name:pl]";}[id=~'.*1$'] {text-name: "[name:en]";}[id=~'.*2$'] {text-name: "[name]";}
Nie wiem, ale na pewno najpierw trzeba te nazwy wyciągnąć SQL-em z bazy w project.mml.
Jako przykład możesz wykorzystać francuski styl, który jest forkiem osm-carto, i który wyświetla “name:fr”:
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.