Université du Québec à Montréal GEO7330, GEO7931 - Activité de stage I et II

Claude Codjia, Benoît St-Onge

Rapport de stage

Manh Kong Nguyen NGUM02078606

Été-Automne 2013

2

Table des matières Liste des figures .................................................................................................................. 3 Liste des tableaux ................................................................................................................ 4 Liste des requêtes ................................................................................................................ 4 Liste d’abréviations ............................................................................................................. 5 Remerciements .................................................................................................................... 6 Introduction ......................................................................................................................... 7

L’organisme d’accueil : le Ministère des Transports du Québec ................................... 7 La place des SIG au sein du MTQ .................................................................................. 9 Environnement de stage ................................................................................................ 10

Rapport technique ............................................................................................................. 10 Automatisation d’identification des segments non nommés ........................................ 11

Introduction ............................................................................................................... 11 Automatisation sur les données de la BGR ............................................................... 11

Méthodologie ........................................................................................................ 11 Analyse de types de voies ..................................................................................... 14

Code 3 : entrées (E) et sorties (S) d’autoroutes ................................................ 15 Segments de sorties (S) ..................................................................................... 16 Segments d’entrée (E) ....................................................................................... 19 Code H : halte routière (H) ............................................................................... 19 Code P : poste de pesée (P) ............................................................................... 20 Code S : stationnement (ST) ............................................................................. 21 Code U : virage en en U (U) ............................................................................. 21

Limitations ............................................................................................................ 22 Conclusion ............................................................................................................ 25

Automatisation sur les données d’Adresses Québec ................................................ 25 Introduction ........................................................................................................... 25 Méthodologie ........................................................................................................ 26 Limitations ............................................................................................................ 27 Conclusion ............................................................................................................ 29

Projet de catalogue de métadonnées GeoNetwork ........................................................ 29 Importation de métadonnées dans GeoNetwork ....................................................... 29

Introduction ........................................................................................................... 29 Méthodologie ........................................................................................................ 30 Limitations ............................................................................................................ 37 Conclusion ............................................................................................................ 37

Procédure d’installation de GeoNetwork .................................................................. 37 Autres projets mineurs .................................................................................................. 38

Véhicules hors routes (VHR) et vérification de la topologie .................................... 38 Test de performance d’un projet du système d'Aide à la Décision en Sécurité Routière (SADSR) .................................................................................................... 42

Réflexions personnelles sur le stage ................................................................................. 42

3

Conclusion ........................................................................................................................ 44 Index des annexes ............................................................................................................. 45 Bibliographie..................................................................................................................... 46

Liste des figures Figure 1: Organigramme global du MTQ ........................................................................... 7 Figure 2: Organigramme du DGSGSM .............................................................................. 8 Figure 3: Organigramme du DTI ........................................................................................ 8 Figure 4: Système de diffusion de données géographiques « SIG Express » ..................... 9 Figure 5: Structure du RTSS (tiré de MTQ, 2002) ........................................................... 12 Figure 6: Structure graphique du RTSS (tiré de MTQ, 2002) .......................................... 12 Figure 7: Nomenclature des SNN (inspiré de Hamoudi, 2009) ........................................ 13 Figure 8: Nouvelle structure du SNN ............................................................................... 14 Figure 9: Sortie d'autoroute (tiré de Hamoudi, 2009) ....................................................... 16 Figure 10: Entrée d'autoroute (tiré de Hamoudi, 2009) .................................................... 16 Figure 11: Points aux extrémités (étoiles bleues) et sorties (points rouges) ..................... 17 Figure 12: Résultat de la jointure spatiale aux points de sortie ........................................ 17 Figure 13: Résultat de la jointure avec les segments de route .......................................... 17 Figure 14: Exemple de SNN d'entrée et de sortie ............................................................. 18 Figure 15: Détection de sortie secondaire ......................................................................... 18 Figure 16: Valeur 'D' dans COTE_CHAUS donnant sur un autre de même type ............ 19 Figure 17: Deux niveaux de halte routière ........................................................................ 20 Figure 18: Poste de pesée (jaune) avec un stationnement (cyan) ..................................... 21 Figure 19: Forme typique d'un virage en U ...................................................................... 22 Figure 20: Information manquante pour certains segments enlevés ................................. 22 Figure 21: Segment de sortie secondaire faussement identifié ......................................... 23 Figure 22: Virages en U ayant le même SNN ................................................................... 24 Figure 23: Création de points avec « Feature Vertices to Points » ................................... 24 Figure 24: Structure du SNN pour BGR ........................................................................... 26 Figure 25: Structure du SNN pour AQ ............................................................................. 26 Figure 26: Exemple de segments sans infrastructure (en bleu clair) ................................ 28 Figure 27: Les segments à traiter sont souvent contigus .................................................. 28 Figure 28: Exemple de XML ............................................................................................ 30 Figure 29: Identification des champs obligatoires d’ISO19139 dans ArcMap ................. 31 Figure 30: Identification des champs obligatoires d'ISO19139 dans GeoNetwork .......... 31 Figure 31: Fichier XML ArcMap ..................................................................................... 32 Figure 32: Fichier XML GeoNetwork .............................................................................. 32 Figure 33: Structure du dossier GeoNetwork ................................................................... 33 Figure 34: Script avec module PythonMagick pour générer les vignettes ....................... 34 Figure 35: Résultat du script pour générer les vignettes ................................................... 34 Figure 36: Les éléments nécessaires sont présents pour l'importation ............................. 35 Figure 37: Comment trouver le dernier identifiant attribué par GeoNetwork .................. 35 Figure 38: Traitement et son résultat ................................................................................ 36 Figure 39: Résultat final dans GeoNetwork...................................................................... 36 Figure 40: Extrait de la procédure d'installation ............................................................... 37

4

Figure 41: Interface de l'outil "Combiner" ........................................................................ 39 Figure 42: Résultat final de la combinaison des couches de motoneiges ......................... 40 Figure 43: Règle topologique "Ne doivent pas avoir de nœuds pendants" ....................... 40 Figure 44: Résultat de l'outil « Topology » ...................................................................... 41 Figure 45: Erreur de numérisation .................................................................................... 41 Figure 46: Tableau de temps de chargement .................................................................... 42 Figure 47: Première tentative de modèle pour projet SNN ............................................... 43

Liste des tableaux Tableau 1: Type d'infrastructure routière .......................................................................... 13 Tableau 2: Description des champs du SNN .................................................................... 14 Tableau 3: Sommaire des SNN traités avec le modèle selon la région ............................ 25 Tableau 4: Description des champs du SNN dans AQ ..................................................... 26 Tableau 5: Types d'infrastructure routière d'Adresses Québec ......................................... 27

Liste des requêtes Requête 1: Requête SQL pour les entrées et sorties d'autoroutes ..................................... 15 Requête 2: Requête SQL pour les haltes routières............................................................ 19 Requête 3: Requête SQL pour les postes de pesée ........................................................... 20 Requête 4: Requête SQL pour les stationnements ............................................................ 21 Requête 5: Requête SQL pour les virages en U ................................................................ 21 Requête 6 : Requête SQL pour trouver les segments à traiter dans AQ ........................... 26

5

Liste d’abréviations AQ : Adresses Québec BGR : Base géographique routière CEGEP : Collège d'enseignement général et professionnel DESS : Diplôme d’études supérieures spécialisées DGE : Directeur général des élections DGSGSM : Direction générale des services à la gestion et de la surveillance des marchés DTI : Direction des technologies de l’information FAO : Food and Agriculture Organization of the United Nations MAMROT : Ministère des Affaires municipales, des Régions et de l'Occupation du territoire MTQ : Ministère des Transports du Québec MRN : Ministère des Ressources naturelles SADSR : Système d'Aide à la Décision en Sécurité Routière SIG : Système d’information géographique SNN : Segments non nommés UQAM : Université du Québec à Montréal VHR : Véhicule hors-route WHO : World Health Organization XML : Extensible Markup Language

6

