Synthèse. Etude du changement de cadre de référence du système d information du territoire genevois.

Transcription

1 Système d information du Territoire Genevois Février à juin 2008 Service de la mensuration officielle Synthèse Etude du changement de cadre de référence du système d information du territoire genevois. Anne-Charlotte Paul Mai 2008 Laurent Niggeler Octobre

2 1 Sommaire 1 Sommaire Contexte de l étude Volet technique Passage des données vectorielles en MN Caractéristiques de la transformation en MN95 sur le canton de Genève : Description de la transformation des données vecteur en MN95 : Passage des données raster en MN Etude technique des principaux logiciels déployés sur Genève Services de transformation en ligne / Outils de transformation de géodonnées Outil en ligne : Reframe Outil extension ArcGIS : convertisseur de Topomat Résumé Effets techniques collatéraux Visualisation et analyse des erreurs Conséquence de la transformation sur les données et précautions d utilisation découlant des problèmes rencontrés lors des tests: Volet organisation Organisation à mettre en place Planification relative au changement de cadre de référence Assurance qualité Volet financier Estimation financière du passage des données vecteurs et raster en MN Estimation du retour sur investissement Volet communication Conclusion Décisions du comité directeur

3 2 Contexte de l étude La grande majorité des cartes, plans et données à référence spatiale se réfèrent à un cadre de référence national pour la planimétrie (x, y - coordonnées nationales) et un autre pour l'altimétrie. Ces cadres de référence constituent la base sur laquelle ces données (mensuration officielle, cadastre souterrain, aménagement du territoire, plans d'exécution de bâtiments ou d'ouvrages, etc.) sont ajustées et géométriquement mises en relation. Les données actuelles contenues dans le système d information du territoire genevois (SITG) sont dans le cadre de référence de la Mensuration nationale de 1903 (MN03) pour la planimétrie, et basées sur le Nivellement fédéral de 1902 (NF02) pour l'altimétrie, avec la particularité pour le canton de Genève, d'avoir conservé le cadre de référence d'origine modifié à la fin des années 70. De ce fait les géodonnées genevoises sont décalées et soumises à une rotation hétérogène par rapport à celles du canton de Vaud. Depuis quelques années, l'office fédéral de topographie (Swisstopo) a défini de nouveaux cadres de référence, un pour la planimétrie appelé Mensuration nationale 1995 (MN95) et un autre pour l'altimétrie dénommé Réseau altimétrique national (RAN95). Ces nouveaux cadres de référence forment un réseau de base pour les données géoréférencées qui offre une précision absolue élevée sur l'ensemble de la Suisse tant pour la planimétrie que pour l'altimétrie. Le changement du cadre de référence actuel MN03 vers MN95 doit être mené à bien d ici Les cantons peuvent bien entendu procéder au passage plus tôt et profiter ainsi plus rapidement des avantages que procure le nouveau cadre de référence. Au niveau français, une nouvelle obligation réglementaire a été établie par décret n du 3 mars 2006 en ce qui concerne l usage du nouveau système de référence de coordonnées, jusqu alors facultatif. Les informations localisées devront être fournies dans le nouveau système national de référence de coordonnées Lambert 93, ceci au plus tard pour avril Lors de son comité de direction du 4 juillet 2007, l Institut Géographique National français (IGN) a décidé de fournir et produire tous ses produits et données en Lambert 93 et ceci pour le 1er semestre La conjugaison de ces opérations va permettre d'harmoniser les référentiels de part et d'autre de la frontière. En effet, tant le nouveau cadre de référence suisse MN95 que le cadre français Lambert 93, sont basés sur le référentiel géographique européen ETRS89. Au niveau genevois, le passage au système de référence MN95 va devenir de plus en plus nécessaire compte tenu des enjeux des actions contenues dans les projets transfrontaliers. Il a de plus été démontré qu'un retour sur investissement de 1 à 5 est possible quand les géodonnées sont harmonisées au niveau du référentiel et des modèles de données. Pour réaliser cette étude un groupe de travail a été constitué. Il rassemblait des représentants des partenaires du SITG, des services de l Etat, des géomètres, du SOSI, de la ville de Genève ainsi que de l office fédéral de topographie. Les séances permettaient d échanger les points de vue sur l étude et d orienter son déroulement. Cette synthèse examine les contraintes du changement de cadre de référence pour le canton de Genève ainsi que l organisation et la planification nécessaires à une telle opération. D autres aspects de l étude y sont mentionnés comme les aspects financiers et informationnels. 3

4 Cette synthèse est développée en 4 volets : - Volet technique : mise en évidence des contraintes et des difficultés techniques ainsi que des outils permettant de transformer les géodonnées du SITG qu elles soient sous forme vecteur ou raster - Volet organisation : proposition d organisation et de planification du changement de système de référence - Volet financier : Estimation des coûts d un changement de système de référence pour le canton de Genève - Volet communication : Les aspects de communication et d information auprès des utilisateurs relatifs au futur changement de système de référence du SITG sont très importants. Le public cible, les moyens et le contenu de la communication doivent être attentivement étudiés Annexes : Vous trouverez en annexe à cette synthèse, plusieurs documents vous permettant d appréhender en détail les différents volets qui sont décrits ci-dessous. Annexe 1 : Fiche informative : changement cadre de référence mars 2008 Annexe 2 : Fiche technique : changement cadre de référence mars 2008 Annexe 3 : Annexe 4 : Tests de transformation Tests de topologie Remarque : Afin de pouvoir effectuer des comparaisons et pouvoir tester des données en MN95, les données du SEMO en CH1903 ont été converties en CH1903+ Ce jeux de données est a disposition des partenaires du SITG. Sur demande, un CD sera fournit (format géodatabase ESRI 9.2). Il est également possible d obtenir davantage de données en MN95 sur demande. 4

