DES DONNEES ORGANISEES EN MODELE UTILISATEUR

A quoi sert la modélisation ? Cette question, souvent posée par les étudiants débutant dans le domaine des SIG, correspond à un problème très actuel. " Modéliser ", c’est prendre une partie du monde (plutôt petite), la ranger, l’ordonner et la schématiser pour aboutir à une représentation conventionnelle appelée SCD (modèle de données ou Schéma Conceptuel de Données).

Les concepts utilisés

- le " monde réel " est constitué d’"objets" qui ont des "propriétés", nommées ici "attributs",

- les objets qui peuvent être définis par une même liste d’attributs sont regroupés en ensembles généralement appelés "classes" ,

- des classes d’objets peuvent elles-mêmes être composées à partir de classes d’objets (l’ensemble des hommes et l’ensemble des femmes composent l’ensemble des humains),

- les objets peuvent être unis par des "relations" ou "liens" (un transformateur alimente des habitations en électricité).

Le schéma de données ne doit pas montrer le monde dans son intégralité, mais une partie, soigneusement délimitée en fonction d’un contexte bien défini et de besoins bien identifiés.

" Modéliser " des données, c’est donc réaliser un schéma. L’implémentation sous un SIG de ce schéma permet la manipulation aisée des données car celles-ci seront alors proposées aux fonctions de ce type de logiciel comme celles-ci les attendent.

Par ailleurs, structurer des données permet d’éviter des redondances non désirées, d’assurer leur sécurité et leur extensibilité (ajout de classes utilisateurs, d’attributs) et permet d’améliorer les performances du logiciel.

Les SIG et les données numériques

Les fonctionnalités des SIG sont globalement celles de SGBD auxquelles sont associées des fonctions d’affichage de cartes, d’analyse spatiale et de traitement thématique.

L’analyse spatiale est parfois considérée dans un sens qui peut être vu comme restrictif, des " opérations qui tirent parti de la répartition spatiale, telles que connexion, voisinage, fermeture... ".

Nous considérerons ici plus généralement que toutes les opérations sur la géométrie et la topologie sont du ressort de l’analyse spatiale (requêtes sur les surfaces, les longueurs, calculs de pourcentages d’occupation du sol...)

Ces fonctions, pour être opérationnelles, ont besoin de données organisées de façon adéquate, c’est-à-dire sous une forme correspondant aux concepts précités : classes, objets, attributs, liens .

Les trois aspects essentiels, qui traduisent une mauvaise organisation ou une organisation inadaptée au logiciel de l’utilisateur sont les suivants :

les données sont " éclatées " (ou pas assez regroupées)

Par exemple, des données telles que " broussailles ", " vignes ", " vergers ", " prairies ", " bois ", " forêts ", " plantations " ne sont guère exploitables par un SIG si chacune de ces entités est implémentée dans le SIG comme une classe d’objets.

Il n’est pas possible, en effet, d’effectuer des requêtes fructueuses sur des données en vrac, constituées d’informations éparpillées. Il est courant de se trouver en face de structures constituées d’informations élémentaires qualifiées d’objets et qui ne possèdent pas d’attributs.

Certains utilisateurs novices se sont retrouvés très dépités après avoir réalisé un import de fichier via une l’interface standard DXF de logiciels très répandus. Les couches DXF dépourvues de valeurs d’attributs générant des tables attributaires...vides !

Une règle très simple aidant au regroupement des informations en classes d’objets significatives dit qu’" un objet sans attribut n’est qu’un attribut d’objet ".

Un regroupement en une classe générique telle que " zones d’occupation du sol " possédant un attribut " nature " contenant les informations précitées (bois, broussailles, vignes...) est nécessaire.

Cette restructuration permet alors, par exemple, de réaliser une analyse thématique donnant les pourcentages de surfaces boisées, de prairies, de bois, ...

Le modèle fourni peut correspondre à une organisation qui a été jugée pratique pour la saisie (un modèle satisfaisant pour la saisie pouvant être une structure " éparpillée "). Le modèle utilisateur devra, par contre, être le plus synthétique possible (peu de classes d’objets, beaucoup d’attributs associés aux objets).

Il peut s’avérer qu’un modèle semble trop synthétique à un utilisateur : dans le cas par exemple où tout le réseau routier est regroupé dans une seule classe " routes " et où l’utilisateur est gestionnaire du réseau vicinal. Celui-ci ne s’intéresse alors réellement qu’à un sous-ensemble de cette classe.

Dans la pratique, cet inconvénient est mineur, car les SIG permettent tous de réaliser la requête simple qui générera le sous-ensemble plus adapté au besoin de cet utilisateur. La démarche inverse, consistant à regrouper des informations, s’avère par contre plus difficile pour l’utilisateur non spécialiste. Pour réaliser cette opération de regroupement, Il est en effet nécessaire de créer des attributs, de les initialiser, d’ajouter des tables (sur un système relationnel), de mettre éventuellement à jour des identifiants.

les données sont organisées en " modèle complexe "

Un autre cas, plus connu, est celui du modèle de données proposé par le fournisseur de BD localisées qui, bien qu’étant un modèle conceptuel correct se révèle non implémentable sur le logiciel du client qui ne possède pas une structure interne suffisamment évoluée. C’est ce qui se passe avec beaucoup de structures " complexes " (un objet complexe est composé d’objets simples, des relations peuvent exister entre les objets) qui ne peuvent pas être correctement traduites sur de nombreux SIG du commerce.