Remerciements Je tiens à remercier ceux qui ont rendu ce stage possible (ordre alphabétique) : du côté du MTQ : Pierre Lessard, Gaétan Poulin et Prita Pourouchottamin; à l’UQAM : Hans Asnong, Claude Codjia, Michel Dufault et Benoît St-Onge. J’aimerais remercier mes collègues qui ont contribué à rendre l’endroit très amical et convivial : Vincent Bouliane, Yali Chen, Marc Chikhani, Dung Do Trong, Mélanie Kenmoe, Mylène Lachapelle, Pierre Lessard, Manon Paquette et Prita Pourouchottamin. Bien sûr, j’aimerais remercier mes amis qui m’ont supporté dans mon cheminement. J’aimerais faire une mention spéciale à Riad Hamoudi, ancien collègue de travail, qui m’a poussé à faire mon DESS en SIG, ainsi qu’à la Chorale des Intrépides, qui m’a permis de relaxer et de me laisser aller pendant quelques heures à chanter chaque semaine. Finalement, un gros merci à la première personne qui à penser à faire bouillir des feuilles de Camellia sinensis afin d’obtenir la merveilleuse boisson qui a été à mes côtés tout le long de ce stage : le thé.

7

Introduction Afin d’obtenir leur diplôme d’études supérieures spécialisées (DESS) en système d’information géographique (SIG), les étudiants de l’Université du Québec à Montréal (UQAM) doivent compléter un stage d’au moins 12 semaines dans un organisme où ils pourront utiliser les habiletés qu’ils ont acquises durant leurs études. Dans mon cas, l’organisme dans lequel j’ai fait mon stage d’une durée de 15 semaines est le Ministère des Transports du Québec (MTQ).

L’organisme d’accueil : le Ministère des Transports du Québec Le mandat du MTQ, selon la déclaration sur leur site internet est « d’assurer, sur tout le territoire du Québec, la mobilité durable des personnes et des marchandises par des systèmes de transport efficaces et sécuritaires qui contribuent au développement du Québec » (MTQ, 2013). Concrètement, ceci veut dire qu’ils sont responsables du réseau routier supérieur, qui comprend les autoroutes, les routes nationales, les routes régionales et les routes collectrices, ainsi que le réseau d’accès aux ressources (MTQ, 1993).

Figure 1: Organigramme global du MTQ

Sous la responsabilité du sous-ministre (figure 1), on trouve la Direction générale des services à la gestion et de la surveillance des marchés (DGSGSM), dans lequel se trouve la Direction des technologies de l’information (DTI) (figure 2). Brièvement, la DGSGSM a pour mandat de gérer les ressources au sein du MTQ; la DTI a comme mandat de gérer les ressources technologiques.

8

Figure 2: Organigramme du DGSGSM La division de la géomatique du MTQ est une des sous-branches de cette direction (figure 3) et c’est dans cette branche que mon stage a été réalisé. La division coordonne les dossiers géomatiques, gère l’information géographique, produit des documents cartographiques et utilise les SIG pour répondre aux besoins géomatiques du MTQ, d’autres projets gouvernementaux et de particuliers.

Figure 3: Organigramme du DTI

9

La place des SIG au sein du MTQ La première chose qui vient en tête lorsque l’on parle du MTQ et des SIG est la cartographie. En effet, le volet cartographique des SIG est très important, car la division de la géomatique produit toutes les cartes pour les réseaux routiers à l’échelle du Québec. Pour produire ces cartes, il est nécessaire d’avoir et de gérer une grande quantité de données et de diffuser celles-ci à ceux qui en auraient besoin. Pour ce faire, la division a développé des systèmes comme « SIG Express » pour partager de façon conviviale les données géographiques (figure 4) au sein du MTQ.

Figure 4: Système de diffusion de données géographiques « SIG Express » La division de la géomatique travaille aussi conjointement avec le Ministère des Affaires municipales, des Régions et de l'Occupation du territoire (MAMROT), le Directeur général des élections (DGE) et le Ministère des Ressources naturelles (MRN) sur le projet « Adresses Québec » (http://adressesquebec.gouv.qc.ca/), pour offrir une géobase officielle du Québec, pour usage interne et aux particuliers.

10

Environnement de stage Le MTQ a plusieurs bureaux dans la grande région de Montréal, mais la division de la géomatique se trouve au 35 rue de Port-Royal. Dans cet immeuble, on trouve aussi d’autres bureaux gouvernementaux. Les bureaux du MTQ sont divisés en sections qui regroupent les divers secteurs d’activités : administration, informatique, environnement et géomatique. Grâce à cette disposition, mes voisins étaient tous des géomaticiens et mes superviseurs n’étaient pas très loin. Cet agencement aide à l’intégration d’un nouvel arrivant, car cette personne sera en contact avec des gens qui œuvrent dans le même domaine. En ce qui concerne l'équipement, les bureaux à cloisons sont tous munis de téléphones et d’ordinateurs PC. Selon les ordinateurs, les logiciels de SIG peuvent varier, mais ArcMap 10.0 se trouve sur tous les postes. D’autres logiciels comme FME ou MapInfo peuvent être installés au besoin; comme mon stage était basé principalement sur la programmation, j’ai demandé qu’on installe le logiciel libre Notepad++ sur mon poste pour que je puisse avoir un environnement convivial pour programmer. Ce qui m’a marqué le plus est le fait que la plupart des logiciels fonctionnent avec une licence flottante, contrairement à un autre lieu de travail que j’ai déjà fréquenté. Il y a assez de licences de base pour tout le monde, mais il n’y a qu’un nombre restreint de licences plus avancées; ceci n’est pas un problème la majorité du temps, mais il arrive qu’il ne reste plus de licence et qu’il faille faire quelques appels pour les libérer. Les manuels de référence existent aussi pour les logiciels en format papier, au besoin.

Rapport technique Deux gros projets étaient nommés dans mon mandat : un portait sur les segments (de route) non nommés (SNN) et l’autre l’élaboration d’un catalogue de métadonnées. Un troisième projet, sur lequel j’aurais travaillé avec les gens du bureau de Québec, était planifié, mais je n’ai que fait qu’une petite tâche pour eux (voir dans la section « Projets mineurs »). Le thème général de ces projets était l’élaboration d’un processus d’automatisation grâce à la programmation et à l’utilisation d’outil d’automatisation, comme Model Builder dans ArcMap. Ceci me convenait, comme mon expérience académique (je possède une technique en informatique) et professionnelle (deux ans en tant que géomaticien dans une autre firme) m’a préparé pour ce genre de stage. De plus, j’ai eu quelques projets de programmation de scripts à mon ancien emploi. On accordait au moins quatre semaines à chaque projet, mais ceci pouvait changer avec la modification des objectifs de ceux-ci. Brièvement, les projets étaient :

Projets majeurs : o Automatisation d’identification des SNN :

Sur les segments de la Base géographique routière (BGR); Sur les segments d’Adresses Québec (AQ).

o Projet de catalogue de métadonnées GeoNetwork : Développer une méthode d’importation massive de données;

11

Rédiger une procédure d’installation des logiciels pour faire fonctionner GeoNetwork.

Projets mineurs : o Fusion des chemins de véhicules hors routes (VHR) et vérification de la

topologie; o Test de performance d’un projet du système d'Aide à la Décision en

Sécurité Routière (SADSR).

Automatisation d’identification des segments non nommés

Introduction Comme mentionnée précédemment, la classification du réseau routier québécois se trouve sous la responsabilité du MTQ et cette information est rassemblée dans la Base géographique routière (BGR), qui est mise à jour de façon régulière avec la collaboration des directions territoriales et des autres ministères. L’information est regroupée sous diverses catégories selon leur fonction (MTQ, 2008; MTQ, 2009):

Autoroutes (collectrices, de déviation, de contournement et sorties); Routes nationales principales; Routes régionales secondaires; Routes locales.

