Как стать автором
Обновить

Комментарии 75

КЛАДР еще поддерживается?! Осуществил переход на ФИАС еще весной 2012 года. Примерно тогда же на Хабре была первая новость о ФИАС. Намного более адекватная схема таблиц. Конечно, все равно потребовалось выкинуть лишнее, немного перестроить таблицы и построить индексы, но ощущения намного приятнее чем от КЛАДРа. Чем именно сложно сказать, т.к. давно ушел из той компании и, к счастью, больше не имею дела ни с КЛАДРом, ни с ФИАСом.
КЛАДР поддерживается. Всё никак не разберусь с кошерным регулярным переводом обновлений ФИАС на сайт.
Действительно, тема.
Кто-нибудь из уважаемых коллег озадачивался, как безболезненно сделать заливку ФИАС на сайт?
Лично у меня пока не получилось. Рассматривал пока варианты только с dbf: как-то напрягает парсить 14-гигабайтный xml на веб-сервере. Но в dbf есть blob-поля, которые PHP не понимает. Пока продолжаю думать.
Через потоковый (sax?) xml парсер затягивал ФИАС достаточно быстро в БД.
Ну как быстро, несколько минут. Правда потом выстраивание полных заголовков для поиска и вычистка всевозможной ереси занимала несколько часов. Но в этом скорее руки виноваты, надо было оптимизировать нормально.
Засовывали в MySQL с нормализацией попутно, с помощью потокового XML-парсера. Потом положили все в Sphinx и искали.
Конвертировал dbf в SQLite и потом приносил полученную базу в rpm-пакетах стандартными средствами обновления. Т.к. в базу ничего не пишется, только читается — отличный вариант. Частичное обновление делать смысла не вижу, те пара часов, что нужны на конвертацию всей новой версии ФИАС в нормальную структуру и построение индексов, вряд ли для кого-то критичны. Регулярный запуск же конвертера можно делать кому как больше нравится.
Все-таки малый размер КЛАДРа — это большое преимущество, если вам нужно его регулярно автоматически обновлять. Конечно, у ФИАСа есть инкрементальные выгрузки, но это ж приходится городить отдельную логику частичного обновления…

С КЛАДРом все просто — скачал да залил целиком.
«Все просто» — это когда КЛАДР слабо интегрирован с вашей системой. Например, используется только для подбора адресов при вводе, а сами адреса хранятся в текстовом виде. Если же адреса в системе — самостоятельные сущности со ссылками на них, то обновление превращается в долгий, мучительный, полу-ручной и чреватый ошибками процесс.
У нас в системе адрес очень даже самостоятельная сущность :-) А в чем мучительность обновления?
Как у вас выглядит, к примеру, переименование нас. пункта?
Краткое резюме: ФИАС — тот же КЛАДР, только в профиль.
Попытались сделать нормальную структуру, при этом на порядки вырос объем.

Спасибо за примеры адресов — очень полезно для тестирования.
НЛО прилетело и опубликовало эту надпись здесь
Самое сложное в случае переименований это то, что люди продолжают по инерции писать старые адреса (и так, вероятно, удобнее). При автоматическом разборе таких адресов иногда просто невозможно восстановить актуальное название:)
Дубли. По КЛАДР в Москве есть две разные улицы 8 Марта, которые, судя по индексу, сильно удалены друг от друга, и на них есть одинаковые дома.

