Les Fonctions de traduction

La fonction qui a donné son nom au composant de traduction est d’assurer la traduction des spécifications formelles (contraintes et règles opérationnelles) en paramètres spécifiques de chacun des processus de généralisation disponibles. Dans cette partie, nous effectuons d’abord un rappel sur les divers paramètres que l’on peut trouver dans des processus automatiques de généralisation, puis nous décrivons un modèle pour remplir sa fonction de traduction et enfin nous détaillons les difficultés que l’on peut rencontrer lors de cette opération.

Diversité des paramètres

Afin de bien mettre en valeur la diversité dans les paramètres rencontrés pour exécuter des processus automatiques de généralisation, nous présentons quatre processus implémentés sur notre plate forme de recherche pour être des processus disponibles du prototype de CollaGen que nous avons développé (voir CHAPITRE E). Le premier exemple provient de l’implémentation du modèle AGENT dans le logiciel Clarity™. Pour effectuer une généralisation à l’aide d’AGENT, il faut définir à la fois, le modèle de données qui associe les types d’agents avec les classes de données géographiques, et surtout l’entité regroupant les spécifications de la généralisation dite ‘AgentMapspec’. Cette entité liste pour chaque type d’agent les contraintes que l’on fait porter sur lui, avec une valeur d’importance et une valeur de priorité (i.e. urgence de traitement a priori). Elle regroupe également tous les paramètres utilisés par les contraintes. Par exemple, le paramètre « Building Minimum Size » est utilisé notamment par la contrainte dite « Building Size » qui contraint l’aire minimum d’un agent bâtiment. L’échelle finale de la carte doit également être saisie dans cette entité ‘AgentMapspec’. L’implémentation des Beams dans le logiciel Clarity™ nécessite un type de paramétrage assez différent. Il nécessite d’abord de définir un certain nombre de valeurs numériques propres au fonctionnement du processus comme le nombre maximum d’itérations ou le facteur de force de réaction, ou en rapport avec les spécifications de la carte comme le seuil de séparation entre les symboles. Il faut également définir le nom des classes d’objets concernés comme dans le cas précédent. Il faut enfin définir les propriétés de résistance à l’étirement et la compression pour chaque classe traitée. Nous pouvons ainsi définir sur les classes de cours d’eau et de routes mineures moins de résistance à la compression que sur les classes de routes importantes (les cours peuvent être plus tordus que les routes sans perdre leur sens géographique).

L’implémentation de la généralisation par Moindres Carrés que nous avons développée dans le cadre de CollaGen (voir E.1.2) repose sur des paramètres que nous avons encapsulés sous forme de contraintes. Il s’agit dans ce cas de définir un système d’équation sur-contraint (plus d’équations que d’inconnues) sur les coordonnées finales de chaque point des objets traités. Ainsi, une contrainte sur le maintien de la position initiale d’un bâtiment se traduit par deux équations pour chacun des points dans la géométrie du bâtiment : une équation ∆x = 0 et une équation ∆y = 0. Paramétrer le processus par moindres carrés revient donc à ajouter des équations dans le système global en fonction des spécifications qui s’appliquent sur chacun des objets. Un autre point clé de ce paramétrage, car difficile à optimiser (Harrie, 2003), est la construction d’une matrice de pondération des équations (les équations dont nous voulons qu’elles soient complètement satisfaites doivent avoir un poids élevé).

Enfin, nous avons développé un processus simple à base de séquences prédéfinies qui permet de généraliser une couche de végétation. Il contient quatre opérations dont un utilisateur peut modifier la séquence : une élimination des petites zones, une dilatation/agrégation, une simplification du contour et une simplification des trous dans les géométries des zones de végétation. Le paramétrage de ce processus consiste à choisir les opérations que l’utilisateur souhaite utiliser, dans quel ordre et avec quels paramètres numériques.

Modèle de fonction de traduction

La fonction de traduction doit être fournie par le fournisseur de processus de généralisation en même temps qu’il rend le processus qu’il a développé disponible dans CollaGen. Nous proposons donc de définir la signature de telles fonctions pour que le composant de traduction puisse les déclencher de manière générique, quel que soit le processus à paramétrer. Puis, nous détaillons un modèle pour remplir cette fonction, que nous illustrons par les exemples utilisés précédemment. La signature que nous définissons pour les fonctions de traduction est la suivante :