La majorité des voies présentes sont identifiées et nommées, mais il existe des voies qui n’ont pas d’identifiant – elles sont connues comme les segments non nommées (SNN). Ces segments sont connectés aux autoroutes, aux routes nationales, à certains axes majeurs du réseau secondaire et on les trouve même au niveau local. L’identification des voies va se faire selon un modèle qui a déjà été développé par un stagiaire en 2009, Riad Hamoudi. Trouver un identifiant facile à comprendre pour ces SNN est important pour pouvoir les situer sur un réseau routier pour, entre autres, les services d’urgences ou d’entretien. Dans le cadre de ce projet, nous nous intéressons uniquement aux segments primaires connectés aux autoroutes. Malgré cette limitation, ceci représente une grande quantité de segments qui requirent beaucoup de traitement et c’est pour cela que l’automatisation est la méthode privilégiée. Initialement, le projet ne visait que les SNN de la BGR, mais une fois que des résultats satisfaisants ont été obtenus pour celle-ci, le tout a été testé, avec quelques modifications, sur la base de données d’Adresses Québec.

Automatisation sur les données de la BGR

Méthodologie Afin de comprendre la structure du SNN, il est nécessaire de parler du système de codification du réseau routier du Québec : la majorité des routes, même certains SNN, ont un identifiant unique qui est composé de 14 caractères, divisés en quatre parties (Route,

12

tronçon, section, sous-route); consultez les figures 5 et 6 pour plus d’information sur la structure du RTSS. Par contre, le RTSS ne permet pas l’identification efficace de voies, alors il faut une nomenclature plus conviviale pour nommer les SNN.

Figure 5: Structure du RTSS (tiré de MTQ, 2002)

Figure 6: Structure graphique du RTSS (tiré de MTQ, 2002) La nomenclature proposée en 2009 (figure 7) utilise divers champs de la BGR et de la base de données d’Adresses Québec (AQ), qui, en plus d’avoir de l’information sur le réseau routier supérieur, contient de l’information sur les routes locales et municipales.

13

Figure 7: Nomenclature des SNN (inspiré de Hamoudi, 2009) Le type d’infrastructure (variable TYPE_INFRA) représente la nature du SNN et est identifiable grâce au 11e caractère du RTSS. Le tableau 1 énumère les divers types d’infrastructure et le tableau 2 offre une description des champs qui composent l’identifiant du SNN. À noter que seule la variable TYPE_INFRA est toujours présente, car il arrive que l’information pour les autres variables ne soit pas disponible dans les bases de données. Par exemple, un virage en U n’aura pas de numéro de sortie, ou une voie peut ne pas avoir d’identifiant de route (figure 7). À l’échelle du Québec, on compte 11 types de voies qui peuvent être des SNN (tableau 1), mais pour la région test de Chaudière-Appalaches, seulement 5 sont traités dans cette phase d’automatisation :

1. Entrée/sortie (E/S); 2. Halte routière (H); 3. Poste de pesée (P); 4. Stationnement (St); 5. Virage en U (U)

Code Préfixe pour SNN Type

3 E/S Entrée et sortie d'autoroutes (carrefours et bretelles) A A Accès restreint B B Aire de contrôle D D Débarcadère G G Carrefour giratoire H H/Hs Halte routière (deux niveaux) P P Poste de pesée R R Refuge S St Stationnement U U Virage en U V V Voie de service

Tableau 1: Type d'infrastructure routière

14

Nom de champ Base de données Description TYPE_INFRA BGR Type d'infrastructure se trouvant au début du segment

ROUTE_PROV BGR Numéro de route du segment de provenance SPEC_PROV AQ Odonyme du segment de provenance DIR_PROV BGR Direction du segment de provenance

