ГОСТ Р 70846.18-2024 Национальная система пространственных данных. Адресация. Концептуальная модель

ГОСТ Р 70846.18-2024

(ИСО 19160-1:2015)

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Национальная система пространственных данных

АДРЕСАЦИЯ

Концептуальная модель

National spatial data system. Addressing. Conceptual model

ОКС 35.240.70

Дата введения 2025-02-01

Предисловие

1 ПОДГОТОВЛЕН Публично-правовой компанией "Роскадастр" (ППК "Роскадастр") на основе официального перевода англоязычной версии указанного в пункте 4 стандарта, который выполнен Федеральным государственным бюджетным учреждением "Российский институт стандартизации"

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 394 "Географическая информация/ геоматика"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 28 декабря 2024 г. № 2074-ст

4 Настоящий стандарт является модифицированным по отношению к международному стандарту ИСО 19160-1:2015* "Адресация. Часть 1. Концептуальная модель" (ISO 19160-1:2015 "Addressing - Part 1: Conceptual model", MOD) путем внесения технических отклонений, объяснение которых приведено во введении к настоящему стандарту.

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).

Сведения о соответствии ссылочных национальных стандартов международным стандартам, использованным в качестве ссылочных в примененном международном стандарте, приведены в дополнительном приложении ДА

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

Введение

Адресация является одним из наиболее распространенных способов точного определения пространственного объекта с целью его идентификации и определения местоположения. В разных странах адреса различаются по структуре. Например, в Российской Федерации ссылка на дорожную сеть в адресе является типичной, в то время как в Японии и Южной Корее адрес (несмотря на то, что Южная Корея постепенно отходит от данного принципа) представляет собой иерархию административных территорий без ссылки на дорожную сеть. В отличие от системы координат адрес может рассматриваться в качестве упрощенной системы определения местоположения пространственного объекта. Адреса используются в различных целях: для навигации, доставки грузов и почтовой корреспонденции, налогообложения, управления землями, планирования, обслуживания коммунальными предприятиями и т.д.

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

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

В содержание настоящего стандарта внесены следующие изменения по отношению к ИСО 19160-1:2015 для приведения в соответствие с межгосударственными и национальными стандартами:

- в область применения добавлены сведения о возможности применения настоящего стандарта в сфере национальной системы пространственных данных;

- добавлены термины "пространственные объекты", "населенный пункт" и "город" с соответствующими определениями.

1 Область применения

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

Модель обеспечивает общее представление адресной информации, независимо от фактической реализации адресации. Модель не предназначена для замены концептуальных моделей, предложенных в других спецификациях, однако обеспечивает средства перекрестного преобразования между различными концептуальными моделями адресной информации, а также позволяет выполнить преобразование адресной информации между отличающимися спецификациями, используемыми в сфере национальной системы пространственных данных (НСПД) (см. [1]), например, в процессе функционирования федеральной государственной географической информационной системы "Единая цифровая платформа "Национальная система пространственных данных" (ФГИС ЕЦП НСПД) (см. [2], [3]).

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

Примечание - Данная концептуальная модель может быть использована для совершенствования спецификации адресных сведений, содержащихся во ФГИС ЕЦП НСПД, Федеральной государственной информационной системе Единого государственного реестра недвижимости, Государственной информационной системе "Единая электронная картографическая основа", Государственной информационной системе обеспечения градостроительной деятельности Российской Федерации, Государственном адресном реестре (Федеральная информационная адресная система) (см. [4], [5]) и иных информационных системах и ресурсах, обеспечивающих ведение адресной информации.

2 Соответствие

2.1 Общие положения

Настоящий стандарт определяет шесть классов требований и соответствий. В приложении A указано как должно проверяться соответствие этим классам в отношении рекомендаций по разработке профиля, соответствующего настоящему стандарту, см. приложение B.

2.2 Модель Core (базовая)

Любая адресная модель, в отношении которой объявлено базовое соответствие, должна удовлетворять всем требованиям, описанным в серии абстрактных тестов (см. A.2).

2.3 Модель Lifecycle (жизненный цикл)

Классы Address, AddressComponent или AddressableObject в адресной модели, для которой объявлено соответствие жизненному циклу, должны удовлетворять всем требованиям, описанным в серии абстрактных тестов (см. A.3).

2.4 Модель Provenance (источник)

Классы Address или AddressComponent в адресной модели, для которой объявлено соответствие источнику, должны удовлетворять всем требованиям, описанным в серии абстрактных тестов (см. A.4).

2.5 Модель Locale (региональная специфика)

Любой класс, AddressComponent или AddressComponentValue, в адресной модели, в отношении которой объявлено локальное соответствие, должны удовлетворять всем требованиям, описанным в серии абстрактных тестов (см. A.5).

2.6 Модель Full conformance (полное соответствие)

Любая адресная модель, в отношении которой объявлено полное соответствие, должна удовлетворять всем требованиям, описанным в серии абстрактных тестов в отношении классов соответствия Core, Lifecycle, Provenance и Locale.

2.7 Документация адресного профиля

Любая документация, в отношении которой объявлено соответствие, должна удовлетворять всем требованиям, описанным в серии абстрактных тестов (см. A.6).

Примечание - См. приложение C в отношении примеров адресных моделей, документально оформленных в соответствии с классом соответствия документации адресного профиля.

3 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ Р 7.0.64 (ИСО 8601:2004) Система стандартов по информации, библиотечному и издательскому делу. Представление дат и времени. Общие требования

ГОСТ Р 57668 (ИСО 19115-1:2014) Пространственные данные. Метаданные. Часть 1. Основные положения

ГОСТ Р 70846.2 Национальная система пространственных данных. Термины и определения

ГОСТ Р ИСО 15836-2-2022 Система стандартов по информации, библиотечному и издательскому делу. Набор элементов метаданных "Дублинское ядро". Часть 2. Свойства и классы DCMI

4 Термины и определения

В настоящем стандарте применены термины по ГОСТ Р 70846.2, а также следующие термины с соответствующими определениями:

4.1 адрес (address): Структурированная информация, которая позволяет точно определить объект с точки зрения его идентификации и местоположения.

Примеры

1 Адрес, где объект является зданием: Lombardy House, 809 Lombardy Street, The Hills, 0039, South Africa.

2 Адрес, где объект является участком земли под зданием: San 4-5, Munjae-ro, Songpa-gu, Seoul, 13144, South Korea.

3 Адрес, где объектом является группа зданий, таких как школа или большая площадь, занятая квартирами: 228-dong 404-ho, 26 Kyunghee-daero, Dongdaemun-gu, Seoul 130-701, South Korea.

Примечания

1 Объект является идентифицируемым в реальном мире, т.е. электронные и виртуальные адреса исключаются.

2 "Идентификация" относится к процессу, в котором структурированная информация в адресе точно определяет объект, т.e. помогает идентифицировать объект. Другими словами, "идентификация" в данном случае не относится к уникальным идентификаторам в базе данных или множестве данных.

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

4 Два адреса из двух различных классов адресов (т.е. имеющих разные наборы компонентов) для одного и того же адресуемого объекта являются двумя различными адресами (см. приложение E в отношении дополнительных примеров).

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

6 В дополнение к адресуемому объекту может быть большое количество людей, организаций, адресов или других объектов, связанных с адресом. Существует внешняя по отношению к адресу модель (см. приложения C и F в отношении примеров).

4.2 адресуемый объект (addressable object): Объект, которому может быть присвоен адрес.

4.3 адрес-псевдоним (address alias): Один из наборов адресов, точно определяющий один и тот же адресуемый объект.

4.4 класс адресов (address class): Описание набора адресов, которые совместно используют одни и те же компоненты адреса, операции, методы, отношения, а также семантику.

Примеры

1 "25 Blue Avenue Hatfield 0028" и "384 Green Street Motherville 2093" из одного класса адресов.

2 "PO Box 765 Goodwood 33948" и "PO Box 567 Grayville 98373" из одного класса адресов.

4.5 компонент адреса (address component): Составная часть адреса.

Примечания

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

2 Компонент адреса может иметь одно или несколько альтернативных значений, например альтернативы на разных языках или сокращения.

4.6 адресация (addressing): Мероприятия, связанные с адресами.

4.7 позиция адреса (address position): Положение, представляющее адрес.

Примечание - Адрес может быть представлен несколькими положениями, например различными входами в здание.

4.8 адресная типовая система (address reference system): Определяемый набор компонентов адреса, а также правила их комбинирования в адреса.

4.9 адрес-потомок (child address): Адрес, определяемый относительно родительского адреса.

4.10 адресуемый объект-потомок (child addressable object): Адресуемый объект, который адресуется относительно другого адресуемого объекта.

Примеры

1 Многоквартирное жилое здание.

2 В Японии gaiku (блок) с многочисленными jukyo bango (номерами для постоянного проживания) (см. [6]).

3 Комплекс из многих строений. В Корее группа строений со многими dong (крыльями или секциями строения).

4.11

4.12 региональная специфика (locale): Определение подмножества среды пользователя, которая зависит от языка и конвенций о культурных ценностях.

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

4.13 родительский адрес (parent address): Адрес родительского адресуемого объекта.

Примечание - Адреса адресуемых объектов-потомков в полной мере наследуют компоненты родительского адреса.

4.14 родительский адресуемый объект (parent addressable object): Адресуемый объект, который в полной мере содержит один или несколько других адресуемых объектов.

Примеры

1 Многоквартирное жилое здание.

2 В Японии, gaiku (блок) с многочисленными jukyo bango (номерами для постоянного проживания) (см. [6]).

3 Комплекс из многих строений. В Корее группа строений со многими dong (крыльями или секциями строения).

4.15 профиль (profile): Один или несколько базовых стандартов или подмножеств базовых стандартов, а также, где применимо, идентификация выбранных спецификаторов, классов, вариантов и параметров указанных базовых стандартов, которые необходимы для выполнения конкретной функции.

Примечание - См. [7], пункт 4.5.

4.16

Примечание - Информация об источнике включает:

- источник или происхождение записи;

- все изменения в записи;

- все организации или всех лиц, которые заботятся о сохранности записи с момента ее создания.

4.17

Примечание - Для термина "пространственный объект" в международной практике общепринятыми являются такие эквиваленты, как "phenomena", "feature", "spatial object", ""feature instance", "entity", применение которых определено контекстом.

4.18 населенный пункт (locality name): Часть территории, служащая постоянным или преимущественным местом проживания и жизнедеятельности людей, имеющая сосредоточенную застройку в пределах границы, установленной в соответствии с законодательством страны.

4.19 город (city): Населенный пункт, имеющий соответствующий статус с учетом численности населения, характера занятий его жителей, географического, экономического, исторического и культурного значения.

5 Сокращения

В настоящем стандарте применено следующее сокращение:

- UML - унифицированный язык моделирования (Unified Modeling Language).

6 Адресная модель

6.1 Общие положения

Адресная модель, описанная в настоящем стандарте, выступает в роли инструмента разработки специальных адресных моделей, таких как модель для описания почтовых адресов или модель для адресов, которая используется в конкретном городе или стране. На рисунках 1-3 представлен общий обзор адресной модели с повышающимся уровнем детализации.

Основа адресной модели использует концепцию, в которой адрес состоит из одного или нескольких компонентов адреса (см. рисунок 1).

Рисунок 1 - Схематическое изображение адресной модели, показывающее базовые элементы

Адрес представляет собой структурированную информацию, которая позволяет точно определять объект с целью идентификации местоположения. Значения компонентов адреса формируют составные части структурированной адресной информации. В простом примере ряд строчек адреса формирует адрес. В более сложном примере адрес включает более одного компонента адреса, такого как номер дома, название автомагистрали, название места и почтовый индекс. Кроме того, структурированная информация в адресе позволяет идентифицировать и определить местоположение объекта.

Примечание - Далее по тексту понятия "автомагистраль" и "элемент улично-дорожной сети" следует считать идентичными.

Значение компонента адреса является ярлыком, реже - ссылкой на другой объект (ReferenceObject). Например, название места может давать ссылку на объект, представляющий границу места, либо адрес может давать ссылку на объект с информацией об адресате, такой как имя клиента и информация о его покупках. Оставшиеся элементы в адресной модели позволяют связать адрес с объектом (AddressableObject), таким как здание, жилое помещение или земельный участок, а также с метаданными (AddressAlias, AddressedPeriod, AddressSpecifications) (см. рисунок 2).

Рисунок 2 - Схематическое изображение адресной модели, показывающее все элементы

Если более чем один адрес точно определяет один и тот же объект, то ссылка на адреса приводится как на адреса-псевдонимы. Типичным примером является здание на углу двух улиц с отдельным входом с каждой улицы и, соответственно, со своим адресом для каждого входа. Другой пример представляет собой обиходные вариации адреса или адресов на разных языках.

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

Если применимо и доступно, то метаданные о спецификации или документе, описывающем адресную типовую систему (т.е. правила для комбинирования компонентов адреса в адреса) и (или) адреса, представленные в модели, находятся в классе AddressSpecification.

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

Таким образом, адресуемый объект может иметь отношение типа родитель-потомок с другими адресуемыми объектами, например здание является родительским адресуемым объектом жилых помещений или офисов. Адрес может также иметь отношения типа "родитель-потомок" с другими адресами, например адрес здания может быть родительским адресом жилых помещений или офисов, расположенных внутри (см. рисунок 3).

Рисунок 3 - Обзор адресной модели в UML

6.2 Схемы

На рисунке 4 приведен общий вид адресной модели в UML.

Рисунок 4 - Адресная модель

На рисунке 5 показаны базовые типы, которые определены в адресной модели:

Рисунок 5 - Базовые типы в адресной модели

На рисунке 6 показаны базовые списки кодов, которые определены в адресной модели:

Рисунок 6 - Базовые списки кодов в адресной модели

Примечание - Существует большое количество возможных значений с небольшим известным наложением для списков кодов AddressableObjectType, AddressClass, AddressPositionType и ReferenceObjectType. В связи с этим списки кодов являются пустыми. Каждая адресная модель должна указывать коды при необходимости (см. приложение C в отношении возможных значений списков кодов стандартных профилей).

Примеры

1 building, house, landParcel, landmark, apartment и complexOfBuildings являются примерами кодов для списка кодов AddressableObjectType.

2 thoroughfareAddress, landmarkAddress и informalAddress являются примерами кодов для списка кодов AddressClass.

3 centroid, streetFront и approximated являются примерами кодов для списка кодов AddressPositionType.

4 street, administrativeArea, individual и organization являются примерами кодов для списка кодов ReferenceObjectType.

На рисунке 7 приведены типы и списки кодов в адресной модели, относящиеся к информации по жизненному циклу.

Рисунок 7 - Типы и списки кодов в адресной модели применительно к информации по жизненному циклу

На рисунке 8 приведен один тип в адресной модели, относящийся к информации по происхождению:

Рисунок 8 - Тип в адресной модели применительно к информации по происхождению

6.3 Классы

6.3.1 Общие положения

Определение классов и их атрибутов приведено в 6.3.2. Для каждого атрибута указывается имя, определение, обязательность или условие наличия значения, максимальная множественность, тип данных и множество возможных значений. Некоторые домены атрибутов указаны со ссылкой на элемент UML, такие как тип данных или список кодов.

6.3.2 Address (Адрес)

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

Пример - Адрес, такой как "99 Lombardy Street, The Hills, 0039" состоит из номера адреса (99), наименования транспортной магистрали (Lombardy Street), названия места (The Hills) и компонентов почтового кода (0039).

Атрибуты класса Address определены в таблице 1.

Таблица 1 - Атрибуты адреса

6.3.3 AddressComponent (Компонент адреса)

Класс AddressComponent является составной частью адреса. Непустое множество AddressComponents формирует адрес.

Пример - "The Hills" является составной частью "99 Lombardy Street, The Hills, 0039".

Атрибуты класса AddressComponent определены в таблице 2.

Таблица 2 - Атрибуты AddressComponent

6.3.4 AddressableObject (Адресуемый объект)

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

Примеры

1 Адрес, позволяющий точно определить место жительства лица: 99 Lombardy Street, The Hills, 0039, South Africa.

2 Адрес, позволяющий точно определить здание: Lombardy House, 809 Lombardy Street, The Hills, 0039, South Africa.

3 Адрес, позволяющий точно определить дверь (квартиру) в здании: Room 4-6, Lombardy House, 809 Lombardy Street, The Hills, 0039, South Africa.

Атрибуты класса AddressableObject определены в таблице 3.

Таблица 3 - Атрибуты AddressableObject

6.3.5 ReferenceObject (Объект ссылки)

Класс ReferenceObject является объектом, к которому может относиться значение компонента адреса.

Примеры

1 Лицо или организация может быть referenceObject для адресата.

2 Несколько ссылок на осевые линии улиц могут быть referenceObjects для названия улицы.

Атрибуты класса ReferenceObject определены в таблице 4.

Таблица 4 - Атрибуты ReferenceObject

6.3.6 AddressSpecification (Спецификация адреса)

Класс AddressSpecification является спецификацией адреса и его составных частей (компонентов).

Пример - [12] является спецификацией для адресов, используемых в Южной Африке.

Примечание - Информация в classSpecification может использоваться для проверки данных адреса и проверки качества.

Атрибуты класса AddressSpecification определены в таблице 5.

Таблица 5 - Атрибуты AddressSpecification

6.4 Типы

6.4.1 Общие положения

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

6.4.2 AddressClassSpecification (Спецификация класса адресов)

Тип AddressClassSpecification представляет информацию о классе адреса.

Атрибуты AddressClassSpecification определены в таблице 6.

Примечание - Атрибуты AddressClassSpecification могут использоваться для проверки данных адреса и проверки качества.

Таблица 6 - Атрибуты AddressClassSpecification

6.4.3 AddressPosition (Положение адреса)

Тип AddressPosition представляет информацию о репрезентативном положении адреса. Атрибуты AddressPosition определены в таблице 7.

Таблица 7 - Атрибуты AddressPosition

6.4.4 AddressComponentValue (Значения компонентов адреса)

Тип AddressComponentValue представляет информацию о значении компонента адреса. Атрибуты AddressComponentValue определены в таблице 8.

Таблица 8 - Атрибуты AddressComponentValue

6.4.5 AddressAlias (Адрес-псевдоним)

Тип AddressAlias представляет информацию об адресе-псевдониме. Атрибуты AddressAlias определены в таблице 9.

Таблица 9 - Атрибуты AddressAlias

6.4.6 AddressedPeriod (Период адресования)

Тип AddressedPeriod представляет период, в течение которого адрес был ассоциирован с адресуемым объектом. Атрибуты AddressedPeriod определены в таблице 10.

Таблица 10 - Атрибуты AddressedPeriod

6.4.7 Lifespan (Срок использования)

Тип Lifespan представляет информацию для описания срока использования адреса, компонента адреса или адресуемого объекта. Атрибуты Lifespan определены в таблице 11.

Таблица 11 - Атрибуты Lifespan

6.4.8 AddressProvenance (Источник адреса)

Тип AddressProvenance представляет информацию об источнике адреса, например источник происхождения записи, изменениях в записи, а также организации или частном лице, владевшем записью с момента ее создания. Атрибуты AddressProvenance определены в таблице 12. Классы, полученные на основе AddressProvenance могут иметь один или несколько атрибутов метаданных, указанных в ГОСТ Р 57668 и (или) ГОСТ Р ИСО 15836-2.

Таблица 12 - Атрибуты AddressProvenance

6.5 Списки кодов (Codelists)

6.5.1 Общие положения

В таблицах 13-18 представлены определения для отдельных значений списков кодов в адресной модели.

Примечание - Каждый профиль может указывать дополнительные значения списка кодов и/или включать только подмножество значений списка кодов.

6.5.2 AddressAliasType (Тип адреса-псевдонима)

Тип AddressAliasType описывает ассоциацию псевдонима между двумя адресами.

Значения, определенные в адресной модели для списка кодов AddressAliasType, определены в таблице 13.

Таблица 13 - Значения AddressAliasType

6.5.3 AddressComponentType (Тип компонента адреса)

Тип AddressComponentType содержит значения для представления широко распространенных типов компонентов адреса. Эти значения определены в таблице 14.

Таблица 14 - Значения AddressComponentType

6.5.4 AddressComponentValueType (Тип значения компонента адреса)

Тип AddressComponentValueType указывает тип значения компонента адреса. Значения, которые определены в адресной модели для списка кодов AddressComponentValueType, приведены в таблице 15.

Таблица 15 - Значения AddressComponentValueType

Примечание - Исправление орфографии в значении (имени) компонента адреса не представляет альтернативный адрес значения компонента.

Примеры

1 "Gordon Rd" является аббревиатурой "Gordon Road" (см. приложение E в отношении дополнительных примеров).

2 "Cologne" является языковой альтернативой "Koln" в Германии (см. приложение E в отношении дополнительных примеров).

3 "Jozi", "Joburg" или "Egoli" являются разговорными альтернативами "Johannesburg" в Южной Африке (см. приложение E в отношении дополнительных примеров).

6.5.5 AddressLifecycleStage (Этап жизненного цикла адреса)

Тип AddressLifecycleStage представляет различные этапы жизненного цикла Address или AddressComponent. Значения, определенные в списке кодов адресной модели AddressLifecycleStage, приведены в таблице 16.

Таблица 16 - Значения AddressLifecycleStage

6.5.6 AddressableObjectLifecycleStage (Этап жизненного цикла адресуемого объекта)

Тип AddressableObjectLifecycleStage представляет различные этапы жизненного цикла AddressableObject. Значения, определенные в адресной модели для списка кодов AddressableObjectLif ecycleStage, приведены в таблице 17.

Таблица 17 - Значения AddressableObjectLifecycleStage

6.5.7 AddressStatus (Статус адреса)

Тип AddressStatus содержит значения для указания статуса адреса. Значения, которые определены в адресной модели для списка кодов AddressStatus codelist, приведены в таблице 18.

Таблица 18 - Значения AddressStatus

6.5.8 AddressTypology (Типология адреса)

Тип AddressTypology содержит значения для указания типа класса адреса. Значения определены в адресной модели списков кодов AddressTypology codelist и приведены в таблице 19.

Таблица 19 - Значения AddressTypology

Примеры

1 Международная торговая корпорация имеет клиентов в 140 странах и обслуживает контактные адреса и адреса доставки для них в пользовательском файле. Вместо попыток понять отдельные классы, используемые каждой юрисдикцией, корпорация использует концепцию типологии с целью общего понимания структурирования адресов в пределах юрисдикции.

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

7 Требования

7.1 Класс требований - Core (базовый)

7.1.1 Зависимости

В таблице 20 показаны целевой тип и зависимости базового класса требований.

Таблица 20 - Зависимости требований класса Core

7.1.2 Требование первого класса Core. Классы

Адресная модель включает классы Address и AdressComponent, а также может включать один или несколько классов, полученных на их основе.

Пример - Примерами компонентов адреса являются названия улиц, названия мест, адресаты и почтовые индексы.

Адрес может включать классы AddressableObject, AddressSpecification, AddressAlias и Addressed- Period или классы, полученные на их основе.

Примеры

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

2 Полигон, представляющий административную территорию.

3 Полигон, представляющий площадь застройки или точку, представляющую здание.

4 Полигон, представляющий земельный участок.

5 Информация о лице или организации, являющейся почтовым получателем (компонент адреса).

Примечание - См. приложение F в качестве примера того, как внешние данные могут быть связаны с компонентом адреса посредством объекта ссылки.

7.1.3 Требование второго класса Core. Ассоциации

Адрес представляет один или несколько компонентов адреса. Компоненты адреса должны относиться к одному или нескольким адресам.

Адрес может позволить точно определить адресуемый объект. Адресуемый объект может быть точно определен с помощью адресов. Многочисленные адреса, которые дают возможность точно определить один и тот же адресуемый объект, являются адресами-псевдонимами.

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

Компонент адреса может находиться в рамках второго компонента адреса, например, когда значения компонента адреса назначаются по правилам, обеспечивающим, что они находятся четко в рамках второго компонента адреса.

Примеры

1 Название улицы однозначно определяет ее в пределах пригорода (но необязательно в пределах города).

2 Номер адреса однозначно определяет его в рамках улицы.

Компонент адреса может давать ссылку на объекты ссылки. На объект ссылки ссылка дается одним или несколькими компонентами адреса.

Примеры

1 Название автомагистрали (получено из AddressComponent) дает ссылку на осевую линию улицы.

2 Название автомагистрали (получено из AddressComponent) дает ссылку на сегменты осевой линии улицы.

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

Адресуемый объект-потомок должен иметь один родительский адресуемый объект. Родительский адресуемый объект может иметь несколько адресуемых объектов-потомков.

Примеры

1 Здание является родительским адресуемым объектом отдельной квартиры (адресуемые объекты-потомки) внутри здания.

2 В Японии gaiku (блок) является родительским адресуемым объектом отдельного jukyo bango (номера для проживания) (адресуемые объекты-потомки) внутри gaiku (блока) (см. [6]).

3 В Корее, группа зданий является родительским адресуемым объектом отдельного dong (здания) (адресуемые объекты-потомки).

Адрес-потомок должен иметь один родительский адрес. Родительский адрес может иметь адреса-потомки.

Примеры

1 Адрес здания является родительским адресом адресов отдельных квартир внутри здания.

2 В Японии адрес gaiku (блока) является родительским адресом отдельных адресов jukyo bango (номеров для проживания) в gaiku (блоке) [6].

3 В Корее адрес группы зданий является родительским адресом адреса отдельного dong (зданий) в этой группе.

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

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

Примеры

1 См. [12].

2 См. [15].

3 См. [16].

4 См. [17].

7.1.4 Требование третьего класса Core. Атрибуты

Классы в адресной модели должны включать обязательные (M), условные (C) и необязательные атрибуты (O), как указано в таблицах 1-12.

7.2 Класс требований - Lifecycle (жизненный цикл)

7.2.1 Зависимости

В таблице 21 показан целевой тип и зависимости класса требований жизненного цикла.

Таблица 21 - Зависимости класс требований Lifecycle (жизненный цикл)

7.2.2 Требование первого класса Lifecycle. Атрибуты жизненного цикла

Атрибуты lifecycleStage и lifeSpan (например, в классах Address, AddressComponent или AddressableObject) должны быть обязательными.

7.2.3 Требование второго класса Lifecycle. Уникальный идентификатор

Уникальный идентификатор (например, Address.id, AddressComponent.id и AddressableObject.id) должен быть обязательным.

7.2.4 Требование третьего класса Lifecycle. Приращение версии

Атрибут Version в атрибуте Lifespan (например, в классе Address, AddressComponent или AddressableObject) должен увеличиваться с каждым изменением объекта данных.

7.3 Класс требований - Provenance (источник)

7.3.1 Зависимости

В таблице 22 показан целевой тип и зависимости класса требований Provenance.

Таблица 22 - Зависимости класса требований Provenance

7.3.2 Требование первого класса Provenance. Атрибут источника

Атрибут происхождения (например, в классах Address, AddressComponent и AddressableObject) должен быть обязательным.

7.4 Класс требований - Locale (региональная специфика)

7.4.1 Зависимости

В таблице 23 показан целевой тип и зависимости класса требований Locale.

Таблица 23 - Зависимости класса требований Locale

7.4.2 Требование первого класса Locale. Атрибут Locale

Атрибут locale (например, в классе Address, AddressComponent и AddressComponentValue) должен быть обязательным.

7.5 Класс требований - Address profile documentation (документация профиля адреса)

7.5.1 Зависимости

В таблице 24 показан целевой тип и зависимости класса требований Address profile documentation.

Таблица 24 - Зависимости профиля класса требований Address profile documentation

7.5.2 Требования и рекомендации

Документация адресного профиля должна содержать следующее:

a) имя разработчика (наименование органа по стандартизации или уполномоченного) профиля и его контактные данные;

b) спецификацию, для которой разработан профиль. Это может быть цитирование спецификации, стандарта или правового акта или описание адресов, которые представлены в профиле;

c) наименования класса(ов) соответствия, которым соответствует профиль;

d) исходная информация о представленных в профиле адресах, такая как цель, с которой назначены адреса, или уполномоченное лицо, назначающее адреса;

e) для необязательных классов (AddressSpecification, AddressableObject, ReferenceObject, AddressAlias, AddressedPeriod) и необязательных ассоциаций в адресной модели явным образом указывают, являются ли они обязательными, необязательными, условными, вне диапазона или запрещенными в профиле. Ограничение по соответствующему классу должно использоваться для указания того, является ли необязательный атрибут обязательным, необязательным, условным, вне диапазона или запрещенным в профиле;

f) следующие элементы профиля моделируются по крайней мере в одной схеме:

1) каждый обязательный класс (Address, AddressComponent), условный класс и необязательный класс в профиле,

2) каждый специфичный для профиля класс, тип или список кодов, полученный на основе класса, типа или списка кодов в адресной модели,

3) каждая обязательная, необязательная, условная и специфичная в зависимости от профиля ассоциация в профиле,

4) каждый обязательный, необязательный, условный и специфичный в зависимости от профиля атрибут в профиле,

g) матрица для указания, какие компоненты адреса являются обязательными, условными или необязательными для каждого класса адресов, определенного в списке кодов AddressClass;

h) если тип Any в AddressComponentValue, то каждое значение в списке кодов AddressComponentType должно быть указано в профиле или в виде ограничений в специализированном классе AddressComponent, или в качестве таблицы, указывающей тип Any значения AddressComponentValue для каждого значения в AddressComponentType;

i) объяснение, где и как положение адреса и/или адресуемого объекта представлено в профиле;

j) схемы образцов данных (примеры) нескольких образцов адресов.

В документацию, если местная информация включена в профиль, также включают описания для указания какие классы в модели профиля включают локальную информацию.

В документацию включают двунаправленное преобразование между каждым атрибутом в профиле и спецификацией.

Схемы в документации должны быть подготовлены следующим образом:

- для различения между базовыми классами и классами, специфичными для профиля рекомендуется использовать прозрачный фон для (базовых) классов из адресной модели, и заполненный цветом фон для классов, специфичных для профиля;

- схемы должны использовать схожие шаблоны местоположения (т.е. AddressSpecification вверху слева, Address и AddressableObject под ним, AddressComponent и ReferenceObject справа) с тем, которые использованы для адресной модели на рисунках 1-4.

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

Примечание - Образцы профилей, соответствующих этим требованиям и рекомендациям, включены в приложение C.

Приложение А

(обязательное)

Серии абстрактных тестов

A.1 Общие положения

Серия абстрактных тестов для классов соответствия представлена в A.2 - A.5.

A.2 Класс соответствия - Core (базовый)

Таблицы A.1-A.3 содержат подробности тестов класса соответствия Core.

Таблица A.1 - Тест 1 Core. Классы

Таблица A.2 - Тест 2 Core. Ассоциации

Таблица A.3 - Тест 3 Core. Атрибуты

A.3 Класс соответствия - Lifecycle (жизненный цикл)

Таблицы A.4-A.6 содержат подробности тестов класса соответствия Lifecycle.

Таблица A.4 - Тест 1 Lifecycle. Атрибуты Lifecycle

Таблица A.5 - Тест 2 Lifecycle. Уникальный идентификатор

Таблица A.6 - Тест 3 Lifecycle. Добавления от новой версии

A.4 Класс соответствия - Provenance (источник)

Таблица A.7 содержит подробности теста на класс соответствия Provenance.

Таблица A.7 - Тест 1 Provenance. Атрибуты источника

A.5 Класс соответствия - Locale (региональная специфика)

Таблица A.8 содержит подробности теста на класс соответствия Locale.

Таблица A.8 - Тест Locale 1. Атрибут Locale

A.6 Класс соответствия - Address profile documentation (профиль документации адреса)

Таблица A.9 содержит подробности теста на класс соответствия Address profile documentation.

Таблица A.9 - Тест Address

Приложение B

(справочное)

Рекомендации по разработке профиля

В.1 Общие положения

B.2 и B.3 приведены в качестве рекомендации для разработчиков профилей. Шаги по разработке профиля настоящего стандарта описаны в B.2. В B.3 приведены шаги по разработке UML для профиля модели адреса

.

________________

Профили могут публиковаться на вебсайте ISO http://standards.iso.org/iso/19160/-1/.

В.2 Шаги по разработке профиля

a) Определяют какому классу соответствия должен соответствовать профиль:

- все профили должны соответствовать базовому классу соответствия,

- кроме того, классы в профиле могут соответствовать одному или нескольким дополнительным классам соответствия (Lifecycle, Provenance и Locale);

b) идентифицируют классы, которые необходимо включить:

- все обязательные классы (Address, AddressComponent) должны быть включены в профиль,

- по каждому необязательному классу (AddressSpecification, AddressableObject, ReferenceObject, AddressAlias, AddressedPeriod), решают, остается ли класс необязательным в профиле, или он является одним из следующих (путем указания ограничений) обязательным условным вне диапазона или запрещенным,

- при необходимости, добавляют или выводят классы, специфичные для профиля. В профиле, совместимом с языком географической разметки (GML), подклассы должны иметь стереотип featureType, атрибуты и ограничения должны копировать в эти подклассы;

c) идентифицируют ассоциации, которые необходимо включить:

- все обязательные ассоциации должны быть включены в профиль,

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

- при необходимости, добавляют ассоциации, специфичные для профиля;

d) указывают значения списков кодов:

- значения списков кодов могут быть указаны в AddressClass,

- значения списка кодов могут быть указаны для AddressableObjectType, AddressPositionType и ReferenceObjectType. Эти значения указывают только в том случае, если соответствующие атрибуты включены в модель,

- при необходимости добавляют значения, специфичные для профиля, к любому из других списков кодов, т.е. AddressComponentType, AddressComponentValueType, AddressStatus, AddressAliasType, AddressLifecycleStage и AddressableObjectLifecycleStage. Значения, специфичные для профиля, должны добавляться, если определение значений существующего списка кодов не соответствует требованиям профиля;

e) идентифицируют атрибуты, которые нужно включить:

- все обязательные атрибуты должны включаться в профиль,

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

- при необходимости, добавляют атрибуты, специфичные для профиля,

- указывают, каким является тип Any для каждого в списке кодов AddressComponentType в качестве таблицы, или в качестве ограничения в специальных классах AddressComponent,

- если применимо, описывают, каким образом каждый атрибут в профиле преобразуется в соответствующий стандарт/спецификацию и обратно;

f) если в профиле указаны значения списка кодов AddressClass, то указывают классы адреса профиля:

- должна быть включена матрица для указания действительных компонентов адреса для каждого класса адреса, который определен в списке кодов AddressClass;

g) создают данные по образцам (примеры) для ряда адресов с целью верификации профиля;

h) подготавливают документацию в соответствии с классом соответствия Address profile documentation (см. 2.7).

В.3 Шаги по разработке модели UML

a) Разработку модели UML начинают с копирования ISO/TC 211 Гармонизированной модели (UML)

;

________________

Информация о модели имеется на странице Группы обслуживания гармонизированной модели (HMMG) на вебсайте www.isotc211.org.

b) создают новый пакет для профиля;

c) добавляют клавиши быстрого доступа к классам текущего стандарта, необходимым для профиля к пакету (например, перетащив их в пакет в Enterprise Architect);

d) создают специализации классов адресной модели настоящего стандарта, если необходимо для профиля;

e) для каждого специального класса:

- добавляют дополнительные атрибуты и ассоциации к другим классам, если требуется для профиля,

- определяют ограничения для идентификации элементов, не применимых в профиле,

- определяют ограничения для описания любых специальных случаев в профилях элемента, где имеется отклонение от элемента настоящего стандарта;

f) создают схемы адресной модели, типов, списков кодов и любых других специализаций в профиле в соответствии с классом соответствия Address profile documentation (см. 2.6).

В.4 Шаги по загрузке профиля на вебсайт ISO

a) Посылают документацию по профилю (PDF) и модель UML (например, файлы XMI) в Секретариат ISO/TC 211;

b) группа Проекта ИСО 19160 проанализирует профиль, а полностью несоответствующие профили будут возвращены и опубликованы не будут. Соответствие тестирования классу соответствия Address profile documentation является обязанностью разработчика профиля и не будет выполняться группой проекта;

c) секретариат ISO/TC 211 создает папку в режиме онлайн для профиля на сайте http://standards.iso.org/iso/19160/-1/, загружает соответствующие файлы в папку, и обновляет readme.txt;

d) секретариат ISO/TC 211 Secretariat уведомляет подавшего о том, что профиль был загружен.

Приложение C

(справочное)

Стандартные профили

C.1 Общие положения

Два стандартных профиля включены в C.2 и C.3. Они иллюстрируют, что из себя представляет профиль, и как он должен быть документально оформлен. Если профили готовы к использованию и соответствуют базовому классу соответствия настоящего стандарта, данные, подготовленные согласно этим профилям не обязательно соответствуют настоящему стандарту (соответствие данных не указано). В C.4 ряд схем из других профилей включен в качестве дополнительных примеров профилей.

C.2 Пример 1. Минимальный адресный профиль

C.2.1 Разработчик профиля

Наименование: Группа проекта ISO 19160-1.

Контактная информация: Секретариат ISO/TC 211, см. www.isotc211.org в отношении контактной информации.

C.2.2 Спецификация

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

C.2.3 Соответствие

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

C.2.4 Модель профиля

Рисунок C.1 - Минимальный адресный профиль. Адресная модель

Address и AddressComponent являются единственными классами в минимальной адресной модели, и ассоциация между этими двумя классами является единственной ассоциацией в модели. Все другие классы и ассоциации в адресной модели находятся вне диапазона в этом профиле (см. рисунок C.1).

Списки кодов и типы для минимальной адресной модели проиллюстрированы на рисунке C.2. AddressComponent имеет два атрибута: type и valuelnformation, все другие атрибуты находятся вне сферы применения. Атрибут value является единственным атрибутом в AddressComponentValue, включенным в эту минимальную адресную модель, все другие атрибуты - вне диапазона.

Единственным действительным компонентом этого адресного класса является addressLine. Значения компонента addressLine являются типом CharacterString.

Таким образом, адрес в минимальной адресной модели состоит из одного или нескольких компонентов addressLine, каждый из которых имеет значение CharacterString. См. также схемы образцов в C.2.5 (рисунки C.3-C.10).

Рисунок C.2 - Минимальный адресный профиль. Списки кодов и типы

Таблица C.1 - Минимальный адресный профиль. Тип Any для значений AddressComponentType

Таблица C.2 - Минимальный адресный профиль. Матрица действительных компонентов для значений AddressClass

C.2.5 Данные по образцам

На рисунках C.3-C.10 представлены схемы образцов адресов в минимальных адресных профилях.

Рисунок C.3 - Минимальный адресный профиль. Образец 1. Адрес улицы в Северной Африке

Рисунок C.4 - Минимальный адресный профиль. Образец 2. Адрес заметного объекта на местности в США

Рисунок C.5 - Минимальный адресный профиль. Образец 3. Адрес в Великобритании

Рисунок C.6 - Минимальный адресный профиль. Образец 4. Адрес в Малайзии

Рисунок C.7 - Минимальный адресный профиль. Образец 5. Адрес в Японии (см. [6])

Рисунок C.8 - Минимальный адресный профиль. Образец 6. Адрес в Испании

Рисунок C.9 - Минимальный адресный профиль. Образец 7. Адрес в Корее

Рисунок C.10 - Минимальный адресный профиль. Образец 8. Адрес в Корее для группы зданий

C.3 Пример 2. Образец адресного профиля

C.3.1 Разработчик профиля

Наименование: Группа проекта ISO 19160-1.

Контактная информация: Секретариат ISO/TC 211, см. контакты на вебсайте www.isotc211.org.

C.3.2 Спецификация адреса

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

Адрес с указанием улицы и номера дома состоит из номера адреса, наименования автомагистрали, наименования места, почтового индекса и, опционально, названия страны, например "99 Lombardy Street, The Hills, 0039, South Africa". Применяются следующие правила:

- номер адреса представляет целое число в диапазоне 1-10000;

- наименование страны является необязательным, однако все другие части адреса являются обязательными.

Адреса с указанием улицы и номера дома назначаются жилым постройкам, коммерческим зданиям или участкам земли. Местные власти отвечают за присваивание адресов с указанием улицы и номера дома, которые используются в основном для оказания услуг, однако широкие слои населения также используют адреса для ориентирования. Каждый местный орган управления ведет реестр каждого здания в его юрисдикции; каждое здание имеет уникальный идентификатор в реестре. Каждый участок имеет уникальный национальный идентификатор, записанный в национальной кадастровой информационной системе.

Адрес почтового ящика состоит из номера почтового ящика, наименования почтового отделения, почтового индекса и, опционально, наименования страны, например "PO Box 345, Orlando, 2020, South Africa". Применяются следующие правила:

- номер почтового ящика представляет целое число в интервале 1-100000;

- номер почтового ящика находится в пределах наименования почтового отделения;

- наименования почтовых отделений находятся в пределах страны;

- указание наименования страны не является обязательным, однако все другие части адреса являются обязательными.

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

C.3.3 Соответствие

Указанный типовой адрес соответствует классу соответствия Core.

C.3.4 Модель профиля

Местоположение представлено только в адресуемых объектах. На рисунке C.11 показана адресная модель для образца адресного профиля, на рисунках C.12 и C.13 показаны соответственно кодовые списки этого профиля. Значения типов для различных AddressComponentTypes приведены в таблице C.3. Таблица C.4 перечисляет допустимые типы компонентов классов адресов. Таблицы C.5-C.7 иллюстрируют соответствие классов адресов, типов компонентов адресов и типов адресуемых объектов данного профиля и конкретных примеров адресов.

Рисунок C.11 - Профиль образца адреса. Адресная модель

Таблица C.3 - Типовой адресный профиль. Тип Any для различных значений AddressComponentType

Таблица C.4 - Пример адресного профиля. Допустимые типы компонентов для различных значений AddressClass

Рисунок C.12 - Пример адресного профиля. Типы

Рисунок C.13 - Типовой адресный профиль. Списки кодов

Таблица C.5 - Соответствие списка кодов AddressClass

Таблица C.6 - Соответствие списка кодов AddressComponentType

Таблица C.7 - Соответствие списка кодов AddressableObjectType

C.3.5 Преобразование из типового адреса в типовой адресный профиль

В таблицах C.8-C.10 представлено, как атрибуты классов Address, AddressComponent и AddressableObject преобразуются из типового адреса в профиль.

Таблица C.8 - Атрибуты адреса. Из типового адреса в профиль

Таблица C.9 - Атрибуты AddressComponent: из типового адреса в профиль

Типовой адрес		Атрибут профиля	Описание преобразования
Нет эквивалента	Нет	type	См. таблицу C.7 в отношении преобразования между наименованиями компонентов в профиле типового адреса и значениями списка кодов AddressComponentType
Нет эквивалента	Нет	valueInformation. value	В таблице C.3 представлены применимые типы данных для значения различных типов компонентов адреса. В случае наименования автомагистрали она дробится на составные части, каждая из которых преобразуется в соответствующий атрибут ThroughfareNameValue.
			Примеры 1 "Church Street" в типовом адресе преобразуется в "Church" в valueInformation.value.name и в в valueInfromation.value.type. 2 "Park Avenue West" в типовом адресе преобразуется в "Park" в valueInformation.value.name и в "Avenue" в valueInfromation.value.type и "West" в valueInformation.value.suffix.
Нет эквивалента	Нет	value.type	Нет

Таблица C.10 - Атрибуты AddressableObject: из типового адреса в профиль

C.3.6 Преобразование из профиля типового адреса в типовые адреса

Таблицы C.11-C.13 демонстрируют, как атрибуты классов Address, AddressComponent и AddressableObject преобразуются из профиля в типовой адрес.

Таблица C.11 - Атрибуты адреса. От профиля к типовому адресу

Таблица C.12 - Атрибуты AddressComponent; от профиля к типовому адресу

Таблица C.13 - Атрибуты AddressableObject: от профиля к типовому адресу

C.3.7 Варианты типовых адресов

На рисунках C.14 и C.15 показаны варианты типовых адресов, соответствующих образцу адресного профиля.

Рисунок C.14 - Образец адресного профиля. Вариант 1. Адрес по улице

Рисунок C.15 - Образец адресного профиля. Вариант 2. Адрес почтового ящика

На рисунках C.16 и C.17 показаны варианты типовых адресов и адресуемых объектов, соответствующих образцу адресного профиля.

Рисунок C.16 - Образец адресного профиля. Вариант 3. Адрес со ссылкой на нежилое (коммерческое) строение

Рисунок C.17 - Профиль типового адреса. Образец 4. Адрес дает ссылку на почтовый ящик

C.3.8 Типовые адреса, связывающие с внешними данными

Рисунок C.18 иллюстрирует, как внешние данные могут быть связаны с типовыми адресами. LA_SpatialUnit определяется см. [9], в то время как классы Employee и BusinessRegister являются вымышленными.

Рисунок C.18 - Связывание типовых адресов с внешними данными

C.4 Схемы из других профилей

Рисунок C.19 иллюстрирует, как классы адресов могут определяться за счет их моделирования в качестве специализаций класса адресов. Если используется этот метод, то атрибут класса в специализации адреса должен быть обязательным, и ограничение должно указывать значение AddressClass в каждой специализации. Этот метод требует агрегирования адресных специализаций из специализированных классов AddressComponent, приведенных на рисунке C.20. Если используется этот метод, то матрица, как описано в требованиях к Address profile documentation в 7.5.2 и проиллюстрировано в таблице C.4, отражает ассоциации между специализациями классов Address и AddressComponent в модели.

Рисунок C.19 - Специализации класса Address

Рисунок C.20, заимствованный из профиля юрисдикции, показывает, как DeliveryService (служба доставки), специализация класса Address, агрегирована из ряда специализаций класса AddressComponent. Значение атрибута типа в каждой специализации AddressComponent указано в качестве ограничений и значений (например, deliveryServiceName, deliveryServiceNumber и т.п.), взятых из специализации профиля списка кодов AddressComponentType (не показано). Тип атрибута значения также указывается в виде ограничения для каждой специализации AddressComponent, а типы (например, Characterstring, Number и т.п.) приведены в [13].

Рисунок C.20 - Адрес DeliveryService, агрегированный из специализаций AddressComponent

Схема на рисунке C.21 иллюстрирует, как сложные типы AddressComponentValue.value могут моделироваться. В юрисдикции, в которой создается схема, многие типы компонентов в ThoroughfareAddress AddressClass имеют подкомпоненты. Например, Road имеет обязательное имя и необязательное обозначение, префикс, суффикс и компоненты типа. Этот атрибут моделируется как класс <<type>>, RoadValue, имеющий эти атрибуты, который цитируется по ограничениям значения в классе специализации Road.

Рисунок C.21 - Сложный тип RoadValue для AddressComponentValue.value

Рисунок C.22 дает еще примеры, как сложные типы AddressComponentValue.value могут моделироваться. В юрисдикции, создающей схему, многие типы компонентов в ThoroughfareAddress и AddressClass имеют подкомпоненты. Например, RoadNumber (номер дороги) имеет обязательный численный атрибут, необязательные буквенно-численные атрибуты и необязательные большие и малые числа. Эти атрибуты моделируются, как класс <<type>>, RoadNumberValue, цитируемый по ограничению значения в классе RoadNumber.

Рисунок C.22 - Более сложные типы AddressComponentValue.value

Рисунок C.23 демонстрирует, как положение AddressableObject может быть представлено общим положением, а также одним или несколькими положениями, зависимыми от предметной области. Схема из профиля настоящего стандарта, которая определяет сервис позиционирования для аварийного реагирования и коммунальных служб. Общее положение представлено атрибутом положения в классе AddressableObject. Положения, зависящие от предметной области, представлены атрибутами положения в классах UtilityRegister и EmergencyAccessRegister. Последний имеет ассоциацию "один-ко-многим" с AddressableObject. Список кодов AddressPositionType специализируется на определении точек общего доступа, таких как buildingCentroid, и точек доступа в зависимости от предметной области, таких как serviceConnectionPoint (например, счетчик газа). Ограничение на AddressableObject ограничивает допустимые типы положений по отношению к общим типам, т.е. к buildingAccessPoint, buildingCentroid и propertyCentroid. Ограничения на UtilityRegister и EmergencyAccessRegister ограничивают допустимые типы положения к типам в зависимости от предметной области, т.е. serviceConnectionPoint и emergencyAccess соответственно.

Рисунок C.23 - Общее положение и положение, зависящее от предметной области

Приложение D

(справочное)

Примеры жизненного цикла и срока эксплуатации адреса, компонента адреса и адресуемого объекта

D.1 Общие положения

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

- муниципальные власти могут предложить адреса объектов собственности, которая еще не построена;

- новый жилец может захотеть, чтобы существующее здание получило новое имя;

- муниципальные власти могут изменить название улицы;

- почтовый оператор может изменить почтовый индекс, чтобы отражать новые схемы доставки;

- ошибка в записи компонента адреса или атрибута должна быть исправлена.

Адресная модель различает следующие четыре набора временных атрибутов:

a) набор, связанный с периодом, в течение которого представление адреса, адресного компонента или адресуемого объекта существует в наборе данных. Этот набор представлен атрибутами beginLifespan, endLifespan и version в типе Lifespan;

b) набор, связанный с периодом, в течение которого адрес, адресный компонент или адресуемый объект действительно существуют в реальном мире. Этот набор представлен атрибутами validFrom и validTo в типе Lifespan;

c) набор, отражающий различные стадии, через которые проходит адрес, адресный компонент или адресуемый объект в своем жизненном цикле. Этот набор представлен атрибутом lifecycleStage;

d) набор, отражающий период, в течение которого адрес связан с адресуемым объектом. Этот набор представлен классом ассоциации AddressedPeriod.

Содержание настоящего приложения иллюстрирует, каким образом использовать атрибуты, и как поддерживать целостность между ними. Каждая строка в таблице настоящего приложения представляет образец в наборе данных. Использование полужирного шрифта и курсива указывает на вставки и обновляет образец соответственно. Для дат validFrom и beginLifespan предполагается, что временная отметка равна 00:00:00. Для дат validTo и endLifespan предполагается, что временная отметка составляет 23:59:59.

В настоящем приложении учтены положения [16] (приложение C).

D.2 Жизненный цикл компонента адреса "автомагистраль"

Событие A (см. таблицу D.1):

2007-02-01: Администратор адресации предлагает автомагистраль с названием "West Street".

2007-02-03: Название автомагистрали записывается в наборе данных.

Таблица D.1 - Атрибуты AddressComponent после события A

Событие B (см.таблицу D.2):

2007-07-01: Название автомагистрали утверждено.

2007-07-11: Теперь это отражено в наборе данных.

Таблица D.2 - Атрибуты AddressComponent после события B

Примечание - В различных сценариях отметка времени для решения, которое вступит в силу, будет после отметки для ее записи в наборе данных.

Событие C (см. таблицу D.3):

2009-02-13: Администратор адресации решает изменить название автомагистрали на "Centre Street".

Новое название вступает в силу 2009-03-01.

2009-02-15: Решение записывается путем обновления набора данных.

Таблица D.3 - Атрибуты AddressComponent после события C

Событие D (см. таблицу D.4):

2010-04-20: Администратор адресации решает изменить написание улицы с "Centre Street" на "Center Street". Новое название улицы начнет действовать с 2010-05-01.

2010-04-25: Решение записано путем обновления набора данных.

Таблица D.4 - Атрибуты AddressComponent после события D

Событие E (см. таблицу D.5):

2011-01-17: Администратор адресации утверждает проект строительства, который приведет к тому, что существующее название "Center Street" будет заменено с 2011 по 02-01. С этой даты название будет историческим.

2011-01-18: Решение записано путем обновления набора данных.

Таблица D.5 - Атрибуты AddressComponent после события E

D.3 Жизненный цикл адреса

Событие A (см. таблицу D.6):

2012-06-01: Администратор адресации предлагает новый адрес для предполагаемого подразделения объекта собственности в "Mill Road". Предложение опубликовано для обсуждения.

2012-06-03: Предложение записано в наборе данных.

Таблица D.6 - Атрибуты Address после события A

Событие B (см. таблицу D.7):

2012-09-10: Власти утверждают новый адрес, однако решено использовать "114-1 Mill Road" для адреса. Адрес станет официальным с 2012-10-01.

2012-09-12: Решение записано путем обновления набора данных.

Таблица D.7 - Атрибуты Address после события B

Событие C (см. таблицу D.8):

2013-01-10: Объект собственности объединен с соседним объектом и решено, что адрес становится недействительным с этой даты.

2013-01-15: Решение записано путем обновления набора данных.

Таблица D.8 - Атрибуты Address после события C

D.4 Жизненный цикл адресуемого объекта

Событие A (см. таблицу D.9):

2012-06-01: власти предлагают строительство нового офисного здания, которое будет называться "Green Acres". Предложение опубликовано для консультаций.

2012-06-03: Решение записано путем обновления набора данных.

Таблица D.9 - Атрибуты адресуемого объекта после события A

Событие B (см. таблицу D.10):

2012-09-10: Власти утверждают строительство здания.

2012-09-12: Решение записано путем обновления набора данных.

Таблица D.10 - Атрибуты адресуемого объекта после события B

Событие C (см. таблицу D.11):

2013-01-10: Власти утверждают решение о сносе здания 2013-02-10.

2013-01-15: Решение записано путем обновления набора данных.

Таблица D.11 - Атрибуты адресуемого объекта после события C

D.5 Период ассоциации между адресом и адресуемым объектом

Событие A (см. таблицу D.12):

2000-06-01: Власти утверждают "44B Bakery Road" в качестве адреса здания "The Milk House" с идентификатором объекта 7762.

Таблица D.12 - AddressedPeriod после события A

Событие B (см. таблицу D.13):

2012-09-10: Власти утверждают снос "The Milk House", поэтому новое здание будет возведено на его месте.

Таблица D.13 - AddressedPeriod после события B

Событие C (см.таблицу D.14):

2013-01-10: власти утверждают "44B Bakery Road" в качестве адреса нового здания "The Computer Shop" с идентификатором объекта 8632.

Таблица D.14 - AddressedPeriod после события C

Приложение E

(справочное)

Примеры альтернативных компонентов адреса и адресов-псевдонимов

Е.1 Общие положения

В E.2 и E.3 приведены примеры альтернативы значения компонентов адреса и адреса-псевдонимы соответственно.

Е.2 Альтернативы значения компонентов адреса

Таблицы E.1-E.3 иллюстрируют значения атрибутов AddressComponentValue на различных примерах значений альтернативных компонентов.

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

Таблица E.1 - Сокращенная альтернатива названия автомагистрали

Пример в таблице E.2 показывает атрибуты компонента адреса и его разговорную альтернативу. В этом примере разговорная альтернатива имеет более низкое предпочтение.

Таблица E.2 - Разговорный вариант названия местности

В таблице E.3 показан пример атрибутов компонента адреса и его языковой альтернативы. В этом примере значения компонента на английском языке (EN) и на африкаанс (AF) имеют одинаковый (наивысший) уровень предпочтения; альтернатива на немецком имеет меньший уровень предпочтения.

Таблица E.3 - Местные альтернативы наименования автомагистрали

Е.3 Адреса-псевдонимы

Таблицы E.4-E.6 иллюстрируют значения соответствующих атрибутов в классах Address, AddressComponent и AddressAlias для различных наборов псевдонимов. В таблице E.4 приведены примеры двух адресов, ссылающихся на одинаковое свойство на углу улицы. Один из адресов имеет более высокий уровень предпочтения.

Таблица E.4 - Адреса-псевдонимы на углу улицы (unspecifiedAlias)

В таблице E.5 приведены примеры двух адресов, принадлежащих различным классам адресов, дающих ссылку на один и тот же объект собственности. Они имеют одинаковый уровень предпочтения.

Таблица E.5 - Адреса-псевдонимы из различных классов (classAlias)

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

Таблица E.6 - Адреса-псевдонимы на различных языках (localeAlias)

Приложение F

(справочное)

Примеры внешних классов

F.1 Общие положения

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

F.2 Ассоциации между адресами и внешними данными

На рисунке F.1 показано, как внешние данные, такие как информация о работниках, бизнесе и клиентах, могут ассоциироваться с одним, или несколькими адресами.

Рисунок F.1 - Ассоциирование внешних данных с помощью адресов

F.3 Внешние классы полученные на основе ReferenceObject

На рисунках F.2 и F.3 показано, как внешние данные могут ассоциироваться с компонентом адреса в профиле адресной модели.

На рисунке F.2 ReferenceSpatialObject получено на основе ReferenceObject, которое ассоциируется с AddressComponent. Внешние классы LA_SpatialUnit и LA_SpatialUnitGroup (которые определены в [9]), ассоциируются с ReferenceSpatialObject.

На рисунке F.3 ReferenceSpatialObject, а также внешние классы Organization и Person получаются на основе ReferenceObject, который ассоциируется с AddressComponent. Внешние классы AdministrativeArea и Thoroughfare являются специализациями ReferenceSpatialObject. Рисунок F.3 также иллюстрирует, что эти специализации могут ассоциироваться друг с другом.

Рисунок F.2 - Ассоциирование классов внешнего управления землями через ReferenceSpatialObject с помощью AddressComponent

Рисунок F.3 - Получение внешних классов на основе ReferenceObject и ReferenceSpatialObject

Приложение ДА

(справочное)

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

Таблица ДА.1

Библиография