Pull to refresh

Comments 75

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

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

Спасибо за примеры адресов — очень полезно для тестирования.
UFO just landed and posted this here
Самое сложное в случае переименований это то, что люди продолжают по инерции писать старые адреса (и так, вероятно, удобнее). При автоматическом разборе таких адресов иногда просто невозможно восстановить актуальное название:)
Дубли. По КЛАДР в Москве есть две разные улицы 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…
Интересно, что мешало продлению выдать другое название улицы?
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
По-моему, Россия тут приятное исключение. У большинства стран аналогичных открытых справочников просто нет. Посмотрите, как люди мучаются.
UFO just landed and posted this here
Ну тут проблема не в несовершенстве технических методов, а в нежелании всех под одну гребенку «причесываться».
В каждой местности есть свои традиции адресации. Отказываться от них нет желания. Есть индекс — оно доводит корреспонденцию до местного почтальона. А Для местного почтальона понятие валидности сое — он знает как доставлять. А то получается абсурд — я знаю, что фраза «На деревню дедушке» наиболее понятным образом объясняет почтальону куда нести письмо, а идиот, сидящий в банке требует какой-то «населенный пункт».
А есть еще огромное количество временных (и даже кратковременных) точек доставки корреспонденции.
Как сказать освоили. На основной работе, в интернет-провайдере мы свою базу адресов абонентов собирали. Опираясь на КЛАДР, опираясь на паспортные данные абонентов. Удивительное дело, паспортистки по-разному могут прописать адреса жильцов в одном подъезде. Ладно бы хоть подъезды отличались… Это конечно создавало определенные проблемы с определением итогового house_id и куда все-таки абонентов отнести. А там и определение оборудования, которое в этом доме стоит (по тому же house_id), и привязка к дому в openstreetmap. Так что как сказать, как сказать…
Я покажусь большим ретроградом если скажу что?:
1. Денормализация базы в НСИ есть странное решение.
2. Те же изменения можно было бы реализовать в старой структуре.
3. Методологическая подготовка у ФИАС на порядок хуже КЛАДРовской.
4. Кардинальных движений с момента пуска КЛАДРа в бой так и не произошло.
Не то что бы «Всё плохо», но гордится ФНС особо нечем в данной реализации.
КЛАДР — да, то был прорыв, а это даже не эволюция, так бантики современные. =)
Мне вообще нравится КЛАДР. Вот только айдишников фиасовских ему не хватает, это да.
КЛАДР расширяем.
К фасетному коду дописать справа 2-3 знака не составит труда. Видел такую бету вполне рабочая без кардинальной смены хранения.
Сделать КЛАДР код «до дома» даже «до квартиры» задача в этой структуре не сложная.
Полностью согласен — эти изменения можно было бы сделать в старой структуре. Вероятно, создатели задумывают нечто большее, что было невозможно в старой структуре, и то, что мы видим сейчас — только первый шаг. Посмотрим.
И да, как уже сказали, id дома в КЛАДР очень не хватает.
Только вот что то затягивают они появление этого нечто.
А вот проблемы с консистентностью данных из-за изменений уже поимели не раз.
Отдельно доставляет то, что ФИАС распространяется исключительно в виде rar-архивов. Для КЛАДРа-то хоть есть 7z.
Писал парсер как КЛАДР, так и ФИАС. ФИАС по своей структуре гораздо более логичный и человечный. Чего только 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, добавим.
>Поэтому адреса Досотуй ул. Советская и Досотуй переулок ул. Советская — разные адреса

Странно, что вы вообще что-то нашли, потому что Досатуй, пару лет службы там незабываемы !))
Sign up to leave a comment.