Автор сервиса для планирования походов опубликовал на «Хабре» технический разбор, который может быть полезен не только разработчикам, но и всем, кто сталкивается с картографическими данными при поиске работы или организации поездок. В статье он подробно разбирает три случая, когда «убедительное число» приводило к неверным выводам, и объясняет, как избежать типичных ошибок при работе с OpenStreetMap (OSM).
Хотя статья посвящена технической стороне создания сервиса, описанные проблемы напрямую влияют на качество данных, которые используются в приложениях для поиска маршрутов, картах и геоинформационных системах. Для читателей «РаботаВакансия» это хороший повод задуматься о том, насколько можно доверять данным из открытых источников и как разработчики могут непреднамеренно искажать информацию.
Проблема профиля высот: почему «+1200 м» может быть неправдой
Один из ключевых кейсов — расчёт профиля высот. Автор использовал данные Mapbox Terrain-RGB, но после прохождения знакомого маршрута обнаружил, что цифры не совпадают с реальными ощущениями. Проверка показала: альтернативный источник (Terrain Tiles из AWS Open Data) в горах даёт более правдоподобный рельеф.
«Разные DEM (цифровые модели рельефа) имеют разный шаг сетки, и на одном треке разница легко набегает на сотню метров», — поясняет разработчик.
Вторая проблема — обработка «сырого» профиля. Если суммировать все положительные разности высот подряд, шум данных (дрожание рельефа в пределах точности) даст завышенную цифру. Автор применяет алгоритм Дугласа–Пекера с допуском 5 метров. Результат на одном маршруте: сырой способ — 453 метра, прореженный — 344 метра.
«Какая из цифр правильная? Строго говоря, никакая. Но вторая честнее», — заключает он.
Ключевые факты
| Параметр | Значение |
|---|---|
| Разница в наборе высоты на одном треке (сырой vs прореженный) | 109 метров |
| Время загрузки данных OSM для участка Москвы (23 км) | 27 секунд (81 МБ JSON) |
| Доля неудачных маршрутов из-за привязки к «обрывкам» троп | 12 из 37 (32%) |
Перегрузка данными и «мёртвые» тропы
Когда автор перешёл к прокладке маршрутов по тропам, возникла новая проблема — объём данных. Живые запросы к OpenStreetMap через Overpass API оказались слишком медленными и ненадёжными. Для участка в Москве (23 км) ответ весил 81 МБ, а время загрузки достигало 27 секунд. На телефоне такой объём «просто убивает вкладку».
Но самое интересное: примерно в трети случаев маршрут не строился вовсе. Причина оказалась не в алгоритме поиска, а в привязке концов маршрута к «обрывкам» троп — незаконченным линиям, которые не соединены с основной сетью.
«Кто-то обвёл кусок по снимку и не дорисовал», — объясняет разработчик.
После доработки (привязка только к главной компоненте графа) успешность выросла с 25 до 28 из 28 возможных, а девять заведомо безнадёжных точек стали отсеиваться заранее с внятным сообщением.
Собственная база и ошибка фильтрации
Чтобы снизить зависимость от Overpass, автор поднял на VPS собственную базу данных на основе слепков Geofabrik. Однако при первой сборке выяснилось, что фильтр тегов «молча выбрасывал всё за пределами России». В результате Крым содержал 7953 объекта, а Минск и Тбилиси — 0.
«Нулевой код возврата означает ровно одно: программа не упала. Он ничего не говорит о том, сделала ли она то, что вы думаете», — резюмирует автор.
Живые данные против подложки
Ещё один вывод: открытые тайлы Protomaps содержат значительно меньше троп, чем живые данные OSM. На 13-м зуме в тайле Архыза была всего одна тропа, тогда как в живой базе — 37. Это означает, что отключать живой слой нельзя, если нужна детальная сеть маршрутов.
Практические выводы для разработчиков и пользователей
Для тех, кто использует картографические сервисы или разрабатывает приложения с геоданными, история автора — хороший урок критического отношения к данным. Даже если код работает, это не гарантирует, что результат корректен.
При создании сервисов, связанных с маршрутами, стоит:
— Проверять профиль высот по нескольким источникам.
— Фильтровать шум данных (алгоритмы сглаживания).
— Учитывать, что открытые данные (OSM) могут быть неполными или содержать «обрывки».
— Тестировать на реальных данных, а не только на синтетических тестах.
Автор продолжает развивать проект и обещает отдельную статью про переход с Leaflet на MapLibre GL. Для IT-специалистов и всех, кто интересуется геоинформационными системами, это может быть полезным материалом.
Источник: Хабр (статья «Планировщик походов изнутри: своя база OSM, свой тайлсет и три замера, которые развернули меня на 180°»)
