Soutenance mémoire
Test Branchement Conduites
OUTILS DE TRADUCTIONS
Une fois le périmètre des applicatifs ciblé, on peut passer { l’étape qui a comme but de définir les processus de traduction spécifiques pour chaque type de données. Le constat, dans cette phase, est que l’on ne peut pas utiliser un seul outil comme clef magique afin de tout transformer. Comme on l’a vu, les applications touchées sont différentes et il y en a certaines que les autres partenaires SITG n’utilisent pas (i.e. GeoConcept et LIDS). Il y a des outils qui ont été mis à disposition par la Confédération et d’autres qui sont en train d’être développés actuellement. On va regarder de plus près cet environnement. On analysera leurs implications dans la deuxième partie de cette section.
PANORAMA GENERAL
Le changement de référentiel a été voulu par la Confédération. Cela a été un long processus, car pour transformer des géodonnées numériques de l’ancien au nouveau cadre de référence, un modèle mathématique se basant sur un maillage de triangles recouvrant tout le territoire a été élaboré. Fin 2006, les cantons et la Confédération ont achevé ce maillage, désigné CHENyx06. Pour le canton de Genève, un maillage très particulier a d’ailleurs été défini en frontière avec le canton de Vaud, afin de réajuster les géodonnées genevoises au reste de la Suisse. Actuellement, swisstopo met gratuitement
{ disposition le maillage national des triangles CHENyx06 ainsi qu’une bibliothèque (DLL) du programme REFRAME (développée par elle) pour les développeurs de logiciels, cela afin de garantir des transformations précises et cohérentes.
Voici un état des lieux des traducteurs actuellement disponibles sur le marché et leurs caractéristiques :
FINELTRA a été élaboré par la Confédération. Ce logiciel permet la conversion de coordonnées du cadre de référence MN95 vers le cadre de référence MN03 et inversement, ainsi que la modélisation des déformations de MN03. Le système d’exploitation est : Windows95, 98, ME, NT4, 2000, XP. A remarquer que FINELTRA ne transforme que les points sur la base d’une transformation affine définie triangle par triangle. La précision atteignable dépend très fortement du jeu de données utilisé. Le jeu de données FINELTRA-MN s’appuie sur les points de triangulation de 1er et de 2ème ordre déterminés par GPS et donc également connus dans le cadre de référence MN95. Une précision de l’ordre de 10 cm peut être atteinte avec ce jeu de données. L’avantage de ce choix est que les triangles ont été réalisés officiellement par la confédération, donc il n’y a pas besoin de les calculer de manière autonome.
REFRAME (également élaboré par la Confédération) permet la transformation planimétrique et/ou altimétrique pour les travaux de mensuration nationale ou de mensuration officielle aux exigences de précision les plus élevées. Avec ces fonctionnalités plus complètes, REFRAME a remplacé FINELTRA. Les formats de fichiers compatibles sont : LTOP (coordonnées et mesures), ESRI Shape, AutoCAD DXF, Interlis 1, Topobase .K, Adalin OneOne et texte avec séparateur (comme CSV) +Export KML (WGS84) pour la visualisation dans Google Earth ou Maps. Le système d’exploitation est : Windows 98, ME, NT4, 2000, XP SP6a, Vista, Linux ou Mac OS X. Son avantage est qu’il permet une transformation simultanée de plusieurs formats différents. Il comprend une interface utilisateur standard ainsi qu’un mode ligne de commande pour les traitements par lots. Une version pleinement fonctionnelle de REFRAME est disponible gratuitement en tant que service de transformation en ligne sur le site Internet de swisstopo. Actuellement, seuls les fichiers de données jusqu’{ 5 Mb peuvent être traités.
FME (Feature Manipulation Engine) est un puissant logiciel GIS servant à la conversion de données. Cette boîte à outils (ETL spatial) révolutionne le géo-traitement et la conversion de données géographiques. FME est capable d’exploiter en lecture et en écriture plus de 200 formats de données géographiques, DAO, raster et de bases de données, et possède encore une dizaine d’opérateurs géométriques topologiques et attributaires. Il est développé par l’éditeur canadien SAFE Software et est utilisé dans tous les secteurs d’activités de l’information géographique. FME Universal Translator est l’application qui permet de traduire des données géographiques entre deux formats. L’avantage dans l’utilisation de FME est qu’{ SIG on dispose de la dernière version.
Le plug-in REFRAME pour FME intègre toutes les transformations planimétriques et altimétriques compatibles avec le logiciel REFRAME. Tous les fichiers pouvant être lus par le logiciel FME-Software (nombreux formats SIG, DAO et texte) peuvent être traités par ce transformer.
Le Plug-in FINELTRA Reprojector pour FME a été développé en utilisant le developer kit officiel de swisstopo (module Tydac).
ESRI
ArcGIS permet d’utiliser MN03 ou MN95 et de convertir les coordonnées d’un système { l’autre. La transformation de datum est réalisée grâce à la grille de transformation mise à disposition par swisstopo au format NTv2 (National Transformation, Version 2). La transformation FINELTRA a été intégrée sous forme de « custom transformers » dans la technologie FME. Avec la version ESRI de FME et l’extension FME pour ArcGIS, un outil similaire est disponible depuis la Toolbox d’ArcGIS. Une extension ArcGIS développée par Topomat, qui réalise la conversion depuis la Toolbox est également présente sur le marché. L’avantage de cet outil est son indépendance vis-à-vis des triangles.
GEOCONCEPT
GéoConcept est actuellement en train d’élaborer son outil de transformation qui sera prêt pour le début de l’été 2009. Celui-ci comprendra une version capable de transformer des objets de l’ancienne projection dans la nouvelle (intégration de REFRAME), plus une version qui sait gérer des données déjà transformées dans le nouveau référentiel. Cet outil sera intégré dans la nouvelle version Geoconcept 6.6.
LIDS
LIDS aussi est en train de développer un traducteur pour sa nouvelle version LIDS7, mais aussi un traducteur pour la version 6. A ce sujet, il faut préciser que LIDS6 est relié à Oracle Bentley, tandis que LIDS7 sera relié directement à Oracle Spatial. De plus, dans cette version-là, les coordonnées seront stockées de manière complètement différente. A ce stade, il faut rester attentif sur un point qui ne concerne pas directement la migration en MN95 : si l’on envisage d’acquérir des solutions nomades dans un futur assez proche, il faudra peut-être considérer la possibilité de passer à un autre produit.
ENJEUX
Ces questions restant ouvertes, il faut également tenir compte d’un certain nombre d’enjeux approfondis par d’autres partenaires SITG, notamment du SEMO qui peuvent aider à compléter le panorama de la migration :
Les imprécisions locales vont rester, ne vont pas s’améliorer ;
Les imprécisions avec la frontière seront nombreuses ;
Il existe un risque de déformation des objets droit et longs (ex. câbles électriques, voies aériennes) ;
La topologie et les métadonnées ne vont pas rester, il faudra les réécrire dans la nouvelle BD transformée en MN95 ;
Il faut constamment connaître la provenance des données pour éviter la présence des coordonnées des deux formats dans le même fichier.
LE CAS DU SEMO
Le SEMO a estimé la durée pour effectuer la migration à une semaine. Ils ont décidé de transformer tous leurs fichiers afin d’éviter des confusions de coordonnées lors de la mise à jour des cartes. La volumétrie n’est pas un élément déterminant à prendre en compte dans leur cas, leurs données sont en format SDE. Ils ne vont pas se servir de REFRAME (car ils utilisent des triangles plus locaux qui ne sont pas disponibles avec REFRAME), mais ils vont réaliser les transformations au travers du traducteur FME module Tydac (le Plug-in FINELTRA Reprojector qui a été validé par la Confédération). Actuellement, tout semble bien fonctionner, cependant il y a un inconvénient : le passage va créer une nouvelle base de données en MN95, cela implique qu’il faudra recréer toutes les règles topologiques, métadonnées, arcs, etc. présentes dans l’ancienne BD en MN03. C’est pourquoi le SEMO a demandé à la société Topomat de développer une fonction qui ne double pas la BD, mais qui fait le changement de cadre de référence directement dans la BD de départ. Ils sont actuellement, dans l’attente de ce module. Ils utilisent aussi le convertisseur Topomat pour essayer de corriger les déformations très locales (avec REFRAME cela n’est pas possible).Chaque membre du SITG va être responsable du changement des coordonnées, cependant le SEMO (l’Etat) va s’occuper des privés (ex. les architectes). On pourrait se demander pourquoi ce même traitement n’a pas été envisagé pour les partenaires SITG possédant la même technologie ?
ANALYSE DES POSSIBLES SCENARIOS A SIG
A SIG on présente la même problématique que le SEMO, en ce qui concerne les adresses stockées dans les bases Oracle. Il est intéressant pour nous d’attendre la réponse de Topomat, pour éventuellement leur demander de développer un module équivalent pour les bases Oracle. Entre-temps, de manière générale, on va tracer des scénarios possibles.On part du constat qu’en étant en partenariat avec le SITG, il convient de viser à utiliser les outils fournis par la Confédération ou par les autres membres du SITG, l{ où c’est possible. On remarque déjà qu’{ l’égard de LIDS et GeoConcept, cette solution n’est pas envisageable car au SITG ils ne sont pas trop utilisés. Or, une possibilité concrète et logique est de tester les outils fournis par les deux logiciels. Une autre solution alternative est de traduire ces fichiers au travers des extensions FME, même en passant par des formats intermédiaires. Il faut cependant faire attention à ne pas passer par trop de formats intermédiaires, au risque de perdre des informations d’un passage { l’autre. L’avantage dans cette solution est le fait que l’on possède déj{ ce logiciel { SIG.
On procède à une analyse par application :
AUTOCAD
Comme anticipé lors de la première partie du travail, a priori il n’y aura pas besoin de transformer tous les fichiers AutoCad DXF dans le nouveau cadre de référence. Cependant, si nécessaire, on a plusieurs possibilités :
REFRAME
FME plug-in REFRAME (et réécrire dans la nouvelle BD)
FME module Tydac (et réécrire)
Toutefois il est nécessaire de rester attentif à ne pas mélanger le MN95 et le MN03 lors de la mise à jour des cartes qui vont rester { l’ancien format.
MAPINFO
En ce qui concerne MapInfo, il n’existe pas de module de conversion des coordonnées en MN95. Il faut donc passer par FME. On pourrait également envisager une conversion des fichiers GRD en Shape ESRI au travers du logiciel FME et une reconversion des files Shape en format MapInfo (cela ne devrait pas créer trop de difficultés).
En bref :
FME module Tydac (et réécrire)
BASES ORACLE
Pour les bases Oracles, on souhaite prévoir le même scénario que le SEMO :
FME plug-in FINELTRA (Module Tydac) + Equivalent Module Topomat, cela afin de ne pas réécrire les règles de l’ancienne BD.
A remarquer que parmi les bases Oracle figure également Oracle Bentley + Oracle Spatial (LIDS 6 et 7) et Oracle GeoConcept. Cela signifie que l’on pourrait envisager le changement de cadre de référence directement dans Oracle. L’avantage de cette solution est de ne pas réécrire dans une autre base de données, mais l’inconvénient est le facteur temps.
LIDS
Module en élaboration (NB. vérifier avec le développeur s’il y a la possibilité de ne pas réécrire les bases).
FME plug-in FINELTRA (Module Tydac) + Equivalent Module Topomat (et ne pas réécrire).
GEOCONCEPT
Dans cette application, il faut faire une distinction entre les sources GCM et celles Oracle GeoConcept. Elles ne peuvent pas être transformées de la même manière.
Pour les sources GCM (il faudra réécrire dans les nouvelles bases):
Module GeoConcept en élaboration
FME ? (éventuelle transformation en fichiers intermédiaires ? lesquels ?)
Pour les sources Oracle :
FME module Tydac + Equivalent module Topomat (et ne pas réécrire)
Un autre type d’approche est envisageable : transformer toutes les données dans un seul fichier intermédiaire pour les traduire et ensuite les réintégrer dans GeoConcept 6.6. Par exemple :
FME => ESRI Shape => plug-in REFRAME =>GeoConcept
L’inconvénient dans cette option et le poids du fichier et les limites techniques.
ENJEUX
Les différents scénarios devront non seulement être bien testés afin de trouver la solution la plus pertinente, mais ils seront également dépendants de facteurs logistiques internes { l’entreprise. Actuellement, la réflexion porte sur l’identification du format le plus ouvert possible, dans le but de pouvoir fonctionner de manière globale avec d’autres systèmes dans un avenir proche. Cela place l’unité Plans-réseaux dans une position d’ouverture et de flexibilité dans laquelle on pourrait envisager un changement de GIS, si l’on trouve un autre système répondant mieux à ces exigences. En outre, on prévoit d’acquérir des solutions nomades au sein de l’entreprise, qui soient totalement compatibles avec la solution bureau. Parmi les premiers résultats d’un état des lieux des solutions nomades actuellement existantes dans le marché, on trouve deux possibilités : une compatible avec LIDS et une autre avec ESRI. L’avantage de passer { ESRI serait d’avoir un seul système qui possède le même GIS que la majorité des partenaires du SITG. Mais chaque possibilité est à étudier soigneusement.
Tout cela pour dire que la conjoncture actuelle permet d’envisager des importants changements, qui pourraient être reliés au passage au MN95. On pourrait envisager de changer de GIS avant de changer de cadre de référence, mais concrètement cela n’est pas pratique pour nous. Le choix le plus opportun est dans l’ordre :
1) changer de cadre de référence,
2) acquérir une solution nomade,
3) éventuellement changer de GIS.
Pour revenir au point 1, plus généralement on a le choix entre :
Utiliser les modules de GC e LIDS pour les fichiers GCM et DGN ;
Utiliser FME module Tydac pour Oracle et MapInfo et/ou pour les fichiers GCM et DGN ;
Faire développer un équivalent du module Topomat pour les bases Oracle et LIDS ;
Utiliser FME translator pour transformer tous les fichiers GCM, DGN, GRD, Oracle en Shapefile ESRI ;
Traduire avec FME plug-in Reframe et réintégrer les données intermédiaires en Shapefile ;
Utiliser le module ESRI pour passer à MN95 (et réintégrer les données).
Il s’agit, { ce stade, d’harmoniser ces possibilités, dans une coordination qui conjugue l’efficacité de la transformation et l’économie des traducteurs utilisés. De manière pragmatique, il est convenable d’uniformiser le plus possible les stratégies. Les possibilités suivantes se présentent :
Est-ce on veut traduire le plus possible directement à partir des applications ?
Vaut-il mieux trouver un fichier intermédiaire unique ? Le cas échéant lequel ?
Idéalement, on souhaite utiliser la même stratégie du SEMO pour LIDS et Oracle GeoConcept, c’est-à-dire lire et remplacer les coordonnées directement dans la BD de départ. On envisage l’achat du module Tydac et d’un équivalent du module Topomat. (Pour GeoConcept et MapInfo il faudra réécrire éventuellement les données). Toutefois, d’autres scénarios restent envisageables.
|
Table des matières
INTRODUCTION
DEMARCHE SUIVIE – METODOLOGIE
1. PERIMETRE DES APPLICATIFS CONCERNES A SIG
1.1. Brève Présentation de la structure Services Partagés
1.2. Volumétries
1.3 APPLICATIFS
1.4. ANALYSE INTERMEDIAIRE
2. OUTILS DE TRADUCTIONS
2.1. PANORAMA GENERAL
2.2. ENJEUX
2.3. ANALYSE DES POSSIBLES SCENARIOS A SIG
2.4. ENJEUX
Scénario 1
Scénario 2
Scénario 3
Scénario 4
3. TESTS
3.1. PRECISION DE LA TRANSFORMATION
3.2. TOPOLOGIE
3.3. Carte de précision SEMO
3.4. Test Dardagny
3.5. Test Dardagny avec Geoconcept 6.6 beta
3.6. Test Branchement Conduites
3.7. Test Longueurs Conduites
CONCLUSION
Télécharger le rapport complet
