Własny serwer kafelków

To też wszyscy słyszeli już nie raz. Może kolega wskazać link do stosownego opis jak tego dokonać? Tyle o tym słyszałem, że aż chętnie bym spróbował

[AKTUALIZACJA:] Wydzieliłem ten wątek z dyskusji w innym wątku, bo jest konkretny i może się przydać - kocio.

Ręczna instalacja serwera kafelków (nie sprawdzałem czy akurat ze stylem osm-carto):

https://switch2osm.org/serving-tiles/manually-building-a-tile-server-14-04/

Na podstawie tych instrukcji powstał nawet gotowy obraz Dockera, więc powinno być jeszcze prościej:

https://hub.docker.com/r/xingfuryda/openstreetmap-tiles-docker/

Znalazłem również opis pod Gentoo http://wiki.openstreetmap.org/wiki/Deploying_your_own_Slippy_Map_Gentoo Tak czy owak w jednym i drugim opisie brakuje mnie wyjaśnienia szeregu kwestii

Czy ten krok jest konieczny przy dziennych importach zmian? Jeśli ściągniemy plik zmian o wielkości 1-2MB z http://download.geofabrik.de/europe/poland-updates/000/001/ to będzie można wskazać renderowi jedynie tą część do wykoanania zmian czy proces renderingu będzie musiał przebiegać dla całego kraju co ma 900MB? Jeśli tak to ile orientacyjne potrwa on na i3-4130@3,40GHz/16GB RAM/Raid ZFS 4x4TB HDD NAS?
Swoją drogą może ktoś służyć gotowcem to instalacji różnic?
Czy jeśli zdecydujemy się na jedno województwo to jak zrobić by mieć dwa. osm2pgsql można wskazać więcej jak jeden plik pbf? Będą się uzupełniać czy przy granicach nakładać?

Opis instalacji carto jest dość pobieżny nie mówiąc o tym, że kwestii omówienia dodania tam własnych rzeczy jak ikony do obiektów nie renderowanych na carto brak. Chwilę zajmie by się przed kod przekopać i zobaczyć co gdzie by należało umieścić jak choćby w tym przykładzie https://github.com/gravitystorm/openstreetmap-carto/commit/34542e07c11b1596b8ff36938e2b4c52a86a0cc2

Reasumując jak widzę opisy to jak się sprężę to zrobię, choć nie wiem czy zostało mnie wystarczająco włosów by ich resztę powyrywać z głowy, gdyż szlag mnie będzie trafiał jak się okażę, że pominąłem jakiś banalny krok. Co najgorsze to śmiem twierdzić, że zwykły śmiertelnik co przyszedł skorzystać z przyzwoitej mapy nie ma tu wielkich szans.

Zwykły śmiertelnik nie potrafi mapować i nie wie co to ortofoto, więc jesteś co najmniej poziom wyżej, więc Ciebie to nie dotyczy :wink:

Ten etap (osm2pgsql) nie wykonuje renderingu, tylko ładuje dane do Postgresa. Więc po inicjalnym załadowaniu, jak będziesz ladowal pliki zmian (np. za pomocą osmosis + osm2pgsql), to idzie to szybko.

Renderem zajmuje się renderd. osmosis może wygenerować listę kafli do wywalenia za cache podczas ładowania diff’a o ile dobrze pamiętam.

O sobie akurat tu nie mówiłem, gdyż mam za sobą 15 lat administrowania maszynami Linuksowymi, głównie Gentoo gdzie dosłownie wszystko trzeba zrobić samemu od początku do końca i nawet jak się poda innym na tacy w zgłoszeniu wraz z rozwiązaniem to i tak nic z tym nie zrobią. Na dzień dzisiejszy wisi 57 zgłoszeń, które zgłosiłem a którymi nie ma się kto zająć mimo, że większość wspomniane gotowe rozwiązanie ma https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&email1=vojcek%40tlen.pl&emaillongdesc1=1&emailreporter1=1&emailtype1=substring&list_id=3411282&query_format=advanced&resolution=— także co nie co wiem o instalacjach i konfiguracjach czy zgłaszaniu błędów.

@WiktorN dzięki za wyjaśnienie. Zobaczymy spróbuję podjąć rękawicę.

