Geospatial – Actualités

MapServer et GDAL/OGR avec proj4.8.0 et les nouvelles projections suisses

10 novembre 2015

Introduction

Il y a quelques semaines, nous avons posté un article présentant une des nouveautés de la bibliothèque Proj4 : la possibilité de reprojeter des données de la projection CH1903/LV03 vers CH1903+/LV95 en utilisant une grille de transformation fournie par Swisstopo. Cet article est son complément technique. Nous allons décrire comment utiliser cette grille de reprojection en utilisant les outils Open Source les plus utilisés dans le monde géospatial.

Cet article n’a pas pour objectif de décrire le fonctionnement interne des bibliothèques et des applications Open Source ni de faire une présentation des projections de manière précise. Certaines approximations sont ainsi faites dans cet article et nos lecteurs avertis voudront bien nous pardonner.

Installation

Pour utiliser la grille de transformation de Swisstopo, il vous faut une version récente de Proj4 (>= 4.8.0) et récupérer la grille à partir du site de Swisstopo. Le fichier CH qui contient les codes de reprojection permettant l’activation de la grille décrit la marche à suivre dans son en-tête.

Vous devez télécharger la grille et la placer dans le répertoire de données lu par libproj. Plusieurs possibilités vous sont offertes pour cela :

  • ajouter le fichier dans le répertoire /usr/share/proj/ (installation standard sous linux) ;
  • placer le fichier dans un répertoire quelconque et le définir dans la variable d’environnement PROJ_LIB.

Fonctionnement de la reprojection

Plusieurs questions apparaissent généralement au sujet des reprojections en utilisant une grille de transformation.

La première, automatique : pourquoi est-ce que l’utilisation du code EPSG ne permet-il pas d’avoir une reprojection précise ? Parce que ce dépôt de code, réalisé par l’OGP, n’utilise pas ces grilles dans les définitions des projections. Si nous souhaitons les utiliser, il faut modifier le dépôt EPSG (et recommencer le travail à chaque mise à jour du dépôt) ou créer un dépôt alternatif national. C’est ce que nous avons fait pour les projections suisses en suivant l’exemple de l’IGN pour la France.

La deuxième question arrive un peu plus tard, lorsque le géomaticien commence à travailler avec ses outils préférés et étudie le fichier de dépôt des nouveaux codes :

# CH1903/LV03
<1903_LV03>  +proj=somerc +lat_0=46.95240555555556 +lon_0=7.439583333333333 +k_0=1 +x_0=600000 +y_0=200000 +ellps=bessel +units=m +nadgrids=chenyx06etrs.gsb +no_defs

Seul le code de l’ancienne projection contient le paramètre magique +nadgrids=chenyx06etrs.gsb qui permet effectivement d’utiliser la grille de transformation (ce fichier gsb justement). L’explication est assez simple : Proj4 reprojette systématiquement les données en passant par l’ellipsoïde WGS84. La nouvelle projection suisse étant compatible avec celle-ci, la perte de précision est due au changement vers l’ellipsoïde WGS84. La grille de transformation permet de corriger ces erreurs.

GDAL/OGR

Avant d’aller plus loin en présentant la configuration de MapServer, commençons par reprojeter des données vers la nouvelle projection. Il suffit simplement de préciser l’ancienne projection en utilisant le dépôt CH :

ogr2ogr -s_srs "+init=CH:1903_LV03" -t_srs "EPSG:2056" PLZO_OSNAMEPOS_lv95ogr2 PLZO_OSNAMEPOS.shp

Le dépôt EPSG présente l’originalité de ne pas avoir besoin de la chaîne « +init= » (chaîne nécessaire pour la définition de la projection pour proj4). En effet, pour ce dépôt spécifique, un alias a été créé simplifiant l’écriture.

MapServer

Nous allons maintenant présenter deux cas de service WMS. Le premier a pour objectif de créer un flux WMS dans la nouvelle projection à partir de données dans l’ancienne projection. La deuxième est assez similaire puisqu’elle présente l’utilisation de MapServer comme client WMS d’un autre service WMS pour reprojeter le flux vers la nouvelle projection.

Serveur WMS LV03+/MN95 avec des couches dans une autre projection

La configuration de MapServer, dans ce cas-là, ne change que très peu d’un cas classique. La configuration de la couche ne change absolument pas mais il est important, dans le cas d’une reprojection, de bien définir la projection en utilisant le bon dépôt :

LAYER
  NAME cantons
  TYPE POLYGON
  DATA cantons_ch.shp
  PROJECTION
    "init=CH:1903_LV03"
  END
  CLASS
   NAME "Cantons"
   STYLE
     COLOR -1 -1 -1
     OUTLINECOLOR 200 200 200
   END
  END
  METADATA
    "wms_title" "cantons"
  END
END

Il faudra définir la projection également au niveau de l’objet MAP :

MAP
  NAME "Limites administratives Suisses"
  PROJECTION
    "init=epsg:2056"
  END
  [...]
END

WMS client en 21781 vers LV03+/MN95

MapServer a la capacité de se comporter comme un client WMS. Cela permet d’avoir une sorte de Proxy cartographique et de rediffuser des couches d’un flux externe vers une application cliente via un seul flux WMS dans lequel nous trouverons des couches stockées dans d’autres formats (bases de données ou fichiers locaux).

La définition d’un mapfile pour ce genre de couche est le suivant :

LAYER
  NAME "cantons"
  TYPE RASTER
  STATUS ON
  CONNECTION "http://monhote.com/wms?"
  CONNECTIONTYPE WMS
  PROJECTION
    "init=CH:1903_LV03"
  END
  METADATA
    "wms_srs"             "EPSG:21781" # projection
    "wms_name"            "cantons" # nom de la couche pour l'appel WMS
    "wms_server_version"  "1.1.1" # version pour l'appel WMS
    "wms_format"          "image/png" # format pour l'appel WMS
    "wms_title"           "canton"
    "wms_extent"          "537686 150057 548139 159018" # optionnel
  END
END

La couche est donc appelée via un flux WMS en 21781 mais définie en CH:1903_LV03 au niveau du mapfile. L’objet MAP contiendra la même projection que précédemment :

MAP
  NAME "Limites administratives Suisses"
  PROJECTION
    "init=epsg:2056"
  END
  [...]
END

Conclusion

Il est maintenant possible d’utiliser la projection suisse avec la nouvelle mensuration effectuée en 1995 au sein des différentes applications Open Source avec des données hétérogènes dans leur projection sans perte de précision. Toutefois, cette perte de précision est faible (submétrique) et en tout cas suffisamment faible pour la plupart des utilisateurs. Aussi, cette présentation ne sera utile qu’au personne qui ont cette problématique dans la gestion de leur données et nous espérons que les solutions présentées leur seront profitables. N’hésitez pas à commenter l’article pour ajouter toute information que vous jugerez opportune.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *