Retrouvez cet article dans : Linux Magazine 91

Les mondes de l’information géographique et du Logiciel libre font plutôt bon ménage ces derniers temps. Aux côtés des bases de données ouvertes à cette information particulière (comme le couple postgresql, postgis), fleurissent des SIG (Système d’Information Géographique comme grass ou qgis) et des serveurs d’application géographique (mapserver ou geoserver). L’administration fiscale, chargée de la gestion du plan cadastral français a d’ailleurs choisi des outils libres pour implémenter son futur serveur de plan.
Toutefois, le téléchargement des informations cadastrales fournira des fichiers au format d’échange EDIGÉO. EDIGÉO est une norme française pour l’échange de données géographiques (norme AFNOR NF52000 homologuée le 5 juillet 1999). Là, force est de constater que les outils libres permettant de récupérer ce format manquent. En effet, EDIGÉO est textuel, destiné à échanger de l’information et n’est pas d’une gestion pratique.
Votre serviteur a donc ouvert un projet relatif à cette norme afin de pallier ce manque. Un premier module, permettant de charger un échange EDIGÉO dans une base de données postgresql est très proche d’une version exploitable et permet déjà cette intégration.
Dans cette série d’articles, nous allons successivement survoler la norme EDIGÉO, puis balayer les outils réalisés et prévus dans le projet edigeo hébergé sur le serveur de développement collaboratif gna. Actuellement, 2 outils d’initialisation et de lecture existent, mais doivent être testés de manière approfondie (au moment où j’écris ces lignes).

La norme EDIGÉO : une structure en poupées russes

La norme EDIGÉO est un document de 318 pages. Nous ne ferons donc que survoler les concepts sans les détailler. Lorsque c’est possible, nous renverrons vers quelques références glanées sur internet.
Commençons par aborder EDIGÉO selon 2 angles de vues. Pratiquement tout d’abord en regardant un fichier; théoriquement ensuite en visitant les concepts.

1. Les fichiers EDIGÉO

Voici un exemple de fichier EDIGÉO :

BOMT 12:EDIGZASE.GEN – entête de métafichier; ligne #1
CSET 03:IRV – entête de métafichier; ligne #2
RTYSA03:DEG – descripteur d’étendue géographique
RIDSA14:EMPRISE_EDIGZA – identifiant du descripteur d’étendue géographique
CM1CC22:+543674.75;+227667.90; – emprise : coordonnées minimales
CM2CC22:+545774.75;+229167.90; – emprise : coordonnées maximales
RTYSA03:GSE – descripteur de sous ensemble
RIDSA07:SeTOP_1 – identifiant du descripteur de sous ensemble
INFST00: – information sur le sous ensemble
STRSN01:1 – structure du sous ensemble; 1:topologique
REGSA00: – identifiant d’un éventuel calage
RTYSA03:GSE – descripteur de sous ensemble
RIDSA07:SeTOP_2 – identifiant du descripteur de sous ensemble
INFST00: – information sur le sous ensemble
STRSN01:1 – structure du sous ensemble; 1:topologique
REGSA00: – identifiant d’un éventuel calage
RTYSA03:GSE – descripteur de sous ensemble
RIDSA07:SeTOP_3 – identifiant du descripteur de sous ensemble
INFST00: – information sur le sous ensemble
STRSN01:1 – structure du sous ensemble; 1:topologique
REGSA00: – identifiant d’un éventuel calage
RTYSA03:GSE – descripteur de sous ensemble
RIDSA07:SeSPA_1 – identifiant du descripteur de sous ensemble
INFST00: – information sur le sous ensemble
STRSN01:3 – structure du sous ensemble; 3:spaghetti
REGSA00: – identifiant d’un éventuel calage
EOMT 00: -- fin de métafichier

A première vue, un échange EDIGÉO est composé d’un nombre variable de fichiers nommés métafichiers par la norme.
Chaque métafichier contient des descripteurs. Nous pouvons comparer un descripteur à une ligne d’une table dans une base de données. De la même manière qu’il existe plusieurs tables dans une base de données, les différents métafichiers définiront différents descripteurs. Notre exemple contient un descripteur d’étendue géographique (emprise) et 4 descripteurs de sous-ensembles géographiques.
Chaque descripteur est lui-même subdivisé en champs. Nous pouvons prolonger l’analogie précédente en comparant le champ d’un descripteur à une colonne dans notre base de données. La fin d’un descripteur est implicitement déterminée par le début d’un autre descripteur (champ RTY) ou une fin de métafichier (champ EOM).
L’ensemble des descripteurs sont encadrés par un en-tête et une fin de métafichier. L’en-tête est composé de 2 champs. Un champ BOM (Begin Of Metafile) et un champ CSE (Character SEt). La fin est composée du champ EOM (End Of Metafile).
Attardons-nous sur un champ edigeo :

 RTYSA03:GTL

Ce champ a pour nom " RTY ". Un champ RTY est toujours le premier champ d’un descripteur. Sa valeur (ici GTL) précise le type du descripteur. Le type GTL caractérise un descripteur de lot (nous préciserons bientôt ce qu’est un lot dans un échange EDIGÉO).
Un champ est toujours composé de 6 parties. Voici les 6 parties de notre exemple :

 La valeur d’un champ de format T peut intégrer des sauts de ligne (0x0a). C’est intéressant pour préciser une adresse ou toute autre information de plusieurs lignes.
La limite de 72 caractères peut être brisée en ajoutant un ou plusieurs champ NEX immédiatement derrière le champ à prolonger.
Le passage d’un champ à un autre sera déterminé par la première majuscule qui suit. Tout autre caractère est ignoré et peut être considéré comme commentaire. Tous les champs de notre exemple précédent de métafichier sont commentés.
Le projet edigeo hébergé par gna [Lien 1] [Lien 2] contient la description de la structure des métafichiers, des descripteurs et leurs champs dans différents scripts SQL [Lien 3].

2. La structure EDIGÉO

L’organisation des informations

Commençons par regarder la structure, nous verrons ensuite le contenu des différents sous-ensembles constitutifs.

Figure 1 : Structure d’un échange EDIGÉO

Un échange EDIGÉO est composé (figure 1) :

• d’un lot de données générales de transmission (métafichier suffixé .THF) ;
• de lots géographiques.

La composition, le nombre de lots et les noms des métafichiers de chacun des lots sont déduits du métafichier THF de données générales de la transmission.
Un lot est lui-même composé de 2 ensembles :

• un ensemble de données de description ;
• un ensemble de données géographiques vectorielles ou matricielles (raster).

L’ensemble de données générales comprend :

• un sous-ensemble de données générales (métafichier suffixé .GEN) ;
• un sous-ensemble de la référence de coordonnées (métafichier suffixé .GEO) ;
• un sous-ensemble de description de la qualité des données (métafichier suffixé .QAL) ;
• un sous-ensemble de définition de la nomenclature (métafichier suffixé .DIC) ;
• un sous-ensemble de définition du schéma conceptuel des données (métafichier suffixé .SCD).

L’ensemble des données géographiques contient les objets géographiques eux-mêmes. Ces objets peuvent être :

• dans un sous-ensemble de données géographiques vectorielles (métafichier suffixé .VEC) ;
• dans un sous-ensemble de données géographiques matricielles (métafichier suffixé .MAT).

Les données cadastrales sont par exemples constituées de 4 sous-ensembles de données géographiques vectorielles :

• les sections cadastrales, données vectorielles topologiques (sans trous, ni recouvrements) ;
• les feuilles cadastrales, données vectorielles topologiques ;
• les parcelles, données vectorielles topologiques ;
• les autres objets cadastraux, données vectorielles spaghetti (sans contrainte de trou ou chevauchement).

3. Les sous-ensembles

Le sous-ensemble des données générales de transmission (.THF)
Les données générales de transmission définissent la structure générale de l’échange.
Celle-ci comprend donc un descripteur de support précisant notamment auteur et destinataire de l’échange et surtout le nombre de lots de cet échange.
Le support est suivi de n descripteurs de lots desquels sont déduits les noms des métafichiers de l’ensemble de données générales et la composition des sous-ensembles de données géographiques.
Pour connaître le nom du fichier d’un sous-ensemble, le principe est le suivant :
1. Repérer le lot qui nous intéresse dans le métafichier THF. Voici par exemple le début d’un descripteur de lot :

RTYSA03:GTL
RIDSA06:EDIGZA
LONSA06:EDIGZA
INFST00:
GNNSA02:SE
GNISA04:SeGN
GONSA02:SE
GOISA04:SeGO

Dans ce lot, nous allons rechercher le sous-ensemble de la référence de coordonnées.
2. Recherchons d’abord le nom du lot. Celui-ci est défini dans le champ LON comme son nom ne l’indique pas vraiment (peut-être l’expression anglo-française " LOt Name " ...). Le nom du lot est constitué des 6 caractères EDIGZA. Cette information constituera le préfixe du nom du fichier recherché.
3. Recherchons ensuite le nom du sous-ensemble de la référence de coordonnées. Vous trouverez cette information dans le champ GON, soit SE.
4. Enfin, nous savons tous que l’extension du fichier recherché est GEO. En concaténant ces différentes parties, nous déduisons que la référence de coordonnées se trouve dans le fichier EDIGZASE.GEO.
Le sous-ensemble des données générales (.GEN)
Le sous-ensemble de données générales précise l’emprise géographique des données du lot et détaille ensuite les sous-ensembles de données géographiques en y ajoutant leur structure (spaghetti, réseau, topologique ou matricielle). Nous n’entrerons pas plus dans le détail de ces structures. L’exemple de métafichier EDIGÉO vu précédemment était un sous-ensemble de données générales, constitué d’un descripteur d’étendue géographique et 4 descripteurs de sous-ensemble.
Le sous-ensemble de la référence de coordonnées (.GEO)
Le sous-ensemble de la référence de coordonnées indique dans quel système cartographique sont exprimées les coordonnées des données géographiques.
Les 4 principaux types de référentiels cartographiques sont les suivants :

• Les référentiels géodésiques (figure 2) avec origine au centre du globe terrestre. La précision des techniques de positionnement du centre de la terre s’améliorant au fil des années, il existe plusieurs référentiels avec différentes origines et orientations. De plus, les besoins cartographiques locaux conduisent à définir des référentiels mieux adaptés à ces besoins.
• Les référentiels géographiques (figure 2) – deuxième type de référentiel – s’appuient sur le précédent. Notre planète est un " patatoïde " (géoïde dans le jargon cartographique). Une modélisation mathématique de notre globe vers un ellipsoïde, volume proche du géoïde constitue le support du référentiel géographique. Les coordonnées sont alors constituées de 2 angles : latitude et longitude. Il est nécessaire de définir un méridien particulier pour l’origine des longitudes (Greenwich, Paris...).
• Les référentiels en projection (figure 2) s’appuient sur un ellipsoïde donné. Dans les usages courants, il n’est pas commode de devoir représenter une carte sur un ellipsoïde. Nous utilisons tous des cartes papier, représentations planes d’un ellipsoïde. Ces référentiels consistent donc à définir une transformation mathématique permettant d’exprimer les coordonnées planes en fonction des longitude et latitude.
• Les 2 derniers référentiels ne permettent pas de définir d’altitude. On peut donc leur adjoindre un système altimétrique.