Instalowałem kiedyś osm-carto i nie miałem wrażenia pobieżności, bo jak się zainstaluje zależności, to chyba tylko kwestia pobrania katalogu. W razie potrzeby chętnie pomogę, wyjaśnię albo sprawdzę.

Jeśli idzie o zmiany w samym stylu (dodawanie, poprawki itp.), to tym bardziej mogę pomóc, bo w tym siedzę od dawna. Zmiany testuję w Kosmtiku (to oznacza 64-bitowe środowisko pracy). Rzeczywiście nie ma żadnej instrukcji zmian w kodzie, ja się nauczyłem właśnie naśladując istniejący kod dla podobnych obiektów i to w większości wystarcza. Zasadniczo obecnie mamy jeden plik zawierający zapytania SQL do wyciągania danych z bazy (project.mml - do niedawna nazywał się project.yaml i trzeba go było konwertować skryptem), a samo stylowanie jest rozproszone po różnych plikach .MSS plus katalog na ikony i wzorki.

Plik YAML-owy ma zdefiniowanych 79 warstw, ale po nazwach można się z grubsza zorientować co one robią, a najtrudniejszy jest tam SQL. Nazwy plików MMS też są dosyć zrozumiałe. Opis elementów dostępnych w CartoCSS jest w dokumentacji na GitHubie.

poczytałem nieco i na start się okazało, że ZFS na bazę postgresową się nie na daje zupełnie :wink: http://www.slideshare.net/fuzzycz/postgresql-on-ext4-xfs-btrfs-and-zfs

Do tego jak o w Gentoo wydanie polecenia

emerge -pv dev-db/postgis sci-geosciences/osm2pgsql

spowodowało, że aplikacje chcą zainstalować dwie różne wersje bazy postegre - osm2pgsql wersję 9.6, a postgis 9.5 :slight_smile:
Przy okazji dowiedziałem się, że postgis wymaga by sci-libs/gdal zainstalować wraz z zależnościami do opencl. Rozumiem, że to jest pomocne jak się ma wydajną kartę graficzną, ale ja nie ma żadnej po za tą wolną na procesorze to jest to i tak konieczne? Oczywiście mogę zrobić tak by pominąć opencl by nie instalował mnie kilkunastu dodatkowych pakietów, ale nie okaże się wówczas, że postgis przestanie działać?

Mi to w domowych zastosowaniach zupełnie nie przeszkadza. A Oracle sprzedaje appliance z ZFS-em m.in. jako storage backend pod Oracle’a, więc nie sądzę, by ZFS nie nadawał się pod bazy.

Ciekawe, bo jedno i drugie w sumie powinno opierać się na postgis-ie, więc coś nie tak (przypuszczam że z pakietem osm2pgsql).

GDAL jest potrzebny, ale nie musi wykorzystywać OpenCI. Myślę, że całe OpenCI możesz wywalić z GDAL-a.

Całkiem możliwe, że ZFS był testowany na pojedynczym dysku a nie na macierzy by porównać z innymi wprost. Musiał bym się dokładnie przyglądnąć, ale jednak Oracle ze swoim ZFS to co innego niż zfsonlinux

Podałem raczej jako ciekawostkę jak gdyż wynika to z faktu, że postgis w repozytorium Gentoo jest tylko w wersji 2.2.2, a do wersji 9.6 sqla potrzebny jest co najmniej 2.3.x. Jak przetestuję to zaś trzeba będzie uzupełnić kolejnego buga https://bugs.gentoo.org/show_bug.cgi?id=600384 :wink:

Tak podejrzewałem. Jednak błąd w skrypcie ebuild od Gentoo
EDIT: A Jednak u mnie. Miałem w jednym miejscu niepotrzebnie dodaną flagę opencl. Ebuildy są prawidłowe

AFAIK to Oracle tak dużo feature’ow nie dopisał do ZFS. Ja swoją bazkę mam na mirrorze z dysków SSD klasy “konsumenckiej”. Z tego co pamiętam w parę godzin ładowanie Polski się zamknęło. Pewnie niedługo będę to przenosił na mirror na dyskach HDD, i może przy okazji przeniosę to na ZVOL-a.

Tyle że ja działam na FreeBSD, YMMV.

