Le problème se situe au niveau du calcul de la BBOX de la couche en coordonnées géographiques (WGS84), dont le résultat est exposé dans la balise EX_GeographicBoundingBox du GetCapabilities. Le calcul de cette BBOX se fait sans vérifier que le méridien d’origine de la projection source de la donnée est bien Greenwich, qui est celui utilisé par le WGS84. Dès lors, si vos données sont dans un système de référence utilisant le méridien de Paris comme origine (les Lambert français de la NTF par exemple, à la différence du Lambert 93 (RGF93) qui utilise Greenwich plus un décalage), la BBOX en WGS84 sera erronée car décalée de plus de 2 degrés vers l’ouest.

Bon, mais qu’est-ce que ça change en pratique ? Je suis sûr que nombre d’entre vous ont déjà utilisé MapServer en WMS 1.3.0 sur ce type de projection sans rencontrer de problème… Il se trouve que certains logiciels clients WMS (l’excellent QGis notamment), plus malins que d’autres, se servent de cette information pour déterminer l’emprise de la couche (quelle que soit la projection utilisée pour l’affichage d’ailleurs), et n’envoient donc pas de requête au serveur WMS quand la vue se situe à l’extérieur de cette emprise, afin de ne pas solliciter inutilement le serveur. Finaud donc. Si vous publiez des données France entière, il y aura recouvrement, et donc pas de problème (à moins peut-être de zoomer sur Strasbourg par exemple. A tester sur vos services WMS 1.3.0 préférés avec QGIS. J’en ai déjà trouvé un…). Mais si l’emprise de vos données est suffisamment étroite (une agglomération par exemple), vous ne verrez tout simplement rien là où vous comptiez les voir apparaître, car d’après le GetCapabilities les données ne se trouvent pas là du tout. Vous ne verrez non seulement rien, et certainement pas d’erreur, et vous risquez de passer quelque temps (je parle d’expérience) à vous creuser la tête pour comprendre ce qui ne va pas dans votre configuration. Sauf que la configuration va bien. Là où ça devient énervant, c’est que les clients WMS qui envoient comme des bourrins des requêtes au serveur où qu’on se situe, ignorant par là la présence et le rôle de la balise EX_GeographicBoundingBox, ces barbares donc, vont eux recevoir une réponse correcte, puisque la reprojection de la donnée elle-même fonctionne normalement. Funeste sort que celui des clients WMS les plus exigeants, les plus respectueux de l’esprit de l’inter-opérabilité, induits ainsi en erreur par un calcul approximatif.

Mais heureux dénouement qui voit les lecteurs assidus de ce blog non seulement informés mais dépannés par un patch tout frais déposé sur le bug-tracker de MapServer ! Pour l’utiliser, il suffit de l’appliquer (commande patch mapows.c wms_1.3.0.patch) au fichier source puis de recompiler et remplacer son mapserv par le nouveau. Il devrait également être rapidement disponible dans la version officielle.

C’est plutôt complet, un peu aride diront les esthètes, mais c’est surtout mis à jour régulièrement.

Merci à Stephan Steiniger pour cette réalisation fort utile.

Retour du cmake : la non détection de certains modules pourtant installés sur le système se règle soit en vérifiant que les versions de dév des packages sont bien installées (pour Grass par exemple), soit en allant faire un tour dans les fichiers du répertoire cmake et en changeant les chemins par défaut. Ce n’est pas le plus compliqué. Bien vérifier que la version de QT utilisée est la 4.

Compilation : la compilation avec l’option « python-bindings », qui permet d’intégrer la prise en charge du python, et le fonctionnement du plug-in Grass entre autres, m’a posé problème. Une erreur et son message un peu ténébreux bloquaient le processus :

Error: Unable to open « /opt/qgis/python/core/core.sbf »: [Errno 2] No
such file or directory: ‘/opt/qgis/python/core/core.sbf’

Malgré quelques recherches sur le net, je ne trouvais rien si ce n’est une autre personne ayant eu ce problème, resté alors sans réponse. Voyant que l’erreur en question se produisait lors de la compilation avec QT et SIP, j’ai fait quelques recherches de ce côté-là. SIP est le module qui permet de créer une interface Python vers des bibliothèques C++, un peu comme SWIG donc. Le wiki de QGis a un article là-dessus. Il est indiqué que la version doit être au moins la 4.5, ce qui n’était pas le cas sur mon système (mais d’où venait ce paquetage ?).

J’ai donc compilé les versions indiquées en lien par le wiki, pour SIP et pour PyQT. La compilation est alors allée jusqu’à son terme, et QGis fonctionne correctement avec le module Grass et la console Python.

C’est avec un certain retard sur le planning initial que l’équipe de QGis vient d’annoncer la sortie de la nouvelle version 0.9.0., nom de code Ganymède, avec, entre autres, au menu :

- L’intégration de python qui permet d’écrire des plugins dans ce langage mais aussi d’utiliser les modules Qgis dans un programme Python
- L’ajout de nouveaux outils Grass
- Une amélioration des possibilités de rendu des cartes, avec notamment la possibilité de faire des classifications par quantile, plus utile que les seules amplitudes jusqu’alors disponibles. Pour les autres méthode (Standard, Moyennes emboîtées, Lognormale, Géométrique, toutes bien pratiques pour classifier des données statistiques), on attendra encore un peu…
- Une refonte des librairies principales, qui améliore sensiblement les performances, notamment dans la manipulation de lourdes couches de données.

Côté installation, de nombreux paquetages sont déjà prêts (Ubuntu, Debian, OpenSuse, Mac OS X et Windows), disponibles ici.

J’ai réalisé l’installation à partir des sources, sans pouvoir intégrer le support Python du fait d’une erreur à la compilation. Le cmake, qui remplace le configure, recherche les installations de python, postgresql, grass et autres. Si le compte-rendu du cmake indique qu’il n’a pas trouvé un composant que vous savez être installé sur le système, un petit tour du côté des fichiers du répertoire cmake peut vous aider : FindGEOS, FindGRASS, FindPostgres, FindProj peuvent être édités manuellement de manière à aider le cmake à retrouver les librairies nécessaires. Au final, l’install est très propre, de même que le uninstall. Par contre, le module Grass n’a pas été installé, malgré la prise en compte des librairies grass-dev pour le make.

Après quelques tests, la véritable plus-value de cette édition se situe du côté des performances, nettement améliorées dans la manipulation de gros fichiers, pour peu qu’on bâtisse un index spatial de la couche en question. Le module de géoréférencement gagne aussi en ergonomie.

Bravo à toute l’équipe de Qgis pour cette nouvelle version.