NO_SORTIE BGR Numéro de sortie du segment (s'il y a lieu) ROUTE_DEST BGR Numéro de route du segment de destination SPEC_DEST AQ Odonyme du segment de destination DIR_DEST BGR Direction du segment de destination

Tableau 2: Description des champs du SNN En 2013, une nouvelle nomenclature a été proposée pour les SNN. Bien que la nomenclature de 2009 fût complète, elle n’était pas assez rapidement déchiffrable. Le format a donc été changé, tout en gardant l’information recueillie dans la dernière version du SNN. La principale différence est que le spécifique d’odonyme est maintenant optionnel lorsque le numéro de la route comprend 3 chiffres ou moins; la raison derrière ceci est que ces routes majeures peuvent être connues sous différents noms selon la région dans laquelle elle se situe, mais son numéro de route ne changera jamais.

TYPE_INFRA[-NO_SORTIE] + ROUTE_PROV[-SPEC_PROV]-DIR_PROV + ROUTE_DEST[-SPEC_DEST]-DIR_DEST

Figure 8: Nouvelle structure du SNN Quelques exemples de SNN selon le type d’infrastructure, selon la nouvelle structure :

Entrée : E 86510-Robert-Cliche-EO 73-N; Halte routière : H 20-O 20-O; Poste de pesée : P 20-O 20-O; Sortie : S-108 73-S 86870-Dentellière-EO; Stationnement : ST 73-SN 73-SN; Virage en U : U 20-E 20-O

Analyse de types de voies Afin de pouvoir automatiser le processus, il est nécessaire de trouver une logique informatique d’identification des segments, selon les propriétés géographiques et attributaires de chaque voie. L’ensemble des étapes ont été automatisé dans le logiciel ArcMap 10.1, compte tenu de son outil Model Builder qui permet d’automatiser des tâches et de sa fonctionnalité intégrée de programmation en langage VBScript ou Python. De plus, une licence ArcInfo est nécessaire pour utiliser certains outils qui sont propres à ce niveau de licence, notamment l’outil « Feature Vertices to Points », qui permet de créer des points aux extrémités des segments. Les modèles d’automatisation se trouvent en annexe. L’identifiant peut être divisé en trois parties majeures, avec le numéro de sortie (NO_SORTIE) étant facultatif, selon le type d’infrastructure concerné :

15

1. Le type d’infrastructure (TYPE_INFRA); 2. La provenance du VNN (ROUTE_PROV, SPEC_PROV, DIR_PROV); 3. La destination du SNN (ROUTE_DEST, SPEC_DEST, DIR_DEST).

Comme l’information se trouve dans des bases de données différentes et que les éléments graphiques se superposent, il est nécessaire de commencer par une jointure spatiale afin de recueillir toute l’information dans un fichier; les analyses par types seront ensuite jointes sur le champ RTSS pour récupérer les identifiants de SNN. Lorsque les composantes du SNN sont trop ambigües pour former un identifiant, une vérification manuelle sera nécessaire et la valeur « XXX » sera attribuée, suivie du type d’infrastructure et de la raison. L’outil « Feature Vertices to Points » sera utilisé dans la majorité des cas : à partir d’un polygone ou d’une ligne, cet outil créé des points aux sommets; dans notre cas, ce sont les points aux extrémités des segments qui nous intéressent. Ceci permet de créer une paire de points qui contiennent l’information du segment initial et qui, grâce à des jointures spatiales subséquentes, nous permettrons d’obtenir l’information des segments de provenance et de destination; le champ qui identifie la paire de points est ORIG_FID. D’autres champs seront communs à toutes les méthodes d’identification :

ROUTE : ce sont les cinq premiers caractères du RTSS et il identifie le numéro de la route. En général, un nombre pair est une route qui va de l’ouest en est, et une route impaire est orientée sud-nord;

GaOdoSpeci/DrOdoSpeci : spécifique d’odonyme à la gauche et à la droite du segment. En général, les valeurs sont les mêmes, mais lorsque ce n’est pas le cas, une vérification manuelle est nécessaire pour bien identifier le SNN;

COTE_CHAUS : spécifie si une chaussée est continue ou composée d’un côté gauche et droit. Sers à déterminer la direction cardinale de la route et pour identifier si c’est une destination ou une provenance pour les segments de type entrée (voir ci-dessous).

Un script en Python/VBScript et un modèle dans Model Builder ont été créés pour chaque type de voie. Les scripts sont intégrés dans les modèles et ces modèles sont eux-mêmes intégrés dans un modèle général qui, une fois lancé, identifie tout les SNN pour la couche qu’on lui fournit. Des exemples de modèles et de scripts sont présentés en annexe.

Code 3 : entrées (E) et sorties (S) d’autoroutes Dans le cadre du projet, nous nous intéressons uniquement aux segments qui touchent les autoroutes; les figures 9 et 10 montrent des exemples d’entrées et de sorties. Pour identifier ces segments, la requête suivante est utilisée :

"CODE"='3' AND "CL_FONCT"='Autoroute' AND "COTE_CHAUS"='0'

Requête 1: Requête SQL pour les entrées et sorties d'autoroutes

16

Figure 9: Sortie d'autoroute (tiré de Hamoudi, 2009)

Figure 10: Entrée d'autoroute (tiré de Hamoudi, 2009)

Segments de sorties (S) En suivant la logique de création de paires de points par segment (voir ci-dessus) nous créons une paire de points à partir de ces segments (figure 11) qui seront par la suite joints spatialement à la couche de points de sorties: pour une paire de points donnée, si un point contient un numéro de sortie, c'est le point de provenance d'une sortie et l’autre est celui de la destination de sortie (figure 12). Ensuite, on élimine les segments desquels les

17

points ont été créés pour que, lorsque la jointure spatiale avec les routes est faite, l’information obtenue corresponde aux segments de provenance et de destination, et non au segment d’origine (figures 12 et 13); un exemple de SNN d’entrée et de sortie est visible dans la figure 14. Par contre, le fait d’éliminer les segments d’origine peut mener à des problèmes dans des zones plus complexes comme des grands échangeurs (voir ci-dessous dans la section « Limitations »).

Figure 11: Points aux extrémités (étoiles bleues) et sorties (points rouges)

Figure 12: Résultat de la jointure spatiale aux points de sortie

Figure 13: Résultat de la jointure avec les segments de route

18

Figure 14: Exemple de SNN d'entrée et de sortie Les segments secondaires de sorties (figure 15) sont détectés lors du traitement des segments d’entrées : selon la logique des paires de points, une sortie secondaire serait considérée comme une entrée, comme elle ne comporte pas de données sur le numéro de sortie. Pour détecter ces segments, il faut donc traiter les segments de sortie primaire avant, afin de recueillir l’information ce de ceux-ci lors du traitement des segments d’entrées.

Figure 15: Détection de sortie secondaire

19

Segments d’entrée (E) Pour différencier la provenance et la destination des segments « E (entrée) », la règle suivante à été utilisée :

Pour les autoroutes, la destination est souvent un segment dont la valeur du champ COTE_CHAUS est soit D ou G. Le type C est aussi commun, mais la priorité est donnée au type D/G. Donc la hiérarchie de destination est la suivante : D/G, C, puis les autres types de voies;

Il arrive que, dans les grands échangeurs, un segment C/D/G donne sur un autre segment C/D/G. Comme il est difficile de donner une valeur correcte à ce SNN, il sera nécessaire de faire une vérification manuelle pour ce segment (figure 16).

Figure 16: Valeur 'D' dans COTE_CHAUS donnant sur un autre de même type

Code H : halte routière (H) Pour traiter les segments d’halte routière, la requête suivante a été utilisée :

"CODE"='H' AND "CL_FONCT"='Autoroute'

Requête 2: Requête SQL pour les haltes routières Le traitement de ce type de segment est plus simple que celui des segments de sortie et d’entrée, car le segment de provenance et de destination est souvent la même.

20

Une particularité de ce type d’infrastructure est qu’il comporte deux niveaux : un niveau primaire identifié avec le code « H » et un deuxième niveau identifié avec les lettres « Hs » (figure 17). Ce niveau secondaire est attaché à un segment de halte primaire. En utilisant la méthode de paire de points, on peut obtenir l’information nécessaire pour bâtir le SNN. Contrairement aux segments E/S, lorsqu’un segment manque d’information à cause qu’il a été éliminé, on peut en déduire que ce segment est un segment de halte secondaire.

Figure 17: Deux niveaux de halte routière

Code P : poste de pesée (P) Pour traiter les segments de poste de pesée, la requête suivante a été utilisée :

"CODE"='P' AND "CL_FONCT"='Autoroute'

Requête 3: Requête SQL pour les postes de pesée Les postes de pesée (P) sont connectés à un même segment de route, alors leur provenance et leur destination sont la même. Il y a parfois des stationnements (ST) qui y sont connectés, comme dans la figure 18. Pour les identifier, la même logique que celle des haltes routières est utilisée, mais il n’existe pas plusieurs niveaux de postes de pesée comme pour les haltes.

21

Figure 18: Poste de pesée (jaune) avec un stationnement (cyan)

Code S : stationnement (ST) Pour traiter les segments de stationnement, la requête suivante a été utilisée :

"CODE"='S' AND "CL_FONCT"='Autoroute'

Requête 4: Requête SQL pour les stationnements Comme mentionnés dans la section des postes de pesées, les stationnements sont connectés aux postes de pesée sur les autoroutes. La logique de détection est la même que pour les haltes routières, mais il n’existe pas plusieurs niveaux de stationnements.

Code U : virage en en U (U) Pour traiter les segments de virage en U, la requête suivante a été utilisée :

"CODE"='U' AND "CL_FONCT"='Autoroute'

Requête 5: Requête SQL pour les virages en U Bien qu’un virage en U retourne nécessairement sur elle-même, la technique des paires de points est quand même utilisée pour avoir de l’information plus précise sur les segments de provenance et de destination des virages. Le format typique est illustré dans la figure 19.

22

Figure 19: Forme typique d'un virage en U

Limitations Le fait d’éliminer les segments d’origine va engendrer des problèmes, car certains segments d’entrée ou de sorties sont raccordés entre eux, et il manquera des données pour compléter le SNN (figure 20). Comme mentionné ci-haut, pour les segments d’entrée, l’identification du segment de destination et celui de provenance peut être problématique parfois et peut nécessiter une vérification manuelle; ces segments sont identifiés avec le préfixe « Z » et les cas particuliers avec « XXX ».

Figure 20: Information manquante pour certains segments enlevés

23

De plus, l’agencement géographique des objets dans la base de données peut donner de faux résultats, selon la logique utilisée ici : la figure 21 identifie faussement un segment d’entrée comme étant un segment de sortie secondaire parce que celui-ci partage un même point d’ancrage avec le segment de sortie. Les segments de sortie secondaires devront donc être vérifiés manuellement.

Figure 21: Segment de sortie secondaire faussement identifié L’identifiant de SNN peut être le même pour certains segments de virage en U, comme illustré dans la figure 22. Cette situation est causée par la numérisation même des segments de routes : lorsque l’outil « Feature Vertices to Points » est utilisé, l’ordre des points est fait selon l’ordre de numérisation du segment (figure 23), donc la provenance et la destination peuvent être inversées. Ceci se produit uniquement pour le cas des virages en U, comme les autres segments ont la même provenance et destination et que l’algorithme de détection est plus détaillé pour les sorties et les entrées.

24

Figure 22: Virages en U ayant le même SNN

Figure 23: Création de points avec « Feature Vertices to Points »

#1

#2 #1

#2

Direction

de n

um

érisation

Dir

ecti

on d

e n

um

éris

atio

n

25

Conclusion Le modèle d’automatisation a été développé pour la région test de Chaudière-Appalaches, mais il a par la suite été utilisé pour traiter les régions de Lanaudière-Laurentides, de la Mauricie et de la province de Québec. Les résultats se trouvent dans le tableau Tableau 3: Sommaire des SNN traités avec le modèle selon la région. À noter que le modèle actuel ne traite que 5 des 11 types de segments de SNN, donc le total réel va être plus élevé. Ce n’est que pour la région de la Mauricie et pour la province que le nombre changerait; dans le premier cas, il y a des segments des segments de refuges (R) et de voie de service (V) et la province contient tous les types de segments. Voici un descriptif des colonnes :

SNN : nombre de segments traités; Cas particuliers : sont des segments pour lesquels on ne peut distinguer l’origine

et la destination. Ce sont exclusivement des segments d’entrée; Information manquante : segments pour lesquels il manque une partie du SNN.

Ceci se produit lorsqu’une voie est effacée dans le processus, ou parfois les voies d’origine et de destination ne contiennent pas l’information;

Total : le nombre de cas particuliers additionnés aux cas à information manquante.

Vérification manuelle

Région SNN Cas particuliers Information manquante Total Chaudière-Appalaches 400 13 16 29

Lanaudière-Laurentides 313 16 49 65 Mauricie 284 11 30 41

Province de Québec 3 895 274 733 1 007 Tableau 3: Sommaire des SNN traités avec le modèle selon la région Le nombre de cas à information manquante pourrait diminuer si la jointure spatiale initiale se faisait en gardant toute l’information des deux couches, et non seulement de la couche BGR – c’est ce que l’on peut observer pour un grand nombre de cas lorsque le modèle est lancé pour la province au complet. Le modèle en est aussi à son stade primaire : les versions futures seront divisées en sous-processus et le tout sera optimisé.

Automatisation sur les données d’Adresses Québec

Introduction L’automatisation a produit des résultats satisfaisants lorsqu’exécutées sur les données de la BGR, alors des questions ont été soulevées quant à la possibilité d’adapter le tout pour la base de données d’Adresses Québec. Des extraits de code et le modèle peuvent être trouvés en annexe.

26

Méthodologie La structure du SNN pour les données de la BGR a la forme présentée dans la figure 24. La majorité des données utilisées pour bâtir le SNN proviennent de la BGR, mais les variables SPEC_PROV et SPEC_DEST, qui contiennent le spécifique d’odonyme, proviennent de la base de données d’AQ.

TYPE_INFRA[-NO_SORTIE] ROUTE_PROV[-SPEC_PROV]-DIR_PROV ROUTE_DEST[-SPEC_DEST]-DIR_DEST

Figure 24: Structure du SNN pour BGR La figure 25 présente la structure du SNN pour AQ. La structure du SNN pour AQ est similaire que celle de la BGR, mais le spécifique d’odonyme est obligatoire, comme il est question de rues locales et que ces segments ne comportent pas tous des numéros de route pour les identifier. Pour la BGR, la direction était déterminée selon le numéro de route : une route paire a une direction ouest-est tandis qu’une route impaire a une direction sud-nord. Par contre, pour AQ, la colonne « Dr/GaOdoOrien » est utilisée.

TYPE_INFRA[-NO_SORTIE] [ROUTE_PROV]-SPEC_PROV-[DIR_PROV] [ROUTE_DEST]-SPEC_DEST-[DIR_DEST]

Figure 25: Structure du SNN pour AQ Pour trouver les segments à traiter, la requête SQL suivante est utilisée; cette requête s’assure que seuls les segments qui se nomment « Voie » sont traités, et pas ceux dont le nom est réellement « Voie », comme « Rue de la Voie ».

"GaOdoSpeci"='Voie' AND "DrOdoSpeci"='Voie' AND "GaOdoRecLg"='Voie' AND "DrOdoRecLg"='Voie'

Requête 6 : Requête SQL pour trouver les segments à traiter dans AQ L’information nécessaire pour bâtir un SNN se trouve dans AQ sous des noms différents, mais il arrive que l’information ne soit pas présente. Le tableau 4 montre les colonnes desquels l’information peut être tirée.

Variable Nom de champ Description TYPE_INFRA CaractRte Type d'infrastructure se trouvant au début du segment

ROUTE_PROV NoRte Numéro de route du segment de provenance SPEC_PROV Dr/GaOdoSpeci Odonyme du segment de provenance DIR_PROV Dr/GaOdoOrien Direction du segment de provenance

NO_SORTIE NO_SORTIE Numéro de sortie du segment (s'il y a lieu) ROUTE_DEST NoRte Numéro de route du segment de destination SPEC_DEST Dr/GaOdoSpeci Odonyme du segment de destination DIR_DEST Dr/GaOdoOrien Direction du segment de destination

Tableau 4: Description des champs du SNN dans AQ

27

Limitations Les mêmes méthodes de détection sont utilisées pour les SNN d’AQ. La seule différence est qu’il n’y a pas de détection de segments secondaires (sorties, haltes, etc.). Par contre, compte tenu de la différence structurale de la base de données d’AQ, nous sommes confrontés à certaines limitations. Tout d’abord, le champ « CaractRte », qui est utilisé pour classer le SNN selon son type d’infrastructure, contient des types d’infrastructures différentes (tableau 5). Le type « Bretelle » représente en fait une entrée ou une sortie, selon la présence ou non d’un numéro de sortie dans la table d’attributs. Le problème survient lorsque l’on arrive à un segment sans type défini, pour lesquels on attribue le préfixe ‘X’; ces segments représentent 38% des segments à traiter, ce qui est problématique. De plus, ils ne semblent pas présenter une caractéristique particulière qui pourrait servir à les différencier (figure 26).

CaractRte Préfixe Compte

Bretelle B (E/S) 6 209 Carrefour giratoire CG 81

Parc routier PR 43 Poste de pesée PR 11

Tournebride T 9 Traverse TR 108

Virage en U U 123 Voie de desserte VD 221 <sans valeur> X 4 257

Total 11 062 Tableau 5: Types d'infrastructure routière d'Adresses Québec

28

Figure 26: Exemple de segments sans infrastructure (en bleu clair) Un autre problème est celui du manque d’information pour compléter le SNN, dû à l’effacement des segments à traiter. Lors du traitement, les segments à traiter, les segments « parents », sont effacés suite à la création des points « enfants », pour que ces points ne prennent pas l’information du segment « parent », mais celui des segments auxquels ils touchent. Ce problème se produisait aussi lors du traitement des SNN de la BGR, mais il est beaucoup plus présent pour AQ : pour 542 segments de la région de Chaudière-Appalaches, 300 sont incomplets. Ceci est dû au fait que les segments à traiter sont souvent raccordés à d’autres segments qui sont aussi à traiter (figure 27).

Figure 27: Les segments à traiter sont souvent contigus

29

Conclusion La méthode de traitement des SNN de la BGR n’est pas très applicable au AQ, compte tenu du nombre de segments qui n’ont pas d’infrastructure définie et de la contigüité des segments à traiter. Pour pallier à ceci, une sélection plus fine des segments à traiter pourrait être considérée. On remarque que plusieurs des segments problématiques sont d’ordre supérieur, et donc sont déjà traités dans la BGR. On pourrait donc ignorer ces segments. Pour l’autre problème, il faudrait que les valeurs manquantes soient complétées, ou qu’un type autre que ‘X’ soit défini. Un dernier problème existe aussi : tandis que la BGR contient le RTSS pour identifier une route, AQ à un IdRte qui sert à ceci. Par contre, ces champs n’existent que dans leur base de données respective et un raccordement n’est pas possible pour partager l’information des SNN entre elles.

Projet de catalogue de métadonnées GeoNetwork Le deuxième volet de mon stage portait sur l’importation de métadonnées dans le catalogue de métadonnées GeoNetwork (http://geonetwork-opensource.org/). C’est un logiciel libre qui gère des données spatiales et qui est utilisés par divers organismes comme le Food and Agriculture Organization of the United Nations (FAO : http://www.fao.org/geonetwork/srv/en/main.home) et le World Health Organization (WHO : http://apps.who.int/geonetwork/srv/en/main.home). Ce système offre aussi une interface conviviale pour rechercher et pour créer de nouvelles données et toutes ces données sont encadrées par des normes ISO. La diffusion des données géographiques au sein du MTQ via GeoNetwork fait partie d’une tendance au gouvernement qui vise l’utilisation de logiciels libres comme celui-ci afin de diminuer les coûts reliés à l’achat et à l’entretien d’un tel système. Cette partie du stage s’est faite en deux parties :

1. élaboration d’une méthode d’importation de métadonnées dans GeoNetwork v2.6.4;

2. rédaction d’une procédure d’installation de la suite de logiciels nécessaires au fonctionnement de GeoNetwork.

Importation de métadonnées dans GeoNetwork

Introduction Le but de ce projet était de transférer les données géographiques, comme des cartes standardisées du ministère, vers un système qui sera facile d’accès. Le problème est que ces cartes, environ 1700 générés par un programme d’automatisation, ne comportent que peu de métadonnées pour les identifier, et les ajouter manuellement prendrait beaucoup de temps. Pour cette raison, il a fallu trouver une façon d’automatiser le plus possible le processus. Les métadonnées de GeoNetwork sont standardisées selon

30

des normes internationales décrites par ISO. Dans notre cas, nous avons utilisé une version modifiée du standard ISO19139 (http://www.iso.org/iso/catalogue_detail?csnumber=32557).

Méthodologie Toutes les données qui sont transférées à GeoNetwork sont accompagnées d’un fichier de format Extensible Markup Language (XML) qui représente la métadonnée du fichier, qu’il soit un fichier PDF qui contient une carte, ou un fichier SHP de forme pour usage dans un logiciel de SIG. Le fichier XML n’est qu’un fichier texte qui a une structure avec des balises, comme un fichier HTML pour les pages internet (figure 28). Contrairement à HTML, il n’y a pas de balises réservées et c’est le système qui va analyser les balises qui va les gérer. <note> <destinataire>Bob</destinataire> <expediteur>Sophie</expediteur> <titre>Bonjour</titre> <texte>Comment ça va?</texte> </note> Figure 28: Exemple de XML En sachant que les données sont emmagasinées dans les fichiers XML, il fallait trouver une façon de les modifier en série, pour les donner des valeurs par défaut qui seraient communes à un groupe de cartes. Par exemple, si toutes les cartes à traiter sont des cartes qui portent sur les municipalités, alors les métadonnées de ces fichiers devraient contenir le mot « municipalité ». Le langage de script Python et un modèle dans Model Builder ont été utilisés pour faire ceci. Vous trouverez le code et le modèle en annexe. La première étape était de connaître les champs qui sont obligatoires, selon les normes ISO19139. Pour ce faire, dans ArcMap, j’ai utilisé une donnée test dans laquelle j’ai modifié des champs avec le préfixe « XXX – » suivi du champ auquel il se rapporte (figure 29); le même processus s’est fait dans GeoNetwork pour des fins de comparaison (figure 30).

31

Figure 29: Identification des champs obligatoires d’ISO19139 dans ArcMap

Figure 30: Identification des champs obligatoires d'ISO19139 dans GeoNetwork

32

Ensuite, il faut ouvrir les fichiers XML pour analyse dans un logiciel de traitement de texte (figures 31 et 32).

Figure 31: Fichier XML ArcMap

Figure 32: Fichier XML GeoNetwork Une fois que les balises à modifier ont été identifiées, il fallait trouver une façon par Python d’analyser et de modifier ces balises. Heureusement, il existe quelques

33

modules externes que l’on peut utiliser pour analyser les fichiers XML; celui que j’ai utilisé, car il est inclus par défaut dans Python, est « ElementTree » (documentation : http://effbot.org/zone/element-index.htm). Avec ce module, j’ai pu modifier les balises obligatoires d’ISO19139. La métadonnée décrit la carte de série et GeoNetwork offre un outil d’importation en série de ces données, mais il n’existe pas de façon d’importer les cartes et les métadonnées qui s’y rattachent d’un coup. Bien que pas obligatoires, ces cartes peuvent être accompagnées de vignettes qui donne un aperçu de la carte elle-même et il n’existe encore une fois pas de façon de générer ces vignettes dans GeoNetwork. Pour pallier à ces problèmes, il fallait analyser la structure même des dossiers dans GeoNetwork. Suite à des tests, j’ai trouvé que les fichiers (carte et vignettes) sont classés selon le numéro d’identifiant de la métadonnée (en groupe de 100), puis dans deux dossiers distincts : « private » pour les cartes et « public » pour les vignettes (où l’on peut trouver une grande vignette et une petite vignette identifiée par le suffixe « _s ») (figure 33). Heureusement, il n’y a pas de vérification de dossier qui est effectué lorsque GeoNetwork fonctionne, donc on peut créer des dossiers d’avance qui contiennent les cartes et les vignettes, puis les ajouter au dossier de GeoNetwork, en connaissant le numéro d’identifiant que la métadonnée aura, suite à son importation.

Figure 33: Structure du dossier GeoNetwork Afin de créer les vignettes, un module externe a dû être utilisé : PythonMagick (http://www.imagemagick.org/script/index.php). Contrairement à d’autres modules, la documentation pour ce module n’était pas très utile et les forums de discussion ont été très efficaces. Suite à ceci, à partir d’un PDF, on génère deux vignettes (figure 35).

34

Figure 34: Script avec module PythonMagick pour générer les vignettes

Figure 35: Résultat du script pour générer les vignettes Pour caractériser davantage les métadonnées, on a cherché à extraire des fichiers qui sont traités, le plus grand nombre d’information possible. Par exemple, on peut se servir d’une partie du nom du fichier pour en faire un mot-clé, ou de l’information contenue dans le fichier PDF pour définir l’échelle. Pour extraire l’information du PDF, il faut utiliser un autre module : pyPDF (http://pybrary.net/pyPdf/). Les PDF étant des formats plus difficiles à analyser que les fichiers texte, on ne peut extraire tant d’information de cette façon. En fait, juste le fait d’extraire l’échelle est plus compliqué que l’on peut le penser, car le script détectait l’espace présent entre les chiffres, par exemple, l’espace entre « 50 » et « 000 » dans « 50 000 », comme étant le signe de l’Euro « € ». Ceci est dû à une différence d’encodage entre le fichier PDF et Python 2.7 et ce

35

n’est pas la première fois que j’ai été confronté à ce genre de problème durant le stage; j’en dirais davantage dans la section « Discussion » (on peut aussi voir des avertissements d’encodage dans la figure 34).

Figure 36: Les éléments nécessaires sont présents pour l'importation Pour obtenir le dernier numéro utilisé par le système GeoNetwork, il ne faut que créer une métadonnée test dans le système et noter le chiffre généré par le système. Dans cet exemple, le dernier identifiant est le 266.

Figure 37: Comment trouver le dernier identifiant attribué par GeoNetwork Une fois que nous avons les éléments nécessaires : la métadonnée en format XML, la carte en format PDF, les vignettes en format PNG et le dernier identifiant assigné par GeoNetwork (pour imiter la structure des dossiers de GeoNetwork) nous pouvons lancer le script final pour préparer les données pour l’importation (figure 38).

36

Figure 38: Traitement et son résultat Une fois que les fichiers ont été modifiés, que les vignettes ont créé et qu’ils ont été déplacés dans leurs dossiers respectifs, il ne reste qu’à les déplacer dans le dossier de GeoNetwork et à utiliser l’outil d’importation de métadonnées de GeoNetwork. L’ensemble des données sera par la suite affiché dans GeoNetwork (figure 39).

Figure 39: Résultat final dans GeoNetwork

37

Limitations Compte tenu de la structure du script, il est obligatoire d’avoir le même nom de fichier (sauf pour l’extension) pour chaque groupe de données (XML, PDF et PNG) pour que le tout soit déplacé correctement. Ceci est parce que c’est la façon la plus simple d’avoir l’information nécessaire pour faire les liens vers les fichiers et les vignettes. Il faut aussi avoir un fichier PDF afin de générer les PNG. Dans le futur, d’autres types de données, comme des images TIFF pourront être importées dans le système, mais il faudra modifier le script, ou en créer un autre, pour arriver à ce but.

Conclusion Comme premier essai, nous avons obtenu des résultats très satisfaisants pour ce projet, ce qui a mené à la deuxième phase du processus : l’élaboration d’une procédure d’installation des logiciels nécessaires au fonctionnement de GeoNetwork sur un nouveau poste.

Procédure d’installation de GeoNetwork Pour conformer à une politique de continuation de projets, au cas où un employé (ou un stagiaire) quitterait, il est nécessaire de documenter les étapes pour installer un logiciel quelconque. Ce document, nommé le P-720 au MTQ, est un document qui contient une procédure, étape par étape, pour l’installation d’un logiciel; brièvement, c’est une image qui est accompagnée d’une description textuelle (figure 40) et mon travail était de faire un brouillon qui servira à faire le document officiel. Je ne reproduirais pas le document ici, mais je vous dicterais les grandes lignes.

Figure 40: Extrait de la procédure d'installation La suite de logiciels (tous des logiciels libres) nécessaires au fonctionnement de GeoNetwork sont :

38

Java (http://java.com/en/download/index.jsp): il faut au minimum la version 1.6 pour que les logiciels ci-dessous fonctionnent. La version 1.6 de Java a été utilisée pour rédiger la procédure;

GeoNetwork (http://geonetwork-opensource.org/) : système de gestion de métadonnées. La version la plus récente, si possible. Contrairement à la version utilisée pour les tests d’importation (version 2.6.4), nous avons utilisé la version 2.8, qui est la plus stable que l’on a trouvée;

GeoServer (http://geoserver.org): système de gestion de données géospatiale qui va être intégré dans GeoNetwork. Il faut télécharger la version en format Web Archive (extension *.war). Nous avons utilisé la version 2.3.4;

PostgreSQL (http://www.postgresql.org/): système de base de données qui va stocker les métadonnées de GeoNetwork. La version qui est utilisée pour la procédure est la 9.2.4.1;

PostGIS (http://postgis.net/): extension spatiale de PostgreSQL pour entreposer les données spatiales. Vous pouvez télécharger cette extension sur le site internet, ou vous pouvez l’installer via une option à la fin de l’installation de PostgreSQL (voir ci-dessous). La version 2.0.3 a été utilisée;

Tomcat (http://tomcat.apache.org/): serveur web qui sert à rouler le tout. La version 7.0.42 a été utilisée.

Pour chacun des logiciels, des captures d’écrans ont été prises et un court texte les a accompagnés. Il y avait aussi une section configuration, là où applicable. La plus grande difficulté de ce volet du projet était le fait que c’était une première pour moi et dans le ministère. Il fallait aussi configurer ces quatre logiciels pour qu’ils communiquent ensemble et pour que le tout fonctionne sans problème. Vous pouvez trouver la procédure en annexe.

Autres projets mineurs Entre les deux gros projets mentionnés ci-haut, j’ai eu l’occasion de travailler sur des projets mineurs. Même si la portée de ces projets n’était pas très grande (bien qu’ils auraient pu l’être), ils m’ont permis de me refamiliariser avec certains aspects des SIG que je n’avais pas abordés depuis quelque temps.

Véhicules hors routes (VHR) et vérification de la topologie Le but principal de ce projet était de combiner les segments de routes pour les motoneiges et les quads venant de plusieurs sources (municipalités et clubs de VHR). Comme le travail n’était pas centralisé, les données de travail n’étaient pas uniformes sur le plan attributaire : les colonnes n’étaient pas les mêmes pour les diverses couches et il arrivait même que certains champs eussent changé de type ou même que la taille d’un champ soit différente. Par exemple : le champ ID, qui est normalement un champ numérique, a été changé en un champ textuel pour accommoder un identifiant composé qui comprenait un tiret. Pour pallier ces problèmes, une nouvelle table a été

39

créée, qui comprenait des champs avec une taille plus grande pour certains champs, et certains champs numériques ont été convertis en champs textuels (figure 41). Lors de cette étape, j’ai appris certaines choses sur la structure des données, notamment qu’il y a une différence entre la structure d’un fichier SHP et celui d’une géodatabase : lorsqu’un champ est créé, sa taille ne peut être modifié en aucun cas, compte tenu de la structure des bases de données et le nom d’un champ peut être modifié, mais seulement lorsque la couche se trouve dans une géodatabase.

Figure 41: Interface de l'outil "Combiner"

40

Figure 42: Résultat final de la combinaison des couches de motoneiges Une fois les couches combinées (figure 42), la seconde étape était de voir s’il y avait des problèmes topologiques, car le but ultime du projet est d’avoir un tracé qui pourrait être utilisé avec des applications de routage. À cette échelle, tout semble être correct, mais lorsque l’on fait rouler l’outil « Topology » d’ArcMap (disponible seulement avec les licences d’ArcEditor et d’ArcInfo), on trouve beaucoup d’erreurs. L’outil « Topology » d’ArcMap est très puissant et permet de déceler des erreurs de topologiques pour une couche donnée, selon le type de géométrie présent et selon la règle choisie (il y en a plusieurs dizaines). Dans notre cas, on cherchait à trouver le nombre de nœuds pendants (figure 43).

Figure 43: Règle topologique "Ne doivent pas avoir de nœuds pendants"

41

Une fois que ceci est fait, l’application génère un rapport et un fichier que l’on peut afficher pour voir les erreurs topologiques (figure 44); pour le fichier des motoneiges, on compte 1 485 erreurs. Certaines erreurs sont légitimes, comme lorsque c’est la fin réelle d’une route, mais il y a aussi des erreurs de numérisation (figure 45).

Figure 44: Résultat de l'outil « Topology »

Figure 45: Erreur de numérisation

42

Il est difficile de trouver une solution universelle pour ces erreurs topologiques : une solution serait d’attacher automatiquement un segment à un autre si celui-ci est décalé de quelques mètres (comme dans la figure 45). Par contre, peut-être que ce décalage reflète vraiment la réalité du terrain et que de faire ceci fausserait les données. Pour l’instant, les données ont été présentées aux personnes concernées pour voir quelles pistes seraient choisies.

Test de performance d’un projet du système d'Aide à la Décision en Sécurité Routière (SADSR) J’ai aussi eu la chance de travailler conjointement avec les bureaux du MTQ à Québec sur un test de performance pour un système de catalogage des données du SADSR. Brièvement, le MTQ possède une base de données qui catalogue tout les accidents routiers qui surviennent sur leur réseau depuis plusieurs années. C’était un projet très simple : cochez des couches et noter le temps en seconde que ça prend pour afficher les données, et ce, à une échelle fixe et à l’échelle de la province (figure 46). Malheureusement, ma participation à ce projet ne s’est limitée qu’à ceci.

Figure 46: Tableau de temps de chargement

Réflexions personnelles sur le stage Les objectifs qui ont été posés en début de stage ont été accomplis : les résultats du projet d’automatisation d’identification de SNN ont donné des résultats satisfaisants pour la BGR et, en testant cette méthode sur la base de données AQ, on a pu voir que la méthode BGR ne peut être appliquée pour AQ. Le travail réalisé pour le projet de GeoNetwork a aussi donné de bons résultats : une méthode d’importation massive de métadonnées a pu être élaborée et j’ai pu en apprendre davantage sur les détails techniques de GeoNetwork ainsi que sur le monde des logiciels libres, un monde que je ne connaissais pas beaucoup. Comme mentionnées précédemment, les tâches qui m’ont été assignées concordaient avec mon profil académique et professionnel. Ma formation au CÉGEP en informatique de gestion m’a permis de savoir comment programmer et documenter un projet, et mon expérience à mon ancien emploi en géomarketing m’a plongé dans le domaine de la géomatique. De plus, à mon ancien emploi, j’ai réalisé quelques projets de programmation pour les SIG (MapInfo), alors j’étais avantagé sur ce plan. Bien sûr, les

43

connaissances que j’ai acquises durant le DESS m’ont permis d’être très bien préparé pour ce stage. Le mandat de stage stipulait que j’allais travailler avec les gens du bureau de la Capitale-Nationale sur un projet, mais ils n’ont pas poursuivi les démarches, alors je n’ai travaillé que sur le court projet de test de performance de système SADSR. C’est malheureux, car je n’ai jamais travaillé sur un projet avec une autre équipe qui ne se trouve pas dans le même bâtiment. Par contre, ceci m’a montré que pas tous les plans sont réalisés et qu’il faut savoir s’adapter à ces changements. Un autre exemple d’adaptation s’est présenté lorsque j’ai commencé mon premier projet (automatisation SNN) : mon premier script était en VBScript, langage avec lequel je suis familier depuis ma technique en informatique et que j’ai aussi utilisé un peu à mon ancien emploi, mais j’ai dû changer pour un autre langage de script (Python) lorsque je me suis aperçu que VBScript n’avait pas les capacités de faire ce que je voulais. J’ai donc eu à apprendre à programmer en Python lors de mon stage, et je suis très content d’avoir eu la chance de faire ceci. C’est facile de se dire que l’on va apprendre un nouveau langage de programmation durant nos temps morts, mais le fait d’avoir un but concret donne de la motivation. Bien sûr, l’apprentissage de Python ne fut pas sans problèmes : j’ai eu beaucoup de problèmes d’encodage que j’ai dû parfois régler de façon originale, mais j’en ai appris beaucoup sur le sujet. J’en ai aussi appris sur la politique de contrôle de version : la version Python 3.0 est disponible depuis quelque temps, mais ArcMap utilise encore la version 2.7 et ne pense pas changer pour la nouvelle version de si tôt compte tenu du nombre d’applications qui roule sur 2.7. Si ArcMap utilisait la version 3.0, j’aurais eu beaucoup moins de maux de tête à jouer avec l’encodage, car l’encodage par défaut de 2.7 est ASCII, qui est limitée à 128 caractères, tandis que l’encodage par défaut de Python 3.0 est UTF-8, qui peut avoir un maximum de 1 112 064 caractères. Mon expérience en automatisation se limitait à l’automatisation dans un programme ou un script que j’avais créé de toute pièce, mais dans ArcMap, il existe l’outil Model Builder, qui permet de créer des modèles pour des fins d’automatisation. Au courant de ma formation universitaire en géographie à l’Université de Montréal et au DESS à l’UQAM, nous avons utilisé un peu Model Builder, mais pas autant que je l’ai utilisé au stage. Mon premier modèle était très fonctionnel, mais il était énorme et qualifié de « monstre » à cause de sa longueur qui en intimidait plus qu’un au bureau (figure 47). Ce modèle a par la suite été compartimenté : chaque branche est devenue un modèle et un modèle général les appelait; ces deux modèles sont disponibles en annexe.

Figure 47: Première tentative de modèle pour projet SNN

44

Un dernier point, plus subtil et moins technique : la politique de bureau. Mon dernier emploi était pour une firme privée, tandis que mon stage s’est passé au sein d’un ministère. La première différence que j’ai pu observer concerne la restriction informatique : au privé, si j’avais besoin d’installer un logiciel quelconque, je n’avais qu’à demander à mon superviseur situé à 30 secondes de mon bureau et j’aurais l’autorisation quelques moments après; au gouvernement, il faut suivre la procédure et s’informer auprès de plusieurs personnes avant de pouvoir procéder. Heureusement, nous avions une technicienne dans les environs, alors le temps de traitement était similaire qu’au privé, mais la distinction publique-privée était là quand même. Un autre point où j’ai dû m’adapter est la politique linguistique : les logiciels avec lesquels j’ai travaillé au ministère étaient tous en français, contrairement à ceux que j’ai utilisés au privé et à l’école. Ceci est dû à la politique linguistique énoncée par le gouvernement. Il y a eu un temps d’adaptation aux termes techniques, mais le problème est que la majorité de la documentation en ligne est en anglais et non en français et cela m’a causé quelques problèmes (même les forums de discussion francophones utilisaient la version anglaise des logiciels).

Conclusion Le stage au MTQ a permis de développer mes talents et habiletés en programmation, en informatique et en géomatique et pour cela, je me compte très chanceux d’avoir pu obtenir un stage aussi technique que celui-ci. Bien que ça aurait pu être intéressant, je n’aurais pas été content d’avoir un stage où j’aurais passé 15 semaines à géoréférencer des éléments sur une carte, mais j’aurais pu utiliser mes talents à un moindre degré. Justement, on a tellement été satisfait de mon travail ici, qu’on m’a donné un poste à temps partiel juste qu’à Noel. Le contexte du stage était très pertinent par rapport à la réalité du marché du travail et des tendances technologiques actuelles. Mon premier projet, qui consistait à trouver des identifiants à des segments de routes, avait une utilité réelle : l’identifiant pourrait servir à des services d’urgence ou d’entretien. Concernant le deuxième projet : on s’aperçoit que les gouvernements s’ouvrent de plus en plus avec divers projets et, bien que ce soit encore un projet pilote pour lequel public est le MTQ, l’implantation de GeoNetwork montre une volonté d’ouverture éventuelle. Lorsqu’une relation réelle et concrète avec le terrain peut se faire, les projets sur lesquels on travaille sont plus motivants et qui a-t’il de plus concret que les réseaux routiers et les transports qui les utilisent?

45

Index des annexes La section qui suit ne contient pas les items en annexe, mais un index de ceux-ci, compte tenu de la taille que représentent les scripts Python, les modèles et autres items.

Projet SNN : o 01_SNN_ModeleInitial : vue du premier modèle réalisé pour le projet

SNN dans Model Builder. À titre indicatif seulement, car le modèle a par la suite été compartimenté;

o 02_SNN_Modele_FinalGeneral : vue du modèle général, qui appelle d’autres modèles;

o 03_SNN_Modele_Entree : modèle pour les segments d’entrée; o 04_SNN_Modele_Halte : modèle pour les segments d’halte routière; o 05_SNN_Modele_Pesee : modèle pour les segments de poste de pesée; o 06_SNN_Modele_Sortie : modèle pour les segments de sortie; o 07_SNN_Modele_Stationnement : modèle pour les segments de

stationnement; o 08_SNN_Modele_VirageU : modèle pour les segments de virage en U; o 09_SNN_Modele_AQ : modèle pour le traitement SNN sur les segments

d’Adresses Québec; o 10_SNN_Code_Entree : code pour traiter les segments d’entrée; o 11_SNN_Code_VirageU : code pour traiter les segments de virage en U; o 12_SNN_Code_Halte : code pour traiter les segments d’halte routière; o 13_SNN_Code_Pesee : code pour traiter les segments de poste de pesée; o 14_SNN_Code_Sortie : code pour traiter les segments de sortie; o 15_SNN_Code_Stationnement : code pour traiter les segments de

stationnement; o 16_SNN_PeuplerTypeES : code utilisé par les segments d’entrée et de

sortie pour distinguer les deux; o 17_SNN_Code_AQ : code utilisé pour traiter les segments d’Adresses

Québec. Projet GeoNetwork :

o 18_GeoNetwork_Modele : modèle d’exportation de métadonnées dans ArcMap;

o 19_GeoNetwork_Code_QueryFix : petit script utilisé par le modèle pour corriger les requêtes;

o 20_GeoNetwork_Code_Vignette : code pour la création de vignettes à partir de PDF;

o 21_GeoNetwork_Code_Metadonnees : code de modification de métadonnées et de préparation pour importation dans GeoNetwork;

o 22_GeoNetwork_ProcedureInstallation : brouillon de procédure d’installation de la suite de logiciel pour GeoNetwork.

46

Bibliographie Hamoudi, Riad. 2009. « Nomenclature des segments non nommés (SNN) de la base géographique routière (BGR) du ministère des Transports : Phase 1 : Accès et sorties d’autoroute ». Rapport de stage, Montréal, Université du Québec à Montréal. Ministère des Transports du Québec (MTQ). 2013. « Déclaration de services aux citoyens ». En ligne. < http://www.mtq.gouv.qc.ca/portal/page/portal/ministere/ministere/organisation/declaratio n_services_citoyens>. Consulté le 7 août 2013. Québec. Ministère des Ressources naturelles et de la Faune (MRNF). 2011. Adresses Québec : Guide de l’utilisateur (version 2.11). Québec : Ministère des Ressources naturelles et de la Faune. Québec. Ministère des Transports du Québec (MTQ). 2002. Guide de la codification et du mesurage du réseau routier. Québec : Ministère des Transports du Québec. Québec. Ministère des Transports du Québec (MTQ). 2009. Les réseaux de transport terrestre au Québec. Rédigé par le secteur de la géomatique du MTQ. Québec : Ministère des Transports du Québec. Québec. Ministère des Transports du Québec (MTQ). 1993. Partage des responsabilités entre le gouvernement et les municipalités. En ligne. < http://www.mtq.gouv.qc.ca/portal/page/portal/78926983C0C916B6E04400144F0 104BD>. Consulté le 7 août 2013. Québec. Ministère des Transports du Québec (MTQ). 2008. Réseau routier supérieur du Québec : Classification fonctionnelle. Rédigé par Gaétan Poulin. Québec : Ministère des Transports du Québec.