Comments 119
Вот так новость, спасибо!
XML в архиве весит 803Мб — нехило, сейчас посмотрим что они там придумали.
Для формата dbf написано дофига библиотек, в том числе под ДОС. Это значительно упрощает миграцию для старых приложений.
Посмотрел форму поиска на сайте fias.nalog.ru — удобно, думаю в своем проекте сделаю так же.
Но что собственно говоря изменилось, при поверхностном просмотре непонятно.
Код остался в таком же виде: 2300300100000 (Анапа)
Читайте документацию, там кроме этого кода еще вагон полей (например родительский элемент, который позволяет легким движением запросом выбирать следующий или родительский уровень данных).
безусловно я так и поступлю, поставил на закачку xml-базу :)

Использовать XML для распространения было очень правильным решением!
«И это хорошо!» (с)
Я в том смысле, что отлично, когда разработка нового стандарта согласованна с предыдущими наработками. Если какой-то старый кусок вписывается в рамки нового, то и нужно его туда включать, а не перехерачивать все с нуля с полной несовместимость со старыми данными.
Первый разя я матюгнулся, когда полез смотреть по ссылке описание структуры и мне вылез *.doc — html ради этого и разрабатывался, чтобы выкладывать в этом формате документы. А второй и последни, когда увидел это.
Неужели люди, разрабатывающие такие технологии не думают об их использовании?
Я совершенно не оспариваю выбор xml как способ структурирования данных, но реализация в таком виде оставляет желать лучшего ибо с этими размерами невозможно эффективно работать. Я имею в виду, что такой подход заставит разработчиков применять к представленным данным свои средства хранения: MSSQL, MySQL.
Я считаю, что наиболее эффективным подходом было бы использование sqlite баз. 1. Размеры были бы гораздо меньше за счет отсутствия расходов на структуру, которая раздувает размеры неимоверно.
2. Достаточно распространены провайдеры для этих баз, открытый формат.
3. Отсутствие привязки к серверу базы данных.
Можно провести более глубокий анализ, но в первом приближении данный выбор кажется мне лучшим.
но реализация в таком виде оставляет желать лучшего ибо с этими размерами невозможно эффективно работать.

Откройте для себя потоковые xml-парсеры. DOM построить да нельзя, а вот потоковым выбрать данные да запросто.

Я имею в виду, что такой подход заставит разработчиков применять к представленным данным свои средства хранения: MSSQL, MySQL.

Все равно все так и делают.

Я считаю, что наиболее эффективным подходом было бы использование sqlite баз. 1. Размеры были бы гораздо меньше за счет отсутствия расходов на структуру, которая раздувает размеры неимоверно.

Поверьте мне сильно она не уменьшится. Там фишка в том что к примеру к тому же дому клеится два длинных ID и информация дополинтельная.

2. Достаточно распространены провайдеры для этих баз, открытый формат.

Xml тоже открыт. И библиотек необходимых еще больше.

Я в курсе потоковых парсеров. Я говорю об эффективности, а не о возможности.
Потоковые парсеры вполне эффективны. К тому же с моей точки зрения это формат иморта. Никто напрямую с этим работать не будет.
Все верно: xml — это формат представления данных
В данном случае он более чем уместен, т.к. позволяет достаточно легко спарсить данные в необходимый пользователю формат
Вас я бы на работу не взял.

По моему тут даже моей бабушке понятно, что XML Это просто формат для иморта/экспорта данных.
Вводить в проект поддержку sqlite дороже, чем поддержку xml или перегнать данные в нужный формат из xml © К. О.
В тот, который использует для хранения данных по умолчанию ИС, в которую будет внедряться ФИАС.

А большинство ИС у нас ВНЕЗАПНО клиент-серверные и многопользовательские. SQLite никто не использует, так как он ВНЕЗАПНО однопоточный.
По правде сказать, я не рассматривал «клиент-серверные и многопользовательские ИС». Возможно, сейчас софт для гос. учреждений и начала эволюционировать, но лет 5 назад он был как раз десктопным и однопользовательским, а полученную инфу таскали на дискетках.
Типичным для меня видением является использование этих самых файлов в разработке десктопного приложения без сервера.
Буду рад узнать, что в данной сфере всё изменилось, но пока такой информацией не владею.
Все изменилось и уже давно. В смысле более 5 лет назад.

