Карты OpenStreetMap ежедневно загружаются на сотни миллионов устройств. На таких объёмах даже маленькая оптимизация на пару процентов даёт существенную экономию трафика, диска, вычислительных ресурсов. А если улучшение в десятки процентов, то это грандиозное достижение.

В октябре 2025 года разработчики представили новый формат хранения данных GOB («Geo-Object Bundle», пакет геообъектов). Это вспомогательный формат для библиотеки GOL (Geo-Object Library), которая была раньше. В новом формате реализовано сжатие zlib и другие оптимизации, что позволило существенно уменьшить размер файлов, скорость загрузки и обработки карт. Работа с нашей Землёй стала гораздо быстрее, если можно так сказать.

Посмотрим, что представляют собой форматы GOL и GOB, как удалось добиться такой оптимизации и как это выглядит в реальных условиях.

GeoDesk и форматы OSM

Начнём с того, что с базами OSM можно использовать стороннюю специализированную СУБД GeoDesk, которая появилась четыре года назад. У неё свой компактный формат GOL, который всего на 10–50% больше, чем исходные данные OSM-PBF. Весь путь конвертации выглядит так:

Прежний формат GOL уже сам по себе был очень экономным: по оценке разработчиков, в традиционной СУБД эти данные заняли бы на порядок (в десять раз) больше места.

Компактное хранение с индексами позволяет осуществлять быстрые запросы для извлечения геообъектов. Запросы на Python или Java возвращаются примерно в 50 раз быстрее, чем SQL.

Поддерживается поиск по тегам, внутри прямоугольника и по расстоянию до других объектов. То есть это специализированная СУБД, которая гораздо лучше SQL подходит конкретно для геоинформационных систем.

Благодаря компактному формату с индексами импорт данных OSM осуществляется очень быстро даже на недорогом оборудовании вроде ноутбука Core i5 с 8 ГБ RAM, как на иллюстрации:

Более подробную информацию см. в руководстве GeoDesk для разработчиков.

GOB — ещё быстрее

Формат GOB ещё больше ускоряет обработку объектов в СУБД. Как уже было сказано, это вспомогательный формат для GOL. По сути, это плотно сжатый GOL без индексов. По размеру он примерно вдвое меньше GOL и на 30% меньше, чем PBF.

Для поддержки нового формата в GOL Tool 2.1 появились две новые команды: «Сохранить GOL как GOB» и «Загрузить GOB в GOL». Утилита командной строки GOL Tool входит в состав опенсорсного пакета GeoDesk Toolkit.

Импорт данных из GOB осуществляется в пять раз быстрее, чем из PBF. Современная система загружает GOB планетарного размера за три минуты. Преимущество в скорости особенно заметно на ПК с ограниченным объёмом памяти (менее 32 ГБ). Если запустить gol build, то система начинает активно свопиться, а вот gol load требует минимум памяти. Даже ноутбук десятилетней давности загрузит всю карту Земли менее чем за час.

В таблице приведена некоторая статистика по размерам файлов и некоторых популярных регионов (без метаданных):

В GOB лучше всего сжимаются плотные, обильно размеченные и аннотированные карты. В нашей таблице это Германия и Япония. Для сравнения, Бразилия, Китай или Россия сжимаются гораздо хуже, в процентах.

Файлы GOB организованы в тайлы, которые позволяют легко извлекать части карты, то есть региональные подмножества, и сшивать их обратно. Это делает GOB удобным форматом для архивирования и распространения геоданных. Извлечение региональных карт происходит «практически со скоростью копирования файлов», сказано в официальном блоге.

У формата есть и некоторые ограничения: GOB не хранит метаданные (метка времени последнего изменения, набор изменений, имя пользователя и т. д.), а также историю. Каждый файл GOB — это снимок набора данных OSM. Другими словами, формат предназначен не для редактирования, а для хранения и распространения данных.

Примеры работы GOL Tool

GOL Tool 2.1 для работы с файлами GOL можно скачать здесь. Последняя версия 2.2.3 под Linux, Windows и MacPS, а также отдельно мультиплатформенная версия на Java.

Кроме GOL Tool, в комплект GeoDesk входят GeoDesk for Python, GeoDesk for Java и GeoDesk for C++ — наборы инструментов для работы с данными OpenStreetMap, в том числе анализа и визуализации данных и разработки продвинутых картографических приложений. Версия для C++ считается самой продвинутой.

Экспортировать GOL в GOB:

gol save <gol-file> [<gob-file>]

Вторую часть в квадратных скобках можно не указывать, тогда используется то же имя файла. Расширение тоже указывать необязательно. То есть в самом простом виде команда будет выглядеть так:

gol save japan

Чтобы ограничить команду определённой областью, используется опция --area (-a). Можно обозначить многоугольник в формате WKT, GeoJSON или в виде простых координат (пары долгота и широта: lon и lat). Кстати, есть удобный онлайновый интерфейс Bounding Box, чтобы вручную нарисовать область — и получить нужные координаты. Например, вся сухопутная граница Норвегии и РФ протяжённостью 43 км:

И получаем координаты ограничивающей рамки в формате MARC:

$$f E 28°48'00"/N 68°52'00" ; E 28°01'00"/N 69°36'00" ; E 31°05'00"/N 70°00'00" ; E 31°51'00"/N 69°17'00" ; E 28°48'00"/N 68°52'00"

Можно перевести в формат WKT и др.:

POLYGON(([28.8017 68.8772], [28.0223 69.6068], [31.0871 70.0073], [31.8664 69.2914], [28.8017 68.8772]))

Поддерживаются сложные многоугольные фигуры:

Если расширение не указано, предполагается .wkt.

Например, экспорт тайлов для региона вокруг Боденского озера в Швейцарии:

gol save world bodensee -a 9.55,47.4,8.78,47.66,9.01,47.88,9.85,47.58,9.82,47.46

Импорт тайлов в GOB:

gol load <gol-file> [<gob-file>]

Следующая команда импортирует тайлы из файла japan.gol в japan.gob, но только из области, которая указана в файле shikoku.wkt:

gol load japan -a shikoku

Можно поэкспериментировать на реальных наборах данных. Например, на сайте Open Planet Data ежедневно обновляется тайлы всей Земли в файле GOB размером чуть менее 50 ГБ, это снапшоты с OSM. Раньше такие файлы в GOL занимали более 100 ГБ. Таким образом, благодаря новому формату наша планета стала «весить» вдвое меньше:

Итак, скачиваем файл planet-latest.osm.gob (переименуем его для простоты в earth.gob) с тайлами всего мира, а также программу GOL Tool 2.1. Затем импортируем тайлы норвежско-российской границы в новый файл, используя указанные выше координаты:

gol load earth -a "POLYGON((28.8017 68.8772, 28.0223 69.6068, 31.0871 70.0073, 31.8664 69.2914, 28.8017 68.8772))"

Готово, импорт выполнен за 1 секунду, получился файл размером 40 МБ.

Для сравнения посмотрим, за сколько можно сделать карту всей Москвы. Сначала сделаем прямоугольник с координатами:

Копируем координаты в формате WKT:

POLYGON((37.295178 55.919019, 37.926892 55.919019, 37.926892 55.55409, 37.295178 55.55409, 37.295178 55.919019))

И извлекаем тайлы в отдельный файл:

gol load earth -a "POLYGON((37.295178 55.919019, 37.926892 55.919019, 37.926892 55.55409, 37.295178 55.55409, 37.295178 55.919019))"

Скорость экспорта тайлов из GOL просто поражает: 191 мегабайт всего за четыре секунды. Переименуем файл в moscow.gol.

Полученный GOL затем экспортируем в GOB для максимального сжатия:

gol save moscow

Сжатие заняло 36 секунд, теперь у нас вся Москва размером 93 МБ для офлайнового просмотра.

Такие карты очень удобно размещать на своём сервере, чтобы пользователи загружали их отсюда. Они загружаются быстрее, не нужно платить за внешний трафик и запросы к API.

Кроме того, такие карты можно внедрять в мобильные приложения и другие нативные программы, для просмотра в офлайне.

Официальные спецификации нового формата GOL пока не опубликованы, но есть обсуждение некоторых технических деталей, в котором раскрыты подробности. Схема тайлинга в GOL стандартная, рекурсивная. Но есть важное отличие:

«В то время как тайловые серверы создают MVT/PNG для каждого тайла на определённом уровне масштабирования, тайлинг в GOL разреженный. В районах с низкой плотностью населения, таких как океаны и пустыни, разбиение на тайлы прекращается на уровне 4 или 6, тогда как в густонаселённых городских районах гранулярность тайлов может достигать уровня 12. Вот почему типичный GOL размером с планету хранит около 50 тыс. тайлов вместо миллионов».

Сами тайлы делятся на «горячие» и «холодные» зоны: система держит часто используемые данные вместе, а пространственно близкие и/или тематически связанные фичи хранятся в смежных областях. Так меньше страниц памяти, которые загружаются для выполнения запроса. Хотя у SSD нет задержек при поиске, но большинство из них по-прежнему значительно лучше работают при последовательном чтении. Более плотная компоновка означает, что в памяти можно кэшировать больше данных, объясняют разработчики.

«Для низкоуровневого хранения GOL и GOB используются такие же методы, что и MVT, например, дельта-кодирование LEB128 для координат и дедуплицирование структур. Один тайл города может содержать тысячи пальм или здания одного типа. Они могут совместно использовать общую таблицу тегов. То же самое касается строк (традиционная СУБД обычно хранит отдельный набор тегов для каждого объекта)».

Что дальше

Новый формат ещё находится в разработке. В ноябре вышла версия 2.2 с поддержкой URL в goal load для автоматического скачивания и сборки файла одной командой. То есть в примере выше нам даже не нужно скачивать файл Земли целиком, а можно запустить импорт тайлов Москвы прямо через интернет. Проверим, как это работает:

gol load https://download.openplanetdata.com/osm/planet/gob/v2/planet-latest.osm.gob -a "POLYGON((37.295178 55.919019, 37.926892 55.919019, 37.926892 55.55409, 37.295178 55.55409, 37.295178 55.919019))"

Действительно, всё работает. Только тут количество тайлов меньше, чем при импорте из локального файла, и размер файла меньше: 148 МБ в несжатом GOL, 63 МБ в сжатом GOB. Это довольно странно, ведь мы запрашивали прямоугольник с точно такими же координатами из одного и того же файла: в одном случае локально, а в другом — через интернет. Но результат разный.

Посмотреть скачанную карту можно командой gol map с указанием имени файла. При этом генерируется HTML, и данные считываются локально:

gol map moscow

Сейчас разработчики экспериментируют с различными алгоритмами сжатия помимо zlib, чтобы изучить потенциальные выгоды. Пока проверили zstd, но он не дал значительных преимуществ.

Вот некоторые показатели производительности в текущей версии на 10x2,3 Haswell Xeon, 32 ГБ, PCI3 NVMe:

• Найти все итальянские рестораны (точки и полигоны) в США в планетарном датасете (world("na[amenity=restaurant][cuisine=italian]").within(usa)) — 52 миллисекунды.

• Измерить длину всех каналов в прямоугольнике 500 км² — 47 микросекунд.

• Найти все объекты в прямоугольнике на несколько городских кварталов — 3 микросекунды.

Возможно, дальнейшие оптимизации позволят увеличить скорость ещё на 20% (например, если использовать инструкции SIMD при проверках ограничивающих рамок). Многоядерность тоже эффект: десятки тайлов могут обрабатываться параллельно.

OpenStreetMap — открытый картографический проект, организованный по принципу вики. Каждый пользователь может вносить изменения в карту. Проект запущен в 2004 году. На картах нет рекламы, а некоммерческий фонд OpenStreetMap Foundation существует за счёт пожертвований, а годовой бюджет всего лишь $652 тыс.

© 2025 ООО «МТ ФИНАНС»