5 3 Volet technique Cette étude met en évidence les contraintes et les difficultés techniques ainsi que les outils permettant de transformer les données du SITG que ce soit des données vecteur ou des données raster. 3.1 Passage des données vectorielles en MN95 Le centre de compétence DG/MN95 de Swisstopo a défini les éléments et conditions de la transformation MN03 vers MN95. Chaque canton a dû déterminer un jeu de triangles permettant de tenir compte de la qualité des réseaux de points fixes et des mensurations existants. Pour le canton de Genève, un maillage très particulier a é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 (annexe 1) Caractéristiques de la transformation en MN95 sur le canton de Genève : Le canton de Genève a des caractéristiques particulières de par sa situation géographique. La majorité de sa frontière se fait avec la France. Cette caractéristique va impliquer un échange important de données géoréférencées avec ce pays. La France va passer en Lambert 93 (représentation nationale du système de coordonnées européen) en mars C est pour cette raison que le canton de Genève a intérêt à passer en MN95 dans les années à venir, ou en tout cas avant 2016 date maximum légale. Le canton de Genève a également une autre particularité, Il possède son propre cadre de référence. Le CH1903-GE diffère du CH1903 présent sur le reste de la Suisse. Cela fait suite à une erreur de détermination d un point de triangulation au niveau de la Dôle. Cela entraîne une cassure entre le canton de Genève et le canton de Vaud. Le passage en MN95 pourrait faciliter les échanges entre les deux cantons. A la frontière entre les deux cantons, un maillage très particulier a été défini. Cela est dû à l erreur mentionnée plus haut qu il était nécessaire d atténuer. Ci-contre : Zone critique entre les cantons de Vaud et Genève. Maillage particulier qui a été défini afin de réajuster les géodonnées genevoises au reste de la Suisse. 5

6 3.1.2 Description de la transformation des données vecteur en MN95 : Pendant la période de tests, toutes les données vecteur du SEMO ont été transformées en MN95 à l aide du convertisseur développé spécifiquement. Ces nouvelles données ont été examinées et comparées aux données en MN03. Des écarts tels que des défauts au niveau des bâtiments, au niveau d alignements devaient être étudiés. o Conséquence de la transformation sur les alignements (3 points par exemple): Ci-contre l alignement ne coupe pas de triangles de transformation. La longueur de l objet en MN03 est de m et en MN95, m, soit une différence de 1.2cm. Ici le point aligné n est pas décalé. L influence des trois sommets du triangle est la même sur les trois points alignés. Echelle approximative : 1/25000 Echelle approximative : 1/15000 Zoom x Sur l exemple ci-dessus, l alignement coupe plusieurs triangles de transformation. L objet a une longueur de m en MN03 et en MN95 mesure m, soit une différence de 2.1cm. La distance entre les points A (en MN03) et A (en MN95) est de 1.6cm. Cet exemple permet d avoir une idée de la variation d un objet suivant sa longueur. Des écarts au niveau des alignements peuvent être visibles sur de très grandes distances et pour des objets qui traverseraient plusieurs triangles. Pour ce qui est du parcellaire transformé de tels écarts n ont pas été constatés. Pour les partenaires ayant besoin d une précision importante comme les CFF, cette variation nécessitera un travail conséquent de traitement après transformation des données en MN95. Les écarts rencontrés lors des tests, entrent largement dans la tolérance de l ordonnance fédérale sur les données du cadastre (OTEMO) qui est de ±10cm. Un test a également était réalisé en transformant des données en MN95 dans le cadre de référence en vigueur, le MN03. Ce nouveau fichier transformé a été comparé avec le fichier 6

7 original (acquisition des données en MN03). Aucune différence n a pu être constatée. Les deux fichiers sont identiques ; cela signifie que la transformation est biunivoque. o Conséquence de la transformation sur les angles des bâtiments : Ne sachant pas comment les angles des bâtiments allaient être influencés lors de la transformation, des comparaisons entre les résultats en MN03 et MN95 ont été réalisées. L écart le plus important constaté est de l ordre de ± 12mgon (= 1millidegré). Le fait que le bâtiment traverse des triangles de transformation ou qu il soit centré dans un seul triangle n entraîne pas de variation plus ou moins importante. o Tests sur les surfaces : Les surfaces en MN03 ont été comparées à celles obtenues après transformation en MN95. Les différences obtenues sont visibles à l échelle du canton. Les variations de surfaces des communes ont été listées dans un tableau et représentées dans un histogramme et sur une carte. Les valeurs présentées ci-dessous correspondent à la différence entre la surface obtenue après transformation en MN95 avec la surface d origine en MN03 (en pour mille). S. MN95 S. MN03 ( ) On peut ainsi visualiser quelles sont les communes dont la surface va augmenter et celles qui perdront en superficie après le passage en MN95. L ordre de grandeur de ces variations est très faible. On peut voir dans l échelle de couleur ci-dessus que les écarts vont de à Ces documents sont présents sur les pages web du SEMO. Le lien est le suivant : Le tableau des différences de surfaces est disponible également 7

8 via ces pages. Le même travail a été réalisé avec tous les biens fonds du canton et peuvent être consultés sur demande. o Temps de transformation : Un récapitulatif des temps de transformation a été inséré dans les pages web créées pour le projet. Ce document concerne les données de la direction cantonale de la mensuration officielle. Le temps nécessaire à la transformation ainsi que le nombre d objets de chaque classe d entités y sont mentionnés. Ces transformations ont été réalisées à l aide du convertisseur en extension du logiciel ESRI. Pour avoir une rapide idée des temps de transformation : Couche contenant peu d objets (185) : Temps : 2min 47s Couche moyenne (3377) : Temps : 6min 48s Couche contenant beaucoup d objets (358219) : Temps : 3h50min Ensemble données du SEMO (1.7 millions obj.) : Temps : 20 heures o Résumé : La transformation de données vecteur n entraîne pas d incohérence. Les déformations rencontrées rentrent dans les tolérances de la mensuration officielle. Pour les partenaires ayant besoin d une précision plus importante (les CFF par exemple travaillent à ±1mm), un nouveau traitement des données va s imposer (nouveau calcul des données à partir de points de référence relevés en MN95). Le temps nécessaire à la transformation des données vecteur n est pas trop important d autant que des améliorations peuvent être apportées aux outils de transformation (shape simplifié, transformation de plusieurs fichiers à la fois ). 3.2 Passage des données raster en MN95. o Possibilités de transformation de raster : Il est possible de convertir une image en MN03 en MN95 à l aide du convertisseur précité. Cet outil nécessite d avoir des données en format GRID. Le protocole de transformation avec cette méthode est disponible sur le site web du SEMO ( Pour une image de 7.63MB (1000m sur 1000m) le temps nécessaire à la transformation est de 36 minutes, pour un seul layer (il y en avait trois dans cette image). Pour une image de 708MB (3080m sur 3080m) le temps nécessaire à la transformation est de 109 heures pour un seul layer. Extrait d image en MN03 (taille pixel : 2m) Extrait de l image obtenue après transformation (taille pixel : 2m) 8

9 La conversion du raster entraîne une dégradation de l image ; en effet, les pixels sont reformés en tenant compte des paramètres de transformation (translation, rotation, échelle). Les résultats obtenus ont été comparés à d autres objets en MN95 comme le domaine routier ou les bâtiments hors-sol. La superposition de ces éléments montre une bonne cohérence entre les objets. Extraits de l image obtenue après transformation (taille pixel : 0.16m) o Cohérence de l opération : La conversion de données raster nécessite beaucoup de temps. C est une activité chronophage dont le résultat ne justifie pas l application systématique. Il est plus intéressant d acquérir des données directement en MN95 plutôt que de leur faire subir une transformation qui entraînera une perte de qualité. Le prochain plan de vol sur Genève aura lieu en 2009, et l orientation des images se fera en MN95 et en MN03. Les cartes et les rasters issus de géotraitement ne subiront pas cette transformation, ils seront soit re-commandés soit re-traités. Seuls les rasters «plans historiques» seront concernés par la conversion, une simple translation des plans ne suffirait pas car un travail assez précis est réalisé à partir de ces données. Les informations concernées sont les suivantes : - Plan historique Billon (1726) - Plan historique Ceard (1837) - Plan historique Grange (1896) - Relevé des rez-de-chaussée de la vieille ville - Report du cadastre Napoléonien (1726) - Transformation du territoire aux XIX et XX siècles Aperçu du Plan historique Grange (1896) Aperçu du Plan historique Billon (1726) 9

10 3.3 Etude technique des principaux logiciels déployés sur Genève Cette étape liste les logiciels utilisés sur le canton qui gèrent des données géographiques et leurs attributs. Après avoir réalisé des entretiens avec les partenaires et autres utilisateurs de données du SITG, une liste assez complète a pu être établie. o Logiciels principaux ESRI ArcGIS v.9.2, v9.1; ArcSITG v.2.7, v.2.6; ArcPad ; ArcSDE Autodesk AutoCAD v à 2009 ArchiCAD v.10 ; v.11 Microstation v.j LIDS LIDS 95, LIDS v6, LIDS + Geoconcept v 5.6 ; v 2.8 Mapinfo v.8 FME o Logiciels secondaires et spécifiques SmallwordGIS Intergraph INTERLIS Studio TatukGIS Surfer Global Mapper Idrisi v.kilimanjaro GRASS Map Server ERDAS Proj4 Mapguide Sky guide Osiris StarCarto StarGIS Toporail o Logiciels de calcul et applicatifs Inwi 5 Covadis Cadna Homere Topogéo Mouse Hastus Lors des entretiens réalisés entre mars et mai 2008, les différences entre le MN95 et le MN03 étaient présentées aux utilisateurs de données du SITG. Un problème concernant la gestion du 7ième chiffre au niveau des coordonnées par les logiciels de calcul et de traitement des données est rapidement posé (exemple : les CFF avec leur logiciel Toporail). Les différents partenaires et services de l Etat rencontrés ont été sensibilisés à cette question. Ils devront vérifier que leurs logiciels ne posent pas de difficultés. Cette vérification se fera avant le transfert de toutes les données en MN95, date à définir officiellement suivant l organisation du passage dans le nouveau cadre de référence. 10

11 3.4 Services de transformation en ligne / Outils de transformation de géodonnées Outil en ligne : Reframe Le logiciel en ligne nommé «Reframe» a été développé par Swisstopo. Il permet de transformer les fichiers allant jusqu à 5 Mo pour l instant. Il est accessible sur le lien suivant et est compatible avec un nombre intéressant de formats de données : LTOP (coordonnées et mesures) Topobase.K ESRI Shape Adalin OneOne AutoCAD DXF.txt avec séparateur Interlis 1 Ce service permet également le passage de données dans les systèmes suisse, européen et mondial. L utilisation est facile et la conversion se fait rapidement. Pour les données supérieures à 5 Mo il est nécessaire de télécharger le logiciel Reframe version client. Dans un proche avenir, l objectif sera de développer un outil s apparentant à Reframe sur le géoservice qui permettra de convertir les données extérieures dans de nombreux systèmes de référence comme le Lambert Outil extension ArcGIS : convertisseur de Topomat. Cet outil a été développé par la société Topomat et s intègre dans le logiciel ArcGIS. Il a été utilisé pour les tests réalisés durant l étude. Pour utiliser ce logiciel il est nécessaire d avoir à disposition les fichiers de triangles Fineltra qui sont disponibles sur demande auprès de Swisstopo ou du SEMO pour la partie de Genève. Les fichiers obtenus avec Reframe et ce convertisseur ont été comparés, les résultats issus de ces deux logiciels sont identiques. Un protocole d utilisation de ce logiciel a été établi durant l étude Résumé Des transformations ont été faites avec ces deux outils durant la période de tests. Sur le site du SEMO, dans les pages web dédiées à ce projet, une fiche détaille le protocole appliqué durant cette étude. L utilisation des logiciels présentés dans ce chapitre y est détaillée. Les deux logiciels utilisés lors de cette étude sont le logiciel Reframe et l extension ArcGIS développé par Topomat. Les données en MN95 résultant de ces deux outils sont identiques. Les précautions à prendre lors de l utilisation de ces logiciels sont minimes, il suffit d avoir les bons fichiers de triangles à disposition et d entrer les bons paramètres lors de la création de jeux de classes d entités (convertisseur ArcGIS). Les indications fournies avec les logiciels sont claires et permettent une utilisation aisée. Les remarques figurant dans la fiche de protocole (annexe 3) peuvent éclairer les utilisateurs sur certains points. 11

12 3.5 Effets techniques collatéraux Afin de savoir comment la transformation gère les polygones, les lignes, les points, les zones superposées à certaines données, les arcs, etc. des topologies ont été crées. La cohérence des données résultant de la conversion a ainsi été contrôlée Visualisation et analyse des erreurs. De la même façon que pour le protocole de transformation des logiciels présentés dans le paragraphe précédent, une fiche détaillant les topologies créées a été mise en ligne. L annexe 4 revient sur la création des topologies, les tolérances utilisées et les erreurs rencontrées. MN03 MN95 Représentation graphique des topologies du canton en MN03 et en MN95, zoom sur l erreur présentée en MN95. Les topologies en MN03 et en MN95 ont été comparées comme le montrent les figures ci-dessus. Les distances mesurées entre les entités concernées par les erreurs topologiques sont inférieures à la tolérance d agrégat définie lors de la création de la topologie. Agrandissement important sur une erreur linéaire. Zoom x 20 En considérant les échelles nécessaires à la visualisation de ces erreurs, on peut convenir de leurs faibles conséquences. Les erreurs le plus souvent mises en évidence concernent les arcs. Cela vient du fait que les arcs en MN03 subissent déjà un léger décalage au lieu de se superposer parfaitement. La transformation en MN95 va accentuer faiblement ces défauts et les règles de topologie créées vont les détecter. Les classes d entités «domaine routier», «Répartition des plans», «bâtiments hors sol», «bâtiments sous-sol», «biens fonds», etc. ont toutes été soumises à des règles topologiques en MN03 comme en MN95. 12

13 Ces exemples présentés sur la fiche 2 démontrent l échelle à laquelle les défauts sont visibles. Toutes ces erreurs rentrent dans la tolérance d agrégat choisie lors de la création de la topologie. Pour en être convaincu, il suffit de faire afficher dans le tableau récapitulatif des topologies sous ArcMap l option «Doivent être plus grandes que la tolérance d agrégat». Cette option permet de voir quelles sont les erreurs qui n entrent pas dans la tolérance exigée Conséquence de la transformation sur les données et précautions d utilisation découlant des problèmes rencontrés lors des tests: o Modification des données transformées : La transformation entraîne peu de déformation sur les entités, lorsque cela se produit, l écart est largement inférieur à la tolérance exigée par l ordonnance fédérale. Pour les erreurs topologiques, celles constatées sont de la même façon présentes dans les données de base en MN03. Elles n apparaissent pas dans le listing d erreur en MN03 car elles ont été vérifiées et tolérées en raison de leur très faible influence. o Création de zones superposées aux données de base : Des interrogations se posaient quant à la transformation de zones. Ces zones sont construites par superposition par rapport aux données de base. Cette construction bouge de la même façon que les données à partir desquelles elle a été créée. Il est tout de même important de prendre des précautions en accrochant correctement ces nouvelles entités sur les constructions de base (tronçons, sommets des entités ). o Domaines et sous-types des données : Les domaines et les sous-types des différentes données sont rattachés à la géodatabase qui les renferme. La conversion de ces données ne permet pas de faire suivre ces domaines. Le protocole d utilisation prend en compte ce problème grâce à une petite manipulation avant la transformation des données. o Transformation d un projet nouveau : Si une construction, un projet, est réalisée à partir de données en MN03, Il faut qu elle subisse la transformation pour passer en MN95. Il ne faut pas qu elle soit copiée et simplement recalée sur les données en MN95! Cette réalisation serait incorrecte dans ces conditions. 13

14 Insertion d un fichier en MN03 dans une représentation en MN95 ou inversement: La fiche technique (annexe 2) insérée dans le dossier «documentation» des pages web, insiste sur le danger d intégrer sous ArcGIS des données en MN03 et en MN95. Ce problème a été souligné lors des entretiens et il est important d insister encore une fois sur ce point. Ci-contre : Boîte de dialogue qui apparaît lorsque l on veut intégrer une donnée en MN95 dans une représentation en MN03. Cette fenêtre avertit l utilisateur de la différence de cadre de référence entre les deux classes d entités car le logiciel ne peut pas gérer deux cadres de référence en même temps. En fermant cette boîte de dialogue les données intégrées (sur l exemple la classe d entités adresse en MN95) vont subir une translation et se superposer aux données en MN03. Il y aura alors un décalage bien visible entre les données qui sont réellement en MN03 et les données qui sont dans un «faux MN03» (décalage pouvant aller jusqu à 90cm environ). Ce problème pourrait se poser pour des logiciels autres qu ArcGIS et les utilisateurs doivent être prudents notamment après le passage définitif des données du canton en MN95. Cette précaution vaut également pour les données archivées. Il est nécessaire que chacun fasse attention à la gestion des archives et que les archives ne soient pas récupérées pour réaliser de nouveaux travaux. o Autre précaution : Lors des tests il s est avéré que les coordonnées contenues dans les tableaux attributaires de certaines données n étaient pas transformées. A l affichage, toutes les données sont bien en MN95, il n y a que les coordonnées figurant dans la table attributaire qu il est nécessaire de recalculer. Dans ArcMap (v.9.2), l option «calculer la géométrie» permet de remédier à ce problème. 14

15 Le Y mentionné dans la table correspond au X de l affichage ArcMap et inversement, le X de la table attributaire correspond au Y de la fenêtre d affichage. Pour les versions antérieures d ArcMap, il est possible de recalculer cela grâce à un algorithme : Dim Output As Double Dim ppoint As IPoint Set ppoint = [Shape] Output = ppoint.x o Précaution à prendre pendant le traitement : Il serait intéressant que la personne responsable de la transformation des données ait à sa disposition deux ordinateurs. De cette façon, les calculs ne seraient pas ralentis par l utilisation d autres applications. Les temps de traitement pourraient être employés à la création d autres manipulations. 4 Volet organisation 4.1 Organisation à mettre en place Pour réaliser cette étape du projet, les interviews réalisées entre mars et mai se sont avérées très utiles. Elles ont permis de mettre en évidence les moyens et besoins de chacun, partenaires comme services de l Etat. Quatre propositions résultent de ces entretiens qui se feraient selon des plannings différents. Les unes suggèrent un passage rapide pour que la période durant laquelle les données vont coexister soit restreinte, la date «objectif» à atteindre serait alors fin Une dernière préconise un passage beaucoup plus long dans le temps, cette date serait alors remise en question et la période de transition étendue. On peut classer ces propositions en deux groupes principaux ; il est possible soit de «centraliser» le service de transformation soit de répartir la tâche sur tous les services concernés de l Etat. Centralisation de la transformation : o Passage en MN95 à partir d une date fixe o Passage progressif en fonction de la demande Répartir les tâches Le document qui reprend toutes ces propositions est disponible sur les pages web créées pour le projet (pages web). Un des plans d organisation doit être approuvé par le groupe d étude. Lors de la présentation de ces différentes propositions au groupe de travail, la date pour le passage de toutes les données en MN95 a été remise en cause. Cette date devra être déterminée par le comité directeur du SITG. Compte tenu de son importance, elle doit être déterminée en accord avec les partenaires et les services de Etat. 15

16 4.2 Planification relative au changement de cadre de référence Etapes du changement de cadre de référence : Avant o Offrir la possibilité aux utilisateurs du SITG de sélectionner leurs données soit en MN03 soit en MN95. Le cadre de référence MN03 resterait la sélection par défaut jusqu à ce que le MN95 devienne cadre légal sur le canton de Genève. o Envoi de données transformées aux différents partenaires du SITG pour qu ils puissent tester la réactivité de leurs outils. Réalisation de tests par les partenaires pour préparer leur structure au changement de cadre de référence. o Détermination d une date pour transformer les données en MN95 en accord avec tous les membres et partenaires du SITG (décision du comité directeur du SITG). o Détermination d une date à partir de laquelle les projets de bureaux d études devront être réalisés sur la base de données en MN95. o Mise en place du plan de communication : envoi de courriers aux utilisateurs en insistant sur l importance de ce projet pour chacun, envoi de mail régulièrement Intensification progressive de ce plan de communication à mesure que les dates clés approchent. o Sélection des données à transformer. (données issues de serveurs métiers, données issues de serveurs de consultation ) o Contact avec les fournisseurs de logiciels dans le cas de mauvaise gestion des données en MN95. Pendant Ces étapes dépendront du mode d organisation retenu pour passer les données du canton en MN95. o Envoi des données mises à jour de tout le canton (partenaires, services de l Etat) au SOSI. o Conversion de toutes ces données en MN95. Après o Contrôle des données transformées : nombre d objets transformés, topologie o Vérification des bases de données ; Les bases de données devront contenir uniquement des données en MN95. o Pour les bureaux d étude passer par un géomètre ou par le SOSI pour transformer un projet qui sera livré après la date du changement de cadre de référence ainsi que toutes les données ayant servi à sa conception. o Créer un service de transformation en ligne au niveau du canton. 4.3 Assurance qualité Transformer une énorme quantité de données est une opération délicate. En plus de l organisation et de la planification d un tel projet, il est nécessaire de définir les contrôles qualité permettant de s assurer que tout le processus s est correctement déroulé : aucune perte de données, topologie respectée, etc. o Vérification du nombre d objets transformés. Le convertisseur Topomat utilisé lors des tests, affichait systématiquement le nombre d objets en entrée et en sortie. Une information s affichait de la même manière lorsqu un objet ne se trouvait pas un triangle de transformation. C est une vérification qui peut être faite pendant 16

17 le calcul aussi bien qu après la transformation. Il est aisé de vérifier si le nombre d objets dans un fichier en MN95 est identique au nombre d objets du fichier en MN03. o Vérification des caractéristiques des nouveaux fichiers Il est nécessaire de vérifier que les caractéristiques des données en MN95 soit bien les mêmes que celles en MN03 (tolérance X, Y, tolérance Z, tolérance en M ). Cela doit se faire avant la transformation, lors de création de nouveaux jeux de classes d entités (par exemple), mais il se peut que la méthode de transformation des entités ne soit pas la même que celle du protocole suivi durant l étude. o Contrôle des règles topologiques Les règles topologiques doivent être établies pour les classes d entités en MN95. Les propriétés de ces règles doivent être les même que pour les données en MN03. La validation des nouvelles données doit passer par le contrôle de ces nouvelles règles. o GéoDataBase contenant les données Il important de vérifier que les géodatabases créées pour stocker les données dans le nouveau cadre de référence ne se composent que de données en MN95. Cette condition permettra d éviter des confusions. 5 Volet financier Ce paragraphe doit permettre d estimer les coûts du changement de cadre de référence pour le canton de Genève. Ces résultats seront repris pour le projet de loi dans sa partie financière. 5.1 Estimation financière du passage des données vecteurs et raster en MN95 o Hypothèses de travail : Nous partons du principe que pour que le canton de Genève a choisi la proposition n 3 pour passer dans le nouveau cadre de référence. Rappel de la proposition n 3 (pour voir toutes les propositions voir les annexes ou les documents figurant dans les pages web du SEMO) : Pour toutes les données de l Etat, c est le SOSI qui se chargera de passer les données géoréférencées en MN95. Le SEMO aura un rôle d aide et viendra épauler le SOSI pour certaines requêtes d utilisateurs sur le MN95. Les partenaires suivant leurs besoins pourront soit gérer eux même le passage dans le nouveau cadre de référence soit demander ce service au SOSI. 17

18 La date du passage en MN95 est fixée à Cette échéance est retenue pour l étude et la date définitive reste à fixer en accord avec le comité directeur du SITG. L estimation globale a été réalisée à partir des dépenses internes et externes de l Etat de Genève. Les dépenses des autres partenaires du SITG ne sont pas prises en compte Estimation du temps consacré au passage en MN95 pour deux techniciens (SOSI et SEMO) Les pourcentages représentent la quantité de travail horaire pendant la période indiquée au niveau de l échelle des temps. Remarques : Le prix concernant ArcSDE dépendra de l architecture hardware envisagée. 18

19 Pour les licences, il sera certainement possible au sein de l Etat de faire un planning et de «bloquer» un nombre de licences nécessaires lors du basculement. o Dépenses internes à l Etat de Genève : Pour réaliser cette estimation, le taux horaire de techniciens travaillant à l Etat a été utilisé. Le statut des personnes en charge de ce travail pourra être revu par la suite. Il est envisagé que quatre PC soient achetés pour répondre suffisamment rapidement à toutes les demandes. o Dépenses externes : Des dépenses externes on été comprises dans cette estimation. Le financement d un tel projet dépassera la somme de CHF et des achats externes, comme des PC ou des logiciels seront certainement nécessaire. Une assistance externe pourrait également être nécessaire notamment pendant la période précédent la date P. o Exemple de coût estimé pour convertir les données du SEMO : Pour cette estimation, on part du principe que les conditions sont optimales, aucun problème n a été rencontré. Le technicien a déjà le protocole de transformation ce qui permet d éviter des pertes de temps. Il est possible de baisser ce coût puisque dans cet exemple un seul ordinateur a été utilisé et les classes d entités converties une à une. Données transformées : données vecteur (polygone, ligne, points) Nombre d entités total : entités Taille de la GDB : 853 Mo Ordinateur et employé dédié à ces transformations : 1 ordinateur et 1 technicien Le temps de travail comprend : Le temps nécessaire pour la réalisation du calcul Le temps nécessaire au technicien pour suivre le protocole, pour créer toutes les topologies et pour réaliser tous les contrôles. Estimation coût pour toutes les données vecteurs du SEMO 3 jours travaillés 24 heures travaillées Tarif horaire technicien 145 CHF/h Estimation 3480 CHF Tarifs issus des publications KBOB, Recommandations relatives aux honoraires o Aide de la confédération : La confédération va accorder à l Etat une partie des dépenses qui seront déboursées pour mettre en place le changement de cadre de référence (uniquement pour les données de la mensuration officielle). Ce dédommagement sera donc fonction du budget utilisé par le département du territoire. 19

20 5.2 Estimation du retour sur investissement Pour l instant il n est pas possible de quantifier le retour sur investissement. Il est avéré que pour des travaux de lever par GPS, des échanges transfrontaliers, le MN95 va procurer un certain nombre d avantages. On peut rappeler les différents avantages que le MN95 procure : Un travail et une manipulation des données seront plus simples. La réduction des incohérences de voisinage permettra d abaisser les frais de levé et de mise à jour des données géoréférencées. Cela pourra se constater à long terme Il permet de déterminer des coordonnées de façon absolue avec les précisions entre points voisins exigées par la MO, sans ajustage local et sans contraintes. Le référencement homogène et absolu de données géoréférencées permet de faciliter l intégration des données ayant des origines diverses. L utilisation facile du GPS sans nécessairement rattachement sur un point connu. 6 Volet communication Les aspects de communication et d information auprès des utilisateurs relatifs au futur changement de cadre de référence du SITG sont très importants. Le public cible, les moyens et le contenu de la communication doivent être attentivement étudiés. Afin de faire connaître à tous les utilisateurs de données du SITG la problématique d une telle étude, des fiches de communication ont été créées. Une attention particulière leur a été apportée car elles doivent attirer l attention de chaque utilisateur de données du SITG sur ce changement de cadre de référence. Des pages web ont également été créées sur le site du SEMO pour mettre en évidence ces fiches et exposer l importance d un tel projet. Ces quelques pages ont permis de mettre en évidence l évolution du projet durant ses mois de réalisation. Un mail envoyé par le webmaster du site du SITG a signalé à ses membres l élaboration de cette étude. Des interviews de partenaires et services de l Etat de Genève ont été réalisées. Elles avaient pour but non seulement de présenter le projet mais aussi d évaluer l utilisation faites des données géoréférencées et les moyens de chaque utilisateur de données du SITG. Lors des entretiens il s est avéré que la communication par mail n était pas toujours bien passée. C est un moyen de communication trop usuel qui ne permet pas d attirer l attention des utilisateurs de données sur un projet aussi important. Les interviews sont un mode de communication qui permet d impliquer tous les utilisateurs de données, cela a été approuvé par la majorité des personnes rencontrées. Puisque ce projet s inscrit dans la continuité, il est important que la communication se fasse de manière soutenue jusqu à ce que le cadre de référence légal sur le canton de Genève soit le MN95. Des courriers officiels devront être envoyés aux bureaux d études pour les informer des documents disponibles et des dates clés du basculement en MN95, ainsi que des modalités pour chaque domaine d activité. Ce nouveau cadre de référence devrait rentrer dans les esprits notamment en offrant la possibilité d extraire des données en MN95 dès la fin

21 7 Conclusion L étude menée au premier semestre 2008 montre qu un changement du cadre de référence du SITG est une opération techniquement réalisable. Des outils de transformations existent. Il a été montré que les impacts sur les données géoréférencées sont très limités, mais qu il est nécessaire que chaque partenaire du SITG teste lui-même avec ses applications l utilisation des données transformées (7 ème chiffre notamment). Chaque partenaire du SITG devra également évaluer l impact organisationnel sur ses processus d utilisation des données géoréférencées internes, venant du SITG ou issus de leurs mandataires. Il faut préparer minutieusement la période du basculement du cadre de référence (qui fait quoi, à quel moment, comment, etc.). Une organisation validée par le comité directeur du SITG et soutenue par un bon plan de communication sera indispensable et garante d une opération réussie. Le calendrier du changement de système de référence devra être largement diffusé pour que les utilisateurs se préparent eux-mêmes au changement de système de référence. Cela introduit une contrainte supplémentaire sur le projet, puisque le respect des délais en sera d autant plus nécessaire. Il est important que tous les acteurs soient avertis et conscients de l existence de cette diffusion très large, qui les engage pour tenir les délais. Finalement il faut souligner que la gestion de multiples cadres de référence est facteur de désorganisation, de confusion, d erreurs et générera des manipulations fréquentes provoquant des dépenses inutiles. Une contrainte dans le projet de changement de cadre de référence est de minimiser ou même d éviter la coexistence des deux systèmes au sein du SITG. 8 Décisions du comité directeur Le comité directeur du SITG doit prendre deux décisions : - Définir la structure d organisation pour le changement de cadre de référence du SITG - Définir la date approximative (période) de ce changement de cadre de référence. ceci le 2 décembre

22 TESTS DE TRANSFORMATION (fiche 1) Protocole de transformation des données du SITG : Un serveur test MN95 a été créé, il contient les mêmes données que Stévinus (le serveur de l État). Ce serveur test se nomme Glaris. Il a été créé spécialement pour le projet et a pour rôle de stocker les données du SITG transformées en MN95. Nous avons essayé de transformer les données directement de Stévinus à Glaris mais à chacune de nos tentatives le calcul était interrompu. Nous pouvions créer de nouveaux jeux de données mais il ne nous était pas possible d intégrer le fichier résultant du convertisseur directement dans Glaris. Un protocole décrivant les étapes de transformation a donc était créé. Le travail doit d abord être réalisé localement avant d être importé dans le serveur test. A. Convertisseur Topomat extension de ArcGis Cette extension est développée par la société Topomat. C est un outil payant qui s intègre facilement aux autres outils de l ArcToolbox. 1. Création d une GéoDataBase personnelle locale qui recevra les copies des jeux d entités en MN03. (avec toutes les caractéristiques du MN03 : grille de projection CH1903, cf : 5.) 2. Création d une seconde GéoDataBase personnelle en local qui permettra de recevoir les résultats de la transformation en MN95. (avec toutes les caractéristiques du MN95 : grille de projection CH1903+, cf : 5.) 1

23 Remarques : Il est possible de ne faire qu une seule GDB. Elle reçoit à la fois les données en MN03 et les données en MN95. Pour une question d organisation et de clarté, il est préférable de faire deux GDB bien distinctes. Le travail est réalisé localement à cause d une rapidité d exécution plus importante. La transformation des données dont les résultats arrivent directement sur un serveur est beaucoup plus longue qu une simple importation réalisée par la suite. 3. Copier le jeu d entités en MN03 que l on veut transformer dans la GDB locale en MN03 récemment créée (sur l exemple : GDN_copie_stevinus_MN03). 4. Lancer la transformation en ayant choisi : o La classe d entités à transformer o Le fichier de triangles Fineltra o La GDB de sortie et le nom du jeu d entités. (Il est préférable que le nom du jeu en MN95 soit identique à celui en MN03.) 2

24 Remarque : Il n est pas nécessaire de compléter le champ «référence spatiale» lorsque les données transformées sont contenues dans un jeu d entités. Par contre lorsque la classe d entité est directement intégrée dans la GDB, il faut rajouter une référence spatiale pour que l entité en sortie soit bien référencée. 5. Sous Glaris, créer un nouveau jeu d entité en sélectionnant toutes les caractéristiques propres au MN95. Ce jeu devra avoir le même nom que celui en MN03 (le préfixe «MN95_TEST.» lui sera automatiquement implémenté). Remarque : La tolérance d agrégat doit être identique pour le jeu en MN03 et pour celui en MN95. Elle peut varier suivant les données. 6. Importer les classes d entités stockées en local dans le jeu créé sous Glaris. 3

25 Les jeux de données tests ont ainsi été créés. Remarque : Pour les premières transformations le fichier de triangle FINELTRA diffusé par Swisstopo était utilisé. Une liste de temps a été complétée pour toutes les données du cadastre. Pour certaines données les temps de transformation paraissaient trop importants, le shape file original a donc été modifié. Au lieu d avoir des triangles recouvrant toute la Suisse, nous travaillions avec un fichier de triangles se superposant uniquement au canton de Genève. Le fichier résultant de cette modification contenait 1017 triangles alors que l original en comptait sur tout le pays. Lorsque les données de base nécessitaient un nombre plus important de triangles pour être transformées, le fichier original était momentanément réutilisé. Triangles situés sur le canton de Genève Triangles représentant le reste de la Suisse, supprimés pour accélérer la transformation. Définition : Tolérance d agrégat : elle représente la distance minimale à partir de laquelle deux entités (sommets, points) vont avoir les mêmes coordonnées. Deux points dont la distance est inférieure à la tolérance d agrégat vont se superposer l un à l autre. 4

26 B. Reframe (convertisseur gratuit en ligne) Ce logiciel est disponible sur le site Il est possible de utiliser ce logiciel pour des fichiers allant jusqu à 5Mb. Le lien suivant renvoie directement à la page concernée : Des explications sur le protocole d utilisation à appliquer sont intégrées aux pages web. Les formats compatibles avec ce logiciel sont les suivants : LTOP (PK,PE, EL, EM, ED, EN, 3D ou ME), ESRI Shape, DXF, Interlis 1, Topobase.K, Adalin OneOne, ou texte avec séparateur). 1. Sélection du fichier à convertir 2. Sélection de la transformation à appliquer 3. Choix des différents systèmes de coordonnées : MN03 en entrée, MN95 en sortie 4. Calcul Important : Pour les fichiers ESRI shape, le logiciel crée un nouveau.shp. Afin de lire correctement ce résultat, Il faut tout d abord enregistrer un fichier.prj qui correspond à la projection des données et ensuite copier les fichiers.shx et.dbf du fichier en MN03. Il faudra par la suite renommer ces fichiers de la même façon que le fichier en MN95. 5