И есть даже такое (по сути ESB для интеграции ведомств в масштабе всей страны).
Ну, и да — КЛАДР был стандартом не только для госучреждений, но и вообще самой стандартной БД адресов в стране и активно используется и в множестве enterprise-софта.
В связи с этими ужасающими объёмами вопрос:
чем в OS X можно посмотреть такие огромные xml-файлы и поиграться с запросами?

P.S. Попытался открыть в Textmate и Safari, после чего они умерил не приходя в сознание.
боюсь что такие вещи только потоквыми парсерами можно открыть. в принципе есть code.google.com/p/xpath4sax/, но проще мне кажется найти утилиту чтобы dbf перегнать в нормальную базу
Возьмите Sedna. Я 4-гигабайтный XML скармливал этому чуду (да, это какое-то время занимает), а потом XPath-запросами моментально получал из него все, что мне нужно.
Надеюсь теперь номера домов и улицы будут все, а то в КЛАДР как-то адреса с точностью до инспекции. Отличная новость
Там есть онлайновый справочник. Из плюсов дома таки да ОТДЕЛЬНО. Но пока не все. На моей улице нет моего дома к примеру.
Мне вот интересно, как согласуется «национальная программная платформа» и перевод госучреждений на OpenSource, с описаниями в doc/docx и тотальным засилием всякого микрософта даже в такой не предназначенной для него области, как сайтостроение?
да легко, через высокий уровень коррупции и низкий — интеллекта
Можно номер стандарта или ссылку на него? Желательно ГОСТ, хотя пойдёт и ISO.
Тебя не проведешь!!!

— PS. Я шутку понял) Увы на хабре с этим серьезные проблемы) Без тега сарказм уже никто не понимает.
Как бы в фнс-е вообще очень много майкрософта. К примеру, mssql кругом. :)
Поддержкой нового классификатора занялась свежесозданная компания ФИАС Ко :)
Интересно квартиры с буквами и дробями — учли?
А то их есть в моей деревне =)
RTFM.

Предусмотрены даже объекты, «для которых нельзя указать точный структурированный адрес (почтовый адрес). Значение блока записывается в произвольном виде, позволяющем однозначно определить местонахождение объекта недвижимости через известные ориентиры на местности.»
базу ФИАС в двух форматах dbf и xml

XML? Не ужели они узнали о это формате? Кстати dbf все так же в cp866? :]
О существовании XML ФНС давно уже знает. Только в областях отличных от КЛАДРа.
Теперь и тут. Кстати я посмотрел тут формат и описание, вполне годно. Самое главное появилась отдельная таблица домов. Что радует.
Почему все так восхищаются отдельной таблицей домов? Ведь в КЛАДР номера домов тоже были выделены в отдельную таблицу.
Потому что в КЛАДР это строки с номерами домов. Типа вот у нас тут так. И опять же там не все дома. Эти обещают все. Что было бы неплохо. А то адресная информация получается до улицы, а дальше каждый в свою дуду дудит.
Логично, что dbf в cp866, его(dbf) и оставили для совместимости со старыми разработками.
вот если бы еще и координаты добавили, вообще цены не было бы этой базе!
Список улиц конкретного города, по всем городам вынуть удаться только в несколько заходов. И да там у дома насколько я помню координат несколько, так-как отрисовано оно не одной точкой.
Честно говоря, не так просто найти хорошие (и свободные) библиотеки для работы с DBF для современных языков и систем программирования. (Речь не идёт о штуках типа MS Access). DBF скорее мёртв, чем жив.

Может быть, лучше бы распространяли в формате базы SQLite — она кроссплатформенна и достаточно универсальна.

XML? Куча пробелов там, небось? Для «ускорения» парсинга. И что, там реально вложенные структуры? А то, может, обычного CSV хватило бы?
XML? Куча пробелов там, небось? Для «ускорения» парсинга. И что, там реально вложенные структуры? А то, может, обычного CSV хватило бы?

Пробелов нет вообще. В CSV вы не сможете выгрузить вот этот кусок. А вот в xml запросто.
кстати, там нет вложенных элементов.
такчто всё выгрузится в csv.

