Page 1 sur 13

Changement de cadre de référence sur les geodonnées de l'Etat de Genève

MN03 - MN95

Rapport sur le déroulement de l'opération réalisée par le centre de compétence du SITG

M Terrond / SOSI Juillet 2011

Page 2 sur 13

PREAMBULE Le geodonnées gérées par divers services de l'Etat de Genève sont centralisées dans trois instances de base de données Oracle, dans un modèle de geodatabase "SDE". C'est ce que l'on nomme le serveur "Métier". Ces données sont répliquées hebdomadairement sur un serveur dit "de Consultation" constitué de deux instances Oracle, également dans un modèle de geodatabase "SDE". Lors de cette réplication, les geodonnées des autres partenaires du SITG sont ajoutées à celles de l'Etat de Genève. Une geodatabase SDE de test est également disponible. Toutes ces données étaient jusqu'à présent référencées dans le cadre CH1903_LV03 (MN03). L'Office Fédéral de Topographie obligeant les cantons à référencer leurs geodonnées dans le cadre de référence CH1903+LV95 (MN95) d'ici à 2016. En mars 2011, le Conseil d'Etat a adopté un arrêté autorisant le changement de cadre de référence et confié cette mission au SOSI (Service de l'Organisation des Systèmes d'Information), centre de compétence du SITG. Le comité directeur du SITG à décidé d'opérer ce changement en juin 2011, en accord avec les autres partenaires du SITG qui doivent également procéder à ce changement sur leurs infrastructures.

ARCHITECTURE TECHNIQUE

Les bases de données géographiques sont installées sur la version Oracle 11g et SDE 9.3 (ESRI) dans une architecture d'utilisation selon trois tiers :

Serveurs IBM AIX pour les bases Oracle 11g Serveurs SunSolaris pour SDE9.3 PC Windows avec ArcGis desktop 9.2 pour les utilisateurs

22.07.2011 - Page 5

Service de l'organisation et des systèmes d'information

Département de l'Intérieur et de la Mobilité

Nouveau cadre de référence MN95Nouveau cadre de référence MN95

Nos Bases SDE

Deux bases de

production "Métier"

Deux bases Consultation

"Load" et "Consult"

Une base de test

785 couches dans 140 jeux de données

8'500'000 objets

360'000'000 de paires de coordonnées

2x 575 couches de données

Page 3 sur 13

ELEMENTS PRIS EN COMPTE

Volumétrie L'ensemble des données du serveur "métier" représente plus de 8 millions d'objets classés dans environ 800 classes d'entités. Plus de 360 millions de paires de coordonnées doivent ainsi êtres recalculées. L'ensemble des données du serveur "Consultation" représente plus de 7 millions d'objets dans environ 600 classes d'entités. Plus de 300 millions de paires de coordonnées doivent êtres recalculées. Le serveur de consultation étant composé d'une instance de "chargement temporaire" et de son double en instance de "consultation", les deux bases sont à traiter.

Données géographiques Nos bases de données géographiques sont composées d'entités traditionnelles telles que :

Points, Lignes et Polygones, mais également de : Annotations Raster Grid Tables Relations Réseaux Règles topologiques Triggers Séquences Comptes utilisateurs et droits associés.

Autres éléments impactés

Quelques applications WEB alphanumériques "traditionnelles", dans lesquelles des coordonnées sont stockées dans des tables d’attributs.

Des appareils GPS, incluant des GPS embarqués dans des outils mobiles. Un environnement "métier" composé de scripts SQL, Python, FME/FMW.

Impact sur la production quotidienne Afin de minimiser au maximum l'arrêt de la production pour les utilisateurs du système d'information géographique, le passage à MN95 à été planifié sur le week-end du 11/12 juin 2011, suivi du lundi 13 (jour férié) en ce qui concerne les 3 instances du serveur métier, et le week-end suivant pour les 2 instances de consultation. Les diverses applications, scripts ou autres paramétrages ont été adaptés simultanément. Les utilisateurs doivent reprendre leur travail quotidien, en principe sans s'apercevoir du changement.

Outils à disposition

