Материалы:КЛАДР: Настоящее, прошлое и будущее

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

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

По сложившимся обстоятельствам, я более 10 лет назад отошел от конкретных работ по ведению КЛАДР, но продолжал отслеживать его состояние. Уже 10 лет назад опыт использования КЛАДР показал необходимость совершенствования его структуры. Однако приступить к этому решили только сейчас.

Поэтому, я решил разместить на сайте статью, подготовленную семь лет назад, но до сих пор не публиковавшуюся. Прочитав ее, я увидел, что текст неплохо бы слегка отредактировать, что я и сделаю, когда будет более понятной концепция ФИАС. Пока привожу текст статьи без изменений (т.е. если в статье будет использоваться понятие «настоящее время» - это означает, что речь идет о 2003-2004 годах).

Классификатор адресов России: история, настоящее, будущее

1. История создания

В 1995 году мне было предложено рассортировать сведения о доходах физических лиц, хранящихся в электронном виде (в файлах) в Государственной налоговой инспекции (ГНИ), по г. Москве, по районным налоговым инспекциям в соответствии с адресом места жительства (сведения о доходах содержат сведения об адресах физических лиц – получателей доходов). Для этого мне был предоставлен справочник, в котором каждой улице Москвы, а при необходимости, и конкретному дому или интервалу домов, был поставлен в соответствие номер районной Государственной налоговой инспекции (ГНИ).

В то время Справки о доходах физических лиц сдавались в ГНИ, в основном, на бумаге. Затем информация из справок вручную вводилась в файлы операторами с использованием специальной программы. Адреса физических лиц хранились в отдельном поле файлов сведений о доходах в используемой до сих пор структуре «9 запятых». Эта структура обеспечивала разделение компонентов адреса (код страны, почтовый индекс, код региона, наименование района, наименование города, наименование населенного пункта, наименование улицы, номер дома, номер корпуса, номер квартиры) запятыми, что существенно упрощало разбор адреса для его обработки. Однако написание в сведениях о доходах каждого компонента адреса было достаточно произвольным. Программные средства, с помощью которых осуществлялся ввод адреса, конечно, использовали, так называемые динамические (самопополняемые) справочники. Но первоначально у каждого оператора справочники были пустые, кроме того, операторы не всегда использовали уже введенные значения, так как всегда существовала возможность ввести наименование вручную. Это приводило к появлению нового варианта написания улицы. Кроме того, информация вводилась разными операторами и в разных районных ГНИ, что приводило к различным написаниям одной и той же улицы в различных справочниках. (В дальнейшем, при автоматической конвертации адресной информации в чековых инвестиционных фондах, было выявлено 37 различных написаний г. Санкт-Петербург, в т.ч. Ленинград, СПБ и даже Санкт-Петроград).

Работа по сортировке информации была сведена к унификации представления информации о «привязке» домов и корпусов в справочнике распределения территории Москвы между ГНИ, а также к преобразованию адресной информации в сведениях о доходах в соответствии со справочником улиц. Так как задача облегчалась тем, что обрабатываемые адреса принадлежали к одному городу, и распознавать необходимо было только улицы, сроки ее реализации оказались небольшими. Более 80% распознаваний было осуществлено в автоматическом режиме, остальное – в автоматизированном.

Анализ проделанной работы позволил сделать вывод о необходимости использования единого справочника при вводе элементов адреса. Так как сведения о доходах физических лиц должны собираться на территории всей России и доводиться до нужных налоговых органов, справочник должен позволять вводить информацию о местах жительства физических лиц на территории всей России. Исходя из этого, справочник должен вестись только централизованно.

Использовать существующий в то время справочник СОАТО (в настоящее время ОКАТО) не представлялось возможным. Во-первых, этот справочник служит только для обозначения административно - территориального деления. Объем справочника СОАТО в 1995 г. был всего 20 тысяч объектов. Детализация его заканчивалась уровнем сельских советов (улицы отсутствуют и в настоящее время). Во-вторых, структура справочника и содержащихся в нем кодов административно – территориального деления, из-за многочисленных исключений из правил, не позволяли эффективно использовать справочник в процессе ввода информации. Поэтому было принято решение о разработке нового справочника, позволяющего эффективно использовать его как в процессе ввода адресной информации, так и в процессе ее контроля и обработки. Имя этому справочнику дано КЛАДР – классификатор адресов России. Может быть название справочника получилось неудачным, но оно прижилось.

Следует учесть, что первоначально ставилась достаточно узкая задача – сортировка информации о доходах физических лиц.

2. Состояние и использование Классификатора адресов в настоящее время

2.1. Проблемы межведомственного взаимодействия и построение единого информационного пространства

В настоящее время стало модно говорить о построении единого информационного пространства административных формирований (регионов, районов, городов). Известны и попытки создания межведомственных информационных систем в России в целом (например, АИС «Доход»). При этом дальше разработки концепции таких систем дело не идет. Одной из основных причин является несовпадение справочников и классификаторов в различных ведомственных системах.

Важность использования единого информационно – лингвистического обеспечения отражена даже в Библии. «Все люди на земле имели один язык и одинаковые слова. Двинувшись с Востока, они нашли в земле Сеннаар долину, и поселились там. И сказали друг другу: наделаем кирпичей и обожжём огнем. И стали у них кирпичи вместо камней, а асфальт вместо извести. И сказали они: построим себе город и башню высотою до небес; и сделаем себе имя, чтобы мы не рассеялись по лицу всей земли. И сошёл Яхве посмотреть город и башню, что строили сыны человеческие. И сказал Яхве: вот один народ, и один у всех язык; это первое, что начали они делать, и не отстанут они от того, что надумали делать. Сойдём же, и смешаем там язык их, так чтобы один не понимал речи другого. И рассеял их Яхве оттуда по всей земле; и они перестали строить город. Посему дано ему имя: Бабель (Вавилон), ибо там смешал Яхве языки всей земли, и оттуда рассеял их Яхве по всей земле». (Быт. II, 1—9). Заметьте, для того, чтобы прекратить работы Бог отнял у людей не кирпичи, не асфальт, а единый язык.

Наиболее сложно решается проблема построения единого адресного пространства. Как правило, адресная информация вводится в виде произвольного текста, что позволяет ее хранить в базах данных, но не позволяет производить ее автоматизированную обработку (например, эффективный поиск необходимой информации по заданному адресу). Известны случаи автоматизированного межведомственного взаимодействия, которые подчеркивают эту проблему. В одном из регионов удалось наблюдать передачу данных из ЗАГСов в налоговые органы на магнитных носителях, как это требовалось совместным решением. В составе информации, передаваемой из ЗАГСов, были данные, позволяющие идентифицировать конкретное физическое лицо: фамилии, имена, отчества, документы, удостоверяющие личность и адреса места жительства. Так вот, проблем не было только с автоматизированной обработкой фамилий, имен и отчеств, т.к. для остальных данных необходимо использовать единые справочники. В результате информация на дискете сопровождалась программой распечатки, информация выдавалась на бумагу, а затем вручную вводилась операторами в базу данных налогового органа. Схожая ситуация наблюдается в настоящее время при передаче информации в налоговые органы из ГИБДД.

На самом деле, конвертировать представление документов, удостоверяющих личность, из одной формы в другую не сложно. Гораздо труднее осуществить конвертацию адресов.

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

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

2.2. Структура Классификатора адресов

Объектами классификации являются отдельные элементы почтовых адресов, называемые в дальнейшем адресными объектами: регионы, районы, города, поселки городского типа, сельские населенные пункты и улицы. В последнее время к объектам классификации добавляются дома, корпуса и квартиры. В классификаторе принята иерархическая система классификации.

Все объекты располагаются по восьми уровням классификации.

Первый уровень классификации включает объекты федерального значения (регионы): республики, края, области, автономные области, автономные округа, входящие в состав Российской Федерации, города Москва, Санкт-Петербург и Байконур.