Swoje wrażenia spisuje w formie brudnopisu. Jak się proces mnie powiedzie to tutaj opublikuję. Na chwilę obecną korzystając z http://wiki.openstreetmap.org/wiki/Deploying_your_own_Slippy_Map_Gentoo doszedłem do sekcji Importing using osm2pgsql. Operacja się powiodła https://justpaste.it/12h7k ale wówczas doczytałem i tak http://wiki.openstreetmap.org/wiki/Osm2pgsql#hstore pisze by do bazy dodać również CREATE EXTENSION hstore;. Czy utworzona baza będzie z tego korzystać skoro utworzyłem ją wcześniej niż dodałem to rozszerzenie do bazy?
Kolejna sprawa to co muszę zrobić by bazę jednak podmienić zgodnie z drugą propozycją komendy czyli

osm2pgsql -U <user> --bbox minlon,minlat,maxlon,maxlat -m -d <db> <planet-file>

gdyż rzecz jasna wystarczy mnie dużo mniejszy obszar niż cały świat który i tak w większości jest pusty. Może należy usunąć to co wprowadziłem dotychczas? W jakim formacie podać wymagane współrzędne?

Wydaje mi się, że hstore musi być dostępne przed importem bazy, inaczej część danych nie zostanie w ogóle zaimportowana.

Obecnie osm-carto nie korzysta jeszcze z dobrodziejstw hstore, bo ciągle jeszcze nie została dopracowana gałąź lua, to pewnie jeszcze kwestia bardziej miesięcy niż tygodni.

No ja generalnie - zamiast robić bbox’owanie pliku planet, pociągnąłem plik z gotowym wycinkiem dla Polski, a następnie dla osmosis’a mam taką konfigurację:

$ cat configuration.txt
# The URL of the directory containing change files.
baseUrl=http://download.geofabrik.de/europe/poland-updates/
baseUrl=http://download.openstreetmap.fr/replication/europe/poland/minute/

Co daje mi minutowe pliki różnicowe tylko dla Polski. Pierwszy URL - z Geofabrik daje pliki różnicowe per dzień, drugi - od Francuzów, daje minutowe pliki różnicowe.

Teraz, co do hstore’a. To tak - musisz założyć najpierw hstore, a potem odpalić ładowanie danych. Dzięki temu dla wszystkich danych będzie dostępny hstore. Istotne jest, by dodać rozszerzenie przed rozpoczęciem ładowania - nie jest konieczne, by było dodane przed

CREATE DATABASE

Tylko tu kocio może mnie poprawić - domyślny styl nie korzysta z hstore’a, bo to wiązałoby się z przeładowaniem całej bazy dla całego świata, na co nikt nie poświęcił do tej pory zasobów. Ale może to już się zmieniło?

EDIT: kocio już się wypowiedział na ten temat post wyżej :slight_smile:

OK

Czy to oznacza, że w obecnym kodzie nawet jak w bazie mamy hstore to i tak nic więcej z bazy nie wyciągniemy i instalacja kilku dodatkowych ikon będzie niemożliwa? Czy też raczej chodzi o to, że działać będzie tyle, że będą ograniczenia i nie wszystko będzie się dało wyrenderować?

To też ważna informacja. Nigdzie nie widziałem potwierdzenia, że jak użyje pliku tylko dla jednego kraju czy województwa to automatycznie mam mapę do niego ograniczoną i nie muszę martwić się o oglądanie reszty pustego świata.
A co w przypadku jak będę chciał wykorzystać dwa kraje czy dwa województwa przy generowaniu bazy? Obszary się dodadzą czy też trzeba będzie bboxy dla połączonych obszarów wskazać?
EDIT:
Sprawdziłem, że jednak nie da się wskazać dwóch plików jednocześnie i należy posłużyć się większym rozmiarowo obszarem, gdyż użycie dwóch wycinków z bazy spowoduje, że przy imporcie natrafimy na obiekty z identycznym iD i cały proces się przerwie w wyniku błędu

osm2pgsql version 0.92.0 (64 bit id space)

Using built-in tag processing pipeline
Using projection SRS 3857 (Spherical Mercator)
Setting up table: planet_osm_point
Setting up table: planet_osm_line
Setting up table: planet_osm_polygon
Setting up table: planet_osm_roads
Allocating memory for dense node cache
Allocating dense node cache in one big chunk
Allocating memory for sparse node cache
Sharing dense sparse
Node-cache: cache=500MB, maxblocks=8000*65536, allocation method=11
Mid: pgsql, scale=100 cache=500
Setting up table: planet_osm_nodes
Setting up table: planet_osm_ways
Setting up table: planet_osm_rels

