Projet

Général

Profil

Actions

Evolution #135

fermé

WMS plage de visibilité et pb échelle

Ajouté par alain ferraton il y a environ 9 ans. Mis à jour il y a plus de 6 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
-
Version cible:
-
Début:
23/05/2016
Echéance:
% réalisé:

0%

Temps estimé:
# ref:

Description

demande de Laurent SAEZ

Une autre évolution intéressante serait que QGIS tienne compte de la plage de visibilité de la couche WMS.
Prenons l'exemple de la couche "scan25" du serveur Géoref métropole (millésime glissant).
Le WMS 1.3.0 GetCapabilities renvoie pour ce layer les infos :
<MinScaleDenominator>10000</MinScaleDenominator>
<MaxScaleDenominator>120000</MaxScaleDenominator>

Exemple : (Géoref Intranet métropole millésime glissant)
http://georef.application.i2/cartes/mapserv?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetCapabilities

Ce serait intéressant que QGIS affecte cette plage de visibilité à la couche et qu'il ne fasse pas d'appel GetMap en dehors de celle-ci.
Pour respecter ces échelles il faudra que QGIS respecte enfin la résolution du standard (1 pixel = 0,28 mm). Et là c'est pas gagné !
Je conseille au développeur de lire les spécifications du standard WMS 1.3.0 et précisément le paragraphe "7.2.4.6.9 Scale denominators" aux pages 27 et 28 qui en plus indiquent un exemple concret.

C'est un peu lourdingue car QGIS n'appelle jamais la donnée à l'échelle qu'il pense solliciter.
J'insiste un peu lourdement mais ce serait quand même intéressant que QGIS respecte réellement la résolution imposée par le standard.

Pour rappel, par exemple pour le calcul du dénominateur d'échelle, en prenant en compte les abscisses, la formule est :
Dénominateur échelle abscisse = (Xmax-Xmin)/largeur image demandée en pixels/taille pixel

Donc si l'outil est conforme au standard WMS 1.3.0 et WMTS 1.0.0 la formule est (valeurs exprimées en mètre) :
Dénominateur échelle abscisse = (Xmax-Xmin)/largeur image en pixels/0,0028
si on parle en terme de résolution, taille pixel en mètre = 0,0254/résolution, la formule devient :
Dénominateur échelle abscisse = (Xmax-Xmin)/largeur image en pixels/(0,0254/résolution)

La résolution du standard est : 0,0254/0,0028 = environ 90,71 ppp

Pour la fenêtre carte QGIS utilise une résolution de 96 ppp pour faire ses calculs des paramètres à envoyer dans ses GetMap.
Pour la composition d'impression il utilise une résolution de 70 ppp pour ses GetMap.
On voit bien qu'il ne respecte jamais le standard et n'appelle donc jamais une couche à la bonne échelle. La bonne échelle étant celle qui respecte le standard et c'est majoritairement le cas des serveurs proposant des données WMS 1.3.0 ou WMTS 1.0.0.

Dans le cas des appels QGIS de la fenêtre carte, la différence avec le standard est de 90,71/96 soit environ 5 % de décalage. Dans ce cas le dénominateur sera plus grand que celui compris par le standard donc l'échelle demandée est plus petite.
Dans le cas des appels QGIS de la composition d'impression, la différence avec le standard est de 90,71/70 soit environ 30 % de décalage. Dans ce cas le dénominateur sera plus petit que celui compris par le standard donc l'échelle demandée est plus grande.
Je pense que les exemples concrets du document que je t'ai transmis sont compréhensibles. L'IGN a compris le problème grâce à lui et travaille sur une solution possible de leur côté.

Tant que QGIS ne respectera pas rigoureusement le standard dans ses GetMap le respect des échelles indiquées par le serveur sera impossible.

Tout est indiqué dans les specs des standards :
- WMTS 1.0.0 : 07-057r7_Web_Map_Tile_Service_Standard.pdf (pages 8 et 9)
http://portal.opengeospatial.org/files/?artifact_id=35326
- WMS 1.3.0 : 06-042_OpenGIS_Web_Map_Service_WMS_Implementation_Specification.pdf (27 et 28).
http://portal.opengeospatial.org/files/?artifact_id=14416

Mis à jour par alain ferraton il y a plus de 6 ans

  • Statut changé de Nouveau à Fermé
Actions

Formats disponibles : Atom PDF