Второй уровень классификации включает районы (улусы) республик, краев, областей, автономных областей, автономных округов, входящих в состав Российской Федерации.

Третий уровень классификации включает: города и поселки городского типа регионального и районного подчинения; сельсоветы (сельские округа, сельские администрации, волости).

Четвертый уровень классификации включает: города и поселки городского типа, подчиненные администрациям городов третьего уровня; сельские населенные пункты.

Пятый уровень классификации включает улицы городов, поселков городского типа и сельских населенных пунктов.

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

КЛАДР поставляется в виде DBF-файлов. В файле Kladr.dbf содержатся объекты с первого по четвертый уровни классификации, в файле Street.dbf – пятый уровень, в файле Doma.dbf – шестой.

Структуру кодового обозначения в файле Kladr.dbf можно представить в следующем виде:

СС РРР ГГГ ППП КК, где СС – код субъекта Российской Федерации (региона); РРР – код района; ГГГ – код города; ППП – код населенного пункта; КК – код актуальности наименования. Структуру кодового обозначения в файле Street.dbf можно представить в следующем виде:

СС РРР ГГГ ППП УУУУ КК, где СС – код субъекта Российской Федерации (региона); РРР – код района; ГГГ – код города; ППП – код населенного пункта; УУУУ – код улицы; КК – код актуальности наименования.

Код актуальности представляет собой двух символьное цифровое значение от 00 до 99. При этом код 00 означает актуальное наименование, остальные – устаревшее. (Введение кода актуальности в состав классификационного кода адресного объекта является ошибкой, к которой автор данной статьи не имеет отношения. Это противоречит принципам построения реляционных отношений. Конечно, следовало использовать отдельное поле).

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

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

3. Перспективы развития Классификатора адресов

3.1. Назначение КЛАДР

Разработка больших информационных систем невозможна без унификации информационного обеспечения (ИО). Одним из способов унификации ИО является использование классификаторов.

Классификатор адресов России предназначен для обеспечения следующих функций, реализуемых в АИС:

• унификация способов хранения и обработки адресной информации любыми задачами АИС;
• сокращение объемов адресной информации, как при ее передаче, так и при хранении в базе данных;
• автоматическое поддержание актуальности адресной информации;
• обеспечение корректного ввода адресной информации оператором;
• поиск и сортировка по адресам любой информации, хранящейся в АИС;
• обеспечение взаимообмена адресной информацией с объектами других ведомств.

Рассмотрим каждую из этих функций.

a) Унификация способов хранения и обработки адресной информации

В настоящее время стало модно говорить о построении единого информационного пространства административных формирований (регионов, районов, городов) или о создании межведомственных информационных систем. Создание таких систем не возможно или не эффективно без использования единых классификаторов.

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

Таким образом, использование КЛАДР позволяет решить следующие задачи:

• обеспечение взаимообмена адресной информацией между различными АИС;
• обеспечение непосредственного доступа к элементам адресной информации в базах данных взаимодействующих АИС;
• сокращение времени и стоимости разработки АИС за счет использования единых процедур и методов обработки адресной информации.

b) Сокращение объемов адресной информации

Использование кодов КЛАДР при передаче и хранении адресной информации позволяет существенно сократить ее объемы. Особенно это важно в системах, ведущих учет физических лиц на федеральном уровне.

Количество физических лиц, данные о которых могут храниться на федеральном уровне может превышать 100 миллионов. При этом цена каждого «лишнего» байта при хранении информации достигает 100 МБ дискового пространства. Практика хранения учетной информации по физическим лицам в МНС РФ показала, что в среднем требуется более 100 байт для представления адреса в текстовом виде. Если сравнить эту величину с размером кода КЛАДР, то экономия памяти при хранении одного адреса для каждого физического лица в сумме на федеральном уровне может превысить 10 ГБ. Если учесть, что в составе данных, хранящихся по физическим лицам, могут быть несколько адресов (место жительства, место рождения, адреса недвижимости и т.п.) преимущество, получаемое от использования КЛАДР бесспорно.

