Хвилинні зміни в OpenStreetMap не такі й хвилинні

OpenStreetMap — це чудовий приклад проєкту зі спільного створення відкритої бази даних геопросторової інформації. Накопичення інформації це тільки частина справи. Її збирають для того, щоб нею можна було користуватись. Ви можете отримати дані для поточної ділянки на мапі скориставшись меню Експорт.

Однак можливості завантажити дані для поточної ділянки мають певні обмеження. Ви не зможете зробити це, якщо ви переглядаєте мапу в масштабі z11 та менше 👇. Бачите повідомлення в жовтому прямокутнику?

Планета OSM

У випадку, коли вам потрібні дані для більшої території, або навіть для всієї планети, вам пряма дорога до місця де проєкт пропонує дані для завантаження — дамп планети, https://planet.openstreetmap.org/

Тут ви можете завантажити дані для всієї планети, як у вигляді зрізу даних на певну дату або у вигляді дампу з повною історією змін, які генерується раз на тиждень.

Ці дані проєкт надає всім охочим безплатно, однак ви можете підтримати проєкт, зробивши пожертву чи ставши членом Фундації OpenStreetMap.

Файли змін даних

Для тих, хто не так глибоко знайомий з проєктом, diffs — це набори змін, що відбулись в даних, які публікуються OpenStreetMap кожного дня, години та хвилини. Ці файли містять перелік усіх змін, внесених до бази даних за обраний проміжок часу.

Розробники можуть використовувати ці diffs для оновлення своїх копій бази даних, які потім використовуються для геокодування, рендерингу мап та інших інструментів майже в режимі реального часу.

Однією з ключових особливостей, що дозволяє стежити за змінами в цій величезній базі даних, є концепція “хвилинних змін” (minute diffs). На перший погляд, назва натякає на майже миттєве відображення кожної зміненої деталі. Але чи справді все так? Звучить ідеально, правда? Але є кілька нюансів, які варто враховувати:

• “Майже” реальний час — ключове слово. Хоча файли змін генеруються щохвилини, їхня фактична поява може затримуватися. Залежно від завантаженості серверів, процес генерації та публікації може зайняти трохи більше часу. Тож, хоча ви й можете побачити зміни протягом кількох хвилин, це не завжди буде рівно одна хвилина.
• Обробка файлів змін — не миттєва. Отримання файлу змін — це лише перший крок. Потім програмне забезпечення повинно завантажити, розпарсити та застосувати ці зміни до локальної копії бази даних. Цей процес також займає певний час, який залежить від розміру файлу змін та продуктивності вашого обладнання. У хвилини пікового внесення змін до OpenStreetMap розмір таких файлів може значно зростати, уповільнюючи процес оновлення.
• Порядок застосування змін має значення. Для забезпечення консистентності даних, зміни повинні застосовуватися в правильному порядку. Це означає, що якщо ви пропустили кілька хвилинних diffs (наприклад, через проблеми з мережею), вам доведеться обробити їх усі послідовно, перш ніж ваша база даних знов буде актуальною.

Використання файлів змін

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

Файл дампу планети в OpenStreetMap генерується раз на тиждень

На момент написання, 08 травня 2025 року, planet-latest.osm.bz2 було створено 2025-05-02 23:50, та його розмір був — 150G; ви також можете отримати дані у двійковому форматі pbf — planet-latest.osm.pbf, 2025-05-02 23:50, 81G; planet-250428.osm.pbf, 2025-05-02 23:50, 81G).

Цей, останній дамп містить дані станом на 25 квітня 2025 року, його було опубліковано — 02 травня 2025 року.

Виходить що на момент публікації дамп вже є на 7 діб застарілим, додайте до цього ще пару днів, коли ви захочете його завантажити, тож у вас на момент початку розгортання дані будуть застарілим на 1-2 тижні, додайте до цього ще час потрібний для завантаження дампу у вашу систему і ви можете виявити, що дані на момент початку їх використання втратили свою актуальність приблизно на 3-5 тижнів (якщо ми говоримо про масштаб планети). Для того щоб наздогнати це відставання та мати актуальні дані варто скористатись файлами реплікації https://planet.openstreetmap.org/replication/, нашими денними, годинними та хвилинними файлами змін.

Процес реплікації

Кожен файл змін містить має додатковий файл з метаданими про сам файл змін — state.txt.

Файл state.txt містить інформацію про часовий відбиток та номер в послідовності наборів змін, за цим номером ми можемо отримати сам файл зі змінами (717.osc.gz, 2025-05-08 17:01, 101K). Для зручності, номер набору змін розбивається на триплети 006/590/717.

Відомості про найсвіжіший файл набору змін міститься в корені відповідних змін, для хвилинних це — https://planet.openstreetmap.org/replication/minute/state.txt.

Для того щоб наздогнати стан ваших локальних даних з поточними даними, що є в OpenStreetMap, вам потрібно визначити часовий відбиток, що є останнім у вашому локальному дампі. Наприклад, у дампі станом на 24 березня 2025 останній відбиток часу був 2025-03-24T00:59:53Z.

Тепер коли у вас є цей час вам потрібно знайти відповідний файл змін (денних чи годинних) та його номер. В цьому вам може допомогти цей сервіс:

https://replicate-sequences.osm.mazdermind.de/?2013-01-01T10:00:00Z

або

curl "https://replicate-sequences.osm.mazdermind.de/?$(date -u -d "@$(stat -c "%Y" planet-latest.osm.pbf)" +"%FT%TZ")"

Пошук файлу змін вручну

Для денних та годинних змін ви також можете скористатись наступним підходом:

• Початковий часовий відбиток (останній з файлу дампа) перетворюємо в Unix epoch time

  date -d "2025-03-24T00:59:53Z" +%s
  # або явно зазначивши формат часового відбитку
  date -u -j -f "%Y-%m-%dT%H:%M:%SZ" "2025-03-24T00:59:53Z" +%s
  

  отримуємо час Unix в секундах 1742777993.

• Отримуємо часовий відбиток з останнього state.txt (відповідно для денних та годинних змін) разом з поточним номером в послідовності змін.
• Обчислюємо різницю в часі (в днях та годинах), отримане значення віднімаємо від номера послідовності та отримуємо посилання для завантаження файлу змін з якого ми почнемо наздоганяти відставання в наших локальних даних.

DUMP_EPOCH_TS=$(date -d "2025-03-24T00:59:53Z" +%s)
REFERENCE_DATE=$(wget -q -O - https://planet.openstreetmap.org/replication/day/state.txt 2>/dev/null | grep "timestamp" | cut -d'=' -f2 | sed 's/T/ /;s/Z//; s/\\//g')
REFERENCE_SEQ=$(wget -q -O - https://planet.openstreetmap.org/replication/day/state.txt 2>/dev/null | grep "sequenceNumber" | cut -d'=' -f2 )
LAST_EPOCH_TS=$(date -d "$REFERENCE_DATE" +%s)

# Тут приклад для обчислення різниці в днях 86400 сек = 24 год
# Замініть на 3600 для обчислення різниці в годинах
DIFF_TS=$(( ($LAST_EPOCH_TS - DUMP_EPOCH_TS) / 86400 ))
TARGET_SEQ=$(( (10#$REFERENCE_SEQ - $DIFF_TS) + 1 ))
seq_padded=$(printf "%09d" "$TARGET_SEQ")
url="https://planet.openstreetmap.org/replication/day/${seq_padded:0:3}/${seq_padded:3:3}/${seq_padded:6:3}.state.txt"

Змінна $url міститиме посилання на state.txt файл для початку процесу реплікації. Цей файл потрібен для osmosis чи подібного інструменту. (Докладніше про сам процес реплікації даних дивіться: https://wiki.openstreetmap.org/wiki/Planet.osm/diffs)

Описаний вище підхід добре підходить для файлів денних та годинних змін, однак не спрацьовує для хвилинних змін.

Проблеми з обчисленням хвилинних змін

Описаний вище підхід для обчислення номера файлу змін для початку реплікації не працює для хвилинних змін. Чому? Тому що хвилинні зміни можуть створюватись більше ніж 60 секунд, через це відбувається “проковзування” в часовому ряді.

Так, якщо взяти діапазон хвилинних змін 6590000 — 6590227, отримаємо 233 хвилини та всього 227 файлів з хвилинними змінами.

На графіках ви можете побачити, скільки часу було витрачено на створення хвилинних змін, та в які хвилини вони були створені. Тут ми бачимо, що о 7:59, 8:02 та 8:05 змін не було створено, відбулося “проковзування”

В цій таблиці також видно, що впродовж 15 хвилин відбулося 3 “проковзування”.

Чи є це критичним для повсякденного використання? Раз таке відбувається вже давно то схоже, що — ні. Наявні інструменти обробки змін цим не переймаються. Так, це може викликати трохи надлишкового трафіку, якщо для хвилинних змін ви відступите трохи далі в минуле ніж треба, однак це не вплине на фінальний результат. Ви отримаєте власний набір даних, що буде синхронізований з даними OpenStreetMap з відставанням до 2 хвилин.

Чи можна це виправити? Можливо

Обробка даних з привʼязкою в часі завжди є нетривіальним завданням. Для виправлення цього стану:

• В метадані наборів змін в полі timestamp потрібно вказувати час початку (момент в часі на який припав початок створення набору змін), цей час в ідеалі має бути цілим (чи дуже близьким до цього) часом у хвилинах, годинах та днях:
  • 13:00:00, 13:01:00, 13:02:00 — для хвилин;
  • 14:00:00, 15:00:00 — для годин; та
  • 00:00:00 — для днів.
• Часом завершення процесу створення змін буде час модифікації самого файлу, хоча його можна також вказати в метаданих набору змін (це той час, який зараз міститься в timestamp).
• Створення наступного набору змін має починатись в обумовлений час незалежно від того чи завершилось завдання зі створення попереднього набору змін. Певний час вони можуть виконуватись паралельно.
• У разі відсутності змін — створювати пустий файл набору змін для підтримання монотонного порядку нумерування змін, щоб не було пропусків в часовому ряді.

Якщо вам дошкуляє такий стан справ, ви можете подати пропозиції щодо його виправлення супровідникам проєкту, можливо це буде виправлено. Як швидко? Важко сказати.

Підсумки

Файли змін залишаються надзвичайно цінним інструментом для підтримки актуальності даних OpenStreetMap. Однак важливо розуміти їхні обмеження та не сприймати назву буквально, особливо це стосується хвилинних змін.

Для розробників, які використовують хвилинні файли змін, це означає необхідність мати надійну інфраструктуру для їхньої обробки, враховувати можливі затримки та бути готовими до обробки великих обсягів даних у періоди активного редагування.

А для звичайних користувачів це просто цікавий факт про те, як працює “за лаштунками” улюблена ними відкрита мапа. Наступного разу, коли ви внесете невелику правку і не побачите її на своєму сервері з мапою миттєво, не хвилюйтеся — можливо, ваш “хвилинний” файл просто ще в дорозі!

Що ви думаєте про хвилинні зміни? Чи стикалися ви з затримками в оновленні даних? Поділіться своїм досвідом у коментарях!