Le CNIG (Conseil National de l’Information Géographique), organisme public, référence les systèmes cartographiques utilisables avec la norme EDIGÉO. Cette liste est disponible sur le serveur du CNIG. [Lien 4]
Ce même sous-ensemble définit d’éventuel descripteur de calage. Les coordonnées peuvent alors être exprimées dans un système de coordonnées local. Le descripteur de calage fournit les informations permettant la transformation du système local au système cartographique. Ceci est particulièrement utile aux informations matricielles.

Figure 2 : Référentiels cartographiques

Le sous-ensemble de description de la qualité (.QAL)
Le sous-ensemble de description de la qualité des données permet d’apporter des précisions qualitatives sur les données. Ce sous-ensemble en référence 9 types différents. Citons par exemple des informations relatives à la précision des données. D’autres relatives à la généalogie ou à l’actualité. Le lecteur souhaitant approfondir se reportera :

• au Bulletin d’Information de L’IGN n° 67 de Benoît David & Pascal Fasquel : " Qualité d’une base de données géographique : concepts et terminologie "
• à la thèse d’Atef Bel-Hadl-Ali relative à la qualité des données [Lien 5].

Le sous-ensemble de définition de la nomenclature (.DIC)
Le sous-ensemble de définition de la nomenclature est un dictionnaire de données appelé " nomenclature d’échange ". La norme prévoit 3 types de nomenclatures :

• Une nomenclature générale commune à tous et gérée par le CNIG.
• Une nomenclature sectorielle, résultat de l’accord entre les collectivités ou personnes qui s’échangent des données géographiques. Cette nomenclature doit respecter la codification de la norme.
• Une combinaison des 2 types de nomenclatures.

La nomenclature générale est gérée par le CNIG et est évolutive. La version actuelle est disponible sur le serveur du CNIG [Lien 6].
Le projet EDIGÉO inclut les référentiels et la nomenclature dans des tables SQL.
Le code d’un objet dans la nomenclature possède 4 composantes séparées par le caractère " _ ". Ces 4 composantes sont :

• Le domaine (1 lettre majuscule). Le code du domaine lui-même a ses autres composantes à " 0 ". Par exemple, le code du domaine " SURFACE D’ACTIVITE ET BATI " est " E_0_0_0 ".
• La classe (1 ou 2 chiffres). Le code de la classe elle-même a ses composantes suivantes à " 0 ". Par exemple, le code de la classe " ZONE D’ACTIVITES SPORTIVES " est " E_4_0_0 ".
• L’objet générique (1 à 3 chiffres). Le code de l’objet générique lui-même a sa dernière composante à " 0 ". Par exemple, l’objet générique " STADE " est " E_4_1_0 ".
• L’objet (1 à 4 chiffres). Par exemple, le code de l’objet " PISTE D’ATHLETISME " est " E_4_1_1 ".

Le sous-ensemble de définition du schéma conceptuel des données (.SCD)
Le sous-ensemble de définition du schéma conceptuel des données est le modèle des données de l’échange.
C’est, en quelque sorte, l’équivalent d’un fichier XML schéma.
Lors du processus d’échange de données, l’émetteur devra extraire et convertir tout ou partie des données intéressant le destinataire. Émetteur et destinataire disposent de leur propre modèle de données. Si nous notons MCDe et MCDr les modèles de données respectifs de l’émetteur et du récepteur, le SCD EDIGÉO sera probablement un sous-ensemble de l’intersection de ces 2 modèles.

Figure 3 : Modèles de données en jeu

Le plus souvent, SCD résultera d’une convention entre l’émetteur et le récepteur. S’agissant de données gérées par un service public comme le cadastre, il s’agit plutôt de fournir les données publiques. A charge ensuite pour le récepteur de récupérer ce qui l’intéresse.

Figure 4 : Modèle général d’un SCD EDIGÉO

Par ailleurs, le modèle de données transmis devra obligatoirement se conformer au modèle général défini (figure 4) par la norme. Ce modèle dissocie géométrie et objets géographiques.

Les sous-ensembles des données vectorielles (.VEC)
L’ensemble des objets géographiques est partitionné en objets géographiques ponctuels, linéaires, surfaciques ou complexes. Sur le schéma, ce partitionnement est symbolisé par une relation d’héritage avec totalité et exclusion (XT selon la notation Merise).

La géométrie des objets simples est déterminée par les relations de constructions les liant aux primitives géométriques. Les objets ponctuels, linéaires et surfaciques sont respectivement liés à des nœuds, arcs et faces. La géométrie des objets complexes se déduit de celle des objets auxquels ils sont liés.
Exemple : L’objet géographique pays est un objet simple surfacique lié à plusieurs faces (le territoire principal et les différentes îles).
La géométrie est entièrement supportée par les primitives nœud et arc. Les faces sont déduites des relations " est à gauche de " et " est à droite de " les liant aux arcs des contours. Un arc peut être une ligne brisée, un arc de cercle ou une courbe. L’échange de courbes doit s’accompagner de conventions entre émetteur et récepteur. Le modèle de données de l’échange devra alors définir des attributs de l’arc précisant le type et les paramètres de la courbe, voire son équation si l’on dispose d’un module de calcul formel. L’usage est plutôt de convertir les courbes en une ligne brisée proche. Les calculs géométriques en sont grandement facilités sans que cela nuise à la qualité topographique.
Le schéma du modèle général laisse en suspend les cardinalités des relations entre primitives géométriques. Ces cardinalités sont en effet différentes selon le modèle utilisé (spaghetti, réseau ou topologique).
Considérons par exemple, les relations " est à gauche de " et " est à droite de " d’un modèle topologique. La décomposition de la géométrie des objets géographiques devra assurer que chaque arc n’a qu’une et une seule face à sa gauche, une et une seule face à sa droite. Ces conditions sont nécessaires, mais pas suffisantes à la topologie.
Des objets géométriques en couronne (avec un ou plusieurs trous) ou en archipel (constitués de plusieurs faces) sont parfaitement décrits dans cette modélisation.

Figure 5 : Objet à trou

Considérons par exemple une parcelle avec un trou (figure 5). La parcelle – objet simple surfacique – sera donc liée à une face. Cette face sera elle-même liée avec les arcs formant les contours intérieur et extérieur.

Conclusion

La norme EDIGÉO, en intégrant notamment le modèle des données de l’échange, permet d’automatiser de nombreux traitements, d’opérer un certain nombre de vérifications. Ses modèles géométriques, dissociant les objets de leur géométrie, permettent d’éviter des redondances.
Nous verrons donc, dans un prochain article, différents objectifs du projet edigeo. EDIGÉO étant destiné à l’échange de données, cela implique différents traitements pour intégrer un échange dans notre SIG. Ces traitements consistent principalement à placer les données dans une base transitoire, réaliser différents contrôles et exporter ensuite vers le SIG cible.
Les contrôles pourront permettre à tout producteur de données EDIGÉO de vérifier ses échanges avant transmission.
En recherchant EDIGÉO dans Google, on retrouve plusieurs contributions dans des forums montrant le manque d’outils, la méconnaissance de la norme. L’un de mes souhaits serait de fédérer les énergies autour du projet pour démocratiser cette norme malheureusement trop peu connue.

Liens

• 1. Site de développement collaboratif gna : https://gna.org
• 2. Projet EDIGÉO : https://gna.org/projects/edigeo
• 3. Scripts SQL du CVS : http://cvs.gna.org/cvsweb/edigeo/metaedigeo/sql/?cvsroot=edigeo
• 4. Systèmes cartographiques du CNIG : http://www.cnig.gouv.fr/upload/ressource/r1091104706.PDF
• 5. Qualité des données géographiques : http://www.univ‑mlv.fr/recherche/WebTheses/UMLV‑2004‑000157.pdf
• 6. Nomenclature générale du CNIG : http://www.cnig.gouv.fr/upload/ressource/r1091105628.ZIP

 Retrouvez cet article dans : Linux Magazine 91