А при чём тут КЛАДР, если в Москве действительно две разные улицы 8 Марта. Или Вы считаете, что названия улицам присваивают составители КЛАДР?
Простите, видимо, не совсем ясно выразил свою мысль. В Москве действительно есть улицы 8 Марта, 8 Марта 1-я и 8 Марта 4-я. Это можно увидеть на любой карте, например, в Яндексе и 2ГИСе. А в КЛАДР есть улицы 8 Марта, 8 Марта 1-я, 8 Марта 4-я и ещё одна 8 Марта.
Это запасная, на случай если первую закроют. Резервирование улиц для повышенной надежности справочника в условиях высоких нагрузок :-)
Нет, Вы выразились ясно, и я Вас понял, но в Москве действительно есть две улицы 8 Марта, без всяких 1-я или 4-я. Одна в районе Аэропорт, вторая в Южном Бутово. Посмотрите в том же Яндексе. Так что КЛАДР здесь не виноват.
Да, Яндекс выдаёт нам ещё одну улицу 8 марта в посёлке Липки в Москве, по всей видимости в КЛАДР имеется в виду она. Вероятно, стоило поместить её и в КЛАДР в соответствующий поселок. Но даже если так, что делать с остальными дублями? Их там довольно много, примеры я приводил в статье, и далеко не все действительно существуют.
Относительно вопроса виновности КЛАДР. Мне кажется, что целью создания адресного справочника является не только отражение текущей картины, но и наведение порядка, в том числе удаление дублей. Система должна работать так, чтобы при добавлении территорий с одинаковыми названиями, добавляющие были вынуждены сделать переименование объекта.
Сравните Трубецкой пер(77000000000718300) и Хользунова пер(77000000000718300) — номера одни. Последний байт я не показываю.
Там в младших битах есть такого чего интересного. В частности переименование или обьединение улиц.
Сравнил, Трубецкой переименован в Хользунова. Не совсем понял, в чем состоит вопрос?
Кстати, в ФИАС, в отличие от КЛАДР, причина неактуальности раскрыта гораздо шире в поле «статус действия»
Тогда я спрошу пояснения — уже как пару лет «КЛАДР» это «ФИАС в формате КЛАДР».
И там одна улица 8ого марта.
И причины «неактуальности», точнее результат, есть (в достаточном обьеме) как в ALTNAMES, так и в младших битах.
В номерах домов встречаются откровенные ошибки, например, «08а» и «0п».

А почему вы решили, что указанные номера — откровенные ошибки?
08А — реальный номер дома, например, в городе Электросталь по улице Первомайской. И от дома 8А по той же улице он отстоит почти на километр.

Там дело было в том, что несколько улиц продлили в сторону за домом номер 1. Но отрицательным числам не все люди обучены, поэтому начали нумеровать с ведущим нулем — 02, 04, 06, 08, 010…
Представляю что бы было, если бы номер дома сделали -8А:) Большое спасибо за комментарий, я действительно привёл неудачный пример в данном случае и сделал неверное заключение.
Я уж не знаю, что лучше -8 или 08. Сообщить такой адрес стороннему человеку без дополнительного пояснения того, что 08 это не 8 все-равно невозможно. Мне повезло и я там жил в «положительном» доме — соседям регулярно приходили письма, которые должны били прийти в «отрицательный». А сколько раз люди искали в 6-ом доме ЖЭК, который находился в 06-ом и не сосчитать.
Наверное, наиболее правильным решением было бы идти в сторону увеличения номера. Тогда, правда, дом номер 100 может быть сильно отдалён от дома 99, но такой путаницы как описываете вы не возникнет.
А ещё в некоторых системах номер дома хранится с типом integer…
Интересно, что мешало продлению выдать другое название улицы?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
По-моему, Россия тут приятное исключение. У большинства стран аналогичных открытых справочников просто нет. Посмотрите, как люди мучаются.
НЛО прилетело и опубликовало эту надпись здесь
Ну тут проблема не в несовершенстве технических методов, а в нежелании всех под одну гребенку «причесываться».
В каждой местности есть свои традиции адресации. Отказываться от них нет желания. Есть индекс — оно доводит корреспонденцию до местного почтальона. А Для местного почтальона понятие валидности сое — он знает как доставлять. А то получается абсурд — я знаю, что фраза «На деревню дедушке» наиболее понятным образом объясняет почтальону куда нести письмо, а идиот, сидящий в банке требует какой-то «населенный пункт».
А есть еще огромное количество временных (и даже кратковременных) точек доставки корреспонденции.
Как сказать освоили. На основной работе, в интернет-провайдере мы свою базу адресов абонентов собирали. Опираясь на КЛАДР, опираясь на паспортные данные абонентов. Удивительное дело, паспортистки по-разному могут прописать адреса жильцов в одном подъезде. Ладно бы хоть подъезды отличались… Это конечно создавало определенные проблемы с определением итогового house_id и куда все-таки абонентов отнести. А там и определение оборудования, которое в этом доме стоит (по тому же house_id), и привязка к дому в openstreetmap. Так что как сказать, как сказать…
Я покажусь большим ретроградом если скажу что?:
1. Денормализация базы в НСИ есть странное решение.
2. Те же изменения можно было бы реализовать в старой структуре.
3. Методологическая подготовка у ФИАС на порядок хуже КЛАДРовской.
4. Кардинальных движений с момента пуска КЛАДРа в бой так и не произошло.
Не то что бы «Всё плохо», но гордится ФНС особо нечем в данной реализации.
КЛАДР — да, то был прорыв, а это даже не эволюция, так бантики современные. =)
Мне вообще нравится КЛАДР. Вот только айдишников фиасовских ему не хватает, это да.
КЛАДР расширяем.
К фасетному коду дописать справа 2-3 знака не составит труда. Видел такую бету вполне рабочая без кардинальной смены хранения.
Сделать КЛАДР код «до дома» даже «до квартиры» задача в этой структуре не сложная.
Полностью согласен — эти изменения можно было бы сделать в старой структуре. Вероятно, создатели задумывают нечто большее, что было невозможно в старой структуре, и то, что мы видим сейчас — только первый шаг. Посмотрим.
И да, как уже сказали, id дома в КЛАДР очень не хватает.
Только вот что то затягивают они появление этого нечто.
А вот проблемы с консистентностью данных из-за изменений уже поимели не раз.
Отдельно доставляет то, что ФИАС распространяется исключительно в виде rar-архивов. Для КЛАДРа-то хоть есть 7z.
7zip умеет unrar'ить.
Писал парсер как КЛАДР, так и ФИАС. ФИАС по своей структуре гораздо более логичный и человечный. Чего только parent_id стоит, и все идентификаторы GUIDом, в отличии от отбрасывания порядковых цифр в КЛАДР. иерархия адресов строится быстро и без проблем.
Кстати проблему с районом я решил добавлением ОКАТО, где районы городов таки есть.
ОКАТО