иерархии организованы через ссылку на родительский guid,
а также косвенно, через коды регион-округ-район-город-пункт-улица.
Когда столкнулся с dbf, я просто сконвертировал его библиотекой, написанной на ruby, в csv и работал уже с ним. Никаких проблем, кроме потраченных пяти минут на поиск нужного решения, не было.
ИМХО мертворожденное
1. Структурно.
Соответсвует модным подходам в БД, но сама структура российских адресов им не соответсвует, т.е. притянуто за уши и обработка исключительных случаев будет невозможна.

Попытка смешать местоположение и адрес к хорошему не приведет.
Привязать гео координаты к адресу — достойная задача, а вот писать в улицу «31 км 200 м Черлакского тракта» — это полный бред. Конечная цель каждого адреса — доставка.
Вот удивиться почтальон когда поймет что пилить надо 31 км непонятно куда=)

2. Организационно.
Адреса ведут муниципалитеты. Там и так бардак, и добавление этой функции прядка не добавит.
Говорить о синхронности действий муниципалитетов говорить вообще не приходится=)
Для примера — одно шоссе проходящее через 3 муниципалитета будет введено 3 раза под отдельными номерами.
Возможно это не баг, а фича, но «не плодите сущности без меры» никто не отменял.

Ex.
Сдт Березка-2 от КЗАМЭ
и так 8 раз, т.к. введено разными людьми из разных муниципалитетов.

3. Целостность
Множество домов без индекса (~ 7000 записей в среднем от 10 до 500 домов на запись), а от индекса считается стоимость доставки, а это значит что вся автоматическая тарификация по этим домам будет развалена.

в строке улица данные
Гаражи в районе ул.Вокзальная 18г
Гаражи в районе ул.Геологов 52
Гаражи в районе ул.Геологов 28
Гаражи в районе ул.Гоголя 57
Гаражи в районе ул.Гоголя 60а
Звезда-3 5 км от д Сорокино
Серебристый от д Свищево 1км
Л.м. в 1.5 км. от дор. Соликамск-Кунгур
Сдт Автомобилист от ПРЗ
4000м от п.Березовка на восток
1500м от п.Березовка на юго-восток
4700м от п.Березовка на восток
4500м от п Первоманский на юго-запад
Промплощадка ООО Ковдорский торговый дом
Промплощадка ООО Топкинский цемент
СНТ ООО дизайн-студия Маренго

говорит о качестве ввода и его контроле.

Понятия снесенного дома нет в базе, как и дома на реконструкции.

Почта РФ говорит о 40-50 млн объектах почтовой связи
в фиас сейчас по оценкам около 5 млн объектов

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

ЛОЛ ШТО? Вообще-то адресная база хороший пример того, что отлично кладется без всякого мата в РСУБД.

Попытка смешать местоположение и адрес к хорошему не приведет.
Привязать гео координаты к адресу — достойная задача, а вот писать в улицу «31 км 200 м Черлакского тракта» — это полный бред. Конечная цель каждого адреса — доставка.

Между тем может быть официальным адресом. Если вы можете придумать как по другому сделать то давайте рассказывайте.

Адреса ведут муниципалитеты. Там и так бардак, и добавление этой функции прядка не добавит.
Говорить о синхронности действий муниципалитетов говорить вообще не приходится=)
Для примера — одно шоссе проходящее через 3 муниципалитета будет введено 3 раза под отдельными номерами.

Вообще это там решено. И шоссе кстати там нет.

Сдт Березка-2 от КЗАМЭ
и так 8 раз, т.к. введено разными людьми из разных муниципалитетов.

А коды смотрели? Я вот смотрел и в свое время выгружал КЛАДР на такой объем информации уровень ошибок целостности там низок.

Множество домов без индекса (~ 7000 записей в среднем от 10 до 500 домов на запись), а от индекса считается стоимость доставки, а это значит что вся автоматическая тарификация по этим домам будет развалена.

У населенного пункта имеется. Стоимость доставки считается по нему, а никак не по индексу дома. Индекс дома это только к какому почтовому отделению относится дом. И полезен исключительно при доставке.

Понятия снесенного дома нет в базе, как и дома на реконструкции.