Reading in file: /mnt/4tb/nagrania/osm/malopolskie-latest.osm.pbf
Applying Bounding box: 13.900000,48.900000 to 24.500000,55.000000
Using PBF parser.
Processing: Node(10215k 309.6k/s) Way(1218k 93.71k/s) Relation(9430 554.71/s)  parse time: 63s

Reading in file: /mnt/4tb/nagrania/osm/podkarpackie-latest.osm.pbf
Applying Bounding box: 13.900000,48.900000 to 24.500000,55.000000
Using PBF parser.
node cache: stored: 10215184(100.00%), storage efficiency: 50.47% (dense blocks: 93, sparse nodes: 9739806), hit rate: 100.00%
Osm2pgsql failed due to ERROR: insert_node failed: BŁĄD:  podwójna wartość klucza narusza ograniczenie unikalności "planet_osm_nodes_pkey"
DETAIL:  Klucz (id)=(30374648) już istnieje.
(7)
Arguments were: 30374648, 667078829, 167364111, <NULL>,

real    1m4,423s
user    0m38,554s
sys     0m1,032s

Kwestia ograniczenia do pewnego wycinka wydaje się prostsza, ale w jakim formacie mam zastąpić wartości minlon,minlat,maxlon,maxlat by zbudować bbox powiedzmy o takich koordynatach?

prawo góra 49.97/21.812
prawo dół 49.95/21.812
lewo góra 49.97/21.739
lewo dół 49.95/21.739

21.739,49.95,21.812,49.97 składnia będzie poprawna?

Wszystko działa, tylko trzeba dołożyć dodatkowy kod jeśli chcemy obsługiwać nowe typy obiektów. hstore daje nam po prostu “zapas” danych, z którego obecnie osm-carto nie umie skorzystać.

Bry.

To tak - ja importuję tylko prostokąt z Polską + jakieś 50km. Zajmuje to około 4-6h.

Do utworzenia zestawu danych do importu używam ekstraktów z geofabrik, które później przycinam do prostokąta.

Wybrałem prostokąt bo osmosis nie pozwala (jak się nie mylę) filtrowania danych diff za pomocą poly, więc filtrować możesz tylko w osm2pgsql, który zaś obsługuje tylko bbox, więc jak masz jedno państwo nie przycięte do bboxa to diffy dodają Ci śmieci za granicami.

Osm2Pgsql importuje dane do bazy zgodnie z plikiem default.style - jeśli nie masz włączonego rozszerzenia hstore i/lub masz wyłączone dodawanie tagów do hstore w osm2pgsql to obiekty, które się nie załapały na jakąś wartość w kolumnie nie zostaną zaimportowane. Hstore się całkiem ładnie indeksuje więc swobodnie można nawet produkcyjnie używać danych w nim zawartych, a jeśli potrzebujesz je jednak w kolumnie to w każdej chwili możesz dodać kolumnę, wypełnić z hstora i poprawić default.style, żeby nowe dane (diff) lądowały już w kolumnie.

Co do samego stylowania to będę miał pytania do bardziej doświadczonych kolegów (na razie nie miałem potrzeby mimo, że kilka takich serwerów już postawiłem… ale jawi się taka koniecznośc w najbliższym czasie), ale z tego co widziałem pobieżnie to tam jest SQL, więc renderd nie powinien zobaczyć różnicy czy w sql będzie ‘select name …’ czy ‘select tags->‘name’ as name’

To nie do końca tak - w jednym z kroków pobierasz i przetwarzasz obszary lądu i wody dla całego świata, więc wynikowo dostaniesz cały świat w tych danych i dokładne dane tylko na pobranym terenie. Ograniczenie tego już tylko po stronie aplikacji. Tak samo przy seedowaniu musisz podać bbox bo inaczej zacznie Ci seedować cały świat :slight_smile:

Zainstalowałem cały szereg pakietów co nie było takie banalne, gdyż opisy w pewnej mierze zdezaktualizowały się, ale w zasadzie wszystko poszło poza jednym pakietem wydzielonym z mapnika a mianowicie python-mapnik. Żebym nie wiem jak kombinował, np. pobierał wszystkie submoduły to zawsze wywala mnie na poniższym błędzie :rage:

x86_64-pc-linux-gnu-g++ -march=native -O2 -pipe -fgcse-sm -fgcse-las -fgcse-after-reload -ftree-vectorize -fabi-version=0 -fPIC -I/usr/include/python3.5m -c src/mapnik_datasource_cache.cpp -o build/temp.linux-x86_64-3.5/src/mapnik_datasource_cache.o -I/usr/include -I/usr/include/mapnik/agg -I/usr/include/mapnik -I/usr/include -I/usr/include/freetype2 -I/usr/include/libxml2 -I/usr/include/gdal -I/usr/include/postgresql-9.6 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/libpng16 -DMAPNIK_MEMORY_MAPPED_FILE -DMAPNIK_HAS_DLCFN -DBIGINT -DBOOST_REGEX_HAS_ICU -DHAVE_JPEG -DMAPNIK_USE_PROJ4 -DHAVE_PNG -DHAVE_WEBP -DHAVE_TIFF -DLINUX -DMAPNIK_THREADSAFE -DBOOST_SPIRIT_NO_PREDEFINED_TERMINALS=1 -DBOOST_PHOENIX_NO_PREDEFINED_TERMINALS=1 -DBOOST_SPIRIT_USE_PHOENIX_V3=1 -DNDEBUG -DHAVE_CAIRO -DGRID_RENDERER -DHAVE_LIBXML2 -std=c++11 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -pthread -ftemplate-depth-300 -Wsign-compare -Wshadow -march=native -pipe -O3 -ftree-vectorize -findirect-inlining
src/mapnik_datasource_cache.cpp:31:34: fatal error: mapnik/value/types.hpp: Nie ma takiego pliku ani katalogu
compilation terminated.

Pliku types.hpp nie ma ani w katalogu src ani mapnik co zresztą potwierdzają źródła https://github.com/mapnik/python-mapnik. Jak sobie z tym poradzić?

EDIT Znalazłem https://github.com/mapnik/python-mapnik/issues/125#issuecomment-264664285
OMFG Python-mapnik nie wspiera stabilnej wersji mapnika czyli serii 3.0.x nawet w najnowszej wersji z git, ech…

Bzę utworzyłem na nowo komendą

osm2pgsql --create --slim \
    --cache 1000 --number-processes 2 --hstore \
    --style ~/osm/openstreetmap-carto/openstreetmap-carto.style --multi-geometry \
    ~/osm/liechtenstein-latest.osm.pbf

oczywiście z lokalnymi zmianami do lokalizacji plików i jest. Zdziwiłem się, że Podkarpackie zajęło aż 3GB czyli dużo więcej niż poprzednio użytą standardową

osm2pgsql -U <user> -m -d <db> <file>

gdzie zajęła jedynie ok 500MB. Rozumiem, że zapewne wszystkiego wcześniej po porostu do bazy nie ładowało.

Nie to jednak jest problemem podstawowym tylko, że wszystko niby działa, ale mapy w apachu brak :wink:

Czy rozumiem najprawdopodobniej ponieważ /etc/renderd.conf odnosi się do nie prawidłowego pliku?


[renderd]
socketname=/var/run/renderd.sock
num_threads=4
tile_dir=/var/lib/mod_tile
stats_file=/var/run/renderd.stats

[mapnik]
plugins_dir=/usr/lib/mapnik/input
font_dir=/usr/share/fonts/truetype
font_dir_recurse=1

[default]
URI=/osm/
TILEDIR=/var/lib/mod_tile
XML=/home/jburgess/osm/svn.openstreetmap.org/applications/rendering/mapnik/osm-local.xml

HOST=tile.openstreetmap.org
TILESIZE=256

Jeśli tak to chętnie bym go utworzył lecz komenda

python generate_xml.py --host localhost --password "" \
        --port 5432 --user osmdb --dbname osmdatabase --world_boundaries=/usr/lib/mapnik/world_boundaries/

wyrzuca następujący błąd

  File "generate_xml.py", line 85
    print mapnik.save_map_to_string(m)
               ^
SyntaxError: invalid syntax

Pomysły?