Оновлення бази даних правками з OpenStreetMap за допомогою Osmosis⚓︎
Щодня зʼявляються мільйони нових оновлень на мапі, щоб не допустити, щоб ваша мапа стала «застарілою», ви можете регулярно оновлювати дані, які використовуються для створення тайлів.
Якщо ви використовуєте останню версію osm2pgsql (версія 1.4.2 та свіжіше) то спробуйте скористатись новою інструкцією. Це особливо корисно, якщо ви хочете використовувати джерело оновлення, яке точно відповідає вашій області завантаження (наприклад, Geofabrik може надавати щоденні оновлення для своїх областей завантаження). Якщо використання osm2pgsql для реплікації даних – це не ваш варіант, то читайте далі…
Тут для оновлення даних в нашій базі ми будемо використовувати osmosis, це призведе також до встановлення Java. osmosis – інструмент загального призначення для роботи з даними OpenStreetMap, і одним із його призначень є оновлення даних в базі свіжими змінами з OpenStreetMap. Крім нього є й інші, наприклад, osmium.
(у відповідь маємо отрмиати "done".)
Також використовується скрипт trim_osc.py для зменшення обсягу оновлень отримуємих з OpenStreetMap.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 вам потрібно встановити їх вручну:
Ми будемо використовувати скрипт openstreetmap-tiles-update-expire для отримання оновлень з OpenStreetMap. В цьому прикладі задамо потрібну територію:
Цей прямокутник покриває Великобританію; змінюйте ці значення відповідно до ваших потреб. Також ви можете використовувати файл .poly, який містить опис меж потрібної ділянки.
Вкажемо обліковий запис:
Для ваших потреб обирайте потрібний обліковий запис (не root), який використовується для запуску служб mod_tile та отримання даних "regional". В Debian 11 це буде обліковий запис відмінний від того, що використовується для сервісу рендерінгу тайлів.
Переконайтесь, що скрипт НЕ містить рядок -e$EXPIRY_METAZOOM:$EXPIRY_METAZOOM. Якщо він є, замініть : на -: -e$EXPIRY_METAZOOM-$EXPIRY_METAZOOM.
Також треба взяти до уваги, що можливо вам доведеться змінити 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
Останній рядок виводу має виглядати приблизно так
Це говорить про створення теки .osmosis у /var/lib/mod_tile, яка містить інформацію про останні імпортовані дані.
В одній ssh сесії із сервером виконайте:
В іншій:
не забудьте замінити шлях на шлях у вашій системі; але цього разу без параметрів.
Якщо ви бачите наступне:
не хвилюйтесь, це лише перевірка дискового простору.
Вміст лог-файлу має бути схожий на наступне:
[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 зробимо наступне:
Можливо ви побачите "problems with history file" – не хвилюйтесь. В системах відмінних від Debian 11 у вас можливо вийде запускати crontab -e безпосередньо від імені користувача відповідального за рендерінг тайлів. Під час першого запуску crontab -e вам буде запропоновано обрати редактор. Перейдіть в кінець файлу. Рядки, що починаються з # є коментарями. Останній рядок коментаря виглядатиме так:
Це відповідно m – хвилини, h – години, dom – день місяця, mon – місяць, dow – день тижня та comand – команда. Додамо наступний рядок:
для запуску скрипту кожні 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:
Сам скрипт можна взяти тут. Можливо вам доведеться внести деякі зміни, щодо розташування файлів, які використовуються скриптом (/var/cache/renderd або /var/lib/mod_tile). Після чого перезапустіть службу:
Після деякої паузи, оновіть http://ip.адреса.вашого.сервера/munin/renderd-day.html, має показувати графік "Data import lag". Якщо ні, перевірте логи /var/log/munin. Якщо вам потрібно більше контексту для розуміння того що відбувається ознайомтесь з документацією munin.