Который недавно заменили на ОКТМО :)
Не для всех применений.
После знакомства с ФИАС и КЛАДР по долгу службы, субъективно могу сказать, что ФИАС лучше.
Плюсы:
+ Постоянные guid'ы у объектов
+ КЛАДР внутри
+ Хорошо документирован (есть на оф. сайте, fias.nalog.ru, если я не ошибаюсь)
Минусы:
— Размер. Причем полезной нагрузки, нужной большинству пользователей там нет. Такой огромный размер получается за счет храния истории объектов (старые названия и пр). Я бы, на месте разработчиков, вынес это в отдельные файлы.
— Вытекает из предыдущего пункта — неудобно парсить
— Бардак попытались устранить, но он остался. Есть населенные пункты без улиц. Есть улицы с признаком «жилая», но родитель у нее — нежилой город. Что с такими объектами делать — непонятно.

Ну и немного веселья из ФИАСа. Названия:
Уровень города:
— Волхов ул.Металлургов 17а
— Упоровский муниципальный
— в районе деревни Матокса

Уровень населенного пункта:
— Гаражи в районе ул.Профсоюзов 48а
— Общество неработающих пенсионеров
— Гаражи во 2-м районе горы Лысуха
— Рассвет АТБ1 от д Малая Кускунка
— Железнодорожная Казарма 253 км
— Отдельный Дом Дачи Художников

Уровень улиц:
— Гаражи в р-не очистных сооружений Блок 3
— Левая сторона дороги Оренбуг-Орск 12.400
— За администрацией поселка (левое крыло)
— садоводство «Волхонское», Любимая улица
— Сараи (за гаражами по ул Дзержинского)
— Зона хранения вооружений и боеприпасов
— г.Санкт-Петербург, Малый Резвый остров

И еще много такого, после чего звонят клиенты и спрашивают, а почему у нас в одном городе нет улицы ХХХ, а в поселке, который к городу относится, таких улиц три? Благо, на оф. сайте есть поиск онлайн и мы их туда отправляем убедиться, что это ФИАС такой.
К сожалению, перемещение неактуальных объектов в отдельные файлы не так сильно уменьшит размер базы, как того хотелось бы. В КЛАДР ведь тоже есть история переименований, и его вес радует, так что дело как раз в не полезной для пользователя нагрузке. И сами гуиды тоже добавляют. И не последнюю роль играет построчное разбиение домов: один дом — одна строка.
И ещё там нет большого количества адресов. Например, в Республике Ингушетия и Дагестане нет около 95% всех домов. Города есть, населённые пункты есть, улицы есть, а домов на них нет. Может, там используют свой другой справочник?
У меня только один вопрос: почему бы им не сделать справочник адресов в формате реляционной БД (со всеми связями между таблицами, да)? Чтобы его просто всосать в МySQL/Postgresql/Oracle/MSSql и не мучаться.

