Embed Size (px)
Citation preview
Stage en milieu de travail
Ville de Rimouski :
Vers des données ouvertes
Travail présenté à.
M. Yves Baudouin
Dans le cadre du cours
Activité de Stage 1 et 2
Geo7930 et Geo7931
Par
Jean-Philippe Lauzon
LAUJ26068306
Université du Québec à Montréal
Le 18 janvier 2016
Remerciement
Je remercie tout d’abord M. Alain Michaud pour m’avoir accueilli au sein de son
équipe du département des Technologies de l’information. Je remercie particulièrement
M. Gilbert Cassista, coordonnateur en géomatique qui m’a pris en charge durant
l’ensemble de mon Stage. M. Cassista, de par sa grande maitrise des données de la ville
de Rimouski et de sa connaissance des SIG à sus m’aiguiller sur la bonne voie. Je salue
aussi Jean-Sébastien Caron, technicien en géomatique qui m’a beaucoup aidé à
comprendre les données de la ville et leurs origines.
Table des matières
1. Mise en contexte
1.1 Présentation de l’organisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problématique globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Mandats du stage
1.3.1 Mandat principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.2 Mandat secondaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Objectif du stage
1.4.1 Objectifs du mandat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Objectifs personnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Échéancier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Méthodologie
2.1 Méthodologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Analyse du SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Transition vers ArcGIS server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3 Mise à niveau des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.4 Topologie des rues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.5 Cartographie pour le plan directeur des parcs et espaces verts. . . . . . . . .13
2.1.6 Carte web : les parcs et loisirs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.7 Carte web : Gestion écologique et récupération . . . . . . . . . . . . . . . . . . . . 17
2.1.8 Carte web : 1946 /2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.9 Transport en commun GTFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.10 Focus : déneigement des rues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.11 Tronçon d’égout à inspecté. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.12 Calendrier des collectes de déchet pour mes services municipaux . . . . 22
2.1.13 Carrière sablière. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.14 petits projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Résultats et discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3. Analyse critique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4. Développement futur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Bibliographie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Annexe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1
1. Mise en contexte
1.1 Présentation de l’organisme
La ville de Rimouski possède une structure organisationnelle semblable à
plusieurs autres municipalités du Québec. Le conseil municipal, composé du maire et de
11 conseiller(ère)s choisit les orientations des projets de la ville et prend les décisions
finales. La direction générale fait le pont avec le conseil municipal et les différents
services et gère la faisabilité des projets. Les projets sont ensuite mis sur pied par les
différents services, en collaboration les uns avec les autres ou non, selon la nature du
projet. Notons que les projets peuvent provenir d’une demande d’un citoyen comme
d’un employé municipal, mais doivent être approuvés par le conseil municipal.
Les neuf services sont représentés dans le schéma 1 de la structure
organisationnelle de la ville, mais ne seront pas détaillés dans ce rapport. Nous nous
intéresserons seulement au service des technologies de l’information puisque le
département de la géomatique est une sous-division de ce service.
Schéma 1: Organigramme de la ville de Rimouski
2
Le service des technologies de l’information est un département principalement
au service des autres départements. Il s’occupe de gérer et d’entretenir les équipements
électroniques (ordinateurs, téléphones, tablettes, etc.) utilisés par l’ensemble des
employés municipaux. Le service s’occupe aussi de fournir les différents logiciels utilisés
par la ville et de mettre sur pied des outils de formation pour ces derniers. La création et
les mises à jour du site web de la ville sont prises en charge par ce service ainsi que tout
ce qui touche à l’intranet et autre outil de communication interne.
Le département de géomatique s’occupe des cartes web pour rendre accessible
aux citoyens les informations que possède la ville. Il s’occupe aussi de fournir les cartes
nécessaires aux autres services. Finalement, ce département s’occupe de la base de
donnée spatiale en créant de nouvelles données, en gardant à jours les données
existantes et en consolidant la structure de cette base de données afin de faciliter son
analyse. Pendant la duré du stage, la plupart des services de la municipalité ont fait
appel au département de géomatique, mais le service de génie est, de loin, celui qui
l’utilise le plus fréquemment. Ce service comporte deux employés; M. Gilbert Cassista,
coordonnateur en géomatique et M. Jean-Sébastien Caron, technicien en géomatique.
1.2 Problématique globale
Depuis les années 80, avec la démocratisation de l’informatique, nous avons vu
apparaitre une tendance vers l’informatisation de la gestion municipale. Cette
informatisation a amené le concept de ville intelligente (Dupuy G., 1993, p.94). À
l’origine, ce concept abordait l’idée d’un traitement de l’information plus rapide, unifié
avec la captation et le traitement de données en temps réel. Ce phénomène permet de
mieux connaitre la ville et de pouvoir prendre des décisions plus informer et plus
rapidement et donc avoir une ville «intelligente» (Dupuy G., 1993, p. 102).
3
Avec le temps, nous avons vu une complexification du concept de ville
intelligente. Selon le modèle de Giffinger, six aspects composeraient la ville intelligente
avec, pour chacun, une liste de critères à remplir selon divers indicateurs. Les six aspects
sont : une économie intelligente, une mobilité intelligente, un environnement
intelligent, des citoyens intelligents, un habitat intelligent et une gouvernance
intelligente. Bien que la municipalité ait un rôle à jouer pour chacun de ces aspects, le
stage s’est déroulé dans le but d’œuvrer sur celui de la gouvernance. Les trois critères
de cet aspect sont la participation dans les prises de décision, offrir des services publics
et sociaux et être transparent.
Ayant choisi d’aller vers le concept de ville intelligente, la ville de Rimouski
entreprend diverses mesures pour atteindre ce but. L’un de ces moyens consiste à
rendre les données de la municipalité disponibles au public. Pour y parvenir, le
département de géomatique a dû réorganiser ses bases de données et développer des
cartes interactives pour les rendre intelligibles au public. Afin de les aider dans cette
tâche, la ville a fait appel à un stagiaire.
. La ville utilisait depuis un certain temps ArcGIS Online, cependant, ce dernier
n’offre pas l’option de contrôler quelles données sont téléchargeable ou non par les
utilisateurs. Le logiciel choisi afin de palier à ce problème est ArcGIS server. Rimouski
souhaite offrir aux citoyens les données qu’elle possède, mais ne peut pas rendre
téléchargeables les données qui ne lui appartiennent pas. Nous donnons comme
exemple ici les données cadastrales qui appartiennent au gouvernement du Québec.
ArcGIS server permet donc de gérer quelles couches de données sont téléchargeable et
quelles ne le sont pas.
4
1.3 Mandats du stage
1.3.1 Mandat principal
Le principal mandat pour ce stage était d’aider le département de géomatique
avec le projet de données ouvertes de la ville de Rimouski. Pour accomplir ce travail,
plusieurs sous-tâches étaient planifiées. Le mandat consistait donc à analyser le SIG de
la ville de Rimouski et étudier en détail le fonctionnement d’ArcGIS server afin de
planifier le transfert des données. Par la même occasion, la ville voulait restructurer sa
base de données afin d’être compatible avec G.O. cité, un SIG développé par une
association de municipalités du Québec afin de fournir des outils de gestion de données
spatiales municipales. Finalement, des domaines devaient être ajoutés aux données afin
de standardiser l’écriture et des métadonnées composées pour faciliter la
compréhension des données.
Dans un deuxième temps, le mandat consistait à utiliser la nouvelle structure de
données afin de publier ces dernières. Les tâches touchaient donc à la création de cartes
interactives pour le site internet de la ville et d’une restructuration des données de
transport en commun pour être compatibles avec Google.
1.3.2 Mandat secondaire
Le mandat secondaire consistait à travailler sur les projets de tous les jours du
département de géomatique. Ces projets consistaient principalement à fournir un
service de cartographie aux autres départements. Dans une moindre mesure, la mise à
jour des données faisait partie des tâches. Ce mandat secondaire était donc d’assister
M. Carron, le technicien en géomatique, dans ses tâches.
5
1.4 Objectif du stage
1.4.1 Objectifs du mandat
Le but recherché par ce stage est de doter la ville de Rimouski d’un outil servant
à contrôler efficacement le niveau d’accessibilité des données. Cet outil lui permettra de
diffuser ses données en les plaçant dans leur contexte qui, parfois, est composé de
données n’appartenant pas à la ville. En diffusant ses données, la ville répond à certains
critères pour la qualifier de «ville intelligente». Les cartes web développées donneront,
aux citoyens, un accès rapide aux informations concernant le territoire et les différents
services offerts par la ville.
En arrière-plan, un des objectifs de l’analyse du SIG et des métadonnées est de
documenter les données, leurs origines, leurs raisons d’être. Ceci dans le but d’en
assurer la pérennité et l’usage par d’autres employés de la ville.
1.4.2 Objectifs personnels
Pour ce stage, quelques objectifs personnels ont été définit. Tout d’abord, il est
intéressant de comprendre comment utiliser les connaissances académiques des SIG
dans une situation réelle. Ensuite, aillant un intérêt marqué pour la gestion municipale,
un des buts fixer correspondait à se familiariser avec le fonctionnement interne d’une
ville. Le dernier objectifs consistait à observer les directions que prennent les
municipalités et la place de la géomatique dans le concept de ville intelligente.
6
1.5 Échéancier
Dans le «protocole d’entente pour un stage en milieu de travail», un échéancier
général avait été établi :
1. Analyse du SIG en place (juillet 2015)
2. Mise en place des correctifs et amélioration au SIG (août – octobre 2015)
3. Participation au projet de données ouvertes (août – décembre 2015)
4. Analyse spatiale et cartographie pour divers projets (juillet – décembre 2015)
5. Mise à jour et création de couches d’informations géographiques selon les
besoins (juillet – décembre 2015)
Notons ici que seuls les points 1 et 2 ont une date de fin précédant la fin du
stage. L’échéancier fut donc aisément respecté à une seule exception. Les
métadonnées, que nous classons dans le point 2, étaient composées à temps perdu,
reléguées à une tâche secondaire, et ont été finalisées durant la dernière semaine de
stage.
Cet échéancier reflète mal l’ampleur des tâches accomplies durant ces six mois
de stage. De plus, le projet principal s’est déroulé sans grand problème et donc plus
rapidement que prévu. Ceci a permis d’ajouter des projets imprévus à la liste de tâche
et donc sans échéancier prévu.
7
2. Méthodologie
2.1 Méthodologies utilisées
Dans cette section, nous aborderons les différents projets réalisés. Pour chacun
d’eux, il y aura une description des objectifs spécifiques, des méthodes utilisées, des
problèmes rencontrés et de leurs solutions
2.1.1 Analyse du SIG
L’analyse du SIG se sépare en deux grandes actions, soit réaliser un inventaire
des données et construire un schéma relationnel expliquant l’origine (quel logiciel est
utilisé pour générer les données) et la fonction des données (comment ces données
sont utilisées, diffusés). Pour chacune de ces actions, plusieurs éléments ont dû être pris
en compte.
L’inventaire des données a été effectué manuellement. Chacun des champs de
chacune des couches a été inséré dans un tableau. Plus tard lors du stage, un « script
python » fut développé pour générer automatiquement ce tableau; le script se trouve à
l’annexe 1. Les raisons justifiant la création manuelle du tableau sont les suivantes : cet
exercice permet de se familiariser avec la base de données et de connaître plus
rapidement où se trouve l’information. De plus, durant cet inventaire, il fut possible de
faire un premier repérage pour consolider la base de données. Ce repérage s’est
effectué en six points :
Trouver les informations en double
Trouver les champs avec un domaine déjà d’associé
Trouver les champs qui pourraient bénéficier d’un domaine
Trouver les couches pouvant être fusionnées
Trouver les couches pouvant bénéficier d’un sous-type
Trouver les couches pouvant avoir un «relationship class»
8
Il fut demandé par la ville de produire un schéma relationnel des données. Ce
schéma devait représenter les chemins que prennent les données, de leurs origines à
leurs publications. Cette étape du projet fût difficile à réaliser et qu’en partie complétée,
car deux problèmes ont été rencontrés.
Les problèmes consistaient à des difficultés d’accès à l‘information nécessaire
pour effectuer la tâche demandé. Ces renseignements se trouvaient dans des logiciels
aillant un nombre limité de License et donc non accessible. Aussi, l’origine de plusieurs
données n’étaient connut que des personnes les aillant importées. Il fut jugé que le
temps consacré à expliquer les relations en détail serait le même que de les faire écrire
par les personnes possédant l’information.
En guise de solution, un gabarit a été créé sous forme de schéma. Il illustre les
différentes origines, les moyens possibles de les importer dans la base de données, il
explique comment ces données sont traitées et comment elles sont publiées. Ce gabarit
fut ensuite rempli par les personnes concernées.
Cette analyse du SIG aura permis de se familiariser à la base de données, de
créer des outils de planifications pour les tâches à suivre et de créer des documents
expliquant la base de données.
2.1.2 Transition vers ArcGIS server
Avant de commencer à planifier la transition des données sur ArcGIS server, une
compréhension plus poussée de ce logiciel était nécessaire. Pour ce faire, une recherche
fut réalisée sur ce logiciel, sur les possibilités qu’il offre. Ensuite, le manuel de formation
a été lu, formation que M. Cassista a suivie avec les gens d’ESRI. Cette formation a été
faite dans l’optique de bien comprendre les différentes fonctionnalités du logiciel pour
ainsi les adapter aux besoins de la ville.
9
Pour planifier la transition, la forme qu’allait prendre la structure des données
devait être défini. Cet objectif aurait pu être de garder la même structure, mais il fut
demandé de préparer la base de données en prévision d’aller vers G.O.Cité. Une
difficulté rencontrée ici est le peu d’information sur le fonctionnement de cette
application. Sur leur site web (http://www.gocite.ca/), il est indiqué qu’il s’agit de 3
modules ajoutés à ArcGIS pour aider les municipalités à standardiser et gérer leurs
données spatiales. Il est aussi indiqué que cette application gère 17 thématiques. Il fut
donc convenu, avec M. Cassista, d’utiliser 17 «feature dataset» correspondant aux
thématiques citées sur le site web de G.O.Cité. Les différentes couches furent réparties
dans les dataset qui leurs correspondaient le mieux.
Avec les objectifs clairement établis, le transfert des données débuta. Les
«features datasets» furent créés et une petite série de couches transférées. Les
fonctionnalités d’ArcGIS server concernant l’accessibilité aux données purent être
vérifiées. L’ensemble des données a ensuite été transféré sur le serveur. On effectua
plusieurs tests concernant les droits d’accès par différents utilisateurs. Des
modifications durent ensuite être apportées. Les principaux problèmes rencontrés
touchaient au «propriétaire» des données qui est l’utilisateur qui ajoute une couche à la
géodatabase. Ce propriétaire est le seul à pouvoir modifier la structure de la donnée
(ex : ajouter un champ). Un utilisateur fut créé afin d’être le seul propriétaire des
données et sont code d’accès distribué aux employés ayant l’autorisation de modifier la
structure des données.
Une fois les données transférées sur le serveur et les problèmes d’accessibilité
réglés, des essais furent effectués pour vérifier le bon déroulement des fonctionnalités
d’ArcGIS server vues lors de la formation. Trois documents ont été rédigés pour
expliquer la marche à suivre lors de l’utilisation d’ArcGIS server. Le premier concerne
l’importation de nouvelles donnée, le deuxième explique la fonction d’archivage des
données et le dernier explique l’outil «versionning».
10
Ce projet a permis de placer les données géographiques de la ville sur un serveur
web. Ceci constitue le premier pas, effectué lors du stage, vers le projet des données
ouvertes que vise la ville de Rimouski.
2.1.3 Mise à niveau des données
Lors de l’analyse du SIG de Rimouski, six points furent surveillés pour consolider
la base de données. Peu d’information se trouvait en double et les couches pouvant être
fusionnées et bénéficier d’un sous-type sont demeurées telles quelles. Pour chacune de
ces couches, M. Cassista avait une raison valable de les conserver. Pour ce qui est des
«relationship class», seule la couche des routes en fut équipée, nous reviendrons sur ce
au point 2.1.4.
Pour les domaines, l’opération s’est déroulée en deux étapes. La première étape
consistait à préparer les domaines alors que la deuxième consistait à les intégrer dans
les données. Pour les domaines déjà existants, la préparation consistait à repérer les
champs correspondants, mais qui n’étaient pas déjà associés. Ensuite, 45 domaines
furent créés.
La deuxième étape est plus complexe dû à une caractéristique d’ArcGIS; il est
impossible d’ajouter un domaine à un champ existant, le domaine doit être associé lors
de la création du champ. Pour réaliser l’ajout des domaines, un outil fut assemblé avec
«model builder». Puisqu’il n’est pas possible d’avoir 2 champs dans la même table ayant
le même nom, un champ temporaire devait être créé. Le modèle créait ce champ
temporaire, y copiait les données du champ désigné. Ce dernier était alors effacé. Un
autre champ était alors créé, avec le nom du champ effacé, mais avec le domaine
désigné d’associé. Les données du champ temporaire y étaient copiées et ce dernier
effacé. Puisque le but d’un domaine est de standardiser l’écriture des données d’un
champ, une inspection manuelle était faite pour vérifier l’intégrité des données.
11
Une autre étape de la mise à niveau des données consistait à la création de
métadonnées. Il fut décidé de se baser sur le même modèle que les métadonnées du
gouvernement du Québec soit une version modifier du «North american profile of ISO
19115 2003». Une description fut intégrée pour expliquer ce que la couche représente
et une description de chacun des champs fut faite.
La difficulté pour les métadonnées était de trouver la signification de certains
champs. Certaines fois, en étudiant les données du champ et son contexte, il était
possible de déduire ce que le champ représentait. D’autres fois, le nom du champ et de
la couche à laquelle il appartient était noté dans un tableau pour éventuellement
compléter le travail.
En incluant des métadonnées dans sa base de données, la ville de Rimouski
ouvre la porte vers une plus grande transparence. En plus de fournir les données qu’elle
possède au public, elle inclut une explication de ce qu’elles représentent, facilitant leurs
compréhensions.
2.1.4 Topologie des rues
Ce projet fut initié afin de corriger la topologie de la couche du réseau routier
dans le but de la préparer pour des analyses de réseau. Ceci consiste principalement à
s’assurer de la connectivité du réseau. Plus précisément à vérifier que les segments de
rues commencent et arrêtent précisément aux intersections. Afin d’effectuer cette
tâche rapidement, 3 règles topologiques furent créées avec ArcGIS;
pas de « dangle » (cul-de-sac)
pas de pseudo nœud (2 segments sans intersection)
ne se superpose pas à lui-même
12
Ces trois règles ont fait ressortir les erreurs recherchées, mais aussi des éléments
qui devaient rester, par exemple, un vrai cul-de-sac. Chacune des alertes fut donc
vérifiée à l’aide de la photographie aérienne datant de 2011 que la ville possède.
Par la suite, 5 informations furent réintégrées à la couche du réseau routier. Ces
informations se trouvaient en partie sur la couche d’origine du réseau routier (qui avait
été copié) en partie sur d’autres couches. Ces informations entraient en conflit avec la
structure des segments du réseau. Plus précisément, ces informations séparent les
segments à d’autres points qu’aux intersections. ces informations sont :
le nombre de voies,
la limite de vitesse,
le type de revêtement,
le propriétaire,
le responsable de l’entretien.
La première méthode suggérée pour réintégrer ces informations dans le réseau
routier consistait à utiliser des références linéaires. Cependant, cette méthode ne se
sert que des tables pour stocker les données. Puisque la ville désirait conserver un
support visuel indépendant pour chacune de ces informations, des couches ont été
créées pour chacune d’elles. Ensuite, des classes de relation furent conçues pour lier de
façon permanente ces couches à celle du réseau routier. De plus, une règle topologique
se vit ajoutée afin que chacune des 5 couches se superpose parfaitement sur celle du
réseau routier.
Ce projet était en lien avec l’objectif secondaire de ce stage, c'est-à-dire,
effectuer les tâches normales des géomaticiens. Il s’agit ici simplement d’affiner la
qualité d’une donnée afin de permettre de future analyse.
13
2.1.5 Cartographie pour le plan directeur des parcs et espaces verts
Ce projet fut réalisé en collaboration avec M. Françis Lagacé, Urbaniste
surnuméraire à la ville de Rimouski. M.Lagacé était chargé de rédiger le plan directeur
des parcs et espaces verts et a fait appel au département de géomatique afin d’obtenir
des cartes pour différentes parties de son travail.
Durant ce travail, une nouvelle couche des parcs fut créée avec les modifications
apportées par M. Lagacé. Ces modifications touchaient essentiellement la nomenclature
des types de parcs. Plusieurs informations existaient déjà dans la base de données, les
statistiques ont dû être importées de Statistique Canada et les rayons de desserte on
dût être créé. Une carte sans plus d’information que l’empreinte des parcs fut créer,
une autre avec le nom des parcs (carte 1). Notons ici que l’encadré contenant les
informations de la carte fût rédigé en suivant le gabarit fournis par la ville.
Carte 1 : Carte des parcs et espaces verts; Format original : 11X18
14
Par la suite, des cartes avec les différents rayons de desserte (400 mètres et 800 mètres)
de 2 types de parcs (parc de voisinage et parc de quartier) furent créées (carte 2).
Carte 2: Analye de la desserte en parcs de voisinage et en parc de quartier; Format original : A0
15
Pour son analyse, des cartes contenants des statistiques sur la population selon
différentes années furent créées. Plus spécifiquement, il y avait une carte avec la
densité de la population et la répartition d’âge (carte 3) ainsi qu’une avec le revenu
moyen.
Carte 3: Carte de la répartition d’âge et densité de la population au Km2 selon le recensement de 2011; Format
original : 11X18
Il s’agit ici d’un projet de cartographie en support à un projet plus grand. Les
cartes présentées ici sont le résultat final d’un travail de longue haleine. Certaines ont
dû être recommencées plusieurs fois suite à des changements de nomenclature.
16
2.1.6 Carte web : les parcs et loisirs
Durant le stage, trois cartes web interactives furent créées. La première
concernait les parcs et loisirs. Cette carte indique la location de tous les parcs et espaces
verts de la ville de Rimouski et permet de faire une recherche par équipement. La
longue liste d’équipement comporte autant le simple banc de parc que l’accès à une
piste cyclable, la présence d’un terrain de baseball ou encore l’autorisation d’avoir un
chien en laisse uniquement.
Pour réaliser cette carte, il fallut intégrer les données sur les équipements
disponibles dans la base de données de géomatique. Ces données provinrent de 3
sources distinctes soit les données fournies par M. Lagacé, celle de l’inventaire de la ville
et d’une vérification à l’aide de Google streetview. Un tableau fut assemblé avec un
champ par équipement et si le parc possède cet équipement, la case correspondant
avait un « V» (pour Vrai) d’inscrit. Ceci permis de programmer des requêtes SQL pour
trouver les parcs et espaces verts avec cet équipement.
Une première application web fut montée à l’aide d’un gabarit fournit par ESRI
sur son portail d’ArcGIS server. Bien que cette application soit fonctionnelle, elle ne
répondait pas à toutes les attentes de M. Michaud, directeur du service des T.I. En
réponse, M.Cassita fournit une application, demandant plus de programmation et qu’il
utilisait pour un autre projet de carte web. Cette application fournie une carte
comprenant des fonctionnalités plus intuitives et avec l’information affichée de façon
plus efficace. De plus, contrairement au premier essai, il y a l’option d’effectuer une
recherche multiple pour les équipements.
17
Pour les équipements, une série d’icônes était disponible dans l’application, mais
ne couvrait pas l’ensemble des besoins. Une recherche web pour trouver des icônes
dans un style similaire, sans droit d’auteur, compléta la liste. De plus, une photographie
par parcs fut sélectionnée parmi la collection prise par M. Lagacé.
2.1.7 Carte web : Gestion écologique et récupération
Cette carte web est basée sur le même principe de recherche que celle des parcs
et loisirs. Il s’agit toutefois de permettre aux citoyens de trouver rapidement l’endroit
où aller déposer des déchets récupérables, mais qui ne sont pas acceptés dans le bac de
recyclage. 64 produits sont listés dans un onglet et en le sélectionnant, la carte indique
les endroits qui reprennent ce produit. La liste comprend différents types de batterie,
les pots de peinture, les vieux électroménagers, etc.
Pour créer cette carte, l’information a dû être transférée d’une liste dans un
document Word à une couche de point dans ArcGIS. La table de cette couche fut
remplie de la même façon que celle des parcs et loisirs, c’est-à-dire qu’un produit
correspond à un champ. Un dernier champ permet d’inscrire la liste complète des
produits que l’endroit accepte. Dans cette liste, un code a été intégré entre chaque
élément afin que l’affichage web soit fait en liste verticale (une ligne, un produit).
L’application utilisée pour construire la carte correspond à celle choisie au premier essai
de la carte des parcs et loisirs.
2.1.8 Carte web : 1946 /2011
Une citoyenne qui étudie en architecture et qui cherchait des plans d’occupation
d’un secteur de la ville avant 1950 déclencha ce projet. Deux plans et un assemblage de
photographie aérienne de 1946 lui furent fournit. Ayant vu des cartes web produites par
18
d’autres villes du Québec, montrant une comparaison entre une vieille photographie
aérienne et une récente, M. Cassista décida de lancer ce projet.
102 photographies aériennes de 1946 furent numérisées. Sur chacune d’elle, une
vingtaine de points de contrôle furent inscrits afin de géoréférencer les photographies.
Parmi les formules proposées dans ArcGIS pour l’interpolation, le «Spline» donnait les
meilleurs résultats. Les photographies fusionnées en une seule matrice terminèrent le
travail.
La carte fut assemblée à l’aide de l’application «story telling» d’ESRI. Au moment
d’écrire ces lignes, il s’agit de la seule carte publiée sur le web. L’adresse est la suivante :
http://rimouski.maps.arcgis.com/apps/StorytellingSwipe/index.html?appid=971385fd1b
d2401ba33fdef8dc2ed7d5#map.
Les deux cartes web mentionnées plus haut (2.1.6 et 2.1.7) seront publiées au
début de l’année 2016 lors de la présentation de l’onglet «Ville intelligente» qui
s’ajoutera au site web de la ville.
Ces trois cartes web s’inscrivent dans le projet de données ouvertes. Il s’agit ici
d’un moyen de fournir aux citoyens des données sur la ville, et ce, de façon intelligible.
Pour les deux premières cartes, il aurait été possible de publier l’information sous forme
de tableau, cependant, cette méthode est fastidieuse pour l’utilisateur et ne fourni pas
de repère spatial. En créant une carte interactive, l’information peut être affichée de
façon claire et efficace, et dans son contexte spatial. Pour ce qui est de la troisième
carte web abordée dans ce travail, elle permet de transmettre une information
historique sur la ville qui aurait autrement dormi dans le coffre des plans de la ville.
19
2.1.9 Transport en commun GTFS
Google map est une application web couramment utilisée pour planifier des
itinéraires. Ces derniers peuvent être adaptés à différent moyen de transport. Pour ce
qui est des transports en commun, Google demande aux sociétés de transport en
commun de lui fournir les données en format GTFS (General Transit Feed Specification).
Ce format consiste en une série de tableaux en format .txt représentant différents
aspects du système de transport en commun et ces tableaux sont reliés entre eux (voir
graphique 1).
Graphique 1: schéma relationnel du format GTFS
Ce format comporte deux grandes familles de données; les données temporaires
et les données géographiques. En ce qui concerne les données temporaires, la société
de transport de Rimouski fournit sur sa page web les horaires pour chaque arrêt de
20
chacun des circuits. Le travail consistait donc à retranscrire ces données dans la bonne
table. Un problème rencontré ici repose sur la différence de précision entre le format
GTFS et l’horaire publié. Ce dernier est précis à la minute, ce qui permet à deux arrêts
consécutifs d’être prévus pour la même heure. Ceci génère un message d’erreur si laissé
tel quel dans le format GTFS qui demande d’être précis à la seconde. Pour y remédier,
un 30 secondes fut ajouté pour le deuxième arrêt partageant le même horaire.
Les données géographiques ont demandé plus de travail. Tout d’abord, les arrêts
étaient placés à titre indicatif seulement. Ils furent donc déplacés à leurs positions
exactes en utilisant la photographie aérienne comme référence. Ensuite, pour les
circuits, les coordonnées de chaque vectrices doivent être inscrites pour permettre à
Google de tracer ce circuit. Il n’est pas possible d’effectuer cette opération avec la
License d’ArcGIS que la ville possède. Pour y remédier, le logiciel Q-GIS fut utilisé afin
d’extraire ces données. L’ordre de numérisation étant lié à l’ordre des résultats de cette
opération, deux des trois circuits ont dût être retracés.
Ce projet utilise la grande popularité de Google map afin de faciliter l’accès à une
information. Ceci s’ajoute au projet de données ouvertes en fournissant à une
plateforme externe, des données qui seront diffusées. Par contre, la ville de Rimouski
possède un second type de transport en commun, les TaxiBus, qui consiste en un service
de taxi qui prend plusieurs passagers en même temps et dessert les secteurs les plus
éloignés du centre urbain. Ce service fonctionnant qu’avec des arrêts prédéterminer,
sans circuit ni horaire précis, n’est pas compatible avec le modèle de Google map. La
ville doit donc réfléchir à un moyen d’intégrer ces deux modes de transports dans un
même modèle.
21
2.1.10 Focus : déneigement des rues
La ville de Rimouski a modernisé le suivi de sa flotte routière en débutant par les
camions de déneigement. Pour ce faire, elle a fait appel à une compagnie externe,
Focus, qui se spécialise dans la gestion de flotte.
Avec un GPS installé sur les véhicules, leur logiciel permet d’obtenir, en temps
réel, des informations sur l’utilisation de ces véhicules. Ainsi, il est possible de voir sur
une carte le parcours emprunté. Pour ce faire, Focus demande à la ville de numériser
elle-même son réseau routier dans leur programme. Une formation a donc été donnée
aux employés du département de géomatique afin de bien comprendre les différents
paramètres à considérer lors de la numérisation. Ces derniers consistaient surtout à
diminuer la précision des tracés ; l’utilisation de polygone au lieu de polyligne sous
forme de segment large et qui ne se rejoint pas aux intersections. La raison de ce
manque de précision est le fonctionnement même du programme qui prend la position
du GPS au 30 secondes, GPS qui peut être précis au 5 mètres, et qui fait un tracé à partir
de ces points. L’idée est que ce tracé se retrouve à l’intérieur du polygone de rue, à un
certain pourcentage, pour indiquer que le véhicule est bien passé par ce chemin.
Ce projet ne participe pas aux données ouvertes, mais démontre l’utilisation
qu’est faite de la géomatique pour la ville. Les outils de la géomatique permettent donc
une gestion en temps réel des effectifs de la ville et ainsi d’atteindre une plus grande
efficacité dans ses services.
2.1.11 Tronçon d’égout à inspecté
Ce travail fut réalisé pour Mme Anick Saint-Pierre, ingénieure responsable de
l’inspection des égouts et aqueduc. Il s’agissait de fournir des plans avec différents
segments d’égouts présélectionnés et leurs caractéristiques (numéros d’identification,
22
longueurs, diamètres, matériaux, etc.). Une problématique que Mme Saint-Pierre devait
résoudre était de ne pas dépasser une certaine longueur totale de segment d’égout à
inspecter afin de respecter son budget. Afin de l’aider dans ce travail, les plans étaient
accompagnés d’un tableau Excel reprenant les caractéristiques de chacun des segments
et calculant automatiquement la longueur totale. Ce travail fut repris plusieurs fois afin
d’intégrer ou d’enlever des segments dans les plans.
Il s’agit ici d’un exemple de projet couramment demandé au département de
géomatique par un autre service.
2.1.12 Calendrier des collectes de déchet pour mes services municipaux
Un des projets sur lequel M. Casista travaillait était celui de la carte web intitulé
«mes services municipaux» qui permettent, en choisissant une localisation, d’obtenir
l’information sur les services municipaux disponibles près de cet endroit. Une de ces
informations consistait à indiquer les journées de collectes d’ordure, de recyclage et de
compost.
La problématique étant que les semaines de collectes changent selon les saisons
et durant l’hiver, elles ne sont pas régulières. Lors de la programmation de l’application
web, ces changements obligent d’indiquer chacune des dates individuellement
puisqu’elles ne sont pas inscrites dans un cycle régulier. Par contre, si la collecte
s’effectue une semaine, elle se fait la même semaine pour tous les secteurs. Ceci a
permis de simplifier la retranscription des données en indiquant manuellement la date
que des lundis et d’additionner les autres journées à l’aide d’Excel.
Ce projet permettra de fournir l’information aux citoyens en limitant le nombre
de calendriers de collecte à imprimer comme il est fait en ce moment.
23
2.1.13 Carrière sablière
Le service des ressources financières a demandé au département de géomatique
de les aider à mettre à jour leurs documents sur les carrières et sablières en exploitation
sur le territoire de la municipalité. Il s’agissait de comparer des documents provenant de
plusieurs sources : le service des ressources financières, les données du service de
géomatique, les données du gouvernement du Québec et des photographies aériennes.
Une analyse de ces différents documents a permis d’identifier de nouvelles
carrières et sablières, certaines qui ne sont plus en exploitation, certaine qui n’ont pas
changé de statuts et celles qui doivent être vérifiées sur place par un inspecteur. Ceci a
permis de partager l’information entre les deux services et d’avoir des données à jour.
2.1.14 petits projets
Cette dernière section sur la méthodologie utilisée traite de plusieurs petits
projets demandés qui consistaient principalement aux tâches quotidiennes du
département de géomatiques. Ces projets n’ont pas demandé plus d’une demi-journée
de travail.
Tous les bâtiments appartenant à la ville
Il fut demandé ici d’ajouter à la couche des bâtiments, un champ indiquant s’il
s’agit d’un bâtiment appartenant à la ville. Avec le logiciel Accès Cité Territoire qui gère
les cadastres et les propriétés, une recherche a été effectuée afin de faire ressortir les
propriétés appartenant à la ville. L’information représentant les cadastres fut transférée
vers ArcGIS afin d’acheminer l’information sur la bonne couche. Une carte montrant les
24
bâtiments ayant une fonction inconnue fut ensuite fournie comme document de travail
(carte 4).
Carte 4: Bâtiments se trouvant sur un lot appartenant à la ville; Format original : A0
25
Motoneige
Ce projet consistait à indiquer le tracé des sentiers de motoneiges pour une
analyse du département d’urbanisme (carte 5).
Carte 5: Empreinte des sentiers de Motoneige; Format original : A0
26
Nombre de logements dans les secteurs urbains du Bic
Une étude pour le déneigement demandait de connaitre le nombre de
logements dans différents secteurs urbanisés dans le district du Bic. Une carte a été
assemblée avec les unités d’évaluation se situant dans les secteurs urbains et avec le
nombre de logements Total se trouvant dans la légende (carte 6)
Carte 6:Nombre de logement en milieu urbain, secteur du Bic; Format original : 11 X 18
Limites district loisir sur limites de quartier
Pour ce travail, il fut demandé de modifier les limites des districts
d’appartenance aux loisirs pour qu’elles se superposent aux limites des quartiers afin de
standardiser les différentes séparations de la ville.
27
Vérification WiFi et Z.A.P.
Il fut demandé de vérifier si les données de la ville concernant les endroits
offrant un accès gratuit à internet par WiFi concordaient avec celle fournie par le
distributeur de ce service.
Cartes avec info sur les lots
Ici il s’agit de plusieurs demandes qui se sont fait tout au long du stage
concernant la demande de citoyens sur les dimensions d’un lot en particulier. Le travail
consistait donc à créer une carte 8 1/2 par 11 centré sur le lot avec les dimensions du
terrain d’afficher.
Intersections importantes
Il s’agissait ici de repérer les intersections importantes, c’est-à-dire, celle avec un
feu de circulation. Ce projet a servi à identifier quelle intersection devait avoir des
pancartes de nom de rue plus grande.
Site du patrimoine du Bic
Ce projet consistait à numériser un tracé fait à la main sur une carte papier pour
identifier les lots faisant partie du site du patrimoine du Bic.
28
Terrain contaminé
Ce projet consistait à trouver dans la base de données du gouvernement du
Canada et celle du gouvernement du Québec, la liste des terrains contaminés. Une
couche de point fut ensuit construite pour chacune de ces deux données. Ces couches
ont ensuite servi à l’étude d’un projet de développement dans le secteur industriel.
Ces petits projets font partie des services que le département de géomatique
offre aux autres services de la ville ainsi qu’aux citoyens. Dans la plupart des cas, il s’agit
d’un service de cartographie.
2.2 Résultats et discussion
À la lumière de ces différents projets réalisés, il est possible d’affirmer que les
objectifs des mandats confiés pour ce stage ont été atteints. ArcGIS server est
opérationnel, des projets d’application web ont été réalisés afin de distribuer des
informations que la ville possède. Avec ce stage, le projet de données ouvertes de la
ville a pu avancer beaucoup plus rapidement.
M. Cassista voit tout le potentiel qu’offre la géomatique aux différents projets de
la ville. Il doit cependant composer avec une petite équipe qui n’a pas le temps
d’accomplir tout le travail nécessaire pour exploiter ce potentiel. Le manque d’effectif
est le principal problème du département de géomatique de la ville de Rimouski.
29
3. Analyse critique
Le domaine des SIG est en constante évolution, et ce, autant d’un point de vue
technique que d’un point de vue conceptuel. À l’origine, il s’agissait d’un outil
d’automatisation de la cartographie pour ensuite, dans les années 1990, devenir un outil
d’aide à la décision. Depuis les années 2000, avec la croissance des applications web, les
SIG ont pour objectif de diffuser des connaissances sur le territoire pour développer une
compréhension partagée de l’espace (Pornon H. 2007). En ce sens, le stage effectué à la
ville de Rimouski s’inscrit dans son époque. Sans être avant-gardiste, il fut demandé
d’utiliser des applications récentes pour publier de l’information géographique.
Le poste occupé au sein de l’organisme municipal était celui d’un haut
technicien. La réflexion qui était demandée concernait surtout la résolution de
problème technique, l’analyse spatiale étant laissée aux ingénieurs et urbanistes.
Cependant, le département de géomatique élabore une réflexion plus cognitive de son
utilité. Il parait évident qu’il y a, selon les projets demandés et les discussions sur leurs
buts, une réflexion sur comment la géomatique peut servir la population. La question
qui semble être posée est «Quelles informations pourraient être utiles ou intéresser la
population ?» et «Comment présenter cette information de façon intelligible avec des
applications faciles d’utilisation?»
Bref, le poste de géomaticien municipal consiste à gérer les bases de données
géographiques, de les manipuler pour en extraire l’information demandée et publier
cette information.
30
4. Développement futur
Plusieurs technologies présentement sur les tables à dessin pourraient influencer
le rôle des géomaticiens. Lors du colloque des géomaticiens municipaux du Québec au
printemps 2015, il fut mention de feux de circulation régulant le trafic selon la densité
de ce dernier en se servant du service de localisation des téléphones cellulaires pour
calculer cette densité. Google développe présentement une voiture se déplaçant sans
conducteur (Google 2016). Ce type de technologie utilisera des données spatiales qui
devront soit être fournies par les municipalités, soit être gérées par celle-ci.
À plus courts thermes, les géomaticiens municipaux semblent emprunter la voie
des données ouvertes. Plusieurs municipalités mettent présentement sur pieds des
applications cartographiques web pour fournir des informations utiles aux citoyens.
Cette tendance est à ses débuts et dépendamment de la réponse des citoyens, elle
pourrait durer encore longtemps.
Malgré ce que le futur prépare, la géomatique municipale devra sans aucun
doute continuer d’assumer ses fonctions de bases. Nous entendons ici le service de
cartographie ainsi que la gestion et l’entretien des données spatiales pour les autres
services municipaux.
31
5. Conclusion
Ce stage aura permis d’atteindre mes objectifs personnels. La géomatique étant
utile pour la grande majorité des départements de l’organisme municipale, elle est
portée à travailler sur une grande variété de projets. Le concept de ville intelligente
repose sur une gestion intégrée des différents aspects qui la composent. Par cet aspect
et par la nature versatile de la géomatique, cette dernière devrait occuper un rôle
important dans la mise en place d’une ville intelligente.
Le DESS en SIG de l’UQAM est très technique dans son approche de la
géomatique. Cette formation a toutefois permis de fournir les outils nécessaires au
travail demandé lors de ce stage. Les lacunes de formation en publication web ont été
en partie comblées lors de ce stage.
Pour conclure, ce stage m’aura permis d’encrer mes connaissances des SIG dans
des situations réelles. De voir un projet de géomatique mener au travers de toutes ses
étapes. Surtout, ce stage m’aura permis de confirmer le grand intérêt que je porte au
SIG.
32
Bibliographie
Dupuy Gabriel, 1993. Chapitre 6 : De l'informatique municipale à la "ville intelligente" :
tendances de l'informatisation urbaine. In: Annuaire des collectivités locales. Tome 13.
pp. 93-103.
Giffinger, R. (s.d.). The smart city model. In European smart cities. http://www.smart-
cities.eu/model.html (page consultée le 28 décembre 2015)
G.O.Cité 2015 à http://www.gocite.ca/ (page consulté le 28 décembre 2015)
Google 2016, à https://www.google.com/selfdrivingcar/ (page consulté le 15 janvier
2016)
Pornon, Henri, 2007, «Bilan et perspectives de 20 années de géomatique», Géomatique
Expert- No 57- juin-juillet 2007 pp. 36- 46
33
Annexes
Annexe 1 : code python
# coding: utf8 # Titre: inventaire_geodatabase.py # But: Ce script crée un fichier csv contenant l'inventaire d'une geodatabase # Cree par: Jean-Philippe Lauzon # Creation: 2015-08-20 # Modification: # Copyright: 2015 ''' DESCRIPTION: cette outil fera l'inventaire l'inventaire de la geodatabase en creant un document csv a l'endroit desirer.le tableau d'inventaire contiendra les champs suivants : Feature dataset, Featureclass, Shape, Nom du champ, Alias du champ, Type du champ ''' ''' Historique des modifications: 2015-08-20: Creation ''' # declaration d'une classe d'erreur class script_exc(Exception): pass #__IMPORTATION_DES_MODULES___ #_______________________________________________________________________ import sys, os, re import traceback import arcpy from arcpy import env
34
#__DECLARATION_DES_VARIABLES___ #_______________________________________________________________________ # Variables en entre, parametrables à partir d'arcgis: GDB = arcpy.GetParameterAsText(0) dossier_sortie = arcpy.GetParameterAsText(1) # variable pour la sortie du fichier csv GDB_spliter=GDB.split("\\") nomgdb = GDB_spliter[-1] inventaire = dossier_sortie + "\\\inventaire_"+nomgdb+".csv" #on cree un nom specifique faisant reference a la geodatabase inventorier #__VERIFICATION_DES_PARAMETRES_EN_ENTRE___ #_______________________________________________________________________ # Verification de la presence de la geodatabase if not arcpy.Exists(GDB): msg=("La geodatabase %s n'est pas présente" %(str(GDB))) raise script_exc(msg) # Verification que la geodatabase donnee par l'utilisateur est une geodatabase info = arcpy.Describe(GDB) if not info.dataType == "Workspace": msg=("Le fichier %s n'est pas une geodatabase" %(str(GDB))) raise script_exc(msg) # la geodatabase devient notre workspace env.workspace = GDB #__DEFINITION_DES_FONCTIONS___ #_______________________________________________________________________
35
# permet de ne pas écraser un inventaire existant en créant un nom unique pour le fichier de sortie. def get_unique_path(path): # source :sametmax.com while os.path.exists(path): # si le nom de fichier existe, on en cherche un autre base, ext = os.path.splitext(path) # on vire l'extension try: base, counter, _ = re.split(r" \((\d+)\)$", base) # on extrait le compteur si il existe except ValueError: counter = 0 path = "%s (%s)%s" % (base, int(counter) + 1, ext) # on reconstruit le path return path #____COMMANDE_PRINCIPALE____ #_______________________________________________________________________ if (os.path.exists(inventaire)): inventaire = get_unique_path(inventaire) try: print "Debut du traitement..." F_out = open (inventaire, "w") # ouvre le fichier en sortie pour écrire dedans F_out.write ("Feature dataset;Featureclass;Shape;Nom du champ; Alias du champ;Type du champ;Projection;Presence de metadata;Chemin d'acces \n") # cette ligne inscrit l'entête dans le fichier de sortie. liste_ds = arcpy.ListDatasets() # on cree la liste des feature dataset... for dataset in liste_ds: # pour chaque feature dataset... liste_fc = arcpy.ListFeatureClasses("","",dataset) # ...on crer la liste des features class... for f_class in liste_fc:
36
liste_champ = arcpy.ListFields(dataset + "\\" + f_class) # pour chaque featureclasse de la liste, on fait une liste des champs. info_fc = arcpy.Describe(dataset + "\\" + f_class) # a partir d'ici on extrait l'information des feature class chemin_incomplet = info_fc.path chemin = chemin_incomplet + f_class f_shape = info_fc.shapeType r_spacial_code = info_fc.spatialReference r_spacial = r_spacial_code.Name meta_d = info_fc.metadataRetrieved if meta_d is False: # on ne peut pas inscrire des donnees booleen avec des string alors on change les donnees booleen en string metadata = "Faux" elif meta_d is True: metadata = "vrai" else: metadata = "" for champ in liste_champ: #a partir d'ici on extrait l'information des champs type_champ = champ.type alias_champ = champ.aliasName nom_champ = champ.name F_out.write(dataset.encode('utf8')+";"+f_class.encode('utf8')+";"+f_shape.encode('utf8')+";"+nom_champ.encode('utf8')+";"+alias_champ.encode('utf8')+";"+type_champ.encode('utf8')+";"+r_spacial.encode('utf8')+";"+metadata.encode('utf8')+";"+chemin.encode('utf8')+ "\n") # la ligne ci-haut ecrit dans le fichier csv les informations recueillient dataset = "" # a partir d'ici, on fait l'inventaire de ce qui n'est pas dans un feature dataset donc on laisse le champ vide liste_fc = arcpy.ListFeatureClasses() # on crer la liste des features class... for f_class in liste_fc:
37
liste_champ = arcpy.ListFields(f_class) # pour chaque featureclasse de la liste, on fait une liste des champs. info_fc = arcpy.Describe(dataset + "\\" + f_class) # a partir d'ici on extrait l'information des feature class chemin_incomplet = info_fc.path chemin = chemin_incomplet + f_class f_shape = info_fc.shapeType r_spacial_code = info_fc.spatialReference r_spacial = r_spacial_code.Name meta_d = info_fc.metadataRetrieved if meta_d is False: # on ne peut pas inscrire des donnees booleen avec des string alors on change les donnees booleen en string metadata = "Faux" elif meta_d is True: metadata = "vrai" else: metadata = "" for champ in liste_champ: #a partir d'ici on extrait l'information des champs type_champ = champ.type alias_champ = champ.aliasName nom_champ = champ.name F_out.write(dataset.encode('utf8')+";"+f_class.encode('utf8')+";"+f_shape.encode('utf8')+";"+nom_champ.encode('utf8')+";"+alias_champ.encode('utf8')+";"+type_champ.encode('utf8')+";"+r_spacial.encode('utf8')+";"+metadata.encode('utf8')+";"+chemin.encode('utf8')+ "\n") # la ligne ci-haut ecrit dans le fichier csv les informations recueillient liste_tab = arcpy.ListTables() # on cree la liste des tables... for table in liste_tab: liste_champ = arcpy.ListFields(table) # on cree la liste des champs dans les tables info_tabl = arcpy.Describe(dataset + "\\" + table) # a partir d'ici on extrait l'information des tables f_shape = "table" # ... et on indique dans le champ "Shape" qu'il s'agit d'une table... f_class = table # ... et on indique dans le champ "Featureclass" le nom de la table
38
r_spacial = "" # puisqu'une table n'a pas de reference spatiale, nous laissons le champ vide chemin_incomplet = info_tabl.path chemin = chemin_incomplet + table meta_d = info_tabl.metadataRetrieved if meta_d is False: # on ne peut pas inscrire des donnees booleen avec des string alors on change les donnees booleen en string metadata = "Faux" elif meta_d is True: metadata = "vrai" else: metadata = "" for champ in liste_champ: #a partir d'ici on extrait l'information des champs type_champ = champ.type alias_champ = champ.aliasName nom_champ = champ.name F_out.write(dataset.encode('utf8')+";"+f_class.encode('utf8')+";"+f_shape.encode('utf8')+";"+nom_champ.encode('utf8')+";"+alias_champ.encode('utf8')+";"+type_champ.encode('utf8')+";"+r_spacial.encode('utf8')+";"+metadata.encode('utf8')+";"+chemin.encode('utf8')+ "\n") # la ligne ci-haut ecrit dans le fichier csv les informations recueillient liste_rast = arcpy.ListRasters() # on cree la liste des raster type_champ = "" # puisqu'il s'agit d'un raster, il n'y a pas de champ... alias_champ = "" nom_champ = "" f_shape = "Rasterdataset" # ... et la shape est forcement un rasterdataset... for raster in liste_rast: f_class = raster # ... on indique dans le champ "Featureclass" le nom du raster info_rast = arcpy.Describe(dataset + "\\" + raster) # a partir d'ici on extrait l'information des raster r_spacial_code = info_rast.spatialReference r_spacial = r_spacial_code.Name chemin_incomplet = info_rast.path chemin = chemin_incomplet + raster
39
meta_d = info_rast.metadataRetrieved if meta_d is False: metadata = "Faux" elif meta_d is True: metadata = "vrai" else: metadata = "" F_out.write(dataset.encode('utf8')+";"+f_class.encode('utf8')+";"+f_shape.encode('utf8')+";"+nom_champ.encode('utf8')+";"+alias_champ.encode('utf8')+";"+type_champ.encode('utf8')+";"+r_spacial.encode('utf8')+";"+metadata.encode('utf8')+";"+chemin.encode('utf8')+ "\n") # la ligne ci-haut ecrit dans le fichier csv les informations recueillient F_out.close() # ferme le fichier en sortie (l'inventaire completee) #____GESTION_DES_ERREURS____ except: # Source: Divers scripts de ESRI print "Une erreur est survenue!" tb = sys.exc_info()[2] tbinfo = traceback.format_tb(tb)[0] pymsg = "PYTHON ERRORS:\nTraceback Info:\n" + tbinfo + "\nError Info:\n " + str(sys.exc_type) + ": " + str(sys.exc_value) + "\n" msgs = "ARCPY ERRORS:\n" + arcpy.GetMessages(2) + "\n" arcpy.AddError(msgs) arcpy.AddError(pymsg) print msgs print pymsg arcpy.AddMessage(arcpy.GetMessages(1)) print arcpy.GetMessages(1) finally: F_out.close()