Une fonction "ArcToolBox" développée spécialement pour la transformation des entités géographiques Point/Ligne/Polygone/Annotation, utilisant la dll "Reframe" fournie par SwissTopo. Cette fonction traite une couche après l’autre, directement dans une base SDE 9.3 ou une Geodatabase de type .mdb. Elle modifie les données au cœur de la base, sans produire un "doublon". Les couches Topologies et Réseaux ne sont pas traitées par cette fonction, elles devront être supprimées et recréées après transformation.

FME, outil de type ETL et le transformer "ReframeReprojector" de SwissTopo. Language SQL (en scripts) Language Python (en scripts)

Page 4 sur 13

TRAVAUX PREPARATOIRES

Recensement des éléments impactés

Recensement des données VECTEUR devant êtres converties ou non (dont quelques unes en "Lambert") Recensement des données RASTER devant êtres converties ou non (dont quelques unes en "Lambert") Recensement des données GRID devant êtres converties ou non (dont quelques unes en "Lambert") Recensement des Attributs (colonnes) contenant des coordonnées X-Y à convertir, aussi bien dans les

couches de données géographiques que dans des tables non-géographiques (manuellement). Recensement des relations (liste obtenue par script SQL) Recensement des règles de topologies (liste obtenue par script SQL) Récupération de toutes les propriétés des règles de topologie par "print-screen" Recensement des réseaux (liste obtenue par script SQL) Récupération de toutes les propriétés des règles de réseaux par "print-screen" Recensement des droits utilisateurs (liste obtenue par script SQL) Recensement des applications "Cartographiques" à adapter Recensement des applications "Alphanumériques" manipulant des coordonnées XY

Élaboration de scripts SQL

Les paramètres des relations étant explicites dans différentes tables de la geodatabase, il est possible de réaliser un script SQL pour récupérer les paramètres et les inscrire dans un un fichier .txt (ce fichier sera ensuite utilisé par un script Python pour reconstituer les différentes relations, après la transformation MN95).

Élaboration de scripts Python

Pour générer un script de création des relations (ArcToolBox) par reprise du résultat produit par le script SQL (.txt, cf. ci-dessus)

Pour générer plusieurs scripts de transformation des données en cadre MN95, par lecture de toutes les couches de la base et génération d'un nombre de scripts d'exécution selon un paramètre.

Élaboration de scripts FMW (FME Workbench)

Pour la transformation des coordonnées contenues dans des colonnes de tables. Pour établir des statistiques basées sur les fichiers .log de la transformation MN95 (durées, erreurs, etc ). Pour modifier automatiquement les fichiers de calage des images raster (.tfw) (pour les images de faibles

résolution)

PHASE DE TESTS

Les tests se sont déroulés sur un environnement identique à celui de production (Machine/Oracle/SDE). Les données ont été copiées sur la base de test en utilisant la fonction Copier/Coller d'ArcCatalog. Cette copie de données s'est faite plusieurs fois, en totalité ou en partie, selon les tests à effectuer.

Le but de la phase de test était de :

Mettre au point de façon définitive la fonction de conversion développée par Topomat Technologies. Contrôler le bon fonctionnement général de la base SDE après transformation MN95 Tester les différents scripts SQL et Python Mesurer les temps nécessaires pour les différentes étapes Trouver des solutions aux différents problèmes inévitablement rencontrés Valider certaines décisions.

La phase de test a permis de mettre en évidence que le fait d'avoir des relations entre tables (environ 100 relations) augmentait considérablement le temps nécessaire à la transformation MN95 pour les couches concernées. La

Page 5 sur 13

décision à donc été prise de supprimer les relations et de les recréer ensuite. Un script SQL et Python ont été développés dans ce but. Sur la base des mesures effectuées, le temps global nécessaire à la transformation des 800 couches de données est d'environ 40 heures. Une répartition sur 4 PC a été testée avec succès, soit environ 10 heures sur chacun des PC engagés simultanément. Sur cette base il a été estimé que la totalité des opérations pouvait être opérée sur 3 jours pour les données du serveur métier et sur 2 jours pour celles du serveur de consultation.

Conversion des données VECTEUR, base de test La méthode de test mise en place à été la suivante :

1. Génération de 40 scripts Phyton , chacun exécutant la transformation de 20 couches de données directement sur la base SDE de test.

