Оновлення бази даних правками з OpenStreetMap за допомогою Osmosis

Щодня зʼявляються мільйони нових оновлень на мапі, щоб не допустити, щоб ваша мапа стала «застарілою», ви можете регулярно оновлювати дані, які використовуються для створення тайлів.

Якщо ви використовуєте останню версію osm2pgsql (версія 1.4.2 та свіжіше) то спробуйте скористатись новою інструкцією. Це особливо корисно, якщо ви хочете використовувати джерело оновлення, яке точно відповідає вашій області завантаження (наприклад, Geofabrik може надавати щоденні оновлення для своїх областей завантаження), і вам не треба перейматись автоматичним позначенням оновлених тайлів як «dirty», щоб примусово додати їх до черги на перегенерацію. Якщо використання osm2pgsql для реплікації даних – це не ваш варіант, то читайте далі…

Тут для оновлення даних в нашій базі ми будемо використовувати osmosis, це призведе також до встановлення Java. osmosis – інструмент загального призначення для роботи з даними OpenStreetMap, і одним із його призначень є оновлення даних в базі свіжими змінами з OpenStreetMap. Крім нього є й інші, наприклад, osmium.

sudo apt install osmosis

Також використовується скрипт trim_osc.py для зменшення обсягу оновлень отримуємих з https://planet.osm.org/, до розміру потрібної нам території. Це дозволить запобігти неконтрольованому росту бази postgres.

cd ~/src
git clone https://github.com/zverik/regional
chmod u+x ~/src/regional/trim_osc.py

sudo apt install python3-shapely python3-lxml

Якщо ви використовували інструкцію для Ubuntu, у вас вже є скрипти потрібні для наступних дій, для Debian вам потрібно встановити їх вручну:

cd ~/src
git clone -b switch2osm https://github.com/SomeoneElseOSM/mod_tile
cd mod_tile

Ми будемо використовувати скрипт openstreetmap-tiles-update-expire для отримання оновлень з OpenStreetMap. В цьому прикладі задамо потрібну територію:

TRIM_REGION_OPTIONS="-b -14.17 48.85 2.12 61.27"

Цей прямокутник покриває Великобританію; змінюйте ці значення відповідно до ваших потреб. Також ви можете використовувати файл .poly, який містить опис меж потрібної ділянки.

Вкажемо обліковий запис:

ACCOUNT=renderaccount

Для ваших потреб обирайте потрібний обліковий запис (не root), який використовується для запуску служб mod_tile та отримання даних regional. В Debian 11 це буде обліковий запис відмінний від того, що використовується для сервісу рендерінгу тайлів.

Також треба взяти до уваги, що можливо вам доведеться змінити OSM2PGSQL_OPTIONS на посилання на скрипт lua по перетворенню теґів, який ви використовуєте для завантаження даних в базу та додайте файл “.style”, який визначає які стовпці потрібно створити. Можуть бути й інші параметри, які вам також потрібно передати, залежно від того, що ви використовували під час створення бази даних. Замініть також “/path/to/” відповідно:

OSM2PGSQL_OPTIONS="-d $DBNAME --tag-transform-script /path/to/src/openstreetmap-carto/openstreetmap-carto.lua -S /path/to/src/openstreetmap-carto/openstreetmap-carto.style"

Далі, створимо теку для логів для журналів актуальності тайлів та вкажемо власником обліковий запис, який використовується для рендерінгу тайлів (для Debian 11 це буде – _renderd). Скрипт має запускатись від імені цього облікового запису, а через те, що обліковий запис відмінний від того, з яким було завантажене програмне забезпечення, нам потрібно передавати повний шлях до скрипту (замініть /path/to на відповідний).

Параметр передаваємий у скрипт openstreetmap-tiles-update-expire має бути вік початково завантажених даних. Якщо ви завантажували дані з Geofabrik, це має бути відповідна дата зі сторінки, наприклад, http://download.geofabrik.de/asia/azerbaijan.html, коли дані для прикладу були вами завантажені.

sudo mkdir /var/log/tiles
sudo chown renderaccount /var/log/tiles
sudo -u renderaccount /path/to/src/mod_tile/openstreetmap-tiles-update-expire 2020-11-14T21:42:02Z

Останній рядок виводу має виглядати приблизно так

2020-11-15 23:50:16 (2.62 MB/s) - ‘/var/lib/mod_tile/.osmosis/state.txt’ saved [342/342]

