Comments 26
Спасибо ГНИВЦу, что заранее сообщил. Обычно он предпочитает вносить изменения молча ツ Например, недавно из ФИАСа тихо пропали интервалы домов (и больше уже не вернутся, судя по всему).
Год назад под другой статьей про адреса я сказал, что банки обязаны использовать ФИАС. Так вот, это ещё не было правдой, но я-то знал! Ребята в ГНИВЦ — милахи!
Подскажите, пожалуйста, а не планируется ли заодно связать адресный справочник со справочником судебных участков (если этого еще нет, конечно)? А то там (в справочнике СУ) данные в таком виде, что черт ногу сломит.
Запрос такой есть, но не слишком востребован. А для чего вы бы стали его использовать?
есть такая задача… К сожалению, подробности раскрыть не могу. Пока развлекаюсь тем, что текст с ГАС «Правосудие» парсю и пытаюсь находить для адреса (передается в фиксированном формате) нужный СУ с учетом исключений, особенностей и т.п. Задача нетривиальная, по крайней мере на мой взгляд.
Рискну предположить, что для автоматизации претензионно-исковой работы.
Мы ведём справочник домов, и вручную (по возможности) проставляем для каждого дома атрибут судебного участка.
Такие дела.
Такие дела.
А «мы планируем выпустить ФИАС в формате КЛАДР» и «БД в формате КЛАДР 4.0» на http://fias.nalog.ru/Updates.aspx — это разные ФИАСы?
а вот эта БД в формате КЛАДР 4.0 как раз с нового года обратится в тыкву, первая строка статьи про это :-)
https://www.nalog.ru/rn77/program//5961265/, да.
Еще 5 месяцев можно насладиться ФИАС в формате КЛАДР haute FNS.
Еще 5 месяцев можно насладиться ФИАС в формате КЛАДР haute FNS.
Недавно сталкивался с разбором ФИАС, даже думал написать сюда статью, но лени хватает только на комментарии сюда. tl;dr — информация внутри базы разрознена, документация не отражает реальное положение дел. Что бы я выделил из своего опыта:
— Формат dbf — нормально прочитать его в Python у меня не получилось, оптугнуло вот что. Но разбор XML это тоже еще та головная боль. Файл ADDROBJ занимает больше 21 гигабайта, это значит прогонять через DOM — совсем не вариант
— Часть полей объявленных как обязательные, по факту отсутствуют. Другие (необязательные) — присутствуют всегда.
— Опираться на код КЛАДР для записей — плохо. Например ряд улиц из новой Москвы, проходят по AREACODE (входит в код кладр) как Подмосковье. При этом города, которым подчинены эти улицы, могут иметь уже другой AREACODE (то есть принадлежать другому региону).
— Необходимо учитывать ACTSTATUS (не CURRSTATUS) или использовать STARTDATE, ENDDATE, UPDATEDATE. Адресные объекты могут переименовываться, чтобы не копаться в истории — крайне важно искать только актуальные записи.
— Существующая отдельная база для «раскрытия» сокращений (SOCRBASE), т.е перевода из SHORTNAME 'г.' в 'Город', не содержит всех реально используемых сокращений в базе ADDROBJ
— Формат dbf — нормально прочитать его в Python у меня не получилось, оптугнуло вот что. Но разбор XML это тоже еще та головная боль. Файл ADDROBJ занимает больше 21 гигабайта, это значит прогонять через DOM — совсем не вариант
— Часть полей объявленных как обязательные, по факту отсутствуют. Другие (необязательные) — присутствуют всегда.
— Опираться на код КЛАДР для записей — плохо. Например ряд улиц из новой Москвы, проходят по AREACODE (входит в код кладр) как Подмосковье. При этом города, которым подчинены эти улицы, могут иметь уже другой AREACODE (то есть принадлежать другому региону).
— Необходимо учитывать ACTSTATUS (не CURRSTATUS) или использовать STARTDATE, ENDDATE, UPDATEDATE. Адресные объекты могут переименовываться, чтобы не копаться в истории — крайне важно искать только актуальные записи.
— Существующая отдельная база для «раскрытия» сокращений (SOCRBASE), т.е перевода из SHORTNAME 'г.' в 'Город', не содержит всех реально используемых сокращений в базе ADDROBJ
— Часть полей объявленных как обязательные, по факту отсутствуют. Другие (необязательные) — присутствуют всегда.О да. Документация часто расходится с реальным положением дел, например:
- Есть описание интервалов домов, но интервалов в выгрузках уже нет.
- В классификационном коде ФИАС предусмотрен номер помещения ОООО, но поля с четырёхзначным номером помещения не существует.
— Опираться на код КЛАДР для записей — плохо. Например ряд улиц из новой Москвы, проходят по AREACODE (входит в код кладр) как Подмосковье. При этом города, которым подчинены эти улицы, могут иметь уже другой AREACODE (то есть принадлежать другому региону).
Случается, что в ФИАСе забывают перенести подчиненные объекты к актуальной версии родителя. А у вас остались примеры таких улиц, которые висят в Подсмосковье?
— Необходимо учитывать ACTSTATUS (не CURRSTATUS) или использовать STARTDATE, ENDDATE, UPDATEDATE. Адресные объекты могут переименовываться, чтобы не копаться в истории — крайне важно искать только актуальные записи.
ACTSTATUS относится не к объекту, а к записи о нем в базе. Как написано в документации: «Обычно последняя запись об адресном объекте».
Запись об объекте может быть актуальна (ACTSTATUS=1), но сам объект удалён (CURRSTATUS=99) или переподчинён (CURRSTATUS=51).
Если искать по наименованиям, то сначала стоит найти историческую запись, а затем подняться до актуальной. Переименованные записи без копания в истории не найти.
— Существующая отдельная база для «раскрытия» сокращений (SOCRBASE), т.е перевода из SHORTNAME 'г.' в 'Город', не содержит всех реально используемых сокращений в базе ADDROBJ
Да, нам иногда приходится пополнять сокращения при конвератции в свои структуры.
Часто встречается обратная ситуация: в SOCRBASE под сотни пар значений (тип, уровень), которые в реальных данных не встречаются.
Список объектов скинул сюда. Впрочем все найденные мною объекты имели CURRSTATUS равный 99. Но тут есть ньюанс, как я понимаю.
К примеру, там есть запись (4-ая по порядку) — ул. Адмирала Горшкова, находившаяся в городе Щербинка. К слову, город Щербика по базе до сих пор город, а вот согласно вики — поселение. Так вот изменилась это запись в сентябре прошлого года. С точки зрения логики, тогда эту запись и могли сделать исторической. И вопрос — как много документов, в которых эта улица все еще существует? Тут видимо надо пологаться из задачи, использовать CURRSTATUS или ACTSTATUS. В самом начале документации (не в описании таблицы) сказано следующее:
ACTSTATUS — определяет, является ли эта запись по адресному объекту актуальной на текущую дату (0 – не актуальный, 1- актуальный).
CURRSTATUS — «Статус актуальности в соответствии » с классификацией адресных элементов и адресных объектов. Содержит значение признака актуальности адресного элемента и объекта адресации
Из «смешного» я еще помню улицы, у которых родительскими объектами были другие улицы — но этого я быстро не найду. Да городской округ в качестве административно территориального деления, согласно закону (еще можно посмотреть здесь), городской округ — это муниципальное деление. В качестве примера — городской округ Егорьевский из Московской области (AOGUID: 96036cfc-7acb-4de8-9004-3ae4c1c232c0).
А вот с домами базы я не смотрел — не было острой необходимости в задаче но напугало наличие _ДВУХ_ баз про дома HOUSE и HOUSEINT. Выдержка из документации:
Таблица HOUSE (House) содержит записи с номерами домов улиц, элементов планировочной структуры, городов и населенных пунктов. При выгрузке сведений по домам в формате DBF именам файлов присваиваются имена HOUSE01 – HOUSE99, где 01-99 коды регионов в соответствии с Приложением 3.
Таблица HOUSEINT (HouseInterval) содержит записи с интервалами домов улиц городов и населенных пунктов.
PS актуальность — от позднелат. actualis — фактически существующий, настоящий, современный =)
К примеру, там есть запись (4-ая по порядку) — ул. Адмирала Горшкова, находившаяся в городе Щербинка. К слову, город Щербика по базе до сих пор город, а вот согласно вики — поселение. Так вот изменилась это запись в сентябре прошлого года. С точки зрения логики, тогда эту запись и могли сделать исторической. И вопрос — как много документов, в которых эта улица все еще существует? Тут видимо надо пологаться из задачи, использовать CURRSTATUS или ACTSTATUS. В самом начале документации (не в описании таблицы) сказано следующее:
ACTSTATUS — определяет, является ли эта запись по адресному объекту актуальной на текущую дату (0 – не актуальный, 1- актуальный).
CURRSTATUS — «Статус актуальности в соответствии » с классификацией адресных элементов и адресных объектов. Содержит значение признака актуальности адресного элемента и объекта адресации
Из «смешного» я еще помню улицы, у которых родительскими объектами были другие улицы — но этого я быстро не найду. Да городской округ в качестве административно территориального деления, согласно закону (еще можно посмотреть здесь), городской округ — это муниципальное деление. В качестве примера — городской округ Егорьевский из Московской области (AOGUID: 96036cfc-7acb-4de8-9004-3ae4c1c232c0).
А вот с домами базы я не смотрел — не было острой необходимости в задаче но напугало наличие _ДВУХ_ баз про дома HOUSE и HOUSEINT. Выдержка из документации:
Таблица HOUSE (House) содержит записи с номерами домов улиц, элементов планировочной структуры, городов и населенных пунктов. При выгрузке сведений по домам в формате DBF именам файлов присваиваются имена HOUSE01 – HOUSE99, где 01-99 коды регионов в соответствии с Приложением 3.
Таблица HOUSEINT (HouseInterval) содержит записи с интервалами домов улиц городов и населенных пунктов.
PS актуальность — от позднелат. actualis — фактически существующий, настоящий, современный =)
Список объектов скинул сюда. Впрочем все найденные мною объекты имели CURRSTATUS равный 99. Но тут есть ньюанс, как я понимаю.
К примеру, там есть запись (4-ая по порядку) — ул. Адмирала Горшкова, находившаяся в городе Щербинка.
Круто! Как будто улица Адмирала Горшкова исчезла и из ФИАС, и с карт. Непонятная история.
наличие _ДВУХ_ баз про дома HOUSE и HOUSEINT.
Больше месяца в ФИАСе интервалов домов (таблицы HOUSEINT) нет, и, видимо, уже не будет.
Из «смешного» я еще помню улицы, у которых родительскими объектами были другие улицы
Да, есть такие улицы, их 12 штук, но все уже неактуальные. Например: «Город Тюмень, Улица Дальняя, Улица Медиков», улица Медиков удалена.
Мне ещё понравились записи, где планировочная структура напрямую привязана к региону:
Таких 860 штук, все актуальные
- Область Ленинградская, Дачное неком-е партнерство Верхняя Ропша, Улица Главная
- Область Ленинградская, Дачное неком-е партнерство Ропшинские Горки, Улица Южная
- Край Краснодарский, Садовое товарищество ДНТ Нептун
- Край Хабаровский, Гаражно-строительный кооп. 135
- Край Хабаровский, Гаражно-строительный кооп. 89
- Край Хабаровский, Гаражно-строительный кооп. 723
- Край Хабаровский, Гаражно-строительный кооп. 712
Таких 860 штук, все актуальные
Но разбор XML это тоже еще та головная боль. Файл ADDROBJ занимает больше 21 гигабайта, это значит прогонять через DOM — совсем не вариант
Используйте SAX-парсер XML (потоковый) для разбора XML и будет вам счастье. Архив тоже можно не распаковывать, а считывать файл напрямую из него с помощью libarchive (умеет в RAR начиная с версии 3.0, для большинства популярных языков должны быть библиотеки-обёртки, на предыдущей работе я для проекта на Ruby использовал https://github.com/AMekss/archive_io). А ещё можно парсинг XML и запись в бд разнести в разные потоки…
Я тогда воспользовался iterparse из lxml.etree — что-то вроде SAX.
А по поводу потоков, разбор XML — не самая трудная задача. Там, в 21 гигабайте, содержится чуть больше 3.2 миллионов записей, если использовать только с атрибутом ACTSTATUS равным 1, то таких записей, на память, что-то около 1.5 миллиона. А вот обработка таких данных — другое дело, для выстраивания иерархии используются строковые UID'ы (атрибут AOGUID). Причем разные объекты могут иметь одинаковые значения AOGUID, тогда «правильная» запись выбирается исходя из других атрибутов.
А по поводу потоков, разбор XML — не самая трудная задача. Там, в 21 гигабайте, содержится чуть больше 3.2 миллионов записей, если использовать только с атрибутом ACTSTATUS равным 1, то таких записей, на память, что-то около 1.5 миллиона. А вот обработка таких данных — другое дело, для выстраивания иерархии используются строковые UID'ы (атрибут AOGUID). Причем разные объекты могут иметь одинаковые значения AOGUID, тогда «правильная» запись выбирается исходя из других атрибутов.
Уникальный ключ — это AOID. А вот AOGUID будет одинаковый у нескольких записей об одном и том же объекте, кажется (из них максимум одна будет актуальной, но это я тоже из памяти достаю обрывки).
AOID — идентификатор записи как таковой, а вот AOGUID и PARENTGUID используются для создания иерархии. Так, один и тот же адресный объект может иметь несколько записей. В этом случае, каждая запись будет иметь разный AOID и одинаковый AOGUID
Да, для каждого AOGUID одна уникальная запись, это выполняется, ура! :)
Меня вопрос ФИАСа интересует в плане учета помещений. Доведут ли ФИАС до квартиры/помещения, для полной идентификации? Сегодня разрозненной получается информация у разных РСО для квартир.
Sign up to leave a comment.
Как перейти от КЛАДР к ФИАС и ничего себе не сломать