Весной мы добавили в API DaData.ru фичу «Адрес по координатам», она же «Обратное геокодирование». Название прозрачно намекает: метод принимает геокоординаты и отдает вагон данных об адресе.

Солидный продукт с той же функциональностью сделал «Яндекс» — он называется «Геокодер». Но сервис «Яндекса» бесплатен только для открытых некоммерческих проектов. Стандартный же тариф — от 120 000 ₽ в год — подходит не всем.

Мы подумали — если сделать бесплатную или недорогую альтернативу, разработчики наверняка скажут спасибо. И сделали, благо подготовили к тому времени сильные стартовые позиции:

  1. Справочник адресов с координатами, собранный и проверенный собственноручно.
  2. Готовое и отлаженное API.

В статье расскажу, как мы создали «Адрес по координатам»: собрали справочник, наладили поиск и упаковали все в готовый метод.

Где взяли данные и чем ищем адрес

Подступаясь к задаче, мы изучили готовые решения: где взять справочник координат с адресами и кто ищет географические объекты по индексу. Оказалось, за нужными инструментами даже не придется далеко ходить.

Адресные объекты берем в ФИАС — Федеральной информационной адресной системе. Это самый полный из открытых и официальных адресных справочников. Подробно о нем мы писали на «Хабре», а для этого материала важны четыре факта:

  • в ФИАС хранятся все адресные объекты страны, от регионов и ниже — до зданий и дополнительных территорий;
  • справочник свободно доступен в форматах DBF и XML;
  • ФИАС не идеален — в нем отсутствуют десятки тысяч домов и множество улиц, особенно новых;
  • каждому адресному объекту в справочнике соответствует уникальный ID — ФИАС-код. Код объекта иногда меняют, но для нашей статьи это не так важно.

Адресные объекты, загруженные из ФИАС вместе с ID, — основа нашего справочника для обратного геокодирования.

Координаты загружаем из OpenStreetMap (OSM). OSM — проект со свободной лицензией: энтузиасты собирают координаты всевозможных объектов и выкладывают для всех желающих.

Если по-простому, OSM — это набор точек, линий и полигонов на карте. У каждого объекта свое описание, тип и набор геокоординат.

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

Данные OSM для России лежат по ссылкам needgeo.com, osm.sbin.ru/osm_dump/ и osmosis.svimik.com/latest/.

links
Список источников публикуют на специальной странице в «Вики» проекта

Выгрузки состоят из PBF-файлов — этот формат сменил XML как более компактный. Превратить PBF в OSM XML ничего не стоит, с конвертацией справится куча одобренных сообществом утилит.

Для собственного справочника мы берем адресные объекты из ФИАС, а затем ищем их координаты в OSM. Если нашли, сохраняем объединенные данные. В итоге получаем такое пересечение ФИАС и OSM.

И все это замечательно, но есть одна проблема: с качеством данных в OSM дела обстоят непросто. Координаты объектов часто не соответствуют реальности.

Полигоны для регионов и районов адекватны. А для городов и ниже — уже не очень.

Поэтому основная работа, и с большим запасом — это собрать из OSM адекватные данные и отсеять брак. Задача настолько объемная, что я отвел под нее в статье отдельный раздел.

Дополняем справочник домами из OSM. Выше я уже говорил, что в ФИАС отсутствуют десятки тысяч домов. Это даже не проблема, а просто реальность, фон. Поэтому мы пополняем свой справочник домами из OSM. Но только теми, для которых в ФИАС существует улица.

Разумеется, у пришедших из OSM зданий нет ФИАС ID. Поэтому мы идентифицируем их как ФИАС-код родителя + номер дома.

По географическим объектам ищем прекрасным Lucene — нашим многолетним помощником. За наводку спасибо сведущему индийцу, написавшему пост Indexing Geographical Data With Lucene (хорошее дополнение — материал A dive into spatial search algorithms — о k-d-деревьях, на которых построен алгоритм поиска).

Как только мы узнали об у́дали Lucine, проблема с поиском решилась почти сама. Делов осталось — пройтись наждачкой.

  1. Загрузили в Lucene свой справочник координат и адресов, получили индекс. Для легкости убрали из него почти все, оставив лишь ID адресов и координаты.
  2. Наладили поиск по индексу: на вход — координаты, на выход — ID найденных адресных объектов. Другой информации поиск не возвращает, поскольку индекс мы донельзя скукожили.
  3. Насытили выдачу, загружая из «большого» ФИАС данные по найденным ID. Добавляем много всего, от нужного всем адреса одной строкой до признака столицы региона у городов.
  4. Придумали, как сортировать и отдавать полученные объекты.

Пока все выглядит просто, но это лишь малая часть работы. Никакого поиска адреса по координатам не получилось бы, не собери мы приличный справочник.

Как собрали базу координат и адресов

Для начала выложу багаж: прочитав статью, быстро сделать подобный справочник не получится. Мы собираем его с 2014 года, постоянно дополняя. Об этом чертовски длинном пути я и расскажу.

Самое сложное — это перебрать кординаты, которые пришли из OSM. На старте мы выверяли их как могли, в том числе руками. Главная цель тогда — получить опорные точки в крупных городах и сделать из них эталонный справочник. Чтобы знать с гарантией: вот этот дом или улица с этими координатами совершенно точно находится в таком-то городе такого-то региона.

Теперь, когда точек опоры много, проверять новые данные вручную почти не приходится. За раз мы добавляем в эталонный справочник по 200 000–300 000 адресов с координатами. И вот как это делаем.

Формируем из OSM-тегов полные адреса́. В OSM-выгрузках составные части адресов хранятся как разные теги.

  • addr:city — д. Булатниково;
  • addr:street — Центральная улица;
  • addr:housenumber — 103.

На следующем шаге нам понадобятся строки, поэтому пробегаем по тегам и собираем из них полный адрес.

Из тегов собираем строку д. Булатниково, Центральная улица, 103.

Прогоняем каждый адрес из OSM через сервис стандартизации «Дадаты». Он приводит адреса к единому формату «Как в ФИАС»:

  • исправляет опечатки;
  • расшифровывает сокращения вроде «НиНо» и «Мск»;
  • меняет старые названия на новые;
  • находит по индексу пропущенные в адресе города;
  • определяет ФИАС ID.

Адреса́ приходят от сервиса стандартизованными, хоть сейчас шли письмо или бандероль.

д. Булатниково, Центральная улица, 103

API стандартизации DaData.ru

142718, Московская обл, Ленинский р-н, с Булатниково, ул Центральная, д 103. a8b6a52f-e96d-4ec3-a0ff-641013ab0445

a8b6a52f-e96d-4ec3-a0ff-641013ab0445 — это ФИАС ID адреса.

Адреса́, которые не получилось сопоставить с ФИАС, «Дадата» помечает флажком. Их разбираем вручную, вариантов несколько.

  1. Адрес пришел не в положенных тегах выгрузки OSM, а черт знает где. Встречали и вовсе не заполненные адресные теги, и город в теге улицы, и еще много всего.
  2. В OSM лежит экзотический объект вроде детской площадки, вузовского футбольного поля или вовсе кладбища. В ФИАС ничего такого нет, да и для наших целей эти результаты не годятся. Такие объекты просто отсеиваем.
  3. Ошибка — и не ошибка вовсе. Например, из OSM пришел район города, которого в ФИАС нет. Или в ОSМ объект находится в населенном пункте, а в ФИАС этот населенный пункт присоединили к городу и удалили. Тогда мы допиливаем алгоритм под загруженные данные.

wrong_tags
Распарсил выгрузку, а там — путаница в тегах

Стандартизованные дома, улицы и населенные пункты мы храним как одну точку. Для улицы и населенного пункта эта точка — центр. В итоге все адресные объекты лежат в одной таблице, внутри — адрес, ФИАС ID, широта и долгота.

Адрес ФИАС ID Широта Долгота
142718, Московская обл, Ленинский р-н, с Булатниково, ул Центральная, д 103 a8b6a52f-e96d-4ec3-a0ff-641013ab0445 55.558773 37.667103
119034, г Москва, пер Турчанинов, д 6 стр 2 8c925e61-9173-48b3-999e-dc85c86d89e7 55.737096 37.597190

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

Если адрес сообщает, что объект находится в Омской области, будь добр по координатам попадать в ее полигон.

Эталонные полигоны мы загружаем из OSM и храним как есть — в формате GeoJSON.

Чтобы выбрать, к какому полигону примерить точку, заглядываем в отдельную таблицу. Здесь мы сопоставили префиксы КЛАДР-кодов и ID полигонов: находишь для адреса КЛАДР-код и смотришь, какой полигон соответствует.

polygon_links
КЛАДР-код — это уникальный идентификатор, который использовали еще до появления ФИАС. Находить этот код для адреса умеет миллион сервисов

Утилита разрешает объекту отстоять от положенного полигона на 1 700 метров. Это правило добавили из-за шоссе, которые часто выходят за границы региона. Но расстояние больше 1 700 метров — признак ошибки, так говорит статистика.

На этом для городов и улиц проверка заканчивается.

Еще раз, построже, проверяем загруженные координаты домов. В дело снова вступает упомянутая утилита, и вот что она делает.

  1. Берет адрес нового дома и находит для него соседей в эталонном справочнике.
  2. По координатам считает расстояние между непроверенным новым домом и надежными соседними.

data_11_09_01_
Соседей найти несложно: 1. Берем новый дом и находим ФИАС ID родителя. 2. Выбираем из эталонного справочника дома́, у родителей которых тот же ФИАС ID

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

