Guide de référence utilisateur

Géo-IDE Carto2 est une application centralisée hébergée en centre serveur. L'accès au portail de composition de cartes est soumis à authentification Cerbère.

Le profil "Producteur" pour l'application "geoide-carto2" peut être fourni par l'administrateur de service (AS) Cerbère de votre organisation ou par un ASD (administrateur de service délégué) qu'il a désigné. C'est bien souvent le SIDSIC qui peut soit affecter le profil, soit aiguiller vers la bonne personne. Contacter l'assistance si cette piste ne permettait pas d'identifier cet administrateur.

L'application répond l'erreur suivante lorsque je veux ouvrir une carte :

Il est fort probable que le jeton de session soit expiré et donc l'utilisateur déconnecté. Faire Ctrl+F5 au clavier, et se ré-authentifier

Si cela ne résout pas le problème, contacter l'assistance en précisant le message d'erreur exact et les circonstances dans lesquelles il est rencontré

Ce message indique que les services du serveur Cartographique permettant d'afficher les couches ne sont pas disponibles

Les différentes situations suivantes peuvent être rencontrées :

• Ce message n'apparaît que dans une seule couche ou dans un nombre limité de couches => corriger chaque couche incriminée :

  1. Ajouter à nouveau la coucher à la carte

  2. Utiliser la fonction de duplication de styles (glissé-déposer à partir du patrimoine de style) pour appliquer les styles existant sur la nouvelle couche

  3. Supprimer la couche corrompue

• Ce message apparaît sur l'ensemble des couches d'une carte MAIS que d'autres cartes du patrimoine sont fonctionnelles, utiliser la fonction de réparation de carte afin de resynchroniser la carte avec la configuration du serveur cartographique

• Ce message apparaît sur l'ensemble des couches d'une carte ET sur l'ensemble des cartes du patrimoine (aucune couche ne s'affiche sur aucune carte), cela signifie que l'application rencontre un problème (le serveur cartographique est indisponible) : attendre le rétablissement de la situation

Géo-IDE Carto2 permet d'exploiter les jeux de données aux formats :

• Formats vecteur supportés :

  • ESRI ShapeFile
  • MapInfo TAB

• Format raster supporté :

  • GéoTiff

  NB : L'exploitation d'un JDD au format GéoTiff par Carto2 n'est possible qu'en lecture seule, ce qui en permet l'affichage des pixels sur la carte. Il n'est en revanche pas possible d'effectuer des traitements raster sur les pixels (analyses thématiques, colorisation des pixels en fonction des valeurs sur les différents canaux...)

L'ajout d'un jeu de données comportant un grand nombre d'objets peut demander des traitements très importants et ainsi mobiliser énormément de ressources pour le moteur cartographique. Nous pouvons considérer qu'un jeu de données vecteur comportant plus de 15 Mo d'objets devient lourd à traiter. Une première solution consiste à générer un fichier d'index avec QGIS (.qix) qui devra être systématiquement mis à jour et répliqué avec les autres fichiers constitutifs du JDD

Par ailleurs il n'est pas utile de visualiser un tel nombre d'objets simultanément

Tout comme lors de l'intégration d'une couche WFS, il est indispensable de prendre des précautions quant à l'échelle courante lors de l'ajout d'une couche issue d'un jdd volumineux dans le back-office puis de paramétrer systématiquement des plages de visibilité dès l'ajout de la couche

Exemple : Je souhaite ajouter une couche issue d'un JDD comportant de nombreux objets

1/ Je me place à une échelle proche du terrain, de l'ordre du 1/50 000 ème

2/ J'ajoute la couche à ma carte

3/ Dans les paramètres avancés de la couche, je définis pour commencer, une plage d'échelle du 1/50 000 ème au 1/100 ème

4/ J'ajuste la plage d'échelles de la couche pour que les objets ne soient présent que lorsque c'est nécessaire et utile

5/ Je peux maintenant appliquer les règles de style, labels et paramétrages des champs

Non.

L'action de réplication ne fait que recopier les données physiques dans l'entrepôt central^[6] et les référencer^[11] dans le gestionnaire de ressource^[8] unifié de Géo-IDE : le jeu de données n'est pas accessible (ni en visualisation, ni en téléchargement) par les autres utilisateurs, mais l'est uniquement par les administrateurs et producteurs de cartes de l'organisation, depuis les modules :

• Géo-IDE Catalogue pour être catalogué / diffusé / publié si besoin

• Géo-IDE Carto V0 et Carto2 pour être utilisé dans des compositions cartographiques