fonctionDeTraduction(echelleFinale : double,

contraintes : Collection<ContrainteFormelle>, regles : Collection<RegleOperationnelle>, annotation : AnnotationSémantique,

processus : ProcessusDeGeneralisation)

− L’échelle finale est tout d’abord un paramètre d’entrée indispensable pour beaucoup de processus comme AGENT car les transformations que l’on veut paramétrer dépendent de l’échelle de la carte.

− Une fonction de traduction utilise la formalisation des spécifications pour récupérer les valeurs des paramètres contenues dans les types d’expression du modèle formel. Cela correspond dans la signature aux deux collections de contraintes formelles et des règles opérationnelles.

− Une fonction de traduction nécessite de faire appel à l’annotation sémantique du schéma de données géographique initial car les spécifications formelles sont exprimées en termes de concepts ontologiques. Cette annotation sémantique est également gérée par le composant de traduction mais n’a pas besoin d’être réalisée au moment de la rédaction d’une fonction de traduction.

− Une fonction de traduction prend en entrée le processus de généralisation qu’elle va paramétrer (voir la modélisation des processus de généralisation en C.9.2).

Pour écrire le contenu de ces fonctions de traduction, le fournisseur de processus peut s’appuyer sur le modèle présenté ci-dessous, même si toutes les étapes décrites ne sont pas toujours nécessaires :

fonctionDeTraduction(…)

recupération des noms de classe utiles dans l’annotation Initialisation des paramètres de processus relatifs au schéma

Pour spec de processus.paramètres Faire

Initialisation concept ← concept lié à spec Initialisation caractère ← caractère lié à spec

Initialisation typeExpression ← type d’expression lié à spec Initialisation contrainte ← contraintes.select(concept,

caractère, typeExpression)

Si (contrainte existe)

Initialisation de spec à partir de contrainte Sinon

Initialisation règle ← règles.select(concept, caractère) Initialisation de spec à partir de règle

Fin si Fin pour

Initialisation des paramètres restant avec des valeurs par défaut

La première étape revient à récupérer par l’annotation sémantique les noms des classes d’objets relatives aux concepts utilisés par le processus à paramétrer. Par exemple, pour AGENT Urbain (processus AGENT spécialisé pour les paysages urbains), la fonction récupère les classes relatives aux concepts de bâtiment, route et îlot urbain ; pour le processus de généralisation de la végétation, elle récupère la ou les classes relatives au concept de végétation.

Puis, la fonction initialise l’ensemble des paramètres relatifs à ce schéma de données : par exemple dans AGENT Urbain, elle relie les classes de bâtiment obtenues précédemment aux « agents bâtiments » connus du processus AGENT Urbain.

Puis, pour chacun des paramètres pouvant correspondre à une des spécifications formelles, la fonction cherche s’il existe une contrainte ou une règle correspondant (à l’aide du concept et du caractère concerné) et elle initialise le paramètre à partir de la contrainte (ou règle) récupérée. Par exemple, pour le seuil de séparation entre symboles de routes des Beams, la fonction cherche dans sa collection de contraintes formelles s’il y a une contrainte de proximité entre routes qui porte sur le caractère de distance minimum entre les symboles. Si elle trouve une contrainte qui correspond, elle récupère la valeur de distance minimum et initialise avec le paramètre « seuil de séparation » des Beams. Pour AGENT, si la fonction trouve une contrainte sur les bâtiments et sur leur aire avec une expression de type seuil, elle ajoute dans l’entité ‘AgentMapSpec’ une contrainte de type « Building Size » sur les agents bâtiments et initialise le paramètre « Building Min Size » avec la valeur contenue dans la contrainte formelle. Dans le cas des moindres carrés, la fonction peut même initialiser la matrice de poids à partir de la valeur d’importance contenue dans les contraintes et les règles formelles. Il convient de noter que la recherche de la contrainte correspondant à un paramètre est effectuée en exploitant l’arborescence de réification de l’ontologie : dans l’ontologie, un bâtiment

« est un » petit compact donc la fonction commence par chercher les contraintes correspondantes sur les bâtiments et si elle n’en trouve pas, cherche s’il y en a sur les concepts de plus haut niveau comme petit compact puis au-dessus si nécessaire.

Enfin, dans un dernier temps, la fonction initialise avec des valeurs par défauts tous les paramètres qui n’ont pu être remplis à l’aide des spécifications comme le nombre d’itérations maximum pour les Beams. Ce dernier point permet de mettre en lumière une des difficultés possibles de la traduction, difficultés décrites dans la partie suivante.

Difficultés de traduction possibles

Même en suivant le modèle proposé, le fournisseur peut rencontrer des difficultés pour écrire le contenu de la fonction de traduction. Nous avons listé trois types de difficultés dans la traduction : des contraintes sans correspondance dans les paramètres, des paramètres sans équivalent dans les contraintes et des différences de conceptualisation des paramètres.

En réalisant des fonctions de traduction qui suivent le modèle proposé, toutes les contraintes ne seront pas prises en compte par le processus. D’une part, cela ne signifie pas que le processus ne tiendra pas compte du problème formalisé par cette contrainte, car il peut le faire sans avoir recours à un paramètre. Par exemple, l’algorithme de simplification du bâti intégré à AGENT (Ruas, 1999), prend en compte une contrainte de maintien de la forme en L de certains bâtiments sans que ce soit paramétrable. Pour prendre un autre exemple, les Beams tiennent compte de la contrainte qu’une route doit garder le plus possible sa position initiale sans que cela soit paramétrable. D’autre part, si nous avons recours à un système de généralisation collaborative, c’est bien parce que les processus disponibles ne sont pas capables de prendre en compte l’ensemble des spécifications d’une carte généralisée complète. La fonction de traduction se contente donc de traduire des spécifications pour les seuls paramètres attendus d’un processus.

Une deuxième difficulté réside dans le cas inverse, quand certains des paramètres ne correspondent à aucune contrainte ni règle. Cela peut être dû à des paramètres purement procéduraux et indépendants des spécifications de la carte comme le nombre d’itérations maximum des Beams. Cela peut être dû aussi à l’absence de spécifications concernant un concept et un caractère donné. La plupart des processus ne fonctionnent pas si l’on ne remplit pas l’ensemble des paramètres donc dans un cas comme dans l’autre, il faut trouver une solution pour remplir ces paramètres. Pour le cas des spécifications manquantes, la solution que nous proposons est de fournir dans la fonction de traduction des paramètres par défaut en fonction de l’échelle finale : si aucune contrainte ni règle n’a été trouvée pour remplir un paramètre dans la collection des contraintes formelles passée en entrée, la fonction de traduction est conclue par l’initialisation du paramètre avec la valeur par défaut (cette valeur par défaut est trouvée par expérimentations du fournisseur sur le processus qu’il rend disponible). Une autre possibilité est de chercher une contrainte proche (la même sur un autre concept par exemple) et d’appliquer la même valeur de paramètre. Pour le cas des paramètres procéduraux, la seule solution est de les initialiser avec des valeurs par défaut. Si le choix de ces paramètres peut conduire à des fortes variations de résultats, le fournisseur de processus peut fournir plusieurs fonctions de traduction qui pourront être essayées dans le système d’essai/erreur de CollaGen comme deux processus concurrents pour être les plus adaptés : CollaGen essaie le

processus paramétré par la première fonction de traduction, et si le résultat est évalué comme mauvais, revient en arrière et essaie avec l’autre fonction de traduction.

Enfin, la dernière difficulté peut être engendrée par des différences de conceptualisation du problème entre la contrainte formelle et le paramètre du processus. Par exemple, le processus de généralisation de la végétation possède un seuil de simplification qui correspond à l’algorithme de Whirlpool (Dougenik, 1980), c’est-à-dire un seuil de proximité pour former des amas de points consécutifs du polygone qui vont être remplacés par leur centre de gravité (Figure C-58). La contrainte pouvant servir à déterminer ce paramètre est la contrainte de granularité des zones arborées qui porte sur le caractère « longueur minimum d’un côté du polygone » (Figure C-58). Il n’y a pas de relation directe entre les deux seuils mais ils sont corrélés : si on se base sur l’un, on peut résoudre l’autre à peu près. Nous proposons dans ces cas au fournisseur de faire une adaptation de la valeur contenue dans la contrainte pour son paramètre. Dans notre exemple, si nous prenons un seuil de Whirlpool valant deux fois le seuil de la contrainte de granularité, nous maximisons nos chances que notre contrainte soit satisfaite après la généralisation.

Figure C-58. Différence de conceptualisation de la granularité entre une contrainte (longueur minimum pour un

côté du polygone) et un paramètre du processus de généralisation de la végétation (seuil de proximité entre points pour former des amas). A droite la version généralisée avec la conceptualisation de l’algorithme.