Це говорить про створення теки .osmosis у /var/lib/mod_tile, яка містить інформацію про останні імпортовані дані.

В одній ssh сесії із сервером виконайте:

tail -f /var/log/tiles/run.log

В іншій:

sudo -u renderaccount /path/to/src/mod_tile/openstreetmap-tiles-update-expire

не забудьте замінити шлях на шлях у вашій системі; але цього разу без параметрів.

Якщо ви бачите наступне:

openstreetmap-tiles-update-expire: 1: python: not found

не хвилюйтесь, це лише перевірка дискового простору.

Вміст лог-файлу має бути схожий на наступне:

[2020-11-15 23:58:28] 3850 start import from seq-nr 4283484, replag is 1 day(s) and 2 hour(s)
[2020-11-15 23:58:28] 3850 downloading diff
[2020-11-15 23:59:31] 3850 filtering diff
[2020-11-15 23:59:58] 3850 importing diff
[2020-11-16 00:01:23] 3850 expiring tiles
[2020-11-16 00:01:23] 3850 Done with import

В replag міститься різниця в часі між наявними та актуальними даними; типово налаштовано на годинні діфи. Якщо це не спрацьовує – перевірте чи osmosis правильно встановлено та ви можете запускати його в командному рядку.

Запустіть openstreetmap-tiles-update-expire знов; значення в replag має зменшитись на годину.

Далі, налаштуємо запуск openstreetmap-tiles-update-expire в crontab з інтервалом у кілька хвилин. Це треба робити для користувача, який використовується для рендерінгу; для Debian 11 зробимо наступне:

sudo -u _renderd crontab -e

Можливо ви побачите “problems with history file” – не хвилюйтесь. В системах відмінних від Debian 11 у вас можливо вийде запускати crontab -e безпосередньо від імені користувача відповідального за рендерінг тайлів. Під час першого запуску crontab -e вам буде запропоновано обрати редактор. Перейдіть в кінець файлу. Рядки, що починаються з # є коментарями. Останній рядок коментаря виглядатиме так:

# m h  dom mon dow   command

Це відповідно m – хвилини, h – години, dom – день місяця, mon – місяць, dow – день тижня та comand – команда. Додамо наступний рядок:

*/5  * *   *   *     /home/renderaccount/src/mod_tile/openstreetmap-tiles-update-expire

для запуску скрипту кожні 5 хвилин. Замініть renderaccount на відповідний обліковий запис, під яким знаходиться ваш скрипт. Стежте за виводом tail -f /var/log/tiles/run.log та почекайте 5 хвилин. Врешті-решт, відставання буде подолане, і нові зміни з OpenStreetMap також зʼявляться у ваших тайлах.

Потенційні проблеми з оновленнями

Якщо помилка “Expiry failed” зʼявляється у /var/log/tiles/run.log, це скоріш за все повʼязано з тим що одна з програм, що використовується render_expired має недостатньо памʼяті для роботи. Якщо це так, зменшіть значення EXPIRY_MAXZOOM в скрипті допоки він не запрацює. Ви також можете отримати більше деталей з інших файлів з /var/log/tiles/.

Якщо зʼявляється помилка “rm: cannot remove ‘/var/lib/mod_tile/dirty_tiles.6877’:”, це може означати, що під час роботи osm2pgsql відбувся збій і не було створено перелік файлів для перестворення в кінці роботи. Розташування файлу журналу, який він створює, знаходиться вище в скрипті. Типово, це /var/log/tiles/osm2pgsql.log, і якщо ви заглянете туди, ви побачите фактичну помилку.

Налаштування munin

У разі використання munin для отримання звітів про активність mod_tile та renderd, ви можете налаштувати його для показу часу відставання ваших даних від даних з основної бази через читання файлу state.txt:

sudo nano /etc/munin/plugins/replication_delay

Сам скрипт можна взяти тут. Можливо вам доведеться внести деякі зміни, щодо розташування файлів, які використовуються скриптом (/var/cache/renderd або /var/lib/mod_tile). Після чого перезапустіть службу:

sudo /etc/init.d/munin-node restart

Після деякої паузи, оновіть http://ip.адреса.вашого.сервера/munin/renderd-day.html, має показувати графік “Data import lag”. Якщо ні, перевірте логи /var/log/munin. Якщо вам потрібно більше контексту для розуміння того що відбувається ознайомтесь з документацією munin.