2. Répartition de ces 40 scripts sur 4 PC "ArcGIS Desktop" (10 par PC). 3. Exécution des 40 scripts 4. Récolte des fichiers .log et analyse des erreurs, calcul des durées par script FME. 5. Trouver la cause des erreurs, appliquer les corrections ou des parades (workaround). 6. Vider la base test et recharger les données du serveur métier 7. Recommencer le tout plusieurs fois.

Afin de tester la conversion sur le serveur SDE de production, quelques couches y ont été copiées sous un autre nom. La conversion à été faite avec succès.

22.07.2011 - Page 11

Service de l'organisation et des systèmes d'information

Département de l'Intérieur et de la Mobilité

Nouveau cadre de référence MN95Nouveau cadre de référence MN95

Mise en œuvre de la solution

Base de donnéesScript

python

Génère un script

par "dataset"

(135)

Dispatch des scripts sur 4 PC

Exécutions

simultanées

Temps global mesuré sur la base test : 10heures

Conversion des données RASTER La transformation MN95 des données raster s'est faite de façon anticipée, ce type de donnée n'étant pas mis à jour fréquemment. Trois types de transformation ont été utilisés, en fonction de la précision (taille du pixel) et de la couverture géographique :

Soit par simple ajout de 2000 km et 1000 km dans les fichiers de calage .tfw (notepad ou script fme) pour les images à faible résolution, pixel de 1m à 50m

Page 6 sur 13

Soit par mise à jour de la géoréférence contenue dans le fichier .tif (GeoTIFF Tools) Soit par recalculation, pixel par pixel (FME et transformer Reframe de SwissTopo), pixel de 10cm à 50cm

Les images ainsi transformées ont été stockées avec leur nom original suffixé de _MN95.

Conversion des données GRID La transformation MN95 des données GRID s'est faite de façon anticipée, ce type de donnée n'étant pas mis à jour fréquemment. La taille minimale d'une cellule des données GRID du SITG étant de 1m, la conversion s'est faite de la façon suivante:

Exportation du GRID en fichier texte .asc (ArcToolBox) Edition du fichier .asc avec un éditeur capable d'ouvrir un fichier de plus de 2GB. (trouvé sur internet) Modification de la paire de coordonnées de l'entête Importation du fichier texte en GRID (ArcToolBox)

Les GRID ainsi transformés ont été stockés avec leur nom original suffixé de _MN95.

Établissement d'un planning des opérations Les tests ont démontré que le changement MN95 pouvait être effectué en 3 jours pour les données du serveur métier et en 2 jours pour celles du serveur de consultation. Toutes les phases de l'opération ont été planifiées pour être effectuées en dehors des heures d'exploitation normales, aucune connexion "utilisateur" ne devant être ouverte lors des opérations. Planning pour le serveur "Métier" Jeudi

S'assurer auprès des personnes compétentes qu'un backup complet de la base est bien réalisé et exploitable. Un test de restauration a été fait afin de confirmer ce fait.

Vendredi soir

Stop/Start de la base SDE Copie intégrale de la base en format Geodatabase-file ESRI 9.3 (ArcCatalog) Sauvegarde de la copie sur DVD Suppression du versionnement, des règles de topologie, des réseaux, des relations sur la base SDE. Début de l'exécution de la transformation MN95 par les scripts Python.

Samedi Suite de l'exécution de la transformation MN95 par les scripts Python. Analyse des fichiers .log

Dimanche Reprises de couches signalées en erreur Création des règles de topologie, des réseaux, des relations sur la base SDE. Remise du versionnement Remplacement des Raster et GRID CH03 par les versions MN95 Mise à jour des attributs contenant des coordonnées X-Y

Lundi Tests divers de bon fonctionnement de la base de production

Page 7 sur 13

Transformation MN95Planning général SERVEUR METIER

Chargement des données GRID MN95 (avec un nom préfixé Z, droits PUBLIC)

Execution des scripts SQL et Python pour : Liste des Topologies et réseaux avec leurs paramètres

Liste des couchesListe des relations GENERATION TOUTES relations pour python (SQL )GENERE creation relations (Python)

Générer les scripts Python de transformation sur le PC1 et répartir sur les 4 PC.

1311 18 194 5

juin

127 86

Transformation MN95Planning général SERVEUR METIER

Création topologies, réseaux, relationsRegister as versioned des couchesSuppression des Raster et Grid CH03 et renommer les MN95

Transformation CH03>MN95 et début des corrections

Dès jeudi 16h30Compress des trois instances, Unregister versionedCopie de toutes les données en base locale .gdbSuppression relations, topologies réseaux

1311 18 194 5

juin

12

Génération scripts python d'exécution et Sql. Divers, répartition sur les 4 PC Chargement données GRID et RASTER

Vues SDE, triggers, tests

Page 8 sur 13

MN95PLANNING QUOTIDIEN SERVEUR LOAD et BASE .GDB

Transformation MN95 instance de chargementEt base locale des guichets Topomaps

1311 18 194 5

juin

12

Méthodes:

Générer des bases locales .mdb depuis le serveur de consultation

Transformer MN95 ces bases sur les 4 PC (scripts python)

Analyser les fichiers .log / Résoudre les problèmes

Supprimer toutes les couches de l'instance de chargement

Copier/Coller avec Arc-Catalogue les couches depuis les bases transformées .mdb MN95

Mettre à jour la base locale des guichets Topomaps

Page 9 sur 13

MN95PLANNING DETAILLE SERVEUR CONSULTATION

Transformation MN95 instance de consultation

1311 18 194 5

juin

12

Supprimer toutes les couches géographiques du serveur CONSULTATION

Copier/Coller les donnée depuis le serveur de chargement (ArcCatalogue)Recharger les 8 dataset particuiers depuis la base locale 8datasets_consultation_mn95.gdbSupprimer les anciennes couches GRID et RASTER et renommer les nouvelles (enlever Préfixe Z)Donner les droits PUBLIC par le script sde sur toutes les couchesRégler les droits non PUBLIC (supprimer public et ajouter les bons droits)

18

MN95PLANNING DETAILLE SERVEUR CONSULTATION

TESTS

1311 18 194 5

juin

12 19

Adapter les fichiers pour l'extracteur de données (choix du cadre par défaut inversé)

Tester les extractions

Adapter et tester les guichets Topomaps

Exporter et transférer les données pour les partenaires

Recalculer les indexs et autres (performances) (scripts SDE)

Page 10 sur 13

PASSAGE EN CADRE DE REFERENCE MN95 POUR LA PRODUCTION La transformation réelle et complète sur la base de production est une opération complexe qui n'avait pas pu être testée. Notre environnement de test n'était pas un clone parfait de l'environnement de production. Serveur Métier: Les différentes étapes ont été réalisées comme prévu entre le vendredi 17h et le lundi (jour férié). Deux collègues du SOSI ont travaillé à ces différentes tâches. Serveur Consultation: Les différentes étapes ont été réalisées comme prévu. D'abord la base de chargement, en cour de semaine, car pas de connections utilisateurs, ensuite la base de consultation le week-end , ainsi que les adaptations sur l'extracteur de donnée et les guichets cartographiques. Deux collègues du SOSI ont travaillé à ces différentes tâches.

Problèmes rencontrés lors de l'opération

Problème 1 - Domaine spatial trop petit ! Dès le lancement des premiers scripts de conversion MN95, les fichiers .log ont montré que certaines couches de données ne pouvaient pas être converties, un message indiquant que "le domaine spatial était trop petit". Les autres couches étaient transformées avec succès. Après analyse du cas particulier, il s'est avéré qu'une résolution trop élevée ne pouvait pas supporter le changement de cadre de référence, celui-ci élargissant fortement le domaine d'étendue d'acceptation des coordonnées, impliquant une résolution moindre. Un exemple de résolution problématique est : 0.000004653 Les couches de données problématiques avaient été créées dans la base SDE dans des versions antérieures à 9.0 et migrées de v8 en v9.x jusqu'en v9.3 sans que cela ne pose le moindre problème. A l'époque, seul le mode "low_precision" était possible. Toutes les couches de données avaient été transformées en mode "high-precision" précédemment à l'opération MN95. La phase de test n'avais pas permis d'identifier ce problème, car les données avait été "copiées/collées" avec ArcCatalog entre le serveur métier vers le serveur de test. Lors de cette opération, le système adapte automatiquement la résolution.

Page 11 sur 13

( résolution correcte)

domaine correct

Page 12 sur 13

Solution trouvée pour transformer ces couches problématiques Le simple fait de "Copier/Coller" ces couches d'une géodatabase dans une autre est la solution. Nous avons donc copié ces couches dans une géodatabase-file ESRIV9.3, ensuite supprimées du serveur SDE de production et rechargées depuis la base locale. Les droits utilisateurs (S ou SUID) ont également dû être remis. La conversion MN95 a ensuite fonctionné correctement.

Problème 2 - Création de certaines relations ! Tous les paramètres des relations ont été sauvegardés par script SQL et un script Python a été développé pour la création automatique de ces relations après transformation. Les tests sur la création de plusieurs relations avaient tous été concluants. Cependant, lors de la création des relations sur la base de production, quelques unes n'ont pas pu se créer, la fonction ArcToolBox donnant le message suivant :

Erreur dans la relation : RELATION_CONSTAT_DEGAT ERROR 999999: Error executing function. A locator with this name does not exist. Failed to execute (CreateRelationshipClass).

Après investigation, il s'agissait de relations créées normalement avec ArcCatalog. Une des deux tables était "hors-dataset". Ensuite la relation avait été "glissée" dans un "dataset". Le SQL d'exportation des paramètres avait bien mentionné la relation à l'intérieur du dataset, mais la création d'une relation ne peut pas se faire si une des deux tables est "hors dataset".

Solution trouvée pour créer ces relations Simplement modifier les paramètres du script Python pour créer la relation "hors-dataset". La transformation des données sur le serveur de consultation planifié la semaine suivante s'est déroulée comme prévu, quelques adaptations ayant été faites en cours de semaine sur la base de la transformation du serveur de production menée précédemment.

RECOMMANDATIONS Afin de garantir le succès d'une telle opération, quelques recommandations peuvent êtres faites:

S'assurer d'un bon backup de la base de donnée, et que celui-ci puisse être exploité. Un test de restore sur un backup le plus récent possible est indispensable. C'est la garantie qu'en cas de gros problèmes on puisse annuler l'opération sans dommages.

S'assurer que les personnes "de piquet" soient informées de l'opération et bien disponibles le cas échéant

(DBA, Spécialiste réseau et ingénieur système). S'assurer qu'aucune intervention sur les équipements électriques, réseaux ou autres ne soit planifié

simultanément, risquant de couper les processus en cours. Disposer d'un environnement de test, afin de pouvoir tester toutes les parties de l'opération sans risque de

dommage aux données de production.

Page 13 sur 13

Disposer d'une copie des données autre que celle du backup de la base SDE. En effet, il est impossible de restaurer qu'une seule couche de donnée à partir d'un backup, la géodatabase complète formant un tout indissociable. En général, le restaure d'un backup nécessite beaucoup de temps. Une copie des données dans un format type Geodatabase-file peut ainsi s'avérer très utile s'il faut "restaurer" qu'une seule couche de données ou simplement visualiser la couche et ses paramètres.

Tester la transformation MN95 sur des données issues du restore d'un backup ou d'une copie physique des

fichiers. Ce test (que nous n'avons pas fait) nous aurait permis de détecter le problème " Domaine spatial trop petit".

Pour rappel, nos données de test avaient été "Copiées/Collées" avec ArcCatalog. Tester les diverses étapes sur le 100% des données (c'est ce que nous avons fait pour la conversion MN95

des données géographiques). Par contre, pour la création automatique des relations, nous ne les avons pas toutes recréées, et c'est

parmi celles non testées que nous avons rencontré le problème (Erreur dans la relation : RELATION_xxxxx)

Assurer une bonne communication avec les personnes utilisant les données géographiques, que se soit en

interne à l'administration aussi bien qu'avec les utilisateurs externes (séance d'information, messagerie, site internet , etc).

Collaborateurs du SOSI ayant participé aux travaux: Michel Terrond Adrien Vieira-de-Mello Pierre Lafontaine Markus Kesseler Andreas Stussi Pour toutes questions sur ce sujet, vous pouvez contacter : Michel Terrond, ingénieur en géomatique SOSI -DIM, Etat de Genève Centre de compétence du SITG michel.terrond@etat.ge.ch