Certificat complémentaire en géomatique

Le présent stage a concerné l’étape de la structuration et de la mise en place de la base de données du mandat « Gestion des forêts sécuritaires bordant les routes nationales de la filiale 1», abrégée GfsRN1. Cette base de données hébergera toutes les informations nécessaires à la réalisation des contrats OFROU – Cantons et Cantons-gestionnaires locaux. Elle recevra également les informations des travaux effectués et devra permettre de produire des synthèses annuelles et quinquennales. Ce modèle de base de données sera ensuite repris pour toute nouvelle période moyennant quelques adaptations. Les utilisateurs de la base de données seront le bureau Ilex et les autres bureaux d’ingénieurs (maximum cinq) mandatés par les Cantons. L’OFROU et les services cantonaux concernés auront uniquement besoin de visionner la base de données et ne vont peut-être même pas le faire. L’OFROU ne va pas inclure cette d’une éventuelle intégration future à cet outil, l’OFROU ne demande même pas de respecter un format particulier de données, ni de noms de champ ou d’attributs définis4.

Afin de répondre aux exigences et d’assurer la faisabilité technique, il a été nécessaires de rassembler le maximum d’informations concernant de près ou de loin les bases de données MS Access et ArcGIS. Pour cela, les sources d’informations suivantes ont été consultées. 20106, différents programmes de base de données, différentes licences, …  Relecture du cours GEOTOOLS-DB du certificat de géomatique 20147.  Renseignements concernant la base de données MISTRA8 et le modèle Interlis9.  Séances avec l’OFROU, Bernard Graf et Alain Dubois pour obtenir des informations, préciser .

CREATION DU MODELE CONCEPTUEL ET DU MODELE LOGIQUE

Une base de données se compose de données et d’un schéma qui décrit la structure des données. On voit toujours la base à travers son schéma. Ce schéma s’exprime selon un modèle, qui est une représentation simplifiée d’une réalité complexe (objets, processus, temps). Il est important de modéliser une base de données, qu’elle soit spatiale ou non, afin de réfléchir à l’organisation des informations et de poser la problématique pour pouvoir répondre à nos requêtes et de faciliter le Un modèle conceptuel est indépendant de tout programme informatique et est souvent décrit à l’aide d’un formalisme. Un de ces formalismes est le Unified Modelling Language (UML), langage de modélisation unifié en français. C’est un langage graphique standardisé qui définit les objets et leurs relations. Le diagramme de classe (ensemble d’objets de même genre) est l’élément central. La Figure 5 montre un exemple de modèle conceptuel avec des indications en rouge concernant le type d’éléments. Il existe également des langages textuels pour représenter un modèle conceptuel comme INTERLIS 2.3, norme officielle suisse, qui est un langage de description et un mécanisme d’échange pour les géodonnées, indépendant de tout système.

Le modèle logique, qui représente le modèle conceptuel en vue d’une implémentation informatique, a ensuite été élaboré. Dans notre cas, ce sont les tables avec leurs champs et leur relations entre « clés primaires » (identifiant unique d’une table) et « clés secondaires » (champ qui reprend la clé primaire d’une autre table pour les lier). Le modèle physique représente la structuration et la description complète (référentiel spatial, domaines de valeurs possibles, types de données,…) du modèle logique dans les systèmes informatiques choisis, dans le cas présent ArcGIS et MS Access. Avant de faire le modèle physique final pour le tronçon test, j’ai trouvé pertinent de créer un modèle physique avec des données propriétaires, gestionnaires et mesures fictives pour pouvoir me familiariser avec les outils et faire des essais pour définir le procédé de remplissage final sans perdre de temps à chercher et remplir les données réelles. Les données fictives ont également permis de modéliser toutes les possibilités, ce qui ne pouvait pas être le cas pour le tronçon test. Le modèle physique, n’étant plus un simple schéma mais la création physique de la base de données, possède de nombreuses étapes qui sont décrites ci-après. Ces étapes ont nécessité de nombreux aller-retour entre elles pour éliminer toutes les erreurs et problèmes survenus.

OBTENTION DES COUCHES DE BASE DES ORGANISMES CANTONAUX ET FEDERAUX  

Afin d’avoir des repères spatiaux et permettre la digitalisation de nos futures entités, il fallait obtenir des couches spatiales de base de la part des différents organismes cantonaux et fédéraux (swisstopo et OFROU). Les données nécessaires commandées sont listées dans l’ANNEXE 1. Toutes les données de base sont regroupées dans une géodatabase spécifique. Les données commandées à swisstopo n’étaient pas encore arrivées pour effectuer le tronçon test sur Vaud. Les données vaudoises déjà en possession du bureau Ilex ont alors été utilisées (cadastre, communes, forêts de protection, cartes nationales et orthophotos, …) et la couche VECTOR 25 a été empruntée sur le serveur de l’université de Genève (UNIGE). L’OFROU a, lui, fourni les éléments relatifs aux routes nationales (axes, tronçons d’entretien,…). Les données provenant de tiers ont nécessité une préparation afin qu’elles soient utilisables pour la base de données à réaliser (par exemple produire des zones tampons autour des axes et ajouter les noms des communes au cadastre). Ces opérations ont été automatisées dans des ModelBuilders.