27 Il suffit de suivre les instructions suivantes : Les résultats obtenus avec les deux logiciels sont identiques. Pour pouvoir réaliser des conversions de fichiers plus importants, il faut télécharger le logiciel complet. Cette opération est payante. 6

28 TESTS DE TRANSFORMATION (fiche 2) Test de comparaison entre les surfaces en MN03 et en MN95 : La modification des surfaces a été étudiée en premier lieu. Deux classes d entités ont été transformées, celle contenant les communes et celle contenant le canton. Après transformation des deux classes d entités concernées, nous obtenons des incohérences dans les surfaces : MN03 Surface (m²) MN95 Surface (m²) COMMUNES CANTON S.(communes)- S.(canton) (en MN03 et en m²) S.(communes)- S.(canton) (en MN95 et en m²) Pour comprendre d où vient l erreur, il est nécessaire de créer des règles topologiques pour nos jeux d entités, en MN95 mais aussi en recréer en MN03. o Sous ArcCatalog, dans le jeu d entités CAD_Communes Click droit dans le contenu Nouveau Topology La tolérance utilisée est identique à celle utilisée par la DCMO. Cette tolérance permet d éviter le dédoublement de points, et lorsqu elle est trop faible, certains points au lieu de s intégrer sur une ligne ou un autre point, subsistent et entraînent des erreurs. 1

29 o Choisir deux classes d entités qui seront concernées par la règle : o Possibilité de choisir un ordre de priorité pour l attribuer aux classes d entités sur lesquelles vont se rattacher la topologie. Les deux classes sur lesquelles nous travaillons ont la même priorité. La valeur 1 leur est attribuée à toutes les deux. Si l une des deux se rattachait à l autre une valeur supérieure à 1 leur serait attribuée. o Choisir les règles topologiques : Les règles de topologie sont décrites dans le logiciel est il suffit de sélectionner la règle qui doit s appliquer aux couches que l on étudie. Nous voulons que les objets de la classe d entités CAD_COMMUNE ne se superposent pas et qu il n y ait pas de trou. 2

30 Les règles topologiques sont désormais chargées et un résumé est présenté. o Visualisation du résultat sous ArcCatalog : Sélectionner sous ArcCatalog la topologie créée puis en sélectionnant l onglet Aperçu on peut visualiser ce qui peut poser problème. On distingue une ligne au centre du canton. Cela signifie que la classe d entité des CAD_COMMUNE que nous avons rapatrié localement présentait des défauts. Il faut le mentionner aux personnes responsables des mises à jour des données de l État. 3

31 Lorsque toutes les modifications ont été apportées, nous avons pu recommencer le processus et obtenir des résultats corrects. Le tableau suivant en découle : MN03 Surface (m²) MN95 Surface (m²) S(MN95)-S(MN03) Somme des surfaces des communes Surface du canton S(Communes)- S(Canton) Après le passage en MN95, on obtient environ 7520 m² de plus que l on en avait en MN03. Un histogramme et la représentation cartographique des différences de surfaces selon les communes permettent de visualiser rapidement les communes ayant subi le plus de modifications. Communes : Les communes qui subissent les modifications les plus importantes sont les communes frontalières avec le canton de Vaud (au Nord) et le coté Est du canton. Il est intéressant de mettre ce résultat en relation avec les triangles Fineltra de tout le canton. ZONE 1 ZONE 2 N Les zones indiquées permettent de voir ce qui peut entraîner les modifications de surfaces, au niveau du canton de Vaud (zone1) la forte densité de petits triangles va perturber le calcul. Au niveau de la zone 2 le nombre de points de référence est moins important, cela a également une incidence sur la transformation. Les surfaces des communes au Nord bougent d avantage que les autres, mais une partie de leur territoire inclut une zone du lac. 4

32 Parcelles : L étude des parcelles a également été réalisée. On ne pouvait pas s attendre à avoir de grandes modifications au niveau des parcelles mais il était intéressant que cela soit fait dans la mesure où l étude est publique. Les parcelles qui subissent le plus de modifications sont particulières, comme celles que l on peut voir dans les exemples ci-dessous. Les propriétaires fonciers peuvent avoir accès à ces informations. Les fichiers créés peuvent être présentés sur demande. 5