1 de 5
DESCRIPTION DU PROJET DE RECHERCHE Durant une quinzaine d années, notre firme a développé une expertise en géomatique et en foresterie à travers ses travaux menés dans le cadre de projets de numérisation et structuration des cartes écoforestières. Forts de ces expertises, nous avons répondu à un appel d offres du Centre d information topographique de Sherbrooke (CITS), pour lequel cinq autres firmes seulement étaient accréditées au Canada. Le CITS désirait mettre à jour et corriger sa base de cartes numériques à l échelle 1/250 000 construites à partir de cartes non structurées au 1/50 000, elles-mêmes produites par la numérisation de cartes traditionnelles élaborées dans les années soixante. Pour cela, le CITS désirait identifier, par un projet ponctuel portant sur une carte seulement et dans un laps de temps limité (moins d un an), les compagnies capables de mener à bien le projet plus vaste. Le CITS possède à cet effet une procédure d évaluation rigoureuse, à travers son système de normes très élaboré. La réussite de ce projet nous aurait permis d obtenir une accréditation de la Base Nationale de Données Topographiques (BNDT). Pour nous, ce projet se démarquait des projets antérieurs menés dans le cadre provincial pour lesquels nous possédions et maîtrisions l outil informatique approprié ArcInfo. Or, le langage et la structuration de l'information d ArcInfo ne permettaient pas, a priori, de traiter les données fournies par le CITS, écrites en CCOGIF, le langage de transfert développé par Géomatique Canada (GC). Comme nous ne pouvions et ne voulions mener ce projet que dans le cadre des possibilités offertes par ArcInfo, il s agissait pour nous d une contrainte majeure, au point que le CITS doutait de la possibilité d y parvenir. Dans ce contexte, le développement d un procédé automatique (une somme et une séquence de programmes informatiques) de correction et de mise à jour des cartes topographiques demandait que l on soit capable de traduire et de structurer l information (cartes et fichiers de référence des toponymes et des réseaux routiers, hydrographiques et autres) donnée en CCOGIF. C est le développement de ce procédé qui constitue le présent projet de RS&DE. OBJECTIFS TECHNOLOGIQUES L objectif technologique principal de notre projet est de développer, avec l outil ArcInfo, un procédé automatique de correction et de mise à jour des cartes topographiques écrites en CCOGIF. Plus spécifiquement, les objectifs technologiques quantifiables et vérifiables sont les suivants : Automatisation : Par procédé automatique, nous entendons qu il s agit essentiellement d applications informatiques (programmes). Toutefois, il semble impossible de tout puisse se faire par ordinateur et notre objectif est de réduire le plus possible l intervention manuelle. 1 de 5
Précision : La mise à jour et la correction des cartes comporte obligatoirement des risques d erreurs. Notre objectif est donc de réduire le nombre de ces erreurs au strict minimum. Le nombre d erreurs sera d ailleurs le critère fondamental selon lequel on évaluera le progrès de notre projet. De plus, la précision des cartes doit être de l ordre du mètre (1 m). Normes : Les cartes produites par ce procédé doivent répondre aux normes suivantes : Spécifications techniques d acquisition BNDT-VMAP ; Règles générales de numérisation du CITS ; Spécifications d acquisition de la toponymie. Flexibilité : Programmation simple pour s adapter facilement à un changement de normes. Simplicité : Le procédé doit être utilisable par un opérateur non initié. Rapidité : Exécution du programme en quelques minutes sur PC. INCERTITUDE TECHNOLOGIQUES Notre projet se situe dans un environnement informatique rigide, puisqu il faut partir et aboutir à des données écrites dans un langage spécifique, le CDOGIF, et qu il faut utiliser un outil informatique donné, dans notre cas, ArcInfo. Cet environnement constitue une contrainte qui donne lieu à deux incertitudes technologiques. Incertitude technologique portant sur la traduction La première incertitude technologique est liée à la double traduction CCOGIF/ ArcInfo / CCOGIF. En effet, le langage AML (Arithmetic Macro Language) et la structuration de l information qui faisaient l intérêt d ArcInfo pour nos projets au provincial ne sont pas compatibles a priori avec le langage CCOGIF. La traduction est susceptible de défaire la structure de l information propre à chacun de ces langages. Sous ce rapport là, la situation est semblable à celle de la traduction automatique des langues qui donne lieu à des violations de la syntaxe parce que les règles sont trop complexes pour être consignées de façon sûre C est pourquoi, nous ne savons pas s il sera possible d effectuer cette double traduction tout en préservant la structure des jeux de données. Toutefois, cette incertitude technologique ne relève pas de notre compétence et nous avons confié le mandat de traduction à deux compagnies spécialisées dans ce domaine, ESRI, qui a conçu le logiciel ArcInfo, et FME, qui se spécialise dans les logiciels de traduction en géomatique. Notre intervention se limite ici à fixer les objectifs, évaluer les performances de la traduction et compléter par des procédures manuelles les lacunes du traducteur. 2 de 5
Incertitude technologique portant sur les performances La structuration des données est un élément capital qui détermine l efficacité du traitement avec un outil donné. Dans le cadre des possibilités offertes par ArcInfo, ou par tout autre outil, il existe ainsi plusieurs façons de structurer les données (par thèmes, par entités, etc.). Cependant, il n est pas possible de connaître les performances (vitesse d'exécution et taux d erreurs) qui résulteront de chacune de ces structurations. Par ailleurs, il est possible d alléger le traitement effectué par ArcInfo, en modifiant la structuration et en modifiant nos algorithmes. Toutefois, le risque est que tout le fardeau du traitement retombe sur nos applications. D une manière comme d une autre, il n est pas possible de savoir si nous atteindrons, ou comment nous atteindrons, les performances souhaitées, ce qui constitue la deuxième incertitude technologique dans le cadre de l environnement informatique d'arcinfo. À l appui des deux incertitudes technologiques mentionnées ci-dessus, nous tenons dans nos dossiers les correspondances entretenues avec ESRI, FME et le CITS, ainsi que la documentation technique sur les travaux d'expérimentation Première approche : couvertures et entités En collaboration avec les programmeurs d ESRI, nous avons élaboré une première approche de structuration de l information consistant à structurer les couvertures (groupes d éléments traités simultanément) d après les entités. Comme notre jeu de données comprend 6 000 entités, on se trouvait à traiter également 6 000 couvertures. L avantage de cette approche, préconisée par ESRI, est qu elle permet d associer facilement les entités et le code correspondant, ce qui permet une programmation simple parce que linéaire. Nous avons donc écrit un premier prototype selon cette approche. Lorsque nous avons fait les tests d exécution, les performances d ArcInfo étaient très médiocres. Il fallait plusieurs heures pour traiter l information sur un PC alors que notre objectif était de quelques minutes. Deuxième approche Dans cette deuxième approche, nous avons structuré les couvertures selon les thèmes prédéfinis du CITS. L avantage de cette approche est qu il n y a plus que 13 3 = 39 couvertures (chacun des 13 thèmes donne lieu à 3 couvertures correspondant respectivement aux points, aux lignes et aux polygones). 3 de 5
Les inconvénients sont qu il faut nettoyer certains champs rendus inutiles en fin de traitement et que l on ne peut plus visualiser simplement le code en l associant aux entités. Ce dernier inconvénient est majeur, car il implique de rentrer systématiquement (39 6 000 fois) dans la couverture pour vérifier la présence des entités. Programmation en bloc Nous avons donc écrit un autre prototype selon cette approche et nous avons fait des tests de performances. Le résultat est que le traitement prend encore plusieurs heures. Toutefois, ici, cette procédure ne pose plus de problèmes au niveau d ArcInfo, mais elle est manifestement trop lourde pour nos propres algorithmes. Programmation modulaire Nous avons donc repris la programmation afin de limiter la recherche aux entités présentes dans les couvertures. En procédant ainsi, nous avons pu réécrire le programme de façon modulaire plutôt qu en un seul bloc comme précédemment. Le résultat est que les performances sont correctes, puisqu il suffit de quelques minutes par thème. Toutefois, la structure du programme était trop rigide, ce qui empêchait de pouvoir s adapter à d'éventuels changements de normes. En effet, cette structure demandait de revoir chacune des milliers de lignes du code. Utilisation de tables de variables Pour rendre l application plus flexible, nous nous sommes servi des tableaux fournis par Géomatique Canada dans lesquels sont consignées toutes les valeurs numériques associées aux normes. Nous avons converti ces données html en format DBF pour construire un fichier de données définissant toutes les variables. Données sur les programmes écrits dans ce projet L application comporte près d une centaine de programmes. Dans la première approche, chacun de ces programmes pouvait contenir jusqu à 10 000 lignes Dans la deuxième approche : La première version comportait également jusqu à 10 000 lignes par programme ; La deuxième version comportait jusqu à 1 000 lignes par programme ; La troisième version ne comportait plus qu une centaine de lignes par programme. 4 de 5
Bilan des tests de détection des erreurs Comme nous l avons mentionné dans la description de notre démarche, nos programmes étaient envoyés régulièrement au CITS pour une évaluation globale. Sur les 12 essais auxquels nous avions droit, nous en avons réalisé 10. Toute l évolution et toutes les descriptions des erreurs ont été enregistrées et sont disponibles sur demande. Lors des premiers essais, on comptait jusqu à 2 000 erreurs. Dans notre dernière version, on n avait plus qu une vingtaine ( 20) d erreurs. Parmi ces erreurs, il y avait : Les erreurs produites par notre programme et que l on peut diviser en quatre catégories : L incohérence des séquences ; Les limites d ArcInfo ; Les erreurs de l utilisateur ; Les bogues. Ces erreurs incontrôlées sont à distinguer des erreurs volontairement introduites pour faire les tests de correction automatique. CONCLUSION Les travaux effectués ont permis d atteindre nos objectifs et les avancements technologiques escomptés. En particulier, nous disposons aujourd hui d un logiciel de traduction CCOGIF/ ArcInfo / CCOGIF effectif dans près de 90% des cas et que nous pouvons compléter grâce à des procédures manuelles développées par nous. Grâce aux procédés de structuration que nous avons développé, la qualité et les performances de notre application sont telles que nous avons effectivement obtenu l accréditation BNDT. Tous droits réservés Chabot, Pomerleau & associés M. Claude Chabot, ing. f., M. Env. et M. Stéphane Lacroix, ing. f 5 de 5