Switch2OSM

Керуйте вашими мапами самі

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

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

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

Для оновлення даних в нашій базі ми будемо використовувати 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 git://github.com/SomeoneElseOSM/mod_tile.git
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, і якщо ви заглянете туди, ви побачите фактичну помилку.