c) автоматическое поддержание актуальности адресной информации

Если же считать, что сокращение объемов хранения адресной информации не столь существенно, учитывая современные возможности дисковых накопителей, следует учесть, что хранение информации в кодах позволяет автоматически актуализировать адресную информацию. При переименованиях адресных объектов коду объекта ставится в соответствие новое наименование и все! Можно учесть и переподчинение адресного объекта при изменении административного деления (например, при слиянии населенных пунктов или регионов).

d) Обеспечение корректного ввода адресной информации оператором

Среди приведенных функций одной из важнейшей является обеспечение корректного ввода адресной информации оператором.

Для того чтобы адресная информация поступила на обработку в АИС, она должна быть введена оператором с помощью клавиатуры или непосредственно из документа с использованием сканирующих устройств.

Оператор, как правило, вводит адресную информацию (адрес), представленную в документах. При этом причинами некорректного ввода информации могут быть:

• ошибочное представление адреса в документе;
• ошибки оператора при вводе адреса.

Практика обработки адресных данных показывает, что, казалось бы, простейшая задача написания адреса, не всегда решается верно. Как правило, источником адресной информации являются документы, удостоверяющие личность (для физических лиц) или регистрационные документы (для юридических лиц).

Рассмотрим реальный пример: физическое лицо проживает по адресу: Московская область, г. Одинцово, Можайское шоссе, д.115, кв.76. В паспорте проставлен штамп регистрирующего органа с указанием его наименования: "Московская область, ПВС Одинцовского УВД, паспортный стол N 1". В поле адреса записано: "Можайское шоссе, д.115, кв.76". Таким образом, при написании адреса могут встретиться различные варианты:

"Московская область, г. Одинцово, ...";

"Московская область, Одинцовский р-н, г. Одинцово, ...";

"г. Одинцово, Одинцовского р-на Московской области, ...";

"г. Одинцово, Московской области ..." и т. п.

Распознавание таких адресов алгоритмическим путем хотя и возможно, но носит вероятностный характер, резко усложняет программу и увеличивает время обработки информации.

Еще более часто встречаются ошибки операторов, при которых искажается написание элементов адресной информации. Это возможно либо как в результате невнимательности, так и определяться незнанием правильного написания того или иного наименования. Например, очень часто встречалась ошибка в написании улицы Орджоникидзе.

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

слово «карова» заменить одним из слов корова, крова и какова;

слово «послась» заменить одним из слов паслась, послабь и послать;

слово «дваре» заменить одним из слов варе, даре, дворе, аваре и два ре.

Другой пример. Если в слове парашют сделать одну ошибку: парашут, то Word дает на выбор три варианта, из которых один правильный: парашу, парашют, пара шут. Если же сделать две ошибки: порошут, слово не распознается совсем (порошу, порошу т, порошат, порошит).

Для обеспечения автоматического распознавания структуры адреса, используется его форматированное представление, в котором за иерархическими элементами адреса закреплены определенные позиции, отделяемые разделителем (например, запятой). Приведенный выше адрес представляется в формализованной структуре в следующем виде: ",143000,,Московская обл,,Одинцово г,,Можайское шоссе,115,,76". При ручном вводе оператором характерной ошибкой при этом является пропуск или ввод лишних запятых.

Более целесообразно обеспечить единственный вариант представления адресной информации с использованием справочников. При таком варианте при вводе адресной информации на экран компьютера вызывается окно с требуемым конкретной ситуацией составом полей, которые должны содержать адресные объекты. Значения полей выбираются из справочников. Такой ввод приводит к невозможности совершить никаких видов ошибок, из перечисленных выше.

Структура КЛАДР разрабатывалась именно исходя из наиболее удобного использования его в процессе ввода информации.

e) Поиск и сортировка информации по адресам

Хранение в БД адресной информации в неформализованном виде, как правило, не позволяет эффективно производить поиск по заданным критериям. Использование же КЛАДР для кодового представления адресов, дает возможность строить эффективные индексы, обеспечивающие практически мгновенный поиск информации по заданному адресу.

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

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

f) Обеспечение взаимообмена адресной информацией с объектами других ведомств

Этот пункт даже не требует пояснения.

3.2. Совершенствование КЛАДР

КЛАДР является, пожалуй, самым широко используемым классификатором в России. Благодаря тому, что КЛАДР используют более миллиона пользователей, представляя данные за десятки миллионов физических лиц в инспекции МНС (все предприятия, численностью 10 и более человек обязаны сдавать данные в налоговые органы на магнитных носителях в формализованном виде) накоплен богатый опыт его применения. Настало время провести доработку КЛАДР с целью его совершенствования.

В первую очередь это касается его структуры.

a) Структура классификационного кода

Из структуры классификационного кода адресных объектов необходимо исключить код актуальности наименования. Как уже отмечалось выше, он нарушает требования к реляционным структурам.

Таким образом, классификационный код любого адресного объекта, начиная от наименований регионов, заканчивая наименованиями улицам, должен представляться в следующем виде:

СС РРР ГГГ ППП УУУУ, где

СС – код субъекта Российской Федерации (региона);

РРР – код района;

ГГГ – код города;

ППП – код населенного пункта;

УУУУ – код улицы.

b) Состав полей

В настоящее время в состав полей КЛАДР кроме поля классификационного кода входят поля наименования адресного объекта, его вида (ул, пос, г, р-н и т.п.). Кроме этого имеются поля для указания почтового индекса, кода ОКАТО и номера налогового органа, соответствующих адресному объекту.

Практика показала, что кроме классификационного кода целесообразно ввести уникальный код адресного объекта. Это объясняется тем, что классификационный код адресного объекта может изменяться при его переподчинении. Уникальный же код должен быть постоянным для каждого конкретного адресного объекта (улицы, населенного пункта и т.д.). Поэтому везде, где говорится о кодовой адресации, имеется в виду применение именно уникальных кодов адресных объектов.

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

Код актуальности может быть задан либо просто признаком (актуален или неактуален), либо датой отмены предыдущего наименования.

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

Наиболее эффективным является способ формирования наименования с использованием главного слова, в приведенном случае – фамилии, которое должно стоять на первом месте.

Таким образом, в КЛАДР должно иметься два поля наименований: официальное и формализованное. А вот выделение вида объекта (ул и др.), как показала практика, нецелесообразно.

Учитывая вышеизложенное, можно определить следующие поля, которые обязательно должны присутствовать в КЛАДР:

• классификационный код адресного объекта;
• формализованное наименование адресного объекта;
• официальное наименование адресного объекта;
• код актуальности наименования;
• дополнительные поля для указания почтового индекса, кода ОКАТО, номера налогового органа и других необходимых данных, соответствующих адресному объекту.

c) Физическое представление

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

Возможно, ведение и распространение эталона КЛАДР (за исключением домов и более мелких элементов) целесообразно вести в одном файле. Причем файл может представляться как в dbf-структуре, так и в текстовом виде. При этом конкретная информационная система будет преобразовывать КЛАДР к нужному виду.

3.3. Организация ведения КЛАДР

В настоящее время КЛАДР ведется централизованно по данным, представляемым налоговыми органами регионов. При этом детализация данных определяется задачами этих органов. Например, если данные используются только для сортировки информации между налоговыми инспекциями, то в населенных пунктах, которые целиком обслуживаются одной инспекцией, наличие улиц для сортировки не требуется. В результате из 1139 городов для 21 в КЛАДР не содержатся улицы (из них – 10 административных центров районов) и из 162450 других населенных пунктов не содержат улиц 125812 (около 78%). Известно, что многие населенные пункты (в основном мелкие – деревни и т.п.) не содержат улиц, но процент, по-моему, должен быть ниже, т.к. в поселках (а их в КЛАДР около 22 тыс.) и селах (около 30 тыс.) улицы, как правило, имеются. Нет уверенности, и в том, что в КЛАДР включены все населенные пункты, особенно в районах, обслуживаемых одной налоговой инспекцией. Кроме этого, в КЛАДР включены элементы, являющиеся не адресными объектами, а объектами учета для целей налогообложения.

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

Наиболее целесообразно осуществлять централизованное ведение КЛАДР с глубиной классификации до улиц. В противном случае не удастся обеспечить единое кодовое представление информации в федеральных базах данных.

Более детальное ведение КЛАДР (до домов или даже с большей глубиной) с «привязкой» адресного пространства к ведомственным объектам должно производиться в регионах и городах. Исключением могут являться города, улицам которых соответствуют несколько почтовых отделений для автоматического определения почтовых индексов.

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

4. Создание Единой системы адресации Российской Федерации

Кроме выполнения задачи по централизованному ведению собственно КЛАДР, основными направлениями работ по созданию Единой системы адресации Российской Федерации должны являться:

• унификация и стандартизация системы обозначений структуры и элементов адресного пространства Российской Федерации;
• обеспечение применения Единой системы адресации в Государственных органах Российской Федерации и заинтересованных предприятиях и организациях.

Все эти направления работ могут осуществляться параллельно с момента принятия решения на создание Единой системы адресации Российской Федерации.

Рассмотрим каждое из этих направлений.

a) Унификация и стандартизация системы обозначений структуры и элементов адресного пространства Российской Федерации

Опыт разработки, ведения и использования ведомственного классификатора адресов ФНС России (КЛАДР) показал, что основными проблемами является отсутствие стандартов на представление элементов адресного пространства. Это касается как вопросов административно – территориального деления (характерным примером является г. Сочи), так и системы обозначения их элементов.

Административно – территориальное деление России складывалось под влиянием различных факторов, и его изменение только в целях унификации невозможно. Однако должны быть выработаны предложения, которые могут быть учтены в процессе создания новых административно – территориальных образований или при изменении, по каким – либо причинам, существующих.

Иное дело с обозначениями элементов адресного пространства в городах и населенных пунктах. В первую очередь это касается наименований улиц. В настоящее время происходит процесс укрупнения ряда городов, путем присоединения к ним населенных пунктов. При этом, как правило, не обращается внимания на появление в городе улиц с одинаковыми наименованиями. Введение правил, по которым следует действовать при слиянии населенных пунктов, не только возможно, но и необходимо.

В процессе работ по этому направлению необходимо стандартизировать способы представления адресов в различных документах. В частности выдвинуть требования к виду штампов регистрации места жительства в документах, удостоверяющих личность. Целесообразно рассмотреть возможность применения в ряде документов кодового обозначения адресов, независимого от изменения административно – территориального деления и переименования элементов адресного пространства.

b) Обеспечение применения Единой системы адресации в Государственных органах Российской Федерации и заинтересованных предприятиях и организациях

Применение Единой системы адресации потребует решения следующих задач:

• разработка методических рекомендаций по применению Единой системы адресации, включая XML-форматы представления адресной информации при взаимообмене;
• разработка программного инструментария (функций, объектов), обеспечивающего простое включение средств ввода и обработки адресной информации в существующие и разрабатываемые программные комплексы;
• обеспечение «привязки» объектов классификатора адресов к ОКАТО;
• разработка программных средств преобразования адресной информации, хранящейся в базах данных в неформализованном виде, к структурированному или кодовому представлению
• выполнение работ по преобразования адресной информации заинтересованных Государственных органов, а также предприятий и организаций (на договорной основе с организациями, занимающимися данным направлением работ).

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

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

Скачать последнюю версию КЛАДР

Документы и файлы

К оглавлению

Источник материала:

https://web.archive.org/web/20180609114639/http://%D0%BA%D0%BB%D0%B0%D0%B4%D1%80.%D1%80%D1%84/kladr.html