Pièges courants lors de l'impression de cartes sur le web

Dans cet article, nous décrivons un certain nombre de pièges courants lors de l'impression de cartes à partir d'applications web : résolution insuffisante, impression de grands formats, étiquettes coupées ou redondantes, problèmes d'échelles, inclusion d'informations non géographiques dans les rapports ;

Un cas d'utilisation

Fréquent dans les applications de cartographie Web, l'impression d’informations géographiques affichées dans le canevas de la carte n’est pas si simple. La plupart du temps, la capture d'écran ne donne pas le résultat escompté. Dans cet article, nous allons essayer de montrer pourquoi il est plus compliqué de générer des impressions de carte de qualité professionnelle dans le cadre d'une solution basée sur le Web et discuter de certains des problèmes les plus courants liés à l'impression de cartes Web.

Dans un SIG Web, plusieurs couches sont généralement affichées en même temps. Il peut s'agir d'une couche WMS en arrière-plan ou de l'affichage d'une orthophoto superposée à un WFS contenant des informations vectorielles sur un réseau (par exemple, les routes, une infrastructure réseau, le cadastre des arbres, etc.) Alors qu'une capture d'écran prise directement dans le navigateur montrerait toutes les informations pertinentes sur la carte, le premier problème, la résolution, vient à l'esprit. Afin de générer une image imprimable à haute résolution du canevas de la carte, les couches doivent être rendues avec des informations supplémentaires telles que le rectangle de délimitation et les projections par un processeur séparé. Ce processeur serait considéré comme le moteur d'un service d'impression, qui peut lui-même fonctionner directement dans le navigateur (par exemple Inkmap) ou comme un service dorsal (par exemple MapFish Print). Le service d'impression doit ensuite traiter les différentes sources de données où chaque couche doit être chargée et rendue séparément.

Les couches sont demandées au(x) serveur(s) correspondant(s), les formats WMS/WFS étant considérés comme des formats standard. Lorsqu'on essaie d'imprimer des cartes de grande taille (c'est-à-dire au format A0) dans une résolution décente, l'image demandée devient si grande que les serveurs WMS refusent de la servir et que la taille de l'image ne peut plus être gérée en mémoire. Comme solution, nous pouvons interroger le service WMS en mode mosaïque.

Lors de la composition de la couche cartographique à partir de tuiles, un problème courant se produit lorsque les étiquettes ne sont pas entièrement contenues dans une tuile ou sont rendues plusieurs fois (pour chaque tuile). Une solution potentielle dans ce cas est d'interroger des tuiles plus grandes et/ou de définir une mémoire tampon autour de la tuile, d'interroger cette image plus grande et d'utiliser uniquement la partie non tamponnée pour la carte.

Avec la demande croissante de meilleures performances et d'une plus grande efficacité, de nombreux serveurs fournissent désormais non seulement le WMS mais aussi des tuiles pré-rendues (WMTS), ce qui permet d'accélérer les déplacements et les zooms dans un WebGIS et de réduire l'impact sur l'utilisation de la mémoire.

Une autre exigence importante

... est que toutes les couches affichées dans l'impression soient à l'échelle (par exemple, 1:10’000) et soient correctement affichées dans le système de coordonnées commun défini. Si une couche ne peut pas être demandée dans le système de coordonnées requis (comme spécifié dans le WMS, WFS ou WMTS), le service d'impression doit gérer la transformation des coordonnées.

Outre les services cartographiques communs de l'OGC, d'autres formats doivent être pris en charge par une solution d'impression complète : GeoJSON, GeoTIFF, GML, grille, image ou couches OpenStreetMap (OSM). Outre le contenu géographique du canevas de la carte, des éléments cartographiques essentiels tels que la flèche du nord, la barre d'échelle et la légende doivent également être affichés. Comme pour la légende, il peut être nécessaire d'afficher des tableaux et des informations supplémentaires, notamment lorsque l'objectif est de générer une impression avec de nombreuses informations supplémentaires ou même un rapport de plusieurs pages. Dans ce cas, l'application doit permettre une mise en page détaillée et l'utilisation de modèles ou offrir un outil de configuration approprié. En ce qui concerne le contenu du rapport et des tableaux correspondants, l'outil doit être capable de regrouper les informations de divers attributs provenant de différentes couches et de les afficher correctement dans le ou les tableaux du rapport. Dans certains cas, des restrictions ou des contraintes spatiales doivent être prises en compte lorsque les informations d'une couche (par exemple, les ménages) sont regroupées sur la base d'unités géographiques définies dans une autre couche (par exemple, les municipalités).

Les nombreux défis liés à l'impression de cartes à partir d'applications web montrent que pour répondre aux demandes actuelles liées à la résolution, à la complexité des rapports ou aux formats de données pris en charge, les solutions doivent être en constante évolution et offrir un très haut degré de flexibilité. Nous pensons que ces défis peuvent être relevés au mieux avec des technologies construites en Open-Source et l'effort conjoint de la communauté.