La mise à jour 2020.01 de vMap est sortie cette semaine. L’optimisation des performances et l’amélioration des outils d’administration sont les maîtres-mots de cette nouvelle version, qui apporte aussi son lot de corrections.

Installation et mise à jour

Vous pouvez installer vMap gratuitement depuis le vStore, Docker ou le Marketplace AWS. Vous pouvez trouver la procédure d’installation sur cette page.

Pour mettre à jour vMap, veuillez suivre la procédure de mise à jour.

Vous pouvez suivre l’évolution des développements des futures versions de vMap sur le dépôt GitLab de l’application, onglet Jalons (ou Milestones). Le changelog complet des corrections et nouveautés de vMap 2020.01 est disponible ici.

Principales évolutions

1. Optimisation des légendes dynamiques de l’application

Optimisation des légendes dynamiques de l’application afin de ne voir apparaître dans la légende que les pictogrammes correspondant aux données visibles sur la carte (en fonction de l’étendue et du zoom en cours).

2. Optimisation des légendes dans les impressions

Le code < div id="map_legend" > (à placer dans les modèles d’impression pour afficher la légende) affichera désormais uniquement les pictogrammes des couches visibles dans l’impression.

3. Administration : Ajout d’un formulaire de filtre pour retrouver plus facilement une couche à associer à un calque

Les couches à associer aux calques peuvent désormais être retrouvées facilement par l’intermédiaire d’un formulaire de filtre.

4. Administration – Studio : Empêcher le champ SQL summary (studio) de se terminer par un point virgule

Si l’administrateur saisi un « ; » à la fin du « SQL Summary », ce dernier est supprimé avant l’enregistrement de l’objet métier. Cette requête étant concaténée par la suite, il est d’ailleurs aussi interdit d’y rajouter une condition quelconque : « where », « order by », « group by », « having », « offset »… Ces contraintes s’appliquent aussi pour la requête « SQL List ».

5. Administration – Studio – champ de type « Grille – Objet métier » : Tri par ordre alphabétique de la liste déroulante des objets métiers

La liste retourne l’ensemble des objets métiers de l’application. Elle est désormais triée par ordre alphabétique.

Évolutions et corrections

1. Gain des performances au démarrage de vMap

Mise en place de procédure permettant d’améliorer les performances de vMap au démarrage de l’application :

  • Récupération de la définition MapServer des couches, des métadonnées, des sources…
  • Double génération du flux privé
  • Redimensionnement et diminution de la taille de plusieurs images
  • Ouverture / fermeture de sessions PHP
  • Récupération des éléments retournés par le SQL List

2. Optimisation des performances des couches (pour les administrateurs de vMap)

Si vous estimez que certaines couches de votre application mettent du temps à s’afficher dans vMap, vous pouvez améliorer ces performances.

  1. Détecter les couches qui prennent du temps à s’afficher.

  2. Se poser la question : a quelle échelle la données doit-elle être affichée ?

  3. Si la couche doit s’afficher à une échelle bien particulière (entre 1/10000 et 1/5000 par exemple), vérifier que l’attribut MAXSCALEDENOM soit bien présent dans l’objet « STYLE » de l’objet « CLASS » de la couche.
    Cette étape évite à MapServer de générer l’image de la couche mais n’empêchera pas ce dernier de réaliser la requête (même si les données ne seront pas affichées) ce qui est en réalité inutile.
    La couche n’est donc pas totalement optimisée.
  4. Si l’objet CLASS de la couche est composée d’un attribut MAXSCALEDENOM, rajouter un attribut MAXSCALEDENOM dans l’objet « LAYER » de la couche. Cette étape évite à Mapserver de réaliser la requête tant que l’utilisateur ne se trouve pas à l’échelle où la donnée est censée être visible. En faisant cela, la couche sera optimisée.

    Exemple avec le mapfile ci-dessous :
    • L’utilisateur zoome une première fois et arrive au 1/20000, la requête ne sera pas réalisée
    • L’utilisateur zoome une seconde fois et arrive au 1/8000, la requête sera réalisée et l’image représentant la donnée sera générée

A noter : Si une couche est affichée à toutes les échelles et que cette dernière retourne des milliers d’enregistrements, il est normal qu’elle mette du temps à s’afficher. Peut être alors qu’un seuil d’affichage (MAXSCALDENOM / MINSCALEDENOM) pourrait arranger le problème.

3. Format d’échange .vex

Anomalies rencontrées au moment de l’import dues aux différences de systèmes d’exploitation source (export du .vex) et destination (import du .vex). Pour rappel, le .vex est un format d’échange entre utilisateurs de vMap. Les .vex mis à disposition de la communauté utilisateurs sont disponibles sur vStore.

Important : il est à noter que ce point n’est pas une correction apportée par Veremes. Seuls les administrateurs (qui sont eux même gestionnaires et créateurs des couches de leur application) pourront mettre en place ces astuces.

4. Support de Debian 10 et Ubuntu 20.04 pour les impressions avec PhantomJS

Corrections

1. Impossibilité de réaliser des impressions sans couche OSM

2. Studio – Champ de type date

  • Impossibilité de vider un champ de type date
  • Affichage anglais des dates dans les infobulles
  • Affichage anglais des dates dans les formulaires de consultation
  • Centrage sur la date du jour dans le champ datepicker au lieu de la date enregistrée en base de données
  • Enregistrement impossible pour des dates dont le jour est supérieur à 12. Exemple : 15/06/2020 (problème de format : Anglais / Français)

L’encodage préconisé de la base de données doit être au format « ISO, DMY ». Pour le tester, exécuter la requête sql suivante sur votre base de données : show datestyle;

Si la base de données n’est pas dans ce format, la requête sql suivante permettra de modifier ce paramètre : ALTER DATABASE ma_database SET datestyle TO ‘DMY’; Le paramètre ma_database doit être modifié par le nom de votre base de données Si la base de données n’est toujours pas au format « ISO, DMY », exécuter la requête suivante : SET datestyle TO « ISO, DMY »;

3. Placeholder du champ de localisation non visible sur la version mobile

Version Desktop

Version mobile

4. Problème d’affichage de couche pour une carte en EPSG:3857

5. Interrogation des objets impossibles pour des cartes en EPSG:4326

6. Studio – Champ Grille objet métier : La balise bo_link n’est pas interprétée

7. Studio – Champ Grille objet métier : Un nombre d’enregistrements trop élevé empêche l’affichage de tous les objets.

8. Studio – Champ Grille objet métier : Le formulaire de consultation affiche les boutons « Ajouter » et « Supprimer

Une option « En consultation uniquement » a été rajoutée dans le champ pour que les boutons ne soient plus visible dans le formulaire de consultation.

9. La liste déroulante de localisation est vide (sur Linux) lorsque la propriété vmap_geocoders est vide par défaut.

10. Écriture intempestive de warning dans les logs de PHP

11. Le clonage d’un objet après avoir requêté sur ce dernier plante l’application

12. Carte > Gestion des cartes : Erreur d’authentification à l’affichage d’une couche

L’ajout d’une couche provenant d’un service WMTS avec authentification (exemple : IGN) génère une erreur 401.

13. Administration : Disparition de certains champs lors de l’enregistrement d’un formulaire objet métier

14. Administration : Suppression de plusieurs objets métiers impossibles

Lorsque plusieurs objets métiers sont sélectionnés, seul le premier est supprimé.

15. Module Cadastre : Le relevé de propriété standard ne retourne pas les tantiemes de propriété ainsi que le numéro de lot

16. Module Cadastre : Erreur SQL lors de la génération du rapport provenant de la table « lot_local »

17. Version mobile : L’affichage de plusieurs infobulle fait planter l’application

L’affichage a été revu pour permettre une navigation plus fluide des éléments sélectionnés (boutons « Précédent », « Suivant ») :