Chacun de ces 3 modules est fonctionnellement indépendant : en particulier il n'est pas nécessaire de cataloguer^[2] un jeu de données et/ou de le diffuser^[5] et/ou de le publier^[10] pour l'utiliser dans une composition cartographique (CartoV0 ou Carto2).

Pour pouvoir utiliser des ressources^[14] de son patrimoine de données dans Géo-IDE Carto2 il est nécessaire de répliquer^[12] ces données depuis Géo-IDE Base en choisissant l'option Répliquer pour Catalogue et Carto2

L'action répliquer pour Géo-IDE Carto V0^[13] ne fait que copier les données dans l'entrepôt central^[6]. Or, le nouveau module Cartographique de Géo-IDE « Géo-IDE Carto2 » est mieux intégré à l'infrastructure Géo-IDE et nécessite un référencement des Jeux de Données^[11] dans le gestionnaire de ressources^[8] unifié de Géo-IDE.

Pour accéder à un Jeu de Données depuis Géo-IDE Carto2, il est donc nécessaire de répliquer son jeu de données depuis Géo-IDE Base en choisissant l'action Répliquer pour Catalogue et Carto2

Différents cas possibles :

1. Le Jeu de données est présent dans Géo-IDE Base mais n'a pas été répliqué dans l'entrepôt central^[6]

   Solution : Dans Géo-IDE Base, répliquer le jeu de données via l'action Répliquer pour Catalogue et Carto2

2. Le Jeu de données a bien été répliqué depuis Géo-IDE Base mais uniquement pour Carto V0

   Solution : Dans Géo-IDE Base, répliquer à nouveau le jeu de données via l'actionRépliquer pour Catalogue et Carto2

3. Le jeu de données n'est pas au format vecteur ShapeFile (.shp)

   Attendre le déploiement de la version 1.1 de Géo-IDE Carto2 qui prendra en charge les formats vecteur TAB et raster GéoTIFF

Cause probable : Les traitements de certains jeux de données comportant de très nombreux objets (plusieurs millions) peut prendre plusieurs dizaines de secondes

Afin d'assurer une expérience utilisateur satisfaisante en termes de visualisation interactive, le temps maximal de traitement de rendu d'un jeu de données par le serveur est limité à 10 secondes : dans ce cas la couche ne s'affichera pas

Solution : Régler le seuil d'échelle d'affichage de la couche à un niveau adapté à la résolution de la couche

En effet, ce phénomène se produit généralement lors de l'utilisation de jeux de données étendus (à l'échelle du département, de la région voire de la France Métropolitaine) pour des données réellement exploitables / visualisable à des échelles beaucoup plus grandes (commune, quartier, ...)

Cause probable : L'autorité de certification du fournisseur de service n'est pas reconnue

L'application retourne une erreur de ce type :

-> Solution : Faire un ticket à à l'Assistance pour les applications Géo-IDE afin de faite enregistrer l'autorité de certification du fournisseur de service dans l'Infrastructure de Données Géographique Géo-IDE

La version de protocole à utiliser doit être un compromis entre celle(s) supportée(s) par le serveur fournissant le service et celles supportées par Géo-IDE Carto2

Les versions supportées par le serveur ne peuvent être connues qu'en consultant la documentation qui lui est associée, ou en contactant ses administrateurs

À défaut, une démarche essais / erreurs en testant diverses versions peut être menée.

Voici celles supportées par Géo-IDE Carto2 :

Cause probable : L'URL du serveur WMS a été déclaré dans le patrimoine avec un "?" en fin d'URL

Cela ne cause pas d'anomalie d'affichage des couches concernées lors de la navigation interactive, mais peut poser des problèmes lors des exports de carte (PDF/PNG) : absence de la couche/légende

Solution : Modifier l'URL du serveur WMS au sein du patrimoine de services. Cela impactera immédiatement la carte aussi bien côté BO que côté FO après rafraîchissement de la page

NB : Il convient également en général et ce pour l'ensemble des couches de la carte, de s'assurer que l'échelle de la carte au sein de l'export est bien incluse dans la plage de visibilité de la couche que l'on n'y retrouve pas

Les performances d'exploitation des services WxS dépendent de nombreux facteurs externes (qualité du réseau, complexité des jeux données sources, capacités et performance du serveur distant et de son moteur de publication, ...)

Contrôler les éléments suivants :

• Paramétrage du serveur source : Contrôler l'URL du service, le type de serveur (WMTS) et la version du service auprès du fournisseur de service

• Projection : Vérifier que la couche sélectionnée est bien associée à une pyramide d'images pré-calculées en EPSG:3857 (WGS 84 / Pseudo-Mercator) en interrogeant les capacités du service WMTS

  En effet Carto2 ne reprojette pas à la volée les données externes, considérant que c'est le rôle d'un serveur Cartographique de servir des données dans la projection demandée

  En particulier pour le service WMTS, en cas d'utilisation d'une couche dans une projection différente, les tuiles d'images seront bien téléchargées mais s'afficheront avec un décalage correspondant au décalage d'origine entre ce système de coordonnées et celui de la projection d'affichage de Carto2 (EPSG:3857)

  Remarque : il s'agit bien de la projection de visualisation interactive des données et non de la projection native des données qui peut bien entendu être différente

• Vérifier avec un client OGC (par exemple QGIS) que le serveur est bien opérationnel

Les performances d'exploitation des services WxS dépendent de nombreux facteurs externes (qualité du réseau, complexité des jeux données sources, capacités et performance du serveur distant et de son moteur de publication, ...)

En particulier pour le WFS, même si Carto2 limite le nombre d'objets téléchargés (seuil fixé à 1000 objets par requêtes), un seul objet complexe pouvant représenter un gros volume, la charge du réseau et la quantité de traitements à assurer peut rapidement atteindre des niveaux très élevés et ainsi les performances se trouver dégradées.

Contrôler les éléments suivants :

• Opportunité d'utiliser le service WFS : Compte tenu des problématiques de performances évoquées ci-dessus et de la limitation d'affichage à 1000 objets :

  • L'utilisation d'une couche WFS doit répondre à un besoin justifié (nécessité d'associer un style spécifique aux données par exemple)
  • La couche cartographique exploitant ce service WFS doit être correctement configurée : il est indispensable de configurer la plage d'échelle d'affichage pour assurer à tout moment un affichage complet de la couche : lorsque la couche est visible il ne devrait jamais y avoir plus de 1000 objets à afficher dans l'emprise courante

  Lorsque cela est possible (lorsque le style d'affichage par défaut convient), il est vivement conseillé de privilégier l'utilisation des services WMS ou WMTS

• Paramétrage du serveur source : Contrôler l'URL du service, le type de serveur (WFS) et la version du service auprès du fournisseur de service

• Nombre d'objets à télécharger : L'application télécharge et affiche les objets de la couche WFS sur l'emprise visualisée dans la limite de 1000 objets. Une couche WFS peut donc se retrouver partiellement affichée à une échelle donnée

  → solution : Régler le seuil d'affichage de la couche à un niveau adapté à la résolution de la couche

• Vérifier avec un client OGC (par exemple QGIS) que le serveur est bien opérationnel

• Projection : Vérifier que le service fourni bien en EPSG:3857 (WGS 84 / Pseudo-Mercator) en interrogeant les capacités du service WFS

  En effet Carto2 ne reprojette pas à la volée les données externes, considérant que c'est le rôle d'un serveur Cartographique de servir des données dans la projection demandée

  Remarque : il s'agit bien de la projection de visualisation interactive des données et non de la projection native des données qui peut bien entendu être différente

Les performances d'exploitation des services WxS dépendent de nombreux facteurs externes (qualité du réseau, complexité des jeux données sources, capacités et performance du serveur distant et de son moteur de publication, ...)

Contrôler les éléments suivants :

• Paramétrage du serveur source : Contrôler l'URL du service, le type de serveur (WMS) et la version du service auprès du fournisseur de service

• Plage d'échelles : Vérifier par essais successifs si la visibilité des couches n'est pas limitée par le serveur à une plage d'échelles

• Vérifier avec un client OGC (par exemple QGIS) que le serveur est bien opérationnel

• Projection : Dans le FO de Carto2, l'affichage des données se fait en EPSG:3857 - Pseudo-Mercator Sphérique (Monde)

  Si le service distant ne fourni pas la couche demandée dans cette projection, il ne renverra pas d'image à Carto2, la couche ne sera donc pas visible au sein de la carte

  Il est possible dans le BO de Carto2, de définir dans les paramètres avancés de la couche, la propriété "Projection native". Cette dernière doit référencer une projection proposée par le service distant. Ainsi, Carto2 demandera au service distant de lui fournir sa couche dans une projection qu'il supporte, puis reprojettera l'image renvoyée pour l'afficher dans la carte en 3857

  Le plus efficient, si elle est connue (via le gestionnaire ou les métadonnées du service externe), est de demander au serveur de renvoyer la couche WMS dans la projection native de la donnée qu'il exploite. Ainsi, pas de reprojection de la donnée elle-même mais seulement de l'image renvoyée afin de pouvoir l'afficher en bout de chaîne dans la carte Carto2

  Avantages :

  - Il est possible d'appeler une couche WMS à un serveur distant dans sa projection native, à partir du moment où cette dernière figure dans la liste "Projection native"

  - Le gain de performances peut s'avérer très important (proportionnel à la complexité de la géométrie des objets sur l'emprise demandée). Il sera négligeable dans le cas d'une géométrie simple, voire nul dans le cas d'une donnée raster

  Inconvénient : Le fait de reprojeter l'image renvoyée par le serveur distant provoque une légère dégradation de l'image par un phénomène d'aliasing (effet d'escalier sur le contour des objets)

1. Cas 1 : Ma carte se retrouve dans un état "non diffusé" alors que les scopes de diffusion (Intranet et Internet) sont cochés

   Solution : Afin de réessayer de diffuser une carte désynchronisée il est indispensable de suivre la procédure suivante :

   1. Décocher les 2 scopes et enregistrer (une erreur est affichée à l'enregistrement due à la désynchronisation entre l'état des scopes cochés et celui de la carte non diffusée)

   2. Recharger la carte F5 -> les 2 scopes doivent alors se trouver décochés dans les paramètres avancés de la carte

   3. Cocher à nouveau les 2 scopes et enregistrer -> la situation doit être rétablie et la carte ainsi diffusée

2. Cas 2 : Diffusion des cartes volumineuses (plusieurs dizaines de couches)

   Le délai de diffusion peut être relativement long (1 à 2 minutes pour 40 à 50 couches). Cela équivaut à une duplication, étant donné que ce processus de diffusion implique un clonage de la carte de travail.

   Or, actuellement, lors de la première diffusion (sélection des scopes depuis les paramètres avancés), aucun indicateur de l'opération en cours ne s'affiche et la fenêtre d'édition des paramètres de la carte reste active durant l'opération, ce qui est problématique : il est indispensable de laisser le processus de diffusion se terminer sans toucher à la carte ni manipuler la fenêtre d'édition des paramètres sous peine de voir la diffusion échouer (dans ce cas se reporter alors au Cas 1 ci-dessus pour relancer le processus)

Bien souvent, si la diffusion d'une carte ne fonctionne pas, sa duplication posera aussi problème (opération impossible, ou encore carte dupliquée portant le même nom que la carte d'origine)

Lorsqu'une carte est dupliquée avec le même nom, une alerte prévient que la carte n'a pas pu être dupliquée, celle-ci est pourtant dupliquée mais avec le même nom (une correction est prévue pour pallier à ce dysfonctionnement). La première chose à faire dans ce cas là, est de renommer la carte dupliquée

Ensuite, utiliser la fonctionnalité de correction de carte. Cette fonction rétabli la cohérence entre les différents éléments techniques nécessaires au bon fonctionnement des cartes Carto2

=> Comprendre et utiliser la fonction de réparation de carte

Constat de base

Actuellement, indépendamment de toute considération de taille des données, le délais d'affichage minimal d'une couche est d'environ 1.5 seconde sur le RIE (délais de traitement du rendu + de transfert réseau + de contrôles par les différents équipements intermédiaires traversés). À peu de choses près, ce délais d'affichage sera le même qu'il s'agisse d'un JDD de 1 Mo ou de 50 Mo. Seuls les très gros JDD ou très complexes verront leurs temps de traitement significativement rallongés

• piste d'optimisation technique (MCO applicatif) -> optimisation des délais de traitement du proxy applicatif Carto2 + passage des données en BD + pré-traitement de la re-projection (éviter les re-projections à la volée systématiques) -> cible : <1s/couche -> évolutions futures envisagées non planifiées

Autres causes de pertes de performance

• info-bulles : les info-bulles sont déclenchées à chaque fois que la souris s'arrête plus d'1s sur la carte et génèrent des requêtes d'interrogation d'autant plus longues à résoudre qu'il y a de couches interrogeables actives (normal) et de couches dans la carte (anomalie en cours de correction). Cela provoque des requêtes longues à résoudre qui limitent les capacités de parallélisation du navigateur : en effet Firefox n'autorise que 6 requêtes en parallèle et met les autres en attente. Ainsi s'il y a plus de 6 requêtes "longues" d'interrogation en cours, cela bloque totalement la résolution d'autres requêtes, en particulier de requêtes WMS allongeant énormément le temps d'affichage des couches. Par exemple, si 6 requêtes d'interrogation simultanées sont résolues en 20s, toutes les requêtes suivantes seront bloquées au niveau du navigateur pensant ces 20s

  • Solution 1 (producteur de carte) : désactiver les options d'interrogation de type "info-bulles" dans toutes les couches côté BO (laisser uniquement les interrogations à la demande); pour vérifier l'effet sur votre carte il suffit de faire la manipulation dans le FO -> gains constatés : au delà de quelques manipulations de la carte (zoom, déplacement, ...) les délais d'affichage des couches explosent. Sans info-bulles ils restent contant, entre 2 et 7s. (en fonction du nb de couches affichées en simultané -> cf ci-dessous)
  • Solution 2 (MCO applicatif) : changer la stratégie de déclenchement de l'outil info-bulles (en cours : au click plutôt qu'au délais d'immobilité) et corriger l'anomalie d'interrogation liée au nombre de couches dans la carte (en cours) -> cible V1.5 de Carto2

• Parallélisation des requêtes côté client (navigateur) : le problème a déjà été évoqué dans le cadre des info-bulle mais reste présent même s'il n'y a aucune info-bulle active. En effet, si plus de 6 couches sont affichées simultanément, seules les 6 premières seront traitées en parallèle, les autres seront mises en attente par le navigateur : ainsi le délais d'affichage de 6 couches est de 1.5 à 2s / de 7 à 12 couches de 4s / de 13 à 18 couches 6s / etc ...

  • Solution1 (producteur de carte) : ne pas afficher plus de 6 couches simultanément (ou plus en fonction du seuil d'acceptabilité des délais d'affichage : potentiellement relevable en fonction des optimisations techniques réalisables évoqués ci-dessus) -> ceci peut être envisagé en réglant les seuils de zoom complémentaires côté BO (notamment en désactivant aussi au fur et à mesure les couches dont on n'a plus besoin à grande échelle pour les remplacer par d'autres couches plus pertinentes)
  • Solution2 (utilisateur) : augmenter au niveau du navigateur le nombre de requêtes parallélisables -> sous firefox il s'agit de la variable "network.http.max-persistent-connections-per-server" -> gains constatés (ex valeur à 24) : pour 14 couches affichées simultanément on passe de 7s (sans info-bulles) -> à 3s

  NB : demander à l'utilisateur de relever la limite de requêtes parallélisables de son navigateur WEB n'est pas évident, mais cette limitation ne peut pas être contournée et ne peut être outrepassée que par l'utilisateur. d'où l'intérêt de la solution 1 ...

Une limitation à 200 couches pour une carte est mise en place

Constat de base

Lorsque je choisis de borner la plage d'échelles de visualisation de ma carte, en pratique, je constate que la valeur d'échelle atteinte n'y correspond pas exactement

Cause : Discrétisation des échelles en cartographie interactive

En cartographie interactive, la visualisation d'une carte se fait au travers d'échelles discrètes (niveaux de zoom prédéfinis par "pas")

Explication : Approximation de la valeur d'échelle, due à des contraintes techniques incontournables

L'indication d'échelle courante dans une carte interactive n'est pas vraiment pertinente, elle n'est qu'une indication nécessairement approximative. C'est pour cela qu'en général, les applications cartographiques interactives, ne proposent et ne devraient proposer, qu'une barre d'échelle graphique et pas une échelle numérique

A la demande des utilisateurs, Carto2 propose une indication d'échelle numérique, mais elle est surtout destinée à aider les administrateurs à régler leurs plages d'échelle (cartes/couches/styles) ou à donner une indication de l'échelle de visualisation approximative à laquelle cela correspondrait sur une carte papier

Quelles contraintes particulières à la cartographie interactive ?

Une indication d'échelle, indique une correspondance entre ce que l'on peut mesurer sur la carte et les distances réelles sur le terrain

Il faudrait donc dans une carte interactive, que la mesure d'une distance à l'écran ait un sens. Or ce qui est affiché à l'écran dépend bien entendu du niveau de zoom spécifié par l'utilisateur mais également de paramètres externes propres à la machine (résolution de l'écran) ou du navigateur (niveau de zoom du navigateur), et le calcul de l'échelle ne prend pas en compte ces paramètres externes. Quelle que soit la résolution de l'écran ou le niveau de zoom du navigateur (50% par exemple), l'indication d'échelle restera la même alors que l'emprise de la carte affichée aura changé (et donc les distances mesurables à l'écran).

Pour résumer, l'échelle numérique en cartographie interactive doit rester une indication est toujours fausse sur une carte interactive