В эталонном справочнике хранятся дома № 1, 2 и 3 по улице Коммунаров.

В новых данных пришли дома № 5, 6 и 7 по той же улице. Судя по координатам, новые дома стоят рядом.

Утилита видит, что дом № 5 находится рядом с домами № 1, 2 и 3 и добавляет его в эталонный справочник. Значит, дома № 6 и 7 тоже проходят проверку.

А дальше решается судьба пришедших из OSM данных:

  • дома, прошедшие обе проверки: на полигоны и на соседей, добавляем в эталонный справочник;
  • если объект не попадает в полигон, новые данные не подходят. То же самое, если расстояние между домом и соседями слишком велико;
  • дома, у которых нет соседей, мы пока откладываем. Они лежат в отдельной базе, когда-нибудь разберем.

Делим прошедшие проверку объекты на две части. Они пойдут в разные таблички нашего эталонного справочника.

Parent_and_son-1
В первой таблице — все объекты с ФИАС ID до домов: регионы, населенные пункты, улицы. Во второй — дома́ и ссылка на родителя из первой таблицы

Две таблицы нужны, чтобы назначить ключи отсутствующим в ФИАС домам. У них нет собственного ФИАС-кода, поэтому делаем вот как:

  • в одну таблицу собираем адресные объекты до дома, у каждого из них свой ФИАС-код.
  • во вторую — только дома́, при этом ссылаясь на родителя в первой таблице.

В итоге здания без ФИАС-кода мы идентифицируем по ключу ФИАС ID родителя + номер дома.

Справочник готов, осталось протестировать. За ночь прогоняем сервис по функциональным тестам и тестируем производительность. Скорость проверяем на Москве, запрашивая все дома в радиусе трех километров. Чтобы уж наверняка. Конечно, обложили все автотестами.

Главное после обновления — чтобы не стало хуже.

Обратное геокодирование глазами пользователя

На вход методу дают координаты, количество результатов и радиус поиска. Радиус по умолчанию — 100 метров, максимальный — километр. Если нужно точное значение, его задают в настройках.

curl -X POST \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -H "Authorization: Token ${API_KEY}" \
  -d '{ "lat": 55.878, "lon": 37.653, "radius_meters": 50 }' \
  https://suggestions.dadata.ru/suggestions/api/4_1/rs/geolocate/address

Обратно метод возвращает найденные объекты: дома, улицы и населенные пункты. При этом сортирует их по убыванию точности.

  1. Дома́.
  2. Улицы.
  3. Населенные пункты.
  4. Города́.

Затем сортирует еще раз — по расстоянию от заданных координат.

Если метод нашел четыре дома и улицу, сначала встанут дома́ в порядке удаленности от заданной точки. За ними — улица.

После всех этих рокировок метод наконец-то возвращает объекты, которые нашел.

"suggestions": [
        {
            "value": "г Москва, ул Сухонская, д 11",
            "unrestricted_value": "г Москва, ул Сухонская, д 11",
           "data": {...}
        },
        {
            "value": "г Москва, ул Сухонская, д 11А",
            "unrestricted_value": "г Москва, ул Сухонская, д 11А",
            "data": {...}
        }
    ]
}

Внутри — куча всего о найденных объектах: строки с полным и сокращенным адресом, актуальное и устаревшие названия, почтовый индекс, ФИАС-код родительского объекта и так далее.

dadata_data
Все данные, которые отдает метод — в документации

И напоследок — о покрытии по координатам. Для разных регионов оно разное, лучше всего дела обстоят в столицах. Вот так с домами:

  • Москва — 96%,
  • Санкт-Петербург — 88%,
  • другие города-миллионники — 74%,
  • остальная Россия — 47%.

А вот это — покрытие по улицам:

  • Москва — 92%,
  • Санкт-Петербург — 79%,
  • другие города-миллионники — 75%,
  • остальная Россия — 67%.

По городам не считали — в масштабах России зыбок даже сам факт принадлежности к гордому званию города.

Ярославская обл, Пошехонский р-н, с/о Федорковский — это город, согласно официальному справочнику ФИАС. А по факту, да и по адресу — сельский округ.

Физически сельский округ напоминает объединение нескольких деревень в большую кляксу. Сложно не только определить центр, но даже найти населенный пункт на карте.

Уже думаем, что добавить к методу: разрешить фильтрацию по типам объектов, возвращать расстояния до заданной точки, еще что-нибудь. Следим за спросом и решаем, вкладывать ли силы.

А в остальном все уже на проде. До 10 000 запросов в сутки — бесплатно, больше — по подписке от 5 000 ₽ в год. Если нужны адреса по координатам для коммерческого проекта, а «Геокодер» слишком дорог — попробуйте API «Дадаты». Все то же самое с промышленных масштабах умеет и «Фактор».