Rapport MN95 - Etat de Genève

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 MN95
Nouveau 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 MN95
Nouveau 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