Skip to content
Snippets Groups Projects
Commit c5a7c89b authored by Laurent Panabieres's avatar Laurent Panabieres
Browse files

Change.log pour la nouvelle version de vMap : 2020.01

Change.log pour la nouvelle version de vMap : 2020.01
parent cd8ca212
Branches
Tags
No related merge requests found
Showing
with 298 additions and 0 deletions
Le document ci-dessous présente une liste non exhaustive d'évolutions / corrections à retrouver dans la version 2020.01 de vMap.
L'ensemble des évolutions et anomalies de cette nouvelle version sont à retrouver sur le GitLab de Veremes : https://gitlab.veremes.net/open-source/vmap/milestones/18
# É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)
![](images/legende_dynamique.png)
## 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.
![](images/calque_formulaire_filtre.png)
## 4. Administration - Studio : Empêcher le champ SQL summary (studio) de se terminer par un point virgule.
Un message informera l'administrateur qu'il est interdit de terminer la requête par un ";".
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.
![](images/grille_objetmetier_liste_objet_metier_tri.png)
# Évolutions / 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 mapserveur 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, **pas de panique nous allons vous donner les ficelles pour améliorer ces performances**.
*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éateur des couches de leur application) pourront mettre en place ces petites astuces.*
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.
![](images/couche_moyennement_optimisee.png)
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
![](images/couche_optimisee.png)
PS : 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.
![](images/couche_non_optimisee.png)
## 3. Format d'échange .vex
Anomalies rencontrées au moment de l'import dûes 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 le [store de Veremes](https://vstore.veremes.net/store/ "store de Veremes")
# Corrections
## 1. PhantomJS non compatible avec Debian 10 et Ubuntu 20.04
## 2. Impossibilité de réaliser des impressions sans couche OSM
## 3. 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)
## 4. Le Placeholder du champ de localisation non visible sur la version mobile
Version Desktop :
![](images/placeholder_version_desktop.png)
Version mobile :
![](images/placeholder_version_mobile.png)
## 5. Problème d'affichage de couche pour une carte en EPSG:3857
## 6. Interrogation des objets impossibles pour des cartes en EPSG:4326
## 7. Studio - Champ Grille objet métier : La balise bo_link n'est pas interprêtée.
![](images/grille_objet_metier.png)
## 8. Studio - Champ Grille objet métier : Un nombre d'enregistrement trop élevé empêche l'affichage de tous les objets.
## 9. 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.
![](images/grille_objetmetier_consultation.png)
## 10. La liste déroulante de localisation est vide (sur Linux) lorsque la propriété vmap_geocoders est vide par défaut.
## 11. Écriture intempestive de warning dans les logs de php
## 12. Le clonage d'un objet après avoir requêté sur ce dernier plante l'application
## 13. Administration : Impossibilité de tester un flux public
## 14. Administration : Erreur d'authentification dans les calques pour les flux WMTS
## 15. Administration : Disparition de certains champs lors de l'enregistrement d'un formulaire objet métier
## 16. Administration : Suppression de plusieurs objets métiers impossibles
Lorsque plusieurs objets métiers sont sélectionnés, seul le premier est supprimé.
## 17. Module Cadastre : Le relevé de propriété standard ne retourne pas les tantiemes de propriété ainsi que le numéro de lot
## 18. Module Cadastre : Erreur sql lors de la génération du rapport provenant de la table "lot_local".
Le document ci-dessous présente une liste non exhaustive d'évolutions / corrections à retrouver dans la version 2020.01 de vMap.
L'ensemble des évolutions et anomalies de cette nouvelle version sont à retrouver sur le GitLab de Veremes : https://gitlab.veremes.net/open-source/vmap/milestones/18
# É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.
Un message informera l'administrateur qu'il est interdit de terminer la requête par un ";".
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 / 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 mapserveur 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, **pas de panique nous allons vous donner les ficelles pour améliorer ces performances**.
*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éateur des couches de leur application) pourront mettre en place ces petites astuces.*
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 (d'une couche avec un MAXSCALEDENOM à 10000) :
- 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
PS : 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 dûes 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 le [store de Veremes](https://vstore.veremes.net/store/ "store de Veremes")
# Corrections
## 1. PhantomJS non compatible avec Debian 10 et Ubuntu 20.04
## 2. Impossibilité de réaliser des impressions sans couche OSM
## 3. 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)
## 4. Le Placeholder du champ de localisation non visible sur la version mobile
## 5. Problème d'affichage de couche pour une carte en EPSG:3857
## 6. Interrogation des objets impossibles pour des cartes en EPSG:4326
## 7. Studio - Champ Grille objet métier : La balise bo_link n'est pas interprêtée.
## 8. Studio - Champ Grille objet métier : Un nombre d'enregistrement trop élevé empêche l'affichage de tous les objets.
## 9. 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.
## 10. La liste déroulante de localisation est vide (sur Linux) lorsque la propriété vmap_geocoders est vide par défaut.
## 11. Écriture intempestive de warning dans les logs de php
## 12. Le clonage d'un objet après avoir requêté sur ce dernier plante l'application
## 13. Administration : Impossibilité de tester un flux public
## 14. Administration : Erreur d'authentification dans les calques pour les flux WMTS
## 15. Administration : Disparition de certains champs lors de l'enregistrement d'un formulaire objet métier
## 16. Administration : Suppression de plusieurs objets métiers impossibles
Lorsque plusieurs objets métiers sont sélectionnés, seul le premier est supprimé.
## 17. Module Cadastre : Le relevé de propriété standard ne retourne pas les tantiemes de propriété ainsi que le numéro de lot
## 18. Module Cadastre : Erreur sql lors de la génération du rapport provenant de la table "lot_local".
changelog/2020.01/images/calque_formulaire_filtre.png

40.9 KiB

changelog/2020.01/images/couche_moyennement_optimisee.png

44.7 KiB

changelog/2020.01/images/couche_non_optimisee.png

47.8 KiB

changelog/2020.01/images/couche_optimisee.png

49.6 KiB

changelog/2020.01/images/grille_objet_metier.png

38.8 KiB

changelog/2020.01/images/grille_objetmetier_consultation.png

7.76 KiB

changelog/2020.01/images/grille_objetmetier_liste_objet_metier_tri.png

15 KiB

changelog/2020.01/images/legende_dynamique.png

438 KiB

changelog/2020.01/images/placeholder_version_desktop.png

20.8 KiB

changelog/2020.01/images/placeholder_version_mobile.png

3.76 KiB

0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment