Фиас выгрузка в эксель
Федеральная информационная адресная система (ФИАС) создана Распоряжением Правительства Российской Федерации от 10.06.2011 №1011-р. С целью.
Замена КЛАДР. Тем не менее классификатор КЛАДР продолжает публиковаться и обновляться - версия 4.0 от 24.12.2012.
С момента первой публикации структура и содержание ФИАС многократно критиковались. Тем не менее, за время существования базы, она объективно улучшается и часть ошибок уже устранена. Поэтому указанные в этом документе несоответствия могут быть исправлены в будущем и их следует уточнять на свежих данных.
//ToDo - понятие "адрес" из докум. "Перечень типовых вопросов и предложений по использованию ПО «ФИАС»" // Секретность
Процесс импорта данных из файлов XML в реляционную базу данных дается на примере PostgreSQL. Все применяемые инструменты являются кросплатформенными. Для других БД (MySQL, Oracle и т.п.) процедура потребует незначительной доработки. См. также гл. 2.3, в которой приводятся ссылки на сторонние проекты, предоставляющие подготовленные данные в других форматах.
Создание таблиц
На сайте ФИАС представлены схемы XSD, описывающие структуру данных. Для преобразования схемы в формат SQL (CREATE TABLE. ) применим XSL Transformation (XSLT). В зависимости от БД может потребоваться изменить типы данных колонок.
Далее, полученные файлы SQL желательно откорректировать, чтобы явно назначить ключи (primary keys).
//// Ссылка на готовые файлы
Импорт данных
Для работы с большими файлами XML предпочтительнее применять потоковые парсеры: используется фиксированное количество оперативной памяти (в приведенном скрипте - порядка 80 Мб) на протяжении всего процесса работы.
Ниже приводится скрипт ETL Scriptella (Apache License) на базе парсера SAX. Он подходит для любой реляционной БД, для которой есть java-драйвер.
Другие источники
Данные ФИАС также распространяются в формате DBF. Для работы с ними рекомендуются утилиты типа PgDBF (импорт ФИАС).
- BasicData.ru - WebAPI и файлы для импорта в БД MySQL. Также может быть интересна БД "Почтовые отделения".
- Классификаторы России (rus-ref)
- zXML Parser - "Парсинг баз ФИАС в MySQL (потоковый XML парсер)". Программа из данных XML создает файл с sql-запросами.
Для понимания структуры данных ФИАС требуются следующие документы:
- Сведения о составе информации Федеральной информационной адресной системы (DOC);
- Описание структуры наборов данных ФИАС (DOC);
- Описание Классификатора адресов российской федерации (КЛАДР) (в архиве DOCUM.ARJ)
Таблицы
- ADDROBJ - Классификатор адресообразующих элементов (край > область > город > район > улица)
- HOUSE - Сведения по номерам домов улиц городов и населенных пунктов, номера земельных участков и т.п
- HOUSEINT - Интервалы домов
- LANDMARK - Описание мест расположения имущественных объектов
- NORMDOC - Сведения по нормативному документу, являющемуся основанием присвоения адресному элементу наименования
- ACTSTAT - Статус актуальности ФИАС
- CENTERST - Статус центра
- CURENTST - Статус актуальности КЛАДР 4.0
- ESTSTAT - Признак владения
- HSTSTAT - Статус состояния объектов недвижимости
- INTVSTAT - Статус интервала домов
- NDOCTYPE - Тип нормативного документа (закон, приказ, справка) // не упоминается в официальной документации
- OPERSTAT - Статус действия
- SOCRBASE - Типы адресных объектов (условные сокращения и уровни подчинения)
- STRSTAT - Признак строения
ADDROBJ
Текстовые элементы адреса
- OFFNAME - Официальное наименование
- FORMALNAME - то же что и OFFNAME , но оптимизированная для поиска
- SHORTNAME - Тип объекта: обл, р-н, г, ул. Расшифровку сокращений см. по табл. SOCRBASE .
Поле FORMALNAME создано специально для поиска: из него исключены все нестандартные символы и знаки пунктуации, буква "ё" заменена на "е" и т.п. Все записи удовлетворяют запросу:
Иерархия административных единиц
В таблице ADDROBJ иерархия построена по типу плоского дерева. И родительские и дочерние элементы хранятся в одной таблице. Воссоздание иерархии выполняется с помощью полей:
- AOGUID - Глобальный уникальный идентификатор адресного объекта. Не смотря на название, уникальным в пределах таблицы он не является. Могут существовать несколько исторический версий и одна единственная актуальная для данного объекта. Подробнее см. раздел "Статус актуальности".
- PARENTGUID - Идентификатор объекта родительского объекта. Содержит ссылку на AOGUID родительского элемента.
- AOLEVEL - Уровень адресного объекта. Условные названия уровней (подробнее см. табл. SOCRBASE ): 1 - регион 2 - зарезервирован 3 - район 4 - город 5 - внутригородская территория 6 - населенный пункт 7 - улицы 8 - зарезервирован 90 - дополнительная территория (ГСК, СНТ, лагери отдыха и т.п.) 91 - улицы на дополнительной территории (улицы, линии, проезды)
Получение полного адреса (от младшего к старшему):
AOLEVEL отражает административно-правовое подчинение, поэтому одни и те же текстовые элементы адреса могут располагаться на разных уровнях. Например, в снт. "Волжанка" (AOLEVEL=90) улицы имеют уровень 91 (против более распространенного 7):
(1) обл. Самарская (3) р-н Сызранский (90) снт Волжанка (91) ул. Ягодная (91) ул. Дачная (91) ул. Рябиновая
Аналогично, существуют населенные пункты без улиц. Например, в пос. Лужки иерархия заканчивается на уровне 6:
(1) обл. Орловская (3) р-н Мценский (6) п. Лужки
Таким образом, построение таблицы полных адресов следует начинать от верхних элементов (AOLEVEL=1) к нижним (AOLEVEL=91), как правило, запрос оформляется в виде множества подзапросов (subquery). Или рекурсивно подниматься от нижних, не имеющих дочерних элементов. Рассмотрим для примера второй вариант. Поскольку число полей в обоих случаях не определено, то полный адрес будет формироваться единой строкой:
- На настоящий момент существует 10 уровней ( AOLEVEL ). Но могут быть введены дополнительные. Например, ранее все ГСК и СНТ вносились на уровень 7 (улицы). Позднее, для них был выделен уровень 90 (дополнительные территории).
- На зарезервированных уровнях (2 и 8) не содержится записей, в том числе и исторических.
Статус актуальности
Из базы ФИАС почти никогда не удаляются элементы. Они могут быть только переведены в разряд "отключенных" (устаревшие, измененные и т.п.), что аналогично работе КЛАДР.
Примечание. Но информация о некоторых адресных объектах всё же может удаляться из БД ФИАС. См документ СВЕДЕНИЯ О СОСТАВЕ ИНФОРМАЦИИ ФЕДЕРАЛЬНОЙ ИНФОРМАЦИОННОЙ АДРЕСНОЙ СИСТЕМЫ, цитирую: "Технологически удалённые из БД ФИАС записи с адресными сведениями. включают удалённые администратором ФИАС по заявке операторов ФИАС (ошибочно введённые, дубли адресных сведений) адресные сведения". Т.е. дубли и ошибочно введённые данные могут быть физически удалены. Большинство из них приобретают статус актуальности КЛАДР (CURRSTATUS) равный 99, т.е. "несуществующий", а после этого уже становятся "технологически удалёнными". Если их нужно найти, то надо скачать т.н. "дельты данных", которые используются для обновления БД ФИАС, это архивы fias_delta_dbf.rar на сайте ФИАС. В некоторых из них имеются таблицы DADDROBJ, DHOUSE, и пр., содержащие технологически удалённые записи, попавшие в "дельту". На дату 15.12.2014 всего технологически удалено 793 записи, из них: 363 актуальных (т.е. ACTSTATUS = 1), 1 с CURRSTATUS != 99, и 1 с LIVESTATUS = 1.
Рассмотрим поля, определяющие действительность объекта:
Для выбора актуальных записей рекомендуется ориентироваться на поля CURRSTATUS и LIVESTATUS .
- LIVESTATUS - Признак действующего адресного объекта. Принимает значения: 0 - не действующий, 1 - действующий (см. прим. 1).
- CURRSTATUS - Статус актуальности КЛАДР 4. Принимает значения: 0 - актуальный, 1-50 - исторический, 51 - переподчиненный (см. табл. CURENTST и гл. 1.2. "Коды адресных объектов" документации КЛАДР).
- OPERSTATUS - Статус действия. Принимает значения: 1 - Инициация, 10 - Добавление, 20 - Изменение и др (см. табл. OPERSTAT ).
- ACTSTATUS - Статус актуальности адресного объекта ФИАС. Принимает значения: 1 - актуальный, 0 – не актуальный (см. табл. ACTSTAT ). Отвечает непосредственно за актуальность "имени". Если объект был переименован (чаще это исправление опечаток), то старая запись получает CURRSTATUS=1 и ACTSTATUS=0. Если же административная единица была ликвидирована или переподчинена, то имя останется по-прежнему актуальным: CURRSTATUS=99/51 и ACTSTATUS=1. В тоже время, при внесении изменений, не касающихся непосредственно адресной части, признак актуальности все равно сбрасывается (ACTSTATUS=0).
Также, в категорию актуальности можно отнести поля STARTDATE , ENDDATE , UPDATEDATE . Но, на данный момент (декабрь 2012 г.) значения этих полей редко бывают заполнены правильно.
Покажем на примере выбор актуальных и исторический записей. "Пермский край" был образован 01.12.2005 объединением "Пермской области" и "Коми-Пермяцкого АО". В базе ФИАС это отразилось следующим образом (см. табл. 1):
- Создана новая запись "Пермский край" (1-й столбец);
- Запись "Пермская область" (2-й столбец) сохранена, причем AOGUID обеих записей идентичен (для связи с дочерними объектами);
- Запись "Коми-Пермяцкий АО" (3-й столбец) также сохранена.
- ACTSTATUS для Коми-Пермяцкого АО сохранен в значении "Актуальный";
- OPERSTATUS не изменился - ошибочно(?);
- CURRSTATUS правильный (0 - актуальный, 1 - исторический, 51 - переподчиненный);
- LIVESTATUS показывает единственную актуальную запись, но значения инвертированы (см. прим. 1).
//ToDo - изменения в подчиненных объектах
- Все актуальные записи (CURRSTATUS = 0) имеют значение (LIVESTATUS = 1) и наоборот. Очевидно, что поведение LIVESTATUS не соответствует описанному в документации. Поле можно использовать для выбора актуальных записей, но с осторожностью до выяснения ситуации в будущем.
Исторические названия
Поля AOID , PREVID , NEXTID в совокупности составляют цепочку от современного к устаревшим наименованиям объекта. Хотя, если имеется два прямых предка (как в примере про "Пермский край"), то наследование невозможно отразить полностью однозначно.
В общем виде получение исторических вариантов наименований объекта имеет вид:
- Наблюдение (в документации не разъяснено): при внесении изменений, предыдущая историческая запись получает значение (CURRSTATUS = 1). Если вносится повторное изменение, то аннулируемая запись принимает значение (CURRSTATUS = 2). Таким образом, цепочка от современного названия к самому старому принимает вид: актуальное (0), предыдущее (3), более раннее (2), самое старое (1).
Адресные классификаторы
Записи в БД ФИАС содержат ссылки на другие российские адресные классификаторы:
- OKATO - код объекта административно-территориального деления (ОКАТО)
- OKTMO - код муниципального образования (ОКТМО)
- CODE - код КЛАДР
- PLAINCODE - код КЛАДР без признака актуальности (последних двух цифр), см. также CURRSTATUS
ФИАС предлагает собственный "классификационный код", который хранится, разбитым на отдельные элементы: REGIONCODE , AUTOCODE , AREACODE , CITYCODE , CTARCODE , PLACECODE , STREETCODE , EXTRCODE , SEXTCODE .
В целом, код является расширенным вариантом КЛАДР:
Могут быть случаи, когда адресному объекту в БД ФИАС не соответствует никакой КЛАДР-код, например:
Подробное описание см. в документе "Сведения о составе информации Федеральной информационной адресной системы".
Прочие поля
- Ведомственные классификаторы ФНС России: СОНО - IFNSFL , IFNSUL ; СОУН - TERRIFNSFL , TERRIFNSUL .
- CENTSTATUS - статус центра; ненулевое значение присвоено столицам, административным центрам и центральным районам регионов (подробнее см. табл. CENTERST ).
- NORMDOC - нормативный документ (табл. NORMDOC ).
На портал ФИАС выгружаются актуальные и исторические сведения ФИАС, а так же технологически удалённые из БД ФИАС адресные сведения. Актуальные и исторические сведения ФИАС выгружается в виде файлов (таблиц) DBF и файлов XML. Вместе с полной базой ФИАС выгружаются дельта данные – новые, изменившиеся и удаленные данные с момента предыдущей выгрузки базы. Дельта данные, т.е. новые, изменившиеся и удаленные данные появившиеся с момента предыдущей выгрузки базы ФИАС, загружаются по следующему алгоритму: по наличию или отсутствию ключа в пользовательской базе определяется тип операции – добавление или обновление записи. После проведения соответствующих операций необходимо удалить по ключу записи, присутствующие в таблицах технологически удаленных данных.
Наличие таких "дельт" позволяет быстро обновить БД ФИАС, не скачивая полный архив (на 2014.12.01 его размер составляет 1.8 Гб). Алгоритм обнобления, действительно, довольно прост. Привожу текст процедуры обновления для MySQL на примере таблицы ADDROBJ:
Иногда может изменятся структура самих таблиц, что требует ручного контроля. Например, колонка "oktmo" сначала содержала 8 символов, а потом была расширена до 11 символов.
Тем не менне, несмотря на удобство обновления через дельты, я рекомендую для обновления заменять БД ФИАС целиком (а после этого объединять её с таблицами технологически удалённых данных, при необходимости). Дело в том, что дельты могут содержать неполную информацию, проще говоря oldfias + delta != newfias. Например, я обновлял БД ФИАС от 2012.07.01 через дельты до состояния на 2012.09.24. Если в дельте была информация о переподчинении или об изменении адресного объекта, то предыдущая версия адресного объекта не обновлялась, т.е. не проставлялось (NEXTID = ид_нового, LIVESTATUS = 0, ACTSTATUS = 0). В результате в БД ФИАС были объекты с одинаковым AOGUID, но имеющие ACTSTATUS = 1. Некоторые новые данные просто отсутствовали в дельте. Возможно, что разработчики ФИАС уже исправили эти ошибки, и более свежие дельты следующие за 2012.09.24 содержат полную информацию, но это требует проверки.
БД ФИАС может содержать ошибки в данных, а) связанные с нарушением целостности двунаправленных списков PREVID/NEXTID, б) ошибки, когда запись об адресном объекте имеет OPERSTATUS = 1, а в действительности произошла другая операция (переименование, переподчинение, слияние, или дробление), и в) ошибки, когда отсутствуют исторические сведения (вызванные тем, что администраторы БД ФИАС, видимо, выполняли прямое изменение данных с помощью SQL-запросов).
Для иллюстрации можно открыть портал ФИАС и воспользоваться расширенным поиском. В поле "Регион" введите "Санкт-Петербург город", в поле "Уровень" выберите "Регион". Нажмите "Найти". Если просмотреть историю изменения города Санкт-Петербург, то можно обнаружить, что Санкт-Петербург раньше назывался "станция Володарская", а должно быть "Ленинград". Это иллюстрирует нарушение целостности двунаправленных списков.
Для иллюстрации ситуации, когда отсутствуют исторические сведения можно рассмотреть адресный объект с AOGUID="df84b14c-6006-46d1-8ce3-3a6ddf8643bd". В БД ФИАС от 2012.08.06 этот объект имел КЛАДР код равный 24000001101000100. В какой-то момент произошло переподчинение родительского объекта, и в итоге у него изменился уровень AOLEVEL с 6 на 90. Соответственно, уровень AOLEVEL дочернего объекта изменился с 7 на 91. Если взять БД ФИАС от 2014.12.01, то в ней нельзя обнаружить исторической записи с КЛАДР кодом равным 24000001101000100. Нет этой записи и в таблицах DADDROBJ.
Ошибки с неправильным OPERSTATUS слишком многочисленны, их классифицирование выходит за рамки данной статьи.
01.06.2020 ИФНС опубликовала новый формат выгрузки данных
17.12.2020 Мягко намекнула, что в 2021 будет использоваться только он
01.09.2021 Это свершилось: теперь просто "полная БД ФИАС" перестала обновляться и требуется использовать ГАР БД ФИАС
Частично импортируем ГАР БД ФИАС в MySQL на PHP.
Новость, мягко говоря, не очень, для тех кому нужно получить иерархию улиц и список домов с почтовыми индексами, особенно учитывая, что КЛАДР до сих жив. А не очень из-за того, что файлик данных с 12Гб резко пополнел до 28Гб. Конечно, можно возразить, что скачал один раз и по чуть-чуть обновляйся. Да, можно, если хранить нужные файлы данных целиком и постоянно накатывать на них обновления, но. наличие багов (даже в полной версии) добавит радости.
Возможно имеет смысл написать небольшую библиотеку, функционал которой - скачивать только необходимую часть zip архива для распаковки конкретного файла с web сервера, поддерживающего докачку. Весьма актуально, т.к. из этих 28Гб требуется значительно меньшая часть. Если вы знаете, что это уже есть где-то "из коробки" или реализовано отдельной библиотекой - пожалуйста, напишите.
Теперь новая БД содержит иерархическую информацию об адресных объектах в двух вариантах:
- по административно-территориальному устройству (для упорядоченного осуществления функций государственного управления) - на основе этого код ОКАТО
- по муниципальному устройству (для организации местного самоуправления) - соответственно, ОКТМО
Не каждый объект "доступен" в обоих иерархиях. Например, если мы возьмём г. Карабулак, то по административно-территориальному устройству он находится в республике Ингушетия, а по муниципальному устройству расположен городском округе города Карабулак, который в свою очередь в республике Ингушетия и "не участвует" в административно-территориальном устройстве.
Моей целью является получение двух таблиц только с актуальной на момент импорта информацией об иерархической структуре адресов (от региона до, обычно, улицы) и списка жилых домов (не интересуют гаражи, шахты, подвалы. ) с почтовыми индексами. NB! При выборе адреса в реальных проектах рекомендую сохранять полный иерархический путь, а не только идентификатор - впоследствии адрес может стать неактуальным (выбрать его нельзя - дома реально нет, а сохранить информацию корректно необходимо).
Таблица gar_addr, ключевое поле id. Иерархию определяют указывающие на него owner_adm и owner_mun. Субъекты РФ (и Байконур) имеют level=1, owner_adm=owner_mun=0. Содержит информацию о названиях адресных объектов (NAME, TYPENAME) и говорящие за себя OKATO, OKTMO, KLADR. OBJECTGUID, ранее в ФИАС именовался AOGUID, является идентификатором адресного объекта (уникальный для актуальных записей; не уникальный, если используются исторические устаревшие записи). OBJECTID аналогичен по значению OBJECTGUID, но уже целочисленный.
Таблица gar_house - список домов. owner_* указывает на gar_addr.id.
Содержит номер дома в 3 полях: основной и 2 дополнительных (и это не я придумал, ADDNUM2 в актуальных данных отсутствует, хотя ранее использовался) и, соответственно, их типы (например: дом, литера, корпус). Описание этих значений в AS_HOUSE_TYPES. XML. ОКАТО и ОКТМО, почтовый индекс.
Импорт и частичное описание структуры.
Всё описанное ниже реализовано в исходниках.
a) Прежде чем начать, проверим zip файл. Убедимся, что он похож на нужный нам и в нём хотя бы есть файлы as_addr_obj. для каждого интересующего нас региона.
Ранее в ФИАС был один файл со всеми регионами, теперь данные о каждом регионе в своей директории.
b) Импортируем файлы AS_ADDR_OBJ_(дата)_(идентификатор).XML, содержащие информацию об адресных объектах.
Все элементы однотипные, выбираем только ISACTUAL=1 и ISACTIVE=1. И получить мы можем только название объекта и поля OBJECTID, OBJECTGUID. Теперь в этом файле нет указания на дочерний объект, нет данных об ОКАТО, ОКТМО - все они находятся в отдельном XML файле.
c) Проверим, что OBJECTID является уникальным. Если нет - надо разбираться, что это вызвало и писать в ИФНС. Ранее в ФИАС такая проблема часто возникала. Проиндексируем таблицу по этому полю - по нему будет определяться адресный объект при обработке последующих XML с данными.
d) Импортируем файлы AS_HOUSES. - дома. Аналогично, интересуют только актуальные записи и дополнительно отсеиваем по типам (дом, здание, строение, корпус). И в этом файле тоже нет данных, какому адресному объекту принадлежит дом.
e) Проиндексируем дома по OBJECTID и убедимся, что все записи уникальны.
f,g) Настало время создать иерархию. Анализируем файлы AS_ADM_HIERARCHY_. и AS_MUN_HIERARCHY_. отбирая только актуальные записи. Пара OBJECTID и PARENTOBJID указывает на OBJECTID объекта.
В этих файлах собрана информация по всем объектам региона. В моём случае PARENTOBJID может быть только адресный объект, но реально в PARENTOBJID может быть и дом. Дочерним у него будет является, например, квартира (файлы AS_APARTMENTS_. ).
h) Проиндексируем gar_addr по owner_adm и owner_mun
i) И начнём искать ошибки :) Отметим достижимыми все субъекты РФ. И далее будем отмечать достижимыми все записи, родители которых тоже достижимы, до тех пора, пока количество достижимых не изменится. Так делаем по обоим полям - owner_adm, owner_mun. Если owner_adm = owner_mun = 0, то оказалось так, что мы не можем выбрать этот объект - это ошибка. Информация об этом будет сохранена в отчёте, а запись удалена. Отправляется bug-report
ГАР, полная выгрузка
В файле AS_ADDR_OBJ_20210906_2a908987-3309-454e-9364-b75afd551e12.XML
есть объект с ISACTUAL="1" ISACTIVE="1"
Таких проблем в выгрузке от 07.09.2021 - 107 (из 1405143+107 записей)
j) Теперь проверяем дома. Удаляем и логируем записи без owner_*, т.к. до них мы не сможем добраться. Логично считать ошибкой отсутствие owner в любом из типе устройств - дом же есть, значит до него надо как-то добраться. Разбираться с такими ситуациями придётся вручную (аналогично предыдущему пункту).
В выгрузке от 07.09.2021 - по owner_adm все дома достижимы; по owner_mun - 1639 домов (из 25842972 интересующих) не имеют владельца.
Надеяться, что дом обычно расположен на конкретной улице и owner_adm должен совпадать с owner_mun не получится. Крайне малое количество домов имеют разных владельцев, например один и тот же дом "Х":
Башкортостан, Уфимский р-н, Зубовский с/с, д. "Х"
Башкортостан, Уфимский м.р-н, с.п. Зубовский сельсовет, тер. СНТ Авиатор, ул N1, д. "Х"
В выгрузке от 07.09.2021 - не совпадающих owner_adm и owner_mun всего 2231 объект и есть огромное желание пренебречь одним из столбцов owner_*.
k) Настало время заполнить OKATO, OKTMO и KLADR. Информация о них в файле AS_ADDR_OBJ_PARAMS_. и надо выбрать VALUE из актуальных записей соответствующего TYPEID (6,7,11). Какие данные ещё есть в этом файле указано в AS_PARAM_TYPES_. XML
Всё просто. Из плюсов, что при обработки иерархии мы не знаем к какому объекту относится OBJECTID - здесь же всё однозначно, искать надо только по таблице addr.
l) Аналогично собираем данные OKATO, OKTMO, POSTALCODE для домов. Это уже другой файл - AS_HOUSES_PARAMS_. с аналогичной предыдущему структурой.
m) Удаляем вспомогательные столбцы и индексы
n,o) Выполняем слияние всех таблиц по регионам в одну общую.
p) Создаём нужные индексы
q) Переименовываем временные таблицы в нормальные имена
Как мне в Excel по Адресу в одной колонке проставить Код ФИАС в другой?
Примерно 1000 строк. Вручную каждый адрес копировать на сайт долго.
Есть ли готовый пример макроса или т.п.?
Ответ
Василий, добрый день!
Обработайте файл с помощью Стандартизации.
В файле с результатами будут колонки с кодом ФИАС и уровнем адреса по ФИАС:
Такое решение вам подойдет?
Ответы 6
Василий, добрый день!
Обработайте файл с помощью Стандартизации.
В файле с результатами будут колонки с кодом ФИАС и уровнем адреса по ФИАС:
Такое решение вам подойдет?
Спасибо! Все работает!
Отлично! Если будет что-то непонятно или возникнут проблемы, пишите :)
Меня тоже интересует получение в Excel кода ФИАС по адресу.
В ответе Анастасии не работает ссылка.
Просьба восстановить ответ.
И еще вопрос, как по коду ФИАС получить в Excel координаты населенного пункта (долгота и широта)
Конфигурация предназначена для поиска идентификаторов домов и квартир в базе ФИАС, если они там имеются.
Классификатор адресов скачивать с сайта налоговой:
Специальные предложения
За реализацию, конечно, плюс)
Только не очень понятно, как именно и чем может помочь подобная конфигурация в решении конкретной прикладной задачи, например выгрузки информации в ГИС ЖКХ.
На мой взгляд было бы намного интереснее создать подсистему, которая будет возвращать УИДы домов по заданному адресу и которая будет работать с любой конфигурацией, имеющей в своем составе БСП.
Пример. Имеем конфигурацию БП 3.0 или отраслевую конфигурацию на базе БП 3.0. В форме ввода адресной информации есть кнопка "Получить УИД дома", которая возвращает нужный УИД из базы ФИАС. Кто-то будет пользоваться кнопкой, а кто-то будет вызывать соответствующую функцию из другого места конфигурации, например из своей обработки.
Актуальная тема, думаю если сделаете какое-то решение которое будет надежно работать и легко расширяться до нужного функционала, сможете продавать его за разумные деньги.
(1) MSConfig, За комментарий спасибо, очень интересны замечания!
Теперь по сути: не все пользуются отраслевой в которой есть выгрузка в ГИС ЖКХ.
Думаю что многие заполняют формы в экселе и после их загружают.
Вот им она будет очень полезна. А кто пользуется БП 3.0 им тем более такая подсистема ни какой роли не играет.
Сервис нужно делать тем кто разрабатывает отраслевую. почему-то они этого еще не сделали.
(3) да, но там каждый адрес экспортировать, открыть этот файл найти в нем нужную колонку и уже тогда копипастить. или запустить базу, и только менять номера домов и получать УИДы
ФайлАдреса = ""+РабочийКаталог+"ADDROBJ.DBF";
на
ФайлАдреса = ""+РабочийКаталог+"ADDROB"+Регион+".DBF";
Только поиск все равно не работает, потому что не дописан.
Мне исправлять влом, ибо нужные мне функции я оттуда спер.
(13) на момент написания это был один файл, возможно сейчас что-то изменилось. Исправления вноситься не будут, для моих целей конфигурация отработала.
Так же вопрос как производить обновление информации? Заново грузить полную базу ФИАС или только обновление
Тоже написали подобную конфу. Служит у нас "эталонным ФИАС" для других наших ИС.
Что сделано допом у нас:
1. Загрузка ФИАС от ФНС делается дельтами. Мы анализируем, когда была полная загрузка, когда были пропуски загрузки дельт.
2. Грузим доп. адреса с ГИС ЖКХ
3. По необходимости, дописываем внешний интерфейс конфы в виде веб-сервисов для получения данных по каким-то критериям.
(9) ФИАС - неполный. Бывает, что улица есть, а домов в ней нет. Но идентификаторы домам назначать-то нужно. Для таких случаев подается заявка в ГИС со списком домов. Им назначаются временные УИДы, которые можно использовать для выгрузки в ГИС ЖКХ. Такие добавленные дома потом выкладываются на сайте ГИС. Соответственно, мы сделали загрузку и этой информации.
(10) ФИАС действительно неполный. Так же с этим столкнулись. Можете подсказать в каком виде передавать запрос в ГИС и в каком формате они предоставляют ответную информацию? Временные ГУИДы потом как-то изменяются или они назначаются в качестве основных?
Автору несомненно плюс!
Все все вокруг все умеют, а выложить не каждый хочет.
На сайте ГИСа выложен регламент по оформлению заявок. Поищите.
Обратная связь, насколько знаю, просто ответное письмо, что заявка взята в работу. В файле потом данные появляются достаточно быстро. День-два, как-то так.
По поводу использования - ГИС пишут, что если временный УИД где-то был использован (был привязан к какому-то адресу), то менять его не нужно. Даже если появится "нормальный" УИД в ФИАС.
Просмотры 18834
Загрузки 44
Рейтинг 5
Создание 21.09.16 14:47
Обновление 28.02.19 13:59
№ Публикации 550401
Кому Бухгалтер
Конфигурация Не имеет значения
Операционная система Не имеет значения
Страна Россия
Вид учета Не имеет значения
Доступ к файлу Абонемент ($m)
Код открыт Да
См. также
Конвертация любых адресов, написанных в свободной форме, к ФИАС Промо
Допустим у нас есть база с адресами клиентов, и написаны они могут быть как душе угодно. С опечатками, без индексов, без разделителей, в совершенно любом формате. Вот было бы здорово иметь функцию, которая одним нажатием кнопки преобразует любую белиберду к строгому представлению адреса по ФИАС? Восстановит индекс, исправит опечатки и вернёт на 100% валидный адрес. Для всех, кто мечтательно сказал "ДА!", выкладываю данную обработку.
2 стартмани
30.06.2020 11212 100 XilDen 15
Сервис push-уведомлений для 1С (Push Notification Service For 1C - PNS4OneS)
1 стартмани
02.02.2022 4609 18 ltfriend 5
Создание интерактивных обучающих курсов с помощью Vanessa Interactive
Приветствую Вас, коллеги. Сегодня Вам предлагается рассмотреть технологию создания интерактивных обучающих курсов, системы Onboarding, интерактивной справки для любых конфигураций разработанных на базе платформы 1С при работе в web клиенте. Прошу посмотреть ролик, кому неинтересно, как это работает, можно дальше не читать. Тестировалось на 1С:Предприятие 8.3 (8.3.20.1646).
1 стартмани
02.02.2022 3268 0 Viktor_Ermakov 2
Универсальный метод, html шаблоны, страницы с авторизацией и без, многоязычность, страница авторизации, etc.
1 стартмани
22.01.2022 4446 7 vl-sher1 29
Модуль обмена с QIWI Промо
Компании, которые используют систему моментальных платежей QIWI, ценят ее за удобство по скорости выплат и для платежей по запросу. Но такие переводы сложны для учета, а при большом объеме проводимых операций отнимают много времени и превращаются в дополнительную головную боль. Мы сотрудничали с компаниями, которые отправляют большое количество платеже на QIWI, и часто слышали боль бухгалтеров о том, как им сложно работать с такими переводами. Поэтому мы автоматизировали выплаты через QIWI в 1С и создали модуль интеграции 1С c API QIWI Wallet и QIWI TopUp.
5 стартмани
25.05.2020 10666 1 Neti 10
Расширение конфигурации для Web-доступа к 1С (1С в роли back-end)
Для реализации того, чтобы 1С формировала и отдавала страницу, которую можно было бы открыть через браузер было написано расширение, которое позволяет публиковать из 1С произвольные ресурсы, будь то API, сайт или изображения / прочие файлы.
1 стартмани
01.04.2021 11878 13 SaschaG 4
Работа с картами в 1С на примере бесплатной библиотеки Leaflet
Разработка функционала отображения и выбора пунктов доставки на карте прямо в 1С с помощью бесплатной библиотеки Leaflet. Тестирование производилось на платформе 8.3.15.1534 на тонком клиенте.
1 стартмани
31.03.2021 14982 49 Parsec1C 18
1 стартмани
24.03.2021 10690 17 ltfriend 12
BIM: взаимодействие с платформой Autodesk Forge Промо
Предлагаемый пример демонстрирует широкие возможности для взаимодействия «1С:Предприятие» с платформой Autodesk Forge и позволяет вам получить базовые представления о применения технологий информационного моделирования в строительстве. Поддерживаются все версии платформы от 8.3.12 и выше до 8.3.18.
1 стартмани
25.11.2020 58202 13 kandr 3
Загрузка данных о продажах ОЗОН из API Ozon и Отчетов в формате *.xlsx в документ "Отчет комиссионера"
Обработки предназначены для следующих конфигураций: Бухгалтерия предприятия, редакция 3.0; Управление нашей фирмой, редакция 1.6; Управление торговлей, редакция 10.3; Управление торговлей, редакция 11; Комплексная автоматизация 2; ERP Управление предприятием 2
Федеральная информационная адресная система (ФИАС) создана Распоряжением Правительства Российской Федерации от 10.06.2011 №1011-р. С целью.
Замена КЛАДР. Тем не менее классификатор КЛАДР продолжает публиковаться и обновляться - версия 4.0 от 24.12.2012.
С момента первой публикации структура и содержание ФИАС многократно критиковались. Тем не менее, за время существования базы, она объективно улучшается и часть ошибок уже устранена. Поэтому указанные в этом документе несоответствия могут быть исправлены в будущем и их следует уточнять на свежих данных.
//ToDo - понятие "адрес" из докум. "Перечень типовых вопросов и предложений по использованию ПО «ФИАС»" // Секретность
Процесс импорта данных из файлов XML в реляционную базу данных дается на примере PostgreSQL. Все применяемые инструменты являются кросплатформенными. Для других БД (MySQL, Oracle и т.п.) процедура потребует незначительной доработки. См. также гл. 2.3, в которой приводятся ссылки на сторонние проекты, предоставляющие подготовленные данные в других форматах.
Создание таблиц
На сайте ФИАС представлены схемы XSD, описывающие структуру данных. Для преобразования схемы в формат SQL (CREATE TABLE. ) применим XSL Transformation (XSLT). В зависимости от БД может потребоваться изменить типы данных колонок.
Далее, полученные файлы SQL желательно откорректировать, чтобы явно назначить ключи (primary keys).
//// Ссылка на готовые файлы
Импорт данных
Для работы с большими файлами XML предпочтительнее применять потоковые парсеры: используется фиксированное количество оперативной памяти (в приведенном скрипте - порядка 80 Мб) на протяжении всего процесса работы.
Ниже приводится скрипт ETL Scriptella (Apache License) на базе парсера SAX. Он подходит для любой реляционной БД, для которой есть java-драйвер.
Другие источники
Данные ФИАС также распространяются в формате DBF. Для работы с ними рекомендуются утилиты типа PgDBF (импорт ФИАС).
- BasicData.ru - WebAPI и файлы для импорта в БД MySQL. Также может быть интересна БД "Почтовые отделения".
- Классификаторы России (rus-ref)
- zXML Parser - "Парсинг баз ФИАС в MySQL (потоковый XML парсер)". Программа из данных XML создает файл с sql-запросами.
Для понимания структуры данных ФИАС требуются следующие документы:
- Сведения о составе информации Федеральной информационной адресной системы (DOC);
- Описание структуры наборов данных ФИАС (DOC);
- Описание Классификатора адресов российской федерации (КЛАДР) (в архиве DOCUM.ARJ)
Таблицы
- ADDROBJ - Классификатор адресообразующих элементов (край > область > город > район > улица)
- HOUSE - Сведения по номерам домов улиц городов и населенных пунктов, номера земельных участков и т.п
- HOUSEINT - Интервалы домов
- LANDMARK - Описание мест расположения имущественных объектов
- NORMDOC - Сведения по нормативному документу, являющемуся основанием присвоения адресному элементу наименования
- ACTSTAT - Статус актуальности ФИАС
- CENTERST - Статус центра
- CURENTST - Статус актуальности КЛАДР 4.0
- ESTSTAT - Признак владения
- HSTSTAT - Статус состояния объектов недвижимости
- INTVSTAT - Статус интервала домов
- NDOCTYPE - Тип нормативного документа (закон, приказ, справка) // не упоминается в официальной документации
- OPERSTAT - Статус действия
- SOCRBASE - Типы адресных объектов (условные сокращения и уровни подчинения)
- STRSTAT - Признак строения
ADDROBJ
Текстовые элементы адреса
- OFFNAME - Официальное наименование
- FORMALNAME - то же что и OFFNAME , но оптимизированная для поиска
- SHORTNAME - Тип объекта: обл, р-н, г, ул. Расшифровку сокращений см. по табл. SOCRBASE .
Поле FORMALNAME создано специально для поиска: из него исключены все нестандартные символы и знаки пунктуации, буква "ё" заменена на "е" и т.п. Все записи удовлетворяют запросу:
Иерархия административных единиц
В таблице ADDROBJ иерархия построена по типу плоского дерева. И родительские и дочерние элементы хранятся в одной таблице. Воссоздание иерархии выполняется с помощью полей:
- AOGUID - Глобальный уникальный идентификатор адресного объекта. Не смотря на название, уникальным в пределах таблицы он не является. Могут существовать несколько исторический версий и одна единственная актуальная для данного объекта. Подробнее см. раздел "Статус актуальности".
- PARENTGUID - Идентификатор объекта родительского объекта. Содержит ссылку на AOGUID родительского элемента.
- AOLEVEL - Уровень адресного объекта. Условные названия уровней (подробнее см. табл. SOCRBASE ): 1 - регион 2 - зарезервирован 3 - район 4 - город 5 - внутригородская территория 6 - населенный пункт 7 - улицы 8 - зарезервирован 90 - дополнительная территория (ГСК, СНТ, лагери отдыха и т.п.) 91 - улицы на дополнительной территории (улицы, линии, проезды)
Получение полного адреса (от младшего к старшему):
AOLEVEL отражает административно-правовое подчинение, поэтому одни и те же текстовые элементы адреса могут располагаться на разных уровнях. Например, в снт. "Волжанка" (AOLEVEL=90) улицы имеют уровень 91 (против более распространенного 7):
(1) обл. Самарская (3) р-н Сызранский (90) снт Волжанка (91) ул. Ягодная (91) ул. Дачная (91) ул. Рябиновая
Аналогично, существуют населенные пункты без улиц. Например, в пос. Лужки иерархия заканчивается на уровне 6:
(1) обл. Орловская (3) р-н Мценский (6) п. Лужки
Таким образом, построение таблицы полных адресов следует начинать от верхних элементов (AOLEVEL=1) к нижним (AOLEVEL=91), как правило, запрос оформляется в виде множества подзапросов (subquery). Или рекурсивно подниматься от нижних, не имеющих дочерних элементов. Рассмотрим для примера второй вариант. Поскольку число полей в обоих случаях не определено, то полный адрес будет формироваться единой строкой:
- На настоящий момент существует 10 уровней ( AOLEVEL ). Но могут быть введены дополнительные. Например, ранее все ГСК и СНТ вносились на уровень 7 (улицы). Позднее, для них был выделен уровень 90 (дополнительные территории).
- На зарезервированных уровнях (2 и 8) не содержится записей, в том числе и исторических.
Статус актуальности
Из базы ФИАС почти никогда не удаляются элементы. Они могут быть только переведены в разряд "отключенных" (устаревшие, измененные и т.п.), что аналогично работе КЛАДР.
Примечание. Но информация о некоторых адресных объектах всё же может удаляться из БД ФИАС. См документ СВЕДЕНИЯ О СОСТАВЕ ИНФОРМАЦИИ ФЕДЕРАЛЬНОЙ ИНФОРМАЦИОННОЙ АДРЕСНОЙ СИСТЕМЫ, цитирую: "Технологически удалённые из БД ФИАС записи с адресными сведениями. включают удалённые администратором ФИАС по заявке операторов ФИАС (ошибочно введённые, дубли адресных сведений) адресные сведения". Т.е. дубли и ошибочно введённые данные могут быть физически удалены. Большинство из них приобретают статус актуальности КЛАДР (CURRSTATUS) равный 99, т.е. "несуществующий", а после этого уже становятся "технологически удалёнными". Если их нужно найти, то надо скачать т.н. "дельты данных", которые используются для обновления БД ФИАС, это архивы fias_delta_dbf.rar на сайте ФИАС. В некоторых из них имеются таблицы DADDROBJ, DHOUSE, и пр., содержащие технологически удалённые записи, попавшие в "дельту". На дату 15.12.2014 всего технологически удалено 793 записи, из них: 363 актуальных (т.е. ACTSTATUS = 1), 1 с CURRSTATUS != 99, и 1 с LIVESTATUS = 1.
Рассмотрим поля, определяющие действительность объекта:
Для выбора актуальных записей рекомендуется ориентироваться на поля CURRSTATUS и LIVESTATUS .
- LIVESTATUS - Признак действующего адресного объекта. Принимает значения: 0 - не действующий, 1 - действующий (см. прим. 1).
- CURRSTATUS - Статус актуальности КЛАДР 4. Принимает значения: 0 - актуальный, 1-50 - исторический, 51 - переподчиненный (см. табл. CURENTST и гл. 1.2. "Коды адресных объектов" документации КЛАДР).
- OPERSTATUS - Статус действия. Принимает значения: 1 - Инициация, 10 - Добавление, 20 - Изменение и др (см. табл. OPERSTAT ).
- ACTSTATUS - Статус актуальности адресного объекта ФИАС. Принимает значения: 1 - актуальный, 0 – не актуальный (см. табл. ACTSTAT ). Отвечает непосредственно за актуальность "имени". Если объект был переименован (чаще это исправление опечаток), то старая запись получает CURRSTATUS=1 и ACTSTATUS=0. Если же административная единица была ликвидирована или переподчинена, то имя останется по-прежнему актуальным: CURRSTATUS=99/51 и ACTSTATUS=1. В тоже время, при внесении изменений, не касающихся непосредственно адресной части, признак актуальности все равно сбрасывается (ACTSTATUS=0).
Также, в категорию актуальности можно отнести поля STARTDATE , ENDDATE , UPDATEDATE . Но, на данный момент (декабрь 2012 г.) значения этих полей редко бывают заполнены правильно.
Покажем на примере выбор актуальных и исторический записей. "Пермский край" был образован 01.12.2005 объединением "Пермской области" и "Коми-Пермяцкого АО". В базе ФИАС это отразилось следующим образом (см. табл. 1):
- Создана новая запись "Пермский край" (1-й столбец);
- Запись "Пермская область" (2-й столбец) сохранена, причем AOGUID обеих записей идентичен (для связи с дочерними объектами);
- Запись "Коми-Пермяцкий АО" (3-й столбец) также сохранена.
- ACTSTATUS для Коми-Пермяцкого АО сохранен в значении "Актуальный";
- OPERSTATUS не изменился - ошибочно(?);
- CURRSTATUS правильный (0 - актуальный, 1 - исторический, 51 - переподчиненный);
- LIVESTATUS показывает единственную актуальную запись, но значения инвертированы (см. прим. 1).
//ToDo - изменения в подчиненных объектах
- Все актуальные записи (CURRSTATUS = 0) имеют значение (LIVESTATUS = 1) и наоборот. Очевидно, что поведение LIVESTATUS не соответствует описанному в документации. Поле можно использовать для выбора актуальных записей, но с осторожностью до выяснения ситуации в будущем.
Исторические названия
Поля AOID , PREVID , NEXTID в совокупности составляют цепочку от современного к устаревшим наименованиям объекта. Хотя, если имеется два прямых предка (как в примере про "Пермский край"), то наследование невозможно отразить полностью однозначно.
В общем виде получение исторических вариантов наименований объекта имеет вид:
- Наблюдение (в документации не разъяснено): при внесении изменений, предыдущая историческая запись получает значение (CURRSTATUS = 1). Если вносится повторное изменение, то аннулируемая запись принимает значение (CURRSTATUS = 2). Таким образом, цепочка от современного названия к самому старому принимает вид: актуальное (0), предыдущее (3), более раннее (2), самое старое (1).
Адресные классификаторы
Записи в БД ФИАС содержат ссылки на другие российские адресные классификаторы:
- OKATO - код объекта административно-территориального деления (ОКАТО)
- OKTMO - код муниципального образования (ОКТМО)
- CODE - код КЛАДР
- PLAINCODE - код КЛАДР без признака актуальности (последних двух цифр), см. также CURRSTATUS
ФИАС предлагает собственный "классификационный код", который хранится, разбитым на отдельные элементы: REGIONCODE , AUTOCODE , AREACODE , CITYCODE , CTARCODE , PLACECODE , STREETCODE , EXTRCODE , SEXTCODE .
В целом, код является расширенным вариантом КЛАДР:
Могут быть случаи, когда адресному объекту в БД ФИАС не соответствует никакой КЛАДР-код, например:
Подробное описание см. в документе "Сведения о составе информации Федеральной информационной адресной системы".
Прочие поля
- Ведомственные классификаторы ФНС России: СОНО - IFNSFL , IFNSUL ; СОУН - TERRIFNSFL , TERRIFNSUL .
- CENTSTATUS - статус центра; ненулевое значение присвоено столицам, административным центрам и центральным районам регионов (подробнее см. табл. CENTERST ).
- NORMDOC - нормативный документ (табл. NORMDOC ).
На портал ФИАС выгружаются актуальные и исторические сведения ФИАС, а так же технологически удалённые из БД ФИАС адресные сведения. Актуальные и исторические сведения ФИАС выгружается в виде файлов (таблиц) DBF и файлов XML. Вместе с полной базой ФИАС выгружаются дельта данные – новые, изменившиеся и удаленные данные с момента предыдущей выгрузки базы. Дельта данные, т.е. новые, изменившиеся и удаленные данные появившиеся с момента предыдущей выгрузки базы ФИАС, загружаются по следующему алгоритму: по наличию или отсутствию ключа в пользовательской базе определяется тип операции – добавление или обновление записи. После проведения соответствующих операций необходимо удалить по ключу записи, присутствующие в таблицах технологически удаленных данных.
Наличие таких "дельт" позволяет быстро обновить БД ФИАС, не скачивая полный архив (на 2014.12.01 его размер составляет 1.8 Гб). Алгоритм обнобления, действительно, довольно прост. Привожу текст процедуры обновления для MySQL на примере таблицы ADDROBJ:
Иногда может изменятся структура самих таблиц, что требует ручного контроля. Например, колонка "oktmo" сначала содержала 8 символов, а потом была расширена до 11 символов.
Тем не менне, несмотря на удобство обновления через дельты, я рекомендую для обновления заменять БД ФИАС целиком (а после этого объединять её с таблицами технологически удалённых данных, при необходимости). Дело в том, что дельты могут содержать неполную информацию, проще говоря oldfias + delta != newfias. Например, я обновлял БД ФИАС от 2012.07.01 через дельты до состояния на 2012.09.24. Если в дельте была информация о переподчинении или об изменении адресного объекта, то предыдущая версия адресного объекта не обновлялась, т.е. не проставлялось (NEXTID = ид_нового, LIVESTATUS = 0, ACTSTATUS = 0). В результате в БД ФИАС были объекты с одинаковым AOGUID, но имеющие ACTSTATUS = 1. Некоторые новые данные просто отсутствовали в дельте. Возможно, что разработчики ФИАС уже исправили эти ошибки, и более свежие дельты следующие за 2012.09.24 содержат полную информацию, но это требует проверки.
БД ФИАС может содержать ошибки в данных, а) связанные с нарушением целостности двунаправленных списков PREVID/NEXTID, б) ошибки, когда запись об адресном объекте имеет OPERSTATUS = 1, а в действительности произошла другая операция (переименование, переподчинение, слияние, или дробление), и в) ошибки, когда отсутствуют исторические сведения (вызванные тем, что администраторы БД ФИАС, видимо, выполняли прямое изменение данных с помощью SQL-запросов).
Для иллюстрации можно открыть портал ФИАС и воспользоваться расширенным поиском. В поле "Регион" введите "Санкт-Петербург город", в поле "Уровень" выберите "Регион". Нажмите "Найти". Если просмотреть историю изменения города Санкт-Петербург, то можно обнаружить, что Санкт-Петербург раньше назывался "станция Володарская", а должно быть "Ленинград". Это иллюстрирует нарушение целостности двунаправленных списков.
Для иллюстрации ситуации, когда отсутствуют исторические сведения можно рассмотреть адресный объект с AOGUID="df84b14c-6006-46d1-8ce3-3a6ddf8643bd". В БД ФИАС от 2012.08.06 этот объект имел КЛАДР код равный 24000001101000100. В какой-то момент произошло переподчинение родительского объекта, и в итоге у него изменился уровень AOLEVEL с 6 на 90. Соответственно, уровень AOLEVEL дочернего объекта изменился с 7 на 91. Если взять БД ФИАС от 2014.12.01, то в ней нельзя обнаружить исторической записи с КЛАДР кодом равным 24000001101000100. Нет этой записи и в таблицах DADDROBJ.
Ошибки с неправильным OPERSTATUS слишком многочисленны, их классифицирование выходит за рамки данной статьи.
Читайте также: