Interopérabilité - Institute of Geodesy and Photogrammetry - ETH ...

Interopérabilité pour
l'utilisation généralisée de
la Géoinformation
Journées d‘étude des 17 et 18 mars 2005
Textes rassemblés par A. Carosio
Comité d‘organisation
Institut de Géodésie et Photogrammétrie, EPF Zurich
Laboratoire de Systèmes d'information géographique, EPF Lausanne
École d’ingénieurs du Canton de Vaud, Yverdon
Fachhochschule beider Basel Nordwestschweiz
Société suisse de géomatique et de gestion du territoire
Conférence des Services Cantonaux du Cadastre
Organisation Suisse pour l'Information Géographique
Office fédéral de topographie
Coordination de l‘information géographique et des systèmes
d‘information géographique
Société suisse des ingénieurs et des architectes
Office fédéral de l’agriculture
ETHZ
EPFL
EIVD
FHBB
geosuisse
CSCC
OSIG
swisstopo
COGIS
SIA
OFAG

Edition française :
Journées d‘étude des 17 et 18 mars 2005
IGP Rapport No. 298 f
ISBN
3-906467-52-X
Interopérabilité pour l'utilisation généralisée de la Géoinformation
Textes rassemblés par A. Carosio
Deutsche Ausgabe :
Weiterbildungstagung 17. und 18. März 2005
IGP Bericht No. 298 d
ISBN 3-906467-51-1
Interoperabilität für die breite Nutzung von Geoinformation
Herausgegeben von A. Carosio
©2005
Institut de Géodésie et Photogrammétrie, EPF Zurich
Tous droits réservés

Avant-propos
La réalisation des infrastructures nationales de données géospatiales (NGDI) au niveau
européen et mondial est indissociable de la problématique de l’interconnexion des systèmes
d’information géographique. L’utilisation commune des géodonnées est une nécessité
des plus urgentes. Pour cela, des solutions techniques et organisationnelles sont
indispensables. La formule magique pour arriver à ce but est : interopérabilité !
Les discussions entre collègues, et même avec des spécialistes du domaine, font souvent
ressortir que la problématique et les solutions techniques de l’interopérabilité ne sont
qu’en partie connues.
Il nous a alors semblé approprié d’organiser des journées d’étude sur ce thème afin de
mettre en commun les connaissances disponibles.
Nous sommes convaincus que la participation des organisations travaillant actuellement
au développement des systèmes interopérables a permis de préparer un programme
recouvrant les divers aspects, permettant ainsi de décrire et de clarifier au mieux la problématique.
Je tiens à remercier chaleureusement les auteurs, qui se sont spontanément proposés, les
collaborateurs de l’EPFZ et de l’EPFL qui ont participé à l’élaboration des versions françaises
et allemandes du rapport ainsi que tous les autres participants.
Alessandro Carosio
Zurich, le 3 mars 2005

Comité d’organisation
Alessandro Carosio, Prof. Dr.
Alain Buogo, ing. dipl.
Thomas Glatthard, ing. dipl.
François Golay, Prof. Dr.
Francis Grin, ing. dipl.
Jens Ingensand, ing. dipl.
Peter Jordan, Dr.
Christian Just, ing. dipl.
Jürg Kaufmann, ing. dipl.
Andreas Morf, ing. dipl.
Stephan Nebiker, Prof. Dr.
Anton Stübi, ing. dipl.
Pierre-Alain Trachsel, ing. dipl.
IGP-EPFZ (Président du Comité)
COSIG
OSIG, geosuisse
LaSIG-EPFL
EIVD Yverdon
LaSIG-EPFL
SIA
swisstopo
geosuisse
IGP-EPFZ
FHBB Abt. Vermessung und Geoinformation, Muttenz
Office fédéral de l’agriculture, division Améliorations
structurelles
CSCC

Sommaire
1
L’interopérabilité dans les SIG : besoins, stratégies, solutions
techniques
Prof. Dr. Alessandro Carosio, IGP-EPFZ
Standards nationaux et internationaux
2
3
4
5
Vue d’ensemble
Urs Flückiger, Groupe de travail de l’OSIG sur les technologies SIG
Standards informatiques (UML, XML, SOAP)
Prof. Dr. Christine Giger, IGP-EPFZ
Interactions entre les géonormes mondiales, européennes et
suisses
Hans-Rudolf Gnägi, IGP-EPFZ
OpenGeospatial Consortium OGC (GML, WMS, WFS)
Adrian Annen, FHBB
Etat de la technique, implémentation I
6
7
Le concept OGC : possibilités et limites
Dr. Andreas Donaubauer, Prof. Dr. Matthäus Schilcher, Anette Huber,
TUM
Standards ISO pour le transfert de données : état de la réalisation
Claude Eisenhut, Eisenhut Informatik AG
Etat de la technique, implémentation II
Réalisations dans le cadre des GDI
8
9
10
Interopérabilité en matière de géodonnées : état actuel et
perspectives dans le canton de Vaud
Marc Gilgen, DINF-VD
La complexité de l’interopérabilité : compte-rendu de la pratique de
la Suisse orientale
Ueli Forrer, F+P Geoinfo AG
Approche modélisation et interopérabilité des données appliquée
aux données de référence en Région Wallonne
Jean-Claude Jasselette, MET Belgique

Prochaines étapes dans l’interopérabilité
11
Modèles standardisés ou interoperabilité sémantique : perspectives
de la recherche
Andreas Morf, IGP-EPFZ, Josef Dorfschmid, ADASYS AG
Intéropérabilité sémantique – projets actuels
12
13
Migration de données UIC
Dr. Théophil Engel, SBB
Intégration des données de la carte nationale 1:25’000 (VECTOR25)
dans le modèle de données de la mensuration officielle
(MD.01-MO-CH)
Robert Balanche, swisstopo
Conséquences organisationnelles de l’interopérabilité I
14
15
16
17
Infrastructure nationale de données géographiques (INDG) :
aspects organisationnels de l'interopérabilité au niveau fédéral
Rolf Buser, COSIG
Profils nationaux des standards internationaux : exemples des
métadonnées
Rudolf Schneeberger, ITV Geomatik AG
Interopérabilité : pas seulement une question de technologie
Willy Müller, Unité de stratégie informatique de la Confédération
Interopérabilité stratégique et administrative
Prof. Dr. François Golay, LaSIG-EPFL
Conséquences organisationnelles de l’interopérabilité II
18
19
20
L’interopérabilité en pratique : expériences acquises lors de projets
menés en Suisse comme à l’étranger
Fr. Ivo Leiss, Ernst Basler + Partner AG
Perspectives pour les professions de la géomatique
Christian Kaul, Kaul Beratungen GmbH
Tarification, problématique des coûts
Jürg Kaufmann, Kaufmann Consulting
Particularités de l’interopérabilité dans la pratique
21
22
Géoréférencement, interopérabilité entre les données de la
mensuration et les informations spatiales superposées, hiérarchie
des données et actualisation des données spatiales subordonnées
Dr. Horst Düster, AGI Soleure
Le graphe de la mobilité : un référentiel géographique pour les
partenaires du système d'information de la mobilité de la région
genevoise
Pascal Oehrli, SSIG Genève

1
L’interopérabilité dans les SIG
Besoins, stratégies, solutions techniques
Alessandro Carosio, EPF Zurich
Alessandro Carosio, Prof. Dr.
Eidg. Technische Hochschule Zürich
Institut für Geodäsie und Photogrammetrie
ETH Hönggerberg
CH-8093 Zurich
Tél :
Fax :
E-mail :
+41 1 633 30 52
+41 1 633 11 01

1 Interopérabilité et transfert de données : une
fonctionnalité centrale pour tous SIG
L’utilisation et la mise en oeuvre des systèmes d’informations géographiques sont liées
de manière indissociable avec les notions d’interopérabilité et de transferts de données.
Seules de petites applications, qui n’exigent le traitement que de petites quantités de
données (par exemple des exercices SIG), sont réalisables sans solution pour le transfert
des données.
Nous disposons actuellement d’une quantité toujours plus importante de données géographiques
sous forme numérique, et un grand nombre d’organisations travaillent avec
de telles données. Le risque de doublon et de contradiction est par conséquent élevé.
Souvent, les données souhaitées existent déjà à quelque part. Elles sont toutefois à nouveau
saisies car :
La documentation appropriée manque
Elles présentent une structure incompatible
Un SIG n’est efficace, que s’il peut répondre aux exigences du plus grand nombre
d’utilisateurs.
Réponse
Requête
Réponse
Requête
Plans
Listes
Sélections
Analyses
Données
digitales
Figure 1 : La communication entre deux systèmes d’information géographique
Les exigences et les besoins sont cependant très différents. C’est la raison qui fait qu’une
solution standard globale est relativement difficile à trouver.
Les pays économiquement développés sont en pleine réalisation de leurs infrastructures
de géodonnées nationales (NGDI) appropriées, dans lesquelles le privé,
l’administration, les fournisseur et les développeurs sont intégrés, afin qu’ils puissent
utiliser en commun les technologies et les données existantes.
Ceci ne peut être atteint que si les problèmes organisationnels et techniques sont résolus,
condition préalable pour la réalisation de centre de coordination (Clearinghouses), pour
l’échange d’informations et pour l’utilisation interopérable de géodonnées (cf. figure 2).
Interopérabilité pour l'utilisation généralisée de la Géoinformation 1.1

L’interopérabilité dans les SIG : besoins, stratégies, solutions techniques
Figure 2 : Conditions organisationnels et techniques préalables pour un NGDI
Tous les points représentés dans la figure 2 sont très importants. Le texte présent ne
traite toutefois que de la thématique de l’interopérabilité et du transfert de données entre
les systèmes de producteurs différents.
Les processus requis sont particulièrement d’actualité, puisque l’on travail actuellement
au développement de normes techniques aussi bien au niveau national, qu’au niveau
des institutions internationales (Europe, monde). Ces normes ont pour but de permettre
la réalisation de systèmes interopérables.
2 Besoins, solutions techniques
SIG
SIG
2.1 La diversité de la demande
Figure 3 : Echange de données et interopérabilité
La complexité de la problématique du transfert de données et la conséquence directe de
la diversité des applications.
Echangés ou demandés sont par exemple :
Une représentation graphique (cartes et plans sous forme digitale)
Une description du contenu de SIG (métadonnées)
Les résultats de requêtes (tables, cartes, etc.)
Le contenu d’une base de donnée structurée (par exemple des tables, des attributs)
sans changement de la structure de données
Les données d’une base de données vers une autre base de données avec une
structure différente
1.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

L’interopérabilité dans les SIG : besoins, stratégies, solutions techniques
Des objets entiers (opérations incluses) dans un environnement orienté objets
Ce petit extrait de demandes fréquentes de transfert de données donne déjà une bonne
vue d’ensemble de la diversité des besoins et de leurs complexités très différentes.
2.2 La diversité des solutions
Un SIG interopérable peut être réalisé selon différentes manières :
Transfert de données
o Echange de données entre systèmes identiques
o Echange de données avec formats standard
o Méthode de transfert de données basée modélisation
Interopérabilité
o Interopérabilité (selon l’OGC = Open Geospatial Consortium ; auparavant
Open GIS Consortium)
3 Le transfert de données au sens strict
3.1 Formats de transfert propriétaire : un besoin fondamental
La mise en service d’une application SIG, les démonstrations de vente, la première formation
de nouveaux usagers et les tests des producteurs pendant le développement du
logiciel nécessitent la prise en charge de données de démonstration d’une application à
une autre du même producteur de SIG. Ainsi tous les SIG permettent la sauvegarde de
données sous la forme de fichiers standard (en général des fichiers séquentielles) ainsi
que la lecture de ceux-ci. Les formats utilisés sont propres à un logiciel SIG donné (formats
propriétaires) et nécessitent chez l’expéditeur et le récepteur des structures de
données identiques pour le transfert de données.
SIG
SIG
Figure 4 : Transfert de données par format propriétaire
D’autres formats propriétaires, qui sont souvent devenus des standards de facto, sont
utilisés pour la sortie de représentations graphique (plottfiles) découlant d’informations
spatiales (cartes et plans). Les logiciels SIG comportent généralement les fonctions nécessaires
à la détermination et à la création de ces formats de données.
3.2 Formats standard
Le besoin d’échanger des géodonnées entre des systèmes de producteurs différents était
déjà reconnu auparavant, en particulier dans les grosses organisations (télécoms, sociétés
de chemin de fers, organisations militaires, etc.).
Pour de telles applications, nous avons à faire à des systèmes d’informations géographiques,
dans lesquels les informations sont gérées de façon homogène. C’est avant tout le
cas dans des organisations fortement hiérarchisées (OTAN, entreprises d’état, etc.).
Interopérabilité pour l'utilisation généralisée de la Géoinformation 1.3

L’interopérabilité dans les SIG : besoins, stratégies, solutions techniques
Si à la fois le contenu géométrique et la thématique ont été fixés, il est possible de définir
un format adapté qui permet la transmission de l’informations, et il est possible de créer
dans chaque systèmes l’interface appropriée pour la lecture et l’écriture de fichier de
transfert dans le format utilisé. Des exemples sont le format d’échange DIGEST de
l’OTAN (Digitial Geographic Information Exchange Standard) et le format NTF (National
Transfer Format) pour l’Ordnance Survey (OS) en Grande-Bretagne.
GIS SIG
Figure 5 : Transfert de données par formats standard
Un autre besoin très répandu est la mise à disposition de géodonnées pour des partenaires
qui ne les utilisent que de manière graphique sur leurs systèmes. Cette forme se retrouve
souvent chez les architectes et les ingénieurs civils qui utilisent des géodonnées
dans des systèmes DAO. Le standard de facto dans le domaine de l’infographie est actuellement
le DXF, un format dans lequel les différentes informations sont séparées en
couches (layers).
La plupart des producteurs SIG permettent l’exportation de données dans le format
DXF, mais aussi leur lecture. Néanmoins, il faut noter que seule une partie des informations
(principalement les graphiques) peuvent être représentés en DXF, ce qui implique
une perte d’information. Les conventions ou les normes qui définissent de façon homogène
l’affectation des couches et la numérotation sont très utiles.
Lorsque le projet de la réforme de la mensuration officielle suisse fut réalisé, on a constaté
avec souci que la détermination de structures de données homogènes pour les 26 cantons
était irréaliste. Par conséquent, la définition d’un format de transfert de données
était une tâche impossible.
La même chose s’est produite au niveau européen quelques années plus tard. Sur suggestion
de la France, le TC 287 du Comité Européen de Normalisation CEN fut créé, entre
autre pour mettre en vigueur des normes pour le transfert de données géographiques.
La Grande-Bretagne et la France ont proposé d’utiliser une version élargie (ETF)
de leurs formats (NTF et EDIGéO (Echange de Données Informatisées GéOgraphiques)).
Les premières réunions par la suite ont alors montré que les besoins différents, mais surtout
la diversité des applications et les contenus des systèmes, rendaient la détermination
d’un format impossible. Une autre solution technique était nécessaire. Lorsque des
structures de données différentes sont attendues, la tendance est à l’utilisation des méthodes
basées modélisation à la place de formats fixes.
3.3 Méthodes de transfert basées modélisation
De nos jours, les géoinformations proposent aux utilisateurs, à côté d’une structure de
données prédéfinie pour la géométrie, la possibilité de définir librement le contenu thématique.
Le système se base sur la description de la structure des données (information
contenue dans le schéma de la BD) pour créer les classes d’entités nécessaires (en géné-
1.4 Interopérabilité pour l'utilisation généralisée de la Géoinformation

L’interopérabilité dans les SIG : besoins, stratégies, solutions techniques
ral une table d’une base de données relationnelles). La gestion des données peut être
ainsi adaptée au besoin.
SIG
Figure 6 : Méthodes de transfert basées modélisation
Cette idée peut aussi être utilisée pour rendre le transfert de données flexibles : la structure
des données que l’on souhaite transférer est décrite, et de celle-ci est déduit un format
pour ces données. Pour cela, deux composants sont nécessaires : un langage standardisé
de description des données pour pouvoir décrire de façon unique et consistante
la structure des données à transférer, ainsi qu’une méthode normée pour déduire un
format à partir de la structure de données.
Détermination
du format
Figure 7 : Composants de la méthode de transfert basées modélisation
La norme EXPRESS avait été choisie comme norme européenne, puisqu’elle était déjà
répandues dans différents domaines (DAO, industries automobile, etc.). Des applications
dans le domaine géographique n’existent toutefois pas encore et la complexité de
la norme n’a pas favorisé son implémentation.
En Suisse, le langage INTERLIS a été défini il y a plus de 10 ans pour la mensuration officielle,
et permet la description de la thématique dans un SIG selon un modèle relationnel
et celle de la géométrie à l’aide d’éléments géométriques prédéfinis (points, lignes,
arcs de cercles, surfaces simples, répartitions du territoire). Ce langage disposait dès le
début d’un compilateur pour la détermination automatique du format de transfert.
Convenant très bien aux SIG actuels, il est de plus en plus employé. Actuellement il n’y
a aucune autre solution au niveau mondial qui puisse être considérée comme opérationnelle.
Dans le comité technique de l’ISO (TC 211), seul INTERLIS a pu être présenté
comme processus implémenté de transfert basé modélisation pour des géodonnées dans
un SIG.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 1.5

L’interopérabilité dans les SIG : besoins, stratégies, solutions techniques
L’ISO a jusque là décidé les points suivants :
Le transfert de données basé modélisation est défini comme standard
L’UML est défini comme formalisme graphique pour la description de structures
de données
Un langage textuel, dont la lecture et l’interprétation pourraient être automatisées,
est prévu. Ses propriétés ont été décrites et fixées, mais aucune autre décision
n’a été prise. Une solution possible est INTERLIS 2.
La Suisse a développé une nouvelle version d’INTERLIS (INTERLIS 2), pour assurer
une compatibilité avec les normes ISO (orientation objets, mise à jour incrémentielle,
etc.). Dans ce cadre, l’interface entre UML et INTERLIS a aussi été réalisée, afin qu’un
schéma UML puisse être traduit automatiquement dans INTERLIS et réciproquement.
De la même manière, le format de transfert a été défini selon le standard informatique
XML. Prochainement, un format de transfert sur la base du GML pourra être généré.
Les technologies basée modélisation proposent aussi une solution pour d’autres domaines.
Les SIG modernes permettent aujourd’hui l’implémentation de modèles directement
depuis le schéma conceptuel (à l’aide d’UML ou d’INTERLIS).
ArcGIS (ESRI) peut implémenter une structure de données à partir d’UML (produit
avec Microsoft Visio)
GeosPro/GeoMedia (a/m/t, Intergraph) à partir d’INTERLIS
Topobase (C-Plan) à partir d’INTERLIS ou d’UML
4 Interopérabilité
Alors que toutes les solutions présentées ci-dessus ont pour but de transférer les données
d’un système à un autre, des possibilités de communication sans déplacement des
géodonnées originales sont envisageables. Cette solution est particulièrement intéressante
si l’utilisation des informations requises reste simple (par exemple la représentation
graphique d’une zone, ou bien le listage d’un certains nombre d’objets). Dans ces
cas, il est plus simple de standardiser les requêtes et les réponses que de transférer les
données de base elles-mêmes.
L’interopérabilité signifie une utilisation en parallèle de différents SIG, dans lesquels les
commandes (requêtes) et les résultats correspondants (réponses) sont échangés (cf. figure
8).
1.6 Interopérabilité pour l'utilisation généralisée de la Géoinformation

L’interopérabilité dans les SIG : besoins, stratégies, solutions techniques
Réponse
Requête
Requête
Réponse
Figure 8 : Interopérabilité
Les industries de SIG (producteurs de logiciels) ont considéré cette idée comme intéressante,
et ont fondé l’Open Geospatial Consortium (OGC), afin de développer ce concept.
Grâce à la participation d’entreprises leader au niveau mondial (ESRI, Intergraph, Siemens,
Oracle, Microsoft, etc.) et à l’implication d’universités et d’institutions de recherches,
l’OGC a obtenu un grand succès, et éveillé des attentes importantes.
Les avantages du concept du point de vue de l’interopérabilité sont évidents :
Les concepts de gestion des données des systèmes communicants peuvent être
très différents.
Le système formulant la requête n’a rien besoin de connaître sur l’organisation
des données du système la recevant.
Les systèmes ne transmettent qu’une partie de l’information. Le contenu entier
reste sous contrôle (droits d’auteurs).
Un avantage pour les producteurs de SIG est le suivant :
Les clients n’ont pas la possibilité de changer facilement de systèmes.
De même, les limites du concept sont visibles : la diversité des requêtes standardisées et
des réponses ne peut pas être trop grande. Dans le cas d’interactions trop complexes,
trop vastes ou trop nombreuses, l’échange de données est plus simple et favorable que
la standardisation des opérations. Bien entendu, les systèmes doivent contenir des informations
comparables. Actuellement, l’OGC n’a prévu des solutions que pour des requêtes
de dénomination similaire (interopérabilité syntaxique).
En résumé, l’interopérabilité est intéressante lorsque :
les applications souhaitées sont d’un niveau peu complexe (par exemple représentation
graphique, listage d’objets ou d’attributs)
les systèmes à qui la requête est soumise sont en service en même temps
Interopérabilité pour l'utilisation généralisée de la Géoinformation 1.7

L’interopérabilité dans les SIG : besoins, stratégies, solutions techniques
5 Métadonnées
La présence toujours plus large de systèmes d’information géographique fait ressortir de
nouveaux problèmes : on ne sait pas quels sont les systèmes d’information géographique
disponibles et quelles sont leurs données. Des systèmes de métainformations permettent
de rendre ces informations disponibles, sous forme de métadonnées (données
sur les données). Ces systèmes sont à leur tour des systèmes d’informations géographiques
dont une partie des métainformations est spatiale (pour quelle région trouve-t-on
des données ? à quel endroit trouve-t-on ces données ?). Dans les métadonnées sont
comprises des informations sur la qualité, la disponibilité, les restrictions d’usage, les
coûts, etc. La description de la structure des données selon un langage particulier (EX-
PRESS, INTERLIS, UML, etc.) peut aussi en faire partie.
Les concepts pour la normalisation des métadonnées sont assurés par les normes ISO.
Dans le cadre des infrastructures de géodonnées nationales (NGDI) l’on définis des profils
nationaux (sous-ensembles), afin de rendre possible une interprétation unique.
Actuellement les métadonnées sont disponibles en consultation visuelle. Dans le futur,
elles devraient être utilisées automatiquement par les systèmes interopérables lors de la
recherche de données.
6 Les souhaits et la réalité
6.1 Les souhaits
Les descriptions optimistes des différents concepts de transfert de données pourraient
faire croire, qu’avec un peu de patience et d’argent, le problème de l’échange automatique
de données géographiques entre deux systèmes quelconques pourrait très prochainement
être réalisable.
SIG SIG SIG
Figure 9 : L’interopérabilité entre systèmes quelconques avec des structures de données
quelconques est souhaitée.
Cela correspond bien évidemment à ce que l’on souhaite, à savoir l’accès et une utilisation
commune des informations précieuses qui se trouvent à différents endroits.
1.8 Interopérabilité pour l'utilisation généralisée de la Géoinformation

L’interopérabilité dans les SIG : besoins, stratégies, solutions techniques
6.2 Limites techniques
Figure 10 : En général, l’affectation des attributs séparés ne peut pas être automatisée
Ni un transfert de données totalement automatisé, ni l’utilisation commune de données
de systèmes avec structures de données indépendantes n’est possible. La frontière insurmontable
réside dans la sémantique non standardisée de la description de la structure
des données.
Les exemples ci-après illustrent des cas répandus.
Le système formulant la requête identifie une classe thématique d’élément avec le terme
‚MAISON’, alors que le récepteur défini la même classe par ‘BÂTIMENT’. Bien évidemment,
les langues étrangères et les abréviations sont des obstacles supplémentaires
pour une interprétation automatique. La situation inverse peut aussi avoir lieu. Des
termes identiques peuvent représenter des objets différents dans deux systèmes qui
communiquent. Dans un système, le terme ‘VOIE’ correspond aux voies de communication
en général (chemin de fer, route, navigation fluviale, etc.), alors que dans un autre
‘VOIE’ correspond uniquement aux voies de chemin de fer. Encore plus fréquents sont
les cas où les éléments thématiques ont à la fois une affectation différente, et une autre
répartition selon la signification.
La sémantique de la description des données ne peut pas être standardisée dans un environnement
libre. Pour l’affectation des entités et des attributs, des informations supplémentaires
sont nécessaires. Il est à noter que l’affectation est dépendante de la signification
de l’objet et de ses attributs. L’affectation dépend aussi des directives internes et
des règles d’acquisition des données. Aucun homme ni ordinateur n’est capable de déterminer
sans informations supplémentaires l’affectation des entités et des attributs. Des
renseignements supplémentaires ou une lecture des descriptions détaillées sont nécessaire
pour mettre en relation les différents champs de données.
Cette affectation doit être réalisée la première fois à l’aide de :
L’analyse d’un expert
Des demandes auprès des responsables
La consultation de métadonnées
Interopérabilité pour l'utilisation généralisée de la Géoinformation 1.9

L’interopérabilité dans les SIG : besoins, stratégies, solutions techniques
Ce n’est qu’après cela qu’une transformation sémantique automatique pourra être effectuée.
Les producteurs de SIG ont développés des modules pour le transfert de données basé
modélisation, qui permettent la visualisation à l’écran des structures de données (par
exemple selon leur description dans INTERLIS) et de l’affectation des classes d’entités et
des attributs de façon interactive. Des développements ultérieurs dans cette direction,
mais cette fois-ci concernant le niveau conceptuelle (transformations sémantiques, interopérabilité
sémantique), devraient voir le jour.
Ontologie
Agent
Agent
Figure 11 : Transformations sémantiques à l’aide de l’ontologie
Entre des systèmes fédérés (organisés selon des règles communes) il sera possible dans
des domaines spécifiques de développer des ontologies, décrivant la sémantique de plusieurs
systèmes, pour permettre de développer des modules de transformation automatiques
(agents).
Les ontologies sont des objectifs actuels de la recherche. Toutefois, la description univoque
de la sémantique ne sera possible que dans des secteurs clairement définis et limités.
Une ontologie correspond à une standardisation de concepts employés pour la construction
de modèle et pour la désignation des éléments d’une structure de données dans un
SIG.
7 Stratégie de développement
Les solutions décrites jusque là sont toutes en soi, malgré les limites techniques évoquées,
des réponses optimales aux besoins variés. Il ne faut donc par conséquent pas
s’attendre à ce qu’une seule solution en particulier s’impose comme standard mondial
pour le transfert de données géographiques :
Les formats propriétaires feront toujours partie des logiciels SIG. Ils sont une solution
optimale pour la gestion de systèmes. Ils transfèrent les données de manière
intégrale (y compris les paramètres de configuration) pour un système
1.10 Interopérabilité pour l'utilisation généralisée de la Géoinformation

L’interopérabilité dans les SIG : besoins, stratégies, solutions techniques
donné. Ils peuvent aussi servir pour l’échange de données à l’intérieur de grandes
organisations, qui utilisent plusieurs systèmes identiques.
Les formats standard sont utilisés lorsque le contenu des SIG est fixé par une autorité
centrale. Pour des structures de données fixées, un format peut être définit,
avec lequel les données peuvent être transmises séquentiellement. Les formats
de données sont également une solution appropriée pour le transfert de données
d’un SIG à un système de DAO. Le DXF est le plus répandu dans le domaine des
DAO. Une norme concernant les couches est appréciée dans ce domaine.
Les méthodes de transfert basées modélisation représentent la solution pour
l’échange de données entre systèmes ayant leur propre structure de données. Les
données entrantes contiennent la description de la structure de données dans un
formalise normé (langage de description de données). Le langage doit être complété
par les procédés nécessaires à une détermination univoque des formats correspondants.
Si la structure des données reçues n’est pas identique à celle du système
destinataire, un transfert complètement automatique ne peut pas avoir lieu.
L’affectation des classes d’entités et des attributs doit être faite la première fois
par une personne humaine. Pour faciliter ce travail interactif, les producteurs de
logiciels ont développé des modules qui comparent les structures de données et
permettent l’affectation des champs des tables à l’écran (par exemple INTERLIS
Studio de Leica).
Figure 12 : Lors du premier transfert de données, la relation entre les attributs doit être définie.
L’interopérabilité est l’alternative qui permet la communication entre deux SIG
sans échange de géodonnées. Les requêtes et les formats de transfert pour les réponses
(Services Interfaces) sont normés. L’étendue réelle des possibilités qui seront
définies dans le cadre des travaux de l’OGC n’est que difficilement prévisible.
Actuellement, des requêtes simples (visualisation, sélection) ainsi que l’accès
à des objets géographiques simples sont déjà spécifiés. Le but du consortium
OGC n’étant pas seulement une communication entre systèmes, mais aussi
l’imbrication de fonctionnalités SIG indépendantes, il faudra aussi définir l’interface
entre les modules des logiciels. Le temps nécessaire pour atteindre ces objectifs
n’est pas déterminable, ni même si l’on pourra réellement les atteindre.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 1.11

L’interopérabilité dans les SIG : besoins, stratégies, solutions techniques
8 Conclusion
La communication entre systèmes d’information géographique est une tâche variée et
complexe, pour laquelle existent de nombreuses possibilités. Les problèmes, les attentes
et les limites techniques ne sont que depuis peu perçus dans leur intégralité. Les méthodes
actuelles de transfert de données et l’interopérabilité vont se développer fortement
dans les prochaines années. Plusieurs méthodes vont sans doute s’imposer comme standard.
Les prochaines étapes dans la recherche sont à attendre dans les domaines de
l’interopérabilité et des transformations sémantiques.
Ces travaux sont les conditions préalables pour que les systèmes d’information géographiques
puissent mettre à disposition de toute la société leurs données précieuses, sans
retard ni obstacle.
1.12 Interopérabilité pour l'utilisation généralisée de la Géoinformation

2
Vue d’ensemble
Urs Flückiger, Groupe de travail de l’OSIG sur les
technologies SIG
Urs Flückiger
ESRI Geoinformatik AG
Beckenhofstr. 72
CH-8006 Zürich
Tél :
Fax :
E-mail :
+41 1 360 24 60
+41 1 360 24 70

Le présent texte a pour objet de proposer au lecteur une vue d’ensemble dans le domaine
des normes et des standards nationaux et internationaux dans le contexte global
de l’« Interopérabilité pour l’utilisation généralisée de la Géoinformation ». Au contraire
des exposés suivants, la présente introduction à la thématique des journées d’étude
n’abordera pas les points soulevés en détail, certains des thèmes développés par
d’autres intervenants étant toutefois utilisés ici à titre d’exemples.
Que recouvre exactement la notion d’interopérabilité ? Elle désigne la capacité d’un système
et l’autorisation qui lui est accordée pour travailler en bonne intelligence avec
d’autres systèmes d’origines différentes dans des limites prédéfinies. L’interopérabilité
résulte de spécifications et de normes. On la retrouve à différents niveaux technologiques.
Les normes apportent-elles une contribution à l’interopérabilité ? Les normes rendent
l’existence plus facile dans un monde en réseau. Bien rares sont les cas dans lesquels les
données ne sont saisies que pour un bref moment et ne sont conservées qu’au sein d’un
seul système. C’est pourquoi l’élaboration et l’adoption de normes constituent des tâches
d’une grande importance. Les normes facilitent l’interconnexion et aplanissent les
obstacles technologiques entravant la collaboration.
Existe-t-il un marché pour les normes ? Différents groupements y travaillent. Le bénéfice
en est très variable mais tous les intervenants en tirent avantage, d’une manière ou
d’une autre.
1 Normalisation
1.1 Définition de la normalisation
Selon l’Institut allemand de normalisation (DIN), la normalisation consiste en
l’uniformisation méthodique d’éléments matériels et immatériels conduite par des cercles
intéressés au profit de la collectivité. Le résultat de cette opération est une prescription
technique appelée norme (« standard » en anglais). Une « norme de droit » (ou
simplement une norme) est une prescription technique de ce type établie par des associations
de normalisation nationales ou internationales. Une « norme de fait » est une
prescription technique largement reconnue et mise en pratique par le plus grand nombre,
découlant de la diffusion étendue d’un produit, établie par l’utilisation exclusive au
sein d’une entreprise (standard ou norme de l’industrie), par des communautés
d’intérêts ou des consortiums nationaux ou internationaux. Les normes de droit et de
fait ne présentent un caractère obligatoire et ne sont à mettre en application par les personnes
physiques et morales que lorsque leur respect est exigé par le biais de dispositions
légales ou contractuelles.
Les normes, en particulier celles relatives à la documentation (métadonnées), à la modélisation
(langage de description unifié) ou à l’échange de données (mécanisme
d’obtention et format de données) accroissent la flexibilité, la fonctionnalité et la productivité
d’un système d’information.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 2.1

Standards nationaux et internationaux
Vue d’ensemble
Type Norme (instance initiatrice) Norme de fait (inst. initiatrice)
Systèmes d’exploitation Unix, Linux (ANSI) Windows 2000 (Microsoft)
Base de données
SQL-92 (ISO)
Format de données
XML (W3C), ITF (SNV)
DXF (AutoCAD), fichier Shape
(ESRI)
Langages de programmation C++ (ANSI)
Java (Sun), Visual Basic (Microsoft)
Services Internet
HTTP (ISO), SOAP, UDDI
J2EE (SUN Microsystems),
WSDL (W3C)
Information géographique
ISO 19115 Métadonnées
(ISO)
WMS (OGC)
Spécifique à une association
Norme SIA 405 (SIA)
Tableau : exemples de normes (de droit) et de normes de fait
1.2 Organisations de normalisation
1.2.1 Organisations de normalisation de droit
Organisation internationale de normalisation (ISO)
L’ISO est l’association internationale de normalisation et son domaine de compétence
s’étend aux activités commerciales et industrielles, à l’administration et à la société. Les
organisations membres peuvent adopter les normes ISO.
Exemples de normes ISO :
ISO 19103 Geographic Information – Conceptual Schema Language
ISO 19115 Geographic Information – Metadata
ISO 19119 Geographic Information – Services
ISO 19136 Geographic Information – Geography Markup Language
ISO 19139 Geographic Information – Metadata – Implementation Specification
TC211 est le comité technique n°211 de l’ISO, en charge des secteurs de l’information
géographique et de la géomatique. Ce comité élabore la série des normes ISO 19100, laquelle
regroupe les normes les plus diverses en matière de géodonnées (Metadata, Spatial
Schema, Spatial Reference, Application Schema, Conceptual Schema Language,
Quality, Encoding, Catalog ...).
Le comité ISO TC211 et l’Open Geospatial Consortium (OGC) collaborent et s’apportent
un soutien mutuel. Une spécification de l’OGC correspond à un niveau de la série des
normes 19100 de l’ISO. Les buts poursuivis dans le cadre de cet accord sont les suivants :
les produits conformes à l’OGC sont (quasiment) conformes aux normes établies
par le TC211 de l’ISO
l’amélioration des standards de l’OGC et des normes du TC 211 de l’ISO
le développement et la vérification plus rapides de spécifications dans un environnement
de test et dans le cadre de projets pilotes
la prise en compte des conditions prévalant sur le marché.
Comité européen de normalisation (CEN)
Le comité européen de normalisation (CEN) va vraisemblablement décider d’adopter en
grande partie la série des normes ISO 19100. Les membres du CEN se sont engagés à
ratifier les normes du CEN.
2.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Standards nationaux et internationaux
Vue d’ensemble
Association suisse de normalisation (SNV)
La SNV étant membre du CEN, elle est dans l’obligation d’adopter les normes du CEN
et par suite, les normes ISO lorsque celles-ci sont adoptées par le CEN. Cela implique
que toute norme suisse présentant des contradictions avec des normes CEN ou ISO devrait
très probablement être supprimée. Les « géonormes » suisses ayant été développées,
implémentées et testées pour répondre à des besoins concrets, la Suisse éprouve le
plus vif intérêt à ce que les normes internationales en matière d’information géographique
éventuellement à adopter répondent à ses besoins et à ce que leur utilité pratique
puisse être examinée dans le cadre d’une implémentation. C’est à cela qu’oeuvrent les
représentants de la Suisse dans les différentes instances concernées, avec un succès
croissant.
On s’efforce également en Suisse, avec une réussite équivalente, de procéder à
l’adaptation progressive des normes existantes et éprouvées aux développements les
plus récents intervenus dans les domaines des technologies de l’information et des normes
relatives aux informations géographiques.
Exemples de normes de la SNV :
SN 612 030 et SN 612 031 : INTERLIS – langage de modélisation et méthode de
transfert de données
SN 612 040 : Adresses de bâtiments
SN 612 050 : Modèle de métadonnées GM03
1.2.2 Organisations de normalisation de fait
Open Geospatial Consortium (OGC)
Des producteurs de SIG de premier plan, des producteurs de données, des administrations,
des organisations et des instituts de recherche se sont réunis en 1994 pour fonder
l’Open Geospatial Consortium (OGC) dans le but de définir des interfaces de logiciels
« ouvertes » indépendantes des producteurs, de favoriser la standardisation des techniques
de SIG et de promouvoir la technologie SIG. Les normes de fait visées doivent
permettre à un large cercle d’utilisateurs de pouvoir accéder simplement aux services
proposés par des prestataires. Un large recours à des composants logiciels interopérables
et immédiatement disponibles (components off the shelf) est préconisé, de même
que l’intégration complète du traitement des géodonnées avec les technologies de
l’information usuelles ainsi que le passage des géodonnées à des services d’informations
géographiques. Les spécifications de l’OGC sont généralement des démarches pragmatiques
ayant l’aptitude au fonctionnement pour objet principal.
Exemples de spécifications de l’OGC :
« OpenGIS Simple Feature Specification (SF, approved) »
« OpenGIS Geography Markup Language (GML, approved) »
« OpenGIS Web Map Server Specification (WMS, approved) »
« OpenGIS Web Feature Server Specification (WFS, approved) »
Service Discovery
Service Description
W3C
Le groupement « World Wide Web Consortium » a été fondé pour ouvrir l’accès à toutes
les possibilités offertes par Internet. Des technologies unifiées (spécifications, directi-
Interopérabilité pour l'utilisation généralisée de la Géoinformation 2.3

Standards nationaux et internationaux
Vue d’ensemble
ves, logiciels et outils) sont développées à cet effet, favorisant le progrès d’Internet tout
en garantissant son interopérabilité.
Les produits principaux dus à W3C sont constitués par de nouvelles recommandations
devant être examinées par les membres puis obtenir leur approbation avant de devenir
des normes de fait pour des protocoles et des applications. L’objectif de cette démarche,
qui est de recueillir un consensus aussi large que possible, est atteint en soumettant chaque
spécification à une procédure clairement définie (dite « Recommendation Process »).
Le but de W3C est de conduire Internet (WWW) à son plein déploiement, en tant que
système de liaison fiable d’ordinateur à ordinateur, qu’interface performante entre
l’homme et la machine et comme moyen de communication efficace entre les hommes.
Afin d’atteindre cet objectif, l’équipe d’experts de W3C travaille en étroite collaboration
avec ses membres dans les cinq domaines suivants :
Architecture Domain (DOM, Jigsaw, XML, XML Protocol, URI)
Document Formats Domain (HTML, Style Sheets, Math, Graphique, Internationalisation,
Amaya)
Interaction Domain (Device Independence, Applications multimédias synchronisées,
Voice Browser)
Technology and Society Domain (Signatures numériques, Métadonnées, Argent
électronique, Protection et sécurité des données)
Web Accessibility Initiative
2 Interopérabilité
La communication entre systèmes d’information différents, indépendante de tout système,
est rendue possible par des interfaces et des formats normalisés ; c’est cette capacité
à communiquer que recouvre la notion d’interopérabilité. Elle permet l’accès simple à
différentes ressources de données (également géoréférencées) et de traitement au sein
d’un processus de travail ou via l’interconnexion directe de différents systèmes. Cette
symbiose entre systèmes et données permet l’utilisation de nombreuses données différentes
en un même lieu et le cas échéant la publication de ces informations.
L’interopérabilité, résultant de spécifications et de normes, est le fondement des infrastructures
informatiques, autrement dit des systèmes répartis pour une solution
d’entreprise globale.
L’interopérabilité se retrouve à différents niveaux.
Niveau Caractéristiques Notions
Acceptation de clients de type
Présentation
J2ME
« thin » ou « fat »
Services
Logique
d’application
Données, formats
Plateforme
Interopération et ouverture :
recours aux normes (Internet, TI,
SIG)
Intégration et conformité TI (API)
Echange et protection de
l’investissement
Indépendance vis-à-vis des
plateformes
HTTP, XML, SOAP, J2EE, UDDI ;
OGC : WMS, WFS
.net, COM, Java SOAP, GML/XML,
C++, VB
DXF, DGN, SHP, OGC SF, INTERLIS,
GML, DBMS OS, PNG, JPG
Unix (SUN, IBM, HP), DOS,
Windows, Mac, Linux ; DBMS
(Oracle, SQL, DB2, Informix) ;
WebServer (IIS, Websphere, Apache)
2.4 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Standards nationaux et internationaux
Vue d’ensemble
3 Analyse sommaire du marché
D’une façon générale, les normes rendent l’existence plus facile dans un monde en réseau.
Bien rares sont les cas dans lesquels les données ne sont saisies que pour un bref
moment et ne sont conservées qu’au sein d’un seul système. C’est pourquoi
l’élaboration de normes constitue une tâche d’une grande importance. Mais qui s’y attelle
?
Selon les règles du marché, l’offre doit être adaptée à la demande. Car seules les normes
présentant un bénéfice clairement identifiable pour les utilisateurs parviendront à
s’imposer. Pour qui la normalisation est-elle alors source d’avantages ?
Les réponses apportées ici à ces deux questions ne sont pas définitives :
La normalisation est l’affaire de différentes organisations ou instances. Les organisations
spécialisées dans la normalisation (ISO, CEN, SNV) ou encore l’OGC ont déjà été
mentionnées. Outre les commissions techniques (par exemple TC211 ou TK151),
d’autres instances ou associations professionnelles (par exemple eCH, sia) s’intéressent
également à la normalisation. Les associations professionnelles sont en particulier invitées
à analyser l’aptitude des normes en cours d’élaboration à être utilisées de façon satisfaisante
en pratique par leurs membres.
EUROGI (European Umbrella Organisation for Geographic Information) entend maximiser
le recours aux informations géographiques au profit des citoyens, des gouvernements
et du commerce en Europe tout en se faisant le porte-parole de la communauté de
l’information géographique. Elle compte atteindre ses objectifs par la promotion, la stimulation
et l’assistance apportées au développement et à l’utilisation des informations
géographiques et des technologies associées.
Le réseau de contact suisse e-geo.ch a été initié en vue de favoriser la mise en place
d’une INDG et d’améliorer le partenariat entre les pouvoirs publics, les organisations et
le secteur privé. L’interopérabilité est impérative pour la mise en pratique de ces deux
initiatives et des normes judicieuses, aisées à appliquer, constituent un précieux avantage
pour la réalisation de ces objectifs.
Les constructeurs sont appelés à implémenter les normes exigées par le marché. Le
client comme le constructeur en tirent profit puisque de nouvelles possibilités et de
nouveaux segments de marchés s’ouvrent à eux.
Les producteurs de données souhaitent rendre leurs données accessibles à un public
aussi large que possible. Leur mise à disposition dans un format normalisé réduit considérablement
le volume de travail requis puisque les données n’ont plus à être préparées
dans des formats propriétaires différents selon les producteurs de SIG. Différentes études
ont établi que des données géographiques de base aisément accessibles étaient la
source d’un bénéfice économique élevé pour le secteur privé comme pour
l’administration publique (cf. INDG de la Confédération).
L’utilisateur n’aura pas à se préoccuper de ces aspects en détail mais devra toutefois
s’informer de façon à pouvoir exiger le respect des normes requises lorsqu’il est mandant
ou mettre en pratique les normes adéquates lorsqu’il est mandataire. Les investissements
consentis devront enfin être pérennisés.
L’élaboration et l’adoption de normes constituent des tâches d’une grande importance.
Les normes facilitent l’interconnexion et aplanissent les obstacles technologiques entravant
la collaboration. Le groupe de travail de l’OSIG sur les technologies SIG a analysé
Interopérabilité pour l'utilisation généralisée de la Géoinformation 2.5

Standards nationaux et internationaux
Vue d’ensemble
les avantages inhérents aux résultats des travaux de l’OGC, de l’ISO et de la SNV pour
les utilisateurs de SIG en Suisse :
Description OGC ISO SN
Gain de productivité pour les entreprises et les administrations via
l’utilisation d’interfaces logicielles normalisées.
X - e
Gain de productivité pour les entreprises et les administrations via
l’utilisation de formats d’échange et de mécanismes normalisés.
e e X
Bénéfice dû à l’emploi de technologies logicielles spécifiques disponibles
immédiatement.
X - X
Protection des investissements (indépendance vis-à-vis des plateformes) ? e X
La Suisse n’est plus une île en matière de normalisation. X X X
Meilleur contrôle des données. - e X
Des directives clairement définies pour les appels d’offres via le respect
impératif du format de données de livraison, d’où une égalité des chances - - X
pour tous les soumissionnaires.
Dans le cas de projets transfrontaliers, les normes nationales propriétaires
(c.-à-d. sans lien avec les normes internationales) ne sont pas utilisées. Les
normes internationales ouvrent la voie menant à une obtention ou à un
e e e
échange réglementé des données.
La normalisation s’effectue à un niveau indépendant de tout système, tant
pour la modélisation que pour les données.
? X X
Les intervenants parlent tous le même « langage ». - ? X
Tableau. : X bénéfice effectif, e bénéfice à attendre /promis, ? bénéfice flou, - absence de bénéfice
Il a été tenté, dans un rapport de swisstopo, d’évaluer les économies concrètement réalisées
grâce à la mise en œuvre judicieuse des normes suisses (rapport 17,
www.swisstopo.ch). Il y est question d’un potentiel de l’ordre de quelques millions de
francs suisses par an. Un autre rapport cite une valeur de 3% pour les économies dues
au recours à des outils et à des processus de travail normalisés
(www.cgey.com/gcicase) ; ce pourcentage pourrait être bien supérieur dans le domaine
des SIG. Toutefois, le bénéfice complémentaire résultant du traitement normalisé des
informations géographiques est tout aussi important que les économies réalisées.
Le jeu de la concurrence semble d’importance secondaire ici, au contraire des marchés
traditionnels. Les organisations ont à collaborer entre elles dans les domaines dans lesquels
des chevauchements sont à constater au niveau thématique et à harmoniser leurs
normes en conséquence. Et c’est déjà le cas actuellement. Les standards de l’OGC tels
que WFS ou WMS sont adoptés en l’état par l’ISO ou adaptés au sein de normes correspondantes.
L’inverse est également vrai, à savoir que l’OGC peut adopter des normes
ISO en tant que standards. D’autres organisations telles que le FGDC collaborent plus
étroitement avec l’ISO et l’OGC. Il en découle un moindre volume de travail pour les
organisations et une plus grande capacité à s’imposer. C’est également plus simple pour
les développeurs, les producteurs et les utilisateurs.
2.6 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Standards nationaux et internationaux
Vue d’ensemble
Références bibliographiques
OSIG GT Technologie SIG (2003) : « Worin liegt der praktische Nutzen von Interoperabilität
und Normung für den GIS-Anwender in der Schweiz? »
OSIG GT Technologie SIG (2005) : « Geo-Webdienst »
URL
CEN, Comité européen de normalisation (www.cenorm.be)
INTERLIS (www.interlis.ch)
ISO (www.iso.org)
ISO TC/211 (www.isotc211.org)
COSIG (www.cosig.ch, www.e-geo.ch)
OGC (www.opengis.org)
Glossaire en ligne (www.integis.ch)
Association suisse de normalisation SNV (www.snv.ch)
OSIG (www.osig.ch)
TC211 – OGC coordination group (www.opengis.org/iso)
Interopérabilité pour l'utilisation généralisée de la Géoinformation 2.7

3
Standards informatiques
(UML, XML, SOAP)
Christine Giger, EPF Zurich
Christine Giger, Prof. Dr.
Eidg. Technische Hochschule Zürich
Institut für Geodäsie und Photogrammetrie
ETH Hönggerberg
CH-8093 Zurich
Tél :
Fax :
E-mail :
+41 1 633 30 51
+41 1 633 11 01

4
Interactions entre les géonormes
mondiales, européennes et suisses
Hans Rudolf Gnägi, EPF Zurich
Hans Rudolf Gnägi
Eidg. Technische Hochschule Zürich
Institut für Geodäsie und Photogrammetrie
ETH Hönggerberg
CH-8093 Zurich
Tél :
Fax :
E-mail :
+41 1 633 30 60
+41 1 633 11 01

5
Open Geospatial Consortium OGC
GML, WMS et WFS
Adrian Annen, Fachhochschule beider Basel
(FHBB), Abt. Vermessung und Geoinformation
Adrian Annen
Fachhochschule beider Basel
Abteilung Vermessung und Geoinformation
Gründenstrasse 40
CH-4132 Muttenz
Tél :
Fax :
E-mail :
+41 61 467 44 68
+41 61 467 44 60

1 Résumé
L’Open Geospatial Consortium OGC est un consortium industriel dont le but est
d’améliorer l’interopérabilité des géodonnées. Les abréviations GML, WFS et WMS,
utilisées fréquemment en rapport avec l’OGC, sont des désignations pour des mécanismes
d’échanges de géodonnées qui sont « ouverts » et indépendants des systèmes.
Pour le Geography Markup Language (GML) il s’agit d’une application basée sur le
XML pour la modélisation et l’échange de géodonnées. Le GML est entre autre utilisé
pour différents services Internet. Par exemple le Web Feature Service (WFS) qui permet
l’échange et la manipulation de données sur Internet, alors que le WMS a un résultat
en général purement graphique. Jusqu’à présent la spécification WMS est
l’application de l’OGC qui a le plus de succès.
2 Introduction
Dans le domaine de la géoinformation, des abréviations telles que OGC, GML, WMS et
WFS sont fréquemment utilisées en rapport avec la notion d’interopérabilité. Une organisation
(l’Open Geospatial Consortium) bien établie s’est formée dans ce domaine dès
le début des années quatre-vingt-dix, s’efforçant de créer des interfaces indépendantes
des systèmes et de ce fait d’augmenter globalement la disponibilité des géodonnées en
se fondant sur des standards existants du monde informatique. Le XML par exemple
sert comme base pour pratiquement toutes les spécifications de l’OGC.
Une spécification appliquée avec succès est le Web Map Service (WMS). Celle-ci a été
implémentée avec succès par divers fabricants et par plusieurs projets OpenSource.
Le standard le plus important est le Geography Markup Language (GML). Le GML met
à disposition un mécanisme pour la modélisation et l’échange de géodonnées orientées
vecteur. Les spécifications Web Feature Services (WFS) sont un exemple pour un tel service.
Dans les chapitres suivants, l’OGC et les spécifications mentionnées ci-dessus vont être
présentés. Seule une petite partie des multiples travaux de l’OGC seront résumés ici. De
plus amples informations sont disponibles le site www.opengeospatial.org.
3 Open Geospatial Consortium (OGC)
3.1 Qu’est-ce l’OGC?
L’Open Geospatial Consortium (OGC) est un consortium international industriel qui se
compose de plus de 270 entreprises, administrations et hautes écoles qui se sont fixés
comme objectif de développer de manière consensuelle des spécifications d’interfaces
publiques. Les spécifications de l’OGC soutiennent des solutions interopérables telles
que Web, applications mobiles, Location Based Services (LBS) ainsi que des solutions
informatiques en général, afin de leur ajouter une référence spatiale. Avec les spécifications
de l’OGC, les développeurs devraient être capables de rendre des géoinformations
complexes et les services se basant sur celles-ci accessibles à une variété d’usagers et
d’applications.
L’OGC est financée en premier lieu par les cotisations de ses adhérents. Actuellement il
existe huit différentes catégories de membres. Elles se différencient par les cotisations
annuelles (de 300$ jusqu’à plus de 50'000$ par année), mais aussi par les droits et les
obligations.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 5.1

Standards nationaux et internationaux
Open Geospatial Consortium OGC (GML, WMS et WFS)
OpenGIS® est une marque protégée de l’Open Geospatial Consortium, Inc. et sert en
même temps comme nom de produit pour les spécifications et les documents qui sont
établis et publiés par l’OGC.
3.2 Historique
Les événements les plus importants dans l’histoire de l’OGC peuvent être résumés de la
manière suivante :
Année Date-clé
Diverses activités autour du projet Open Source GRASS (Geographic
1980-89
Resource and Analysis Support System)
Fondation de l’Open GIS Consortium, Inc.
1994
Nombre de membres fin 1994 : 20
Publication du OpenGIS Web Map Server Interface Specification et du
1999 contrat de collaboration entre ISO/TC 211 et OGC
Nombre de membres fin 1999 : 182
Changement de nom en Open Geospatial Consortium, Inc.
2004
Nombre de membres fin 2004 : 272
En janvier 2005, il existait 17 Abstract Specifications et 14 Implementation Specifications.
En plus, d’innombrables Recommendation Papers et d’autres projets ont été publiés.
4 Geography Markup Language (GML)
4.1 Qu’est-ce que le GML?
Le Geography Markup Language (GML) est un langage utilisant la grammaire XML,
développé par l’Open Geospatial Consortiums (OGC) pour la modélisation, l’échange et
la sauvegarde de géodonnées. Les objectifs les plus importants de GML sont :
Le soutient de champs d'applications aussi larges que possible (des données non
spatiales peuvent être aussi représentées)
GML comme base d’applications pour des SIG Internet
Une syntaxe de géodonnées et leurs relations faciles à comprendre
Une syntaxe efficace de la géométrie
La séparation des données de leurs présentations
Intégration facile de données non-spatiales déjà existantes en XML
Possibilité de relier différents jeux de données
Mise à disposition d’un ensemble d’objets géométriques de base
Ces objectifs sont visés à l’aide d’une documentation riche et variée. La version actuelle
(3.1) de la spécification GML contient environs 600 pages.
4.2 Domaine d’application
Un des buts les plus important est l’utilisation universelle de GML comme format de
données pour un certain nombre d’applications géoréférencées. Les domaines
d’applications principaux de GML sont :
Une base pour des applications SIG Internet
Echange de données entre différents systèmes SIG (p.ex. Web Feature Service,
WFS)
Une base pour des Location Based Services (LBS)
5.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Standards nationaux et internationaux
Open Geospatial Consortium OGC (GML, WMS et WFS)
4.3 Concept
La conception de GML se fonde sur Feature-Model de l’OGC. D’après la définition de
l’OGC un ‘Feature’ est composé d’un objet avec un certain nombre de propriétés (‘Properties’).
Chaque propriété se caractérise par son nom, son type et sa valeur.
Si au moins une propriété d’un type d’un Feature est géométrique, on parle alors d’un
Feature géographique. Plusieurs Features peuvent être rassemblés dans une Feature
Collection. Une Feature Collection peut elle-même représenter à nouveau un Feature, de
sorte qu’il est possible de modeler une imbrication aussi profonde que l’on souhaite.
Figure 1 : Concept de base GML
La version GML 3 est définie dans environ 30 XML Schema Document (schémas de
base). Pour une application concrète de GML il faut déduire un schéma d’application
spécifique, qui se fonde sur les classes définies dans les schémas de base. Dans le schéma
d’application, des Features particuliers peuvent être définis avec des propriétés
d’applications spécifiques. Ceci peut être atteint par élargissement ou par restriction des
classes existantes.
4.4 Relation avec l’ISO
L’OGC s’efforce d’adapter ses concepts à ceux de l’ISO (International Organization for
Standardization). Pour cela, il est prévu d’harmoniser la spécification GML de l’OGC
avec la norme ISO 19136 (Geography Markup Language GML). La norme ISO 19136 est
actuellement dans le 'Commitee Stage' (état janvier 2005). Cela signifie que le Technical
Commitee (TC) de l’ISO concerné s’occupe des spécifications. Dans ce cas, c’est le TC
211 de l’ISO qui est responsable. Pour des informations plus détaillées veuillez consulter
le site de l’ISO (www.iso.org).
5 Les Web Services de l’OGC
5.1 Objectif
De grandes quantités de données se trouvent réparties dans de nombreux endroits, dans
des formats propriétaires. L'utilisation de ces données à partir de systèmes étrangers
n'est que difficilement réalisable, voire impossible. Des Web Services offrent une solution
en accédant à des sources de données réparties sur Internet. A côté des grands fabricants
de SIG qui offrent de telles solutions, il y a aussi des projets OpenSource, qui
mettent ces fonctionnalités à disposition. Le lien entre des services différents reste encore
non résolu (solutions isolées). C’est le point de départ des Web Services de l’OGC.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 5.3

Standards nationaux et internationaux
Open Geospatial Consortium OGC (GML, WMS et WFS)
Ils définissent des méthodes, une série de paramètres ainsi que les règles de communication
qui permettent à un système donné l'accès à des bases de données distribuées, pour
autant que les deux composantes disposent d’une interface identique.
5.2 Le principe de base
L’OGC a défini dans l’OWS (OGC Web Service) Common Implementation Specification
les points communs de leurs différents Web Services. L'expression Web Services décrit
la façon de standardiser l'intégration d'applications basées sur des réseaux. Le XML est
utilisé pour la définition et la description des applications. La communication se base
sur des protocoles Internet. Par l'application de le XML, les Web Services ne sont pas liés
à un certain système d’exploitation ou à un certain langage de programmation.
Figure 2 : Schéma de fonctions des Web Services de l’OGC
Le modèle de fonctionnement illustré dans la figure 2 représente les fonctions suivantes:
1. Le client prend contact avec le serveur et demande des documents de Capabilities
2. Le serveur livre au client des Capabilities au format XML (description du caractère
fonctionnel) du service souhaité
3. Le client demande des données au serveur
4. Le serveur livre les données dans le format demandé
Ces quatre étapes forment le fonctionnement de base d'un service d’après les spécifications
de l’OGC. D'autres interactions entre clients et serveurs sont possibles selon le service,
par exemple la consultation d'autres informations d’un Feature, d’une couche de
carte etc.
Les Web Services communiquent ensemble (conformément à leur définition) à l'aide de
protocoles Internet donnés. La plupart des OGC Web Services utilisent pour le moment
le protocole HTTP. L’Hyper Text Transfer Protocol (HTTP) dispose d'un modèle d'interaction
très simple entre le client et le serveur qui se compose d'une demande (Request)
envoyée par un client à un serveur et d'une réponse (Response) envoyée par le serveur
au client.
5.3 Le Web Map Service (WMS)
Le WMS-Specification décrit une interface sur laquelle des cartes georéférencées peuvent
être mise à disposition. Le service est composé de trois opérations de base, pour
lesquelles des paramètres sont définis :
Description des données disponibles (GetCapabilities)
Livraison des données demandées (GetMap)
Consultation d'autres informations (GetFeatureInfo)
5.4 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Standards nationaux et internationaux
Open Geospatial Consortium OGC (GML, WMS et WFS)
Les deux premières opérations doivent être impérativement implémentées, la fonction
pour la consultation des informations d’un Feature est optionnelle. L'accès à un WMS
peut avoir lieu à l'aide d'un navigateur standard, les paramètres étant alors communiqués
dans l’URL (méthode GET). Des logiciels avec une interface utilisateur graphique
(GUI) sont naturellement plus confortables, ils sont conçus soit comme application standalone
ou soit comme application/navigateur. Avec la version WMS actuelle (1.3) la
transmission des consultations est réalisée avec la méthode POST. Un WMS livre en général
des images purement graphiques dans un format image habituel comme PNG
(Portable Network Graphics), JPEG (Joint Pictures Expert Group) ou GIF (Graphics Interchange
Format). La production de cartes est aussi concevable dans le SVG-Format
(Scalable Vector Graphics).
Figure 3 : Description schématique de WMS dispersés
Des cartes WMS peuvent être demandées par différents WMS. C'est-à-dire que la spécification
soutient la construction d'un réseau de Map Server, dans lequel un client peut
demander des données (voir figure 3). Puisque chaque WMS est indépendant, chacun
doit pouvoir décrire lisiblement ses possibilités et ses ressources à un autre ordinateur.
Le concept d’un Map Server en cascade est en outre représenté dans la figure 3 (Cascading
Map Server). Ainsi, un Map Server est un client d'un autre WMS et forme, vu de
l’extérieur, un nouveau Web Map Service (réunion de plusieurs WMS dans un service).
La spécification WMS 1.3 de l’OGC est intégrée actuellement comme norme 19128
ISO/DIS 19128 (Web Map Server Interface) dans la série des norme ISO.
5.4 Le Web Feature Service (WFS)
Alors qu'avec le WMS le résultat est en général purement graphique, la spécification
WFS met en avant le transfert d’objets géographiques. Le problème est que des données
géographiques ne sont que rarement modélisées selon un modèle de données uniforme.
Par conséquent, il est important que le schéma de données soit fourni avec les données.
Ainsi un client doit pouvoir comprendre les modèles de données et les données.
Le mécanisme d'échange de données GML (Geography Markup Language) de l’OGC est
utilisé comme base pour les spécifications WFS. De cette façon, des données géographiques
et leur schéma correspondant peuvent être codés et transférés en XML. À la différence
du WMS, il est aussi possible de manipuler et de modifier ces données. Des opérations
continues ont été définies comme 'Transaction' et 'LockFeature'. Les opérations
suivantes sont définies dans les spécifications WFS :
GetCapabilities : Un WFS doit être en mesure de décrire ses fonctionnalités. Il doit
être notamment en mesure d’indiquer les Feature Types soutenus et les opérations
applicables s’y basant.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 5.5

Standards nationaux et internationaux
Open Geospatial Consortium OGC (GML, WMS et WFS)
DescribeFeatureType : Un WFS doit être en mesure de livrer sur demande la structure
pour tous les types de Features soutenus (schéma de données). En clair, cela
veut dire qu’un schéma d’application GML est transféré.
GetFeature : Un WFS doit être en mesure de livrer des instances (objets) de types de
Features. En plus, il doit reconnaître quelles propriétés (Properties) doivent être
fournies et il doit être en mesure de traiter des sélections spatiales aussi bien que
non-spatiales.
Transaction : Un WFS peut être en mesure d’effectuer des opérations sur des objets.
Ces opérations sont 'Create', 'Update' et 'Delete' pour des objets géographiques.
LockFeature : Un WFS peut appliquer un Lock-Request à une ou plusieurs instances
pendant la durée d'une transaction.
En conséquence on peut différencier les Web Feature Services selon deux types :
Basic WFS : Un WFS de base soutient les opérations 'GetCapabilities', 'DescribeFeatureType’
et ‘GET Feature'. Cela correspond à un WFS ‘Read-Only'.
Transaction WFS : Celui-ci soutient toutes les opérations du WFS de base et en plus
les opérations 'Transaction' et ‘LockFeature' (optionnel).
Un WFS livre un document d’instance GML avec la requête GetFeature. Dans la version
actuellement valable des spécifications WFS (1.0), il est stipulé que la version GML 2
doit être utilisée. Actuellement la spécification WFS est dans une phase de révision, dans
laquelle entre autres l'intégration de la version 3 est examinée par GML. Toutefois il
n’est pas encore clair, si la spécification complète GML 3 doit être soutenue. Sur la base
de la complexité de la version GML actuelle, la discussion au sujet d’une limite avec un
profil (Level 0) est en cours.
6 Conclusion
Avec l’OGC, un consortium international industriel très actif s'est établi dans le secteur
de l'information géographique ayant pour but la standardisation au niveau international.
Le consortium est largement soutenu de part la participation de grands producteurs
de systèmes, d’administrations nationales et internationales et de hautes écoles. Avec
ses activités, l’OGC a contribué à la mise au point de nombreuses normes et standards
nationaux sur la standardisation internationale. Il est réjouissant que depuis quelques
années l’OGC harmonise ses activités avec celles de l’ISO, ce qui pourrait mener à
moyen et à long terme à une acceptation plus large, mais aussi à des standards plus stables.
L’OGC a créé trois spécifications très utiles avec le WMS, le WFS et le GML. L’exemple
du WMS a montré que même l’application d'un standard relativement simple sur une
base internationale peut demander plusieurs années. On peut donc supposer que dans
le cas du GML et du WFS, la définition des profils minimaux accélérerait clairement une
adaptation réussie. L’urgence d’une transition des processus basés format vers ceux basés
modélisation, nécessaire pour une utilisation étendue des normes, a été entre temps
reconnue par l’OGC. Le développement de mesures concernant cet aspect a démarré.
Toutefois, le changement qui en découle pour les fabricants de systèmes et les utilisateurs
ainsi que les adaptations en résultant pourraient exiger encore beaucoup de travail
et temps.
5.6 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Standards nationaux et internationaux
Open Geospatial Consortium OGC (GML, WMS et WFS)
Références bibliographiques
Nebiker S. und Annen A. , 2004
Vergleichsstudie INTERLIS 2 – GML 3
Disponible sous :
http://www.kogis.ch/docs/Vergleichsstudie_ILI_GML_revidiert.pdf [Online 21. Jan.
05]
Nebiker, S., et al., 2004
Script du GIS/SIT-Workshop 2004 : 'WMS, WFS, Simple Features und Co.'
[ayant eu lieu le 30 mars 2004 à Berne]
Open Geospatial Consortium Inc. (OGC), 2004
Geography Markup Language (GML) Recommendation Paper 3.1
Disponible sous :
http://portal.opengeospatial.org/files/?artifact_id=4700 [Online 21. Jan. 05]
Open Geospatial Consortium Inc. (OGC), 2004
Web Map Service (WMS) Implementation Specification 1.3
Disponible sous :
http://portal.opengeospatial.org/files/?artifact_id=5316 [Online 21. Jan. 05]
Open Geospatial Consortium Inc. (OGC), 2002
Web Feature Service (WFS) Implementation Specification 1.0
Disponible sous :
https://portal.opengeospatial.org/files/?artifact_id=7176 [Online 21. Jan. 05]
International Organization for Standardization (ISO).
Informations sur divers standards
Disponible sous :
http://www.iso.org [Online 21. Jan. 05]
Interopérabilité pour l'utilisation généralisée de la Géoinformation 5.7

6
Le concept OGC
Possibilités et limites
Andreas Donaubauer, Matthäus Schilcher,
Anette Huber, TU Munich
Andreas Donaubauer, Dr.-Ing. /
Matthäus Schilcher, Univ.-Prof. Dr.-Ing. /
Anette Huber
Technische Universität München
Fachgebiet Geoinformationssysteme
Arcisstraße 21
D-80290 München
Tél :
Fax :
E-mail :
+49 89 289 22973
+49 89 289 22878

Avant-propos
Cet article donne un aperçu de l’état de la technique pour l’utilisation de données géoinformatiques
provenant de bases de données distribuées, sur la base des standards de
l’Open Geospatial Consortium (OGC).
A l’aide d’exemples, les possibilités et limites des standards OGC seront discutés. Un
nouveau projet de recherche entre l’EPF Zurich et la TU Munich sur l’infrastructure des
géodonnées (GDI) à grande échelle sera présenté. Ce projet a pour but d’analyser les synergies
des deux concepts « transfert de données basé modélisation » et « OGC Web Services
».
1 Introduction et définitions
Depuis plus de 20 ans, des géodonnées sont produites un peu partout dans
l’administration et le domaine privé. Par conséquent, la quantité et la dispersion de géodonnées
ont fortement augmenté. De part l’hétérogénéité prononcée des différents SIG,
l’utilisation efficace et durable de ces données n’est pas toujours optimale. A l’heure actuelle,
les problèmes se situent avant tout dans l’hétérogénéité des différents systèmes,
avec chacun leur propre interface et format de données. L’utilisation de différents modèles
de données sur un plan conceptuel, logique et physique constitue également un problème
majeur.
Pour surmonter les obstacles actuels dans l’utilisation combinée de géodonnées hétérogènes
et distribuées, deux concepts, basés sur des standards et normes internationales,
sont étudiés et discutés intensivement dans les domaines académiques et privés. Il s’agit
d’une part du transfert de données basé modélisation pour remédier au problème de
l’hétérogénéité des données et des modèles qui les constituent. Conçu dans la série des
géonormes ISO 19100, ce transfert de données est possible grâce à INTERLIS, une norme
suisse. On étudie d’autre part l’utilisation des Geo Web Services de l’Open Geospatial
Consortium OGC pour établir une interopérabilité entre différents systèmes
d’informations géographiques par rapport à leurs interfaces et formats de données propriétaires
à chacun.
Ce texte décrit les possibilités et limites du concept basé sur l’interopérabilité à l’aide
des OGC Web Services 1 . Il donne aussi un aperçu de la future combinaison des deux
approches « interopérabilité à l’aide de OGC Web Services » et « transfert de données
basé modélisation », appelée « approche combinée ».
Le tableau 1 donne une vue d’ensemble sur les méthodes pour l’utilisation combinée de
géodonnées distribuées et permet une classification des concepts décrits ci-dessus.
1
Ce texte se restreint au Web comme plate-forme pour l’interopérabilité de SIG. L’OGC élabore non
seulement des spécifications se référant aux technologies du Web (OGC Web Services), mais également
des standards pour d’autres plates-formes (par exemple SQL, COBRA, JAVA). Ceux-ci ne seront
pas traités ici.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 6.1

Etat de la technique, implémentation I
Le concept OGC : possibilités et limites
Exemples de standards
et de normes
Exemples de formats
spécifiques aux développeurs
de SIG/ formats
propriétaires/ interfaces
d’accès
DBR (SICAD) DXF
(CAD)
Transfert des données au
niveau des fichiers
orienté graphique TIFF (ISO 12639),
SVG (W3C)
structuré en objet GDF (ISO 14825) Shape (ESRI), SQD
„Intégration de données“ basé modélisation INTERLIS ?
orienté graphique OGC WMS
Interface d’accès Web
d’Autodesk MapGuide
Interopérabilité (Internet
comme plateforme de
communication entre les
composants logiciels)
„Services Web“
structuré en objet OGC WFS Interface d’accès d’un
ESRI ArcIMS Feature
Service
OGC+INTERLIS
basé modélisation (pas encore disponible)
„Approche combinée“
OGC Web Services
Tableau 1 : Méthodes pour l’utilisation combinée de géodonnées distribuées
Dans ce qui suit, quelques notions de base pour le concept de l’« interopérabilité à l’aide
des OGC Web Services » sont définies.
(Géo)données distribuées : (Géo)données séparées physiquement ou logiquement les
unes des autres.
Interopérabilité : Capacité de communication entre des systèmes indépendants en recourant
à des données et fonctionnalités par des interfaces de logiciels.
Service : Fonctionnalité isolée mise à disposition par un logiciel à travers une interface.
Pour l’utilisateur d’un service, la complexité et les structures internes restent cachées.
Enchaînement de services / Service Chaining : Appel de services séquentiels ou parallèles,
de façon à ce que la réponse d’un service soit de nouveau utilisée, par enchaînement,
comme entrée pour un autre appel de service. L’enchaînement de services est
fondamental pour l’élaboration de paquets de services.
Paquet de service / Aggregate Service : Combinaison de services isolés dans le but
d’obtenir un service plus approprié. Un paquet de service doit être établit lorsque la
fonctionnalité ou l’offre de données du service respectif n’est pas suffisant pour répondre
à la requête d’un utilisateur. Le noyau de chaque paquet de service, appelé Aggregate
Service, reçoit les entrées des utilisateurs, s’occupe de l’enchaînement des services
et livre le résultat final à l’utilisateur. Un Aggregate Service apparaît donc en tant que
client pour plusieurs services.
Web Service : Fonctionnalité, mise à disposition par un logiciel par l’intermédiaire
d’une interface Web. Des informations concernant le Web Service, comme par exemple
ses capacités, peuvent être demandées grâce à l’interface Web.
Geo Web Service : Web Service avec la fonctionnalité pour l’utilisation de géodonnées.
OGC Web Service : Geo Web Service avec une interface spécifiée par l’Open Geospatial
Consortium OGC.
6.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation I
Le concept OGC : possibilités et limites
2 Possibilités des OGC Web Services
L’application „Renseignements sur les conduites à partir de SIG distribués“, a été élaborée
dans un projet de recherche de la Technische Universität de Munich et l’association
Runder Tisch GIS. Les possibilités et avantages de l’utilisation de géodonnées distribuées
avec des OGC Web Services vont être illustrés ci-dessous.
2.1 Expériences de la TU Munich et de l’association Runder Tisch
GIS e.V.
Depuis l’année 2000, le domaine des systèmes d’informations géographiques de la TU
Munich et de l’association Runder Tisch GIS ont eut l’occasion de faire bon nombres
d’expériences à travers divers projets de recherche dans le développement d’OGC Web
Services, mais aussi dans leur utilisation et la combinaison de Services provenant de
producteurs différents.
2.1.1 Points principaux de la recherche
Les points clés des recherches de la TU Munich et de l’association Runder Tisch GIS
dans le domaine de l’utilisation de géodonnées distribuées sont :
Accès simplifié et utilisation plus efficace des géodonnées,
Utilisation de géodonnées distribuées pour un nouveau profil d’utilisation (utilisateurs
n’ayant pas de connaissance en SIG),
Enchaînement de Geo Web Services,
Possibilités et limites des OGC Web Services,
Interopérabilité entre les divers producteurs de données sur la base des standards
OGC,
Rentabilité et modèles de marché pour l’utilisation de géodonnées distribuées.
2.1.2 Plate-forme test OGC de l’association Runder Tisch GIS e.V.
Dans le cadre de la plate-forme test OGC (un environnement dans lequel sont exploités
des produits de tous les producteurs importants de SIG, ainsi que des logiciels Open
Source, voir figure 1), la Runder Tisch GIS étudie la mise en pratique de spécifications
OGC pour divers produits SIG. Les buts essentiels de cette recherche sont de démontrer
que :
les SIG de producteurs différents peuvent coopérer dans une application commune
sur la base des standards OGC,
l’utilisateur peut tirer profit du fait que l’administration et l’économie ont un accès
aux données distribuées grâce aux OGC Web Services,
des applications pratiques basées sur l’accès aux géodonnées existantes et distribuées
avec l’OGC Web Services peuvent être développées,
ce concept peut être introduit avec succès à l’échelle allemande et internationale.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 6.3

Etat de la technique, implémentation I
Le concept OGC : possibilités et limites
Développeur (Produits) SpécificationsOGC Exemples d‘applications
• AED-SICAD
(Internet Suite 6.0)
• A utodesk
(MapGuide 6.5)
• C-Plan
(TB Internet)
• ESR I
(ESR I Arc IMS 9.0 SP1
avec WMS- et WFS-
Connector)
• GE Energy (Smallworld
SIAS 2 .1)
• Intergraph (GeoMedia
WebMap 5.1b avec
WMS et WFS Adapter)
• M.O.S.S.
(W EGA-MAR S 4.2)
• Terradata
• University of
Minnesota (UMN Map
Server 4.3)
• WMS(Web Map Service)
• WFS (Web Feature Service)
• WCTS( W eb C o or d in a te
Transformation Service)
• Aggregate Services:
Implémenter plusieurs
s p éc ific a tio ns c o mme c lie n t
Régions tests
(S ou mission nai re des don née s)
• B aden-W ürttemberg,
ville Horb am Neckar
• Bayern:
Landkreis Fürstenfeldbruck, ville
de Bad Wörishofen, ville de
München, ville de Nürnberg
• B randenburg:
Landkreis Barnim
• Test d‘interopérabilité entre
les fournisseurs WMS
• Evaluation des immeubles
(sur plusieurs Länder)
• Renseignementssur les
conduites à partir de
différents SIG
Universit és
• Technische Universität
München
• Universität der Bundeswehr
München
Entreprises de services
SIG
• Geo-IT
• RIWA
Figure 1 : Plate-forme test OGC de l’association Runder Tisch GIS e.V. (Etat janvier 2005)
D’autres caractéristiques de la plate-forme test OGC sont :
neutralité par rapport aux producteurs,
système étendu aux utilisateurs ainsi qu’aux producteurs,
large échelle,
construit sur la base de la collaboration entre fournisseurs de données, producteurs
de systèmes, universités et entreprises de services SIG
recherches à partir d’applications pouvant être exploitées dans la pratique de manière
concrète,
contribution à la construction d’infrastructure de géoinformations
leader dans le domaine de l’utilisation des OGC Web Feature Services indépendante
des producteurs, et dans les domaines de l’enchaînement des OGC Web
Services (Service Chaining).
Lors du salon INTEGRO 2003, il a été démontré, avec l’exemple d’application « Évaluation
de bien immobiliers », que les OGC Web Map Service Specification (WMS) sont une
base stable pour des solutions de renseignements SIG Web interopérables. De plus, une
comparaison avec d’anciennes études sur l’interopérabilité de la Runder Tisch GIS e.V. a
prouvé que les systèmes d’informations géographiques des grands producteurs possèdent
actuellement des interfaces WMS qui sont au point. Lors d’INTEGRO 2004
l’exemple d’application « Renseignement sur les conduites à partir de SIG distribués» a
été présenté. Cet exemple a livré la première preuve d’interopérabilité, au-delà d’un seul
et même produit, basée sur la spécification Web Feature Service (WFS).
2.2 Exemple d’application « Renseignement sur les conduites à partir
de SIG distribués»
2.2.1 Situation initiale
Les gérants de réseaux de conduites (entreprises de télécommunications et
d’approvisionnement en énergie) sont tenus par la loi de pouvoir renseigner une tierce
personne voulant savoir si ses conduites seraient touchées par d’éventuelles mesures de
constructions projetées. Pour un fournisseur d’énergie, suivant sa taille, ces questions
6.4 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation I
Le concept OGC : possibilités et limites
peuvent se compter par milliers chaque année. Des sommes importantes de dommages
sur les réseaux de conduites sont engendrées chaque année suites aux atteintes faites par
des tiers. C’est pourquoi il est dans l’intérêt de tous les gérants de réseaux de prendre
cette obligation de renseigner suffisamment au sérieux. [Kopperschmidt 2004]. Sur la
base du nombre de tracés et de sections ainsi que du grand nombres d’utilisateurs potentiels,
le service des conduites possède un grand potentiel de renseignements sur les
conduites et sur les entreprises concernées (voir figure 2).
Clients potentiels
Habitants
Municipalités
Bureaux de génie civil
Fournisseurs de services
...
Prestataires
de services SIG
Géodonnées officielles de base
- Adresse géoréférencées
- ALK, DFK, Orthophotos
Fournisseurs de services
SIG A
SIG B
. . .
. . .
. . .
. . .
. . .
SIG C
Fournisseur de gaz
Fournisseur d’électricité
Télécom
Producteur de chauffage à distance
Fournisseur en eau potable
Exploitants des canalisations
...
Graphique adapté de : micus management consulting GmbH
Figure 2 : Renseignements sur les conduites provenant de SIG distribués vu comme une
prestation 2 .
Afin de pouvoir offrir une solution de ce genre, un SIG pour le service des conduites
doit avoir accès aux géodonnées de tous les gérants de conduites, ainsi qu’aux géodonnées
officielles de base.
Deux obstacles s’opposent à la solution du SIG sur les conduites englobant toutes les
entreprises gestionnaires de conduites : il y a tout d’abord l’hétérogénéité et la dispersions
des géodonnées existantes des gestionnaires de conduites, et d’autre part, ces
derniers sont rarement prêts à céder leur géodonnées à des tiers.
2.2.2 Approches possibles
Pour la création d’un SIG sur les conduites, il y a 2 approches principales pour surmonter
la dispersion ainsi que l’hétérogénéité des géodonnées existantes :
Approche A : Intégration des données (Construction du SIG par le service des
conduites en copiant toutes les géodonnées des gestionnaires de conduites ainsi
que des géodonnées officielles).
Approche B : Basée sur des requêtes aux SIG distribués au moyen des OGC
Web Services (Les données restent chez les gestionnaires de conduites ; ceux-ci
fournissent seulement les renseignements à travers les interfaces Web Services
d’après les spécifications Open Geospatial Consortium OGC).
Dans le cas de requêtes touchant plusieurs entreprises, l’approche A s’avère toutefois
problématique pour les raisons suivantes :
2
NdT : ALK = Automatisierte Liegenschaftskarte , DFK = Digitale Flurkarte, les deux notions correspondant
au plan cadastral
Interopérabilité pour l'utilisation généralisée de la Géoinformation 6.5

Etat de la technique, implémentation I
Le concept OGC : possibilités et limites
Les gérants de conduites doivent fournir l’ensemble de leurs données aux prestataires
de service intéressés.
A cause de l’hétérogénéité des données et des systèmes des gestionnaires de
conduites, l’intégration des données est coûteuse en temps et en argent.
Le service des conduites est responsable de l’actualité des données intégrées
dans le SIG, ce qui engendre, pour eux, des frais supplémentaires et d’autre part
des problèmes de responsabilité en cas de mise à jour défaillante.
Sur la base de ces réflexions, décision fut prise en 2004 de développer l’approche B, soit
l’accès aux données sur les SIG distribués à travers les OGC Web Services. Ce projet,
a les buts :
Les fonctionnalités de recherche sont basées sur les spécifications OGC Web Feature
Service et sont ouvertes à l’utilisation à grande échelle, indépendamment des
producteurs.
Mise en évidence du potentiel Geo Web Services avec une interface standardisée,
avec comme exemple une solution de recherche innovatrice.
2.2.3 Mise en œuvre des OGC Web Services pour les renseignements sur les
conduites à partir de SIG distribués
La figure 3 montre l‘architecture du système et en particulier la mise en oeuvre de
l’interface OGC Web Map Service (WMS) et Web Feature Service (WFS).
SIG A
Gaz
Browser
Aggregate Service
SIG B
Courant
OGC Web
Map Service
OGC Web
Feature Service
WFS Bridge
Géodonnées officielles de base
- Adresses géoréférencées
- ALK, DFK, Orthophotos
. . .
SIG C
SIG D
SIG E
Eau potable
Eau usée
Eclairage
Liaison Internet
Figure 3 : Architecture du système
Pendant que l’OGC Web Services permet par Internet les accès en lecture aux systèmes
des gérants de conduites et des gestionnaires de géodonnées officielles de bases,
l’application spécifique appelée Aggregate Service exécute les tâches suivantes :
convertit la demande de l’utilisateur en une requête OGC Web Services (OWS),
convertit un résultat d’un OGC Web Service en une requête d’un autre OWS,
combine plusieurs résultats de requêtes OWS,
ramifie suivant des règles le déroulement en fonction du résultat d’un OWS,
réagit à la perte, aux messages d’erreurs d’OWS ainsi qu’à la contradiction des résultats
OWS,
présente à l’utilisateur des résultats intermédiaires et finaux,
dissimule à l’utilisateur la complexité du système distribué.
Les figures suivantes montrent le déroulement d’une requête au système „Renseignements
sur les conduites à partir de SIG distribués“.
6.6 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation I
Le concept OGC : possibilités et limites
Figure 4 : Requête d’adresse
L’utilisateur peut introduire une adresse dans le masque d’Aggregate Service. Il donne
ainsi la route, le numéro du bâtiment, le numéro postal, le lieu où se trouve le dommage
ainsi que les travaux planifiés.
Figure 5 : Géocodification
L’adresse choisie par l’utilisateur est envoyée par l’Aggregate Service à un Geocoding
Service (ici un Web Feature Service qui permet l’accès aux adresses géoréférencées). Le
Geocoding Service transforme l’adresse en coordonnées.
Figure 6 : Téléchargement du plan cadastral
Interopérabilité pour l'utilisation généralisée de la Géoinformation 6.7

Etat de la technique, implémentation I
Le concept OGC : possibilités et limites
Un extrait géographique du plan cadastral est chargé à travers un WMS-Client pour
l’adresse concernée.
Figure 7 : Lieu des dégâts encadré par un polygone
L’utilisateur marque la position du dommage, respectivement du lieu des travaux en
dessinant un polygone sur le plan cadastral.
Figure 8 : Renseignement sur les conduites chez un prestataire de ces services
Le polygone est transmis de l’Aggregate Service du service des conduites aux différents
systèmes (WFS-Bridges) des gestionnaires de conduites. Les WFS-Bridges formulent une
requête aux Web Feature Services des gestionnaires de conduites (opération „GetFeature“,
filtre géométrique „Intersects“ avec le polygone comme argument du filtre),
convertit la réponse du WFS (document GML) sous forme „Réseau de conduites touché“
/ „Réseau de conduites non touché“ et retourne celle-ci à l’Aggregate Service du SIG du
service des conduites.
L’Aggregate Service du SIG du service des conduites rassemble toutes les réponses de la
requête aux gestionnaires de conduites, et envoie une réponse globale à l’utilisateur
sous forme d’une page HTML.
2.3 Résumé
Cet exemple „ Renseignements sur les conduites à partir de SIG distribués“ présenté cidessus,
montre le principe, les avantages et la faisabilité des solutions basées sur les
technologies OGC Web Services pour relier les composants d’un système distribué.
Le principe :
6.8 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation I
Le concept OGC : possibilités et limites
Gestion des données distribuées : Les données restent dispersées sur les systèmes,
où elles sont acquises et gérées.
Architecture orientée service : Le travail d’ensemble du système fonctionne sur
l’appel d’opération, ou plus précisément sur des requêtes. Le but de ces requêtes
n’est pas de transférer à l’utilisateur les géodonnées résultantes afin qu’il puisse
les analyser et les retravailler. L’utilisateur ne doit recevoir que la réponse à la requête
spatiale qu’il vient d’effectuer (p.ex. « Y a-t-il une zone de protection des
eaux sur la parcelle X ? »)
Interfaces de service standardisées : Les requêtes ainsi que les réponses sont
standardisées. Grâce à l’interface standardisée, les requêtes sur des systèmes de
différents producteurs de SIG sont formulées de la même façon. Les structures internes
complexes du système ainsi que le modèle de données restent dissimulés
grâce à l’interface de service simple.
Les avantages :
Simplicité pour le client : Pour l’utilisateur final, les géodonnées et les fonctionnalités
d’un SIG ne doivent pas être maîtrisées. L’obstacle d’apprentissage de
l’utilisation des technologies SIG est faible. De nouveaux groupes d’utilisateurs de
ressources géoinformatiques peuvent ainsi être équipés.
Faibles dépenses pour des opérateurs de solutions de renseignements : L'opérateur
d'une solution de renseignements économise temps et argent par la suppression
des étapes de travail de l’acquisition de données, du transfert de données, du
formatage, de la préparation des données et de la gestion des données.
Actualité des données : L’accès des géodonnées via le Web chez les fournisseurs
de données originaux entraîne une amélioration de la qualité par l’utilisation de
données actuelles.
Possibilité de réutilisation des composants : Une fois publiées, les Geo Web Services
sont réutilisables. Par la multiplicité des possibilités de combinaisons des
Geo Web Services, ils peuvent, une fois organisés, être utilisés de multiples façons.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 6.9

Etat de la technique, implémentation I
Le concept OGC : possibilités et limites
3 Limites des OGC Web Services
Les limites atteintes actuellement dans l’interopérabilité à l’aide des OGC Web Services
pour l’utilisation combinée de géodonnées distribuées sont présentées ci-dessous.
3.1 Limites de faisabilité
Certains problèmes pratiques se posent encore aujourd’hui lors de la résolution de problèmes
faisant appel à des géodonnées distribuées et d’OGC Web Services. Les défauts
de faisabilité du concept sont les suivants :
La combinaison de différents types d’OGC Web Services est un processus long
et intense : Dans le cas où des OGC Web Services de types différents (p.ex . : Gazetteer
Service et Maps Service) sont rattachés au sein d’une chaîne de services,
une consistance des standards de l’OGC entre eux est nécessaire. C’est dans ce
domaine que l’on constate encore certaines inconsistances qui induisent un investissement
supplémentaire à cause des transformations syntaxiques. Dans
l’exemple « Renseignements sur les conduites à partir de SIG distribués» décrit cidessus,
les inconsistances sont compensées par une programmation conséquente
dans l’Aggregate Service.
Si l’on considère la consistance entre les standards pour les Web Services de
l’informatique et de la géoinformatique, on constate que les versions de spécifications
OGC, valables actuellement ne soutiennent pas encore le SOAP-Standard,
fréquemment utilisé dans les Web Services. Ce fait pourrait gêner l’intégration
des OGC Web Services dans l’environnement général de la technologie de
l’information.
Rapidité de transmission des données par Internet : Les résultats des requêtes
aux OGC Web Services peuvent avoir un volume de données relativement grand
(p.ex. : haute résolution d’image raster pour WMS, données GML pour WFS ). De
ce fait, la maintenance et le traitement des données distribuées ne sont pas toujours
réalisables à cause des vitesses de transfert actuelles.
Limites de la dispersion et de la modularité : Des études de la TU Munich [Donaubauer
2004a] ont démontré, que pour la résolution de problèmes liés à une référence
spatiale sur la base de données distribuées et d’OGC Web Services, les requêtes
seront probablement plus nombreuses que lors d’une requête dans une
base de données centralisée.
3.2 Limites dans l’acceptation
L’acceptation du concept dans la pratique, c’est-à-dire chez les producteurs de SIG ainsi
que chez les exploitants (potentiels) des OGC Web Services (p.ex. : fournisseur de données
et prestataires de services) est fondamental pour que l’utilisateur en tire profit. Ce
concept ne devient rentable et donc intéressant que si beaucoup de producteurs proposent
des interfaces OGC de bonne qualité pour leur système, non seulement sur leur
serveur, mais aussi du côté du client. De plus il faut que les clients importants des producteurs
de SIG, comme par exemple les grands gestionnaires de données, demandent
ces interfaces et les emploient. Ce n’est qu’à ce moment-là que le concept décrit sera intéressant
et réalisable pour les applications pratiques.
À l’heure actuelle, une partie des spécifications pour les OGC Web Services est déjà largement
soutenue dans les produits des producteurs de SIG. L’interopérabilité entre les
producteurs, a été testée à plusieurs reprises avec la spécification orientée représenta-
6.10 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation I
Le concept OGC : possibilités et limites
tion graphique WMS, la plus souvent implantée (voir p.ex. : Kunkel/Teege 2003). Le fait
que la mise en oeuvre de solutions basées sur WMS est possible a été démontré (voir
Schilcher et al. 2004, et Willkomm 2004). La plate-forme test OGC de la Runder Tisch
GIS e.V., décrite ci-dessus, montre que les spécifications WFS sont déjà soutenues à
l’heure actuelle par plusieurs producteurs de SIG, mais rarement d’une façon intégrale.
La mise en pratique des spécifications OGC se limite aujourd’hui souvent aux renseignements
de bases sur les données existantes, c’est-à-dire à l’accès en lecture. La possibilité
de l’accès en écriture, que permet un Transactional WFS, n’est utilisée que très
rarement, ceci pour plusieurs raisons. D’une part, la réalisation d’un accès en écriture
standardisé est complexe (gestion des transactions, interruption de la connexion Internet,
etc.). D’autre part, la demande des utilisateurs potentiels des OGC Web Services est
insuffisante.
Il existe toujours une réticence certaine du côté des gestionnaires de données, en tant
qu’exploitants potentiels des OGC Web Services, à l’idée de permettre un accès à leur
système par Internet. Cette réserve peut s’expliquer dans la mesure où les spécifications
OGC ont certaines lacunes dans les domaines de la sécurité et le contrôle d’accès (Digital
Rights Management). De plus, le standard pour un Web Service, qui permettrait
de gérer les prestations, se trouve encore dans une phase de projet.
3.3 Limites dans la fonctionnalité
La réalisation d’une solution de renseignements sur la base des OGC Web Services
n’est plus un problème aujourd’hui. Néanmoins, les spécifications OGC actuellement
disponibles ne couvrent pas encore toutes les méthodes d’analyse importantes pour des
bases de géodonnées. Ainsi des requêtes métriques (surface, périmètre, etc. des propriétés
géométriques de géoobjets) manquent, ainsi que des méthodes d’analyse, avec
lesquelles de nouveaux géoobjets peuvent être créés à partir des géoobjets existants
(p.ex. : découpage analytique de surfaces 3 ). Le langage „Filter Encoding“, spécifié par
l’OGC pour la sélection de géoobjets est plus limité dans sa capacité d’expression que le
SQL par exemple.
Le principe du concept « interopérabilité à l’aide des OGC Web Services » est de dissimuler
les structures internes complexes du système à l’utilisateur. Ceci est réalisé par un
accès sur les systèmes à partir d’interfaces d’accès simplifiées et standardisées (voir 2.3).
Cet accès aisé est un avantage, étant donné que l’accès aux géodonnées est simplifié.
D’un autre côté, les OGC Web Services cachent aussi le modèle conceptuel, qui se
trouve derrière les géodonnées, alors que ces informations seraient parfois nécessaires
pour pouvoir traiter les données, livrées par un OGC Web Service. Pour des analyses
plus complexes de données, la structure des divers géoobjets et leurs rapports entre eux,
ainsi que la sémantique des données doivent être connus. Des informations qui pourraient
justement être déduites du modèle conceptuel.
3 La TU Munich a introduit un service nommé « Web Spatial Analysis Service » dans le processus de
standardisation des OGC, sensé combler cette lacune (voir Donaubauer 2004a).
Interopérabilité pour l'utilisation généralisée de la Géoinformation 6.11

Etat de la technique, implémentation I
Le concept OGC : possibilités et limites
4 Bilan et perspectives
En conséquence des possibilités et limites actuelles des OGC Web Services, les domaines
d’applications favorisés sont les suivants :
Les OGC Web Services conviennent à l’établissement de solutions de renseignements
à la fois sur un terminal Internet fixe et mobile
Les OGC Web Services doivent toujours être avantagés, lorsque la gestion des
géodonnées ainsi que les connaissances des SIG ne sont pas maîtrisées chez
l’utilisateur
et lorsque les exigences par rapport à l’actualité des données sont hautes
Combinaison de données Ad hoc, c’est-à-dire un rassemblement rapide des informations,
provenant de sources différentes. Utilisées par exemple en cas de crise
ou de catastrophe
Les « OGC Web Services » et « le transfert de données basé modélisation », les deux
concepts pour l’utilisation de géodonnées hétérogènes et distribuées, cités au début de
cet article, font partie des points principaux de la recherche en Géoinformatique à la TU
Munich (Interopérabilité à l’aide de OGC Web Services) et à l’EPF Zurich (transfert de
données basé modélisation). Les deux hautes écoles travaillent actuellement sur un projet
en coopération avec Swisstopo et Landesvermessungsamt Baden-Württemberg sur le
thème suivant : Construction d’un SIG transfrontalier dans la région du lac de Constance
Baden-Württemberg-Schweiz sur la base de standards internationaux. A partir de
l’exemple de l’application de planification régionale transfrontalière, il devient évident,
à quel point la demande pour une utilisation rapide et facilitée des données est présente
au-delà des frontières. Les deux concepts nommés ci-dessus seront analysés lors
de ce projet par rapport à leurs avantages et limites. De plus il sera examiné comment
une combinaison des deux concepts pourrait fonctionner. Par une telle combinaison de
ces deux technologies une nouvelle forme de Web Service devrait surgir. Celle-ci
supprimerait les restrictions par rapport au transfert de données basé modélisation
des OGC Web Services précédents. Pour INTERLIS un tel concept dans l’intégration
de la technologie OGC Web Services serait une plus-value certaine.
Le profit que l’on espère tirer d’une combinaison des deux concepts est, d’une part, un
élargissement des fonctionnalités, qui permettraient l’exécution de tâches plus efficacement.
D’autre part les Web Services (élargis et intelligents) sont faciles à intégrer dans
des solutions de portail. Ces portails ont l’avantage de permettre une recherche facilitée
de Web Services adaptés, dont l’accès est ainsi plus aisé. Cette combinaison promet de
plus un apport important pour la géoinfrastructure régionale, nationale et internationale.
La demande en géodonnées peut ainsi facilement être satisfaite et donner naissance
à de nouveaux groupes d’utilisateurs pour les géodonnées disponibles.
6.12 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation I
Le concept OGC : possibilités et limites
Bibliographie :
Annen, A. : Geostandards : OpenGeospatial Consortium OGC (GML, WFS, WMS).
Conférence dans le cadre de l’interopérabilité pour une utilisation étendue de la
géoinformation, Zurich, 2005
Donaubauer, A. : Interoperable Nutzung verteilter Geodatenbanken mittels standardisierter
Geo Web Services, Doctorat à la TU Munich, 2004, Internet :
http ://tumb1.biblio.tu-muenchen.de/publ/diss/bv/2004/donaubauer.html
Donaubauer, A. ; Fischer, F. ; Huber, A. ; Müller, S. ; Plabst, S. ; Straub, F. : Leitungsauskunft
aus verteilten GIS. Rapport de Projet du Runder Tisch GIS e.V., Munich,
2004. Internet : http ://www.rundertischgis.de
Gnägi, H. R. ; Plabst, S. : Modellbasierter Datenaustausch und Geo Web Services im
Internet. éditeur : Schilcher, M. . Volume sur la conférence sur le 9ème Séminaire
de formation continue sur les systèmes géoinformatiques, Munich, 2004.
Kopperschmidt, W. : Unternehmensprozesse optimieren durch Web-Services am Beispiel
digitaler Planauskunft. Éditeur : Schilcher, M. . Volume sur la conférence sur
le 9ème Séminaire de formation continue sur les systèmes géoinformatiques,
Munich, 2004.
Kunkel, T. ; Teege, G. ; Seuß, R. : Projektbericht zu den Stufen IA und IB des Projektes
„Interoperabilität auf der Basis von OpenGIS Web Services – Länderübergreifende
Datennutzung bei verteilten Geodatenbanken und unterschiedlichen
Herstellersystemen für das Anwendungsbeispiel Real Estate“. Runder Tisch GIS
e.V., Munich, 2003.
Shi, W. : Zum modellbasierten Austausch von Geodaten auf Basis XML. Doctorat à
l’Universität der Bundeswehr Munich, Munich, 2004
Schilcher, M. et al. : OGC Web Services zur interoperablen Nutzung verteilter Geodatenbanken
für die Immobilienwirtschaft. Editeur : Bernard, L., Fitzke, J. und R. Wagner
: Infrastructure des géodonnées.Bases et applications. Heidelberg, 2004.
Schilcher, M. ; Aumann, G. et al. : Abschlussbericht Forschungsprojekt GeoPortal.
Munich, 2004.
Willkomm, Ph : Interoperabilität auf der Basis von OpenGIS Web-Services Bericht aus
Forschung und Praxis. Editeur : Schilcher, M. . Volume sur la conférence sur le
9ème Séminaire de formation continue sur les systèmes géoinformatiques, Munich,
2004.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 6.13

7
Standards ISO pour le transfert de
données
État de la réalisation
Claude Eisenhut, Eisenhut Informatik AG
Claude Eisenhut
Eisenhut Informatik AG
Rosenweg 14
CH - 3303 Jegenstorf
Tél :
Fax :
E-mail :
+41 31 762 06 62
+41 31 762 06 64

1 Théorie
1.1 Quelle interopérabilité ?
L’interopérabilité est la coopération des applications dans un système „ouvert“. Une collaboration
avec d'autres applications peut avoir lieu indépendamment du hardware utilisé,
des systèmes d'exploitation employés, de la technologie de réseau utilisée et de la
réalisation d'une application. Pour cela il est généralement nécessaire de respecter les
standards communs, mais sans que des accords particuliers entre les applications soient
nécessaires.
Dans un projet d’intégration il y a normalement un mandant et un nombre défini
d’applications qui doivent collaborer (pour le projet). Aller au delà des standards fixés
dans des accords n’a pas de conséquences négatives sur la collaboration. Les applications
concernées par l’accord sont connues et influencent le projet.
Lors de la construction d'une infrastructure de données, les applications qui doivent
coopérer ne sont pas connues et/ou changent régulièrement. C’est pour cela qu’un accord
allant au-delà du standard est impossible!
Des standards fonctionnant et utilisables dans la pratique qui n'exigent pas d’accords
supplémentaires, sont une condition impérative pour l’interopérabilité d’une infrastructure
de données
Interopérabilité pour l'utilisation généralisée de la Géoinformation 7.1

Etat de la technique, implémentation I
Standards ISO pour le transfert de données : état de la réalisation
1.2 Quelles normes ISO ?
Norme Titre Etat Description
OMG Unified Modeling Diverses Diagrammes de classes
UML Language
versions.
191xxx basées
sur UML 1.3
ISO 19103 Conceptual
schema language
DTS
Restrictions de l’UML + types de données
de base comme texte, chiffre, etc.
ISO 19109
Rules for
applicationschema
DIS
Métamodèle (=langage de modélisation).
Superflu, puisque UML+19103 défini le
langage de modélisation!
ISO 19107 Spatial schema IS Type de données géométriques
(inclus la topologie)
ISO 19108 Temporal schema IS Type de données temporelles
(inclus la topologie)
ISO 19111 Spatial referencing
by coordinates
IS
Modèle de données pour système de
références spatiales par coordonnées
ISO 19112
ISO 19123
Spatial referencing
by geographic
identifiers
Schema for
coverage geometry
and functions
IS
DIS
Modèle de données pour noms
géographiques
Modèle de données - Coverage
ISO 19115 Metadata IS Modèle de données pour Métadonnées
ISO 19118 Encoding DIS Détermine les règles de codification pour
le transfert de données. Doit être en
premier défini de manière univoque et
complète pour l’interopérabilité!
W3C
XML
XML
1.0 (rarement
1.1)
Format de texte flexible
W3C
XML-
Schema
ISO 19136
XML-Schema 1.0 Langage de description pour des données
XML
Geography
Markup Language
CD (GML 3.2)
Spécification commune de l’OGC et l’ISO
pour le transfert de données
WD : Working draft ; CD : Committee draft ; DIS/DTS : Draft International Standard/Draft ;
Technical Specification ; FDIS : Final Draft International Standard ; IS : International Standard
7.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation I
Standards ISO pour le transfert de données : état de la réalisation
Langage de
modélisation
(UML+19103
(19109))
Types de données
et modèles
prédéfinis
(19107, 19108,
19111, 19112,
19115, 191123)
Modèle
d’application en
UML (par ex.
mensuration
officielle)
Syntaxe
(19188)
GML (19136, XML, schéma XML)
Règles de
codification
(doivent être
définies!)
Format de
transfert de
données
univoque et
complet
Liens entre les différents standards ISO
Applications des standards ISO sans GML
A l’aide de l’UML, le modèle de données est modélisé en considérant les restrictions de
19103 et en utilisant les types de bases définis par 19103, 19107 etc. De plus, des règles
de codification générale sont définies, par exemple comment un objet et les valeurs de
ses attributs seront codés. Ensuite, on applique sur son propre modèle les règles de codification
définies au préalable pour recevoir le format de transfert concret.
Pour faits pour un format de transfert concret sans ISO 19136 (GML), des accords supplémentaires
doivent réalisés!
Applications des standards ISO avec GML
A l’aide de l’UML le modèle de données est modélisé en considérant les restrictions du
GML (contient aussi celles de 19103) et en utilisant les types de bases définies par le
GML (contient 19103, 19107 etc.). Ensuite, on applique sur son propre modèle les règles
de codification définies par le GML pour recevoir le format de transfert concret. Le résultat
est un schéma XML qui correspond aux règles de GML. Aucun accord supplémentaire
n'est nécessaire pour un format de transfert concret.
1.3 Différentes approches de modélisation
Avec l’apparition du GML, deux avis s’affrontent :
Le modèle UML comme moyen de visualisation ; le schéma GML comme norme
Le modèle UML comme norme ; le schéma GML comme format de transfert
Interopérabilité pour l'utilisation généralisée de la Géoinformation 7.3

Etat de la technique, implémentation I
Standards ISO pour le transfert de données : état de la réalisation
Le modèle UML comme moyen de visualisation ; schéma GML comme norme
Selon ce point de départ, le schéma GML est décisif et le modèle UML ne sert qu’à visualiser
la structure de données et sert éventuellement au développement du schéma
GML.
Avantages de cette approche :
Aucune traduction du modèle UML n’est nécessaire, le schéma décrit directement
le format du transfert. Pendant la réalisation, le développeur du logiciel
doit avant tout avoir le format de transfert en tête.
Inconvénients :
La structure du contenu ne peut pas être différenciée des astuces d’utilisation du
format.
Un autre format de transfert ne peut pas être déduit facilement (pour les mêmes
données).
Les règles de transformation, définies dans 19136 (annexe F) ne couvrent pas
tous les schémas GML possibles.
Modèle UML comme norme ; schéma GML comme format de transfert
D’après ce point de départ le modèle UML est décisif et le schéma GML déduit automatiquement
sert seulement au transfert de données.
Avantages de cette approche :
D’autres formats de transfert se laissent aussi déduire.
Le modèle UML ne décrit que la structure du contenu, les astuces d’utilisation
du format sont crées par les règles de codification.
Inconvénients :
Certaines possibilités de GML ne peuvent pas être utilisées puisque les règles de
transformation de UML à GML dans 19136 manquent (annexe E).
Une traduction du modèle UML est nécessaire pour le format de transfert
concret. Pour l'utilisateur, il suffit d’appuyer sur un bouton, mais pendant la réalisation
le développeur de logiciel doit avoir en tête le modèle UML, le format
de transfert et les règles de traduction.
1.4 Critère de jugement
Lors du choix d’un standard de transfert de données, les critères suivants doivent être
considérés. On attachera plus d’importance à un facteur ou un autre selon le contexte.
Comment assurer les données contre d’éventuelles pertes suite à des développements
techniques futurs, encore inconnus aujourd’hui ?
Comment assurer les données contre la perte suite à un changement de personnel
?
Quelles sont les conséquences d’une modification du modèle ?
Un seul format de transfert est-il suffisant, ou alors différents formats de transfert
pour les mêmes données sont-il nécessaires ?
Comment contrôler la bonne réception par l’utilisateur des données commandées
?
Comment le producteur peut-il prouver qu’il a livré ce qu’il a promis ?
7.4 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation I
Standards ISO pour le transfert de données : état de la réalisation
Comment la manipulation des données peut-elle être simplifiée chez
l’utilisateur ?
Comment la manipulation des données peut-elle être simplifiée chez le producteur
?
Comment la manipulation des données peut-elle être simplifiée au pool et au
portail de données ?
Comment simplifier le transfert des prestations de services autour des données ?
Quelle est la simplicité du développement des logiciels ?
Ces standards fonctionnent–ils avec de grands volumes de données ?
Comment l’utilisation de plusieurs langues est-elle soutenue ?
Comment les structures organisationnelles fédérales sont-elles soutenues ?
Ces standards sont-ils influençables ?
Quels autres utilisateurs et usagers de données ont également besoin de ces standards
?
Y a-t-il suffisamment de spécialistes sur place ?
Des logiciels standard peuvent-ils être utilisés ?
2 Démonstration de logiciels
Modéliser avec différents outils
Description de formats
Quel est l’aspect des données ?
Contrôle des données
Outils de conversion
Les concepts de modélisation sont-ils présents dans les SIG ?
Outils pour le développement du logiciel
3 Appréciation
Les normes ISO sont utilisables. Mais elles demandent néanmoins un grand investissement,
d’une part à cause de l’étendue des différentes normes et d’autre part parce que
les concepts importants se répartissent sur plusieurs normes.
Les normes ISO sont applicables avec un investissement conséquent. Cet effort nécessaire
résulte du fait que chaque thématique est fortement détaillée, par exemple le type
de données géométriques.
Pour l’interopérabilité, les normes ISO ne sont applicables que si elles sont limitées. Il y
a trop de contradictions entre les différentes normes et trop souvent des idées définies
sont abstraites et par conséquent pas directement réalisables. La norme 19136 (GML) est
un premier pas utile dans le domaine des transferts de données.
Proposition d’amélioration
Au lieu de développer depuis trois ans dans le cadre du projet 19139 un format de transfert
pour les métadonnées, le TC211 devrait appliquer les règles de codification de 19136
(GML) sur le modèle de métadonnées (19115). Ainsi on aurait directement à l’intérieur
du TC211 un feed-back sur la faisabilité.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 7.5

Etat de la technique, implémentation I
Standards ISO pour le transfert de données : état de la réalisation
4 Perspectives
La recherche du meilleur rapport productivité/coûts ne va pas disparaître!
C’est pour cette raison que les entreprises innovatrices cherchent une nouvelle répartition
des chaînes de processus. L’interopérabilité réduit les frais d’interfaces et permet
ainsi une nouvelle répartition.
Le transfert de données est dépassé … ! L’avenir appartient aux (Web-)Services!
Les (Web-)Services ne sont pas prévus pour les utilisateurs humains mais pour des applications
qui échangent automatiquement des données et/ou font appel à des fonctions
sur des ordinateurs éloignés.
Mais sans transfert de données efficace, aucun Service ne peut fonctionner.
Chaque appel de fonction est en soi un transfert de données. La dénomination de la
fonction est les arguments de la fonction en cours doivent être transférés d’un ordinateur
à l’autre et le résultat doit être retourné.
INTERLIS est –il encore nécessaire ?
Le format de transfert d’INTERLIS offre quelques possibilités que GML n’offre pas
(transfert incrémentiel, balises multilingue). Dans le cas ou ceux-ci ne sont pas nécessaires,
le GML peut être facilement utilisé pour le transfert. Le schéma de base d’INTERLIS
est toutefois nettement plus petit et par conséquent plus facile à réaliser.
Comparé avec INTERLIS, la possibilité de contrôle automatique des données avec
UML/GML (selon ISO 19136) est pauvre. Les possibilités de descriptions de données
sont substantiellement meilleures avec INTERLIS. Renoncer à INTERLIS comme langue
de description serait une régression.
7.6 Interopérabilité pour l'utilisation généralisée de la Géoinformation

8
Interopérabilité en matière de
géodonnées
État actuel et perspectives dans le canton de
Vaud
Marc Gilgen, État de Vaud
Service de l’information sur le territoire
Avec la collaboration de
Sandrine Durler, État de Vaud
Lucien Imhof, État de Vaud
Bruno Magoni, ASIT-VD
Marc Gilgen
État de Vaud
Département des infrastructures
Service de l’information sur le territoire
Av. de l’Université 3
CH-1014 Lausanne
http://www.dinf.vd.ch/sit
Tél :
Fax :
E-mail :
+41 21 316 34 83
+41 21 316 24 84

1 Introduction
Cela fait plus de 10 ans que le canton de Vaud a mis en œuvre des interopérabilités en
matière de géodonnées. L’Association pour le système d’information du territoire vaudois
(ASIT-VD 1 ), avec sa mission de plate-forme d’échange de données, a mis très tôt en
place une base de métadonnées avec un service de catalogage des données (appelé Géocatalogue)
et un service de commande en ligne des données (appelé Géocommande). En
parallèle, l’Administration cantonale, membre important de l’ASIT-VD, a engagé et développé
les ressources nécessaires pour créer un système d’information du territoire au
sein de l’État 2 . Cette infra-structure et cette organisation ont permis de développer et
favoriser les échanges de données. Dans le même temps, des interopérabilités entre applications
informatiques ont vu le jour.
Aujourd’hui, l’État de Vaud est le principal fournisseur de géodonnées via le Géoportail
de l’ASIT-VD. Il bénéficie et utilise largement les services de l’ASIT-VD en matière de
catalogage et de commande. Il est évident que cela ne fonctionne qu’avec une infrastructure
technique et organisationnelle adéquate au sein de l’Administration cantonale. Du
point de vue technique, le système d’information du territoire de l’État fonctionne essentiellement
sur le principe d’un entrepôt unique de données (Datawarehouse), alimenté
par les bases de données métiers des différents services. Cette base centrale unique permet
de servir de nombreuses applications géomatiques au sein de l’État et de développer
des interopérabilités en matière de géodonnées. Celles-ci sont de différents types et
servent différents besoins, internes ou externes à l’administration.
2 État actuel des réalisations
2.1 Interopérabilités en matière de géodonnées
Les interopérabilités en matière de géodonnées mises en œuvre à l'Administration cantonale
et à l’ASIT-VD vont du simple lien URL à des réalisations bien plus complexes.
Nous revenons en détail ci-dessous sur les interopérabilités suivantes :
Applications administratives interrogeant des géodonnées
Interrogation de couches géographiques pour les autorisations de construire
Service de cartes pour des applications Internet
Commande en ligne de géodonnées (sélection et extraction d'objets géographiques)
Applications géomatiques interrogeant des données administratives
Interrogation de bases de données distantes
Accès aux métadonnées
Connexion avec le catalogue géographique suisse
1 http://www.asit.vd.ch
2 http://www.dinf.vd.ch/sit
Interopérabilité pour l'utilisation généralisée de la Géoinformation 8.1

Etat de la technique, implémentation II
Interopérabilité en matière de géodonnées : état actuel et perspectives dans le canton de Vaud
2.2 Interrogation de couches géographiques pour les autorisations
de construire
Le service de l’État qui délivre les autorisations de construire (centrale des autorisations
3 ) dispose d'une application Internet dont un module permet l'interrogation de différentes
couches géographiques de la base de données centrale. La délivrance d’un permis
de construire est soumise à de nombreuses conditions. Parmi celles-ci, beaucoup
font intervenir la dimension géographique, liée à l’emplacement de la future construction.
De plus, afin de tenir compte au mieux de la taille de la future construction demandée,
une emprise est saisie dans l'application Web. La requête envoyée aux couches
géographiques effectue ainsi l'intersection spatiale sur la base d'un cercle proportionnel
à la taille de la future construction. Les résultats sont renvoyés dans l'application Internet.
Cette interopérabilité permet d’effectuer diverses vérifications qui seraient fastidieuses
sans un tel processus automatique.
Une des vérifications concerne le nom de la commune. En effet, celui-ci est saisi manuellement
par l’opérateur, de même que les coordonnées géographiques de la demande de
permis de construire. La requête spatiale permet de vérifier que la position géographique
de la demande de permis de construire se situe à l’intérieur du périmètre de la
commune.
La majorité des couches interrogées est stockée dans le Datawarehouse. Quelques-unes
sont stockées dans des fichiers plats. Ce mécanisme permet de vérifier la compatibilité
de la construction avec différentes contraintes légales liées à l’occupation du territoire,
en particulier l’affectation du sol, la protection des eaux souterraines, les inventaires
cantonaux et fédéraux, les mesures de protection des bâtiments (pour un bâtiment existant).
En cas de conflit, par exemple si le bâtiment est situé dans un périmètre d'inventaire,
le mécanisme indiquera les services administratifs à consulter pour se prononcer
sur la future construction. Ce processus automatisé permet ainsi à une application « non
géographique » d’interroger un serveur géographique.
2.3 Interopérabilités liées au guichet cartographique
Le guichet cartographique de l’État de Vaud (GéoPlaNet 4 ) permet la publication sur Internet
des géodonnées produites et utilisées par l’Administration cantonale. Il bénéficie
également du principe d’intégration des géodonnées dans un entrepôt unique. En outre,
de nombreuses passerelles uni- ou bidirectionnelles existent avec d’autres applications.
Parmi celles-ci, nous pouvons citer les passerelles avec le registre foncier 5 (extraits du
registre foncier), avec la centrale des autorisations 6 (consultation des dossiers), ou encore
avec la promotion économique 7 (recherche des terrains disponibles).
Les principales interopérabilités liées au guichet cartographique sont décrites cidessous.
Ces interopérabilités illustrent déjà le principe, l’intérêt et le potentiel d’un guichet
universel, par lequel les prestations de l’État sont offertes au travers d’un portail
unique.
3 http://www.camac.vd.ch
4 http://www.geoplanet.vd.ch
5 http://www.rf.vd.ch
6 http://www.camac.vd.ch
7 http://www.terrains.vd.ch
8.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation II
Interopérabilité en matière de géodonnées : état actuel et perspectives dans le canton de Vaud
2.3.1 Service de cartes pour des applications Internet
Pour les applications administratives de l’État, l’interopérabilité se traduit principalement
sous la forme d’un service de cartes. Ce service fourni par GéoPlaNet permet soit
d’intégrer dynamiquement des cartes dans une autre application (service de cartes simple),
soit d’accéder à l’interface du guichet cartographique (service de cartes avec navigation).
La localisation peut se faire par coordonnées ou sur un objet donné (par ex. une
parcelle dans une commune). Les paramètres de localisation, d’échelle et de taille de la
carte, ainsi que le choix des couches de données sont transmis par URL. Les applications
du registre foncier, de la centrale des autorisations et de la promotion économique utilisent
ces services de cartes.
2.3.2 Interrogation de bases de données distantes
A l’inverse, le guichet cartographique permet aussi d’accéder à des informations dans
des bases de données distantes. C’est l’exemple du registre foncier : à partir de GéoPla-
Net, on peut obtenir le nom du propriétaire d’un bien-fonds. Cette information sera
bientôt complétée par d’autres issues de l’extrait du registre foncier (état descriptif de
l’immeuble, propriété, servitudes, etc.). Cela montre l’intérêt et le rôle du guichet cartographique
pour accéder à des informations non géographiques. Cet accès à
l’information par la dimension géographique et par un point d’entrée unique est un
avantage certain pour l’utilisateur.
2.3.3 Accès aux métadonnées
En matière de métadonnées, le guichet cartographique offre un accès direct sur le Géocatalogue
de l’ASIT-VD 8 , dans lequel toutes les géodonnées sont décrites. Il s’agit ici
d’assurer le couplage entre la donnée et la métadonnée dans le cadre du service de
consultation des géodonnées (guichet cartographique).
2.4 Commande en ligne de géodonnées
L’outil de Géocommande de l’ASIT-VD 9 permet de commander en ligne des géodonnées
sur le territoire du canton. L'utilisateur a la possibilité de sélectionner ses données
via le Géocatalogue, et de choisir un périmètre d'extraction de manière textuelle ou géographique.
La sélection géographique offre en fait un service de sélection par objet, en
plus du service de visualisation utilisé pour afficher les fonds de cartes. Les objets géographiques
sur lesquels peut se faire la sélection sont les districts, les communes, les périmètres
de plans cadastraux et les parcelles. Le moteur cartographique est le même que
celui du serveur de cartes du guichet cartographique (MapServer). La sélection par objet
s'effectue via une base de données PostGIS.
Une fois complétée, la commande est envoyée aux fournisseurs concernés. Pour les géodonnées
de l’État de Vaud, la requête est traitée automatiquement : les géodonnées sont
extraites du Datawarehouse sur le périmètre sélectionné, puis sont transmises à
l’utilisateur par FTP. La facturation est également établie de façon automatique.
La chaîne de traitement d’une commande en ligne met donc en œuvre une série
d’interopérabilités entre plusieurs applications : pour définir le périmètre de commande
8 http://www.asit.vd.ch/geoportal/geocatalog/public.asp
9 http://www.asit.vd.ch/geoportal/geodata/public.asp
Interopérabilité pour l'utilisation généralisée de la Géoinformation 8.3

Etat de la technique, implémentation II
Interopérabilité en matière de géodonnées : état actuel et perspectives dans le canton de Vaud
(sélection d’objets géographiques), pour transmettre et exécuter la requête (extraction
d’objets géographiques).
2.5 Connexion avec le catalogue géographique suisse
Avec le nouveau catalogue géographique suisse 10 , l’ASIT-VD opère comme un partenaire
de type C (le partenaire de type A saisit ses métadonnées directement dans la base
centralisée de geocat, le partenaire B dispose de sa propre base mais réplique ses métadonnées
dans la base centralisée, le partenaire C autorise un accès à sa base par geocat
sans réplication). L’ASIT-VD dispose en effet de sa propre base de métadonnées que
geocat peut interroger. Pour ce faire, un protocole d’interrogation (Catalog Gateway
Protocol) a été défini au niveau fédéral et implémenté dans l’application de l’ASIT-VD.
Cette dernière peut ainsi recevoir et interpréter les requêtes provenant de geocat, et renvoyer
une réponse dans une structure et un format adéquats reconnus par geocat. Cette
interopérabilité est la première mise en œuvre du principe de portail suisse de recherche
de géodonnées avec un catalogue décentralisé.
L’interopérabilité entre geocat et le Géocatalogue de l’ASIT-VD illustre la nécessité de
disposer de modèles de données communs. Le modèle de métadonnées GM03Core doit
au moins être mis en œuvre dans tous les systèmes de métadonnées car c’est sur la base
de ce modèle que s’effectue l’échange de métadonnées minimal. Ainsi, l’ASIT-VD a
adapté le Géocatalogue afin d’être conforme au modèle de métadonnées suisse
GM03Core. Toutes les métadonnées obligatoires de GM03Core sont contenues dans le
Géocatatogue et sont visibles au travers de geocat.
Les développements techniques pour favoriser l’interopérabilité doivent s’accompagner
d’efforts dans d’autres domaines. Il convient ici de mentionner les efforts consentis pour
adopter ou élaborer des modèles de données standard et des procédures d’échanges des
géodonnées entre les partenaires. L’Administration cantonale et l’ASIT-VD travaillent
ensemble dans ce but. Une démarche a abouti dans le domaine des plans généraux
d’évacuation des eaux (PGEE 11 ). Une autre démarche est en cours dans le domaine de
l’aménagement du territoire pour normaliser les échanges des données de l’affectation
du sol.
3 Perspectives
3.1 Service Web d'information sur les découpages territoriaux
Le canton va mettre en place prochainement un service Web d’information sur les découpages
territoriaux du canton. Dans un premier temps, il concernera le canton, les districts,
les communes, les plans cadastraux et les biens-fonds. Ce service permet de
transmettre dans une forme standard et en format XML des informations sur les unités
des découpages précités (par ex. numéro fédéral et nom des communes) et la composition
et appartenance des entités d’un découpage vis-à-vis des autres découpages (par ex.
numéro de tous les biens-fonds et de tous les plans cadastraux appartenant à une commune
donnée).
10 http://www.geocat.ch
11 http://www.dse.vd.ch/eaux/assainissement/eaux/pgee.htm et
http://www.asit.vd.ch/documentation/command.asp
8.4 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation II
Interopérabilité en matière de géodonnées : état actuel et perspectives dans le canton de Vaud
Ce service sera avant tout exploité dans le processus de commande et de diffusion des
géodonnées. Conçu comme un service Web indépendant de toute application, il pourra
cependant être utilisé par la suite dans d’autres domaines. Les avantages d'un tel service
sont évidents : la mise à jour des bases de données pourra être automatisée lors de
changements tels que des fusions de communes ou l'arrivée de nouveaux lots de mensuration.
En comparaison, les méthodes traditionnelles de mise à jour prennent un temps
considérable au vu de la multitude d’applications qui utilisent ces informations.
Par ce service, il est aussi prévu d'automatiser la mise à jour des numéros postaux
d’acheminement (NPA) et des localités dans toutes les applications concernées. Les
NPA changent régulièrement et sont actualisés plusieurs fois par année 12 .
3.2 Service de cartes sécurisé
L’ASIT-VD et le canton sont en phase de développement et de test d’un service de cartes
sécurisé basé sur les spécifications OGC 13 . La première étape va mettre en œuvre la spécification
Web Map Service (WMS) pour fournir des cartes sous forme d’images, avec un
accès sécurisé et authentifié par nom d’utilisateur et mot de passe.
L’objectif est double :
Compléter la diffusion physique des données par une offre d’accès direct aux données
via le standard WMS. L’utilisation du WMS permet à toute application fonctionnant
comme client WMS d’envoyer des requêtes et d’intégrer les cartes retournées
directement dans l’interface cliente. Les applications visées ici sont en particulier
les logiciels SIG et les applications Web. Corollairement, les utilisateurs visés
sont aussi bien les professionnels de domaines métiers (mensuration, environnement,
aménagement, etc.) que par exemple des communes. En matière de SIG, de
plus en plus de logiciels offrent des fonctionnalités de clients WMS, aussi bien commerciaux
(par ex. MapInfo, ArcGIS) que dans le monde du logiciel libre (par ex.
JUMP). La sécurisation permet d’identifier les utilisateurs et de définir notamment
un système de tarification pour ce service d’accès direct, au même titre que pour le
service de diffusion physique.
Offrir un service de guichet cartographique centralisé (portail vaudois), à l’attention
des administrations publiques en premier lieu. La condition est que le fournisseur de
géodonnées dispose d’un serveur capable de répondre à des requêtes WMS et de
produire des images conformes à ce standard. Le guichet cartographique unique,
hébergé et maintenu par l’ASIT-VD, fonctionnera alors comme client WMS et permettra
la consultation de géodonnées provenant de divers fournisseurs. Un des enjeux
est notamment de pouvoir superposer des données de l’Administration cantonale
et des données fournies par les communes.
Ce service sécurisé permettra dans un premier temps l’interopérabilité uniquement en
matière de géodonnées. Par la suite il est envisagé d’orienter les développements vers
l’interopérabilité des fonctionnalités. Cela signifie que des fonctionnalités présentes au
niveau de l’application du fournisseur pourront être accédées par le guichet centralisé,
voire même par n’importe quel client. Il paraît évident que la mise en place d’une telle
interopérabilité passe par le développement de fonctionnalités sous la forme de services
Web.
12 http://www.poste.ch/yellowbox
13 http://www.opengeospatial.org
Interopérabilité pour l'utilisation généralisée de la Géoinformation 8.5

Etat de la technique, implémentation II
Interopérabilité en matière de géodonnées : état actuel et perspectives dans le canton de Vaud
Pour l’Administration cantonale, ces perspectives représentent non seulement des objectifs
et des défis techniques, mais également des objectifs stratégiques. En effet, la mise en
place de telles interopérabilités aura des incidences sur la diffusion des géodonnées, leur
tarification, leur gestion et leur mise à jour (partage de coûts, mutualisation
d’infrastructures), leurs conditions d’utilisation.
4 Conclusion
L’interopérabilité en matière de géodonnées joue un rôle important, voire essentiel.
Dans le canton de Vaud, les développements réalisés dans ce domaine permettent aujourd’hui
de faire les constatations suivantes :
L’interopérabilité offre des solutions techniques à des problèmes organisationnels
(par ex. par le service d’interrogation de couches géographiques).
L’interopérabilité permet des gains de temps et d’argent par la rationalisation de tâches
liées à l’acquisition, la gestion, la mise à jour, la publication et la diffusion des
géodonnées (par ex. par le service de commande en ligne des géodonnées).
L’interopérabilité soutient la promotion et l’utilisation des géodonnées dans des
domaines peu ou pas familiarisés à la géomatique (par ex. par le service de cartes
mis à disposition par le guichet cartographique).
L’interopérabilité augmente la fiabilité des données : on évite des réplications multiples,
on accélère fortement leur mise à jour, on diminue les volumes de stockage ainsi
que les efforts de gestion (par ex. par le service d’information sur les découpages
territoriaux).
8.6 Interopérabilité pour l'utilisation généralisée de la Géoinformation

9
La complexité de l’interopérabilité
Compte-rendu de la pratique de la Suisse
orientale
Ueli Forrer, F+P GEOINFO AG
Ueli Forrer
F+P GEOINFO AG
Geoinformatik und Vermessung
Kasernenstrasse 69
CH-9100 Herisau
http://www.geoinfo.ch
Tél :
Fax :
E-mail :
+41 71 353 53 53
+41 71 353 53 50

1 Introduction
Pour nous, prestataires de services dans le domaine des SIG, l’interopérabilité est un
thème d’une grande actualité qui, envisagé dans une perspective à long terme, deviendra
une question de survie pour nos entreprises. Lorsque nous analysons des définitions
existantes de l’interopérabilité, nous nous heurtons très vite à la question de la délimitation
du système. Dans notre système, une infrastructure régionale de géodonnées,
l’interopérabilité peut actuellement être trouvée au sein de divers sous-systèmes.
1.1 Définitions de l’interopérabilité
L’interopérabilité est définie de diverses manières dans les publications consacrées à ce
sujet. Nous nous limiterons par la suite à deux définitions 1 différentes, bien que très
proches au niveau du sens :
1. On désigne, par le terme d’interopérabilité, la capacité à collaborer que présentent
des techniques, des organisations ou des systèmes différents. En règle générale,
le respect de normes et de standards communs est nécessaire à cette fin.
Lorsque deux systèmes sont conciliables l’un avec l’autre, on dit également qu’ils
sont compatibles.
2. L’interopérabilité est la capacité de systèmes hétérogènes indépendants à collaborer
les uns avec les autres de façon aussi harmonieuse que possible afin
d’échanger ou de mettre à la disposition de l’utilisateur des informations d’une
manière efficace et exploitable, sans que des mesures particulières entre systèmes
soient nécessaires à cet effet.
1.2 Délimitation du système
Si, dans le cadre de la première définition, l’interopérabilité est désignée comme étant la
capacité à collaborer que présentent des techniques, des organisations ou des systèmes
différents, alors il est logique d’en déduire qu’elle est très largement conditionnée par la
délimitation du système, quelle que soit la nature de cette dernière, technique ou organisationnelle.
2 Interopérabilité à l’exemple de la société IG GIS AG
En Suisse orientale, les cantons d’Appenzell Rhodes-Extérieures (AR), d’Appenzell
Rhodes-Intérieures (AI) et de Saint-Gall (SG), rejoints par 60 communes (districts dans le
cas du canton d’AI), ont formé conjointement un groupement d’intérêts en matière de
SIG baptisé IG GIS AG. Dans ces cantons et ces communes, l’exploitation effective du
SIG est en partie externalisée depuis 1997, date à laquelle l’administration l’a confiée à
un exploitant privé, l’entreprise F+P GEOINFO AG. IG GIS AG, dont le rôle est limité à
la coordination, regroupe les intérêts des actionnaires (communes, districts et cantons)
face à l’exploitant du SIG. Le poste de gérant (emploi à mi-temps) de la société IG GIS
AG est administrativement rattaché au service de la planification informatique du canton
de Saint-Gall.
1
Source : http://de.wikipedia.org
Interopérabilité pour l'utilisation généralisée de la Géoinformation 9.1

Etat de la technique, implémentation II
La complexité de l’interopérabilité : Compte-rendu de la pratique de la Suisse orientale
2.1 Système complet
Si nous considérons l’état actuel de l’architecture du système complet, il devient relativement
difficile de se rendre compte de l’interopérabilité du système complet en raison
de sa très grande ampleur. En outre, le centre de calcul (CC) de IG GIS AG est non seulement
intégré au centre de calcul du canton de Saint-Gall (Abraxas Informatik AG),
mais également aux structures informatiques des autres cantons et communes. La figure
1 présente, d’une manière fortement simplifiée, l’architecture du centre de calcul de IG
GIS AG, considéré comme un système complet :
Figure 1
L’extension de IG GIS AG, regroupant trois cantons une soixantaine de communes, nous
permet de parler d’une infrastructure de géodonnées régionale (IRGD). Si nous nous
mettons en quête d’interopérabilité dans cette organisation, c’est au sein de bien des
sous-systèmes que nous la retrouvons.
nous considérons les « relations extérieures » de cette organisation, à savoir les nombreux
fournisseurs de données, d’autres IRGD, la future INGD (infrastructure nationale
des géodonnées), voire une organisation européenne exploitant une infrastructure de
géodonnées, alors je ne peux m’empêcher de songer à la tour de Babel Si selon la définition
de l’interopérabilité mentionnée ci-dessus, toutes ces organisations doivent dorénavant
« échanger ou mettre à la disposition de l’utilisateur des informations d’une manière
efficace et exploitable, sans que des mesures particulières entre systèmes soient nécessaires à cet
effet ».Ces derniers ne devraient pas uniquement respecter des centaines de normes et de
standards techniques à cette fin, ils devraient également devenir « interopérables » ou
compatibles au niveau de leurs formes d’organisation et des processus de gestion interne
des entreprises. Nous en sommes encore très loin. Et comme pour la tour de Babel,
le désespoir qui nous étreint parfois résulte du fait que tous ne parlent pas le même langage
: l’ingénieur saisissant des données techniques relatives à une commune parle un
9.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation II
La complexité de l’interopérabilité : Compte-rendu de la pratique de la Suisse orientale
tout autre langage que l’informaticien exploitant une infrastructure régionale de géodonnées.
Figure 2
Ce principe de base « de la diversité des langages » appliqué au cas de l’interopérabilité
est très simple à vérifier : si l’on recherche le terme « interopérabilité » sur Internet,
nombreux sont les liens qui renvoient à des organismes d’assistance. Et là également, les
organisations, les langues, les techniques et les cultures les plus diverses se rencontrent.
Par la suite, les limites du système vont être resserrées et le système complet IG GIS sera
au centre de l’attention. Ce dernier sera subdivisé en trois sous-systèmes dans un souci
de clarté de l’exposé :
Données
Logique d’application
Présentation des données
D’autres sous-systèmes seraient les suivants :
Plates-formes du système
Systèmes d’exploitation
Réseaux
Autres processus d’organisation
2.2 Sous-système des « données »
2.2.1 Etat actuel
Figure 3
Si nous considérons le sous-système des « données », alors les structures hétérogènes de
la Suisse orientale apparaissent en pleine lumière dans cette solution. Des communes de
taille modeste (comptant jusqu’à environ 4500 habitants) pour lesquelles on recense jus-
Interopérabilité pour l'utilisation généralisée de la Géoinformation 9.3

Etat de la technique, implémentation II
La complexité de l’interopérabilité : Compte-rendu de la pratique de la Suisse orientale
qu’à 17 organismes indépendants différents ne sont pas rare. Et bien sûr, chacun de ces
organismes est propriétaire de ses données et attribue en toute autonomie les droits
d’accès à ses données.
Aujourd’hui, 64 fournisseurs de données différents proposent 178 thématiques de
données (la mensuration officielle (MO) est un thème, le cadastre des conduites d’eaux
usées en est un autre, etc.), selon 609 genres de jeux de données (la couche des biensfonds
de la MO est par exemple un genre de jeux de données) et 15 formats de données
différents. Parmi ceux-ci, seuls 9 jeux de données sont décrits en format INTERLIS et
normalisés par les cantons 2 , la SIA 3 ou d’autres associations professionnelles. Seules les
données livrées en format INTERLIS sont dites « interopérables ». Si l’on subdivise les
609 genres de jeux de données selon les zones géographiques, par exemple selon les
différentes communes (biens-fonds de la MO de la commune X, biens-fonds de la MO
de la commune Y, etc.), le total s’élève alors à 10606 jeux de données différents. Nous
exploitons et organisons donc un nombre considérable d’interfaces et investissons beaucoup
de temps dans les contrôles de qualité. Et tout cela fonctionne très bien !
Dans le centre de calcul d’IG GIS, de très nombreuses données sont conservées au sein
d’un SGBDR 4 . Il s’agit de données d’utilisateurs, de droits d’utilisateurs, de définitions
de vues, etc. qui sont toutefois plus du ressort de la logique d’application, une séparation
claire n’étant cependant pas possible dans ce cadre. Aujourd’hui encore, les données
graphiques sont disponibles dans un format propriétaire, ce qui reste malheureusement
imputable aux performances du système, compte tenu de l’ampleur des volumes
de données que nous gérons.
Au sein du centre de calcul du canton de Saint-Gall et via Intranet dans les données des
cantons d’AR et d’AI, nous avons mis en place différents accès directs à d’autres
SGBDR. Au total, 22 autres bases de données (bases de données de tiers) sont aujourd’hui
directement reliées aux données de l’IG GIS. Autrement dit, l’utilisateur accède
directement à ces bases de données via son SIG. Cette intégration dans les structures
informatiques existantes est une nouvelle preuve d’interopérabilité.
L’analyse du sous-système des données doit tenir compte d’autres aspects d’une grande
importance :
La présentation des données, les légendes qui y sont associées, les informations de nature
juridique et le niveau d’actualité jouent auprès des utilisateurs un rôle qu’il
convient de ne pas sous-estimer.
Nous gérons des métadonnées complètes concernant tous les jeux de données ; elles
sont stockées dans le SGBDR et déjà disponibles actuellement sous une forme permettant
un échange « interopérable » avec des systèmes de tiers.
2.2.2 Perspectives
Concernant la normalisation des données, nous attendons la publication de normes par
les instances internationales, nationales et régionales les plus diverses.
Dans le sous-système des données, l’avenir nous semble être à une gestion des données
centralisée sur la base d’un serveur de géodonnées avec un SGBDR. Nos tentatives
d’accès à un serveur de géodonnées avec diverses applications montrent que
2
La conférence des géodonnées dans le canton de SG et le comité SIG dans le canton d’AR
3
Société suisse des ingénieurs et des architectes
4
Système de gestion de base de données relationnelle
9.4 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation II
La complexité de l’interopérabilité : Compte-rendu de la pratique de la Suisse orientale
l’interprétation de types de données géométriques simples soulève déjà bien des questions.
Et la présentation différenciée des données en fonction des produits rend la tâche
encore plus ardue.
S’agissant de l’échange et de la présentation des données, nous misons sur INTERLIS
2, bien qu’à l’heure actuelle, l’acceptation par nos fournisseurs de données semble très
incertaine pour une partie d’entre eux. Dans ce cas également, le standard international,
à savoir GML3, est une solution envisageable.
2.3 Sous-système de la « logique d’application »
2.3.1 Etat actuel
Figure 4
Nous exploitons d’une part des applications gérées de façon interne sur la base
d’un SIG de bureau ainsi que diverses applications Internet, et d’autre part des
produits publics sur Internet, tel que le géoportail www.geoportal.ch. Notre logique
d’application reste très fortement orientée vers les applications isolées et
assez faiblement vers le SGBDR. Sur ce point, l’interopérabilité n’est pas encore
acquise.
Comme déjà mentionné pour le sous-système des données, les points suivants nous
semblent importants et dignes d’être évoqués dans le domaine de la logique
d’application :
Nous gérons un système de management très complet des utilisateurs avec des
règles contractuelles et des droits d’accès correspondants.
Nous stockons l’intégralité de nos données au sein de structures, la classification
suivante étant employée :
catégories
domaines
thèmes
jeux de données
Afin de faciliter la tâche des utilisateurs, nous leur mettons des données à disposition
sous la forme habituelles de cartes, lesquelles sont alors des combinaisons
prédéfinies de jeux de données ou de vues définies.
Nous possédons un nombre croissant de jeux de données également définis via
un ensemble de règles (par exemple des réseaux hydrographiques incluant les
kilométrages et les formations d’itinéraires, des topologies de surfaces, etc.).
2.3.2 Perspectives
En matière d’interopérabilité au sein de la logique d’application, la voie du développement
est déjà toute tracée par les progrès de l’informatique : .net, COM, GML/XML etc.
accroîtront l’interopérabilité des futures applications.
En ce qui concerne les droits d’accès aux données, une réelle interopérabilité semble
très incertaine et peu judicieuse.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 9.5

Etat de la technique, implémentation II
La complexité de l’interopérabilité : Compte-rendu de la pratique de la Suisse orientale
Les structures de données (sous la forme des subdivisions mentionnées précédemment),
les vues sur les données prédéfinies, etc. sont aujourd’hui déjà stockées au sein
d’un SGBDR et sont déjà « interopérables » d’un point de vue technique.
INTERLIS 2 nous permettra à l’avenir de décrire la définition de règles relatives aux
données de manière « interopérable ». Les règles elles-mêmes sont à stocker dans un
SGBDR, si possible avec les données.
2.4 Sous-système de la « présentation »
2.4.1 Etat actuel
Les normes et les standards les plus divers existent déjà dans le sous-système de la présentation.
Aujourd’hui déjà, nous recourons par exemple aux systèmes d’exploitation
les plus divers pour diffuser des données sur les géoportails destinés à la consultation
interne (entre 6000 et 7500 cessions par mois) et publique sur Internet (entre 10000 et
14000 cessions par mois) via http. De même, nous faisons l’expérience d’un type particulier
d’interopérabilité dans le cadre de l’exploitation des géoportails pour les utilisateurs
(230 enregistrés) via l’environnement Metaframe/Citrix, dépassant les limites des
systèmes d’exploitation.
Figure 5 : Sous-système de la présentation
Les techniques à disposition actuellement, en particulier WMS 5 et WFS 6 , permettraient
d’accroître l’interopérabilité (dans le cas également des données propriétaires), mais elles
ne sont pas mises en œuvre en raison des droits d’accès. En conséquence, l’utilisation
de WMS n’est judicieuse actuellement que pour les données publiques sur Internet.
2.4.2 Perspectives
Dans ce sous-système, nous voyons l’utilisation future de divers services Internet
comme une possibilité judicieuse pour les données librement disponibles sur le réseau :
WMS (Web Map Servive)
WFS (Web Feature Service)
WCS (Web Coverage Service)
WCAS (Web Catalog Service)
WCTS (Web Coordinate Transformation Servive)
d’autres services Internet
Actuellement le service WMS (Web Map Service) arrive assurément en première position
pour nos applications, les tiers institutionnels pouvant consulter et imprimer des
données mais pas les obtenir en format vectoriel. Cela conviendrait toutefois à de nom-
5
Web Map Service
6
Web Feature Service
9.6 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation II
La complexité de l’interopérabilité : Compte-rendu de la pratique de la Suisse orientale
breux propriétaires de données qui permettent la consultation et l’impression de données,
en particulier au sein de l’administration.
3 Résumé
Au sein d’une structure organisationnelle pour des géodonnées régionales comme celle
de la société IG GIS AG, des prémices d’interopérabilité sont présentes dans les sousdomaines
les plus divers. Aujourd’hui encore, elles restent très techniques, à niveaux
multiples et concernent des domaines très différents et très spécifiques des secteurs de
l’informatique et de l’information géographique. A notre sens, nous sommes encore très
loin d’une interopérabilité authentique, autrement dit d’une interopérabilité entre organisations
en charge d’infrastructures de géodonnées d’ampleur régionale et nationale.
La complexité de l’interopérabilité s’accroît à mesure que la délimitation du système
gagne en ampleur et l’interopérabilité tend à s’éloigner des systèmes et des techniques
pour se concentrer sur les organisations et leurs processus opérationnels.
Références bibliographiques
INSPIRE. 2003. Spatial Data Infrastructure in Europe. Spatial Application Division
K.U. Leuven, Research & Development
Open GIS Consortium. OpenGIS Service Architecture
OSIG. 2003. Worin liegt der praktische Nutzen von Interoperabilität und Normung für den
GIS-Anwender in der Schweiz?”
Organisation suisse pour l’information géographique, rapport du groupe de travail
sur les technologies SIG
Ott, Mathias. Datenaustausch und Interoperabilität, Dienste für eine offene
Geodatenstruktur,
ww.ikg.uni-bonn.de/Lehre/Geoinfo/is_iv_SS_04/Vorträge%5C04_05_27_Ott.ppt
Interopérabilité pour l'utilisation généralisée de la Géoinformation 9.7

10
Approche modélisation et
interopérabilité des données appliquée
aux données de référence en Région
Wallonne
Jean-Claude Jasselette, MET Belgique
Jean-Claude Jasselette
MET (D.432) Topographie et Cartographie
CAMET - Boulevard du Nord, 8
B-5000 Namur
Tél :
Fax :
E-mail :
+32 817 733 51
+32 817 738 88

1 Introduction
1.1 Présentation rapide
Jean-Claude Jasselette est attaché à la Direction de la Topographie et de la Cartographie
du Ministère de l’Équipement et des Transports au sein de la Région wallonne en Belgique.
Il est impliqué dans le projet InfraSIG. Il a notamment participé aux travaux de
modélisation des données topographiques de référence sur base de la méthode INTER-
LIS.
L’objectif principal de l’exposé est de présenter les travaux entrepris dans le cadre de la
mise en place d’une infrastructure d’informations géographiques en Région wallonne.
L’exposé s’efforcera de montrer les lignes directrices qui ont été suivies et leurs implications
en terme d’interopérabilité au niveau des données spatiales.
1.2 Plan
Après une brève description de la situation de la cartographie belge, la problématique
sera replacée dans son contexte régional wallon. On passera successivement en revue les
objectifs poursuivis, les moyens mis en œuvre et enfin l’état d’avancement des travaux.
Les conclusions porteront sur les avantages du choix effectué, sur les problèmes rencontrés
ainsi que sur les enseignements qui en ont été retirés.
2 Contexte et problématique
2.1 La Belgique, un état fédéral jeune
FLANDRE
13 522 km 2
BRUXELLES
162 km 2
WALLONIE
16 844 km 2
Interopérabilité pour l'utilisation généralisée de la Géoinformation 10.1

Etat de la technique, implémentation II
Approche modélisation et interopérabilité des données appliquée aux données de référence en
Région Wallonne
Comme chacun le sait, la Belgique est engagée depuis plus de vingt ans dans un processus
de régionalisation. Pour des sujets tels que la cartographie, le pouvoir public se décompose
en, d’une part, un échelon fédéral et, d’autre part, un niveau régional qui comprend
la Région wallonne (16’844 km 2 ), la Région flamande (13’522 km 2 ) et la Région de
Bruxelles capitale (162 km 2 ).
2.2 Cartographie, l’état fédéral et les régions
Comme dans la plupart des états européens, la Belgique dispose d’un Institut Géographique
National propre (IGN). Cette administration publique fédérale est chargée de
tous les aspects de cartographie, de géodésie et de télédétection qui portent sur la totalité
du territoire national. L’IGN belge est producteur de cartes et de données topogéographiques
de grande qualité correspondant à des échelles comprises entre 1’300‘000
et 1/10’000.
À côté de cela, toujours à l’échelon fédéral, le cadastre est producteur de plans parcellaires
à très grande échelle. À l’heure actuelle, ces plans ont un but exclusivement fiscal et
ne sont, pour la plupart, pas de qualité topographique. Un ambitieux projet de modernisation
du cadastre belge est en préparation.
À la suite de la régionalisation des compétences en matière d’environnement,
d’aménagement du territoire, de travaux publics et, plus récemment, d’agriculture, les
pouvoirs publics régionaux ont mis sur pied divers projets cartographiques. En ce qui
concerne les données de référence, les trois régions ont notamment lancé chacune un
projet de cartographie topographique numérique à très grande échelle. Il s’agit des projets
Urbis en Région de Bruxelles capitale, PICC en Région wallonne et GRB en Région
flamande. Ces trois projets répondent approximativement aux mêmes critères de précision
et sont comparables à une cartographie de type « travaux publics » à une échelle de
1/1’000 ou mieux. Ils sont généralement complétés par des couvertures
d’orthophotoplans numériques.
En l’absence d’un organisme de coordination de niveau fédéral ou interrégional, les projets
initiés par les trois régions ont malgré tout des caractéristiques techniques assez sensiblement
différentes.
2.3 La cartographie en Région wallonne
2.3.1 La diversité des approches et des références
Au sein même d’une région, l’homogénéité n’est pas toujours la règle non plus. Ainsi,
en Wallonie, différents producteurs de données cartographiques analogiques ou numériques
ont utilisé ou utilisent encore des méthodes et des références différentes. Par
exemple, faute de référence commune, il n’est pas rare que des géomètres agissant pour
diverses administrations de la Région wallonne ne puissent pas s’échanger les données
qu’ils ont récoltées par levers topographiques.
2.3.2 La richesse des données numériques
Depuis quelques années, l’abondance et la richesse des données géographiques numériques
produites par les administrations de la Région wallonne sont toutefois reconnues.
Ainsi, les Plans Photographiques Numériques Communaux (PPNC) forment un orthophotoplan
numérique en couleurs de résolution métrique qui couvre la totalité du territoire
de la Région. Le Projet Informatique de Cartographie Continue (PICC) offre quant
à lui une cartographie numérique à l’échelle de 1/1’000 d’une superficie supérieure à
10.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation II
Approche modélisation et interopérabilité des données appliquée aux données de référence en
Région Wallonne
8’000 km 2 , reprenant notamment dans une base de données géographiques plus de 55 %
des 1’500’000 bâtiments que la Région wallonne comporte.
Au vu de la qualité des données existantes et des coûts que leur production a représenté,
on comprend que leur valorisation soit un enjeu important et qu’il ne soit pas envisagé
de relancer un nouveau projet de la même envergure.
2.3.3 Le contrat d’avenir et la démarche eGov
À notre époque d’informatisation croissante et d’interconnexion des bases de données,
la nécessité de coordonner les activités des différents pouvoirs publics responsables de
la production de données spatiales est devenu un enjeu crucial.
Le Gouvernement de la Région wallonne est conscient de cet enjeu. Dans une des mesures
prioritaires de son Contrat d’Avenir pour la Wallonie (CAW), document de Déclaration
de Politique Régionale, il est stipulé que le Gouvernement « mettra à disposition de
tous les acteurs, via le réseau Internet, l’ensemble des données cartographiques en Région
wallonne » et ce en « intégrant les différents projets de cartographie dans un système
ouvert, cohérent et coordonné permettant l’échange d’informations et évitant tant
les doublons que les incompatibilités ». Depuis 2002, le CAW actualisé précise que les
« projets cartographiques régionaux seront mis à disposition du public sur Internet dans
le cadre du projet d’e-Gouvernement wallon ». On voit donc que l’accès à des données
géographiques cohérentes et de qualité est jugé prioritaire par les pouvoirs publics wallons.
2.3.4 Le CTC et le projet InfraSIG
C’est dans ce cadre que le Comité Technique Cartographique (CTC) de la Région wallonne
a été mis en place en novembre 2000. Le CTC est composé de représentants du
Ministre chargé de la cartographie et des différentes Directions générales des Ministères
wallons. Son but principal est d’assurer la cohérence entre les différents services de cartographie
de la Région wallonne afin de répondre aux objectifs du CAW actualisé.
Afin de pouvoir proposer au Gouvernement les éléments d’une politique de gestion et
de diffusion des données géographiques publiques de qualité et à jour, dans le cadre
d'une infrastructure basée sur l’Internet, le CTC a lancé en 2002 un projet dénommé InfraSIG.
Ce projet vise à définir et à réaliser une infrastructure de gestion et de diffusion
des données géographiques de la Région wallonne pour répondre aux demandes et aux
besoins de tous les utilisateurs. Pour réaliser ce projet, le CTC bénéficie de l’assistance
technique d’un consortium piloté par la société GFI.
Le projet InfraSIG se développe suivant quatre axes :
1.Un axe organisationnel afin de coordonner le projet, de définir le rôle et la responsabilité
des acteurs, de sensibiliser et former les utilisateurs, et d’établir un guide
des bonnes pratiques.
2.Un axe technique qui a pour but d’aborder la problématique
de l’infrastructure de diffusion des données,
des métadonnées,
de la mise en cohérence des données de référence et des données thématiques
par la modélisation,
des services associés à ces données,
des procédures de mise à jour.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 10.3

Etat de la technique, implémentation II
Approche modélisation et interopérabilité des données appliquée aux données de référence en
Région Wallonne
3.Un axe juridique qui vise,
d’une part, à établir un modèle de licences uniformisé pour la mise à disposition
d’informations géographiques par la Région ;
d’autre part, à étudier l’impact des législations relatives à l’accès à l’information.
4.Un axe socio-économique qui a pour objectif d’analyser les coûts, le marché et les
usages en vue de proposer au Gouvernement wallon les éléments d’une politique
de diffusion des données géographiques.
A chacun de ces axes correspond un ou plusieurs groupes de travail.
Ministre M. DAERDEN
(en charge des matières cartographiques)
Inter-Cabinets ministériels – “Carto”
Différentes DG
Comité Technique Cartographique
Assistance technique
du Projet
Gestion du projet INFRASIG
GT
Organisation
Coordination
Données de
référence
Métadonnées
GT Technique
Infrastructure
Données
thématiques
Diffusion
Mission Permanente
GT
Juridique
GT
Prix
Organisation
Technique Juridique Prix
Missions Ponctuelles
Enfin, le CTC est chargé de « gérer les collaborations et les accords de coopération avec
d'autres instances régionales et communautaires (OC GIS-Vlaanderen, CIRB, …), nationales
(IGN, cadastre, …), et européennes (projets transfrontaliers, initiative INSPIRE,
…) ».
10.4 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation II
Approche modélisation et interopérabilité des données appliquée aux données de référence en
Région Wallonne
3 Objectifs poursuivis
Les principales lignes directrices qui sont suivies dans la mise en place de
l’infrastructure de diffusion de l’information géographique wallonne peuvent se résumer
comme suit.
3.1 Utilisation des données
Tout d’abord, l’infrastructure doit faciliter la réutilisation des données et garantir le
maintien du niveau de qualité de ces données, ce qui implique leur mise à jour.
Afin de garantir que des informations géographiques produites dans le cadre d’un projet
spécifique soient réutilisées à d’autres fins et qu’elles soient consultées par le secteur
public ou encore intégrées dans des services à valeur ajoutée par le secteur privé, il faut,
dans un premier temps, leur assurer une meilleure visibilité et une documentation adéquate.
Il faut aussi identifier et réduire dans la mesure du possible les facteurs limitant
l’accès aux données géographiques, comme les lourdeurs liées à l’administration ou à la
législation, les prix trop élevés, ainsi qu’une série de problèmes techniques.
3.2 La notion de source authentique
Ensuite, comme nous l’avons vu, la cohérence doit être renforcée. Cet objectif sousentend
par exemple qu’une référence commune soit identifiée ou constituée et qu’on
évite tant que faire se peut la dispersion de multiples copies des données de référence.
Cette dernière situation fait naître en effet d’énormes problèmes en cas de mise à jour de
ces données.
Un objectif à long terme est donc d’en arriver à la notion de source authentique qui
permet d’avoir une référence unique et facilement accessible. À titre d’exemple, a
contrario, les données du PICC sont copiées quatre fois sur la version intermédiaire du
portail cartographique de la Région wallonne.
3.3 Interopérabilité au niveau des données
La diffusion en ligne d’information géographique implique aussi d’assurer
l’interopérabilité au niveau des données.
3.4 Respect des normes et standards internationaux
La réalisation de cette infrastructure est menée dans un esprit d’intégration et de coordination
avec l’initiative européenne INSPIRE (Infrastructure for Spatial Information in
Europe) ainsi que dans le respect des normes et standards internationaux existants,
voire en préparation (ISO, CEN, NBN, OGC, W3C…).
3.5 Indépendance vis-à-vis des constructeurs
Enfin, la Région wallonne recherche une indépendance maximale vis-à-vis des constructeurs
de logiciels. À performances égales, les solutions « open source » bénéficieront
donc d’un avantage par rapport aux solutions propriétaires.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 10.5

Etat de la technique, implémentation II
Approche modélisation et interopérabilité des données appliquée aux données de référence en
Région Wallonne
4 Moyens mis en œuvre
4.1 Le projet InfraSIG, interaction public-privé
Le projet InfraSIG fonctionne sur la base d’une interaction entre différentes administrations
et des partenaires privés et universitaires. Depuis 2004, l’École Polytechnique de
Zurich est également associée au projet.
4.2 Méthode INTERLIS 2
Ce partenariat se justifie car, comme nous le verrons plus en détails, la démarche
INTERLIS a été adoptée dans le cadre du projet InfraSIG.
5 État d’avancement de l’implémentation
5.1 Réalisations achevées
La 1ère phase du projet InfraSIG s’étale sur 4 années (février 2002-2006). Les objectifs
intermédiaires suivants ont été atteints à ce jour :
La réalisation d’un portail cartographique intermédiaire intégré au projet
d’e-Gouvernement de la Région wallonne.
La réalisation d’un système de gestion de métadonnées conforme aux normes ISO
19115 et 19139.
La réalisation d’applications, d’accès sécurisé, en visualisation et en téléchargement
des données de référence prioritaires.
La rédaction de rapports relatifs aux aspects juridiques et économiques.
La modélisation des données topographiques de référence wallonnes suivant la
méthode INTERLIS 2 et la rédaction des clauses techniques d’un cahier des charges
basé sur ce travail de modélisation.
5.2 Le portail intermédiaire
5.2.1 État d’avancement
Le portail cartographique constitue un guichet unique, fédérateur et interactif, de diffusion
des informations géographiques de la Région wallonne à tous les utilisateurs : administrations,
entreprises et citoyens. Le portail actuel est une version intermédiaire
mise en œuvre afin de répondre rapidement à l’objectif de diffusion des données de référence.
Il sert de point d’entrée unique afin de :
Donner à tous l’accès aux données géographiques au travers du système de métadonnées
et de modèles de licences uniformisés pour la diffusion des données.
Permettre la visualisation et le téléchargement sécurisé des données de référence
prioritaires.
Donner à tous, via des liens Web, l’accès aux autres ressources géographiques
(carte géologique, atlas, cartes statiques, cartes dynamiques comme Trafiroute,
etc.) actuellement disponibles sur les sites des différents services de cartographie
de la Région wallonne.
Favoriser la mise en œuvre de standards pour garantir l’échange et la documentation
de données de qualité par la diffusion des résultats du projet InfraSIG à travers
le guide des bonnes pratiques et des recommandations.
10.6 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation II
Approche modélisation et interopérabilité des données appliquée aux données de référence en
Région Wallonne
Assurer la sensibilisation des utilisateurs en définissant les grands concepts de
l’information géographique et en mentionnant les dates des colloques, conférences
ou salons et des liens Web portant sur l’information géographique.
5.2.2 Activités futures
Portail définitif – Architecture technique visée
UTILISATEUR
Sécurité / authentification
Registre
Données
Services
Gestion accès / authentification
Modèles
Services
Catalogue de données
Catalogue services
Web Services OGC & W3C
Outils cartographiques
Services
INTERLIS
FTP
Bases de données
Oracle spatial 10g
Les données sont toutes stockées dans un système de gestion de base de données. Pour
les données géographiques, le choix de la Région Wallonne se porte sur Oracle Spatial.
Les données du PICC, par exemple, vont être migrées du format propriétaire lié à leur
SIG logiciel de production vers Oracle spatial 10g.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 10.7

Etat de la technique, implémentation II
Approche modélisation et interopérabilité des données appliquée aux données de référence en
Région Wallonne
5.3 MétaWal et les normes ISO
5.3.1 État d’avancement
Tous les spécialistes s’accordent pour dire que les métadonnées sont un élément indispensable
de toute infrastructure de données spatiales. Dans le cadre du projet InfraSIG,
les métadonnées de tous les jeux de données publiques wallonnes ont été décrites suivant
la norme ISO 19115. La première phase de ce travail a consisté à sélectionner et à
traduire en français les champs à retenir pour la description des jeux de données wallons
et à ajouter des descripteurs propres aux besoins des utilisateurs (extensions wallonnes).
Une fois le dictionnaire de métadonnées constitué, les modèles conceptuels
UML (Unified Modelling Language) de la norme ISO et du profil wallon ont été générés.
Le modèle UML de métadonnées a ensuite été implémenté au sein du système de gestion
de base de données ORACLE.
Des interfaces de saisie Intranet-Extranet ont ensuite été développées permettant
l’encodage des métadonnées par le gestionnaire de données, qui est responsable à la fois
de ses données et des métadonnées qualifiant ces dernières. Le contrôle d’accès à ces
interfaces est réalisé via un répertoire électronique LDAP déployé par ailleurs.
Un outil d’import/export XML de métadonnées, respectant entièrement la prénorme
ISO 19139 version 6, a été développé. Il permet l’intégration de métadonnées issues
d’imports exogènes et l’échange de métadonnées avec tout partenaire extérieur à la Région
wallonne.
A l’heure actuelle, le système, baptisé MétaWal, est opérationnel et la base de métadonnées
a été alimentée. Un ensemble d’interfaces de recherche multicritères ont été développées
afin de permettre la consultation par différents types d’utilisateur. La combinaison
avec l’outil de recherche Mugire permet des recherches multilingues.
5.4 Les données diffusées – les services sur ces données
5.4.1 État d’avancement
Les données auxquelles le portail intermédiaire donne accès en priorité sont les données
de référence (PICC, PPNC, atlas des rues, MNT des principaux cours d’eau). Jusqu’à
présent, les services développés sur ces données permettent, d’une part, leur visualisation
au travers de deux interfaces compatibles avec la norme OGC WMS et, d’autre part,
le téléchargement des fichiers contenant les données suivant deux formats propriétaires
de SIG logiciels.
Notons que ces données seront complétées par d’autres données thématiques au fur et à
mesure de leur validation.
5.4.2 Activités futures
Le portail intermédiaire gère des services suivant les normes OGC ou W3C. Ces services
s’appuient sur des outils cartographiques qui activent des algorithmes et des fonctionnalités
techniques qui sont encapsulées dans des Web Services accessibles par les utilisateurs.
Outre les services applicatifs et les services de visualisation et d’accès aux données, des
services génériques seront mis progressivement à la disposition des utilisateurs et des
concepteurs d’applications. Parmi ceux-ci, on trouvera des services de localisation (liés à
un gazetteer), de téléchargement et les services INTERLIS (checker, traduction sémanti-
10.8 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation II
Approche modélisation et interopérabilité des données appliquée aux données de référence en
Région Wallonne
que des données, outils de transformation de formats, gestion des identifiants uniques).
Ces outils permettront d’assurer l’interopérabilité des données, de répondre aux requêtes
des utilisateurs travaillant avec différents SIG logiciels et de télécharger les données
dans le format demandé.
L’évolution de l’environnement de service prévoit d’intégrer des services qui répondent
à des fonctions plus élémentaires. C’est la combinaison de ces services « atomiques » qui
permettra de réaliser des applications d’un niveau correspondant aux besoins des utilisateurs.
Par ailleurs, l’infrastructure de diffusion devra intégrer un catalogue de services répondant
probablement à la norme OGC. Plusieurs catalogues existant sur le marché sont en
cours d’évaluation dans le cadre du projet InfraSIG. Leur niveau d’implémentation de la
norme ebXML est un des critères d’évaluation.
5.5 Aspects juridiques
5.5.1 État d’avancement
Pour chaque catégorie d’utilisateurs, un modèle de licence uniformisé pour toutes les
données diffusées par l’Administration régionale a été rédigé et placé sur le portail cartographique.
L’accès aux données en téléchargement n’est autorisé que moyennant acceptation
de la licence par l’utilisateur. En ce qui concerne l’accès en visualisation, un
avertissement juridique est également affiché à l’écran.
Cela a nécessité l’examen des législations relatives à la propriété intellectuelle, au droit
administratif, aux données à caractère personnel et au respect de la vie privée, à la protection
des consommateurs, à la responsabilité du producteur et de l’utilisateur, et à la
signature électronique.
5.5.2 Activités futures
Il est actuellement question d’ouvrir le portail cartographique au citoyen afin de permettre
la visualisation des données de référence par tout un chacun. Toutefois, en l’absence
de jurisprudence, il est difficile de pouvoir garantir qu’aucune de ces données n’enfreint
le droit au respect de la vie privée. En particulier, la question se pose pour les orthophotoplans
très détaillés qui permettent de visualiser l’intérieur des propriétés privées.
5.6 Aspects socio-économiques
5.6.1 État d’avancement
Pour fixer complètement les règles de la diffusion des données géographiques, il faut
définir une politique de prix. Afin de proposer une telle politique au Gouvernement
wallon, trois axes ont été suivis.
D’une part, une étude des usages des données géographiques a été entreprise.
Cette partie a fait notamment appel à une recherche sémantique sur une très
grande quantité de documents.
D’autre part, une étude a porté sur les aspects généraux de la fixation des prix et
sur la situation en matière de données géographiques en Europe.
Enfin, une étude a permis de dégager une proposition de politique des prix qui
préconise un prix bas et qui tient compte du coût marginal de diffusion.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 10.9

Etat de la technique, implémentation II
Approche modélisation et interopérabilité des données appliquée aux données de référence en
Région Wallonne
Cette proposition respecte les objectifs généraux de la Région wallonne qui demande
que les données géographiques bénéficient d’une large diffusion permettant les économies
d’échelle et le développement régional.
La proposition se base sur les caractéristiques du marché de l’information géographique
et fournit une matrice permettant de fixer des prix en fonction du statut des données, du
type d’utilisateur et de l’usage prévu. Par exemple, un entrepreneur pourrait avoir accès
gratuitement à certaines données jugées essentielles pour lui et devoir payer d’autres
données car l’usage auquel il les destine est défini comme commercial.
5.6.2 Activités futures
Concrètement, la proposition, si elle est acceptée par le Gouvernement wallon, devrait
déboucher sur un système dans lequel les données sont diffusées gratuitement pour les
services publics et les institutions d’enseignement dans le cadre de leurs missions. À côté
de cela, la diffusion se ferait sur base de formules d’abonnement ou de partenariat
avec des acteurs professionnels. Enfin, une vente au détail reste possible dans certains
cas.
5.7 Modélisation des Objets Topographiques de Référence
5.7.1 État d’avancement
La modélisation des données de référence est partie des données existantes et en particulier
du PICC. Il en résulte que le catalogue des objets est fortement influencé par ces
dernières données. Un effet secondaire du processus de modélisation a été de faire
mieux connaître les données du PICC et d’ouvrir la réflexion sur les données de référence
à d’autres métiers que les seuls producteurs de données géographiques. Tout cela
contribue à faire migrer progressivement le PICC d’un plan topographique numérique
vers le statut de base de données de référence.
Le concept d’héritage, propre à la technologie orientée-objet, a été mis à profit pour définir
trois modèles de données géographiques concentriques. Du modèle le plus détaillé
au moins détaillé, nous les avons appelé ici le modèle « géomètres », qui contient tous
les objets levés sur le terrain sur base du système wallon Walcors (le réseau wallon de 23
balises permanentes GPS-RTK), un niveau intermédiaire, le modèle « PICC » qui ne reprend
qu’une partie des objets du précédent et enfin le modèle « Région wallonne » qui
ne reprend que les objets topographiques de référence communs au plus grand nombre
d’applications. Un modèle « de référence » à un niveau national ou européen peut être
conçu sur le même mode.
La méthode INTERLIS 2 est particulièrement adaptée pour concevoir et rendre compatibles
des modèles à des niveaux de détails très variés.
La modélisation a permis d’une part de restructurer les données en thématiques pour
tenir compte de divers usages potentiels des données. D’autre part, lors de la modélisation,
il est apparu judicieux d’enrichir les données existantes de concepts nouveaux,
comme celui de plate-forme de route.
5.7.2 Activités futures
Ces concepts nouveaux et la mise en œuvre des outils INTERLIS (en particulier le checker)
ont mis en évidence un certain nombre d’incohérences des données par rapport au
nouveau modèle. Il s’ensuit qu’un ré-engineering partiel des données se révèle maintenant
nécessaire.
10.10 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation II
Approche modélisation et interopérabilité des données appliquée aux données de référence en
Région Wallonne
Ensuite, il faudra mettre en place les processus de mise à jour des données en
s’appuyant sur les méthodes et outils d’INTERLIS. Dans ce but, il faut tendre vers une
mutualisation plus poussée des efforts. Par exemple, il faut faire en sorte qu’un seul lever
de terrain puisse contribuer à la mise à jour de plusieurs bases de données hiérarchisées.
Les opportunités offertes par INTERLIS 2 en matière de mise à jour incrémentielle
doivent être analysées de façon approfondie. La mise en place d’un système de gestion
des identifiants uniques des objets (OID) devra pour ce faire être envisagée.
5.8 Cahier des charges commun pour les levers topographiques
5.8.1 État d’avancement
Sur base des travaux de la modélisation conceptuelle des données, les spécifications
techniques d’un cahier des charges commun ont été rédigées. Lorsqu’il aura fait l’objet
d’une validation complète, ce cahier des charges pourrait être imposé aux géomètres qui
exécutent des travaux pour les pouvoirs publics wallons. De la sorte, les résultats de
leurs mesurages seront compatibles entre eux et pourront servir à mettre à jour les données
du PICC et les objets topographiques de référence suivant une méthode simplifiée.
5.8.2 Activités futures
Le cahier des charges doit encore être testé dans des conditions réelles.
Par ailleurs, afin de faciliter les échanges d’information entre les acteurs de terrain et
l’administration, un projet pilote va démarrer prochainement. Il a pour objectif de mettre
en place dans le portail cartographique un service Web d’échange de données reposant
sur les outils INTERLIS 2. Ce système permettra à un géomètre faisant des mesurages
pour l’Administration wallonne
de télécharger la documentation dont il a besoin : le cahier des charges et sa documentation,
les modèles de données, etc.
de soumettre à l’Administration le résultat de ses levers de terrain en utilisant
lui-même les outils INTERLIS 2 pour convertir ses données suivant ses besoins et
pour vérifier leur conformité au modèle correspondant au moyen du checker
d’INTERLIS.
de recevoir du système une validation de son travail dès lors que
l’Administration a contrôlé les données.
Les aspects organisationnels et humains sont au cœur des problèmes que ce projet pilote
doit aborder. En effet, la réussite d’un tel projet nécessite une bonne gestion du changement
et une convergence des intérêts vers un modèle commun.
5.9 Autres réalisation futures
5.9.1 Intégration d’autres partenaires
Dans cette démarche de la Région wallonne de construire un référentiel commun basé
sur un catalogue d’objets de référence à partir desquels pourront être générés de nouveaux
objets thématiques, la nécessité d’une coordination avec les spécialistes d’autres
métiers de la Région wallonne, les autres Régions (Flandre et Région bruxelloise) et le
Fédéral (IGN et cadastre) se fait déjà sentir. Cette coordination est notamment requise
afin de répondre aux attentes de l’Europe (initiative INSPIRE).
Interopérabilité pour l'utilisation généralisée de la Géoinformation 10.11

Etat de la technique, implémentation II
Approche modélisation et interopérabilité des données appliquée aux données de référence en
Région Wallonne
6 Réflexions
6.1.1 Avantages de la démarche INTERLIS
La méthode INTERLIS 2 présente d’une part des avantages qui découlent de sa conception
orientée-objet comme l’héritage et le polymorphisme. D’autre part, INTERLIS offre
des possibilités comme le contrôle de conformité des données vis-à-vis d’un modèle déterminé
au moyen de l’outil appelé « checker ». Les potentialités que la méthode offre en
matière de multilinguisme sont aussi particulièrement appréciées en Région wallonne et
de manière générale en Belgique. De plus, la méthode devrait faciliter la réalisation d’un
service de mise à jour incrémentielle des données.
Enfin, un avantage décisif de la méthode, en plus de son indépendance des systèmes
informatiques, est la garantie d’interopérabilité qu’il offre dès lors que les données sont
accompagnées de leur modèle conceptuel décrit suivant la méthode INTERLIS.
6.1.2 Difficultés rencontrées
Plusieurs des avantages cités ci-dessus se réfèrent explicitement à la version 2
d’INTERLIS. La Région wallonne a choisi de passer immédiatement à cette version 2
sans implémenter d’abord la version 1. Ce choix met certainement l’administration wallonne
parmi les utilisateurs précurseurs d’INTERLIS mais il a déjà été la cause de certaines
pertes de temps et il comporte une part de risque difficile à évaluer.
Par exemple, il a fallu parfois progresser « en aveugle » sans pouvoir valider les travaux
effectués : ce fut le cas lors de la phase de la modélisation en INTERLIS 2 alors que les
outils n’existaient qu’en INTERLIS ; c’est toujours le cas en ce qui concerne la modélisation
de la représentation graphique en INTERLIS 2 pour laquelle trop peu d’outils existent
à l’heure actuelle. Verrons-nous prochainement un lien direct avec les SLD de
l’OGC ?
D’autres questions techniques restent encore en suspens : quid de l’implémentation des
OID et de leur transfert vers d’autres formats de données au travers de transformations
qui ne sont, par nature, jamais neutres ? Comment normaliser le travail pour que tous
les producteurs de données puissent utiliser le même script de configuration des outils
de conversion de format ? Jusqu’où pourra aller la mise à jour incrémentielle ? Etc.
Notre expérience nous incite à plaider pour que la norme INTERLIS 2 soit complétée par
des règles d’implémentation afin d’éviter une partie des problèmes évoqués ici.
Mais à côté des difficultés techniques, des problèmes organisationnels et humains ont
aussi été rencontrés. La difficulté d’impliquer tous les acteurs dans la démarche s’est
traduite par une participation nettement moins grande des utilisateurs de données, que
des producteurs, déjà sensibilisés aux intérêts de la modélisation, par exemple.
On voit aussi qu’on doit faire face à une grande diversité des méthodes de travail, en
particulier pour les levers sur le terrain. Cela s’explique certainement par un manque de
tradition de cohérence au sein des producteurs de données wallons. Il en résulte que des
changements profonds sont à envisager pour que les données produites soient conformes
au modèle. On peut s’attendre à l’avenir à un phénomène de résistance au changement,
qui pourraient nécessiter qu’un cadre juridique soit imposé lors de la généralisation
de la démarche. Des problèmes de vocabulaire ont également été rencontrés à plusieurs
reprises.
10.12 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Etat de la technique, implémentation II
Approche modélisation et interopérabilité des données appliquée aux données de référence en
Région Wallonne
7 Conclusions
L’expérience menée jusqu’à présent en Région wallonne est globalement positive. La
démarche INTERLIS a permis de suivre des méthodes cohérentes et de lancer une réflexion
approfondie et à long terme sur l’évolution des données topographiques de référence.
Le choix d’INTERLIS 2 a malgré tout représenté une prise de risque non négligeable et
de nombreuses questions importantes restent encore sans réponse.
Les solutions mises en place sont toujours à l’état embryonnaire. Les voies d’évolution
qui s’ouvrent dans un avenir proche concernent notamment la relation entre les données
de référence et les données thématiques, ce qui nécessitera d’inclure plus d’acteurs encore
dans les réflexions.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 10.13

11
Modèles standardisés ou
interoperabilité sémantique
Perspectives de la recherche
Andreas Morf, ETH Zurich
Josef Dorfschmid, ADASYS AG
Andreas Morf
Eidg. Technische Hochschule Zürich
Institut für Geodäsie und Photogrammetrie
ETH Hönggerberg
CH-8093 Zurich
Sepp Dorfschmid
ADASYS AG
Dörflistrasse 67
Postfach 5019
CH-8050 Zurich
Tél :
E-mail :
+41 1 633 32 56 (Morf)
+41 1 363 19 39 (Dorfschmid)

1 Problématique / objectifs
Il arrive encore souvent que des données doivent être saisies à nouveau, quand bien
même elles sont en fait déjà disponibles. Elles ne sont cependant pas dans la forme souhaitée.
Il faudrait entreprendre des reformatages complexes, voire parfois assembler différents
jeux de données de type approprié, mais non transparent.
Jusqu’à ce jour, on a essayé de résoudre cette problématique par une standardisation
aussi étendue que possible des modèles et des formats de données. Lorsque la définition
des besoins et des exigences envers ces données est possible et que les utilisateurs
concernés peuvent être réunis autour d’une même table, un tel procédé offre de bonnes
perspectives de succès.
Dans de nombreux cas, une définition et une standardisation exhaustives des modèles
reste cependant impossible, ou alors implique des coûts disproportionnés.
1.1 Possibilités et limites de la standardisation de modèles
L’approche par les modèles (ISO/UML/INTERLIS) constitue un outil qui permet une
modélisation des données très flexible. L’utilisation de cette approche est largement répandue
et a été utilisée dans différentes communautés de l’information pour la définition
et la normalisation de leurs modèles de données (SIA 405, AVS, VSA-DSS).
Avec les concepts orientés objets mis en oeuvre par exemple dans INTERLIS 2, il est
maintenant aussi possible de définir des modèles de base que l’on peut ensuite, par le
processus d’héritage, enrichir sous forme d’extensions de modèles (actuellement comparable
aux extensions cantonales du modèle fédéral de la mensuration officielle).
S’il ne se révèle pas possible, pour des raisons administratives ou juridiques, de définir
un modèle de données complet et définitif, il en résulte notamment deux problèmes
fondamentaux :
Deux parties d’une même communauté de l’information (par exemple des cantons)
étendent un modèle de base avec les mêmes éléments additionnels, qu’ils
modélisent cependant différemment (noms différents pour les classes, les tables,
les attributs)
Des communautés de l’information de niveau supérieur ou « parentes » (Etat, Espace
européen) souhaitent utiliser les données et veulent élaborer à cet effet des
modèles standard. La coordination des besoins de tous les intéressés est très coûteuse
et conduit ou bien à des modèles qui constituent le plus grand dénominateur
commun et ne satisfont dès lors personne, ou bien à des modèles prenant en
compte toutes les possibilités mais d’une complexité telle qu’ils ne sont plus guère
utilisables en pratique.
La mise en oeuvre de systèmes géoinformatiques respectant des modèles de données
normalisés se heurte souvent à des obstacles, et des logiciels de saisie, de traitement et
de mise en valeur de l’information en soi appropriés ne sont pas mis en œuvre, parce
qu’ils n’implémentent pas les modèles de données souhaités ou parce que leur implémentation
entraînerait des coûts disproportionnés.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 11.1

Prochaines étapes dans l’interopérabilité
Modèles standardisés ou interoperabilité sémantique - perspectives de la recherche
1.2 Attentes d’un nouveau concept
Là où la mise en oeuvre de modèles de données normalisés se révèle impossible ou excessivement
coûteuse pour des raisons administratives, politiques, juridiques voire
techniques, on attend des voies de solution qui permettent l’interopérabilité de systèmes
dont les modèles de données diffèrent un tant soit peu :
Cette interopérabilité sémantique doit être assurée par une transformation. La
formulation des règles de transformation pour des modèles de données particuliers
est une étape qui n’est pas automatisable, ou tout au moins pas entièrement.
Les correspondances entre les différents modèles (qui représentent cependant des
réalités identiques ou similaires) doivent, à l’instar des modèles de données, être
définies au moyen d’un formalisme indépendant des systèmes utilisés (contrairement
aux transformations de format qui sont normalement réalisées avec un langage
de programmation / de script).
L’utilisation d’un tel formalisme doit être aussi intuitive que possible pour toutes
les personnes impliquées, avec dans toute la mesure du possible l’aide d’une interface
graphique appropriée (similaire à la modélisation des données avec UML).
L’assujettissement de processus de modélisation et de formats de données constituant
des standards de l’industrie doit être possible et défini (en particulier les
standards d’interopérabilité ISO/OGC).
D’un tel outil pour la modélisation de transformations sémantiques, on peut attendre les
avantages et applications suivants :
spécification formelle et visualisation des correspondances entre modèles à
l’intention des utilisateurs et des décideurs ;
dérivation automatique des programmes, scripts et instructions de transformation
(à l’exemple de scripts XSLT, SQL-3, iG et autres) ;
des portails d’accès à l’information permettant aux clients de déclarer leurs propres
modèles de données et de transformer ainsi automatiquement les données
qui leur sont délivrées.
Il serait donc souhaitable de disposer de solutions logicielles permettant de définir et de
réaliser avec simplicité et fiabilité des transformations de données complexes.
On peut ainsi imaginer la situation représentée dans la figure ci-dessous, que l’on peut
aussi formuler :
M out = f(M in-1 , .., M in-i )
La structure des données d’entrée D in-1 à D in-i est décrite par les modèles d’entrée M in-1 à
M in-i . Celle des données obtenues D out est définie par le modèle obtenu M out . Cette description
est réalisée à l’aide d’INTERLIS 2 ou d’un langage de description analogue.
11.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Prochaines étapes dans l’interopérabilité
Modèles standardisés ou interoperabilité sémantique - perspectives de la recherche
Comment doit-on alors décrire la fonction f ?
Modèle des données
d’entrée
Modèle de la transformation
sémantique
Modèle des données
obtenues
M trf
M out
D in-1
D in-2
M in-1
M in-2
Données résultantes
Moteur de
transformation
D out
Données d’entrée
Modélisation
Définition de la transform.
Contrôle
Flux de données
2 Principes fondamentaux pour la définition de la fonction
de correspondance
2.1 Définition impérative
Dans beaucoup de cas, de telles transformations de données sont définies au moyen de
langages de programmation.
Dans les cas les plus simples, on utilise des langages de script (p. ex. PERL). Dans bien
des cas par contre, on utilise des langages de programmation particuliers. On écrit alors
un programme pour résoudre le problème.
2.2 Définition descriptive
On aimerait dans toute la mesure du possible éviter de produire un programme. Des
descriptions seraient plus agréables, parce que l’on ne doit pas se préoccuper, lors de
leur élaboration, de tous les aspects de l’implémentation.
Les vues (Views), telles qu’elles sont aussi prévues dans INTERLIS 2, constituent une
voie de solution intéressante.
L’objet d’un projet de recherche actuel de l’IGP/EPFZ est de clarifier l’adéquation d’un
formalisme pour la description de la fonction de correspondance en faisant appel au
langage de modélisation UML (Unified Modeling Language). UML offre aussi, en plus
des diagrammes de classe pour la modélisation de géodonnées, des types de diagrammes
pour la description de procédés (dynamiques). On peut ainsi décrire les instructions
nécessaires pour la mise en correspondance de structures de données sous une forme
graphique et facile à comprendre pour l’utilisateur.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 11.3

Prochaines étapes dans l’interopérabilité
Modèles standardisés ou interoperabilité sémantique - perspectives de la recherche
2.3 Exemples
2.3.1 Données de base
Dans une région, il y a – comme partout – des êtres humains, donc des femmes ou des
hommes. Ci-après, le modèle de données – quelque peu simplifié - correspondant :
MODEL Hommes =
TOPIC Hommes =
CLASS EtreHumain (ABSTRACT) =
Prenom: TEXT*30;
Nom: TEXT*100;
AnneeDeNaissance: 1900..3000;
Domicile: CHCoord;
END EtreHumain;
CLASS Femme EXTENDS EtreHumain =
END Femme;
CLASS Homme EXTENDS EtreHumain =
END Homme;
END Hommes;
END Hommes.
Il faut maintenant former des couples et les traduire sous forme de données.
Cela donne, pour les couples, le modèle suivant :
MODEL Couples =
TOPIC Couples =
CLASS Couple =
PrenomHomme: TEXT*30;
NomHomme: TEXT*100;
AnneeDeNaissanceHomme: 1900..3000;
PrenomFemme: TEXT*30;
NomFemme: TEXT*100;
AnneeDeNaissanceFemme: 1900..3000;
END Couple;
END Couples;
END Couples.
11.4 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Prochaines étapes dans l’interopérabilité
Modèles standardisés ou interoperabilité sémantique - perspectives de la recherche
2.3.2 Full-Join (produit cartésien)
Si l’on s’intéresse à tous les couples possibles, on devrait définir la transformation suivante
:
TRANSFORMATION MODEL ToutesCouples =
IMPORTS Hommes, Couples;
VIEW Couple
JOIN OF M ~ Hommes.Hommes.Homme,
F ~ Hommes.Hommes.Femme;
=
PrenomHomme: TEXT*30 := M->Prenom;
…
PrenomFemme: TEXT*30 := F->Prenom;
END Couple;
MAP Couple TO Couples.Couples.Couple;
END ToutesCouples.
Une définition impérative comparable aurait à peu près la forme suivante :
loop M := toutes Hommes.Hommes.Homme
loop toutes F := Hommes.Hommes.Femme
PrenomHomme := M->Prenom;
PrenomFemme := F->Prenom;
créer Couples.Couples.Couple
copier les attributs
end
end
La différence est évidemment relativement petite.
2.3.3 Equi-Join
Si l’on s’intéresse à tous les couples, chez qui les deux partenaires sont nés la même année,
on devrait légèrement compléter la transformation :
TRANSFORMATION MODEL CouplesDuMemeAge =
IMPORTS Hommes, Couples;
VIEW Couple
JOIN OF M ~ Hommes.Hommes.Homme,
F ~ Hommes.Hommes.Femme;
WHERE M-> AnneeDeNaissance == F-> AnneeDeNaissance;
=
PrenomHomme: TEXT*30 := M->Prenom;
…
PrenomFemme: TEXT*30 := F->Prenom;
END Couple;
MAP Couple TO Couples.Couples.Couple;
END CouplesDuMemeAge.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 11.5

Prochaines étapes dans l’interopérabilité
Modèles standardisés ou interoperabilité sémantique - perspectives de la recherche
D’une manière analogue, on pourrait écrire la définition impérative suivante :
loop M := toutes Hommes.Hommes.Homme
loop toutes F := Hommes.Hommes.Femme
if M->AnneeDeNaissance== M->AnneeDeNaissancethen
PrenomHomme := M->Prenom;
PrenomFemme := F->Prenom;
créer Couples.Couples.Couple
copier les attributs
end
end
end
Mais il est aussi évident qu’en présence d’une grande quantité de données, ceci conduit
à un investissement très élevé, même pour un volume de données résultant relativement
faible (les couples trouvés), du fait que seules les personnes du même âge sont acceptées
comme partenaires. Pour chaque homme, toutes les femmes sont mises en regard, puis
la question de l’âge est examinée. Ceci conduit à M * F opérations de comparaison.
Si l’on construisait une structure auxiliaire, grâce à laquelle les femmes d’une année de
naissance précise pourraient être trouvées, le programme apparaîtrait comme suit :
HF := StructureAuxiliaire (Hommes.Hommes.Femme, AnneeDeNaissance)
loop M := toutes Hommes.Hommes.Homme
loop toutes F := ChoixDeStructureAuxiliaire (HF, M ->
AnneeDeNaissance)
PrenomHomme := M->Prenom;
PrenomFemme := F->Prenom;
créer Couples.Couples.Couple
copier les attributs
end
end
Le temps du processus devrait ainsi en principe être réduit à M * log(F), et il serait alors
possible de traiter des quantités plus grandes de données.
En réalité, on n’aimerait pas, lors de la définition d’une transformation sémantique de
données, avoir à se préoccuper de tels aspects de l’implémentation. La forme descriptive
est donc préférable. Elle a cependant l’inconvénient d’exiger du processus de transformation
qu’il reconnaissance les possibilités d’optimisation sur la base de la condition
WHERE.
L’exemple suivant le démontre d’une manière encore plus claire.
11.6 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Prochaines étapes dans l’interopérabilité
Modèles standardisés ou interoperabilité sémantique - perspectives de la recherche
2.3.4 'Near' - Join
On s’intéresse à tous les couples chez qui les partenaires ne sont pas éloignés de plus
d’un kilomètre.
TRANSFORMATION MODEL CouplesDansRayon =
IMPORTS Hommes, Couples;
FUNCTION Distance(P1: CHCoord; P2: CHCoord): NUMERIC;
VIEW Couple
JOIN OF M ~ Hommes.Hommes.Homme,
F ~ Hommes.Hommes.Femme;
WHERE Distance(M->Domicile, F-> Domicile) < 1000.0;
=
PrenomHomme: TEXT*30 := M->Prenom;
…
PrenomFemme: TEXT*30 := F->Prenom;
END Couple;
MAP Couple TO Couples.Couples.Couple;
END CouplesDansRayon. aare.
Comment le programme de transformation doit-il identifier une possibilité
d’amélioration ?
Si l’on introduisait des définitions spécifiques, pour lesquelles la référence aux classes de
base serait reconnaissable, et qui pourraient être mises en œuvre dans le cadre d’une
condition WHERE, ceci redeviendrait simple :
TRANSFORMATION MODEL CouplesDansRayon =
IMPORTS Hommes, Couples;
FUNCTION DansLEspaceDe
(Basis1: CLASS; P1Attr: ATTRIBUTE;
Basis2: CLASS; P2Attr: ATTRIBUTE;
MaxDistance: NUMERIC): BOOLEAN;
VIEW Couple
JOIN OF M ~ Hommes.Hommes.Homme,
F ~ Hommes.Hommes.Femme;
WHERE DansLEspaceDe(M, Domicile,
F, Domicile, 1000.0);
=
PrenomHomme: TEXT*30 := M->Prenom;
…
PrenomFemme: TEXT*30 := F->Prenom;
END Couple;
MAP Couple TO Couples.Couples.Couple;
END CouplesDansRayon.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 11.7

Prochaines étapes dans l’interopérabilité
Modèles standardisés ou interoperabilité sémantique - perspectives de la recherche
2.3.5 'Nearest' - Join
Si l’on est encore plus restrictif dans la formation des couples, et que l’on forme seulement
des couples entre la femme qui habite le plus près d’un homme ou vice versa, la
description de la transformation reste très semblable.
TRANSFORMATION MODEL CouplesVoisin =
IMPORTS Hommes, Couples;
FUNCTION ShortestDistance
(Basis1: CLASS; P1Attr: ATTRIBUTE;
Basis2: CLASS; P2Attr: ATTRIBUTE): BOOLEAN;
VIEW Couple
JOIN OF M ~ Hommes.Hommes.Homme,
F ~ Hommes.Hommes.Femme;
WHERE ShortestDistance (M, Domicile,
F, Domicile);
=
PrenomHomme: TEXT*30 := M->Prenom;
…
PrenomFemme: TEXT*30 := F->Prenom;
END Couple;
MAP Couple TO Couples.Couples.Couple;
END CouplesVoisin.
Si l’on veut décrire la transformation de manière impérative, il est évident que la solution
est très complexe, surtout si l’on veut pouvoir traiter un grand nombre de données
dans un temps raisonnable.
2.4 Projet de recherche 'Nouvelles voies de solution pour la description
conceptuelle de transformations sémantiques'
2.4.1 Situation de départ
A l’origine, les bases pour l’utilisation des vues, qui fournissent la représentation d’une
structure de données de sortie à une structure de données d’arrivée, étaient soigneusement
introduites. Pour un utilisateur qui ne serait pas familiarisé avec ce processus venant
du monde des bases de données, ces définitions de représentation ne sont pas faciles
à comprendre et à mettre en oeuvre. En outre, il est difficile d’obtenir une représentation
graphique intuitive, incluant le même état des faits que la transformation.
2.4.2 Fixation du but : notation graphique et formalisme relatif
A part le „diagramme de classe“, le langage de modélisation graphique UML met
d’autres types de diagrammes à disposition, qui permettent l’élaboration de modèles
pour des procédés. Comme la transformation de modèles avec ces méthodes ne peut pas
être formulée complètement, il faut pour cela utiliser le répertoire UML. Une proposition
d’éléments de modélisation correspondants (MOF Query/Views/Transformations ;
UMLX) a déjà été soumise à l’OMG (Object Management Group), qui est responsable
pour le développement futur d’UML.
11.8 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Prochaines étapes dans l’interopérabilité
Modèles standardisés ou interoperabilité sémantique - perspectives de la recherche
Pour la représentation de la transformation sémantique des géodonnées, il est nécessaire
d’évaluer les éléments du diagramme et d’y apporter les compléments nécessaires.
L’ajustement de la symbolique UML pour un domaine d’application (géoinformatique)
est aussi appelé profil UML. Une transformation modèle peut être représentée comme
suit :
Parcelle
-Remarques
-Geometrie
Processor:
CalculateAreaOf()
Parcelle
-Remarques
-calcSurface
Batiment
-NombreEtages
-Utilisation
-Geometrie
Temp-Associaton:
WHERE
Intersect(Parcelle.Geometrie,
Batiment.Geometrie)
*
*
Batiment
-NombreEtages
-Utilisation
Des représentations graphiques comme UML ne pouvant pas être directement reprises à
la machine, un formalisme textuel doit être créé en complément. La réalisation peut par
exemple se faire comme une extension à INTERLIS 2. Dans le cas de transformations,
pour lesquelles une saisie orientée quantité suffirait, les prescriptions d’imagerie peuvent
être aussi représentées avec des Views.
2.4.3 Implémentation des modèles de transformation
Avec la formulation de modèles et de transformations sur un plan conceptuel, nous obtenons
des „caisse à outils“, avec lesquelles nous pouvons obtenir l’interopérabilité sémantique.
Nous ne sommes ainsi pas liés à un système concret de SIG ou à un logiciel
de transformation avec un langage particulier de programmation ou de script.
De la même manière que nous sommes avec INTERLIS indépendants du format de
transfert (XML, GML, ITF), les prescriptions de transformation se laissent transposer
dans le langage de transformation, respectivement de programmation, adapté pour une
application donnée, par ex. SQL, XSLT, Xquery, iG-Skript, FME, etc.
De même que la communication des experts occupés au procédé de modélisation des
données est notablement améliorée par des moyens conceptuels et graphiques comme
UML, il est judicieux de formuler explicitement les liens et les transformations entre différents
modèles de données (de domaines similaires ou identiques). Ceci ne peut pas
être réalisé seulement avec un langage de programmation.
2.5 Conclusions
Une définition descriptive d’une transformation sémantique a sans aucun doute des
avantages, car elle fait la séparation entre définition et implémentation.
Pour ne pas fixer trop haut les attentes par rapport aux programmes de transformation,
ou courir le risque que des possibilités d’optimisation ne soient pas utilisées, il est judicieux
d’encourager la formulation de conditions particulières par des opérations spéciales.
Pour de telles opérations, il faut prévoir explicitement un code correspondant dans
Interopérabilité pour l'utilisation généralisée de la Géoinformation 11.9

Prochaines étapes dans l’interopérabilité
Modèles standardisés ou interoperabilité sémantique - perspectives de la recherche
les programmes de transformation. C’est lors de la création des programmes de transformation
que le niveau d’optimisation souhaité doit être décidé.
3 Un regard sur INTERLIS 2
Qui connaît INTERLIS 2 a remarqué, que les vues 'AllePaare' et 'GleichaltrigePaare' sont
formulables avec les moyens actuels d’INTERLIS 2.
Pour les vues dans les modèles 'UmkreisPaare' et 'NachbarPaare' ainsi que pour une vue
'GleichaltrigePaare' facile à reconnaître par le traducteur, il est nécessaire de compléter
INTERLIS 2 par des opérateurs ‘View’. On peut utiliser pour cela une ébauche similaire
aux fonctions INTERLIS déjà existantes.
Une fonction supplémentaire doit être implémentée, pour que d’une vue, les objets
puissent être engendrés conformément à une classe de modèle.
Avec un petit ajout à INTERLIS 2, il est possible de décrire la traduction sémantique
de données.
La définition d’une définition exacte fait partie d’un projet commun.
4 Avantages principaux
4.1 Communication
A part le transfert de données, il a été créé avec INTERLIS un langage commun, afin que
les hommes puissent s’entretenir d’une manière précise sur la structure des données.
De même, une compréhension générale de la description des méthodes de transformation
de données pourrait être déduite d’une telle approche.
Comme avec les modèles de données, il pourrait aussi être intéressant de trouver la définition
la plus adaptée pour la transformation des données. Un langage commun produit
de meilleurs services.
11.10 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Prochaines étapes dans l’interopérabilité
Modèles standardisés ou interoperabilité sémantique - perspectives de la recherche
4.2 Bénéfices pour un processeur
Autres outils
Editeur UML
Autres sources de
définition de
modèles et de
traduction
Modèle
I2
Compilateur I2
Modèle
en XML
Données
entrantes
Traducteur
Données
sortantes
Le traducteur est gardé abstrait. Il a les fonctionnalités suivantes :
Il est en mesure d’analyser les données qui correspondent aux modèles de données
INTERLIS 2, et peut de ce fait supporter des modèles de données relativement
exigeants.
Il est en mesure de construire des vues définies dans INTERLIS 2 sur des données
intégrées et d’exécuter des traductions de données sur la base de modèles.
On peut à ce stade ajouter, que des transformations simples de données peuvent être
définies et exécutées avec un INTERLIS 2 légèrement adapté. Comme avec les fonctions
prévues dans INTERLIS 2, des opérateurs spécifiques pour la création de vues peuvent
être définis pour des applications plus exigeantes, et codés dans le traducteur d’une
manière correspondante.
Les modèles INTERLIS 2 (y compris les traductions) peuvent être analysés avec l’éditeur
UML et formatés d’une manière encore plus définitive avec le INTERLIS 2-Compiler
(par exemple dans INTERLIS 2 ou XMI). Comme solution alternative, il est aussi possible
de produire de telles données de description de modèles et de traductions avec
d’autres outils (indépendants d’INTERLIS). Ces définitions de modèles et de traductions
sont lues par le traducteur. Ce dernier sachant ainsi comment traiter les données d’input
pour en faire des données d’output.
De par cette claire séparation des composants individuels, on obtient une grande adaptabilité
aux différents besoins que l’on trouve dans des situations concrètes de système.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 11.11

12
Migration des données UIC
Théophil Engel, UIC / SBB
Théo Engel, Dr.
SBB-Infrastruktur-Asset Management, Programmanager Fahrstrom
Schanzenstrasse 5
CH-3000 Bern 65
Tél :
Fax :
E-mail :
+41 51 220 21 80
+41 51 220 39 19

1 Contexte
1.1 Vue d’ensemble
1.1.1 Entrée
La construction de voies de chemin de fer repose depuis longtemps sur des tracés à base de coordonnées.
Depuis les années 90, leur usage est étendu à l’entretien systématique. Les avantages
financiers et techniques sont considérables et généralement reconnus. Les tracés numériques
sont également la base d’une amélioration de l’interopérabilité de toutes les installations de
l’infrastructure. L’harmonisation transfrontalière des références de cordonnées, stipulée par
l’Union Européenne est une condition de base pour un élargissement des champs d’utilisation
tels que p.ex. la navigation par satellite.
1.1.2 Quatorze Phrases clé
1 Définition absolue des voies de chemins de fer à base de coordonnées (CNTD), le fondement de
la construction et de l’entretien moderne des voies //2 Projet UIC Georail comme nouvelle étape
de consolidation dans la direction de l’introduction des coordonnées absolues au chemin de fer //3
Définition : géodésie ferroviaire, CNTD //4 Les principes les plus importants dans l’usage de ces
données clé de l’infrastructure //5 Les avantages économiques et techniques de l’utilisation des
tracés à base de coordonnées absolues //6 Importance du potentiel d’optimisation grâce aux coordonnées
absolues au niveau des processus //7 Un traitement exhaustif implique une approche
transfrontalière //8 Approfondissement substantiel sur des questions de référence des coordonnées,
de standardisation des données et d’interfaces des données //9 Répondants de Georail Phase
2 : entreprises de constructions des voies, Eurogeographics (services topographiques européens),
recherche, littérature de construction ferroviaire //10 Concertation interne UIC avec le projet
TMG (Track Machine Guidance) //11 Dialogue entre l’UIC avec Eurogeographics. Centre ferroviaire
comme répondant de Eurogeographics ? //12 Suite du travail au niveau du pilotage : Directive
UIC en tant que ligne directrice //13 Suite du travail technique : Règlements nationaux et
troisième édition du livre « Eisenbahnbau » - Wichmann Edition, 2006-7 //14 Reprise des idées
de Georail par le groupe d’experts des voies de l’UIC ?
1.1.3 Buts de GEORAIL et contenu du rapport
Clarification des questions fondamentales liées à l’usage des coordonnées pour la construction
des voies. Esquisse de premières idées favorisant l’interopérabilité de tous les
objets de l’infrastructure par l’usage de coordonnées.
Le premier chapitre donne une vue sur la thématique des coordonnées des chemins de
fer avec l’accent sur les applications de la voie. Le second chapitre reflète les principaux
résultats obtenus dans le cadre du projet UIC dans le domaine de la transformation sémantique.
Le troisième chapitre dessine la future orientation.
1.2 Développement historique
La définition continue des tracés à base de coordonnées numériques, CNTD (en anglais,
continuous numeric track definition) s’est imposée durant les années 90 comme base des
travaux de voie. Les grands réseaux ferroviaires prévoient leur introduction où ils l’ont
déjà effectué. L’industrie des voies les utilise pour le pilotage des machines.
Les mots-clés du point de vue économique pour le travail de voie sont : usage simple,
uniformité méthodologique sur l’ensemble du réseau ferroviaire, précision et fiabilité
Interopérabilité pour l'utilisation généralisée de la Géoinformation 12.1

Prochaines étapes dans l’interopérabilité
Migration des données UIC
opérationnelle, pas de « spécialités » d’utilisation. Il en découle deux challenges pour les
géodésiens :
- L’harmonisation des réseaux géodésiques hétérogènes sur le plan européen.
- La représentation (globale) plane des tracés des voies spatiales.
A l’UIC, les travaux de voie représentent le thème clé du groupe des experts voie. Classiquement
ils ne connaissent pas les coordonnées. Les premières contributions sur
l’usage des coordonnées pour les travaux de voie viennent du groupe FIG 6.4 „Track
and utility line“ de la FIG (Fédération Internationale des Géomètres). FIG 6.4 postule le
contact avec les spécialistes de la voie : la direction n’appartient pas, à long terme à la
FIG mais à l’UIC. C’est à eux que revient la direction de ces travaux. Le transfert se fait
par étapes :
1990 – Décision de la FIG de s’engager dans la géodésie ferroviaire.
1996 – Les présidents de la FIG et de l’UIC établissent un premier contact.
2000 – Les Experts Voie de l’UIC prennent la direction du projet de coordonnées du pilotage
des machines de chantier sous la direction des chemins de fer suédois
(BV).
2002 – Début du projet Georail et fin de l’engagement de la FIG.
2004 – Première „Open Rail Session“ sous le patronage de l’UIC.
Hormis les partenaires ferroviaires, les domaines suivants sont impliqués dans Georail :
- La commission ExG-G (expertgroup geodesy, groupe de travail géodésique)
de Eurogeographics, comme représentant des services topographiques nationaux.
D’entente avec la commission Européenne ils fixent dans les années
90 ETRS89 comme référentiel européen unique.
- ISO/TC211 et CEN TC287 pour les questions de standardisation des données.
- Les représentants de l’industrie de machines Plasser-Theurer et Müller AG.
- La recherche, représentée par l’institut de géodésie de l’EPF Zurich.
- La littérature de construction ferroviaires par les auteurs principaux de „Eisenbahnbau“
(G. Müller, Wichmann Verlag 2000), Hochschule für Technik
und Wirtschaft de Dresde.
1.3 Quelques notions de base
CNTD ou Continuous Numeric Track Definition est le terme anglais pour les tracés absolus
à base de coordonnées.
CNTD décrit la géométrie des voies à trois dimensions à l’aide d’une succession
d’éléments mathématiques précis et univoques de la voie de sorte à pouvoir déterminer
à chaque point du tracé, sa position en plan, en altitude et en dévers.
Avec le CNTD, les éléments suivants forment la base de la géodésie ferroviaire :
- Les données d’ordre, comme clé d’interrogation et de structuration des
données, sous forme de tracés de ligne numériques, univoques. Groupés à
l’échelle du réseau, ces tracés, appelés « axe kilométrique », forment les réseaux
des lignes des compagnies ferroviaires.
- Les points de référence géodésiques. C’est par ces points que les données
ferroviaires sont rattachées au système de coordonnées absolu. Ces points
12.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Prochaines étapes dans l’interopérabilité
Migration des données UIC
comprennent aussi la fonctionnalité de repères de la voie, ce qui entraîne les
avantages décrit au paragraphe suivant.
- Des points d’axes de voie et les points critiques de l’espace libre qui constituent
les éléments de base du calcul des tracés.
La géodésie ferroviaire est un domaine particulier de la géodésie d’ingénieur qui comprend
toutes les procédures et données géoréférencées, nécessaires à la structuration
topologique, à la gestion et à l’utilisation interdisciplinaire des tracés numériques des
voies.
Les axes km forment le noyau du modèle hiérarchique structuré des données à base de
coordonnées de l’infrastructure (figure 1.1). Le second niveau autour du noyau, comprend
les données de voies, utilisées par tous les services spécialisés. La troisième couche
comprend les données principales des services spécialisés et la dernière couche est
constituée des données dont l’intérêt se limite à un service particulier.
Cette manière de structuration permet de remplacer l’accès aux données à deux valeurs
de coordonnées par un accès unidimensionnel de kilométrage, soit une facilité considérable
au niveau de l’organisation des algorithmes de recherche.
Infrastructure des objets avec référence
spatiale, selon le modèle des couches :
Noyau : Le réseau de tronçon avec les nœuds
(points de service) et les côtés (tronçons)
Première couche : Réseau des voies
Deuxième couche : Données centrales
Troisième couche : Données dont l’intérêt est
limité
CNTD : points de référence géodésique et des
données du noyau et du premier niveau
Figure 1.1 : Modèle de couches hiérarchiques des données à base de coordonnées de
l’infrastructure
1.4 Développement technique
Le développement du CNTD est le résultat de l’étroite collaboration entre spécialistes
des mensurations, du service de la voie et de l’informatique. Le développement du
CNTD prend son origine dans le quotidien ferroviaire selon le mode « par des utilisateurs
pour des utilisateurs ».
Trois décennies de développement caractérisent le développement comme suite :
- Années 80 : divers développements selon l’approche « Bottom-up »
- Années 90 : différentes phases de consolidation individuelle au sein des
chemins de fer mais sans coordination transfrontalière.
- Dès 2000 : maturité opérationnelle des systèmes avec des gains économiques
dans le domaine de la voie. Premiers efforts de coordination internationale.
L’optimisation sur le plan des processus et de l’organisation est le prochain pas de développement
important.
Le CNTD met fin aux méthodes de calcul de tracés relatifs.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 12.3

Prochaines étapes dans l’interopérabilité
Migration des données UIC
Ces anciennes méthodes sont toutes basées sur le principe des flèches. A l’aide d’une
corde, tendue entre deux points, on mesure la flèche d’un segment de courbe que l’on
compare à une valeur théorique. Dès 1940, les chemins de fer commencent à entretenir
les courbes de leur réseau des voies de cette manière. Des coupons de rails plantés latéralement
à un mètre de la voie tous les 20m de distance, servent de points de référence
aux tracés, ce sont les points de repérage. Les alignements entre les courbes ne sont en
principe pas repérés.
L’impulsion pour un changement provient :
- De l’industrie des machines de construction des voies, qui fait des progrès
décisifs dans l’automatisation du pilotage des machines.
- Des chemins de fer qui commencent à calculer des tracés numériques des
voies à base de coordonnées.
Le pas décisif est franchi, lorsque les fonctionnalités « point de repérage » et « point fixe
géodésique » sont réunis. Les machines de voies parviennent, grâce aux progrès dans la
détermination automatisée du pilotage des machines et aux coordonnées des points de
repérage, à déterminer en chaque point de la voie et en temps réel la position actuelle de
la voie ainsi que la différence entre cette position et les tracés théoriques. Le résultat sert
au pilotage des machines de voie, dont la valeur est générée à partir des données de
voies suivantes :
- Des repères définis en coordonnées,
- Des tracés théoriques continus en coordonnées,
- Une référence homogène univoque à l’échelle du réseau,
- La détermination automatique de la position effective des voies.
Les conditions fixées pour l’utilisation des machines de voie dans le cadre de l’entretien
systématique à l’échelle du réseau, sont ainsi pleinement satisfaites : usage simple, uniformité
méthodologique sur l’ensemble du réseau ferroviaire, précision et fiabilité opérationnelle,
pas de « spécialités ».
Le processus d’automatisation fonctionne aujourd’hui de manière différenciée dans la
pratique :
- Pour les repères matérialisés comme points de mesure géodésiques sur les
pylônes de la ligne de contact, la méthode est pleinement opérationnelle et
mûrie.
- La variante, où on ne travaille plus qu’avec un positionnement par satellite
n’est qu’en voie d’élaboration. En lieu et place du repérage le long des voies,
il n’existe plus que des points de référence géodésiques à proximité des
voies, déterminés par GPS tous les deux km. Les problèmes non résolus
sont :
L’absence de signaux GPS dans les zones d’ombre (p.ex. dans les tunnels,
pour les zones couvertes des gares, ...).
Une précision insuffisante pour des parties critiques du réseau, tels p.ex.
des groupes d’appareils de voies complexes – souvent dans les entrées et
sorties des gares d’une certaine taille – les tracés fixe et surtout les tronçons
de grande vitesse. A ces endroits, une précision répétitive
d’implantation de l’ordre du mm doit être assurée, alors que de manière
générale ±5mm sont requis pour bénéficier de tous les avantages du travail
avec des coordonnées absolues.
12.4 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Prochaines étapes dans l’interopérabilité
Migration des données UIC
Le moteur pour l’harmonisation des références de coordonnées vient, pour le domaine
de la voie, des besoins du positionnement par satellite, où une précision maximale ne
peut être obtenue qu’à travers des réseaux exempts de toute tension.
1.5 Facteurs de gain
Accroissement de la qualité de la position de la voie
Améliorations économiques
Hiérarchie des données
Optimisations fonctionnelles : appui des processus
En résumé : effet catalyseur et synergies grâce aux coordonnées.
2 Transformation sémantique
Les travaux du deuxième chapitre ont été effectués par l’EPFZ dans le cadre du projet
Georail de l’UIC.
2.1 Modélisation des données d’ordre
La base pour la modélisation des données d’ordre est constituée par les données de ligne
issues de la banque de donnée des installations fixes (DfA) ainsi que les nœuds de
station. De cet extrait significatif de la réalité le schéma conceptuel est établi à l’aide du
CSL INTERLIS.
2.2 Standardisation de l’interface des données d’ordre
Le compilateur teste le schéma textuel. Dès que ce test fonctionne sans faute, on en extrait
la description du format de transfert (schéma physique). Dans le présent exemple
on utilise le format de transfert ITF de INTERLIS. De manière analogue, on peut également
produire les formats de transfert XTF ou GML. Le schéma physique comprend
l’information sur la manière de structurer des données de transfert.
Selon de format standard, les données initiales sont restructurées. Dans la plupart des
cas un simple langage de programmation ou d’encryptage suffit, par exemple awk. Awk
est un langage simple d’encryptage sur la base de la reconnaissance de modèles, à l’aide
duquel des simples données ASCII peuvent systématiquement être transformées en
format standard.
2.3 Visualisation des données de ligne et de stations à l’aide de
Geoshop
Les données CFF se trouvent maintenant dans le format de transfert INTERLIS indépendant
d’un système (ITF). A l’aide d’un logiciel qui supporte INTERLIS, il est possible
de les visualiser. Par la suite on utilise « GeoShop » un logiciel basé sur des standards
systèmes neutres. Il permet le traitement de géodonnées de structures variées (spécifiquement
la visualisation, la diffusion et la vente des données) par Intra- ou Internet.
GeoShop comprend trois modules :
- Geoshop Server. Cette partie centrale du programme gère les données géographiques
ainsi que les informations des utilisateurs.
- Geoshop Client Tools : Ils permettent la visualisation et la diffusion des données
avec des clients, ne nécessitant qu’un navigateur compatible Java.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 12.5

Prochaines étapes dans l’interopérabilité
Migration des données UIC
- Geoshop Administrator Tools : Ils pilotent la configuration du serveur, le statut
des utilisateurs et des commandes ainsi que les représentations graphiques.
2.4 Modélisation des données des services spécialisés : ligne de
contact AE
Dans une prochain étape, il s’agit de rendre exploitable le contenu de banques de données
rattachées à l’aide de modélisation, en supposant que les deux tables contiennent
au moins un attribut commun. Comme exemple, la géométrie des données du réseau de
ligne est tirée pour visualiser l’information de la ligne de contact des CFF.
Les informations de la ligne de contact se trouvent dans un tableau Excel, où chaque ligne
correspond à un tronçon de la ligne de contact. La table comprend un attribut pour
chaque tronçon de la ligne de contact, par exemple l’année de la première électrification.
Bien que les lignes de contact aient une localisation univoque, la table ne comprend pas
de coordonnées. Le seul attribut est constitué par les valeurs kilométriques (km de, km
à) qui constituent chaque fois le début et la fin d’un tronçon de ligne de contact. Les axes
kilométriques du réseau des lignes sont répartis en plusieurs tronçons de lignes de
contact qui se composent d’un multiple de tronçons de ligne.
Baujahr Fahrleitung
BPK von Linie von Fil von LinieKorr km von
Lausanne 100 100 West Lausanne 0.0000
St-Maurice 100 100 West St-Maurice 51564.9400
Sion 100 100 West St-Maurice 92432.0600
Brig 100 100 West Brig 145548.5000
Brig Tunnel 109 109 West Brig 147149.9000
Vevey Ouest (bif) 111 111 West Lausanne 762.5000
BPK bis Linie bis LinieKorr km bis Jahr 1. El.
St-Maurice 100 100 St-Maurice 51564.9400 1924
Sion 100 100 St-Maurice 92432.0600 1923
Brig 100 100 Brig 145548.5000 1919
Iselle di Trasquera 100 100 Brig 167478.3100 1906
Iselle portail tunnel 109 109 Brig 166973.4000 1922
Puidoux-Chexbres 111 111 Lausanne 7829.0000 1940
Fig. 2.1: Extrait du fichier Excel des données de la voie
Le développement de données de la ligne de contact avec leur cheminement issu de
données qui ne comprennent que la valeur de kilométrage au début et à la fin et de
données d’ordre, avec le tracé géométrique est un exemple typique d’une transformation
sémantique.
12.6 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Prochaines étapes dans l’interopérabilité
Migration des données UIC
D’abord on décrit la classe de départ des données de lignes de contact à l’aide de UML
et INTERLIS. Il en résulte une classe UML « ligne de contactAE » et une classe INTER-
LIS « Ligne de contact ».
2.4.1 Standardisation de l’interface de service spécialisé : ligne de contactAE
Du modèle INTERLIS on peut automatiquement déterminer la description de format de
la classe „ligne de contactAE“. Avec un processeur 1:1, les données du tableau Excel
sont transformées en format standard ITF.
2.4.2 Modélisation des données de service spécialisé : ligne de contact (avec
tracé)
Comme fichier cible de la transformation sémantique nous voulons définir la classe „ligne
de contact“ avec seulement deux attributs : l’attribut « électrification initiale » (Erstelektrifizierung)
repris de la classe « ligne de contactAE » (Fahrleitung) et l’attribut « itinéraire
» du type POLYLIGNE, qui est nouvellement calculé à partir des attributs « km
de » et « km à » de la classe « ligne de contact » et de l’attribut « itinéraire »de la classe
« axe ». Le diagramme UML de cette nouvelle classe « Ligne de contact » correspond à la
figure 2.2 et le modèle INTERLIS de donnée à la figure 2.3.
Fahrleitung
Erstelektrifizierung
Figure 2.2 : Modèle graphique de la nouvelle classe „Ligne de contact“ (UML-Diagramm)
TABLE Fahrleitung =
Erstelektrifizierung: [1900 .. 2500];
Verlauf: POLYLINE WITH (STRAIGHTS, ARCS) VERTEX Koord2
WITHOUT OVERLAPS > 0.50000;
NO IDENT
END Fahrleitung;
Fig. 2.3: Nouvelle classe „ligne de contact“ (avec tracé), modèle INTERLIS
2.4.3 Transformation sémantique
Sont à disposition maintenant : les modèles de données INTERLIS comme données initiales
„axe“ (de 2.4.1) et „ligne de contactAE“ (de 2.4.2) ainsi que le fichier but „ligne de
contact“ (de 2.4.3) puis les données „axe“ et „ligne de contact“ en format standard ITF de
INTERLIS.
Il existe des logiciels, tels le système INTERLIS-Conversion Système ICS, qui permettent
de définir conceptuellement la transformation de deux (ou plusieurs) classes données en
une nouvelle classe (ou plusieurs) à l’aide de modèles de transformations adéquat. La
fonction de transformation dont nous avons besoin s’appelle :
Découper de la ligne de la classe „axe“ du point initial « km de » jusqu’au point « km à » d’un
objet de la classe « ligne de contact AE » et stocker ce tronçon de ligne avec l’attribut « année de
la première électrification » de la classe « ligne de contact AE » comme nouvel objet de la classe
« ligne de contact ».
Interopérabilité pour l'utilisation généralisée de la Géoinformation 12.7

Prochaines étapes dans l’interopérabilité
Migration des données UIC
[……]
TABL Fahrleitung
OBJE 0.0000.0100 1924
STPT 537875.40604 152041.99120
LIPT 537984.59908 152018.12626
ARCP 538041.11107 151980.47901
[..]
ARCP 566299.34338 118421.92351
LIPT 566299.35779 118418.30702
ELIN
[.....]
OBJE 1763.3040.7744 1925
STPT 681720.79964 248756.00813
LIPT 681721.16279 248758.52014
ARCP 681761.91402 248844.22701
[..]
LIPT 683823.44151 247149.25542 0.000 -263.000
LIPT 683786.02309 247064.53648
ELIN
ETAB
[……]
Fig. 2.4: Extrait du fichier ITF de la nouvelle classe „ligne de contact“ (avec tracé)
2.4.4 Visualisation des données de ligne de contact (avec tracé) dans GeoShop
Le fichier ITF de la nouvelle classe „ligne de contact“ (avec itinéraire“ peut être utilisé
comme donnée par « Geoshop ». Lors de la visualisation dans le « GeoShop » on colorie
les différentes classes d’âge de la ligne de contact avec des couleurs différentes (figure
2.5).
12.8 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Prochaines étapes dans l’interopérabilité
Migration des données UIC
3 Avenir
Fig. 2.5 : Visualisation de la ligne de contact dans Geoshop (avec légende)
3.1 Suite? Idées directrices
3.1.1 Justesse des données
Les données sous forme de coordonnées ne sont utilisables qu’à partir du moment où
tout fonctionne dans tous les domaines : référence spatiale ; structure des données, exhaustivité
des données, justesse des données, topologie des données, vue réseau 100%.
3.1.2 Harmonisation globale des structures des données
L’harmonisation des structures de données comme élément de la correspondance des
données est le fondement de l’interopérabilité. La mise en pratique de cette tâche à
Interopérabilité pour l'utilisation généralisée de la Géoinformation 12.9

Prochaines étapes dans l’interopérabilité
Migration des données UIC
l’échelle européenne est la tâche clé de l’UIC. Le point de départ est toujours la situation
de la structure des données existante des valeurs déjà saisie par les différentes compagnies.
Le but à long terme est une structure de donnée adoptée par l’UIC et supportée
par les compagnies individuelles. L’utilisation d’un logiciel uniforme est un premier niveau
d’harmonisation concret.
3.1.3 Harmonisation des structures de données dans des zones voisines, non
adaptées
Si des zones frontalières où des réseaux différents se touchent ou bien si les chemins de
fer n’ont pas les moyens pour procéder à une harmonisation, respectivement si les adaptations
techniques seraient trop grandes, les données peuvent être maintenues sans aucun
changement. Des travaux de la modélisation des données ressort qu’il est toujours
possible de les réunir ultérieurement. Malgré cela il est recommandé de tester les structures
quand à leur consistance, en élucidant les inconsistances le plus tôt possible.
3.1.4 Passage entre différents systèmes de coordonnées
Afin de pouvoir appondre les coordonnées adjacentes non harmonisées, il faut disposer
le long des tronçons traversant les zones de transition, de points fixes calculés dans les
deux systèmes pour en déduire les paramètres de transformation pour le passage d’un
système à l’autre. Le facteur d’échelle de ces transformations doit toujours être égal à un
pour ne pas modifier les cotes des parties constructives tels les appareils de voie.
3.1.5 Adaptation avec les réseaux de la mensuration officielle
L’adaptation implique obligatoirement le dialogue entre les chemins de fer et la mensuration
officielle pour éviter des investissements à double lors de l’établissement du réseau
des points fixes. Il est utile d’avoir dans les zones de transition, en plus des coordonnées
des deux systèmes voisins, un troisième élément donnée sous forme de coordonnées
ETRF89 et d’en calculer les paramètres de transformation.
3.2 Suite? Concrètement
De la clarté et de l’uniformité doivent appuyer l’introduction de CNTD selon des bases
de géodésie ferroviaire, afin de permettre aux partenaires européens de l’UIC dès le début,
d’obtenir les meilleurs résultats possibles avec la nouvelle technologie de coordonnées.
Une directive doit d’abord fixer la direction vers laquelle se diriger pour le domaine de
la voie, puis pour tous les futurs usages qui viendront s’y greffer.
Remerciements
A tous les collaborateurs de l’EPF, de l’UIC, de la DB, de la SNCF, des CFF qui ont
contribué à ce texte.
12.10 Interopérabilité pour l'utilisation généralisée de la Géoinformation

13
Intégration des données de la carte
nationale 1:25’000 (VECTOR25) dans le
modèle de données de la mensuration
officielle (MD.01-MO-CH)
Robert Balanche, direction fédérale des
mensurations cadastrales/swisstopo
Robert Balanche
Seftigenstrasse 164
CH-3084 Wabern
Tél :
Fax :
E-mail :
+41 31 963 21 11
+41 31 963 22 97

1 Introduction
Les données de la mensuration officielle sont devenues, particulièrement depuis le début
de la réalisation de la Réforme de la Mensuration Officielle (REMO), toujours plus
populaires, principalement en raison de la stratégie qui avait été choisie à l'époque, prévoyant
un concept basé modèle pour la gestion des données numériques. On peut affirmer
que cette solution était alors visionnaire, on en mesure aujourd'hui seulement, les
bénéfices et avantages.
De part notre système fédéraliste et l'organisation décentralisée de la mensuration officielle
suisse, l'avancement des travaux de nouvelles mensurations est très différent d'un
canton à l'autre ou d'une région à une autre. Aujourd'hui encore, les données de la MO
ne recouvrent pas l'entier du territoire national, cet état de fait retient bon nombre de
client potentiel d'utiliser ce jeu de données très précis et très fiable.
Pour combler ce manquement, le département fédéral de la défense, de la protection de
la population et des sports (DDPS) a établi une stratégie pour la mensuration officielle
pour les années 2004-2007 et une vision pour les années suivantes 1 . Ce document indique
que les données de référence de l'Infrastructure National de Données Géographique
(INDG), et donc celles de la MO, doivent à cet égard remplir les conditions suivantes :
a. Un modèle de données existe,
b. Les données recouvrent l'ensemble du territoire,
c. L'intérêt public est réel,
d. Les données ont une qualité définie,
e. La mise à jour est garantie,
f. Le financement est assuré.
Pour atteindre le second élément de cette liste, il est prévu de recourir à des produits de
remplacement provisoires (PRP) simples à titre de solution transitoire.
Les produits de remplacement provisoires (PRP) sont des données vectorielles numérisées,
décrites dans le modèle de données de la MO et échangeables via l’interface de la
mensuration officielle (IMO). Leur actualité, leur exactitude et la teneur en informations
ne remplissent pas les exigences de la MO. Ils servent exclusivement à l’utilisation de la
MO comme donnée de référence pour des systèmes d’information du territoire et non
pas pour les besoins du registre foncier.
Les PRP complètent la MO là où elle ne dispose pas de données ou bien dans les régions
où seuls existent des plans cadastraux graphiques. Ils peuvent également compléter les
composantes existantes des données numériques de la MO avec des couches
d’information ou thèmes manquants.
On prévoit d'obtenir des PRP pour les couches d’information „couverture du sol“, „objets
divers“ et „nomenclature“ à partir de produits numériques existants (p. ex. VEC-
TOR25 et SwissNames de swisstopo).
Le présent article se consacre à l'interface prévue pour récupérer les données issues des
données vectorisées de la carte nationale au 1:25'000 (VECTOR25) dans le modèle de
données de la mensuration officielle MD.01-MO-CH, version 24.
1
http://www.swisstopo.ch/data/vd/Documents/Strategie_MO_04_07.pdf
Interopérabilité pour l'utilisation généralisée de la Géoinformation 13.1

Prochaines étapes dans l’interopérabilité
Intégration Vector25 / MO
2 Comparaison des données VECTOR25 et de la MO
2.1 Les données VECTOR25
VECTOR25 est le modèle numérique du paysage de la Suisse qui se base sur le contenu
et la géométrie de la Carte nationale 1:25’000. VECTOR25 restitue, dans un format vectoriel
flexible, les objets naturels et artificiels du territoire. Il se prête spécialement à une
utilisation dans des systèmes d’informations géographiques (SIG). VECTOR25 décrit
environ 8.5 millions d’objets avec leur situation, leur forme, leur catégorie d’objets,
d’autres attributs et leur relation avec leur environnement (topologie). Son périmètre
couvre l’ensemble de la Suisse et les régions frontalières conformément au périmètre de
la carte nationale 1:25’000. Les données de VECTOR25 sont gérées indépendamment du
découpage en feuilles. Les objets de grande dimension (telles que des zones boisées très
étendues) sont artificiellement subdivisés en entité appropriée plus petite afin de garantir
un niveau de maniabilité satisfaisant des données.
2.1.1 Structure des données VECTOR25
VECTOR25 se compose de 9 couches thématiques :
Couches thématiques Description
Réseau routier
Réseau des routes et des chemins
Réseau ferroviaire
Réseau des chemins de fer
Autres moyens de transport Bacs, téléphériques, etc.
Réseau hydrographique Axes des cours d’eau et de rive
Surfaces primaires
Couverture du sol primaire (forêt, lac, etc.)
Bâtiments
Divers types de bâtiments
Haies et arbres isolés Diverses catégories d’objets de végétation
Surfaces aménagées
Aires artificielles et aménagées
Objets isolés
Diverses catégories d’objets artificiels
Chaque couche comprend différents types de topologie (p.ex. lignes des surfaces primaires).
Chaque couche et type de topologie est défini par une série d’attributs comprenant
au minimum les attributs standards (ObjectId, ObjectOrigin, ObjectVal, YearOf-
Change). VECTOR25 contient au total env. 150 catégories d’objets différentes (p.ex. routes
de 2e classe, ruisseaux).
2.1.2 Qualité des données de VECTOR25
VECTOR25 se distingue par les critères de qualité suivants :
couverture complète de qualité et forme homogènes
découpage libre sur l’ensemble du périmètre
précision de position : 3-8m (correspond à la précision de la carte)
possibilités d’analyses et de simulations grâce à la topologie
dimensions géométriques minimale et maximale pour chaque objet ( application
facilitée)
possibilité d’arrondir les coordonnées au m ou dm sans perte de la topologie
identification des objets univoque et stable ( condition nécessaire pour des mises
à jour incrémentielles)
géométrie simple ( pas de difficulté lors de transfert ou d’application sur
d’autres SIG ou système CAO-DAO).
13.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Prochaines étapes dans l’interopérabilité
Intégration Vector25 / MO
2.2 Le modèle de données de la mensuration officielle
La réforme de la mensuration officielle (REMO) au début des années nonante a donné
naissance au premier modèle de données de la mensuration officielle suisse, le MD.93.
Ce modèle, partie intégrante de l'Ordonnance technique du DDPS sur la mensuration
officielle (OTEMO) 2 , représentait le minimum légal que les cantons devaient respecter
tant au niveau du contenu que de l'organisation des donnés de la MO. Les cantons ont
souvent étendu ce modèle de base avec leurs spécificités cantonales, ainsi depuis les années
1993, toutes les entreprises de mensurations étaient basées sur ce modèle de données.
On mesure aujourd'hui l'avantage de posséder des données pour tout le pays organisées
et structurées selon un modèle commun.
A la fin des années nonante, le besoin s'est fait sentir d'élaborer un nouveau modèle de
données qui devaient corriger les erreurs de jeunesse du premier modèle et l'adapter
pour satisfaire aux nouvelles exigences. Ainsi le 18 décembre 2001, fut publié le nouveau
modèle de données 2001 de la mensuration officielle nommé MD.01-MO-CH. Malheureusement
celui-ci comportait encore un thème provisoire, celui des adresses de bâtiment
du fait que la norme suisse correspondante avait pris du retard dans sa conception.
Finalement en juin 2003, la norme suisse des adresses de bâtiment (SN612040) a été
publiée et deux semaines plus tard la version du MD.01-MO-CH, version 24, reprenant
totalement la norme précitée, était officialisée.
2.2.1 Structure du MD.01-MO-CH
Les données de la mensuration officielle sont structurées selon 8 couches d'informations:
1. Points fixes
2. Couverture du sol
3. Objets divers
4. Altimétrie
5. Biens-fonds
6. Conduites
7. Divisions administratives
Le modèle de données de la mensuration officielle est quand à lui structuré selon 20
thèmes distincts :
1. Points_fixesCategorie1
2. Points_fixesCategorie2
3. Points_fixesCategorie3
4. Couverture_du_sol
5. Objets_divers
6. Altimetrie
7. Nomenclature
8. Biens_fonds
9. Conduites
10. Domaines_numerotation
11. Limites_commune
12. Limites_district
13. Limites_canton
14. Limites_nationales
15. Repartitions_plans
16. RepartitionNT
17. Zones_glissement
18. NPA_Localite
19. Adresses_des_batiments
20. Bords_de_plan
2
http://www.admin.ch/ch/f/rs/c211_432_21.html
Interopérabilité pour l'utilisation généralisée de la Géoinformation 13.3

Prochaines étapes dans l’interopérabilité
Intégration Vector25 / MO
2.2.2 Qualité des données de la MO
La qualité des données de la MO est très élevée et est représentée selon un critère de
précision et de fiabilité. L'exigence de qualité diffère selon la région considérée. En effet,
plusieurs niveaux de tolérance ont été établis en fonction de critères régionaux, ceux-ci
sont définis dans l'OTEMO à l'art 3 :
NT1: régions urbaines
NT2: régions construites et zones à bâtir
NT3: régions agricoles et forestières d'exploitation intensive
NT4: régions agricoles et forestières d'exploitation extensive
NT5: régions d'estivage et régions improductives
L'OTEMO définit aux articles 28 et suivants la précision des données selon la couche
d'information et le niveau de tolérance correspondant. On trouve, par exemple pour les
couches d'information "biens-fonds" et "conduites", les valeurs de précision suivantes :
La précision planimétrique (écart-type en cm) pour un point défini exactement dans le
terrain est :
NT2 NT3 NT4 NT5
3.5 7 15 35
N.B. le NT1 (régions urbaines) doit satisfaire au moins aux exigences du NT2.
Pour ce qui est de la fiabilité l'article 33 de l'OTEMO indique :
"La preuve de fiabilité doit être apportée pour chaque point des couches d'information "points
fixes", "biens-fonds" et pour les limites territoriales de la couche d'information "divisions administratives",
ainsi que pour les points particuliers…"
3 Transfert des données de VECTOR25 dans le
MD.01-MO-CH
3.1 Divergence entre les jeux de données
D'après le descriptif de la structure des données du VECTOR25 et des données du modèle
de données de la mensuration du chapitre 2, on se rend vite compte que, non seulement,
les objets ne sont pas structurés de la même manière, mais que la définition
même des informations est différente. En effet, si on étudie d'un peu plus près la définition
de la couverture du sol, on est confronté à deux approches bien différentes de la
même réalité. Du côté de VECTOR25, on a la description suivante pour la couche "Surfaces
primaires" :
La couche Surfaces primaires décrit la couverture du sol. Les différents types de surface de cette
couche (lac et forêt) se délimitent réciproquement et forment un réseau de surfaces sans redondance
et sans lacune. Contrairement à la Carte nationale, la couche Surfaces primaires présente
les zones d’habitation sous la forme de surface (interprétée). Les bâtiments isolés sont proposés en
tant que couche thématique séparée.
13.4 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Prochaines étapes dans l’interopérabilité
Intégration Vector25 / MO
La description de la couverture du sol dans la mensuration officielle est définie à l'article
7, al. b de l'OTEMO :
1. bâtiments,
2. surfaces à revêtement dur subdivisées en : route/chemin, trottoir, îlot, chemin de
fer, place d’aviation, bassin et autre surface à revêtement dur,
3. surfaces vertes subdivisées en : pré/champ/pâturage, culture intensive (ellemême
subdivisée en vigne et autre culture intensive), jardin, tourbière et autre
surface verte,
4. eaux subdivisées en : eau stagnante, cours d’eau et roselière,
5. surfaces boisées subdivisées en : forêt dense et autre surface boisée,
6. surfaces sans végétation subdivisées en : rocher, glacier/névé, éboulis/sable,
gravière/décharge et autre surface sans végétation
Deux grandes divergences apparaissent entre ces jeux de données au niveau de cette
couche d'information. La couverture du territoire selon VECTOR25 n'inclue ni les bâtiments,
ni les routes. Cela signifie que lors de la préparation du transfert des données de
VECTOR25 vers le MD.01-MO-CH, ces éléments devront être regroupés et la partition
du territoire devra être à nouveau redéfinie. Ceci est un exemple pour lequel une solution
doit être trouvée.
VECTOR25
Surfaces primaires
(Partition du territoire)
MD.01-MO-CH
Couverture du sol
(Partition du territoire)
Bâtiments
Routes
(Surface)
(Poly Li-
)
Figure 1 : Divergences entre la couverture du sol de VECTOR25 et du MD.01-MO-CH
3.2 Correspondances des objets
Lors de la préparation d'un tel échange de données, une des premières étapes à exécuter
est de définir un tableau de correspondances définissant clairement la cible des objets
sources. Cet un travail relativement long et toujours sujet à discussions. Il arrive, en effet,
que certains objets n'existent pas dans l'un ou l'autre des jeux de données. Dans le
cas où un objet existe dans le jeu de données source et pas dans le jeu de données cible,
doit-on choisir de l'ignorer ou de le transférer tout de même pour éviter une perte d'information
?
Les tableaux ci-dessous indiquent pour chaque objet de chaque couche du VECTOR25,
le thème et le genre d'objet correspondant dans le MD.01-MO-CH.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 13.5

Prochaines étapes dans l’interopérabilité
Intégration Vector25 / MO
3.2.1 Réseau routier
Vector25.ObjectVal Description Cible MD.01-MO-CH
Autobahn Autoroute route_chemin
Autob_Ri Autoroute, chaussées séparées route_chemin
Autostr Semi-autoroute route_chemin
Ein_Ausf
Entrée / Sortie (Autoroute /
Route)
route_chemin
A_Zufahrt Accès d'autoroute route_chemin
1_Klass Route de 1re classe route_chemin
2_Klass Route de 2e classe route_chemin
3_Klass Route de 3e classe route_chemin
4_Klass Route de 4e classe route_chemin
5_Klass Route de 5e classe sentier
6_Klass Route de 6e classe sentier
Q_Klass Route de quartier route_chemin
HistWeg Route / chemin historique sentier
PzPiste Piste pour chars d'assaut sentier
Parkweg Chemin de parc sentier
BrueckLe Pont isolé tunnel_passage_inferieur_galerie
GedBruLe Pont couvert isolé tunnel_passage_inferieur_galerie
StegLe Passerelle isolée tunnel_passage_inferieur_galerie
3.2.2 Réseau ferroviaire
Vector25.ObjectVal Description Cible MD.01-MO-CH
Gt_Bahn
Ligne avec desserte ferroviaire
marchandise
voie_ferree
I_Geleis Voies industrielles voie_ferree
MS_Bahn Chemin de fer-musée voie_ferree
NS_Bahn1
Chemin de fer à voie normale
unique
voie_ferree
NS_Bahn2
Chemin de fer à voie normale
multiple
voie_ferree
SS_Bahn1
Chemin de fer à voie étroite
unique
voie_ferree
SS_Bahn2
Chemin de fer à voie étroite
multiple
voie_ferree
Str_Bahn Chemin de fer sur route voie_ferree
Str_Bhof
Jonction de voies dans l'aire
de gare
voie_ferree
3.2.3 Autres moyens de transport
ector25.ObjectVal Description Cible MD.01-MO-CH
A_Faehre Bac à voitures bac
LS_Bahn Téléphérique telepherique
Mat_Bahn Téléphérique pour matériel telepherique
P_Faehre Bacs pour passagers bac
Skilift Téléski skilift
13.6 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Prochaines étapes dans l’interopérabilité
Intégration Vector25 / MO
3.2.4 Réseau hydrographique
Vector25.ObjectVal Description Cible MD.01-MO-CH
Bach Ruisseau ru
Bachachs Axe du ruisseau -
Bach_U Ruisseau souterrain eau_canalisee_souterraine
Bisse Bisse ru
Druckl_1 Conduite forcée simple conduite_forcee
Druckl_2 Conduite forcée multiple conduite_forcee
Drucksto Galerie sous pression conduite_forcee
Fluss Axe de la rivière -
Fluss_U Rivière souterraine eau_canalisee_souterraine
Kanal
Ruisseau sans sens du courant
clair
ru
Seeachse Axe du lac -
Seeinsel Ile dans lac -
See Rive du lac -
3.2.5 Surfaces primaires
Vector25.ObjectVal Description Cible MD.01-MO-CH
Z_BaumS Pépinière foret_dense
Z_Fels Rocher rocher
Z_Fluss Rivière cours_eau
Z_Gebue Buissons autre_boisee
Z_GerGeb Pierrier / Eboulis avec buissons eboulis_sable
Z_GerGle Pierrier / Eboulis sur glacier eboulis_sable
Z_Geroel Pierrier / Eboulis eboulis_sable
Z_GerWa Pierrier / Eboulis en forêt eboulis_sable
Z_GerWaO Pierrier / Eboulis en forêt clair. autre_boisee
Z_Glet Glacier glacier_neve
Z_GsPist Piste sur herbe route_chemin
Z_HaPist Piste sur revêtement dur route_chemin
Z_KiGrub Gravière graviere_decharge
Z_LeGrub Glaisière autre_sans_vegetation
Z_ObstAn Verger autre_verte
Z_Reben Vignes vigne
Z_See Lac eau_stagnante
Z_Siedl Zone d'habitation autre_sans_vegetation
Z_StauDa Digue de retenue autre_sans_vegetation
Z_StauMa Barrage rocher
Z_SteBru Carrière graviere_decharge
Z_SumGeb Marais et buissons autre_verte
Z_Sumpf Marais autre_verte
Z_SumWa Marais en forêt autre_boisee
Z_SumWaO Marais en forêt clairsemée autre_verte
Z_Uebrig Autre type de sol champ_pre_paturage
Z_Wald Forêt foret_dense
Z_WaldOf Forêt clairsemée autre_boisee
Interopérabilité pour l'utilisation généralisée de la Géoinformation 13.7

Prochaines étapes dans l’interopérabilité
Intégration Vector25 / MO
3.2.6 Bâtiments
Vector25.ObjectVal Description Cible MD.01-MO-CH
Z_Gebaeude Maison batiment
Z_Innenhof Cour intérieure autre_revetement_dur
Z_Gasthof Auberge isolée batiment
Z_Huette Cabane batiment
Z_Kirche Eglise batiment
Z_Kuehlturm Tour de refroidissement silo_tour_gazometre (OD)
Z_Lagertank Réservoirs (hydrocarbures, gaz) batiment
Z_Perron Perron, halle de quais quai (OD)
Z_Schiessstand Stand de tir batiment
Z_Schloss Château batiment
Z_Station
Station / Arrêt des transports
publics
couvert_independant
Z_Treibhaus serre couvert_independant
Z_WBecken Station d'épuration des eaux bassin
3.2.7 Haies et arbres isolés
Vector25.ObjectVal Description Cible MD.01-MO-CH
BauReihe Rangée d'arbres cordon_boise
Hecke Haie cordon_boise
OBReihe Rangée d'arbres fruitiers cordon_boise
EinBaum Arbre isolé arbre_isole_important
ObstBaum Arbre fruitier arbre_isole_important
3.2.8 Surfaces aménagées
La couche Surfaces aménagées contient les catégories d’objets gare, aire d’aéroport et
gare d’aéroport. N'ayant aucune correspondance dans le MD.01-MO-CH, elles n'ont pas
été récupérées.
3.2.9 Objets isolés
Vector25.ObjectVal Description Cible MD.01-MO-CH
Antenne Antenne mat_antenne
ARA Station d'épuration des eaux autre
AusTurm Tour d'observation tour_panoramique
BiStock Oratoire / Croix statue_crucifix
Brunnen Fontaine fontaine
Denkmal Monument monument
Doline Doline autre
Drehsch Tour tournante tour_panoramique
ElWerk Centrale électrique autre
Hoehle Caverne / Grotte grotte_entree_de_caverne
Kamin Cheminée marquante cheminee
Kapelle Chapelle statue_crucifix
KiTurm Clocher autre_corps_de_batiment
Quelle Source source
Reserv Réservoir (eau) reservoir
Schiffst Débarcadère debarcadere
13.8 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Prochaines étapes dans l’interopérabilité
Intégration Vector25 / MO
SendeAnl Poste émetteur mat_antenne
Turm Tour tour_panoramique
W_Turm Château d'eau tour_panoramique
WaFall Cascade autre
ZistOff Citerne ouverte reservoir
HSP_Ltg
Ligne électrique à haute tension
ligne_aerienne_a_haute_tension
Ruine Ruine ruine_objet_archeologique
Sender Station radio mat_antenne
3.3 Transfert des données
Les tables de correspondances étant établies, il "suffit" à présent de décrire une interface
pour transférer tous ces objets du VECTOR25 dans le MD.01-MO-CH. Pour ce faire, il
est nécessaire de choisir un outil et de le paramétrer pour que chaque objet du jeu de
données de VECTOR25 soit bien transféré dans le bon thème du MD.01-MO-CH. Pour
mettre en place un telle interface il est nécessaire de se plonger dans le code et de programmer
soi-même une partie de celle-ci, les outils standard de conversion ne suffisent
parfois pas.
A titre d'exemple, vous trouverez ci-dessous un extrait des scripts nécessaires pour créer
une telle interface avec les outils de ilitools.
Cette interface étant prévue pour les modèles de données de langue française, allemande
et italienne, il a été nécessaire d'établir une librairie des noms de tables et d'attributs
afin que le cœur du script puisse être décrit qu'une seule fois.
Extrait de la librairie française correspondant à la couche VECTOR25 "Surfaces primaires"
:
MAP PRI
LANG
TOPIC
TABLE
TABLE_NACH
TABLE_SURFACE
OTHER
Z_GERGEB_VAL
Z_GERGEB
Z_FELS_VAL
Z_FELS
Z_FLUSS_VAL
Z_FLUSS
Z_GEBUE_VAL
Z_GEBUE
Z_GLET_VAL
Z_GLET
Z_KIGRUB_VAL
Z_KIGRUB
Z_SEE_VAL
Z_SEE
Z_SUMPF_VAL
=> F
=> Couverture_du_sol
=> SurfaceCSProj
=> Mise_a_jourCS
=> SurfaceCSProj_Geometrie
=> PRP
=> sans_vegetation.eboulis_sable
=> Z_GerGeb_X-Z_GerGle_X-Z_Geroel_X-Z_GerWa_X
=> sans_vegetation.rocher
=> Z_Fels_X-Z_StauMa_X
=> eau.cours_eau
=> Z_Fluss_X
=> boisee.autre_boisee
=> Z_Gebue_X-Z_GerWaO_X-Z_SumWa_X-Z_WaldOf_X
=> sans_vegetation.glacier_neve
=> Z_Glet_X
=> sans_vegetation.graviere_decharge
=> Z_KiGrub_X-Z_SteBru_X
=> eau.eau_stagnante
=> Z_See_X
=> verte.autre_verte
Interopérabilité pour l'utilisation généralisée de la Géoinformation 13.9

Prochaines étapes dans l’interopérabilité
Intégration Vector25 / MO
Z_SUMPF
=> Z_Sumpf_X-Z_ObstAn_X-Z_SumGeb_X-Z_SumWaO_X
Z_WALD_VAL => boisee.foret_dense
Z_WALD
=> Z_Wald_X-Z_BaumS_X
Z_SOLD_VAL => sans_vegetation.autre_sans_vegetation
Z_SOLD
=> Z_Siedl_X-Z_LeGrub_X-Z_StauDa_X
Z_UEBRIG_VAL => verte.champ_pre_paturage
Z_UEBRIG => Z_Uebrig_X
Z_BEFESTIGT_VAL => revetement_dur.route_chemin
Z_BEFESTIGT => Z_GsPist_X-Z_HaPist_X
Z_REBEN_VAL => verte.culture_intensive.vigne
Z_REBEN
=> Z_Reben_X
TMP => 1.0
END_MAP !PRI
Extrait du script :
Sélection de la catégorie :
IF PRI.Z_GERGEB SHPIN_REC.objectval LOC IS_NOT_NULL THEN
PRI.Z_GERGEB_VAL => VAR.ART
PRI_SURFACE
END_IF
…
PROCEDURE PRI_SURFACE
!***********************************************************
! Write the Object and the geometry for the category PRI
!***********************************************************
IF PRI.LANG = 'F' THEN
VAR.ART
=> OUT.Genre
ELSE
VAR.ART
=> OUT.Art
END_IF
NEXT_OBJID
=> OUT.OBJID
ILOUT_WRITE_OBJECT
PRI.TABLE_SURFACE
ILOUT_WRITE_SURFACE
END_PROCEDURE !PRI_SURFACE
13.10 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Prochaines étapes dans l’interopérabilité
Intégration Vector25 / MO
3.4 Problèmes rencontrés
3.4.1 Divergences topologiques
Avant de pouvoir transférer les données conformément aux tableaux décrits ci-dessus, il
convient d'étudier les divergences topologiques présentes. En effet, comme indiqué au
chapitre 3.1 la définition primaire de la couverture du sol diverge entre le produit VEC-
TOR25 et la mensuration officielle.
Une des plus problématiques concerne les informations de la couche réseau routier du
VECTOR25. Ce réseau est défini selon un type géométrique linéaire dans le jeu de données
VECTOR25 alors que les routes sont des éléments surfaciques dans le MD.01-MO-
CH. A priori, on ne connaît pas exactement la largeur de chaque route. Pour contourner
ce problème, on est obligé de se raccrocher à la documentation de swisstopo relative aux
signes conventionnels de la carte nationale, qui prévoit une largeur par classe de route.
Celle-ci étant une information attributive dans le VECTOR25, on pourra récupérer cette
valeur et reconstruire des éléments surfaciques.
Selon la documentation sur les signes conventionnels de la carte nationale, les classes
sont définies ainsi :
Route de 1 ère classe, largeur de 6m
Route de 2 ème classe, largeur de 4m
Route de quartier, largeur de 4m
Route de 3ème classe largeur de 2,8m
Chemin de 4 ème classe, largeur de 1,8m
Les routes de 5 ème et 6 ème classe sont transférées comme sentier avec une géométrie
de type linéaire dans le thème objets divers.
L'élargissement des objets linéaires et la création d'objets surfaciques s'exécutent directement
à l'aide des outils standard d'un SIG.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 13.11

Prochaines étapes dans l’interopérabilité
Intégration Vector25 / MO
0 25 50 75 100 125 Meter
Figure 2 : Transformation du réseau routier linéaire en éléments surfaciques
3.4.2 Généralisation des données
Les données de VECTOR25 sont issues de la carte nationale au 1:25'000, étant un produit
cartographique, ces données sont généralisées. Il n'est pas possible d'améliorer globalement
la généralisation des informations, lorsque celles-ci ne sont pas suffisantes pour les
besoins de la MO, même en tant que PRP, on peut recourir à des sources d'informations
différentes, par exemple en utilisant les données issues du logiciel ATOMI de swisstopo
pour le réseau routier.
ATOMI est un programme d'extraction automatique des axes de routes d'après des orthophotos,
le modèle numérique de terrain et une structure vectorielle du réseau routier.
La superposition des données issues de VECTOR25 et de ATOMI donne le résultat cidessous
:
13.12 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Prochaines étapes dans l’interopérabilité
Intégration Vector25 / MO
0 25 50 75 100 125 Meter
Figure 3 : Superposition des données VECTOR25 avec les données issues de ATOMI
Cette solution améliore grandement la qualité du réseau routier, par contre cela engendre
d'autres problèmes. Les routes étant maintenant "exactes" on constate que des bâtiments
se trouvent à cheval sur celles-ci! Plusieurs scénarios sont possibles :
On garde les données VECTOR25 originales, sans adjonction des routes de
ATOMI,
On récupère les routes de ATOMI et on laisse les bâtiments tel quel, même s'il
chevauche les routes,
On récupère les routes de ATOMI et on corrige les bâtiments afin d'obtenir un
jeu de données cohérents et réalistes. L'investissement est alors important.
On constate donc que des améliorations provoquent d'autres problèmes ou divergences.
Il faut alors se poser la question de l'investissement que l'on veut consentir et estimer le
résultat escompté. Des choix doivent être faits!
On peut résumer le processus ainsi :
Interopérabilité pour l'utilisation généralisée de la Géoinformation 13.13

Prochaines étapes dans l’interopérabilité
Intégration Vector25 / MO
3.5 Contrôles finaux
Figure 4 : Processus d'intégration de plusieurs sources de données
Le choix d'une interface étant fait et les données transférées, il reste maintenant à
contrôler l'intégrité des données résultantes. La mensuration officielle est très exigeante
sur la qualité des données, les contrôles y sont donc stricts et de nombreux outils
effectuent ces différents tests. Après le bon déroulement du transfert, on peut générer
un fichier INTERLIS correspondant au modèle de données de la mensuration officielle
et le contrôler à l'aide d'un "checker". On constate alors que de nombreuses erreurs
peuvent encore être présentes dans le jeu de données. Ci-dessous quelques cas
rencontrés dans notre zone de test :
Figure 5 : Un seul centroïde pour 2 surfaces distinctes
Figure 6 : Surface résultante très petite
13.14 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Prochaines étapes dans l’interopérabilité
Intégration Vector25 / MO
Figure 7 : Points manquants à générer
Figure 8 : No area found for
centroid
Figure 9 : Area with unknow
centroid
Figure 10 : Area with "n"
centroid
Figure 11 : duplicate line Figure 12 : Intersection Figure 13 : partial line
overlap
Figure 14 : full line overlap
Pour résoudre ces cas, une routine ou un travail manuel est nécessaire afin de rendre les
données cohérentes et respecter ainsi les exigences de la MO. Là encore, un choix doit
être fait pour ce qui est du respect desdites exigences dans le cadre de données issues
des PRP. Admet-on une qualité moindre ? Ou accepte t'on certaines "erreurs" ?
Interopérabilité pour l'utilisation généralisée de la Géoinformation 13.15

Prochaines étapes dans l’interopérabilité
Intégration Vector25 / MO
4 Conclusion
Le transfert des données du produit VECTOR25 dans le modèle de données de la mensuration
officielle démontre à quel point une description claire du modèle de données
est indispensable. En effet, si un jeu de données ne possède ni modèle de données, ni
descriptif clair, il sera quasiment impossible d'en récupérer son contenu pour d'autres
besoins, et donc de les rendre interopérables.
Une bonne description des données ne suffit toutefois pas. L'interopérabilité des données
nécessite une analyse précise, non seulement du modèle, mais également de la sémantique.
On constate dès lors que l'interopérabilité technique pose moins de problème que l'interopérabilité
sémantique. En effet, il ne faut pas perdre de vue qu'un jeu de données sert
en premier lieu à répondre aux besoins pour lesquels il a été établi. Ainsi, lorsque l'on
désire utiliser un jeu de données dans un contexte différent que celui prévu à l'origine,
les risques sont grands que les exigences posées au premier jeu de données ne correspondent
pas aux exigences du second!
L'interopérabilité sémantique comprend également la problématique linguistique. En
effet, si la langue diffère d'un jeu de données à l'autre, se pose alors la question de la correspondance
des termes et des définitions. Un dictionnaire des termes techniques est
d'une grande aide pour mieux appréhender un jeu de données décrit dans une langue
étrangère.
L'interopérabilité des données est une nécessité et un outil indispensable pour une utilisation
plus efficace des informations, notamment géographiques.
Littérature
Stratégie de la mensuration officielle pour les années 2004 à 2007 et vision
pour les années suivantes. Département fédéral de la défense, de la protection
de la population et des sports. Office fédéral de topographie, direction fédérale
des mensurations cadastrales.
VECTOR25, le modèle numérique du territoire de la Suisse, office fédéral de
topographie.
Transfert des données de VECTOR25 dans le MD.01, travail de semestre, A.
WILDBOLZ, EIVD 2004.
Documentation Interlis Tools de la firme Infogrips Gmbh.
13.16 Interopérabilité pour l'utilisation généralisée de la Géoinformation

14
Infrastructure nationale de données
géographiques (INDG)
Aspects organisationnels de
l'interopérabilité au niveau fédéral
Rolf Buser, suppléant du responsable COSIG centre
de compétence SIG (COSIG)
COSIG
Rolf Buser, Dipl. Ing. ETH
c/o Office fédéral de topographie / swisstopo
Seftigenstrasse 264
CH-3084 Wabern
Tél :
Fax :
E-mail :
+41 31 963 24 03
+41 31 963 23 25

Par infrastructure nationale de données géographiques (INDG) 1 , on désigne „… un ensemble
de mesures politiques, institutionnelles et techniques, élaboré, utilisé et étendu en commun
par toutes les parties responsables de la mise à disposition de données géographiques de base.
Cette structure doit assurer que, les expériences, données, technologies, standards, bases juridiques,
ressources matérielles et personnelles dédiés à la production et à l’utilisation de
l’information géographique répondent adéquatement aux besoins et aux objectifs des administrations,
organisations et citoyens, intégrant tous les échelons décisionnels (locaux, régionaux et
nationaux).“
Cette définition de l'INDG montre la nécessité de développer une infrastructure présentant
un haut degré d'interopérabilité. L'interopérabilité doit être garantie d'une part sur
le plan politique, organisationnel et institutionnel, et d'autre part, sur le plan technique,
c'est-à-dire au niveau des données ainsi que du système. Sur le plan technique, l'essor
rapide des technologies Internet permet de développer des solutions de plus en plus
performantes. En réalité, le problème ne se situe pas tant à ce niveau, même au sein de la
Confédération. Les possibilités techniques sont nombreuses et on dispose d'ores et déjà
de solutions satisfaisantes.
En revanche, sur le plan politique, organisationnel et institutionnel, l'interopérabilité
dans le domaine de l'information géographique n'en est qu'à ses débuts.
Vous trouverez ci-après une présentation succincte de certains aspects organisationnels
dans le domaine de l'INDG au niveau fédéral.
Réseau de contact
Pour la création d'une INDG, l'interopérabilité politique, organisationnelle et institutionnelle
doit être assurée en priorité par rapport à l'interopérabilité technique. Une stratégie
commune, des procédures obligatoires, une terminologie claire ainsi qu'une parfaite
harmonisation des exigences et attentes des partenaires et institutions concernés
sont nécessaires à cet effet. Il est indispensable de garantir à tout moment une communication
"interpersonnelle" étendue et d'intégrer les communautés d'information. Avec
la réunion constitutive du réseau de contact e-geo.ch qui s'est tenue en janvier 2005, une
première étape a été franchie en direction de l'interopérabilité politique, organisationnelle
et institutionnelle. Le réseau de contact doit être mis en place en intégrant, voire en
renforçant les structures fédérales et les systèmes hétérogènes. Sa direction sera assurée
par un organe de pilotage constitué à la fois de représentants de l'ensemble des échelons
administratifs, des institutions ainsi que de l'économie privée.
Le nouveau centre opérationnel du réseau de contact, qui est financé pour l'essentiel par
la Confédération, constitue le secrétariat de l'organe de pilotage, et s'acquitte en priorité
des tâches qui lui sont confiées par ce dernier.
Géodonnées de base et géoservices de base
Les contenus de l'INDG Suisse, c'est-à-dire les données et les services qui doivent être
mis à disposition par l'INDG, doivent être définis en toute priorité. Les communautés
d'information évoquées ci-dessus sont amenées à jouer un rôle décisif à cet égard. Dans
le cadre de domaines d'activité clairement définis (p. ex. aménagement du territoire), il
s'agit d'élaborer des visions communes pour la création de modèles de géodonnées et
géoservices de base. C'est là la seule façon de garantir l'interopérabilité des données et,
1
Concept de mise en oeuvre de la stratégie fédérale pour l’information géographique
Interopérabilité pour l'utilisation généralisée de la Géoinformation 14.1

Conséquences organisationnelles de l’interopérabilité I
Infrastructure nationale de données géographiques (INDG) - aspects organisationnels de
l'interopérabilité au niveau fédéral
ultérieurement, celle des services proposés. Avec la création du catalogue de géodonnées
de base de la Confédération, une première étape vient d'être franchie. Les discussions
relatives aux communautés d'informations pourront être menées sur la base de ce
catalogue. Au niveau fédéral, il s'agit avant tout, sur le plan organisationnel, de motiver
les communautés d'information existantes en vue d'accomplir ces nouvelles tâches ou
d'encourager la création de nouvelles communautés d'information. Une autre tâche consistera
à sensibiliser les décideurs.
La Confédération souhaite proposer et mettre en réseau des géoservices de base. COSIG
assurera la coordination de la mise en œuvre de la plate-forme fédérale, qui s'appuie sur
des normes "productives" ainsi que sur celles issues des travaux de la SNV (Association
suisse de normalisation) et de l'OGC (Open Geospatial Consortium).
Sur le plan organisationnel, des discussions devront être menées quant à l'élaboration
d'un registre des géoservices de base, dans lequel les fournisseurs et leurs services sont
décrits de façon structurée et font l'objet d'une catégorisation. Les géoservices de base
devront ensuite être décrits avec précision et les possibilités d'accès à ces services ainsi
que leur mode de communication devront être définis.
Standards / Normalisation
L'adoption d'une approche basée sur des modèles étant décisive pour garantir l'interopérabilité,
une telle approche est amenée à l'avenir à jouer un rôle majeur au sein de la
Confédération.
Les lignes directrices et standards suivants seront définis au sein de l’administration fédérale
:
la description des métadonnées s’effectue selon le profil-CH développé sur la base
de la norme ISO 19115 (au minimum le profil Core sera respecté),
la modélisation des données géographiques s’effectue à l’aide du langage de
modélisation UML (Unified Modeling Language) sur la base d’un catalogue
d’objets,
l’échange de géodonnées de base, indépendant des systèmes, s’effectue au minimum
à l’aide du langage INTERLIS/XML et veille à la compatibilité avec les
standards internationaux,
la mise en réseau des géoservices de base s’effectue au minimum en tenant
compte de leur compatibilité avec les standards internationaux tel que le W3C
(World Wide Web Comsortiums).
Les efforts menés actuellement en vue de la création d'une plate-forme nationale pour
les géonormes (NGN) doivent être poursuivis et bénéficier d'un soutien financier. Il s'agit
de faire avancer et de coordonner le développement et l'utilisation de normes géographiques
et de modèles de données. Les normes et modèles de données doivent être
mis à la disposition de tous les utilisateurs concernés et être perfectionnés. Pour ce faire,
il convient, en premier lieu, de coordonner les initiatives et activités existant déjà et disposant
d'un financement ad hoc, qui sont efficaces, mais qui manquent en revanche de
coordination. Celles-ci doivent également se fonder sur une base financière solide. L'objectif
est de parvenir à une diffusion rapide des connaissances concernant l'intérêt et
l'emploi des normes et des modèles de données ainsi qu'à une utilisation conséquente de
ces normes et modèles.
La formation, la technique, les modèles de données, le support, les normes et le marketing
constituent les activités centrales à mener dans ce domaine.
14.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

15
Profils nationaux des standards
internationaux
Exemple des métadonnées
Rudolf Schneeberger, ITV Geomatik AG
Rudolf Schneeberger
Dorfstrasse 53
CH-8105 Regensdorf
Tél :
Fax :
E-mail :
+41 44 871 21 90
+41 44 871 21 99

1 Introduction
1.1 Définition de métadonnée
Pour beaucoup de gens, le terme "métadonnées" est vague, indéfinissable et trop technique.
Souvent les métadonnées ne semblent pas importantes vu la disponibilité des données.
Elles ne sont donc pas traitées et n'existent que sur une petite notice. C'est pourquoi
la plupart du temps les métadonnées ne sont pas volontiers saisies. L'utilisateur ne
sait souvent pas à quoi elles peuvent bien servir.
Selon leur définition, les métadonnées sont "des données sur des données". Cela signifie
que ce sont des descriptions des données effectives. Les deux définitions suivantes permettent
d'éclaircir un peu le domaine :
Métadonnée signifie des données structurées. Elles permettent de décrire une ressource
d'informations et qui, de ce fait, devient plus facilement identifiable.
Les métadonnées sont des informations lisibles par des ressources électroniques
ou par d'autres moyens.
En regardant d'un peu plus près notre environnement, nous remarquons qu'en fait nous
rencontrons des métadonnées tous les jours. Imaginons une étale de barres de chocolat
dans un magasin. Si chacune de ces barres est emballée par un papier blanc et si "chocolat"
est inscrit dessus, laquelle allez-vous acheter? Sûrement aucune, car il est impossible
de savoir de quel type de chocolat il retourne. L'acheteur veut savoir s'il s'agit d'un chocolat
aux noisettes ou pas, qui l'a fabriqué, comment il s'appelle, quel est son prix, ... etc.
C'est seulement en connaissant ces indications qu'il est possible de comparer ces différentes
barres de chocolat et que l'acheteur peut choisir lesquelles correspondent à ses
attentes qualité-prix.
La problématique est exactement la même avec les métadonnées concernant les géodonnées.
Elles donnent une description exacte du contenu des géodonnées. C'est seulement
lorsque le contenu, la précision, le modèle, le format et encore bien d'autres caractéristiques
des géodonnées sont connus qu'il est possible de décider si les géodonnées remplissent
les critères. Les questions les plus importantes auxquelles répondent les métadonnées
de géodonnées sont :
Interopérabilité pour l'utilisation généralisée de la Géoinformation 15.1

Conséquences organisationnelles de l’interopérabilité I
Profils nationaux des standards internationaux : exemple des métadonnées
QUI propose - institution - personne de contact
- source / distributeur - adresse
- responsabilité
QUOI et - type de données - date d'acquisition
- contenu - nom et description
- échelle - manière
COMBIEN
- quantité de données
- contexte
- statut
DE QUOI S'AGIT-IL - type d'objets - thesaurus
- référence spatiale - spécialité
- référence temporelle
COMMENT à l’intérieur - format - base de données
- interface - droit d'accès
- analogique / digital - chemin d'accès
DANS QUEL cadre - signification technique - restriction d'utilisation
et
- description des devoirs
- indication d'aptitude
DANS QUELLES conditions - prix - ayant droit
- droits d'accès - reproduction
- droits d'utilisation
1.2 La métainformation comme partie intégrante d'une NGDI
Le but principal d'une infrastructure nationale de données géospatiales (NGDI) est de
produire par accès facilité une offre optimale et une large utilisation de géoinformation.
Les métainformations sont donc une partie essentielle dans cette NGDI.
15.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Conséquences organisationnelles de l’interopérabilité I
Profils nationaux des standards internationaux : exemple des métadonnées
2 Normes ISO
2.1 Contenu d'ISO 19115:2003 - Métadonnée
Structure pour la description de données géographiques digitales sous la forme d'un
modèle abstrait (modèle conceptuel des métadonnées) :
Introduction avec accords et définitions
Diagramme de classe faisant partis de la famille des diagrammes UML
Catalogue d'objets (Datadictionary)
Autres annexes
La norme ne dit rien sur la forme de mise en oeuvre dans un SIG ou d'une base de données
et n'est pas non plus une "recette" pour l'implémentation.
2.2 Profil et élargissement d'ISO 19115:2003 - Métadonnée
La norme ISO 19115 part du principe que son utilisation est universelle, mais tout en
ayant la possibilité de la limiter à l'aide de profils. La norme ISO définit plus de 200
méta-éléments (classes, attributs, associations), même si la plupart d'entres eux sont
optionnels.
Profil
Les profils permettent d'adapter le modèle global ISO de métadonnées pour une application
spécifique. Dans chaque profil, le modèle minimal doit être complètement intégré.
De plus, un besoin d'élargissement d'un profil peut apparaître.
Élargissement
Un profil peut être élargi avec des éléments de métadonnées qui lui sont propres ou
avec d'autres modifications. La norme ISO 19115 décrit, dans l'annexe C, exactement
comment élargir les structures prédéfinies et quels sont les élargissements possibles.
Modèle de métadonnées
ISO complet
(ISO Comprehensive
Metadata Profile)
Modèle de métadonnées
ISO minimal
(ISO Core Metadata
components)
Elargissement
Profile XY
Interopérabilité pour l'utilisation généralisée de la Géoinformation 15.3

Conséquences organisationnelles de l’interopérabilité I
Profils nationaux des standards internationaux : exemple des métadonnées
Règles pour l'établissement de profils
1. Les éléments déjà disponibles ne peuvent pas être modifiés dans son propre profil.
2. Si des attributs déjà existant sont utilisés dans un nouveau jeu d'entités, ces derniers
ne peuvent pas être modifiés.
3. L'élargissement permet ...
... d'établir des règles plus strictes pour les types de connections,
4. ... de définir des domaines de valeurs pour les entités et les attributs,
5. ... de raccourcir des domaines de valeurs préexistants,
6. ... ou de les étendre.
7. Mais les élargissements ne doivent pas permettre ce que le standard interdit.
3 Norme suisse pour les métadonnées
3.1 Pourquoi une norme suisse?
Les inventaires de métadonnées sont soit régionaux (cantons), soit dédiées à un domaine
technique (CDS, GeoMeta, Geostat) ou soit inaptes à une recherche par Internet et
à l'acquisition de métadonnées. Les bases de métadonnées existantes sont incompatibles
entre elles, de même qu'à la norme ISO 19115:2003.
La COSIG est responsable de la coordination des géodonnées pour l'administration fédérale,
et elle a donc aussi agi pour le domaine des métadonnées. Vu que la COSIG ne
voulait pas développer son propre "modèle fédérale", elle a collaboré avec un groupe de
travail issu des cantons, hautes écoles et entreprises pour définir un modèle de métadonnées.
Ce dernier satisfait aux exigences minimales, est ISO compatible et sera publié
par le SNV comme une norme Suisse.
3.2 De la norme ISO à la norme suisse
SIK - GIS
CDS
Stellungnahmen
zum Entwurf
ISO
19115:2003
Schweizer Norm
SN 612050
Pflichtenheft
geocat.ch
Pilot
geocat.ch
Arbeitsgruppe
SNV - TK 151
SNV
Vernehmlassung
GM03
Metadatenmodelle
INTERLIS
Beschreibung
geocat.ch
Catalog Gateway
15.4 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Conséquences organisationnelles de l’interopérabilité I
Profils nationaux des standards internationaux : exemple des métadonnées
Pour prendre en compte les demandes des intéressés en Suisse, une comparaison entre
la norme ISO et les bases de métadonnées du groupe de travail Systèmes d’information
géographique (SIK-GIS) et de l'office fédéral de l'environnement, des forêts et du
paysage (CDS) a été effectuée. Cela a permis une première ébauche d'un profil suisse de
métadonnées dans lequel des parties de la norme ISO ont déjà été éliminées. D'autres
parties ont été remodelées en tant qu'extensions.
Il faut retenir que la comparaison entre deux bases de métadonnées n'a pas permis d'analyser
tous les besoins. Des prises de position d'offices fédéraux, des cantons et d'autres
intéressés ont fait ressortir des besoins supplémentaires. Le modèle de métadonnées
refait a été la base pour l'ébauche de la norme suisse. Elle a été envoyée en procédure de
consultation fin 2003. Les résultats de cette procédure de consultation ont été discutés
dans un groupe de travail (SNV/TK151). Ce dernier, se composant de représentants de
toutes les parties intéressées, décida pour chaque cas s'il y avait un intérêt à une insertion.
Un modèle définitif en a été déduit, lequel est la base pour la norme suisse.
Parallèlement à l'établissement de la norme suisse, le portail et le serveur de métadonnées
geocat.ch ont été spécifiés et développés (voir chapitre 4).
3.3 Pourquoi la norme ISO comme base?
ISO est l'organisation internationale pour les standards à l'échelle mondiale.
CEN est le pendant européen pour ISO et va reprendre ISO 19115:2003.
La Suisse fait partie de CEN, et elle est, de ce fait, tenue de prendre en compte ses
normes, donc aussi ISO 19115:2003.
C'est seulement sur la base du standard international ISO 19915:2003 qu'un échange
de données international est possible.
3.4 Différences norme ISO – norme CH
La description du modèle en UML dans la norme ISO 19115:2003 est trop générale pour
une application concrète. C'est pourquoi, en Suisse, le modèle a été détaillé en INTERLIS
2, le standard suisse pour la modélisation et l'échange de données qui est modélisé et
documenté dans la notation UML. Le degré de concrétisation est ainsi augmenté et
l'échange rendu possible. INTERLIS 2 contient des règles de codage pour la production
automatique d'un schéma descriptif XML. Celui-ci est lisible par la machine et utilisable
pour mettre en place une structure de base de données et son application. Avec ces règles,
et en plus de la description UML, on évite l'établissement d'un schéma XML "à la
main" comme le fait actuellement ISO avec la norme 19139.
Comme le modèle de métadonnées d'ISO, le modèle suisse se compose de deux profils :
GM03Core et GM03Comprehensive. Les deux contiennent les éléments de métadonnées
d'ISO-Core. Une autre possibilité a cependant été choisie (voir figure) : ISO définit un
modèle de métadonnées le plus complet possible (profil ISO-Comprehensive), prescrit
quels sont les éléments qui doivent être contenus dans chaque profil et laisse par la suite
le soin à chaque groupe d'utilisateurs de définir son propre profil. En Suisse, par contre,
la modélisation se fait de manière inverse : le noyau minimal est défini par GM03Core
et, par héritage, l'élargissement se fait par GM03Comprehensive. L'avantage du procédé
suisse par rapport à ISO est donc que tous les profils ont la même base GM03Core, ce
qui garantit un dénominateur commun pour l'échange.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 15.5

Conséquences organisationnelles de l’interopérabilité I
Profils nationaux des standards internationaux : exemple des métadonnées
Modèle de
métadonnées
Comprehensive
Modèle de
métadonnées
local
Modèle de
métadonnées
GM03Core
Modèle de métadonnées
GM03Comprehensive
Modèle de
métadonnées
Core
Modèle de
métadonnées
local
Modèle de
métadonnées
local
Modèle de
métadonnées
local
Modèle de
métadonnées
local
3.5 Bases lors de l'élaboration de la norme suisse
ISO19115:2003 métadonnée a été choisie comme base :
Tous les éléments de métadonnées d'ISO-Core ont été repris dans GM03Core.
Tous les éléments de métadonnées ou classes, qui sont obligatoires selon les conditions
et objectifs de la norme, ont été repris.
Les éléments de métadonnées sont définis afin d'englober les catalogues de données
suisses résultants.
La compatibilité à ISO 19115:2003 est assuré par :
Les élargissements, qui sont modélisés selon l'annexe C de la norme ISO (par ex. :
informations légales „Legislation Information“).
Le plurilinguisme suisse, qui a été transcrit selon l'annexe J de la norme ISO.
Dans quelques cas particuliers, il a fallu contourner la norme ISO afin de trouver une
solution utilisable :
Autorité responsable („Responsible Party“)
autorité („Authority“) et identifiant („Identifier“)
La réutilisation de données dans plusieurs instances (par ex : „Responsible Party“,
système de coordonnées, etc.) impose des écarts lors de la modélisation des relations.
3.6 Modèle de métadonnée GM03
Pour assurer une description minimale des géodonnées, le modèle minimal de métadonnées
GM03Core a été défini. Les éléments de métadonnées répondant aux questions
suivantes font partie de GM03Core :
Existe-t-il des données pour un thème donné? (QUOI)
Existe-t-il des données pour un certain lieu? (OÙ)
Auprès de qui peut-on obtenir ces données? (QUI)
Sous quelle forme ces données peuvent-elles être acquises? (COMMENT)
Quand ou à quelle période, les données ont-elles été collectées ou actualisées?
(QUAND)
Le modèle GM03Core couvre uniquement les éléments les plus importants et ne remplit
pas toutes les exigences. C'est pourquoi le modèle plus complet GM03Comprehensive a
15.6 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Conséquences organisationnelles de l’interopérabilité I
Profils nationaux des standards internationaux : exemple des métadonnées
été élaboré, contenant tous les éléments d'ISO et les besoins supplémentaires des parties
intéressées.
3.7 Domaine d'utilisation de la norme suisse SN612050
La norme se penche sur les métadonnées pour les géodonnées, et elle est valable pour
les entreprises qui sont responsables de l'acquisition, le traitement, l'administration et la
distribution de métadonnées.
La norme, s'appliquant en premier lieu aux géodonnées, peut aussi être étendue à d'autres
domaines d'application.
La norme réglemente comment les métadonnées doivent être structurées conceptuellement.
Elle offre donc la compréhension uniformisée des métadonnées par les personnes
et parties intéressées. Par contre, elle ne réglemente pas comment doivent être mise en
place des installations concrètes (de bases de données, par ex.).
La norme ne développe pas non plus de propre technique pour la description précise
des principes. Elle se sert de techniques existantes. Pour la description du modèle de
données, le langage de description textuelle d'INTERLIS est utilisé en complément
d'UML (Unified Modelling Language).
La norme établit le principe d'échange de données. C'est XML (règles d'après INTERLIS
2) qui est utilisé pour l'échange de données.
4 geocat.ch
4.1 Portail pour les métadonnées geocat.ch et géocatalogue
Les exigences par rapport à un catalogue de géodonnées se réduisent à deux points :
Le catalogue de géodonnées doit être consultable à travers une application de recherche
pour que les métadonnées acquises puissent être visualisées. C'est à travers
un portail de métadonnées hétérogène et décentralisé que ce catalogue de
géodonnées est interrogé, et que les données sont mises à disposition de l'utilisateur.
Le catalogue de géodonnées doit disposer d'une application d'administration pour
que les données puissent être saisies, administrées et mises à jour.
Le portail de métadonnées geocat.ch remplit exactement ces deux exigences concernant
les catalogues de géodonnées.
4.2 Mise en oeuvre concrète
Le principal but est la réalisation, au niveau national, d'un portail pour l'ensemble des
métadonnées géographiques. Il est envisagé d'introduire une infrastructure décentralisée
qui permette l'administration décentralisée et l'accès à tous les catalogues de métadonnées
reliés.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 15.7

Conséquences organisationnelles de l’interopérabilité I
Profils nationaux des standards internationaux : exemple des métadonnées
Portail pour la recherche
Gateway
Catalogue de métadonnée
avec ses outils de gestion
et d’aministration
1
user
Discovery Service
Discovery
Service
user
Catalog
Management
Utilisateur
(interface)
Composant
de l’infrastructure
Search Server
2
Catalog
Gateway
Gateway and Client of
Metadatabases
gateway
manager
Partner A
Metadata
Partenaire
Méta-base de donnée
Relation entre un
utilisateur et
un composant
3
Database and Tool
Administration
Metadata
Management
Catalog
Management
Import / Export
Search Server
Flux d’informations
Catalog
Server
Metadatabase
MetaCH
Metadata
Metadata
general
administrator
metadata
contributor
catalog
administrat
or
catalog
administrat
or
metadata
contributor
metadata
contributor
catalog
administrat
or
KOGIS
Partner and
producer of
Geodata
A
Partner and
producer of
Geodata
B
Partner and
producer of
Geodata
C
Deux types de base de données sont reliées :
La base de données centrale geocat.ch, laquelle est atteignable par l'application de
recherche geocat.ch.
Les base de données distribuées qui sont reliées à l'application de recherche
geocat.ch par le Catalog Gateway.
Pour les producteurs de métadonnées, trois types de partenariats sont possibles :
Gestion de données directement dans la base de données centrale.
Gestion de données dans sa propre base de données ; c'est au moyen d'un outil
d'import/export que ces données sont mises à disposition au travers de la base de
données centrale et donc de l'application de recherche.
Gestion de données dans sa propre base de données, laquelle peut être interrogée
au travers de l'application de recherche en passant par le Catalog Gateway.
4.3 Portail de recherche
Le portail de recherche donne à l'utilisateur un aperçu complet et unitairement structuré
des géodonnées, mais aussi un accès rapide aux informations concernant ces dernières,
peu importe l'institution qui les administre. Ce service de recherche n'est pas utilisé en
tant que solution centralisée pour l'administration et la distribution de métadonnées
géographiques. En général, il est prévu que les métadonnées soient directement gérées
par le producteur associé des géodonnées à l'aide de sa propre infrastructure (partenaire
C).
15.8 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Conséquences organisationnelles de l’interopérabilité I
Profils nationaux des standards internationaux : exemple des métadonnées
L'application permet deux types de recherche : la recherche textuelle simple et la recherche
détaillée à travers laquelle chaque élément peut être recherché. La recherche géographique
suivant une description du lieu (par ex. Canton de Berne) à l'intérieur d'un
rectangle ou d'un polygone est commune aux deux types de recherche.
Le service de recherche doit ainsi avoir un accès coordonné et transparent aux différentes
méta-base de données. La valeur fonctionnelle d'une telle solution explique l'utilisation
d'un protocole pour le questionnement et le résultat. Ce protocole, décrit en SOAP
(Simple Object Access Protocol), est implémentable relativement facilement à moindre
frais, autant pour des bases de données relationnelles, que pour des solutions basées sur
XML.
geocat .
ch
Discovery Client
Geocat .
ch
Portal
Gateway Protokoll
Gateway
Server(s)
Requête (HTML)
Requête(s)
Résultat(s) en XML
Consolidation
du résultat
Présentation du résultat
Requête détaillée (HTML)
Requête(s) GM03
Présentation des résultats
en GM03 (HTML)
Résultat(s) en SML GM03
Références
Vermessung und Geoinformation - GM03 - Metadatenmodell, Ein Schweizer Metadatenmodell
für Geodaten, SN 612050, Working Draft Version 1.4
ISO Norm 19115:2003, Geographic Information - Metadata
Aufbau eines Nationalen Metadaten-Portals als Teil einer Nationalen Geodaten-
Infrastruktur in der Schweiz, Referat von D. Angst (ITV Geomatik AG) und A.
Schneider (KOGIS), AGIT 2004 in Salzburg
Pflichtenheft geocat.ch Metadatenkatalog für Geodaten, August 2002
Catalog Gateway Protocol, Mai 2004, KOGIS, Version 0.99
Interopérabilité pour l'utilisation généralisée de la Géoinformation 15.9

16
Interopérabilité : pas seulement une
question de technologie
Willy Müller, Unité de stratégie informatique de la
Confédération
Willy Müller
Unité de stratégie informatique de la Confédération
Friedheimweg 14
CH-3003 Bern
Tél :
Fax :
E-mail :
+41 31 325 90 35
+41 31 322 45 66

Les présentes journées d’étude sont consacrées à l’interopérabilité dans le domaine de
l’information géographique (ou géoinformation). Mais qu’est-ce que l’interopérabilité ?
Selon la définition figurant dans [IEEE 90], il s’agit de la capacité que possèdent deux ou
plusieurs systèmes ou composants à échanger des informations puis à exploiter les informations
venant d’être échangées. Dans notre contexte, c’est essentiellement la possibilité
d’échanger des données géographiques qui nous intéresse. Un certain niveau
d’interopérabilité est presque toujours atteint, d’une manière ou d’une autre. Ainsi, un
bureau de géomètre peut-il dresser un plan, en faire un tirage sur papier puis envoyer
celui-ci par la poste à un autre bureau où il sera manuellement réintroduit dans le système
informatique local. Nous ne serions certainement pas ici les uns et les autres si
cette solution nous satisfaisait. Nous aspirons à une meilleure interopérabilité, ce qui
sous-entend que le niveau d’interopérabilité peut être plus ou moins élevé. La qualité de
l’interopérabilité présente en fait deux dimensions : la première est en corrélation négative
avec le volume de travail et les coûts nécessaires à un échange de données puis une
exploitation consécutive par voie informatique. La seconde est en corrélation positive
avec l’ensemble des systèmes ou des composants échangeant des informations entre eux
et étant en capacité de les utiliser ultérieurement. Il convient par conséquent de préciser
la définition fournie dans [IEEE 90] pour l’adapter à notre contexte : l’interopérabilité est
la capacité commune au plus grand nombre possible de systèmes et de composants à
échanger des données par voie informatique et à permettre la poursuite de leur utilisation
moyennant le volume de travail le plus réduit possible, ne faisant en particulier intervenir
aucun traitement manuel.
1 Le Conseil fédéral souhaite une collaboration
informatique sans accroc
Quel rôle l’Etat a-t-il à jouer en matière d’interopérabilité, en particulier dans le domaine
de l’information géographique ? Doit-il faire connaître sa position à ce sujet ou convientil
qu’il reste totalement en retrait ? L’Etat suisse, englobant les autorités fédérales, cantonales
et communales, se voit confronté à plus d’un titre à des questions qui, au premier
abord, semblent d’ordre plutôt technique :
1. Il a pour mission de créer des conditions-cadre profitables aux habitants comme
à l’économie.
2. Il est directement concerné en sa qualité de producteur et de consommateur important
d’informations géographiques.
3. Il se doit de procéder à une analyse approfondie des conséquences qu’entraîne
une interopérabilité améliorée.
Le Conseil fédéral estime que la promotion de la société de l’information constitue une
priorité en Suisse. Il souhaite en outre organiser ses activités de gouvernement et
d’administration avec efficacité, souplesse et transparence. A cette fin, il a défini trois
grands axes dans sa stratégie de cyberadministration (eGovernment) :
1. Créer des conditions propices : les conditions organisationnelles, technologiques
et le cadre de sécurité propices à une collaboration sans accroc au sein de
l’administration sont à créer.
2. Excellence du service : l’accès aux prestations de services proposées par l’Etat –
englobant également la mise à disposition d’un large éventail d’informations
géographiques – doit gagner en facilité et en transparence pour le secteur privé
comme pour l’ensemble des citoyens.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 16.1

Conséquences organisationnelles de l’interopérabilité I
Interopérabilité : pas seulement une question de technologie
3. Interconnexion : l’objectif visé est l’« intégration informatique » entre les services
administratifs des différents niveaux hiérarchiques (Confédération, cantons et
communes) comme entre l’Etat et ses partenaires (pouvoirs publics, économie et
société).
Les travaux visant à encourager la collaboration informatique dans le domaine de
l’information géographique sont donc à considérer comme un élément d’une stratégie
plus vaste. C’est entre autres à cette fin qu’a été créée la COSIG, le service de coordination
de l’information géographique et des systèmes d’information géographique (cf.
www.cosig.ch). Les grands axes « Créer des conditions propices » et « Interconnexion »
visent quant à eux à une meilleure interopérabilité.
Des mesures sont donc nécessaires à différents niveaux pour accroître l’interopérabilité.
Les distinctions suivantes sont en particulier à établir, à l’exemple du modèle que nous
avons développé dans le cadre de l’architecture de la cyberadministration en Suisse
[eGovCH] :
Politische, Conditions-cadre rechtliche politiques,
und
organisatorische juridiques et Rahmenbedingungen
organisationnelles
Services Fach spécialisés
-Services
Services Infrastruktur-Services
d’infrastructure
Services Daten-Services
de données
Services
de
répertoire
Base technique
Figure 1 : Domaines dans lesquels des mesures harmonisées entre elles sont nécessaires en vue
d’obtenir une réelle interopérabilité.
Infrastructure technologique : ordinateurs, mémoires et réseaux destinés au traitement
informatique et à l’échange de données.
Services d’infrastructure : applications non spécialisées permettant un échange de
données fiable et sûr.
Services de répertoire : répertoires informatisés, au besoin interprétables par une
machine, concernant des partenaires de communication et des prestations de services
accessibles par voie informatique.
Services de données : définition de la syntaxe et de la sémantique garantissant
que des partenaires d’un échange de données puissent ensuite utiliser ces données
sans problème majeur.
Services spécialisés : applications spécialisées écrites de telle manière à pouvoir
collaborer avec d’autres applications spécialisées.
16.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Conséquences organisationnelles de l’interopérabilité I
Interopérabilité : pas seulement une question de technologie
Organisation, processus et droit : conditions-cadre organisationnelles et juridiques
permettant l’interopérabilité et fixant les règles du jeu pour la collaboration
informatique.
Une coopération sans accroc ne deviendra possible que lorsque les conditions propices
auront été créées à tous les niveaux. Quelques points critiques vont être abordés de façon
plus approfondie dans la suite. Des exemples issus du domaine de l’information
géographique seront en règle générale cités en guise d’illustration.
2 Premier axe : créer des conditions propices
Pour que des systèmes puissent échanger des données sans intervention humaine, ils
doivent pouvoir se comprendre, ce qui n’est possible que s’ils partagent un langage
commun. Nous commençons actuellement à comprendre comment de tels langages devraient
se présenter pour être optimaux ainsi que la manière de les documenter. Des
spécifications correspondantes sont disponibles dans le domaine de l’information géographique
et ont passé, au moins partiellement, des premiers tests avec succès (exemples
: INTERLIS, GML). La présente contribution n’a pas pour objet de développer ces
points en détail. Cependant, on oublie volontiers, lorsqu’on se consacre à la spécification
de classes, de règles d’intégrité et d’étiquettes (tag), que les enjeux dépassent largement
la simple précision de ces spécifications. Trois aspects vont plus spécifiquement être
abordés dans la suite :
la lutte pour le langage adéquat
l’attribution de noms et d’identifiants
les mises en relation de données de domaines différents.
2.1 La lutte pour le langage adéquat
Aucune loi de la nature ne garantit, hélas, qu’il n’existe qu’un seul langage. Il n’est donc
guère étonnant de voir surgir des communautés linguistiques différentes, plus ou moins
indépendantes les unes des autres, toutes dotées de conventions qui leur sont propres. Il
en va de même dans le domaine de l’information géographique : les développeurs de
logiciels définissent leurs propres formats d’échange de données, parallèlement aux instances
nationales et internationales de normalisation. Tant que les membres d’une même
communauté linguistique ne souhaitent échanger des données qu’entre eux, cela ne
cause pas de réelles difficultés. Dans le cas contraire, des langages différents représentent
alors un sérieux problème d’interopérabilité.
Les langages ne servent malheureusement pas qu’à la communication, ils constituent
également des outils d’exclusion, de sorte que la décision d’intégrer un participant au
sein d’une communauté linguistique revêt une importance stratégique. Le Conseil fédéral
se prononce de manière explicite pour une interconnexion au sein du territoire de la
Suisse comme au-delà. Si cette vision se concrétise, la concurrence entre les développeurs
de logiciels et les fournisseurs de données concernés va s’exacerber et les niches
que les uns ou les autres sont parvenus à se créer disparaîtront.
2.2 Mises en relation
La limite entre ce qui est à considérer comme une information géographique et ce qui ne
l’est pas est plus délicate à tracer que ce que l’on imagine à première vue. Au sens large,
cette catégorie englobe tout ce qui comporte une référence spatiale, autrement dit tout ce
qui a été, est ou sera en relation avec des coordonnées ou une portion de terrain. A y re-
Interopérabilité pour l'utilisation généralisée de la Géoinformation 16.3

Conséquences organisationnelles de l’interopérabilité I
Interopérabilité : pas seulement une question de technologie
garder de plus près, il s’agit potentiellement de tous les objets possédant une extension
spatiale, puisque tout ce qui possède une extension spatiale se trouve forcément à un
endroit donné à un instant donné : clubs de golf, webcams, antennes de téléphonie mobile,
fumeurs, bovins, renoncules des glaciers, conduites de gaz, précipitations. Mais ce
n’est pas tout ! Tout ce qui est en relation avec un tel objet est susceptible d’être intégré à
des informations géographiques : vitesses des vents, mortalité infantile, pratiques
sexuelles ou préférence marquée pour le vin rouge.
Que reste-t-il d’autre ? Pas grand-chose en vérité. De sorte que l’on est amené à introduire
une notion supplémentaire, celle de données de référence. Il s’agit d’informations
géographiques pouvant être utilisées pour projeter d’autres informations sur elles.
L’idée est limpide et la notion aisée à concevoir, mais elle est source de difficultés. Cette
notion a été intégrée dans le projet de la nouvelle loi sur l’information géographique et a
provoqué des discussions très animées au cours des réunions préparatoires. A y regarder
de plus près, même les informations géographiques les plus simples comprennent
des références à des « objets tiers », tels que des pays, des cantons ou des communes,
des routes nationales, des routes principales ou secondaires, des numéros de maisons ou
de parcelles. Et des informations géographiques combinées à des données attributaires –
par exemple une carte enrichie d’informations géologiques – peuvent être utilisées par
des tiers comme base de travaux ultérieurs – par exemple en vue de l’aménagement de
sites de stockage de déchets nucléaires définitifs.
Nous souhaitons créer un réseau d’interopérabilité pour les informations géographiques
dont l’ampleur s’étende si possible au monde entier. Des normes pour la représentation
des informations spatiales sont nécessaires à cet effet, mais elles ne sont pas suffisantes,
comme les exemples ci-dessus l’ont mis en lumière. Nous avons également besoin de
normes pour la représentation des renseignements devant être mis en relation avec elles.
C’est pourquoi l’interopérabilité dans le domaine de l’information géographique ne
peut pas et ne doit pas se restreindre aux informations géographiques au sens le plus
strict, sous peine d’être d’un bénéfice très limité.
2.3 Attribution de noms et d’identifiants
Que seraient les cartes nationales sans la désignation des localités ou les plans de villes
sans les noms des rues ? Au contraire de la syntaxe et de la sémantique générales, il est
souvent impossible, ou uniquement possible sous conditions, de fixer de tels noms ou
identifiants au sein de normes ou de standards, alors qu’ils sont indispensables dans
l’optique de l’interopérabilité. Deux partenaires d’une communication ne savent qu’ils
parlent d’un même objet que s’ils le désignent par un même terme. En plus d’instances
de normalisation, élaborant, publiant et tenant à jour les normes nécessaires, nous avons
besoin d’institutions identifiant les objets à propos desquels nous souhaitons échanger
des informations et diffusant les listes actuelles des identifiants attribués, accessibles et
consultables par voie informatique, à toutes les parties concernées.
Dans le cas idéal, les compétences en matière d’espaces nominaux sont définies sans
ambiguïté ni chevauchement. Cette exigence simple à formuler d’un point de vue technique
peut toutefois revêtir un caractère explosif dans certains cas particuliers. Ainsi, la
communauté des Etats ne s’accorde-t-elle pas sur le fait de savoir si Taiwan est un Etat
indépendant ou s’il ne s’agit que d’une province – renégate – chinoise. La reconnaissance
d’un Etat est un acte politique, pouvant conduire à un conflit armé, dans le pire
des cas.
16.4 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Conséquences organisationnelles de l’interopérabilité I
Interopérabilité : pas seulement une question de technologie
Avant l’ère de l’interconnexion, toute application était contrainte de gérer et d’identifier
elle-même les données dont elle avait besoin. Des problèmes surgissent si l’on souhaite à
présent les échanger. Des travaux sont en cours dans les domaines de spécialité les plus
divers afin de s’atteler à la résolution de ces difficultés. Les efforts déployés en vue de
l’introduction d’identifiants pour les personnes physiques et morales en constituent un
exemple.
Pour bon nombre d’objets, les responsables de l’attribution de leurs noms n’ont pas encore
été définitivement désignés. La désignation des responsables de l’attribution des
noms et de leurs champs de compétences respectifs de même que l’acceptation de ce
pouvoir de définition par la communauté de la communication constituent des décisions
avant tout politiques et organisationnelles, lesquelles sont rarement exemptes de
conflits et de luttes de pouvoir. Nous avons encore beaucoup de travail en perspective
dans ce cadre.
3 Deuxième axe : excellence du service
L’interopérabilité n’est pas une fin en soi. Nous y oeuvrons parce que nous espérons en
tirer des avantages. Nous ne pourrons toutefois profiter de ces avantages que lorsque les
systèmes collaboreront effectivement. Le Conseil fédéral a fixé pour objectif que les administrations
utilisent les possibilités offertes par les technologies de l’information afin
de faciliter l’accès à leurs prestations de services au secteur privé comme à l’ensemble
des citoyens. Les communications aussi bien entrantes que sortantes sont concernées
dans ce contexte.
Il convient à cette fin que :
les producteurs de données génèrent les données sous une forme numérique (ce
qui, dans le cas de la mensuration officielle par exemple, n’est pas encore partout
le cas) ;
les données soient mises à disposition par voie informatique dans des formats
adéquats et à des conditions réalistes ;
une infrastructure adéquate soit mise en place pour l’échange de données ;
les destinataires des données disposent de l’infrastructure adéquate pour lire et
traiter les données.
Les conditions énumérées peuvent sembler banales. Et pourtant, en arriver concrètement
à ce que, par exemple, les plans de tous les biens-fonds de Suisse soient effectivement
numérisés et que les logiciels qui les gèrent soient en mesure de pourvoir à leur
échange par voie informatique n’a rien d’évident. Cela nécessite un intense travail de
persuasion auprès des géomètres officiels, des syndics de communes et du personnel
politique et rend indispensables des investissements parfois conséquents. Il va de soi
que la Confédération œuvre également à rendre ses informations géographiques accessibles
simplement par voie informatique.
4 Troisième axe : interconnexion
Nous aspirons à une interconnexion plus dense et à une meilleure interopérabilité. Du
point de vue de la théorie des systèmes, nous modifions ce faisant les règles
d’interaction au sein d’un système dynamique. Et cela entraîne inéluctablement des
conséquences pour l’ensemble du système : il va se modifier. Que nous le voulions ou
non, nous n’avons d’autre choix que de réagir à ces modifications. Quiconque a une
pensée stratégique ne peut se satisfaire d’une telle situation. Il anticipera les change-
Interopérabilité pour l'utilisation généralisée de la Géoinformation 16.5

Conséquences organisationnelles de l’interopérabilité I
Interopérabilité : pas seulement une question de technologie
ments possibles et cherchera, par des mesures organisationnelles, à influer sur ceux-ci
autant qu’il le pourra.
Parmi les champs dans lesquels des modifications sont à prévoir, on peut citer les exemples
suivants :
la tarification et le financement
l’authenticité et les droits d’auteur
la protection des données
la responsabilité des fournisseurs de données
4.1 Les modèles de tarification et de financement sont à réviser
Il n’y a pas si longtemps encore, les informations géographiques se présentaient sous la
forme de cartes ou de plans et pouvaient en conséquence être traitées comme des biens
classiques. Cela n’est plus possible que sous conditions si elles sont transmises sous
forme de jeux de données numériques car les informations de ce type peuvent être copiées,
transférées, recomposées, modifiées ou associées à de nouvelles informations en
l’espace de quelques fractions de secondes.
La transmission par voie informatique génère cependant un nouveau potentiel : il devient
plus facile, pour des partenaires commerciaux, des administrations ou des entreprises
d’acquérir des données puis de les traiter pour en faire de nouveaux produits qui
seront commercialisés à leur tour.
Vu sous cet angle, l’Etat devient d’une certaine manière un fournisseur de matières
premières d’une industrie de transformation. Pour tous ceux qui procèdent au traitement
de données en aval du fournisseur, l’utilisation de données brutes est d’autant
plus intéressante que les conditions de leur acquisition auront été favorables. Si le prix
des données est trop élevé, ses propres produits deviennent trop onéreux et par suite,
moins attrayants.
La stratégie poursuivie par le Conseil fédéral consiste à mettre les géodonnées de la
Confédération à la disposition des utilisateurs à un prix aussi avantageux que possible
de façon à créer des conditions profitables pour l’économie. Il s’emploie à inciter les cantons
à adopter une stratégie similaire. Les efforts d’économie parallèlement entrepris par
l’Etat viennent cependant entraver le bon déroulement de ce processus.
4.2 Droits d’auteur et authenticité
En l’absence de mesures spéciales, l’auteur de données transmises par voie informatique
n’est plus identifiable de sorte qu’elles peuvent subir un traitement complémentaire à
son insu, donc sans son accord, voire être cédées à des tiers. Il m’est possible, sans
grande difficulté, de télécharger des fichiers vidéo sur Internet, de les traiter au moyen
de programmes simples, de les copier ensemble puis de diffuser le résultat sous mon
propre nom. Il en va de même pour les informations géographiques.
Leur capacité à être copiées très simplement pose des problèmes encore non résolus à
des secteurs d’activité entiers. Des mécanismes de comptabilisation bien rodés se retrouvent
sapés à la base. Parvenir à imposer le droit d’auteur dans le cybermonde est un
défi non encore relevé. Que ferions-nous si l’ensemble des cartes de l’Office fédéral de
topographie se retrouvait aux mains d’un groupe qui les mettrait à disposition sur Internet
via un serveur basé outre-mer ?
16.6 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Conséquences organisationnelles de l’interopérabilité I
Interopérabilité : pas seulement une question de technologie
La capacité à être aisément copiées et modifiées est source d’un problème supplémentaire
: comment savoir si la version des données dont je dispose est bien autorisée ?
Comment puis-je par exemple être sûr que le plan de mensuration qui s’affiche sur mon
écran est bien une copie autorisée ?
Les premières esquisses de solutions technologiques destinées à remédier à ces problèmes
commencent bien à apparaître, comme la gestion des droits numériques (Digital
Rights Management, DRM), mais leur adaptation au contexte qui nous intéresse reste
limitée, étant conçues pour des objets pouvant être considérés comme des entités et qu’il
est possible d’exploiter sur un support clairement défini.
Les textes législatifs en cette matière sont lacunaires pour l’heure et les solutions techniques
nécessaires sont encore insuffisantes.
4.3 Protection des données
La facilité d’accès aux informations géographiques et leur capacité à être aisément reliées
à d’autres données s’accompagnent de nouveaux problèmes. L’un de ceux-ci
consiste dans le fait qu’il devient plus difficile de tenir des informations secrètes. Des
indications provenant de différentes sources et concernant un même territoire peuvent
être assez facilement exploitées pour déceler d’éventuelles différences. Il est ainsi possible
de confronter des images satellites à des cartes publiées par les autorités locales. Et
les informations délibérément occultées sur les cartes peuvent ainsi être riches
d’enseignements pour les services de renseignements...
Des données personnelles peuvent également être mises en relation avec des informations
géographiques. Si l’on relie entre elles des indications tirées de l’annuaire téléphonique,
des adresses de bâtiments et des données cartographiques, la domiciliation de
toutes les personnes concernées peut être visualisée en un tournemain. Si une personne
porte un téléphone portable branché sur elle, sa position est connue. Une carte affichant
sa localisation instantanée pourrait sans grande difficulté être mise en ligne sur un site
Internet. De telles informations peuvent aider à repérer des personnes en situation de
crise, dans le cas d’une catastrophe naturelle par exemple. La police peut aussi les utiliser
pour arrêter des criminels. Mais elles sont tout aussi intéressantes pour des détectives
privés, des services de renseignements ou des terroristes.
Lorsque nous accroissons l’interopérabilité, nous ne pouvons pas nous permettre de négliger
des mesures visant à empêcher toute utilisation abusive ou délictuelle des informations.
Actuellement, l’Etat et la classe politique éprouvent de vives difficultés à établir
une délimitation claire en matière de données numériques, pour déterminer ce qui
doit être permis et ce qui est à interdire. Certains vont par exemple jusqu’à considérer la
version numérique de la carte de la Suisse comme un jeu de données personnelles digne
d’une protection puisque ces informations peuvent potentiellement être mises en relation
avec des données personnelles.
4.4 Responsabilité des fournisseurs de données
L’interopérabilité n’est pas un voeu coupé de la réalité. Les géodonnées sont de plus en
plus fréquemment accessibles sous forme numérique et le marché commence à utiliser
les possibilités qui en découlent. Il est prévisible que des chaînes entières de création de
richesse se mettent progressivement en place. Qu’ils le veuillent ou non, les acquéreurs
de données auront à faire face à des souhaits toujours plus pressants des clients. Ceux-ci
concerneront d’une part la stabilité de l’offre : quiconque utilise des données fournies
Interopérabilité pour l'utilisation généralisée de la Géoinformation 16.7

Conséquences organisationnelles de l’interopérabilité I
Interopérabilité : pas seulement une question de technologie
par quelqu’un d’autre pour générer ses propres produits compte fermement que ces
données resteront disponibles dans le futur. Le bénéfice économique sera alors maximal
lorsque les fournisseurs de données définiront leurs produits avec précision et pourront
garantir à leurs clients que la disponibilité de leur offre s’inscrit dans la durée.
Il sera d’autre part inévitable que les clients, prenant goût à la situation, formulent de
nouveaux souhaits mettant alors les fournisseurs sous pression. Ainsi, il est par exemple
prévisible de voir croître les exigences en matière de plus grande actualité des données.
5 Conclusion
Si l’interopérabilité devient une réalité dans le domaine de l’information géographique,
il en résultera logiquement un immense pool de données auquel différentes parties apportent
leur contribution. Les intervenants, au nombre desquels on compte l’Etat ainsi
que les entreprises privées concernées, devront s’accorder sur l’identité des contributeurs
et la quote-part de chacun d’entre eux à ce pool de données de même que sur des
règles de comportement à adopter vis-à-vis de celui-ci. Le pool de données en lui-même
constitue un capital économique à ne pas sous-estimer, dont la valeur augmente à mesure
que le volume des informations qu’il intègre croît. La manière dont ce capital sera
mis en valeur – bien ou mal – décidera de l’ampleur de la création de richesse.
[eGovS 99] L’activité gouvernementale à l’heure de la société de l’information. Stratégie de la
Confédération en matière de cyberadministration., 13 février 2002.
http://www.admin.ch/ch/f/egov/egov/strategie/ISB_fr.pdf
[IEEE 90] Institute of Electrical and Electronics Engineers. IEEE Standard Computer
Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York,
NY: 1990.
[IGES 98] Stratégie du Conseil fédéral suisse pour une société de l’information en Suisse du
18 février 1998.
http://www.admin.ch/ch/f/egov/gv/berichte/2a.pdf
[eGovCH 05] eGovCH - eGovernment Architektur Schweiz.
Unité de stratégie informatique de la Confédération (en préparation).
16.8 Interopérabilité pour l'utilisation généralisée de la Géoinformation

17
Interopérabilité stratégique et
administrative
François Golay, EPF Lausanne
François Golay, Prof. Dr.
Laboratoire de Systèmes d'information géographique
Ecole Polytechnique Fédérale de Lausanne
CH-1015 Lausanne
Tél :
Fax :
E-mail :
+41 21 693 57 81
+41 21 693 57 90

1 Introduction
L’interopérabilité est perçue comme une réponse avant tout technologique aux besoins
d’ouverture des systèmes géoinformatiques. L’OGIS constitue indubitablement le principal
vecteur d’un développement technologique concerté à travers le monde, et les architectures
informatiques qui s’imposent – composantes logicielles, services sur le Web,
etc. – permettent d’en assurer une implémentation efficace. Finalement, les travaux de
normalisation entrepris plus particulièrement au sein de l’ISO permettent d’ancrer ces
concepts dans la durée.
Les dernières présentations de ce séminaire nous ont toutefois bien montré que le partage
de données exige un accord non seulement sur le contenant – les architectures –
mais aussi sur le contenu des échanges. Quelles sont les données impliquées dans un
échange ? Sur quelles informations des actions communes sont-elles basées ? Ces questions
sont l’objet de l’interopérabilité sémantique des systèmes d’information géographique,
discutée plus tôt par Morf et Dorfschmied [Morf 2005]. L’élaboration et la normalisation
de modèles communs constituent une réponse à ces questions, tout comme
l’identification et la définition de références croisées entre les systèmes interopérants.
Les orateurs précédents ont finalement souligné que la diversité des acteurs et des institutions
impliquées dans le partage d’informations [Buser 2005] et de services nécessite
une organisation adéquate, respectant les responsabilités institutionnelles de chaque acteur.
Nous constatons dans la présente contribution qu’il ne saurait y avoir de partage efficace
de données sans reconnaissance et prise en compte des missions et des stratégies
propres à chaque acteur institutionnel, plus particulièrement aux communes, aux cantons
et à la Confédération. Nous postulons que les interopérabilités technique et sémantique
ne pourront être mises en œuvre que dans le cadre d’une bonne interopérabilité
stratégique et administrative des acteurs institutionnels.
2 Organisation fédéraliste suisse et missions des acteurs
Dans le cadre du rapport Etude préliminaire au projet e-geo.ch : aspects organisationnels et
techniques, [Moreni & al. 2003] ont proposé une représentation de l’imbrication des niveaux
décisionnels sur le territoire, à l’exemple de la Suisse (figure 1). On y constate un
positionnement bien distinct des acteurs et institutions fédérales, cantonales et communales.
Les préoccupations de ces acteurs et institutions peuvent différer de façon notable, conformément
à leurs responsabilités dans les processus de management territorial. Ainsi :
Au niveau local (communal), les préoccupations foncières sont prédominantes. Il
s’agit avant tout de documenter de manière fiable le statut juridique et technique
du sol, et l’unité de référence sont de manière prépondérante la parcelle, le bâtiment,
la rue. La localisation des infrastructures techniques, la gestion du patrimoine
bâti, etc., sont des exemples typiques de ce niveau.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 17.1

Conséquences organisationnelles de l’interopérabilité I
Interopérabilité stratégique et administrative
NATIONAL
REGIONAL
LOCAL
Etat
Ville
Confédération
Canton Canton Canton
Com Com Ville Com
Organismes de droit public (p.ex. services éléctriques, etc.)
Sociétés privées
Figure 1 : Imbrication des niveaux décisionnels sur le territoire
Au niveau régional (cantonal), l’information spatiale est avant tout un outil de
management territorial. Les attentes consistent donc avant tout en l’obtention
bien actualisée d’informations pertinentes et cohérentes sur l’occupation du territoire,
et sur l’état de ses équipements et de son environnement. Terrains publics,
sites contaminés, statistiques d’occupation du sol, espaces menacés par des dangers
naturels constituent quelques exemples d’informations pertinentes à ce niveau.
Au niveau national (fédéral), il s’agit avant tout de permettre la conception et la
planification de stratégies cohérentes par les organisations et institutions faîtières.
Un accès global et homogène aux informations, sans « coutures » réductrices
entre les régions, constitue un préalable nécessaire.
3 Intégration des données entre niveaux décisionnels
Les données de base nécessaires à l’accomplissement des missions de ces différents niveaux
stratégiques sont toutefois partiellement les mêmes : des indicateurs d’occupation
du territoire à l’échelle d’un canton peuvent être déduits des plans d’affectation communaux,
des statistiques de l’utilisation du sol à l’échelle nationale peuvent être agrégées
à partir de données locales sur l’utilisation du sol, etc. Pour des raisons d’efficacité,
les données correspondantes doivent être saisies et gérées une seule fois, au niveau le plus approprié
(principe formulé dans le rapport [INSPIRE 2002] pour les infrastructures de données
géographiques).
Les besoins propres à chaque niveau décisionnel, énumérés ci-dessus, doivent cependant
tous être pris en compte lors de la saisie des données et de leur diffusion, quel que
17.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Conséquences organisationnelles de l’interopérabilité I
Interopérabilité stratégique et administrative
soit l’organisme en charge de sa réalisation. Quelques difficultés récemment rencontrées
témoignent des difficultés dues à cette interdépendance des besoins :
Des communes dépositaires de leurs données cadastrales sont réticentes à remettre
ces données à l’autorité cantonale, de crainte d’une centralisation excessive.
Mais comment les services cantonaux pourraient-ils alors réaliser une gestion
globale des terrains de l’Etat ?
Des cantons dépositaires de données à grande échelle ne voient en contrepartie
par l’intérêt de promouvoir une qualité systématique, clairement documentée,
de ces données. Ces données ne sont dès lors pas utilisables pour des tâches de
gestion à l’échelle foncière.
Des cantons s’opposent à l’harmonisation de structures de données demandée
par la Confédération, afin de permettre un accès « sans couture » à travers toute
la Suisse.
De tels dysfonctionnements existent aussi entre services publics et entreprises privées.
Pourquoi a-t-il donc fallu refaire une saisie à neuf du réseau routier suisse pour les besoins
de la navigation automobile ?
4 Interopérabilité stratégique et administrative :
une ressource à développer !
La réutilisation de données entre différents niveaux stratégiques implique donc que
chaque acteur d’un niveau décisionnel connaisse (et reconnaisse !) les besoins des autres
niveaux décisionnels, et qu’il soit prêt à assurer la saisie des données dont il est responsable
conformément aux besoins de l’ensemble des partenaires.
Cette exigence ne concerne pas que les dimensions techniques et organisationnelles de
l’interopérabilité. Elle exige une forme de partage de reconnaissance et de partage
d’objectifs et de missions. Plus difficile à satisfaire que la faisabilité technique des
échanges de données, elle fait de l’interopérabilité stratégique et administrative un
prérequis à l’interopérabilité technique, sémantique et organisationnelle déjà présentée
au cours de ce séminaire. Elle traduit dans les faits un second principe proposé dans
le rapport [INSPIRE 2002] : administrative interoperability should precede geospatial interoperability.
La bonne prise en compte de ce principe d’interopérabilité stratégique et administrative
devrait aussi faciliter l’acceptation et la mise en œuvre par l’ensemble des acteurs de
quelques instruments d’une bonne « gouvernance » de l’interopérabilité :
On cherchera à déléguer la saisie et la gestion de données d’intérêt commun à
une seule instance.
Pour garantir une qualité adéquate de ces tâches, répondant aux besoins essentiels
de l’ensemble des partenaires, des normes doivent être définies au niveau
décisionnel le plus élevé (normes SNV/ASN pour l’ensemble de la Suisse).
Interopérabilité pour l'utilisation généralisée de la Géoinformation 17.3

Conséquences organisationnelles de l’interopérabilité I
Interopérabilité stratégique et administrative
Bibliographie
Buser, R., 2005, Conséquences organisationnelles de l’interopérabilité, Actes de la journée
d’étude « Interopérabilité pour l’utilisation généralisée de la géoinformation », mars
2005, A. Carosio éd., ETH Zürich.
INSPIRE, 2002, INSPIRE Architecture and Standards Position Paper, JRC-Institute for Environment
and Sustainability, Ispra.
Moreni, C. & al., 2003, Etude préliminaire au projet e-geo.ch : aspects organisationnels
et techniques, Rapport sur mandat de la COSIG, EPFL-LASIG et ETHZ-Geoinformation.
Morf, A. & Dorfschmied, J., 2005, Modèles standardizes ou interopérabilité sémantique,
Actes de la journée d’étude « Interopérabilité pour l’utilisation généralisée de la géoinformation
», mars 2005, A. Carosio éd., ETH Zürich.
17.4 Interopérabilité pour l'utilisation généralisée de la Géoinformation

18
L’interopérabilité en pratique
Expériences acquises lors de projets
menés en Suisse comme à l’étranger
Ivo A. Leiss, Ernst Basler + Partner AG
Ivo A. Leiss, Dr.
Zollikerstr. 65
CH-8702 Zollikon
Tél :
Fax :
E-mail :
+41 44 395 12 80
+41 44 395 12 34

1 Introduction
L’interopérabilité dans le cadre de l’utilisation d’informations géographiques (ou géoinformations)
est un thème omniprésent en matière de projets de SIG dans les domaines
de l’aménagement et de l’environnement. Dans la pratique, on se trouve confronté à
l’interopérabilité dans diverses circonstances :
lors de l’échange de géodonnées (par exemple avec des mandants ou des entreprises
partenaires)
lors de l’échange d’applications et de systèmes (par exemple des applications de
gestion dépourvues de référence géographique)
lors de l’échange de processus (par exemple un service destiné à la géocodification
d’adresses).
La présente contribution a pour but d’apporter un éclairage sur l’interopérabilité
d’informations géographiques à la lumière d’une sélection de projets conduits par la société
Ernst Basler + Partner AG, en Suisse comme à l’étranger. Des problèmes types en
matière d’interopérabilité et les solutions adoptées sont présentés. L’importance de
l’interopérabilité pour le futur est enfin évaluée.
2 Projets cités à titre d’exemples
2.1 Projets nationaux : trois exemples cantonaux
L’interopérabilité dans le cadre de l’utilisation d’informations géographiques dans les
cantons est illustrée à l’aide de trois projets de SIG différents (tableau 1).
Nom du projet
Mandant Tâches assignées Partenaires du projet
(période prévue)
Bruits de la rue,
Zurich
(2000 – 2005)
Carte des risques
de crue, Lucerne
(2003 – 2005)
SPATZ
Mapserver,
Grisons
(2004 – 2005)
Direction des
constructions du
canton de Zurich,
service de la
protection contre le
bruit
Département des
constructions, de
l’environnement et de
l’économie du canton
de Lucerne, service
des transports et de
l’infrastructure
Service archéologique
du canton des
Grisons
Portage du cadastre des
bruits de la rue
(émissions), analyse par
SIG des bâtiments touchés
par le bruit (nuisances)
Etablissement d’une carte
des risques de crue dans le
canton de Lucerne,
établissement d’un
cadastre des crues
survenues
Représentation
d’informations
archéologiques (SPATZ)
au sein d’un service
cartographique via
Intranet, interaction entre
le système d’information
archéologique et le service
cartographique (exemple :
édition de points)
Norsonic Brechbühl
AG
F. Preisig AG
Centre SIG du canton
de Zurich
Kost+Partner AG
ITECO
Service des
mensurations et de la
géoinformation du
canton de Lucerne
Centre de compétence
en SIG du canton des
Grisons
GWZ Informatik
Tableau 1 : Trois projets cantonaux en bref, bases de réflexions ultérieures.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 18.1

Conséquences organisationnelles de l’interopérabilité II
L’interopérabilité en pratique: expériences acquises lors de projets menés en Suisse comme à
l’étranger
2.2 Projets internationaux : système d’information cartographique
transnational sur Internet pour les inondations (TIMIS flood)
Le projet « TIMIS flood » vise à la mise en place d’un système d’information transnational
pour les inondations couvrant les bassins versants internationaux de la Moselle et de
la Nahe. Des technologies innovantes (SIG, informatique) sont mises en œuvre à cette
fin. Le projet « TIMIS flood » doit mettre les informations suivantes à disposition :
des données spatiales harmonisées et d’un haut niveau qualitatif,
des informations relatives aux dangers et aux risques ainsi que
des informations destinées à la prévision et à l’avertissement.
L’ensemble des services d’information résultants doit au final être combiné sur une
plate-forme unique baptisée « TIMIS flood Service ». Ce service sera accessible pour les
différents utilisateurs (administrations, scientifiques, grand public) en 2008.
Les mandants sont sept administrations différentes issues de trois pays (Allemagne,
France, Luxembourg). En sa qualité de maître d’œuvre, la société Ernst Basler + Partner
AG est responsable de la coordination du projet et de la mise en œuvre du système
d’information. Elle bénéficie de l’assistance de l’entreprise Hydrotec dont le siège est à
Aix-la-Chapelle (Allemagne) et s’appuie sur un grand nombre de sous-traitants pour la
saisie des données. Des informations complémentaires peuvent être obtenues à l’adresse
Internet http://www.timisflood.net.
3 Les divers aspects de l’interopérabilité
3.1 Echange de géodonnées
Dans le cadre des projets cités en exemple, l’échange des géodonnées constitue de loin le
défi le plus important à relever dans le domaine de l’interopérabilité. Des données doivent
être échangées entre les intervenants suivants (figure 1) :
la société Ernst Basler + Partner, en tant que mandataire
les mandants
les partenaires du projet (entreprises partenaires, sous-traitants, autres intervenants)
des fournisseurs externes de géodonnées (par exemple swisstopo, des bureaux
de géomètres).
Fournisseur
de données
Partenaire
du projet
ESP
(mandataire)
Mandant
Figure 1 : Les intervenants lors de l’échange de géodonnées.
18.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Conséquences organisationnelles de l’interopérabilité II
L’interopérabilité en pratique : expériences acquises lors de projets menés en Suisse comme à
l’étranger
Les formats d’échange standardisés sont très peu utilisés à l’heure actuelle. En règle générale,
un format de transfert approprié est défini préalablement à un échange de données,
en fonction des possibilités des systèmes source et destination (tableau 2).
Formats d’échange pour des données vectorielles Proportion (estimée)
ESRI (Shape, Coverage, Personal Geodatabase, fichier 60%
d’exportation)
DAO (DXF, DGN) 10%
Bases de données et tableaux (MS Access, MS Excel, dbf) 10%
XML 10%
Autres (INTERLIS, ASCII) 10%
Formats d’échange pour des données tramées (raster) Proportion (estimée)
Tiff (World, Geo) 50%
ESRI (Grid) 20%
ASCII 20%
Autres 10%
Tableau 2 : Formats utilisés pour l’échange de géodonnées. Les proportions (estimées) se
rapportent au nombre d’informations à transférer dans les projets cités en exemple.
La proportion élevée de formats ESRI s’explique par le fait que la société Ernst Basler +
Partner AG s’est spécialisée dans les produits ESRI et qu’elle travaille donc fréquemment
avec des mandants et des partenaires de projets utilisant également des produits
ESRI.
Seules 20% de toutes les données mises à notre disposition par les mandants contiennent
des métadonnées exploitables. Dans ce cas également, aucun standard n’est encore parvenu
à s’imposer au niveau intercantonal et encore moins au niveau international.
3.2 Echange d’applications et de systèmes
L’utilisation commune d’applications a gagné en importance au cours des dernières années.
L’interconnexion croissante généralisée des systèmes en est la raison.
Parmi les projets cités en exemple, cet aspect est présent dans les projets à base Internet
que sont « SPATZ Mapserver » et « TIMIS flood ».
Dans le cas du système d’information archéologique SPATZ, il s’agit d’une base de
données Oracle avec une interface utilisateur pour l’exploitation des données. L’accès en
lecture à SPATZ s’effectue via « OGR Virtual Format », un pilote Open Source, lisant des
objets géographiques simples dans une base de données ODBC à l’aide d’un fichier de
configuration XML. L’accès en écriture à la base de données Oracle est garanti par une
interface de la société GWZ Informatik (distributeur de SPATZ). Les paramètres sont
alors transmis au moyen d’un fichier ASCII.
Comme il s’agit d’une application Intranet dans le cas de SPATZ Mapserver, aucun
format d’échange compatible OGC (WFS, WMS) n’est actuellement mis en œuvre.
Pour le projet « TIMIS flood », les services d’information géographique sont actuellement
conçus sur une base WFS et WMS. Il s’agit déjà d’une fonctionnalité standard dans
le cas du portail Internet (sur une base ESRI ArcIMS). Toutefois, il n’est pas encore garanti
à l’heure actuelle que tous les serveurs nationaux acceptent ces formats OGC. Nous
partons cependant du principe que ces formats OGC s’imposeront au cours des prochaines
années.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 18.3

Conséquences organisationnelles de l’interopérabilité II
L’interopérabilité en pratique: expériences acquises lors de projets menés en Suisse comme à
l’étranger
3.3 Echange de processus
L’interopérabilité des processus reste très peu développée à l’heure actuelle. Dans le
contexte de services Internet (par exemple pour la géocodification d’adresses), cet aspect
devrait gagner en importance à l’avenir.
Parmi les projets cités en exemple, seul « TIMIS flood » a prévu l’échange de processus.
Il devrait être possible, à compter de 2008, de générer la prévision de crue pour un point
en territoire allemand (Rhénanie-Palatinat) sur les berges de la Moselle en combinant
différents processus : les prévisions du service météorologique allemand, les mesures de
cotes actuelles dans le bassin versant (France, Luxembourg et Allemagne), une prévision
d’écoulement en Bade-Wurtemberg et une modélisation hydraulique pour la position
considérée en Rhénanie-Palatinat. Le résultat fourni à l’utilisateur sera une prévision de
crue sous forme de carte et de texte (semblable à une prévision météorologique). Les
mêmes processus pourront être mis à contribution pour des localisations quelconques
au Luxembourg.
Toutes les questions ne sont cependant pas résolues. En effet, les obstacles les plus importants
résident moins dans la faisabilité technique que dans l’acceptation de procédures
et de processus différents (étrangers). Ainsi, le succès du projet dépend moins de
normes et de standards que d’une bonne communication en interne comme en externe.
3.4 Interopérabilité et planification de projet
Les aspects mentionnés précédemment n’interviennent qu’une fois le projet lancé. Les
expériences acquises en pratique ont toutefois permis d’établir que l’investissement en
temps, en argent et en communication requis par l’interopérabilité était généralement
sous-estimé. Les informations suivantes sont généralement absentes ou insuffisamment
disponibles au stade de la planification d’un projet :
Qualité des géodonnées ou des systèmes
Outre la qualité en principe à vérifier de la base des données, les formats utilisés
peuvent à eux seuls provoquer des problèmes de qualité : un format de DAO
impose d’autres règles d’intégrité à un jeu de données géométriques qu’un format
de SIG. Et même entre formats de SIG différents, la rigueur des exigences
concernant l’organisation et la cohérence des données peut grandement varier.
Elaboration ou adaptation des interfaces requises
Durant le traitement d’un projet, il peut survenir, pour des raisons purement
techniques, que de nouvelles interfaces deviennent nécessaires ou que des interfaces
projetées aient à être adaptées.
Documentations complètes
Au stade de la planification, des propriétés des données ou des systèmes à utiliser
sont implicitement acceptées alors qu’elles ne sont pas documentées, qu’elles
le sont de manière insuffisante ou qu’elles ne sont pas présentes au sein de métadonnées.
Il convient enfin d’ajouter, pour être tout à fait complet, que des idées de projets sont
régulièrement enterrées avant même d’avoir réellement vu le jour en raison de tarifs
trop élevés pour les géodonnées.
18.4 Interopérabilité pour l'utilisation généralisée de la Géoinformation

4 Bilan
Conséquences organisationnelles de l’interopérabilité II
L’interopérabilité en pratique : expériences acquises lors de projets menés en Suisse comme à
l’étranger
Les conclusions suivantes peuvent être tirées des projets esquissés précédemment, en
matière d’interopérabilité appliquée à l’utilisation de géodonnées :
Dans le cas de projets de SIG dans les domaines de l’aménagement et de
l’environnement, l’échange de données est la préoccupation principale en matière
d’interopérabilité.
Rares sont les normes ou les standards à être mis en œuvre pour l’échange de
données. Les formats ESRI Shape et Tiff sont les plus fréquemment utilisés, mais
cela dépend en premier lieu des possibilités (des logiciels de SIG) des parties
concernées. INTERLIS est actuellement (trop) peu utilisé.
La progression de XML comme format d’échange est continue, l’interopérabilité
ayant toutefois à souffrir de ses multiples déclinaisons (WFS, GML, ESRI XML,
INTERLIS 2, etc.).
Les formats OGC WFS et WMS parviendront à s’imposer pour devenir des standards,
au moins pour les projets internationaux. Les autres formats disparaîtront
du marché ou seront confinés à des niches.
Le constat suivant est finalement à dresser : le nombre de projets pour lesquels des données
ou des systèmes sont à réunir croît en permanence. C’est la raison pour laquelle
l’interopérabilité des applications et des processus s’améliorera au cours des années à
venir. Quant à savoir si des normes et des standards s’imposeront à l’avenir : nous, prestataires
de services dans le domaine de l’information géographique avons de toute façon
à nous adapter, que ce soit aux besoins des mandants et des partenaires des projets ou
aux standards prédéfinis.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 18.5

Conséquences organisationnelles de l’interopérabilité II
L’interopérabilité en pratique: expériences acquises lors de projets menés en Suisse comme à
l’étranger
Abréviations et définitions
Abréviation / notion
ASCII
DAO
DXF
DGN
GML
Grid
INTERLIS
ODBC
OGC
OGR
Oracle
Shape
SIG
Tiff
TIMIS
SPATZ
WFS
WMS
XML
Définition
American Standard Code for Information Interchange ; codage
d’un total de 128 caractères (lettres, chiffres, signes de ponctuation
et caractères spéciaux)
Dessin assisté par ordinateur
Format de fichier à base vectorielle de la société Autodesk, développé
spécialement pour des solutions de DAO.
Format de fichier à base vectorielle de la société Intergraph
Geography Markup Language ; format à base XML pour l’échange
de données de SIG
Format de fichier à base tramée (raster) de la société ESRI
Langage de description et de modélisation de données, basé sur
XML dans sa version 2
Open Data Base Connectivity, pilote de base de données pour des
accès à une base de données liés à des applications
Open Geospatial Consortium
Bibliothèque de logiciels pour l’accès à différents formats de SIG
vectoriels
Fournisseur de logiciels de bases de données
Format de fichier pour des données vectorielles développé par la
société ESRI
Système d’information géographique
Format de fichier pour la mémorisation de données tramées
Transnational Internet Map Information System
Synergie Projekt Archäologie Thurgau und Zürich (projet de synergie
des cantons de Thurgovie et de Zurich dans le domaine de
l’archéologie)
Web Feature Service ; protocole Internet destiné à la lecture et à
l’écriture de données de SIG en format vectoriel, basé sur GML
Web Map Service, protocole Internet destiné à la lecture et à
l’écriture de cartes numériques
Extensible Markup Language ; format destiné à la génération de
documents structurés
18.6 Interopérabilité pour l'utilisation généralisée de la Géoinformation

19
Perspectives pour les professions de la
géomatique
Christian Kaul, Kaul Beratungen GmbH
Kaul Beratungen GmbH
Christian Kaul
Flaachtalstrasse 8
CH-8412 Hünikon
Tél :
Fax :
E-mail :
+41 52 343 79 01
+41 52 343 79 02

Perspectives pour les professions de la géomatique …
… ou les conditions nécessaires à l’éclosion de la frêle fleur baptisée « Interopérabilité ».
1 Introduction
Débutons par l’affirmation principale : à elles seules, les nouvelles possibilités techniques
offertes par l’interopérabilité ne garantissent aucun nouveau marché au domaine
de la géomatique !
L’interopérabilité n’est pas non plus à considérer comme un projet technique qui, une
fois achevé, rend l’entreprise concernée « interopérable ». Elle doit au contraire devenir
une tournure d’esprit de base dont tous les professionnels de la géomatique devront être
imprégnés. Ainsi, les développements considérables à attendre dans ce domaine pourront-ils
être utilisés de façon active.
Une réelle symbiose entre différents niveaux et sous-ensembles est indispensable pour
que les chances et les possibilités offertes par l’interopérabilité ouvrent de nouvelles
perspectives aux métiers de la géomatique. Les défis techniques ne représentent dans ce
cadre que l’un des pétales d’une fleur aux multiples facettes.
Pensée et
action
systémiques
Capacités
techniques
Visionnaire,
coopératif,
généraliste
Poursuite
la formation
professionnelle
Travail au
sein de
projets
multidisciplinaires
Interopérabilité pour l'utilisation généralisée de la Géoinformation 19.1

Conséquences organisationnelles de l’interopérabilité II
Perspectives pour les professions de la géomatique
2 Au cœur : l’entrepreneur
Dans le secteur privé comme dans l’administration publique, la personnalité de
l’entrepreneur (ou du dirigeant) joue un rôle déterminant. La thématique de
l’interopérabilité ne peut pas être abordée sur un mode passif - réactif. Elle requiert la
présence d’un esprit visionnaire ayant une idée, même vague, de la direction à prendre
et de la destination à atteindre. Toute organisation dépourvue de vision est tôt ou tard
vouée au déclin à notre époque enfiévrée.
L’interopérabilité implique la coopération. Les responsables se doivent de donner
l’exemple en matière de capacité et de volonté à coopérer avec d’autres organisations et
doivent promouvoir une telle attitude. Et ce rapprochement peut être l’occasion de reconnaître
les mérites et les capacités de ses partenaires, socle sur lequel se bâtiront les
futures réussites communes.
L’interopérabilité des géodonnées s’accompagne d’un très fort accroissement du contenu
des données qu’une organisation a à gérer. Ainsi, les aptitudes du généraliste bénéficient-elles
d’un regain d’intérêt. Selon le prof. Dr Hans Ulrich, un généraliste est « ....une
personne qui, sans posséder une connaissance exhaustive de sa propre sphère d’activité,
en a une compréhension globale ». L’entrepreneur doit donc se consacrer davantage à la
vue d’ensemble, globale et compléter en cela les spécialistes au sein des entreprises.
3 Les pétales : l’entreprise
Les quatre domaines suivants sont d’importance dans le contexte de l’interopérabilité
pour les collaborateurs d’une entreprise :
Les capacités techniques
L’entreprise doit maîtriser les techniques nécessaires à un travail « interopérable ».
L’informatique sera appelée à jouer un rôle encore plus fort dans ce cadre. Une entreprise
doit être en mesure de satisfaire les exigences de ses clients, lesquelles changent à
une vitesse sans cesse croissante, tout en faisant simultanément un usage actif du développement
technique au rythme effréné.
Sur le plan du contenu, l’intérêt va très fortement se déplacer vers les technologies Internet.
Le développement des capacités en matière de techniques de données devra se
poursuivre en parallèle.
Le travail au sein de projets multidisciplinaires
L’interopérabilité offre la possibilité d’une collaboration efficace au sein de projets interdisciplinaires.
Cela implique toutefois que tous les participants fassent preuve
d’ouverture et d’intérêt pour les autres thèmes et les autres équipes et aient clairement
conscience qu’une telle attitude n’est pas innée, mais qu’elle peut et doit s’acquérir et
être développée.
La pensée et l’action systémiques
Les exigences imposées aux produits du secteur de la géomatique vont continuer à croître.
Et les réponses simples et claires se feront de plus en plus rares. Les principes et les
méthodes de la systémique ont fait leurs preuves depuis de longues années dans un
contexte de cette nature. Ce mode de pensée et d’action ne doit pas être réservé à une
poignée de spécialistes car il constitue la base du succès de l’interopérabilité pour tous
les métiers de la géomatique.
19.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Conséquences organisationnelles de l’interopérabilité II
Perspectives pour les professions de la géomatique
La poursuite permanente de la formation professionnelle
Les capacités décrites précédemment et exigées des collaborateurs de l’entreprise ne
peuvent pas être acquises du jour au lendemain, en plus de leur travail quotidien. Une
politique de formation continue active, ciblée et surtout permanente de tous les collaborateurs
est nécessaire à cette fin : quelques exercices destinés à régler des urgences à
court terme ne permettent pas au personnel d’une entreprise d’acquérir durablement les
connaissances indispensables et encore moins d’en maintenir le niveau.
4 Les sépales : une base durable
L’ONU définit le développement durable comme étant : « ..... un développement permettant
de satisfaire les besoins actuels sans risquer que les générations futures ne puissent
pas répondre aux leurs ». Cette définition est largement reconnue et constitue le
fondement de l’« Agenda21 » des Nations unies.
Les trois pôles que sont la société, l’économie et l’environnement sont fréquemment associés
à la notion de développement durable.
Société
Les prestations de services effectuées dans le secteur de la géomatique entretiennent
traditionnellement un lien étroit avec la société par l’intermédiaire de leur mandant
principal : les pouvoirs publics. Pour partie, les activités dans le domaine de
l’interopérabilité sont très fortement marquées par le cadre de la société. Dans ce
contexte, une très grande importance est à accorder au régime juridique et le cadre juridique
est toujours d’un poids bien supérieur à son équivalent technique. C’est pourquoi
de bonnes connaissances juridiques et une étude approfondie des conditions prévalant
en cette matière sont à la base de la réussite des projets comme des produits.
La normalisation constitue un autre facteur décisif. Comme les présentes journées
d’étude le mettent en lumière, des efforts très conséquents sont actuellement produits au
niveau de l’ISO et du CEN. Il convient donc de faire valoir la solide expérience pratique
acquise dans ce domaine en Suisse pour en faire bénéficier ces travaux de normalisation.
Economie
Cela signifie tout simplement que les activités déployées dans le domaine de
l’interopérabilité produisent des effets positifs au final. Ce résultat n’est toutefois atteint
que si les efforts fournis sont compensés par un bénéfice largement attendu. En conséquence,
c’est l’utilisateur ou le client final qui définit les conditions de base de la rentabilité,
lesquelles ne doivent pas découler des visions propres aux professionnels de la
branche. Cela suppose cependant une connaissance bien plus approfondie et plus honnête
des réels besoins des clients.
Ces réflexions valent également pour les activités financées par l’Etat. Un service géographique
pourrait être financé par les recettes fiscales de l’Etat et proposé gratuitement
aux utilisateurs. Mais ici aussi, un bénéfice à la hauteur des montants investis doit être
recueilli par l’Etat.
Environnement
Ce pôle englobe les rapports entretenus avec les ressources au sens le plus large, autrement
dit l’exigence imposée de conduire les activités du ressort de l’interopérabilité en
minimisant l’investissement à consentir à cette fin en termes d’énergie, de matériel, de
Interopérabilité pour l'utilisation généralisée de la Géoinformation 19.3

Conséquences organisationnelles de l’interopérabilité II
Perspectives pour les professions de la géomatique
travail et d’argent. Dans le domaine de l’interopérabilité, cet objectif peut d’abord être
atteint par l’intermédiaire d’une excellente capacité d’actualisation des solutions et
d’une protection de l’investissement indépendante de tout système pour les données.
Même la solution technique la plus géniale qui soit ne pourra pas être considérée
comme étant durable si elle doit être revue de fond en comble tous les deux ans. La garantie
de la protection de l’investissement et la mise à jour systématique des données
constituent conjointement une lourde responsabilité que la branche doit assumer envers
les futures générations.
5 De nouvelles perspectives grâce à l’interopérabilité
Les affirmations suivantes peuvent être avancées sur la base des réflexions menées jusqu’à
présent :
le traitement de projets étendus, d’ampleur régionale ou suprarégionale, gagnera
en simplicité
la collaboration entre équipes internes et externes différentes gagnera en efficacité
des produits inenvisageables pour une entreprise seule (des solutions de portail
pour l’utilisation de géodonnées par exemple) pourront être développés et lancés
en partenariat
la collaboration éprouvée entre les pouvoirs publics et le secteur privé (Public-
Private-Partnership, PPP) pourra être approfondie
de nouveaux champs d’activité s’ouvriront du fait de l’intensification des collaborations
et d’une meilleure compréhension mutuelle entre les acteurs concernés
l’utilisation conjointe de technologies, de savoir-faire, de capacités (ressources en
personnel, en matériel, en logiciels, etc.), de lignes de données, etc. gagnera en
attrait
des aptitudes déjà possédées pourront être communiquées plus aisément sous la
désignation d’ « interopérabilité ».
Informations complémentaires :
- Ouvrage « Systems Engineering, Methodik und Praxis », éditeur : Daenzer / Huber,
Verlag Industrielle Organisation, Zurich, ISBN 3-85743-998-X
- Concernant l’ « Agenda 21 » :
http://www.are.admin.ch/are/fr/nachhaltig/index.html
19.4 Interopérabilité pour l'utilisation généralisée de la Géoinformation

20
Tarification, problématique des coûts
Jürg Kaufmann, KAUFMANN Consulting / FIG
Jürg Kaufmann, dipl. Ing. ETH
KAUFMANN CONSULTING/FIG
Hauffeld 109
CH-8455 Rüdlingen
Tél :
Fax :
E-mail :
+41 1 867 14 36
+41 1 867 34 89

1 Introduction
L’objet des considérations formulées dans la suite est de mettre en évidence les conséquences
de l’interopérabilité sur la structure des coûts et la fixation des tarifs.
Certaines notions sont à clarifier avant d’aborder ces questions plus en détail :
Interopérabilité :
Collaboration au sein d’un système ouvert (conformément au modèle client / serveur). La collaboration
entre les applications peut s’effectuer indépendamment du matériel utilisé, des systèmes
d’exploitation mis en œuvre, de la technologie de réseau à laquelle il est recouru et de
l’implémentation d’une application.
Tarif :
1. Liste à valeur obligatoire récapitulant les barèmes des prix et des émoluments fixés pour un
certain nombre de livraisons, de prestations, de taxes, etc.
2. Niveau de prix, de salaires, de rémunérations, etc. défini par contrat ou par ordonnance.
Tarifer :
Déterminer le niveau d’une prestation par un tarif.
La notion de coût est considérée comme étant connue.
Le processus traditionnel de fourniture d’une prestation va d’abord être présenté afin
que les conséquences de l’interopérabilité puissent être évaluées. La comparaison avec le
déroulement en cas de recours à l’interopérabilité pourra fournir des indications sur la
modification des facteurs relatifs aux coûts.
Les effets produits par l’interopérabilité sur la structure des coûts seront mis en lumière
et un chapitre ultérieur présentera les réflexions concernant la tarification.
L’accent sera ensuite mis sur les résultats du groupe de réflexion sur la « diffusion de
données et les émoluments » de même que sur les travaux de la COSIG en matière de
tarification et en rapport avec les conséquences de l’interopérabilité.
Quelques conclusions viendront enfin esquisser le comportement futur de la société de
l’information.
2 Conséquences de l’interopérabilité sur le processus de
fourniture d’une prestation
La figure 1 présente le schéma bien connu de tous décrivant le processus de fourniture
d’une prestation.
Commande
Réception de la livraison
Paiement
Demande auprès de la logistique
Préparation de la livraison
Encaissement
Figure 1 : schéma général de la fourniture de prestations
Ce processus n’a pas varié depuis que les hommes pratiquent des activités commerciales
et joue aujourd’hui encore un rôle dominant. Certaines innovations ont conduit à des
Interopérabilité pour l'utilisation généralisée de la Géoinformation 20.1

Conséquences organisationnelles de l’interopérabilité II
Tarification, problématique des coûts
versions abrégées de ce processus, dans le cas par exemple du libre service, ou à des méthodes
de paiement plus efficaces, comme pour les codes-barres. Le shopping en ligne
(ou e-shopping) fonctionne lui aussi selon ce même schéma. La vendeuse est remplacée
par un terminal et à ses conseils se sont substitués du texte et des photos. Toutefois, ce
type de fourniture de prestation n’est pas encore parvenu à trouver de solution de remplacement
réellement convaincante au sourire et au rayonnement de la vendeuse ou de
la serveuse.
Le schéma parcouru est rigoureusement identique en cas de mise en application de
l’interopérabilité. A cela près, cependant, que tous les intervenants humains du processus
de fourniture de prestation sont remplacés par des machines.
Compte tenu du niveau élevé des coûts salariaux en Suisse, la fourniture de la prestation
devrait en principe s’effectuer à des conditions financièrement plus avantageuses.
Les prestations étant fournies par des automates, il est indispensable que leur imputation
s’effectue elle aussi de façon automatique.
3 Conséquences de l’interopérabilité sur les coûts
Les composants des coûts applicables à la fourniture d’une prestation sont en principe
les suivants :
les coûts d’enregistrement de la commande
les coûts de transmission de la commande
les coûts de préparation de la livraison
les coûts de livraison
les coûts de facturation et d’encaissement.
Dans le cas normal, ces coûts viennent majorer le prix de la marchandise livrée ou de la
prestation de service effectuée en tant que quote-part des frais généraux. Ce composant
des coûts n’est pas divulgué au client. La part des frais généraux peut être déterminée
lorsque les intervenants d’un processus de même que leurs coûts spécifiques sont
connus.
Les déterminations usuelles par branche des suppléments pour frais généraux constituent
la règle dans le système traditionnel.
Cependant, les machines / systèmes / automates intervenant dans l’exécution d’une
livraison ne sont plus connus a priori dans le cas d’un mode de travail « interopérable ».
La marchandise commandée est prise en livraison ou consultée là où elle est disponible.
Indépendamment des modalités de fixation d’un prix pour la marchandise ou la prestation
de service, une solution se passant de supplément pour frais généraux doit être
trouvée. Les coûts de fourniture de la prestation doivent être considérés de manière séparée.
La prestation étant fournie par des automates, la saisie des facteurs contribuant à la
formation du prix doit pouvoir s’effectuer automatiquement parce qu’il devient impossible,
dans le contexte de l’interopérabilité, de suivre les chemins empruntés et de saisir
manuellement les données nécessaires à l’imputation des coûts.
Il est en outre assez peu judicieux d’intégrer séparément chacun des composants intervenant
dans la fourniture de la prestation au sein d’un système de facturation avec les
barèmes de coûts qui lui sont propres, les structures de prix des différents prestataires
de services impliqués ne pouvant en aucun cas être coulées dans un même moule.
20.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Conséquences organisationnelles de l’interopérabilité II
Tarification, problématique des coûts
C’est pourquoi il est impératif, à l’ère de l’interopérabilité, de travailler avec des tarifs
convenus.
4 Conséquences de l’interopérabilité sur la tarification
Une tarification judicieuse de la fourniture des prestations est par conséquent une nécessité,
afin que les avantages de l’interopérabilité produisent tout leur effet.
Certaines des exigences posées à la tarification ont déjà été mentionnées en relation avec
les coûts :
les facteurs contribuant à la formation du prix doivent pouvoir être déterminés,
fixés et imputés automatiquement
les tarifs définis doivent être en rapport avec le volume de travail requis pour la
fourniture de la prestation
les tarifs doivent être clairement compréhensibles pour l’auteur de la commande.
Différentes solutions ont été proposées en matière de structure des prix, mais aucune
solution unifiée n’est encore parvenue à se dégager ni à s’imposer.
5 Résultats des efforts entrepris jusqu’à présent en
matière de tarification
En Suisse, on compte deux études consacrées à la tarification. Un groupe de réflexion paritaire,
mis en place par la D+M 1 , s’est d’une part penché sur les problèmes liés à la diffusion
des données et aux émoluments. Et la COSIG a d’autre part commandé une expertise
sur la question de la tarification. Les travaux de ces deux groupes d’experts ont été
coordonnés au plus haut niveau.
Les deux études parviennent à la conclusion qu’une stratégie dite du « coût marginal »
(marginal cost) est à appliquer dans le cas des géodonnées. Le coût marginal englobe exclusivement
les coûts de traitement et de livraison. La justification invoquée pour cette
recommandation est que les géodonnées sont en règle générale acquises pour remplir
une mission conférée par la loi. Ce constat s’applique en fait à la plupart des géodonnées.
Dans le projet de loi sur l’information géographique, il est également question de
géodonnées de base d’intérêt national, cantonal ou communal, selon l’échelon de la hiérarchie
administrative ayant confié une mission à caractère légal. Les coûts
d’investissement, c.-à-d. les coûts d’acquisition des données, sont donc à supporter par
la collectivité. Afin cependant de générer un retour aussi important que possible sur ces
coûts, les données doivent être fournies aux conditions les plus favorables qui soient aux
intéressés, de façon à ce que les impôts de ces derniers soient maximisés, leurs bénéfices
n’étant pas amputés par des coûts d’acquisition élevés et atteignant donc un niveau
conséquent si des produits à forte valeur ajoutée peuvent être créés à partir de ces données.
Les travaux du groupe de réflexion ont mis en lumière le fait que les contributions aux
coûts d’investissement, telles qu’elles ont été proposées par le rapport Buschor dans le
cadre des travaux sur la réforme de la mensuration officielle et introduites dans la plupart
des cantons, n’étaient pas en mesure d’apporter une participation significative à
l’amortissement des investissements consentis pour la mensuration officielle. Si les prix
sont élevés, le nombre des acquisitions par les utilisateurs est minimisé tandis que
1 NdT :V+D = Direction fédérale des mensurations cadastrales
Interopérabilité pour l'utilisation généralisée de la Géoinformation 20.3

Conséquences organisationnelles de l’interopérabilité II
Tarification, problématique des coûts
l’équilibre du régime de diffusion n’est pas atteint. Si les prix sont modiques,
l’acquisition de données est plus fréquente, mais les montants encaissés sont trop faibles
pour permettre une durée d’amortissement convenable. Le groupe de réflexion a par
conséquent recommandé de revenir au régime du coût marginal, en vigueur jusqu’à
l’introduction de la proposition Buschor.
Le groupe de réflexion s’est également penché sur les barèmes tarifaires. Il a tenté, dans ce
cadre, d’intégrer les conséquences de l’interopérabilité à sa réflexion.
Les facteurs de coûts suivants répertoriés sur la figure 2 ont été pris en compte :
Composant Mode de facturation Prix proposé
Traitement administratif d’un mandat Forfaitaire par mandat CHF 50.-/mandat
Traitement technique d’un mandat Forfaitaire par mandat CHF 50.-/mandat
Volume de travail requis pour la livraison
du résultat
Forfaitaire par mandat CHF 20.-/mandat
Utilisation de l’infrastructure pour la
génération du produit souhaité
CHF/mégaoctet de
données acquises
CHF 5.-/mégaoctet de
données vectorielles
(en format INTERLIS)
Utilisation de l’infrastructure Internet en cas
Par demande
CHF 10.- par demande
d’acquisition des données par ce moyen
Figure 2 : proposition de tarification du groupe de réflexion
Les quatre premiers composants entrent en ligne de compte si la diffusion est du ressort
des services publics. Les composants grisés sont facturés en cas d’utilisation d’Internet
ou de toute autre infrastructure « interopérable ».
Ensemble, la saisie et l’imputation de la quantité de données effectivement acquise constituent
un mode de facturation résolument neuf et transparent, le format INTERLIS bien
défini étant mis à contribution pour les données vectorielles et un format équivalent
étant employé pour les données tramées (raster). Ce mode de facturation doit permettre
de prendre en compte la préparation de la livraison. Une facture est ainsi établie à
l’acquéreur, correspondant objectivement aux données qu’il a acquises, de sorte qu’il
peut influer sur le prix d’achat.
Ce canevas devrait pouvoir permettre de relever les défis lancés par l’interopérabilité.
Cependant, la capacité réelle du mode de facturation et les niveaux des tarifs sont à tester
dans le cadre d’une utilisation en pratique.
La stratégie du coût marginal a bien été prise en compte dans le projet de la nouvelle loi
sur l’information géographique, mais il n’est pas encore certain qu’elle soit effectivement
mise en application. Quoi qu’il en soit, il semble sage de fixer séparément les coûts
de traitement et de livraison et de s’éloigner ainsi du modèle traditionnel du supplément
pour frais généraux.
6 Conclusions
L’interopérabilité ne modifie pas fondamentalement la problématique des coûts, mais
déplace le centre de gravité vers des processus fortement automatisés pour la fourniture
des prestations. Des tarifs simples et transparents doivent être définis afin de développer
des solutions « interopérables » également judicieuses sur le plan commercial.
Des premiers modes de facturation ont déjà été élaborés. Il ne reste donc qu’à les tester
dans le cadre d’une utilisation en pratique et éventuellement à les adapter à la lumière
des expériences réalisées.
20.4 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Conséquences organisationnelles de l’interopérabilité II
Tarification, problématique des coûts
Bibliographie
Groupe de réflexion sur la diffusion de données et les émoluments [2003] « Proposition
pour la future réglementation de la diffusion des données et des émoluments dans la
Mensuration Officielle », D+M, Berne
Groupe de Réflexion Datenabgabe und Gebühren [2003] 'Vorschlag für die zukünftige
Regelung der Datenabgabe und der Gebühren in der Amtlichen Vermessung, V+D,
Bern
COSIG - Tarif [2002] Nouvelles stratégies de tarification et de commercialisation des
géodonnées de la Confédération, INFRAS pour le compte de la COSIG, 26 septembre
2002.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 20.5

21
Géoréférencement, interopérabilité
entre les données de la mensuration et
les informations spatiales
superposées, hiérarchie des données
et actualisation des données spatiales
subordonnées
Horst Düster, Amt für Geoinformation,
Canton de Soleure
Horst Düster, Dr.
Amt für Geoinformation Kanton Solothurn
Abteilung SO!GIS Koordination
Werkhofstr. 65
CH-4509 Solothurn
Tél :
Fax :
E-mail :
+41 32 627 25 32
+41 32 627 22 14

1 Situation
Une administration cantonale présente des similitudes avec une structure d’entreprise
hétérogène. Les organes administratifs sont subdivisés selon une structure très variée
pour l’exécution de leurs missions et les unités correspondantes sont par surcroît séparées
dans l’espace. Le besoin en informations, et spécialement en informations géographiques,
est toutefois prédominant chez tous.
Un grand nombre de sources d’informations fonctionnant indépendamment les unes
des autres est disponible pour satisfaire ces besoins en informations. En règle générale,
ces sources présentent des redondances entre elles. Ainsi, les appartenances au registre
foncier ou les noms locaux de différents objets sont par exemple conservés de façon redondante
dans des systèmes de gestion de données différents. Une révision et une mise
à jour cohérentes de ces informations en fait dénuées de liens entre elles sont en règle
générale impossibles.
La conséquence de cette situation est une utilisation inefficace des ressources, due en
particulier à des incertitudes au niveau des décisions.
Le modèle de SIG élaboré dans le canton de Soleure met principalement l’accent sur
l’accroissement de la productivité, l’amélioration de la sûreté des décisions et par suite
l’accroissement de son bénéfice opérationnel, de même que sur l’amélioration du bénéfice
stratégique dans le but de doter l’Etat de structures et d’instruments plus performants.
2 Stratégie
La vision dans laquelle s’inscrit la mise en œuvre stratégique du modèle prévoit une accélération
et une amélioration des processus fondamentaux d’administration et de décision
sur la base d’informations géographiques et attributaires numériques cohérentes. A
cette fin, les informations spatiales et attributaires doivent pouvoir être réunies de façon
normalisée et logique, sans redondance. Cela suppose une interopérabilité technique
fournie par des interfaces ouvertes. Pour que ces dernières puissent à leur tour être utilisées,
une interopérabilité conceptuelle via des systèmes ouverts est alors supposée.
Du fait de l’objectif gouvernemental fixé pour 2005, à savoir que « 90% des utilisateurs
et des applications standard doivent migrer vers des serveurs de terminaux sous Linux
», le service de coordination SO!GIS se sert largement de logiciels libres et ouverts.
Le recours à Open Source GIS s’offre ainsi à nous pour la mise en œuvre concrète de la
vision dans le respect de l’objectif gouvernemental. En l’absence de tout intérêt, de la
part des concepteurs de ce logiciel, à lier les utilisateurs à un système / produit dépendant
de son fabricant, un grand nombre de formats de données différents est accepté. En
outre, une large assistance est garantie aux spécifications et aux interfaces ouvertes telles
que les multiples spécifications OGC. Enfin, les interfaces système utilisées du logiciel
Open Source GIS sont documentées de manière ouverte et librement disponibles.
3 Environnement système
Les composants Open Source GIS suivants sont mis en œuvre dans le canton de Soleure
dans le cadre d’une architecture multicouche. PostgreSQL est utilisé dans la couche des
données pour pérenniser leur conservation. PostgreSQL se conforme aux standards
SQL92 et SQL99. L’extension PostGIS permet d’adjoindre les fonctions de la spécifica-
Interopérabilité pour l'utilisation généralisée de la Géoinformation 21.1

Particularités de l’interopérabilité dans la pratique
Géoréférencement, interopérabilité entre les données de la mensuration et les informations spatiales
superposées, hiérarchie des données et actualisation des données spatiales subordonnées
tion OGC « SQL for simple features » à PostgreSQL. De cette manière, une couche de
conservation de données pleinement compatible avec les SIG est à disposition, avec laquelle
la communication peut être établie via des interfaces standardisées, comme base
d’interopérabilité technique. Cet environnement constitue le fondement de la conservation
des données et du traitement de l’information normalisés. Il n’est par conséquent
pas indispensable que les couches d’application ou les applicatifs disposent de fonctions
SIG.
Les couches d’application et les applicatifs sont d’une grande diversité, afin de répondre
aux exigences qui leurs sont posées. Il est recouru à des systèmes propriétaires sur une
base client – serveur via ODBC, JDBC, GDAL/OGR ou des interfaces natives, de même
qu’à de véritables architectures multicouche, à base Internet en règle générale.
Ce choix est en principe indépendant des systèmes d’exploitation, des langages de programmation
et des environnements de développement utilisés, la communication entre
les différents composants se déroulant sur une base standardisée.
4 Exemple de profil du sol
L’exemple de la requête d’informations pour un profil du sol va nous permettre de présenter
la conception et l’environnement système tels qu’ils sont envisagés dans un cas
concret, celui du canton de Soleure.
4.1 Problème posé
Les informations relatives à un profil du sol doivent pouvoir être mémorisées et gérées
de façon normalisée et sans redondance. Un mode de conservation durable et normalisé
des données est mis en place à cette fin, intégré au sein d’une architecture multicouche.
La réunion des informations initiales s’effectue sur une base spatiale en recourant à
SQL92 et au standard OGC « SQL for simple features ». La couche d’application est
structurée à l’aide de technologies Internet dans ce cas. Des interfaces ouvertes et « interopérables
» sur le plan technique et organisationnel sont utilisées.
Le résultat d’une requête doit livrer le type de sol de même que le numéro d’inscription
actuel du bien-fonds au registre foncier, le nom local actuel et l’altitude actuelle du profil
du sol concerné.
4.2 Solution adoptée
Du point de vue du profil du sol, les informations initiales peuvent être la position du
profil dans l’espace en guise de base géométrique ainsi que le type du sol. Elles sont
mémorisées et gérées dans une base de données PostgreSQL/PostGIS. Aucune information
supplémentaire n’est requise par le profil du sol pour la résolution du problème
posé. Le numéro de parcelle actuel, le nom local actuel et l’altitude actuellement connue
sont dérivés en vue de résoudre le problème posé, du point de vue du profil du sol. Les
informations déduites proviennent toutes du fond de la mensuration officielle et sont
gérées dans la base de données PostgreSQL/PostGIS indépendamment des informations
relatives au sol. Les couches d’informations forment ainsi une hiérarchie « à plat »,
au sein de laquelle elles sont a priori dépourvues de relations entre elles, sauf via leur
position dans l’espace. Les relations établies ne résultent que du problème posé.
Si une requête est à présent formulée via « SQL for simple features » puis transmise à la
base de données, l’intersection demandée dans l’instruction (statement) SQL est effectuée
et le système peut fournir le résultat souhaité en guise de réponse. La requête SQL
21.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation

Particularités de l’interopérabilité dans la pratique
Géoréférencement, interopérabilité entre les données de la mensuration et les informations spatiales
superposées, hiérarchie des données et actualisation des données spatiales subordonnées
pour l’obtention du numéro d’inscription au registre foncier de la parcelle sur laquelle le
profil est foré se présente alors sous la forme suivante :
select profil_du_sol.type_de_sol, numero.parcelle
from profil_du_sol, parcelles
where distance(profil_du_sol.geometrie,parcelles.geometrie)=0;
En principe, cette requête peut être déposée par toute couche d’application ou tout applicatif.
L’interopérabilité est garantie par des interfaces ODBC, JDBC, GDAL/OGR ou
natives mais documentées de manière ouverte sur le plan technique.
Figure 1 : architecture du système pour l’exemple de profil du sol
Interopérabilité pour l'utilisation généralisée de la Géoinformation 21.3

Particularités de l’interopérabilité dans la pratique
Géoréférencement, interopérabilité entre les données de la mensuration et les informations spatiales
superposées, hiérarchie des données et actualisation des données spatiales subordonnées
Bilan
La stratégie présentée d’environnement système multicouche combinée à une communication
normalisée entre les composants est indépendante des systèmes d’exploitation
comme des langages de programmation, à la condition toutefois que les standards de
communication destinés à assurer l’interopérabilité soient respectés. Les améliorations
suivantes en résultent alors :
Moins de redondances
La stratégie poursuivie depuis plusieurs années à Soleure visant à la normalisation des
informations de base a conduit à une réduction considérable des redondances au niveau
de la conservation des bases, les informations dérivées étrangères aux objets n’étant plus
mémorisées conjointement avec les objets auxquels elles se rapportent.
Une gestion plus efficace des données
La gestion des données s’est simplifiée et a gagné en efficacité. La mise à jour des bases
s’effectue exclusivement sur les informations de base normalisées, au sein d’une hiérarchie
horizontale.
Des données à caractère obligatoire
Les informations de base normalisées sont gérées et actualisées séparément.
L’information souhaitée n’étant générée qu’au moment d’une requête, la qualité des résultats
des requêtes a pu être considérablement améliorée et la sûreté des décisions s’en
est trouvée accrue.
21.4 Interopérabilité pour l'utilisation généralisée de la Géoinformation

22
Le graphe de la mobilité
Un référentiel géographique pour les
partenaires du système d'information de la
mobilité de la région genevoise
Pascal Oehrli, SSIG Genève
Pascal Oehrli
SSIG - Service des Systèmes d'Information et de Géomatique
DIAE - Département de l'Intérieur, de l'Agriculture et de l'Environnement
7, rue des Gazomètres
Case Postale 36
CH-1211 Genève 8
Tél :
Fax :
E-mail :
+41 22 327 79 29
+41 22 327 50 70

Le système d’information de la mobilité de la région genevoise (SI Mobilité) est un système
d’information thématique né dans le cadre du Système d’Information du Territoire
Genevois (SITG). Le SI Mobilité est un partenariat entre les différentes institutions et acteurs
ayant trait aux déplacements et à ses infrastructures, ceci pour tous les moyens de
transport. Ses buts sont de rassembler, organiser, valoriser, coordonner et diffuser les
données et les produits relatifs à la mobilité à Genève.
L’analyse de la situation jusqu’alors a montré que les données produites ou gérées par
les différents partenaires étaient indépendantes les unes des autres, parfois redondantes
et globalement inutilisables directement dans une application ou un modèle. Malgré
l’existence d’un graphe routier au sein du SITG, d’autres graphes ont été développés par
les acteurs en fonction de leurs besoins métiers spécifiques. Il existait jusqu’à 5 ou 6 différentes
représentations de la géographie des routes.
Sur ce constat, une démarche a été lancée pour mettre au point un graphe routier commun
à tous les partenaires qui puisse intégrer au maximum les spécificités de chacun.
L’importance de pouvoir disposer d’un référentiel géographique unique et maintenu de
manière centralisée s’est rapidement imposée. Le graphe de la mobilité est donc né pour
répondre à ce besoin. Il intègre la géographie des différentes infrastructures servant aux
déplacements : les routes, les chemins et sentiers, le rail et les voies navigables ainsi que
les points de connexion : les carrefours, les quais de gare et les débarcadères. Un ensemble
de règles dites de connectique permet de lié de manière logique ces différents composants
du graphe de la mobilité.
Ce référentiel géographique, mis à disposition de tous les partenaires du SI Mobilité va
permettre de coordonner les différentes données produites et gérées par ceux-ci. Ces
données sont organisées dans un modèle de donnée intégrant les aspects liés à
l’infrastructure elle-même et aux aménagements mis en place, à la mobilité de manière
générale, aux diverses législations s’appliquant et les moyens de les matérialiser et aux
aspects environnementaux ou de sécurité. Ces multiples informations, de nature différente,
peuvent être coordonnées au travers du graphe de la mobilité par différents
moyens tels que la segmentation linéaire, la topologie de réseau ou par d’autres moyens
de relations géographiques ou non. De plus, le graphe de la mobilité constitue une base
pour l’analyse du réseau et la résolution d’itinéraires ou d’autres requêtes temporelles
ou géographiques sur un réseau de déplacement multimodal.
Interopérabilité pour l'utilisation généralisée de la Géoinformation 22.1

Particularités de l’interopérabilité dans la pratique
Le graphe de la mobilité : un référentiel géographique pour les partenaires du système d'information
de la mobilité de la région genevoise
Lignes TC
Graphe routier
Parkings
Arrêts TC
Carrefours
Graphe de la
mobilité douce
Graphe des accès
parkings
Connectique
Graphe de la mobilité
Graphe des voies
navigables
Débarcadères
Quais Gares
Aéroports
Graphe ferroviaire
Lignes aériennes
Gares
Le graphe de la mobilité est géré et mis à jour par le service en charge de la mensuration
officielle et mis à disposition librement de tous les partenaires du SITG.
En conclusion, on peut dire que l'existence d'un référentiel commun minimum constitue
une base essentielle à l'interopérabilité dans un système d’information, à l'exemple d'un
système de coordonnées... ou d'un graphe de référence commun pour les structures linéaires.
Le graphe de la mobilité commun genevois, tout comme la démarche qui a
permis d'aboutir au consensus de tous les acteurs concernés et les différents modèles
que l'on peut y rattacher par segmentation dynamique, semble constituer un bon exemple
d'élaboration d'un référentiel commun.
22.2 Interopérabilité pour l'utilisation généralisée de la Géoinformation