Там есть пометка действующий адрес. Вообще в данный момент эта база основана на КЛАДР где нормальная точность была до улицы. Дальше был ад и израиль. Сейчас они хотят получить точность до дома, что уже хорошо.

Почта РФ говорит о 40-50 млн объектах почтовой связи
в фиас сейчас по оценкам около 5 млн объектов

Под объектом почтовой связи что тут подразумевается? Дом или помещение? Опять же в КЛАДР и ФИАС точность справочника домов не взирая на его объем желают лучшего. Но в КЛАДР раньше было написано точность до улицы. Не более.

>а от индекса считается стоимость доставки
В этом случае будет достаточно индекса родительского объекта. Внутри города стоимость не различается.
Хороший вариант, особенно формат XML — теперь проще будет встраивать в веб-приложения.
А еще непонятно зачем было доверять делать сайт очередным криворуким пионерам и чем не устраивали обычные ссылки на скачивание? Но нет же — обязательно нужно извратиться через какой-нибудь убийственный яваскрипт. И в результате в последнем 11-м фоксе
Ошибка: __doPostBack is not defined
Источник: javascript:__doPostBack('ctl00$contentPlaceHolder$downloadRadGrid$ctl00$ctl04$formatKladrSZLinkButton','')
Строка: 1
Это самый обычный ASP.NET, причем тут «убийственный яваскрипт»?
Печально, что адресные базы становятся лучше, но все так же ужасно далеки от реальности…
Не знаю кто как, а я не вижу разницы между кривым яваскриптом с ничем не обоснованной избыточностью (убийственностью) без названия и тем же самым с названием заглавными буквами и с точкой :)
Очень странно с моей точки зрения называть «криворукими пионерами» людей, которые для создания сайта использовали одну из самых распространенных веб-технологий. То, что у вас оно не работает — не значит, что оно плохо.
Я не защищаю WebForms (терпеть не могу, если честно), но подобные заявления отдают каким-то айти-экстремизмом.
/offtopic
Мне тоже стыдно конечно, но с объективной точки зрения они именно криворукие и именно пионеры. Если не понимают вред любой избыточности системы и жертвуют устойчивостью и скоростью работы во имя удобства разработки и модности технологии. А массовость рядов «не понимающих» не делает их менее криворукими и менее пионерами.
PS (сайт не работает в одном браузере на чистой системе) === (сайт не работает)
Я могу, конечно, многого не понимать, но имхо было бы лучше всем, если бы база (сами XML файлы) была доступна по rsync. А еще лучше под git'ом.
Эти точно не сделают. А если и сделают, то вместо нормального rsync'а будет какая-то кривая, адски глючащая, самописная проприетарная приблудина на дотнете.
Старнный вопрос, и тот и другой не особо распространены (то есть в рф rar всяко лучше 7z распространен), почему не zip был бы законным вопрос… может быть чуть чуть хуже степень сжатия, зато разархивировать любой холодильник сможет %)
Так принято, rar прочно засел в мозгах российских обывателей. Зря он что ли в топе продаж. Гнать бы надо — да некому, привыкли же.
местный админ тетеньке которая архивирует (и фиксирует ежедневно в бумажном и пронумерованном журнале) поставил ZVER, а там…
за две минуты нашел дубль в базе (причем еще неправильно названный не ПД а СОТ)
Неудачная идея была… XPathDocument весь xml грузит в память.
По мотивам статьи пробую XmlTextReader (кстати, чем он отличается от XmlReader?).
некорректная схема или xml:
AS_INTVSTAT_2_250_11_04_01_01.xsd
AS_INTVSTAT_20120307_ff633bef-b21a-479d-8f04-705541a70b4e.XML
наименования атрибутов различаются.
В документации не описано поле LIVESTATUS, которео есть в XML базах.
Не могу найти сроки введения базы в эксплуатацию. Даже в приказе нету.
Когда продакшн-релиз?
Че-то не понял а как забирать базу? Руками скачивать что-ли? Нет какого-то урла чтобы забирать?
Есть публичный OLAP кубик по фиасу вот тут www.roscomputing.com/ru/address-olap/AddressOlap.aspx Можно делать анализ целостности базы и получать статистику. Например, можно убедиться, что среди адресных объектов много битых ссылок на нормативные документы и т.п.
Only those users with full accounts are able to leave comments. Log in, please.