Обновления тoгда можно было бы рассылать просто в виде пачки команд DML.

Ну и да, поле техсостояния не совсем понятно зачем нужно. Типа, ЖКХ-шники попросили примотать? Лучше бы геоданные примотали (хотя бы в виде точки).
Это нужно чтобы сократить затраты на работу по сведению разных справочников в большом количестве муниципальных организаций, возможности построения различной статистики и истории развития по регионам, для большей прозрачности. Мне бы очень хотелось, чтобы ФИАС развивался и исправлял все ошибки, которые есть сейчас, и в перспективе стал действительно эталонной базой.
Ничего не мешает и сейчас загрузить его, например, в Oracle. Связи между таблицами все есть. Присутствует неконсистентность, это да, но связи есть. Вопрос в качестве того, что внутри у КЛАДР и ФИАС, и как с этим работать.
Составление справочника напрямую в БД, со всеми констрейнтами гарантировало бы непротиворечивость сразу. Муниципальным организациям — дать доступ через веб или какой нибудь клиент для сверки, корректировки и внесения данных (доступ через VPN или сертификат или типа того).
Так а это и сейчас, наверное, есть. На тему клиента не уверен (да и не нужен он, мне кажется, чтобы работа со справочником не привелась к полной анархии), но база данных, откуда выгружаются КЛАДР и ФИАС, очевидно, есть. Мне кажется, что в текущей системе всё сильно зависит от людей: сделал корректировку — молодец, не сделал — другие люди будут мучиться и никто ничего не поправит. Проверок вносимой информации тоже, по всей видимости, нет: никто не берёт на себя ответственность.
А если нужен справочник адресов с геопривязкой? Кто-нибудь решил для себя эту проблему? На ум приходит только выдирание их из OSM.
Если не попадаете под лицензионные ограничения Яндекс и храните координаты только в кэше, то можно использовать его АПИ. Правда, с ним надо работать аккуратно и проверять что он возвращает.
Если подождете до сентября, то у нас в dadata.ru появится проставление геокодов для адресов.
На openstreetmap.ru есть API для подобного случая. Однако в небольших населённых пунктах дома не все нарисованы и не на всех проставлены адреса. Так что в подобных случаях придётся поработать на благо OSM самому.
Часто встречаются случаи, когда в номере дома содержится литера

Вы точно не путаете буквы в номере дома с литерой? Т.к. это вещи разные. Вот например: г. Санкт-Петербург, 7-я линия В.О., дом 64а, литера Г
Как я люблю Питер с его чудесными домами… Взять, например, следующие:
набережная Обводного канала 134_136_138к233литерА — это как в КЛАДР, ФИАС же такие адреса пишет как 134_136_13 корпус 233 строение (литера) А, что кстати есть ошибка из-за неправильного номера дома (потеряли 8 в конце) и написания с нижним подчёркиванием вместо дефиса
Красных Партизан 5 литер АБВГ
Дачная (Горелово) 162 литер АА1А2

Да, согласно классификации КЛАДР дома 64А, 64 литера А и 64 корпус А — совершенно разные дома. Но, мне кажется, судя по похожести написаний в рамках улицы, вызвано это никакими не правилами, а отсутствием стандартов. То есть, где-то воспринимают А как часть номера дома, где-то как строение, а где-то как корпус (… а где-то вообще не задумывается). Сейчас ФИАС верит источнику и А может уйти в одно из трёх полей в зависимости от формата записи в КЛАДР, однако в ФИАС есть поле под строение и тип «литера», и, мне кажется, что все литеры должны попадать в это поле, если это не литера номерного корпуса или строения. В вашем случае, скорее всего, дом стоит писать как 64АГ, что наверняка так и делается в жизни (на картах и в поиске я его не нашёл).

Это похоже на историю с домовладениями — они вроде есть, и вроде дом — это другой тип в КЛАДР, но их никто не пишет как домовладения, а пишут как дома.
Очень огорчает отсутствие в ФИАСе информации о районах и муниципальных образованиях, микрорайонах.
Мне необходимо было построить полную иерархию, выкрутился тем, что на каком-то сайте нашёл данную информацию, написал паука и натравил полученные данные на ФИАС. Связка осуществляется по ОКАТО / ОКТМО. Но всего этого конечно хотелось бы избежать…

P.S. Было бы ещё супер круто иметь геокоординаты, но это вообще из области фантастики :-)
Я, в свое время, не поленился и связал базу КЛАДРа с базой OSM.
Тут тебе и геометрия улиц, и границы городов и регионов, ну и дополнительная информация (хотя бы ОМК УМ).
К сожалению OSM еще очень далеко не полон, и связывается далеко не все.
Ну и опечатки в названиях улиц в обеих базах такие, что комраде Левенштайн не всегда помогает.
Самое главное — не особо верить полю cladr:code в OSM — его туда явно не робот заливал, а человеки.
Районы, кстати, тоже покуда по ОКТМО определяю (http://postindex.esosedi.ru/77-moskva/st-653186-frunzenskaya/index.html — хамовники). Но так нельзя — надо будет полигональный тестер натравить (благо он есть).
Причина проста — например в Подольске есть районы города, но ОКТМО — один (и называется — Подольск).

PS: Уже полтора года все думаю — «вот допилю и выложу для желающих нормальную, цельную базу». И как всегда…
Одно время некоторые энтузиасты указывали cladr:code в OSM (но это было года 3 назад), а сейчас этим никто не занимается и опираться на этот тег не стоит.
ИМХО, как завещала википедия, надо некоторые данные привязывать к внешним источникам, хотя бы для проверяемости.
В последней версии вернули. Судя по весу архивов, они её потеряли ещё 21го июля.
Неплохо так, потеряли :) Примечаний к релизам я там что-то не вижу.
Ну, это ведь не совсем релиз, а актуальный срез БД
Да, вы правы. А вот насчет актуального среза — правильно ли я понимаю, что, скачав последнюю базу целиком, я получаю не только актуальные записи, но и не актуальные, со статусом 0 в соответствующем поле (точно не помню название)?
Да, именно так. Только там статусов немного больше: переименован, переподчинён,…
Вот, если я не ошибаюсь, то просто получить текущее состояние базы, без истории подчинений-переподчинений, нельзя. И нужно так или иначе идти с первой записи подряд и повторять все операции над объектом по полю AOGUID. В выборке из первых 5151+7577 строк, 5151 со статусом «0» и 7577 со статусом «1» — почти половина :))
Завести форум на сайте фиаса и там обсуждать все неточности. я уверен что силами сообщества можно привести данные к более менее адекватному виду. Сейчас занимаюсь внедрением ФИАС — нашел немало некорректных записей и с удовольствием отписался о них. Тестировщики будут тестировать функционал и по-любому тоже найдут ошибки. Жаль что у нас все так просто не делается…
Из-за нашей федеративной системы налоговой нужно давить на регионы, чтобы они добавляли отсутствующие данные, а они часто этот процесс саботируют. Поэтому с добавлением данных не все так просто. Мы в DaData.ru дополняем стандартные справочники теми адресами, которых в них нет — для целей проверки доставки, а не для целей сдачи отчетности в налоговую. Можете присылать нам, дадим бонус на тестирование сервиса :)
Мы возвращаем два индекса: индекс по КЛАДР для отчётности перед различными структурами и индекс для доставки корреспонденции, чтобы письмо все-таки дошло по адресу.

К dadata.ru это не относится? Там один индекс. Судя по всему — по КЛАДРу.
К dadata.ru — нет. Это возможности Фактора, в dadata.ru их тоже можно добавить, если будет спрос. Если вам это будет полезно, можете зарегистрировать запрос на нашем форуме: dadata.userecho.com, добавим.
>Поэтому адреса Досотуй ул. Советская и Досотуй переулок ул. Советская — разные адреса

Странно, что вы вообще что-то нашли, потому что Досатуй, пару лет службы там незабываемы !))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий