ISO 19110:2016

NORME ISO
INTERNATIONALE 19110
Deuxième édition
2016-12-01
Information géographique —
Méthodologie de catalogage des entités
Geographic information — Methodology for feature cataloguing
Numéro de référence
©
ISO 2016
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2016, Publié en Suisse
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni utilisée
sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie, l’affichage sur
l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à l’ISO à
l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2016 – Tous droits réservés

Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Conformité . 3
4.1 Classes de conformité . 3
5 Abréviations . 4
6 Exigences . 4
6.1 Généralités . 4
6.2 Exigences conceptuelles . 4
6.3 Exigences relatives à l’implémentation XML .12
6.4 Exigences relatives au document d’instances XML .13
Annexe A (normative) Suite de tests abstraits .16
Annexe B (normative) Schéma conceptuel et dictionnaire de données du catalogue d’entités .24
Annexe C (normative) Description du codage .44
Annexe D (normative) Gestion des registres de catalogues d’entités .47
Annexe E (informative) Exemples de catalogage des entités .56
Annexe F (informative) Concepts de catalogage des entités .68
Annexe G (informative) Transformation des catalogues d’entités historiques .71
Bibliographie .73
Avant-propos
L’ISO (Organisation internationale de normalisation) est une fédération mondiale d’organismes
nationaux de normalisation (comités membres de l’ISO). L’élaboration des Normes internationales est
en général confiée aux comités techniques de l’ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l’ISO participent également aux travaux.
L’ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d’approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www.
iso.org/directives).
L’attention est appelée sur le fait que certains des éléments du présent document peuvent faire l’objet de
droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l’élaboration du document sont indiqués dans l’Introduction et/ou dans la liste des déclarations de
brevets reçues par l’ISO (voir www.iso.org/brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la signification des termes et expressions spécifiques de l’ISO liés à l’évaluation
de la conformité, ou pour toute information au sujet de l’adhésion de l’ISO aux principes de l’Organisation
mondiale du commerce (OMC) concernant les obstacles techniques au commerce (OTC), voir le lien
suivant: www.iso.org/iso/fr/avant-propos.html
Le comité chargé de l’élaboration du présent document est l’ISO/TC 211, Information
géographique/Géomatique.
Cette deuxième édition annule et remplace la première édition (ISO 19110:2005), qui a fait l’objet d’une
révision technique. Elle incorpore également l’Amendement ISO 19110:2005/Amd1:2011. L’Annexe G
explique comment mettre les catalogues d’entités de la première édition en conformité avec cette
version révisée.
iv © ISO 2016 – Tous droits réservés

Introduction
Les entités géographiques sont des phénomènes du monde réel associés à une position sur la Terre,
au sujet desquels des données sont recueillies, tenues à jour et diffusées. Les catalogues d’entités qui
définissent les types d’entités, leurs opérations, leurs attributs et leurs associations représentés sous
forme de données géographiques sont indispensables pour transformer les données en informations
exploitables. Ces catalogues d’entités favorisent la diffusion, le partage et l’utilisation des données
géographiques en facilitant la compréhension du contenu et de la signification des données. À moins
que les fournisseurs et les utilisateurs de données géographiques ne partagent la même compréhension
des types de phénomènes du monde réel représentés par les données, les utilisateurs ne pourront pas
juger si les données fournies conviennent à leurs besoins.
La disponibilité de catalogues d’entités normalisés pouvant être utilisés à de multiples reprises réduira
les coûts d’acquisition des données et simplifiera le processus de spécification de produit pour les jeux
de données géographiques.
Le présent document fournit un cadre normalisé d’organisation et de présentation de la classification des
phénomènes du monde réel dans un jeu de données géographiques. Tout jeu de données géographiques
constitue une abstraction grandement simplifiée et réduite d’un monde complexe et divers. Un catalogue
de types d’entités ne peut jamais saisir la richesse de la réalité géographique. Il convient toutefois qu’il
présente l’abstraction particulière représentée dans un jeu déterminé de données d’une façon claire et
précise, et sous une forme facilement compréhensible et accessible aux utilisateurs des données.
Il existe deux niveaux d’entités géographiques: les instances et les types. Au niveau de l’instance, une
entité géographique est représentée comme un phénomène discret qui est associé à des coordonnées
géographiques et temporelles, et peut être caractérisé par un symbole graphique particulier. Ces
instances d’entités individuelles sont regroupées en classes de caractéristiques communes: les types
d’entités. Il est reconnu que l’information géographique est perçue de manière subjective et que son
contenu dépend des besoins particuliers des applications. Les besoins particuliers des applications
déterminent la manière dont les instances d’entités sont regroupées en types d’entités à l’intérieur d’un
système de classification particulier. L’ISO 19109 spécifie comment les données doivent être organisées
afin de refléter les besoins particuliers des applications présentant des exigences similaires en matière
de données.
NOTE La description complète du contenu et de la structure d’un jeu de données géographiques est donnée
par le schéma d’application élaboré conformément à l’ISO 19109. Le catalogue d’entités définit la signification
des types d’entités et des attributs, opérations et associations d’entités associés contenus dans le schéma
d’application.
Le présent document permet la description multilingue de schémas d’application conformes à
l’ISO 19109. Il fournit en outre un mécanisme qui permet une description globale unique de propriétés
apparaissant de nombreuses fois dans un schéma d’application et la liaison de ces propriétés globales
aux types d’entités correspondants.
Les critères de collecte utilisés pour identifier les phénomènes individuels du monde réel et les
représenter sous forme d’instances d’entités dans un jeu de données ne sont pas spécifiés dans le
présent document. Comme ces critères de collecte ne sont pas inclus dans les normes, il convient de les
inclure séparément dans la spécification de produit de chaque jeu de données.
L’organisation normalisée des informations d’un catalogue d’entités n’aboutira pas automatiquement à
une harmonisation des applications ou à leur interopérabilité. Dans les situations où les classifications
des entités sont différentes, le présent document peut au moins servir à clarifier ces différences et, de
cette façon, aider à éviter les erreurs qui résulteraient de leur non-prise en compte. Il peut également
être utilisé comme cadre normalisé d’harmonisation des catalogues d’entités existants dont les
domaines se chevauchent.
La présente révision de l’ISO 19110 traite de questions associées à la gestion multilingue des catalogues
d’entités et applique les modifications décrites dans un précédent amendement. Outre l’élimination
d’incohérences mineures dans les schémas conceptuels, cet amendement a permis d’améliorer le
mécanisme de gestion des propriétés globales. Il a également apporté une implémentation par
schémas XML pour le schéma conceptuel des catalogues d’entités et une gestion des registres de
catalogues d’entités. Si le schéma conceptuel initial ne constitue pas un sous-ensemble du schéma
conceptuel amendé, il est possible de transformer des instances historiques.
vi © ISO 2016 – Tous droits réservés

NORME INTERNATIONALE ISO 19110:2016(F)
Information géographique — Méthodologie de catalogage
des entités
1 Domaine d’application
Le présent document définit la méthodologie de catalogage des types d’entités. Il spécifie comment les
types d’entités peuvent être organisés dans un catalogue d’entités et présentés aux utilisateurs d’un
jeu de données géographiques. Le présent document s’applique à la création de catalogues de types
d’entités dans des domaines jusqu’ici non catalogués et à la révision des catalogues d’entités existants
pour les rendre conformes aux pratiques normalisées. Il s’applique au catalogage des types d’entités
qui sont représentés sous forme numérique. Ses principes peuvent être élargis au catalogage d’autres
formes de données géographiques. Les catalogues d’entités sont indépendants des dictionnaires de
concepts d’entités définis dans l’ISO 19126 et il est possible de les spécifier sans utiliser ni créer de
dictionnaire de concepts d’entités.
Le présent document s’applique à la définition d’entités géographiques au niveau du type d’entité. Il ne
s’applique pas à la représentation des instances individuelles de chaque type. Il exclut les schémas de
présentation tels que spécifiés dans l’ISO 19117.
Le présent document peut être utilisé comme base pour la définition de l’univers du discours modélisé
dans une application particulière ou pour normaliser les aspects généraux d’entités du monde réel
modélisés dans plusieurs applications.
2 Références normatives
Les documents suivants cités dans le texte constituent, pour tout ou partie de leur contenu, des
exigences du présent document. Pour les références datées, seule l’édition citée s’applique. Pour les
références non datées, la dernière édition du document de référence s’applique (y compris les éventuels
amendements).
ISO 19103, Information géographique — Langage de schéma conceptuel
ISO 19109, Information géographique — Règles de schéma d’application
ISO 19115-1:2014, Information géographique — Métadonnées — Partie 1: Principes de base
ISO/TS 19115-3:2016, Information géographique — Métadonnées — Partie 3: Mise en oeuvre par des
schémas XML
ISO 19135-1:2015, Information géographique — Procédures pour l’enregistrement d’éléments — Partie 1:
Principes de base
ISO/TS 19139:2007, Information géographique — Métadonnées — Implémentation de schémas XML
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— IEC Electropedia: disponible à l’adresse http://www.electropedia.org/.
— ISO Online browsing platform: disponible à l’adresse http://www.iso.org/obp.
3.1
désignation
désignateur
représentation d’un concept par un signe qui le dénomme
Note 1 à l’article: Dans le travail terminologique, on distingue trois types de désignation: les symboles, les
appellations et les termes.
[SOURCE: ISO 1087-1:2000, 3.4.1]
3.2
entité
abstraction d’un phénomène du monde réel
EXEMPLE Le phénomène nommé «Tour Eiffel» peut être classé avec d’autres phénomènes similaires dans un
type d’entité «tour».
Note 1 à l’article: Une entité peut se présenter sous forme d’un type ou d’une instance. Il convient de n’utiliser le
type d’entité ou l’instance d’entité que lorsque l’un d’eux seulement est désigné.
[SOURCE: ISO 19101-1:2014, 4.1.11]
3.3
association d’entités
relation qui relie des instances d’un type d’entité (3.2) à des instances du même type d’entité ou d’un
type d’entité différent
3.4
attribut d’entité
caractéristique d’une entité (3.2)
EXEMPLE 1 Un attribut d’entité nommé couleur» peut avoir une valeur d’attribut «vert» qui appartient au
type de données «texte».
EXEMPLE 2 Un attribut d’entité nommé «longueur» peut avoir une valeur d’attribut «82,4» qui appartient au
type de données «réel».
Note 1 à l’article: Un attribut d’entité comporte un nom, un type de données et un domaine de valeurs associés
à celui-ci. Un attribut d’entité pour une instance d’entité possède également une valeur d’attribut émanant du
domaine de valeur.
[SOURCE: ISO 19101-1:2014, 4.1.12]
3.5
catalogue d’entités
catalogue contenant des définitions et descriptions de types d’entités (3.2), d’attributs d’entités (3.4) et
de relations d’entités présents dans un ou plusieurs jeux de données géographiques, ainsi que toute
opération sur entité (3.7) pouvant être appliquée à ces entités
Note 1 à l’article: Les relations entre entités comprennent les héritages d’entités (3.6) et les associations
d’entités (3.3).
[SOURCE: ISO 19101-1:2014, 4.1.13]
3.6
héritage d’entité
mécanisme par le biais duquel des entités (3.2) spécifiques incorporent la structure et le comportement
d’entités plus générales liées par leur comportement
2 © ISO 2016 – Tous droits réservés

3.7
opération sur entité
opération que chaque instance d’un type d’entité (3.2) peut exécuter
EXEMPLE Une opération sur entité sur un «barrage» consiste, par exemple, à rehausser ce barrage. Les
résultats de cette opération sont d’augmenter la hauteur du «barrage» et le niveau de l’eau dans un «réservoir».
Note 1 à l’article: Il arrive que les opérations sur entité fournissent une base pour la définition du type d’entité.
3.8
langage fonctionnel
langage dans lequel les opérations sur entité (3.7) sont spécifiées de façon formelle
Note 1 à l’article: Dans un langage fonctionnel, les types d’entités peuvent être représentés sous forme de types
de données abstraites.
3.9
signature
chaîne de texte qui spécifie le nom et les paramètres requis pour invoquer une opération
Note 1 à l’article: Elle peut comporter des paramètres optionnels de retour. Cette signature découle habituellement
de la définition formelle. C’est l’équivalent de la signature UML.
4 Conformité
4.1 Classes de conformité
La méthodologie permettant de cataloguer les types d’entités est définie à travers un ensemble
d’exigences pour décrire les types d’entités. Une classe de conformité unique est définie pour les
modèles satisfaisant à l’ensemble des exigences conceptuelles. Le présent document présente un modèle
conceptuel pour la représentation de descriptions de type d’entité sous forme d’un jeu de schémas UML
qui satisfait cette classe de conformité. L’Annexe A présente les suites de tests abstraites des classes de
conformité.
Un second ensemble d’exigences pour l’implémentation XML du modèle conceptuel forme la base d’une
classe de conformité pour l’implémentation XML du modèle UML pour représenter les types d’entités
dans un catalogue d’entités. Cette implémentation repose sur les règles définies dans l’ISO/TS 19139 et
l’ISO/TS 19115-3.
L’Annexe D définit un modèle conceptuel pour un catalogue d’entités enregistré, mais le présent
document ne spécifie aucune implémentation XML correspondante.
Tableau 1 — Classes de conformité définies par la présente spécification
Nom de la classe de conformité
a
Classe de conformité URI Cible de normalisation
(article mis en œuvre)
/conf/conceptual-model Modèle conceptuel Modèle conceptuel d’un catalogue
d’entités
/conf/feature-catalogue-xml Implémentation XML Implémentation XML d’un modèle
conceptuel de catalogue d’entités
/conf/feature-catalogue-xml-instance Document d’instance XML Document d’instance XML valide pour
l’échange de contenus d’un catalogue
d’entités
a
Toutes les classes de conformité URI sont des URI de HTTP préfixés «http://standards.iso.org/iso/19110» aux chemins
dans la cellule du tableau pour obtenir l’URI complet.
5 Abréviations
GFC Geographic Feature Cataloguing (catalogage des entités géographiques)
GFM General Feature Model (modèle d’entité général)
HTTP Hyper Text Transfer Protocol (Protocole de transfert hypertexte)
OHI Organisation Hydrographique Internationale
TS Technical Specification (Spécification technique)
UML Unified Modeling Language (langage de modélisation unifié)
URI Uniform Resource Identifier (identificateur de ressource uniforme)
XML eXtensible Markup Language (langage de balisage extensible)
6 Exigences
6.1 Généralités
L’Article 6 spécifie les exigences générales et particulières relatives aux éléments d’information des
catalogues d’entités.
6.2 Exigences conceptuelles
Les Tableaux 2 à 10, 12 et 13 récapitulent les exigences relatives au modèle conceptuel permettant de
décrire les types d’entités et leurs attributs, opérations, et associations dans un catalogue d’entités.
Les exigences sont groupées par classes d’exigences; chaque classe d’exigences est dotée d’un URI, et
chaque exigence possède un URI basé sur l’URI de la classe d’exigences dans laquelle elle est incluse.
La colonne des dépendances fournit l’URI de toute classe d’exigences qui doit être satisfaite, condition
préalable à la classe d’exigences.
Dans les Tableaux 2 à 10 et 12 à 13, les conventions suivantes sont observées:
— le terme «entité» renvoie aux éléments du modèle qui représentent des objets d’informations
instanciables dans le modèle conceptuel. Selon le paradigme de modélisation utilisé, ces objets
peuvent avoir d’autres libellés, par exemple «objet», «classe», «élément» ou «entité»;
— l’inclusion du nom d’une entité modélisée dans un énoncé d’exigences implique que l’entité ou l’un
des sous-types soit dérivé(e) de cette entité dans une instance du modèle;
— le nom des propriétés est donné entre guillemets (« »), et est toujours en minuscules.
4 © ISO 2016 – Tous droits réservés

Tableau 2 — Classe d’exigences pour le catalogue
Identificateur http://standards.iso.org/iso/19110/1.1/req/catalogue
Type de cible Modèle conceptuel.
Nom Exigences fondamentales du catalogue conceptuel pour le catalogue d’entités de l’ISO 19110.
Dépendance ISO 19115-1:2014, 6.6.2
ISO/TS 19139:2007, 7.4.4
Exigence /req/catalogue/representation
Un catalogue d’entités doit documenter une abstraction de la réalité représentée par une
ou plusieurs entités géographiques.
NOTE   Un catalogue d’entités peut se conformer aux spécifications du présent document
indépendamment de tout jeu de données géographiques existant.
Exigence /req/catalogue/abstraction
Le type d’entité doit être le niveau d’abstraction de base dans un catalogue d’entités.
Exigence /req/catalogue/electronic-form
Un catalogue d’entités doit être disponible au format électronique.
Exigence /req/catalogue/inheritance
Un catalogue d’entités doit hériter de toutes les propriétés et relations définies sur la classe
abstraite CT_Catalogue dans l’ISO/TS 19139:2007, 7.4.4.
Exigence /req/catalogue/identification
Le catalogue d’entités doit inclure les informations d’identification qui comprennent un
«nom», un «numéro de version» et une «date de version».
Exigence /req/catalogue/producer
L’entité du catalogue d’entités doit comprendre une propriété obligatoire «producer» avec
une valeur exacte qui représente une entité conforme au contenu de l’entité CI_Responsi-
bility définie par l’ISO 19115-1:2014, 6.6.2.
Exigence /req/catalogue/functional-language
Si un langage fonctionnel est utilisé pour définir de manière formelle les opérations sur
entité, l’entité du catalogue d’entités doit être assortie d’une propriété «functional language»
(langage fonctionnel) dont la valeur de texte spécifie le langage utilisé.
Exigence /req/catalogue/identifier
Si un identificateur globalement unique est inclus dans une propriété d’un catalogue d’enti-
tés, il doit être désigné «identifier» avec une valeur qui est une entité conforme au contenu
de l’entité MD_Identifier défini par l’ISO 19115-1:2014, 6.6.2.
Recommandation /rec/catalogue/schema-language
Pour optimiser l’utilité d’un catalogue d’entités dans différentes applications, il est recom-
mandé d’utiliser un langage de schéma conceptuel pour modéliser les informations du
catalogue d’entités.
NOTE   Les définitions en langage naturel, les alias de type d’entité, les critères de créa-
tion et de retrait des instances d’entités et les autres éléments sémantiques du catalogue
d’entités peuvent être inclus dans un schéma conceptuel sous forme de commentaires
structurés ou d’attributs.
Tableau 3 — Classe d’exigences pour le contenu basique
Identificateur http://standards.iso.org/iso/19110/1.1/req/base-content
Type de cible Modèle conceptuel.
Nom Exigences fondamentales du contenu conceptuel basique pour le catalogue d’entités de
l’ISO 19110.
Dépendance http://standards.iso.org/iso/19110/req/catalogue
Exigence /req/base-content/minimum
Un catalogue d’entités doit au moins décrire un type d’entité.
Exigence /req/base-content/feature-type-names
Un type d’entité doit être identifié par exactement un «nom de type» qui est unique dans
le périmètre du catalogue d’entités qui le comporte.
La valeur «type name» doit consister en une propriété facultative «codespace» (espace de
code) qui spécifie un espace de nommage et une valeur de chaîne qui fournit le nom.
Exigence /req/base-content/feature-type-is-abstract
Un type d’entité doit avoir une propriété obligatoire «is abstract» (est abstraite) avec une
valeur booléenne.
Exigence /req/base-content/feature-properties
Les propriétés d’un type d’entité doivent être liées au type d’entité avec le rôle «carrierO-
fCharacteristics».
Les propriétés d’un type d’entité doivent être catégorisées comme un attribut d’entité, une
opération sur entité ou un rôle d’association.
Exigence /req/base-content/property-type-names
Tous les types de propriétés (attributs, opération ou rôle d’association) doivent être identifiés
par un nom de type «type name» unique dans le périmètre du type d’entité (propriétés locales)
ou du catalogue d’entités (propriétés globales) qui contient la définition de la propriété.
La valeur «type name» doit consister en une propriété facultative «codespace» (espace de
code) qui spécifie un espace de nommage et une valeur de chaîne qui fournit le nom.
Exigence /req/base-content/all-type-definitions
Le catalogue d’entités doit inclure les définitions de tous les types d’entités et types de
propriétés (attribut, opération ou rôle d’association) inclus dans le modèle.
Exigence /req/base-content/constraints
Si le modèle applique des contraintes au type d’entité ou aux entités du type de propriété,
celles-ci doivent être représentées par une entité de contraintes qui a une propriété de
description avec une valeur de chaîne. Le type d’entité ou l’entité du type de propriété doit
être liée à l’entité de contraintes via un rôle «constrainedBy».
Recommandation /rec/base-content/multiple-definition
Si le même terme est défini à la fois dans une source de définition référencée et dans un
élément du catalogue d’entités (type d’entité, propriété, association ou valeur listée), il
convient que la définition du catalogue d’entités prévale.
Recommandation /rec/base-content/only-elements
Pour assurer la prédictibilité et la comparabilité du contenu du catalogue d’entités, il est
recommandé que le modèle ne comporte que les éléments spécifiés dans le modèle concep-
tuel UML inclus dans le présent document (voir Annexe B).
Recommandation /rec/base-content/functional-language
Il est recommandé d’utiliser les spécifications d’un langage fonctionnel pour faciliter la
définition des types d’entités.
6 © ISO 2016 – Tous droits réservés

Tableau 3 (suite)
Recommandation /rec/base-content/abstract-property-type
Il convient d’implémenter la spécification des propriétés d’entité par le biais d’une classe
de type de propriété abstraite dont sont dérivés les types d’attribut, d’opération et de rôle
d’association.
Recommandation /rec/base-content/property-closure
Il convient qu’un catalogue d’entités comprenne, pour chaque type d’entité, les spécifica-
tions des propriétés liées au type d’entité, ainsi que les spécifications des opérations qui
affectent les propriétés d’entité définies dans le catalogue.
Informative Chaque attribut d’entité, valeur listée, association d’entités et type d’entité peut avoir une
propriété «code» qui a une valeur alphanumérique en guise d’identificateur.
Tableau 4 — Classe d’exigences pour l’attribut
Identificateur http://standards.iso.org/iso/19110/1.1/req/attribute
Type de cible Modèle conceptuel.
Nom Exigences fondamentales de l’attribut conceptuel pour le catalogue d’entités de l’ISO 19110.
Dépendance http://standards.iso.org/iso/19110/req/base-content
Exigence /req/attribute/inheritance
L’entité d’attribut d’entité doit hériter de toutes les propriétés et associations de l’entité
type de propriété.
Exigence Un attribut d’entité doit avoir une propriété nommée «valueType» à l’aide d’une valeur sous
forme de chaîne référençant une donnée ou un type d’objet. Le type de valeur «valueType»
doit être spécifié soit directement dans la définition de l’attribut, soit indirectement dans
une liaison (voir /req/global, ci-dessous).
Exigence /req/attribute/attribute-cardinality
Un attribut d’entité doit avoir une propriété de cardinalité qui spécifie la limite inférieure
et supérieure du nombre d’instances du type de valeur cible pouvant se produire dans une
instance de données valide. La valeur par défaut est 1.
Exigence /req/attribute/measurement-unit
Si une entité d’attribut d’entité a une propriété qui spécifie les unités de mesure associées
à une valeur d’attribut, elle doit être nommée «valueMeasurementUnit» et avoir une valeur
sous forme de chaîne qui identifie une unité de mesure.
Exigence /req/attribute/code
Si une entité d’attribut d’entité a une propriété fournissant un identificateur supplémentaire
pour l’attribut, il doit être nommé «code».
Tableau 5 — Classe d’exigences pour l’association
Identificateur http://standards.iso.org/iso/19110/1.1/req/association
Type de cible Modèle conceptuel.
Nom Exigences fondamentales de l’association conceptuelle pour le catalogue d’entités de
l’ISO 19110.
Dépendance http://standards.iso.org/iso/19110/req/base-content
Exigence /req/association/inheritance
L’entité d’association d’entités doit hériter de toutes les propriétés et associations de l’entité
de type d’entité.
Exigence /req/association/association-participation
Une association d’entités doit comporter au moins deux instances de rôle d’association liées
par le rôle «roleName».
Exigence /req/association/role-cardinality
L’entité de rôle d’association doit avoir une propriété de cardinalité qui spécifie la limite infé-
rieure et supérieure du nombre d’instances du type d’entité cible pouvant se produire dans
une instance de données valide. La valeur par défaut est «0.*».
Exigence /req/association/association-role-inheritance
L’entité de rôle d’association doit hériter de toutes les propriétés et associations de l’entité de
type de propriété.
Exigence /req/association/role-relation
Une entité de rôle d’association doit être liée à exactement une entité d’association d’entités
par un rôle «relation».
Exigence /req/association/role-player
Une entité de rôle d’association doit être liée à au moins un type d’entité par le rôle «role-
Player».
NOTE   Cette liaison peut directement provenir du rôle d’association, auquel cas la cardina-
lité est 1, ou être indirectement fournie par une liaison et un rôle d’association lié, auquel cas
plusieurs types d’entités peuvent être liés au rôle d’association.
Exigence /req/association/role-type
Une entité de rôle d’association doit avoir une propriété «type» avec une valeur spécifiée par
l’énumération des termes suivants {ordinary, aggregation, composition} (ordinaire, agréga-
tion, composition).
Exigence /req/association/role-is-ordered
Une entité de rôle d’association doit avoir une propriété «isOrdered» dont la valeur booléenne
indique si les instances de ce rôle d’association au sein de l’instance d’entité qui le contient
sont ordonnées ou non, avec FALSE = «non ordonné» et TRUE = «ordonné».
Exigence /req/association/role-is-navigable
Une entité de rôle d’association doit avoir une propriété «isNavigable» dont la valeur
booléenne indique si ce rôle est navigable de l’entité source à l’entité cible de l’association.
TRUE = «navigable».
8 © ISO 2016 – Tous droits réservés

Tableau 6 — Classe d’exigences pour l’héritage
Identificateur http://standards.iso.org/iso/19110/1.1/req/inheritance
Type de cible Modèle conceptuel.
Nom Exigences fondamentales de l’héritage conceptuel pour le catalogue d’entités de l’ISO 19110.
Dépendance http://standards.iso.org/iso/19110/req/base-content
Exigence /req/inheritance/class
Les relations d’héritage dans un catalogue d’entités doivent être représentées à l’aide d’une
classe de relation d’héritage qui associe un type d’entité dans le rôle «subtype» à un type
d’entité différent dans le rôle «supertype».
Exigence /req/inheritance/description
Une relation d’héritage doit avoir une propriété «description».
Exigence /req/inheritance/unique-instance
Une relation d’héritage doit avoir une propriété «uniqueInstance» qui est une valeur boo-
léenne, (TRUE) si une instance du «supertype» peut être une instance d’au plus un de ses
types d’entité «subtype».
Tableau 7 — Classe d’exigences pour les propriétés globales
Identificateur http://standards.iso.org/iso/19110/1.1/req/global
Type de cible Modèle conceptuel.
Nom Exigences fondamentales des propriétés globales conceptuelles pour le catalogue d’entités
de l’ISO 19110.
Dépendance http://standards.iso.org/iso/19110/req/base-content
Exigence /req/global/global-property
Un type de propriété globale doit être associé à un catalogue d’entités via le rôle «feature-
Catalogue» et ne doit être associé à aucun type d’entité via un rôle «featureType».
Exigence /req/global/binding
Une liaison doit associer exactement un type de propriété dans un rôle «globalProperty»
à exactement un type d’entité dans soit un rôle «featureType», soit un rôle «rolePlayer»,
mais jamais dans les deux rôles à la fois.
Exigence /req/global/binding-description
Si une liaison a une propriété qui sert à décrire l’instance de liaison, elle doit être nommée
«description» et avoir une valeur de chaîne.
Exigence /req/global/global-xor-local
Un type de propriété qui remplit un rôle «globalProperty» dans une liaison ne doit pas être
aussi associé à un rôle «carrierOfCharacteristics» dans un type d’entité et doit être associé
à un catalogue d’entités via le rôle «featureCatalogue».
Exigence /req/global/bound-association-role
Si le modèle autorise une association «rolePlayer» entre un rôle d’association dans un rôle
«globalProperty» et un FeatureType, cette liaison doit alors passer par une entité du rôle
d’association lié qui hérite de toutes les propriétés et association de l’entité de liaison.
Identificateur http://standards.iso.org/iso/19110/1.1/req/global
Type de cible Modèle conceptuel.
Nom Exigences fondamentales des propriétés globales conceptuelles pour le catalogue d’entités
de l’ISO 19110.
Tableau 7 (suite)
Dépendance http://standards.iso.org/iso/19110/req/base-content
Exigence /req/global/bound-feature-attribute
Un attribut d’entité qui remplit un rôle «globalProperty» doit spécifier un type de valeur
«valueType» pour l’attribut en l’absence de «valueType» valide spécifié dans la définition
de l’attribut d’entité.
Une liaison entre un attribut d’entité et un type d’entité qui spécifie un type de valeur
«valueType» doit passer par une entité de l’attribut d’entité lié qui hérite de toutes les
propriétés et associations de l’entité de liaison.
Exigence /req/global/binding-constraints
Si le modèle comprend des contraintes sur les entités de liaison, celles-ci doivent être repré-
sentées par une entité Contraintes qui a une propriété de description avec une valeur de
chaîne. L’entité de liaison doit être liée à l’entité Contraintes via un rôle «constrainedBy».
Tableau 8 — Classe d’exigences pour l’opération
Identificateur http://standards.iso.org/iso/19110/1.1/req/operation
Type de cible Modèle conceptuel.
Nom Exigences fondamentales de l’opération conceptuelle pour le catalogue d’entités de l’ISO 19110.
Dépendance http://standards.iso.org/iso/19110/req/base-content
Exigence /req/operation/inheritance
La classe opération sur entité doit hériter de toutes les propriétés et associations de la
classe type de propriété.
Exigence /req/operation/affected-features
Si l’opération sur entité est contenue dans un type d’entité, ceci doit être spécifié via le rôle
«featureType» (type d’entité).
NOTE   Des opérations sur entité peuvent être définies sous forme d’une classe autonome
pour les opérations qui affectent les valeurs de propriété d’autres entités, mais qui ne sont
pas considérées comme faisant partie d’un type d’entité.
Exigence /req/operation/operation-attributes
Seuls les attributs d’entité doivent être associés aux opérations sur entité via les rôles
d’association «observesValueOf», «affectsValuesOf», ou «triggeredByValuesOf».
Exigence /req/operation/signature
Chaque entité d’opération sur entité doit avoir exactement une propriété «signature» qui
est unique dans le périmètre du catalogue d’entités.
NOTE   La signature spécifie le nom de l’opération et le nom des paramètres requis utilisés
pour décrire l’opération.
Exigence /req/operation/operation-cardinality
Une entité d’opération sur entité doit avoir une propriété de cardinalité qui spécifie le
nombre de valeurs de retour possible. La valeur par défaut est 1.
Identificateur http://standards.iso.org/iso/19110/1.1/req/operation
Type de cible Modèle conceptuel.
Nom Exigences fondamentales de l’opération conceptuelle pour le catalogue d’entités de l’ISO 19110.
10 © ISO 2016 – Tous droits réservés

Tableau 8 (suite)
Dépendance http://standards.iso.org/iso/19110/req/base-content
Exigence /req/operation/formal-definition
Si une opération est formellement spécifiée à l’aide d’un langage fonctionnel, le texte de
cette spécification doit être fourni dans une propriété d’entité d’opération sur entité nom-
mée «formalDefinition».
Exigence /req/operation/functional-language
Si une entité d’opération sur entité comprend une propriété «formalDefinition», l’entité du
catalogue d’entités qui la comprend doit alors avoir une propriété «functional language».
NOTE   Le but est que les définitions formelles utilisent le langage fonctionnel spécifié
pour le catalogue, mais ceci ne peut se vérifier qu’avec les instances du catalogue d’entités.
Tableau 9 — Classe d’exigences pour la liste de valeurs
Identificateur http://standards.iso.org/iso/19110/1.1/req/value-list
Type de cible Modèle conceptuel.
Nom Exigences fondamentales de la liste de valeurs conceptuelle pour le catalogue d’entités de
l’ISO 19110.
Dépendance http://standards.iso.org/iso/19110/req/base-content
Exigence /req/value-list/class
Si le domaine d’un attribut d’entité est une énumération ou du vocabulaire contrôlé, comme
indiqué par la propriété «valueType», cette liste doit être spécifiée à l’aide d’une entité de
valeurs listées qui remplit le rôle «listed value» sur l’attribut d’entité.
Exigence /req/value-list/label
Chaque instance de valeur listée doit avoir exactement une valeur de propriété textuelle
«label».
Exigence /req/value-list/definition
Si une entité de valeur listée a une propriété fournissant une définition de la valeur, elle
doit être nommée «definition».
Exigence /req/value-list/code
Si une entité de valeur listée a une propriété fournissant un identificateur supplémentaire
d’une valeur, il doit être nommé «code».
Tableau 10 — Classe d’exigences pour le modèle conceptuel
Identificateur http://standards.iso.org/iso/19110/1.1/req/conceptual-model
Type de cible Modèle conceptuel.
Nom Modèle conceptuel pour le catalogue d’entités de l’ISO 19110.
Dépendance http://standards.iso.org/iso/19110/req/catalogue
http://standards.iso.org/iso/19110/req/base-content
http://standards.iso.org/iso/19110/req/attributes
http://standards.iso.org/iso/19110/req/association
http://standards.iso.org/iso/19110/req/inheritance
http://standards.iso.org/iso/19110/req/global
http://standards.iso.org/iso/19110/req/operation
http://standards.iso.org/iso/19110/req/value-list
Exigence /req/conceptual-model/all
Un modèle conceptuel conforme à la méthodologie de l’ISO 19110 pour représenter un
catalogue d’entités doit satisfaire à toutes les exigences énumérées dans le catalogue et
les classes d’exigences relatives au contenu basique, attributs, association, héritage, global,
opération et liste de valeurs.
Afin de permettre l’implémentation XML d’un modèle conforme aux exigences susvisées, le présent
document comprend, en Annexe B, un modèle UML conforme aux exigences énumérées ci-dessus. Ce
modèle UML ajoute certaines propriétés, associations et classes supplémentaires optionnelles qui ne
sont pas imposées par les classes d’exigence du Tableau 1, mais qui ont été jugées utiles par le comité de
rédaction. Le modèle UML en Annexe B est considéré comme normatif pour les définitions, propriétés
et cardinalités de ces éléments et associations.
6.3 Exigences relatives à l’implémentation XML
L’implémentation XML de la méthodologie pour cataloguer les entités repose sur le modèle UML
présenté en Annexe B. Cette implémentation nécessite deux espaces de nommage. L’espace de nommage
http://standards.iso.org/iso/19110/gfc/1.1 (l’abréviation normalisée est gfc) implémente les classes,
propriétés et associations comprises dans le modèle UML. L’espace de nommage http://standards.iso.
org/iso/19110/fcc/1.0 (l’abréviation normalisée est fcc) comprend les éléments qui implémentent les
classes abstraites nécessaires pour permettre les implémentations ISO XML pour lier les éléments du
présent document sans engager une version particulière de l’implémentation XML. Ce modèle repose
sur la règle d’implémentation donnée dans l’ISO/TS 19115-3:2016, Article 8. Le Tableau 11 résume les
classes abstraites implémentées dans l’espace de nommage fcc.
Tableau 11 — Classes abstraites définies dans l’espace de nommage fcc pour permettre le
couplage libre avec d’autres implémentations ISO/TC 211 XML
Espace de nommage définissant l’implémenta-
Classe abstraite
tion concrète
_FeatureCatalogue catalogue d’entités (gfc)
_FeatureType catalogue d’entités (gfc)
L’ISO/TS 19139:2007, Articles 7, 8 et 9, et l’ISO/TS 19115-3:2016, 8.3, décrivent les détails de l’encodage
du schéma conceptuel UML en un jeu de schémas conceptuels XML. L’implémentation du schéma XML
du modèle conceptuel de l’ISO 19110 fourni en Annexe B observe les règles et les modèles décrits dans
ces articles, en les appliquant au modèle UML pour l’implémentation XML.
La validation du schéma XML ne suffisant pas à soumettre à essai toutes les exigences énumérées,
certains tests de conformité nécessitent d’autres procédures de validation. Par exemple, comme indiqué
12 © ISO 2016 – Tous droits réservés

---------
...

МЕЖДУНАРОДНЫЙ ISO
СТАНДАРТ
Второе издание
2016-12-01
Географическая информация.
Методология каталогизации
пространственных объектов
Geographic information — Methodology for feature cataloguing

Ответственность за подготовку русской версии несёт GOST R
(Российская Федерация) в соответствии со статьёй 18.1 Устава ISO
Ссылочный номер
ДОКУМЕНТ ЗАЩИЩЕН АВТОРСКИМ ПРАВОМ

Все права сохранены. Если не указано иное, никакую часть настоящей публикации нельзя копировать или использовать в какой-
либо форме или каким-либо электронным или механическим способом, включая фотокопии и микрофильмы, без
предварительного письменного согласия со стороны ISO, расположенной по нижеуказанному адресу, или членов ISO в стране
регистрации пребывания.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Тел.: + 41 22 749 01 11
Факс: + 41 22 749 09 47
copyright@iso.ch
www.iso.ch
ii © ISO 2016 – Все права сохраняются

Содержание Страница
Предисловие . iv
Введение . v
1 Область применения. 1
2 Нормативные ссылки . 1
3 Термины и определения . 1
4 Соответствие . 3
4.1 Классы соответствий . 3
5 Сокращения. 4
6 Требования . 4
6.1 Общие положения . 4
6.2 Концептуальные требования . 4
6.3 Требования, предъявляемые к XML-реализации . 11
6.4 Требования, предъявляемые к документу XML-экземпляра . 12
Приложение A (нормативное) Абстрактный проверочный набор . 15
Приложение B (нормативное) Концептуальная схема каталога объектов и словарь данных. 25
Приложение C (нормативное) Описание преобразования . 46
Приложение D (нормативное) Управление реестрами каталогов объектов . 49
Приложение E (информативное) Примеры каталогизации объектов . 59
Приложение F (информативное) Принципы каталогизации объектов . 71
Приложение G (информативное) Преобразование унаследованных каталогов объектов . 74
Библиография . 76

Предисловие
Международная организация по стандартизации (ISO) является всемирной федерацией национальных
организаций по стандартизации (комитетов-членов ISO). Разработка международных стандартов
обычно осуществляется техническими комитетами ISO. Каждый комитет-член, заинтересованный в
деятельности, для которой создан технический комитет, имеет право быть представленным в этом
комитете. Международные правительственные и неправительственные организации, имеющие связи с
ISO, также принимают участие в работах. ISO тесно сотрудничает с Международной
электротехнической комиссией (IEC) по вопросам стандартизации в области электротехники.
Процедуры, использованные при разработке настоящего документа, а также процедуры его
дальнейшего утверждения, описаны в директивах ISO/IEC (часть 1). Особо необходимо отметить, что
для различных типов документов ISO применяются различные критерии утверждения. Данный
международный стандарт разработан в соответствии с редакционными правилами директив ISO/IEC
).
Часть 2 (см. www.iso.org/directives
Следует иметь в виду, что некоторые элементы настоящего международного стандарта могут быть
объектом патентных прав. Международная организация по стандартизации не несет ответственность
за идентификацию какого-либо одного или всех патентных прав. Сведения о любых патентных правах,
обнаруженных во время разработки настоящего документа, будут указаны в разделе «Введение» и/или
в списке патентных уведомлений, полученных ISO (см. www.iso.org/patents).
Все торговые названия, используемые в этом документе, указаны для удобства пользователей и не
должны рассматриваться в качестве одобрения.
Пояснения специальных терминов и выражений, связанных с оценкой соответствия, и сведения о
соблюдении ISO принципов Всемирной торговой организации (WTO) по недопущению технических
препятствий торговле (TBT) см. по адресу: www.iso.org/iso/foreword.html.
За разработку настоящего документа отвечает комитет ISO/TC 211 Географическая
информация/Геоматика.
Второе издание настоящего стандарта отменяет и замещает первое издание стандарта
(ISO 19110:2005), который подвергся пересмотру в техническом плане. Кроме того, замещается
ISO 19110:2005/Изм. 1:2011. Приложение G содержит информацию, позволяющую сопоставить
каталоги объектов из первого издания с каталогами объектов, которые используются во втором
издании настоящего стандарта.
iv © ISO 2016 – Все права сохраняются

Введение
Географические объекты представляют собой объекты реального мира, связанные с определённым
местом на Земле, для которых выполняется сбор, хранение и распространение данных. Каталоги
объектов, определяющие типы объектов, их операции, атрибуты и связи, представленные в виде
географических данных, являются необходимыми при преобразовании этих данных в пригодную для
использования информацию. Такие каталоги объектов способствуют распространению,
распределению и использованию географических данных посредством обеспечения лучшего
понимания содержания и смыслового значения этих данных. Если поставщики и пользователи
географических данных не имеют общего представления об объектах реального мира,
характеризуемых этими данными, пользователи не смогут оценить насколько предоставленные
данные соответствуют их целям.
Доступность стандартных каталогов объектов, которые можно использовать многократно, сократит
расходы на сбор информации и упростит процесс формирования спецификаций для наборов
географических данных.
Настоящий стандарт предоставляет нормативную базу для формулирования и декларирования
классификации объектов реального мира с помощью набора географических данных. Любой набор
географических данных является значительно упрощенной и неполной абстракцией сложного и
многообразного мира. Каталог типов объектов никогда не сможет охватить обширность
географической реальности, однако такой каталог должен содержать чёткое и точное описание
конкретной абстракции, характеризуемой определённым набором данных. Описание абстракции
необходимо представить в форме, которая легко понятна и доступна пользователям.
Существуют два уровня географических объектов: экземпляры и типы. На уровне экземпляров любой
географический объект представляется в виде отдельного объекта, связанного со своими
географическими и временными координатами. При этом графический объект может обозначаться
определенным графическим символом. Отдельные экземпляры объектов объединяются в классы с
общими характеристиками (типы объектов). Необходимо отметить, что географическая информация
воспринимается субъективно, а её содержание зависит от потребностей конкретных областей
применения, которые влияют на выбор способа группировки экземпляров в типы согласно
определенной системе классификации. Стандарт ISO 19109 содержит описание структурирования
данных с учётом конкретных потребностей областей применения, предъявляющих похожие
требования к данным.
ПРИМЕЧАНИЕ Полное описание содержимого и структуры набора географических данных определяется
прикладной схемой, разработанной согласно требованиям стандарта ISO 19109. Каталог объектов содержит
описание типов объектов, а также их атрибутов, операций и связей, указанных в прикладной схеме.
Настоящий стандарт допускает многоязычное описание прикладных схем, соответствующих
требованиям стандарта ISO 19109. Кроме того, регламентируется механизм, позволяющий выполнить
одиночное глобальное описание некоторых свойств, встречающихся много раз в прикладной схеме, и
обеспечивающий сопоставление этих глобальных свойств с типами объектов.
В настоящем стандарте отсутствуют критерии сбора информации, используемой для идентификации
отдельных объектов реального мира и представления их в виде экземпляров объектов, формирующих
набор данных. Критерии сбора информации не регламентируются стандартами, поэтому их
необходимо указывать отдельно в описании каждого набора данных.
Стандартный способ структурирования информации каталога объектов не обеспечит автоматическое
согласование или совместимость между областями применения. Если классификации объектов
различаются, настоящий стандарт может по крайней мере объяснить причины различий и, как
следствие, помочь избежать ошибок, которые не исключены в случае игнорирования различий. Кроме
того, текст настоящего стандарта может использоваться в качестве основы гармонизации имеющихся
каталогов объектов, обладающих перекрывающимися областями.
Настоящее издание стандарта ISO 19110 посвящено вопросам, связанным с многоязычным
управлением каталогами объектов, и использует изменения, задокументированные в предыдущем
издании. Помимо устранения незначительных противоречий в концептуальных схемах, обновлённое
издание содержит описание улучшенного способа управления глобальными свойствами. Кроме того,
описана реализация XML-схемы для концептуальной схемы каталога объектов и управление
реестрами каталогов объектов. Если первоначальная концептуальная схема не является
подмножеством исправленной концептуальной схемы, можно выполнить преобразование
унаследованных экземпляров.
vi © ISO 2016 – Все права сохраняются

МЕЖДУНАРОДНЫЙ СТАНДАРТ ISO 19110:2016(R)

Географическая информация. Методология каталогизации
пространственных объектов
1 Область применения
Настоящий стандарт содержит описание методологии каталогизации типов объектов и способа
структурирования типов объектов в рамках каталога объектов и их представления пользователям
наборов географических данных. Кроме того, настоящий стандарт применяется при создании
каталогов типов объектов в ранее некаталогизированных областях и пересмотре имеющихся
каталогов объектов с целью обеспечения соответствия требованиям стандартной практики. При этом
предполагается, что каталогизация выполняется для типов объектов, представленных в цифровой
форме. Указанные принципы можно распространить на каталогизацию других форм географических
данных. Каталоги объектов не зависят от словарей концепции объектов, указанных в стандарте
ISO 19126, и могут описываться без использования или создания словаря концепции объектов.
Настоящий стандарт применяется при определении географических объектов на уровне типов, но не
применим в случае необходимости представления отдельных экземпляров каждого типа. В настоящем
стандарте не используются схемы представления из стандарта ISO 19117.
Стандарт ISO 19110:2016 можно использовать как основу для определения предметной области,
смоделированной в конкретном приложении или для стандартизации общих аспектов объектов
реального мира, моделируемых более чем в одном приложении.
2 Нормативные ссылки
Текст, полностью или частично заимствованный из нижеперечисленных документов, составляет
неотъемлемую часть требований настоящего стандарта. Для датированных ссылок применяется
только цитируемое издание. Для недатированных ссылок применяется самое последнее издание
ссылочного документа (в том числе изменения).
ISO 19103. Географическая информация. Язык концептуальной схемы
ISO 19109. Географическая информация. Правила для прикладной схемы
ISO 19115-1:2014. Географическая информация. Метаданные. Часть 1. Основные принципы
ISO/TS 19115-3:2016. Географическая информация. Метаданные. Часть 3. Реализация XML-схемы
для фундаментальных понятий
ISO 19135-1:2015. Географическая информация. Процедуры регистрации элементов. Часть 1.
Основные принципы
ISO/TS 19139:2007. Географическая информация. Метаданные. Реализация XML-схемы
3 Термины и определения
Для целей настоящего документа применяются следующие термины и определения.
ISO и IEC ведут терминологические базы данных, доступные по следующим адресам:
— электротехническая энциклопедия IEC: http://www.electropedia.org/;
— интернет-платформа для просмотра информации ISO: http://www.iso.org/obp.
3.1
обозначение
указатель
designation
designator
представление понятия с помощью соответствующего условного обозначения
Примечание 1 к статье При проведении терминологической работы используются обозначения трёх типов:
символы, наименования и термины.
[ИСТОЧНИК: ISO 1087-1:2000, 3.4.1]
3.2
объект
feature
абстракция явления реального мира
ПРИМЕР Объект, именуемый «Эйфелева башня», можно классифицировать вместе с другими похожими
объектами как тип пространственного объекта «башня».
Примечание 1 к статье Объект может встречаться как тип или экземпляр. Необходимо использовать тип или
экземпляр объекта, когда предназначен только один из них.
[ИСТОЧНИК: ISO 19101-1:2014, 4.1.11]
3.3
связь объекта
feature association
отношение, связывающее экземпляры объектов (3.2) одного типа с экземплярами объекта такого же
или другого типа
3.4
атрибут объекта
feature attribute
характеристика объекта (3.2)
ПРИМЕР 1 Атрибут объекта с именем «цвет» может иметь значение атрибута «зеленый», принадлежащее к
типу данных «текст».
ПРИМЕР 2 Атрибут объекта с именем «длина» может иметь значение атрибута «82,4», принадлежащее к
типу данных «действительный».
Примечание 1 к статье Атрибут объекта характеризуется именем, типом данных и соответствующей областью
значений. Кроме того, атрибут объекта для экземпляра объекта имеет также значение атрибута из области
значений.
[ИСТОЧНИК: ISO 19101-1:2014, 4.1.12]
3.5
каталог объектов
feature catalogue
каталог, содержащий определения и описания типов (3.2), атрибутов (3.4) и отношений объектов,
существующих в одном или нескольких наборах географических данных, вместе с применяемыми
операциями объектов (3.7)
Примечание 1 к статье Отношения объектов охватывают наследования объектов (3.6) и связи объектов (3.3).
[ИСТОЧНИК: ISO 19101-1:2014, 4.1.13]
3.6
наследование объектов
feature inheritance
механизм, посредством которого более специализированные объекты (3.2) включают структуру и
поведение связанных по поведению более общих объектов
3.7
операция объекта
feature operation
операция, которая может выполняться для каждого экземпляра типа объектов (3.2)
ПРИМЕР Операция объекта «плотина» - повышение плотины. Результатом этой операции является
увеличение высоты «плотины» и уровня воды в «резервуаре».
Примечание 1 к статье В ряде случаев операции объекта служат основой для определения типа объекта.
3.8
функциональный язык
functional language
язык, используемый для формализованного описания операций объектов (3.7)
Примечание 1 к статье На функциональном языке типы объектов могут быть представлены как абстрактные
типы данных.
3.9
сигнатура
signature
текстовая строка, содержащая имя и параметры, необходимые для запуска операции
Примечание 1 к статье Сигнатура может содержать дополнительные возвращаемые параметры. Основой
такой сигнатуры обычно служит формальное определение. В этом случае сигнатура эквивалентна UML-сигнатуре.
4 Соответствие
4.1 Классы соответствий
В основу методологии каталогизации типов объектов положен набор требований, предъявляемых к
описанию типов объектов. Определение одиночного класса соответствия формулируется для
моделей, удовлетворяющих всем концептуальным требованиям. Настоящий стандарт содержит
сведения о концептуальной модели представления описаний типов объектов с помощью набора UML-
схем, удовлетворяющих определению некоторого класса соответствия. Приложение A предоставляет
информацию об абстрактных проверочных наборах для классов соответствий.
Второй набор требований, предъявляемых к XML-реализации концептуальной модели, служит основой
для класса соответствия, используемого при XML-реализации UML-модели представления типов
объектов в каталоге объектов. Основой такой реализации служат правила, указанные в стандартах
ISO/TS 19139 и ISO/TS 19115-3.
Приложение D содержит описание концептуальной модели для реестрового каталога объектов, но не
предоставляет сведения о соответствующей XML-реализации.
Таблица 1 — Описание классов соответствий
Унифицированный Цель стандартизации Имя класса соответствия (реализованный
идентификатор ресурса раздел)
a
класса соответствия
/conf/conceptual-model Концептуальная модель Концептуальная модель для каталога объектов
/conf/feature-catalogue-xml XML-реализация XML-реализация концептуальной модели каталога
объектов
/conf/feature-catalogue-xml- Документ XML-экземпляра Действительный документ XML-экземпляра для
instance обмена содержимым каталога объектов
a
Все унифицированные идентификаторы ресурсов классов соответствий представляют собой унифицированные
идентификаторы ресурсов HTTP с префиксом 'http://standards.iso.org/iso/19110' для путей в ячейках таблиц (используются для
получения полного унифицированного идентификатора ресурсов).
5 Сокращения
GFC Geographic Feature Cataloguing (Каталогизация географических объектов)
GFM General Feature Model (Общая модель объекта)
HTTP Hyper Text Transfer Protocol (Протокол передачи гипертекста)
IHO International Hydrographic Organization (Международная гидрографическая организация)
TS Technical Specification (Техническое описание)
UML Unified Modeling Language (Унифицированный язык моделирования)
URI Uniform Resource Identifier (Унифицированный идентификатор ресурса)
XML eXtensible Markup Language (Расширяемый язык разметки)
6 Требования
6.1 Общие положения
Раздел 6 содержит общие и специальные требования, предъявляемые к информационным элементам
каталогов объектов.
6.2 Концептуальные требования
Таблицы 2 – 10, 12 и 13 обобщают требования, предъявляемые к концептуальной модели описания
типов объектов и их атрибутов, операций и связей в каталоге объектов. Требования объединяются в
классы требований. Каждый класс требований обладает унифицированным идентификатором ресурса.
При этом каждое требование также обладает унифицированным идентификатором ресурса,
основанным на унифицированном идентификаторе ресурса класса требований, к которому оно
принадлежит. Строка «Зависимость» содержит унифицированный идентификатор ресурса класса
требований. Наличие унифицированного идентификатора ресурса должно соблюдаться в качестве
предварительного условия для класса требований.
В таблицах 2 — 10, 12 и 13 используются следующие соглашения.
— Термин «сущность» используется для обозначения элементов модели, представляющих
информационные объекты, допускающие создание экземпляров в рамках концептуальной
модели. В зависимости от используемой концепции моделирования возможно применение
других обозначений сущности (например, «объект», «класс», «элемент» или «особенность»).
— Добавление имени сущности модели в описание требований означает, что сущность или любой
подтип получены на основе такой сущности экземпляра модели.
— Имена свойств заключены в одинарные кавычки (' ') и содержат буквы только нижнего регистра.
Таблица 2 — Класс требований для каталога
Идентификатор http://standards.iso.org/iso/19110/1.1/req/catalogue
Целевой тип Концептуальная модель
Имя
Ключевые концептуальные требования, предъявляемые к каталогу объектов согласно
ISO 19110
Зависимость ISO 19115-1:2014, 6.6.2
ISO/TS 19139:2007, 7.4.4
Требование /req/catalogue/representation
Каталог объектов должен документировать абстракцию реальности, представляющую
один или несколько географических объектов.
ПРИМЕЧАНИЕ Каталог объектов может соответствовать требованиям настоящего
стандарта независимо от какого-либо имеющегося набора географических данных.
Требование /req/catalogue/abstraction
Тип объекта должен использоваться в качестве базового уровня абстракции каталога
объектов.
Требование /req/catalogue/electronic-form
Необходимо обеспечить наличие каталога объектов в электронной форме.
Требование /req/catalogue/inheritance
Каталог объектов должен наследовать все свойства и взаимосвязи, указанные для
абстрактного класса CT_Catalogue в стандарте ISO/TS 19139:2007, 7.4.4.
Требование /req/catalogue/identification
Каталог объектов должен содержать идентификационную информацию, в том числе
'name', 'versionNumber' и 'versionDate'.
Требование /req/catalogue/producer
Сущность каталога объектов должна содержать обязательное свойство 'producer' только
с одним значением, соответствующим содержимому сущности CI_Responsibility,
описанной в стандарте ISO 19115-1:2014, 6.6.2.
Требование /req/catalogue/functional-language
Если для официального описания операций объектов используется функциональный
язык, сущность каталога объектов должна обладать свойством 'functional language' с
текстовым значением, указывающим используемый язык.
Требование /req/catalogue/identifier
Если глобальный уникальный идентификатор используется в качестве свойства каталога
объектов, такому идентификатору необходимо присвоить имя 'identifier' и значение,
соответствующее содержимому сущности MD_Identifier, описанной в стандарте
ISO 19115-1:2014, 6.6.2.
Рекомендация /rec/catalogue/schema-language
Для моделирования информации каталога объектов рекомендуется использовать язык
концептуальной схемы, чтобы достигнуть максимальной полезности каталога объектов в
различных областях применения.
ПРИМЕЧАНИЕ Определения на естественном языке, псевдонимы типов объектов,
критерии создания/удаления экземпляров объектов и прочие семантические элементы
каталога объектов могут добавляться к концептуальной схеме в качестве
структурированных комментариев или атрибутов.
Таблица 3 — Класс требований для базового информационного наполнения
Идентификатор http://standards.iso.org/iso/19110/1.1/req/base-content
Целевой тип Концептуальная модель
Имя Ключевые концептуальные требования, предъявляемые к базовому содержимому
каталога объектов согласно ISO 19110
Зависимость http://standards.iso.org/iso/19110/req/catalogue
Требование /req/base-content/minimum
Каталог объектов должен содержать описание как минимум одного типа объекта.
Требование /req/base-content/feature-type-names
Тип объекта должен идентифицироваться только с помощью одного имени типа,
уникального в рамках каталога объектов.
Значение имени типа ('type name') должно содержать необязательное свойство
'codespace' (указывает пространство имен) и строковое значение (предоставляет имя).
Требование /req/base-content/feature-type-is-abstract
Тип объекта должен обладать обязательным свойством 'is abstract' с булевым
значением.
Требование /req/base-content/feature-properties
Свойства типа объекта должны иметь связь с типом объекта, обладающим ролью
'carrierOfCharacteristics'.
Свойства типа объекта должны классифицироваться как один из атрибутов объектов,
операций объектов или ролей связей.
Требование /req/base-content/property-type-names
Все типы свойств (атрибут, операция или роль связи) должны идентифицироваться
одиночным именем типа, уникальным в пределах типа объекта (локальные свойства),
или каталога объектов (глобальные свойства), содержащего определение свойств.
Значение имени типа ('type name') должно содержать необязательное свойство
'codespace' (указывает пространство имен) и строковое значение (предоставляет имя).
Требование /req/base-content/all-type-definitions
Каталог объектов должен содержать определения всех типов объектов и типов свойств
(атрибут, операция или роль связи), входящих в состав модели.
Требование /req/base-content/constraints
Если модель содержит ограничения в отношении сущностей типов объектов или типов
свойств, такие ограничения должны представляться сущностью ограничений,
обладающей свойством описания со строковым значением. Сущность типа объектов или
типа свойств должна связываться с сущностью ограничений через роль 'constrainedBy'.
Рекомендация /rec/base-content/multiple-definition
Если определение одного и того же компонента одновременно существует в
упоминаемом источнике определений и элементе каталога объектов (тип объекта,
свойство, связь или списочное значение), определение, содержащееся в элементе
каталога объектов, должно иметь приоритет.
Рекомендация /rec/base-content/only-elements
Для обеспечения предсказуемости и сравнимости содержимого каталога объектов
необходимо, чтобы модель содержала только элементы концептуальной UML-модели,
регламентируемой настоящим стандартом (см. приложение B).
Рекомендация /rec/base-content/functional-language
При формулировании определений типов объектов рекомендуется использовать
функциональный язык.
Идентификатор http://standards.iso.org/iso/19110/1.1/req/base-content
Целевой тип
Концептуальная модель
Имя Ключевые концептуальные требования, предъявляемые к базовому содержимому
каталога объектов согласно ISO 19110
Зависимость http://standards.iso.org/iso/19110/req/catalogue
Таблица 3 (продолжение)
Рекомендация /rec/base-content/abstract-property-type
Описание свойств объектов должно реализовываться с помощью абстрактного класса
типов свойств, используемого для получения типов атрибутов, операция и ролей связей.
Рекомендация /rec/base-content/property-closure
Каталог объектов должен для каждого типа объекта предоставлять описание свойств,
связанных с типом объекта, и операций, влияющих на свойства объектов из каталога.
Справочная
Каждый атрибут объекта, списочное значение, связь объекта и тип объекта может
информация обладать свойством 'code' с буквенно-цифровым значением, используемым в качестве
идентификатора.
Таблица 4 — Класс требований для атрибута
Идентификатор http://standards.iso.org/iso/19110/1.1/req/attribute
Целевой тип Концептуальная модель
Имя
Ключевые концептуальные требования, предъявляемые к атрибутам каталога объектов
согласно ISO 19110
Зависимость http://standards.iso.org/iso/19110/req/base-content
Требование /req/attribute/inheritance
Сущность атрибута объекта должна наследовать все свойства и связи сущности типа
свойства.
Требование Атрибут объекта должен обладать свойством 'valueType' со строковым значением,
указывающим тип данных или объекта. Свойство 'valueType' должно указываться
напрямую как часть определения атрибута или косвенно в привязке (см. /req/global
ниже).
Требование /req/attribute/attribute-cardinality
Атрибут объекта должен обладать свойством кардинальности, указывающим нижний и
верхний предел количества экземпляров типа целевых значений, которые могут
существовать в экземпляре допустимых данных. Значение по умолчанию равно 1.
Требование /req/attribute/measurement-unit
Если сущность атрибута объекта обладает свойством, указывающим единицы
измерения, связанные со значением атрибута, такой сущности необходимо присвоить
имя 'valueMeasurementUnit' и строковое значение, идентифицирующее единицу
измерения.
Требование /req/attribute/code
Если сущность атрибута объекта обладает свойством, предоставляющим
дополнительный идентификатор атрибута, такой сущности необходимо присвоить имя
'code'.
Таблица 5 — Класс требований для связи
Идентификатор http://standards.iso.org/iso/19110/1.1/req/association
Целевой тип Концептуальная модель
Имя Ключевые концептуальные требования, предъявляемые к связям каталога объектов
согласно ISO 19110
Зависимость http://standards.iso.org/iso/19110/req/base-content
Требование /req/association/inheritance
Сущность связи объекта должна наследовать все свойства и связи сущности типа
объекта.
Требование /req/association/association-participation
Связь объекта должна обладать как минимум двумя экземплярами ролей связей,
соединённых через роль 'roleName'.
Таблица 5 (продолжение)
Требование /req/association/role-cardinality
Сущность роли связи должна обладать свойством 'cardinality', указывающим нижний и
верхний предел количества экземпляров типа целевых объектов, которые могут
существовать в экземпляре допустимых данных. Значение по умолчанию равно 0.*.
Требование /req/association/association-role-inheritance
Сущность роли связи должна наследовать все свойства и связи сущности типа свойства.
Требование /req/association/role-relation
Сущность роли связи должна связываться только с одной сущностью связи объекта
через роль 'relation'.
Требование /req/association/role-player
Сущность роли связи должна связываться как минимум с одним типом объекта через
роль 'rolePlayer'.
ПРИМЕЧАНИЕ Такое сопоставление может осуществляться напрямую через роль
связи (в этом случае кардинальность равна 1) или косвенно через промежуточную роль
связывания (в этом случае роли связи может сопоставляться несколько типов объектов).
Требование /req/association/role-type
Сущность роли связи должна обладать свойством 'type' со значением в виде
перечисления, состоящего из следующих элементов {ordinary, aggregation, composition}.
Требование /req/association/role-is-ordered
Сущность роли связи должна обладать свойством 'isOrdered' с булевым значением,
указывающим состояние упорядочения экземпляров этой роли связи в пределах
экземпляра объекта (FALSE = "не упорядочено", TRUE = "упорядочено").
Требование /req/association/role-is-navigable
Сущность роли связи должна обладать свойством 'is navigable' с булевым значением,
указывающим на возможность перемещения такой роли от исходного объекта к
целевому объекту связи. TRUE = 'navigable'.
Таблица 6 — Класс требований для наследования
Идентификатор http://standards.iso.org/iso/19110/1.1/req/inheritance
Целевой тип Концептуальная модель
Имя Ключевые концептуальные требования, предъявляемые к наследованию каталога
объектов согласно ISO 19110
Зависимость http://standards.iso.org/iso/19110/req/base-content
Требование /req/inheritance/class
Связи наследования в каталоге объектов должны представляться с помощью класса
связей наследования, сопоставляющего одиночный тип объекта роли 'subtype' с
отличающимся типом объекта роли 'supertype'.
Требование /req/inheritance/description
Связь наследования должна обладать свойством 'description'.
Требование /req/inheritance/unique-instance
Связь наследования должна обладать свойством 'uniqueInstance' с булевым значением.
Данное свойство имеет значение TRUE, если экземпляр роли 'supertype' может
выступать в роли экземпляра по крайней мере одного из своих типов объектов 'subtype'.
Таблица 7 — Класс требований для глобального свойства
Идентификатор http://standards.iso.org/iso/19110/1.1/req/global
Целевой тип Концептуальная модель
Имя Ключевые концептуальные требования, предъявляемые к глобальным свойствам
каталога объектов согласно ISO 19110
Зависимость http://standards.iso.org/iso/19110/req/base-content
Таблица 7 (продолжение)
Требование /req/global/global-property
Тип globalProperty должен иметь связь с одиночным каталогом объектов через роль
'featureCatalogue' и не должен связываться с каким-либо типом объекта через роль
'featureType'.
Требование /req/global/binding
Привязка должна связывать только один тип свойства в роли 'globalProperty' с точно
одним типом объекта в роли 'featureType' или в роли 'rolePlayer', но не в обеих ролях.
Требование /req/global/binding-description
Если сопоставление обладает свойством, используемым для описания экземпляра
сопоставления, такому сопоставлению необходимо присвоить имя 'description' и
строковое значение.
Требование /req/global/global-xor-local
Тип свойств, заполняющий роль 'globalProperty' при сопоставлении, не должен
одновременно заполнять роль 'carrierOfCharacteristics' для типа объектов, но должен
иметь связь с одиночным каталогом объектов через роль 'featureCatalogue'.
Требование /req/global/bound-association-role
Если модель позволяет установить связь 'rolePlayer' между ролью связи роли
'globalProperty' и типом объектов, сопоставление должно выполняться с помощью
сущности роли сопоставляющей связи, наследующей все свойства и связи сущности
сопоставления.
Идентификатор http://standards.iso.org/iso/19110/1.1/req/global
Целевой тип
Концептуальная модель
Имя
Ключевые концептуальные требования, предъявляемые к глобальным свойствам
каталога объектов согласно ISO 19110
Зависимость http://standards.iso.org/iso/19110/req/base-content
Требование /req/global/bound-feature-attribute
Атрибут объекта, заполняющий роль 'globalProperty', должен указывать 'valueType' для
атрибута исключительно в случае отсутствия действительного экземпляра 'valueType',
указанного в определении атрибута объекта.
Сопоставление между атрибутом и типом объекта, указывающее 'valueType', должно
выполняться с помощью сущности атрибута сопоставляющего объекта, наследующей
все свойства и связи сущности сопоставления.
Требование /req/global/binding-constraints
Если модель содержит ограничения в отношении сущностей сопоставления, такие
ограничения должны представляться сущностью ограничений, обладающей свойством
описания со строковым значением. Сущность сопоставления должна связываться с
сущностью ограничений через роль 'constrainedBy'.
Таблица 8 —Класс требований для операции
Идентификатор http://standards.iso.org/iso/19110/1.1/req/operation
Целевой тип
Концептуальная модель
Имя
Ключевые концептуальные требования, предъявляемые к операциям каталога объектов
согласно ISO 19110
Зависимость http://standards.iso.org/iso/19110/req/base-content
Требование /req/operation/inheritance
Класс операций объектов должен наследовать все свойства и связи класса типов
свойств.
Требование /req/operation/affected-features
Если операция объекта входит в состав типа объекта, информацию об этом необходимо
указать с помощью роли 'featureType'.
ПРИМЕЧАНИЕ Определение операций объектов возможно в виде отдельного класса
операций, влияющих на значения свойств других объектов, однако такие операции не
считаются частью какого-либо типа объекта.
Таблица 8 (продолжение)
Требование /req/operation/operation-attributes
Связывание с операциями объектов через роли связей 'observesValueOf',
'affectsValuesOf' или 'triggeredByValuesOf' должно выполняться только для атрибутов
объектов.
Требование /req/operation/signature
Каждая сущность операции объекта должна характеризоваться только одним свойством
'signature', уникальным в рамках каталога объектов.
ПРИМЕЧАНИЕ Сигнатура указывает имя операции и необходимые имена
параметров, используемые для обращения к операции.
Требование /req/operation/operation-cardinality
Сущность операции объекта должна обладать свойством кардинальности, указывающим
возможное количество возвращаемых значений. Значение по умолчанию равно 1.
Идентификатор http://standards.iso.org/iso/19110/1.1/req/operation
Целевой тип
Концептуальная модель
Имя
Ключевые концептуальные требования, предъявляемые к операциям каталога объектов
согласно ISO 19110
Зависимость http://standards.iso.org/iso/19110/req/base-content
Требование /req/operation/formal-definition
Если операция формализованно описывается с использованием функционального
языка, текст такого описания должен указываться в свойстве сущности операции объекта
'formal definition'.
Требование /req/operation/functional-language
Если сущность операции объекта содержит свойство 'formalDefinition', тогда сущность
каталога объектов должна обладать свойством 'functional language'.
ПРИМЕЧАНИЕ Предполагается, что формальные определения используют
функциональный язык, указанный для каталога, однако это можно проверить только с
помощью экземпляров каталога объектов.
Таблица 9 — Класс требований для списка значений
Идентификатор http://standards.iso.org/iso/19110/1.1/req/value-list
Целевой тип Концептуальная модель
Имя Ключевые концептуальные требования, предъявляемых к списку значений каталога
объектов согласно ISO 19110
Зависимость http://standards.iso.org/iso/19110/req/base-content
Требование /req/value-list/class
Если область значений атрибута объекта представляет собой перечисление или
контролируемый словарь (указывается свойством 'valueType'), такой список должен
формироваться с использованием сущности списочного значения, заполняющей роль
'listed value' для атрибута объекта.
Требование /req/value-list/label
Каждый экземпляр списочного значения должен характеризоваться только одним
текстовым значением свойства 'label'.
Требование /req/value-list/definition
Если сущность списочного значения обладает свойством, предоставляющим
определение значения, такой сущности необходимо присвоить имя 'definition'.
Требование /req/value-list/code
Если сущность списочного значения обладает свойством, предоставляющим
дополнительный идентификатор значения, такой сущности необходимо присвоить имя
'code'.
Таблица 10 — Класс требований для концептуальной модели
Идентификатор http://standards.iso.org/iso/19110/1.1/req/conceptual-model
Целевой тип Концептуальная модель
Имя Концептуальная модель каталога объектов согласно ISO 19110
Зависимость http://standards.iso.org/iso/19110/req/catalogue
http://standards.iso.org/iso/19110/req/base-content
http://standards.iso.org/iso/19110/req/attributes
http://standards.iso.org/iso/19110/req/association
http://standards.iso.org/iso/19110/req/inheritance
http://standards.iso.org/iso/19110/req/global
http://standards.iso.org/iso/19110/req/operation
http://standards.iso.org/iso/19110/req/value-list
Требование /req/conceptual-model/all
Концептуальная модель, соответствующая методологии ISO 19110 в части
представления каталога объектов, должна удовлетворять всем требованиям,
перечисленным в классах требований каталога, базового содержимого, атрибутов,
связей, наследования, глобальных свойств, операций и списка значений.
Для XML-реализации модели, соответствующей вышеуказанным требованиям, настоящий стандарт
(см. приложение B) содержит описание UML-модели, удовлетворяющей вышеперечисленным
требованиям. UML-модель характеризуется рядом дополнительных необязательных свойств, связей и
классов, которые не предусмотрены классами требований из таблицы 1, но сочтены полезными
редакторским комитетом. UML-модель из приложения B считается нормативной для определений,
свойств и кардинальностей этих элементов и связей.
6.3 Требования, предъявляемые к XML-реализации
XML-реализация методологии каталогизации объектов основана на UML-модели, представленной в
приложении B. Для реализации необходимы два пространства имен. Пространство имен
http://standards.iso.org/iso/19110/gfc/1.1 (стандартное сокращение gfc) реализует классы, свойства и
связи, содержащиеся в UML-модели. Пространство имен http://standards.iso.org/iso/19110/fcc/1.0
(стандартное сокращение fcc) содержит элементы, реализующие абстрактные классы, необходимые
для сопоставления других ISO XML-реализаций с элементами настоящего стандарта без привязки к
конкретной версии XML-реализации. Основой данного шаблона служит правило реализации,
указанное в стандарте ISO/TS 19115-3:2016 (см. раздел 8). Таблица 11 содержит сводные сведения об
абстрактных классах, реализованных в пространстве имен fcc.
Таблица 11 — Абстрактные классы, указанные в пространстве имен fcc с целью обеспечения
гибкого сопоставления с другими XML-реализациями, которые соответствуют требованиям
ISO/TC 211
Абстрактный класс Пространство имен, определяющее конкретную реализацию
_FeatureCatalogue Каталог объектов (gfc)
_FeatureType Каталог объектов (gfc)
Стандарты ISO/TS 19139:2007 (см. разделы 7, 8 и 9) и ISO/TS 19115-3:2016 (см. 8.3) содержат
сведения об преобразовании концептуальной UML-схемы в набор XML-схем. Реализация XML-схемы
концептуальной модели ISO 19110, рассмотренной в приложении B, выполняется с учётом правил и
шаблонов, описанных в этих разделах и применяемых к UML-модели при XML-реализации.
Поскольку проверка XML-схемы не позволяет определить насколько соблюдаются все перечисленные
требования, некоторые проверки соответствия требуют выполнения других процедур контроля
достоверности. Например, согласно ISO/TS 19139:2007 (см. 8.4) элемент свойства, расположенный
после стандартного шаблона типа свойств XML-класса (XCPT), может относиться только к одному из
следующих типов:
1) встроенные данные (по значению), представляющие собой XML-класс;
2) атрибут xlink:href (по контрольному значению); или
3) атрибут gco:nilReason (нулевое значение).
Поскольку XML-схема не может накладывать ограничения на совместное появление содержимого или
атрибутов, поэтому в дополнение к проверке XML-схемы необходимо использовать некоторый
механизм ограничения свойств на исключительность по значению или по ссылке или отсутствие
значения.
Правила, реализующие эти ограничения, содержатся в подходящем классе требований для
экземпляров XML-документа. Пакет XML-реализации ISO 19110 содержит набор правил Schematron,
предназначенный для проверки на соответствие этим требованиям. В случае отсутствия средства,
позволяющего выполнить проверку с помощью правил Schematron, может потребоваться прямой
контроль соответствия этим требованиям.
Таблица 12 — Класс требований для XML-реализации
Идентификатор http://standards.iso.org/iso/19110/req/1.1/xml-implementation
Целевой тип Документы XML-схемы и правил Schematron
Имя Ключевые требования для XML-реализации концептуальной модели каталога объектов.
Зависимость http://standards.iso.org/iso/19139/spec#7
http://standards.iso.org/iso/19139/spec#8
http://standards.iso.org/iso/19139/spec#9
http://standards.iso.org/iso/19115-3/1.0/spec#8.4
http://standards.iso.org/iso/19110/1.1/spec/annex-b
Требование /req/xml-implementation/rule-based
XML-схема и правила Schematron, реализующие UML-модель каталога объектов,
регламентируемого настоящим стандартом, должны соответствовать правилам и
шаблонам, указанным в стандартах ISO/TS 19139 и ISO/TS 19115-3.
Требование /req/xml-implementation/base-data-types
Основные типы данных должны реализовываться согласно правилам,
сформулированным в стандарте ISO/TS 19139.
6.4 Требования, предъявляемые к документу XML-экземпляра
При использовании различных пр
...

SLOVENSKI STANDARD
oSIST ISO 19110:2017
01-marec-2017
Geografske informacije - Metodologija za objektne kataloge
Geographic information - Methodology for feature cataloguing
Information géographique - Méthodologie de catalogage des entités
Ta slovenski standard je istoveten z: ISO 19110:2016
ICS:
07.040 Astronomija. Geodezija. Astronomy. Geodesy.
Geografija Geography
35.240.70 Uporabniške rešitve IT v IT applications in science
znanosti
oSIST ISO 19110:2017 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

oSIST ISO 19110:2017
oSIST ISO 19110:2017
INTERNATIONAL ISO
STANDARD 19110
Second edition
2016-12-01
Geographic information —
Methodology for feature cataloguing
Information géographique — Méthodologie de catalogage des entités
Reference number
©
ISO 2016
oSIST ISO 19110:2017
© ISO 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2016 – All rights reserved

oSIST ISO 19110:2017
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Conformance . 3
4.1 Conformance classes . 3
5 Abbreviated terms . 3
6 Requirements . 4
6.1 General . 4
6.2 Conceptual requirements . 4
6.3 XML implementation requirements .11
6.4 XML instance document requirements .12
Annex A (normative) Abstract test suite .14
Annex B (normative) Feature catalogue conceptual schema and data dictionary .23
Annex C (normative) Encoding description .42
Annex D (normative) Management of feature catalogue registers .45
Annex E (informative) Feature cataloguing examples .54
Annex F (informative) Feature cataloguing concepts .65
Annex G (informative) Transformation of legacy feature catalogues .68
Bibliography .70
oSIST ISO 19110:2017
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO’s adherence to the World Trade Organization (WTO) principles in the
Technical Barriers to Trade (TBT) see the following URL: www.iso.org/iso/foreword.html.
The committee responsible for this document is ISO/TC 211, Geographic information/Geomatics.
This second edition cancels and replaces the first edition (ISO 19110:2005), which has been technically
revised. It also replaces ISO 19110:2005/Amd1:2011. Annex G explains how to transform feature
catalogues from the first edition to this revised version.
iv © ISO 2016 – All rights reserved

oSIST ISO 19110:2017
Introduction
Geographic features are real-world phenomena associated with a location relative to the Earth, about
which data are collected, maintained, and disseminated. Feature catalogues defining the types of
features, their operations, attributes, and associations represented in geographic data are indispensable
to turning the data into usable information. Such feature catalogues promote the dissemination,
sharing, and use of geographic data through providing a better understanding of the content and
meaning of the data. Unless suppliers and users of geographic data have a shared understanding of the
kinds of real-world phenomena represented by the data, users will be unable to judge whether the data
supplied are fit for their purpose.
The availability of standard feature catalogues that can be used multiple times will reduce costs of data
acquisition and simplify the process of product specification for geographic datasets.
This document provides a standard framework for organizing and reporting the classification of real-
world phenomena in a set of geographic data. Any set of geographic data is a greatly simplified and
reduced abstraction of a complex and diverse world. A catalogue of feature types can never capture
the richness of geographic reality. However, such a feature catalogue should present the particular
abstraction represented in a given dataset clearly, precisely, and in a form readily understandable and
accessible to users of the data.
Geographic features occur at two levels: instances and types. At the instance level, a geographic feature
is represented as a discrete phenomenon that is associated with its geographic and temporal coordinates
and may be portrayed by a particular graphic symbol. These individual feature instances are grouped
into classes with common characteristics: feature types. It is recognized that geographic information is
subjectively perceived and that its content depends on the needs of particular applications. The needs
of particular applications determine the way instances are grouped into types within a particular
classification scheme. ISO 19109 specifies how data shall be organized to reflect the particular needs of
applications with similar data requirements.
NOTE The full description of the contents and structure of a geographic dataset is given by the application
schema developed in compliance with ISO 19109. The feature catalogue defines the meaning of the feature
types and their associated feature attributes, feature operations, and feature associations contained in the
application schema.
This document enables the multilingual description of application schemas compliant with ISO 19109. It
goes further to provide a mechanism enabling a single global description of some properties occurring
many times in an application schema and a binding of those global properties to the corresponding
feature types.
The collection criteria used to identify individual real-world phenomena and to represent them as
feature instances in a dataset are not specified in this document. Because they are not included in
the standards, collection criteria should be included separately in the product specification for each
dataset.
A standard way of organizing feature catalogue information will not automatically result in
harmonization or interoperability between applications. In situations where classifications of features
differ, this document may at least serve to clarify the differences and thereby help to avoid the errors
that would result from ignoring them. It may also be used as a standard framework within which to
harmonize existing feature catalogues that have overlapping domains.
This revision of ISO 19110 addresses issues related to the multilingual management of feature
catalogues and applies the changes documented in a previous amendment. In addition to removing
minor inconsistencies in the conceptual schemas, the amendment enhanced the mechanism ensuring
the management of global properties. The amendment also provided an XML schema implementation of
the feature catalogue conceptual schema and a management of feature catalogue registers. If the initial
conceptual schema is not a subset of the amended conceptual schema, it is possible to transform legacy
instances.
oSIST ISO 19110:2017
oSIST ISO 19110:2017
INTERNATIONAL STANDARD ISO 19110:2016(E)
Geographic information — Methodology for feature
cataloguing
1 Scope
This document defines the methodology for cataloguing feature types. This document specifies how
feature types can be organized into a feature catalogue and presented to the users of a set of geographic
data. This document is applicable to creating catalogues of feature types in previously uncatalogued
domains and to revising existing feature catalogues to comply with standard practice. This document
applies to the cataloguing of feature types that are represented in digital form. Its principles can be
extended to the cataloguing of other forms of geographic data. Feature catalogues are independent of
feature concept dictionaries defined in ISO 19126 and can be specified without having to use or create
a Feature Concept Dictionary.
This document is applicable to the definition of geographic features at the type level. This document
is not applicable to the representation of individual instances of each type. This document excludes
portrayal schemas as specified in ISO 19117.
This document may be used as a basis for defining the universe of discourse being modelled in a
particular application, or to standardize general aspects of real world features being modelled in more
than one application.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 19103, Geographic information — Conceptual schema language
ISO 19109, Geographic information — Rules for application schema
ISO 19115-1:2014, Geographic information — Metadata — Part 1: Fundamentals
ISO/TS 19115-3:2016, Geographic information — Metadata — Part 3: XML schema implementation for
fundamental concepts
ISO 19135-1:2015, Geographic information — Procedures for item registration — Part 1: Fundamentals
ISO/TS 19139:2007, Geographic information — Metadata — XML schema implementation
3 Terms a nd definiti ons
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at http://www.iso.org/obp
oSIST ISO 19110:2017
3.1
designation
designator
representation of a concept by a sign which denotes it
Note 1 to entry: In terminology work, three types of designations are distinguished: symbols, appellations
and terms.
[SOURCE: ISO 1087-1:2000, 3.4.1]
3.2
feature
abstraction of real-world phenomena
EXAMPLE The phenomenon named “Eiffel Tower” may be classified with other similar phenomena into a
feature type “tower.”
Note 1 to entry: A feature may occur as a type or an instance. Feature type or feature instance should be used
when only one is meant.
[SOURCE: ISO 19101-1:2014, 4.1.11]
3.3
feature association
relationship that links instances of one feature (3.2) type with instances of the same or a different
feature type
3.4
feature attribute
characteristic of a feature (3.2)
EXAMPLE 1 A feature attribute named “colour” may have an attribute value “green” which belongs to the data
type “text”.
EXAMPLE 2 A feature attribute named “length” may have an attribute value “82,4” which belongs to the data
type “real”.
Note 1 to entry: A feature attribute has a name, a data type, and a value domain associated to it. A feature
attribute for a feature instance also has an attribute value taken from the value domain.
[SOURCE: ISO 19101-1:2014, 4.1.12]
3.5
feature catalogue
catalogue containing definitions and descriptions of the feature (3.2) types, feature attributes (3.4)
and feature relationships occurring in one or more sets of geographic data, together with any feature
operations (3.7) that can be applied
Note 1 to entry: Feature relationships include feature inheritances (3.6) and feature associations (3.3).
[SOURCE: ISO 19101-1:2014, 4.1.13]
3.6
feature inheritance
mechanism by which more specific features (3.2) incorporate structure and behaviour of more general
features related by behaviour
3.7
feature operation
operation that every instance of a feature (3.2) type may perform
EXAMPLE A feature operation upon a “dam” is to raise the dam. The results of this operation are to raise the
height of the “dam” and the level of water in a “reservoir”.
2 © ISO 2016 – All rights reserved

oSIST ISO 19110:2017
Note 1 to entry: Sometimes, feature operations provide a basis for feature type definition.
3.8
functional language
language in which feature operations (3.7) are formally specified
Note 1 to entry: In a functional language, feature types may be represented as abstract data types.
3.9
signature
text string that specifies the name and parameters required to invoke an operation
Note 1 to entry: It may contain optional returned parameters. This signature is usually derived from the formal
definition. This is the equivalent of the UML signature.
4 Conformance
4.1 Conformance classes
The methodology for cataloguing feature types is defined through a set of requirements for the
description of feature types. A single conformance class is defined for models meeting all the
conceptual requirements. This document presents a conceptual model for a representation of feature
type descriptions as a set of UML diagrams that satisfy this conformance class. Annex A presents the
abstract test suits for conformance classes.
A second set of requirements for XML implementation of the conceptual model are the basis for a
conformance class for XML implementation of the UML model for representation of feature types in a
feature catalogue. This implementation is based on rules defined in ISO/TS 19139 and ISO/TS 19115-3.
Annex D defines a conceptual model for a registered feature catalogue, but no corresponding XML
implementation is specified by this document.
Table 1 — C on f or m a nc e c l a s s e s de f i ne d by t h i s s p e c i f ic at ion
a
Conformance class URI Standardization target Conformance class name (implemented clause)
/conf/conceptual-model Conceptual model Conceptual model for a feature catalogue
/conf/feature-catalogue-xml XML implementation XML implementation of feature catalogue concep-
tual model
/conf/feature-cata- XML instance document Valid XML instance document for interchange of feature
logue-xml-instance catalogue content
a
All Conformance Class URIs are HTTP URIs, prefix ‘http://standards.iso.org/iso/19110’ to the paths in the table cell to
get the complete URI.
5 Abbreviated terms
GFC Geographic Feature Cataloguing
GFM General Feature Model
HTTP Hyper Text Transfer Protocol
IHO International Hydrographic Organization
TS Technical Specification
oSIST ISO 19110:2017
UML Unified Modeling Language
URI Uniform Resource Identifier
XML eXtensible Markup Language
6 Requirements
6.1 General
Clause 6 specifies general and specific requirements for feature catalogue information elements.
6.2 Conceptual requirements
Tables 2 to 10, 12, and 13 summarize requirements for the conceptual model for describing feature types
and their attributes, operations, and associations in a feature catalogue. Requirements are grouped into
requirements classes; each requirements class has a URI, and each requirement has a URI that is based
on the URI for the requirements class to which it is included. The dependencies column provides the URI
for any requirements class that must be met as a precondition for the requirements class.
In Tables 2 to 10 and 12 to 13, the following conventions are followed.
— The term “entity” is used to refer to model elements representing instantiable information objects
in the conceptual model. Depending on the modelling paradigm used, these may have other labels,
e.g. “object,” “class,” “element,” or “feature”.
— Inclusion of a model entity name in a requirements statement implies that entity or any subtype is
derived from that entity in a model instance.
— Property names are provided in single quotes (‘ ‘), and are all in lower case.
Table 2 — Requirements class for catalogue
Ide nt i f ie r http://standards.iso.org/iso/19110/1.1/req/catalogue
Target type Conceptual model
Name Core conceptual catalogue requirements for ISO 19110 feature catalogue
Dependency ISO 19115-1:2014, 6.6.2
ISO/TS 19139:2007, 7.4.4
Requirement /req/catalogue/representation
A feature catalogue shall document an abstraction of reality representing one or more
geographic features.
NOTE   A feature catalogue may comply with the specifications of this document inde -
pendent of any existing set of geographic data.
Requirement /req/catalogue/abstraction
The feature type shall be the basic level of abstraction in a feature catalogue.
Requirement /req/catalogue/electronic-form
A feature catalogue shall be available in electronic form.
Requirement /req/catalogue/inheritance
A feature catalogue shall inherit all the properties and relationships defined on the abstract
CT_Catalogue class in ISO/TS 19139:2007, 7.4.4.
Requirement /r e q /c at a lo g ue/ide nt i f ic at ion
The feature catalogue shall include identification information that includes a ‘name’, a
‘versionNumber’, a ‘versionDate’.
4 © ISO 2016 – All rights reserved

oSIST ISO 19110:2017
Table 2 (continued)
Requirement /req/catalogue/producer
The feature catalogue entity shall include a mandatory ‘producer’ property with exactly
one value that is an entity conforming to the content of the CI_Responsibility entity defined
by ISO 19115-1:2014, 6.6.2.
Requirement /req/catalogue/functional-language
If a functional language is used to formally define feature operations, the feature cata-
logue entity shall have a ‘functional language’ property with a text value that specifies
the language used.
Requirement /r e q /c at a lo g ue/ide nt i f ie r
If a globally unique identifier is included as a property of a feature catalogue, it shall be
named ‘identifier’ and shall have a value that is an entity conforming to the content of the
MD_Identifier entity defined by ISO 19115-1:2014, 6.6.2.
Recommendation /rec/catalogue/schema-language
To maximize the usefulness of a feature catalogue across different applications, the use of
a conceptual schema language to model feature catalogue information is recommended.
NOTE   Natural-language definitions, feature-type aliases, criteria for the creation and
withdrawal of feature instances, and other semantic elements of the feature catalogue may
be included in a conceptual schema as structured comments or as attributes.
Table 3 — Requirements class for base content
Ide nt i f ie r http://standards.iso.org/iso/19110/1.1/req/base-content
Target type Conceptual model
Name Core conceptual base content requirements for ISO 19110 feature catalogue
Dependency http://standards.iso.org/iso/19110/req/catalogue
Requirement /req/base-content/minimum
A feature catalogue shall describe at least one feature type.
Requirement /req/base-content/feature-type-names
A feature type shall be identified by exactly one ‘type name’ that is unique in the scope of
the containing feature catalogue.
The ‘type name’ value shall consist of an optional ‘codespace’ property that specifies a
namespace, and a string value that provides the name.
Requirement /req/base-content/feature-type-is-abstract
A feature type shall have a mandatory ‘is abstract’ property with a Boolean value.
Requirement /req/base-content/feature-properties
Properties of a feature type shall be linked to the feature type with the role ‘carrierOf-
Characteristics’.
Properties of a feature type shall be categorized as one of feature attribute, feature oper-
ation, or association role.
Requirement /req/base-content/property-type-names
All property types (attribute, operation, or association role) shall be identified by a single
‘type name’ that is unique within the scope of the feature type (local properties) or feature
catalogue (global properties) that contains the property definition.
The ‘type name’ value shall consist of an optional ‘codespace’ property that specifies a
namespace, and a string value that provides the name.
Requirement /r e q / b a s e - c ont e nt/a l l- t y p e - de f i n i t ion s
The feature catalogue shall include definitions of all feature types and property types
(attribute, operation, or association role) included in the model.
oSIST ISO 19110:2017
Table 3 (continued)
Requirement /req/base-content/constraints
If the model includes constraints on feature type or property type entities, they shall be
represented by a constraints entity that has a description property with a string value.
The feature type or property type entity shall be linked to the constraints entity via a
‘constrainedBy’ role.
Recommendation /r e c/ b a s e - c ont e nt/mu l t iple - de f i n i t ion
If the same term is defined in both a referenced definition source and in a feature catalogue
element (feature type, property, association, or listed value), the definition in the feature
catalogue element should take precedence.
Recommendation /rec/base-content/only-elements
To ensure predictability and comparability of feature catalogue content, it is recommended
that the model includes only the elements specified in the UML conceptual model included
in this document (see Annex B).
Recommendation /rec/base-content/functional-language
The use of functional language specifications to help define feature types is recommended.
Ide nt i f ie r http://standards.iso.org/iso/19110/1.1/req/base-content
Target type Conceptual model
Name Core conceptual base content requirements for ISO 19110 feature catalogue
Dependency http://standards.iso.org/iso/19110/req/catalogue
Recommendation /rec/base-content/abstract-property-type
Specification of feature properties should be implemented through an abstract property
type class from which attribute, operation, and association role types are derived.
Recommendation /rec/base-content/property-closure
A feature catalogue should include, for each feature type, specifications of any properties
bound to the feature type, and specifications of any operations that affect feature proper-
ties defined in the catalogue.
Informative Each feature attribute, listed value, feature association, and feature type may have a ‘code’
property that has an alphanumeric value intended as an identifier.
Table 4 — Requirements class for attribute
Ide nt i f ie r http://standards.iso.org/iso/19110/1.1/req/attribute
Target type Conceptual model
Name Core conceptual attribute requirements for ISO 19110 feature catalogue
Dependency http://standards.iso.org/iso/19110/req/base-content
Requirement /req/attribute/inheritance
The feature attribute entity shall inherit all the properties and associations of the property
type entity.
Requirement A feature attribute shall have a property named ‘valueType’ with a value that is a string
referencing a data or object type. The ‘valueType’ shall be specified either directly as part
of the attribute definition, or indirectly in a binding (see /req/global, below).
6 © ISO 2016 – All rights reserved

oSIST ISO 19110:2017
Table 4 (continued)
Requirement /req/attribute/attribute-cardinality
A feature attribute shall have a cardinality property that specifies the lower and upper
limit on the number of instances of the target value type that may occur in a valid data
instance. Default value is 1.
Requirement /req/attribute/measurement-unit
If a feature attribute entity has a property specifying the measurement units associated
with an attribute value, it shall be named ‘valueMeasurementUnit’ and have a value that
is a string that identifies a unit of measure.
Requirement /req/attribute/code
If a feature attribute entity has a property providing an additional identifier for the attrib-
ute, it shall be named ‘code’.
Table 5 — Requirements class for association
Ide nt i f ie r http://standards.iso.org/iso/19110/1.1/req/association
Target type Conceptual model
Name Core conceptual association requirements for ISO 19110 feature catalogue
Dependency http://standards.iso.org/iso/19110/req/base-content
Requirement /req/association/inheritance
The feature association entity shall inherit all the properties and associations of the feature
type entity.
Requirement /req/association/association-participation
A feature association shall have at least two association role instances linked through the
‘roleName’ role.
Requirement /req/association/role-cardinality
The association role entity shall have a ‘cardinality’ property that specifies the lower and
upper limit on the number of instances of the target feature type that may occur in a valid
data instance. Default value is “0.*”.
Requirement /req/association/association-role-inheritance
The association role entity shall inherit all the properties and associations of the property
type entity.
Requirement /req/association/role-relation
An association role entity shall be bound to exactly one feature association entity through
a ‘relation’ role.
Requirement /req/association/role-player
An association role entity shall be bound to at least one feature type through the ‘role-
Player’ role.
NOTE   This binding may be directly from the association role, in which case the cardinality
is 1, or indirectly via a binding and bound association role, in which case multiple feature
types may be bound to the association role.
oSIST ISO 19110:2017
Table 5 (continued)
Requirement /req/association/role-type
An association role entity shall have a ‘type’ property with a value specified by an enumer-
ation consisting of the following terms {ordinary, aggregation, composition}.
Requirement /req/association/role-is-ordered
An association role entity shall have an ‘isOrdered’ property with a Boolean value that
indicates if the instances of this association role within the containing feature instance
are ordered or not, with FALSE= “not ordered” and TRUE = “ordered”.
Requirement /req/association/role-is-navigable
An association role entity shall have an ‘is navigable property with a Boolean value that
indicates whether this role is navigable from the source feature to the target feature of the
association. TRUE = ‘navigable’.
Table 6 — Requirements class for inheritance
Ide nt i f ie r http://standards.iso.org/iso/19110/1.1/req/inheritance
Target type Conceptual model
Name Core conceptual inheritance requirements for ISO 19110 feature catalogue
Dependency http://standards.iso.org/iso/19110/req/base-content
Requirement /req/inheritance/class
Inheritance relationships in a feature catalogue shall be represented using an inheritance
relation class that associates one feature type in the ‘subtype’ role with a different feature
type in the ‘supertype’ role.
Requirement /req/inheritance/description
An inheritance relation shall have a ‘description’ property.
Requirement /req/inheritance/unique-instance
An inheritance relation shall have a ‘uniqueInstance’ property that is a Boolean value, true if
an instance of the ‘supertype’ can be an instance of at most one of its ‘subtype’ feature types.
Table 7 — Requirements class for global
Ide nt i f ie r http://standards.iso.org/iso/19110/1.1/req/global
Target type Conceptual model
Name Core conceptual global properties requirements for ISO 19110 feature catalogue
Dependency http://standards.iso.org/iso/19110/req/base-content
Requirement /req/global/global-property
A globalProperty type shall be associated to one feature catalogue through the ‘feature-
Catalogue’ role and shall not be associated to any feature type via a ‘featureType’ role.
Requirement /req/global/binding
A binding shall associate exactly one property type in a ‘globalProperty’ role to exactly
one feature type in either a ‘featureType’ role, or a ‘rolePlayer’ role, but not in both roles.
Requirement /req/global/binding-description
If a binding has a property used to describe the binding instance, it shall be named ‘de-
scription’ and have a string value.
Requirement /req/global/global-xor-local
A property type that fills a ‘globalProperty’ role on a binding shall not also fill a ‘carrier -
OfCharacteristics’ role on a feature type and shall be associated to one feature catalogue
through the ‘featureCatalogue’ role.
8 © ISO 2016 – All rights reserved

oSIST ISO 19110:2017
Table 7 (continued)
Requirement /req/global/bound-association-role
If the model allows a ‘rolePlayer’ association between an association role in a ‘globalProp-
erty’ role and a feature type, then that binding shall be through a bound association role
entity that inherits all the properties and associations of the binding entity.
Ide nt i f ie r http://standards.iso.org/iso/19110/1.1/req/global
Target type Conceptual model
Name Core conceptual global properties requirements for ISO 19110 feature catalogue
Dependency http://standards.iso.org/iso/19110/req/base-content
Requirement /req/global/bound-feature-attribute
A feature attribute that fills a ‘globalProperty’ role shall specify a ‘valueType’ for the attrib-
ute if and only if there is no valid ‘valueType’ specified in the feature attribute definition.
A binding between a feature attribute and a feature type that specifies a ‘valueType’ shall
be through a bound feature attribute entity that inherits all the properties and associations
of the binding entity.
Requirement /req/global/binding-constraints
If the model includes constraints on binding entities, they shall be represented by a Con-
straints entity that has a description property with a string value. The binding entity shall
be linked to the Constraints entity via a ‘constrainedBy’ role.
Table 8 — Requirements class for operation
Ide nt i f ie r http://standards.iso.org/iso/19110/1.1/req/operation
Target type Conceptual model
Name Core conceptual operation requirements for ISO 19110 feature catalogue
Dependency http://standards.iso.org/iso/19110/req/base-content
Requirement /req/operation/inheritance
The feature operation class shall inherit all the properties and associations of the property
type class.
Requirement /req/operation/affected-features
If the feature operation is contained inside a feature type, this containment shall be spec-
ified through the ‘featureType’ role.
NOTE   A feature operations may be defined as a standalone class for operations that
affect property values of other features but are not considered a part of any feature type.
Requirement /req/operation/operation-attributes
Only feature attributes shall be associated with feature operations via ‘observesValueOf’,
‘affectsValuesOf’, or ‘triggeredByValuesOf’ association roles.
Requirement /req/operation/signature
Each feature operation entity shall have exactly one ‘signature’ property that is unique in
the scope of the feature catalogue.
NOTE   The signature specifies the operation name and required parameter names used
to invoke the operation.
Requirement /req/operation/operation-cardinality
A feature operation entity shall have a cardinality property that specifies the number of
return values possible. Default value is 1.
Ide nt i f ie r http://standards.iso.org/iso/19110/1.1/req/operation
Target type Conceptual model
Name Core conceptual operation requirements for ISO 19110 feature catalogue
oSIST ISO 19110:2017
Table 8 (continued)
Dependency http://standards.iso.org/iso/19110/req/base-content
Requirement /r e q /op e r at ion/f or m a l- de f i n i t ion
If an operation is formally specified using a functional language; the text of this specifi-
cation shall be provided in a feature operation entity property named ‘formal definition.’
Requirement /req/operation/functional-language
If a feature operation entity includes a ‘formalDefinition’ property, then the containing
feature catalogue entity shall have a ‘functional language’ property.
NOTE   The intention is that formal definitions utilize the functional language specified
for the catalogue, but this can only be verified with feature catalogue instances.
Table 9 — Requirements class for value list
Ide nt i f ie r http://standards.iso.org/iso/19110/1.1/req/value-list
Target type Conceptual model
Name Core conceptual value list requirements for ISO 19110 feature catalogue
Dependency http://standards.iso.org/iso/19110/req/base-content
Requirement /req/value-list/class
If the domain of a feature attribute is an enumeration or controlled vocabulary, as indicated
by the ‘valueType’ property, that list shall be specified using a listed value entity that fills
the ‘listed value’ role on the feature attribute.
Requirement /req/value-list/label
Each listed value instance shall have exactly one text ‘label’ property value.
Requirement /r e q /v a lue -l i s t/de f i n i t ion
If a listed value entity has a property providing a definition of the value, it shall be named
‘definition’.
Requirement /req/value-list/code
If a listed value entity has a property providing an additional identifier for a value, it shall
be named ‘code’.
Table 10 — Requirements class for conceptual model
Ide nt i f ie r http://standards.iso.org/iso/19110/1.1/req/conceptual-model
Target type Conceptual model
Name Conceptual model for ISO 19110 feature catalogue
Dependency http://standards.iso.org/iso/19110/req/catalogue
http://standards.iso.org/iso/19110/req/base-content
http://standards.iso.org/iso/19110/req/attributes
http://standards.iso.org/iso/19110/req/association
http://standards.iso.org/iso/19110/req/inheritance
http://standards.iso.org/iso/19110/req/global
http://standards.iso.org/iso/19110/req/operation
http://standards.iso.org/iso/19110/req/value-list
Requirement /req/conceptual-model/all
A conceptual model that conforms to the ISO 19110 methodology for representing a fea-
ture catalogue shall meet all the requirements enumerated in the catalogue, base-content,
attributes, association, inheritance, global, operation and value-list requirements classes.
10 © ISO 2016 – All rights reserved

oSIST ISO 19110:2017
In order to enable XML implementation of a model conforming to the above requirements, this
document includes as Annex B a UML model conforming to the requirements enumerated above. The
UML model adds some additional, optional properties, associations, and classes that are not mandated
by the requirements classes in Table 1, but were determined to be useful by the editing committee.
The UML model in Annex B is considered normative for the definitions, properties, and cardinalities of
these elements and associations.
6.3 XML implementation requirements
The XML implementation of the methodology for feature cataloguing is based on the UML model
presented in Annex B. The implementation requires two namespaces. The namespace http://standards.
iso.org/iso/19110/gfc/1.1 (standard abbreviation is gfc) implements the classes, properties and
associations included in the UML model. The namespace http://standards.iso.org/iso/19110/fcc/1.0
(standard abbreviation is fcc) includes elements that implement abstract classes necessary to enable
other ISO XML implementations to link to elements of this document without committing to a particular
version of the XML implementation. This pattern is based on the implementation rule in ISO/TS 19115-
3:2016, Clause 8. Table 11 summarizes the abstract classes implemented in the fcc namespace.
Table 11 — A b s t r ac t c l a s s e s de f i ne d i n t he fc c n a me s p ac e t o a l low lo o s e c oupl i n g t o ot her
ISO/TC 211 XML implementations
Abstract class N a me s p ac e de f i n i n g c onc r e t e i mple me nt at ion
_FeatureCatalogue feature catalogue (gfc)
_FeatureType feature catalogue (gfc)
ISO/TS 19139:2007, Clauses 7, 8 and 9, and ISO/TS 19115-3:2016, 8.3 describe the details of encoding
the UML conceptual schema into a set of XML schemas. The XML schema implementation of the
ISO 19110 conceptual model provided in Annex B follows the rules and patterns described in those
clauses, applying them to the UML model for XML implementation.
Because XML schema validation is insufficient to test all of the enumerated requirements, some
conformance tests require other validation procedures. For instance, as stated in ISO/TS 19139:2007, 8.4,
a property element following the default XML Class property type (XCPT) pattern may have exactly one of
1) inline content (by-value) that is an XML Class,
2) an xlink:href attribute (by-reference value), or
3) a gco:nilReason attribute (nil value).
Because XML schema cannot constrain the co-occurrence of content or attributes, some mechanism in
addition to XML schema validation shall be used to restrict a property to be exclusively by-value or by-
reference or a nil value.
Rules implementing these constraints are included in the appropriate requirements class for the XML
document instances. The ISO 19110 XML implementation package includes a Schematron rule set for
testing conformance with these requirements. If a tool for Schematron validation is not available,
conformance to these requirements may need to be tested by inspection.
Table 12 — Requirements class for XML implementation
Ide nt i f ie r http://standards.iso.org/iso/19110/req/1.1/xml-implementation
Target type XML schema and Schematron rule documents
Name Core requirements for implementation of feature catalogue conceptual model using XML.
oSIST ISO 19110:2017
Table 12 (continued)
Dependency http://standards.iso.org/iso/19139/spec#7
http://standards.iso.org/iso/19139/spec#8
http://standards.iso.org/iso/19139/spec#9
http://standards.iso.org/iso/19115-3/1.0/spec#8.4
http://standards.iso.org/iso/19110/1.1/spec/annex-b
Requirement /req/xml-implementation/rule-based
XML schema and Schematron rules implementing the UML model for feature catalogue
defined in this specification shall follow the rules and patterns defined in ISO/TS 19139
and ISO/TS 19115-3.
Requirement /req/xml-implementation/base-data-types
Base data types shall be implemented according to rules set forth in ISO/TS 19139.
6.4 XML instance document requirements
Various conformance tests for this document require that metadata instance (XML) documents can
be validated without error against the XML schemas defined in this document. While many tools are
available to test the validation of XML instance documents against provided XML schemas, it is important
to understand that not all validation tools implement the full W3C XML Schema Recommendation and
not all validation tools interpret the W3C XML Schema Recommendation in the same manner. It is
recommended that a tool that implements a strict interpretation of and full support for the W3C XML
Schema Recommendation be used when validating XML instance documents to test conformance.
Conformance classes for requireme
...