Actuellement, les fournisseurs de données localisées se préoccupent de ce problème et développent des structures " simples " ou " descendues " compatibles avec les logiciels ne permettant pas une implémentation " complexe ".

Il ne faudrait cependant pas que cette démarche, pragmatique mais provisoire, fasse renoncer aux seules structures réellement cohérentes que sont les structures complexes. En effet, une structure " descendue " pose des problèmes de redondances d’informations et d’implémentation de relations. Par exemple, le code N7 de la route nationale 7 sera répété autant de fois qu’il existe de tronçons élémentaires composant cette route.

Il est aussi très difficile d’exprimer avec une structure simple la relation suivante : une route, un sentier de grande randonnées et une piste cyclable passent par un tronçon élémentaire commun

Cette relation est de cardinalité n->m, c’est-à-dire qu’un objet (GR, par exemple), est composé de m tronçons et que une n objets (route, piste cyclable, GR) partagent un tronçon.

Les conséquences de ce problème sont alors les suivantes :

- perte d’informations,
- traduction de l’information sous une forme difficilement exploitable par le SIG.

les données sont mal regroupées

Une classe d’objets regroupant, par exemple, des séparateurs d’autoroutes avec des ponts et des escaliers plongera l’utilisateur gestionnaire d’autoroute dans la perplexité s’il désire prendre en compte le type de ceux-ci (végétal, en béton, métalliques...) ; l’attribut se retrouvant alors aussi associé aux ponts et aux escaliers.

Dans le même ordre d’idées, le nombre de marches d’un escalier pourrait ici se trouver associé aux séparateurs d’autoroutes et aux ponts où le gabarit maximum d’un camion aux séparateurs et aux escaliers.

Un autre exemple lié à une démarche pragmatique a les mêmes conséquences ; le producteur de données est aussi un utilisateur d’une partie de celles-ci. Il ne structure que les données nécessaires à ces propres applications ; les autres sont empilées en vrac dans des classes de " ponctuels " de " linéaires " et de " surfaciques ". On trouve alors en vrac, des limites d’états, des talus, des bords de chaussées...

L’information géographique doit constituer la " colonne vertébrale " du modèle utilisateur. Si des informations ont été regroupées sans réelle cohérence, l’utilisateur, nous l’avons vu, sera gêné quand il voudra associer ses propres informations à celles contenues dans la BD localisée.

Il est donc souhaitable que les fournisseurs de données localisées conçoivent des modèles de données qui puisse être

exploités directement par l’utilisateur ou qu’ils informent celui-ci de l’intérêt d’une réorganisation des données (si possible en lui donnant quelques conseils).

Comment transmettre une information géographique structurée ?

Le format adéquat pour supporter des informations géographiques est un format capable de véhiculer leur géométrie, les informations textuelles associées, les relations existantes entre ces informations et des informations sur ces informations (qualités, précision, date...).

Le format EDIGéO est un exemple de ce type de formats. Il présente un avantage indiscutable si la structure transmise est adaptée au logiciel récepteur et si cette structure est une bonne base de modèle utilisateur. Dans le cas contraire, un effet pervers peut être induit par son utilisation s’il véhicule une structure médiocre ou inadaptée. En effet, l’utilisateur, naturellement, voudra utiliser telle qu’elle la structure fournie.

Un autre format très répandu est le format DXF " standard " constitué de couches d’informations ne possédant pas d’informations attributaires associées. Il ne permet pas de transmettre une structure. . Il est toutefois possible de transmettre des attributs dans des " blocs " ou dans des AEE (Autocad Extended Entity) mais peu d’interfaces savent utiliser ces outils spécifiques.

L’information devra donc être organisée en modèle utilisateur par une interface spécifique ou nécessitera un long et fastidieux travail d’organisation sous le SIG. L’interface des logiciels développés dans le cadre de l’opération SAPHIR, qui utilise le format DXF véhiculant la BDTopo de l’IGN, réalise cette opération. Là encore, l’existence dans la plupart des SIG d’une interface standard peut amener l’utilisateur peu informé à sous utiliser la base de données localisées acquise.

Conclusion

Les données localisées souffrent encore d’une structuration souvent mal adaptée au besoin de l’utilisateur, car trop complexe, trop éparpillée ou encore mal regroupée, ainsi que d'un manque d'accompagnement pour au moins rassembler les définitions précises et exactes des objets traités.

Cette inadaptation peut limiter l’utilisation de ces données à la seule exploitation en " fond de plan". Leur inorganisation les rendant impropres à une utilisation " intelligente " (analyse spatiale, statistiques...). Le rapport coût des données / services rendus est alors très défavorable ; la prestation se rapprochant de celle fournie par une simple image " raster ".

L’utilisateur doit donc faire preuve de vigilance lors de l’acquisition d’une base de données. Ses objectifs devront être bien définis pour qu’une éventuelle restructuration soit réalisée en un modèle où les données géographiques seront le véritable support de son système.

Fiche élaborée par le groupe de travail "aide à la maîtrise d'ouvrage des SIG", avril 1998