Gestionnaire des couches #572
Comments
|
@amandine-sahl peux-tu nous indiquer où trouver la configuration des couches de GeoNature ? Dans un premier temps :
Les filtres par section (type de page) ou par espèce seront traités dans un second temps, pour une itération future. |
|
Retours suite à la recette :
|
|
Quelques updates sur mon travail en cours sur l'ajout d'un gestionnaire de couches SIG additionnelles sur les cartes de l'atlas. J'ai ouvert la draft PR : #604 ConfigurationVoici la configuration d'exemple qui permet d'obtenir le gestionnaire et les couches des captures d'écran postées par @bruhnild . COUCHES_SIG = [
{
'name': 'Zonage pluvial',
'type': 'wms',
'url': 'https://cartographie.nantesmetropole.fr/arcgis/services/PLUm/plum_annexes/MapServer/WMSServer?',
'options': {
'layers': 'Zonage_pluvial_(I19-03)54824',
'transparent': True,
'format': 'image/png'
}
},
{
'name': 'Réseau de chaleur',
'type': 'wms',
'url': 'https://cartographie.nantesmetropole.fr/arcgis/services/PLUm/plum_annexes/MapServer/WMSServer?',
'options': {
'layers': 'Réseau_de_chaleur_(I_07-00)28291',
'transparent': True,
'format': 'image/png'
}
},
{
'name': 'PLUM annexes',
'type': 'arcgisMapService',
'url': "https://cartographie.nantesmetropole.fr/arcgis/rest/services/PLUm/plum_annexes/MapServer"
}
]Limites du plugin L.LayerTreeControl
Après une recherche ça reste tout de même la meilleure option de plugin. À noter que gn-atlas va dépendre du fork du plugin par Makina suite à une correction de bug qui n'a pas encore été répercuté sur le upstream. Ajout d'une dépendance vers la lib esri-leafletLib nécessaire pour gérer les couches provenant d'un serveur Arcgis. La lib ne sera chargée dans le navigateur que s'il y a des couches Arcgis à afficher. J'ai choisi de l'inclure dans les dépendances npm de l'atlas car la solution de permettre à l'admin d'inclure son propre code JS via une propriété J'ai néanmoins testé rapidement et ça pourrait fonctionner avec la configuration suivante et la méthode JS {
'name': 'PLUM annexes',
'type': 'arcgisMapService',
'url': "https://cartographie.nantesmetropole.fr/arcgis/rest/services/PLUm/plum_annexes/MapServer",
'assets': [
'custom/esri-leaflet.js',
'custom/createEsriLayer.js',
]
}function createLayer(coucheSigInfo) {
let func = eval("create" + capitalize(coucheSigInfo.type) + "Layer");
return func(coucheSigInfo);
}Couche geoJSON et territoire.jsonIl était mentionné dans les tickets pointés par @camillemonchicourt l'opportunité d'inclure l'élément de configuration
Travaux en cours
|
|
OK merci pour ces éléments. L'idée était d'utiliser le gestionnaire de couches simple et basique de Leaflet. Je pense que peu d'utilisateurs voudront ajouter des couches sur les cartes, mais encore moins sous forme d'arbre de couches. De plus si cela oblige à intégrer un plugin peu fonctionnel, je suis assez réservé. Ajouter un mécanisme simple et générique d'ajout de couches, groupé avec les couches de types de maille, est pertinent, mais encore un autre bloc à part pour ça pour gérer les arbres de couches, peu fonctionnel ni maintenu pose soucis il me semble. On voulait aussi éviter la dépendance à "esri-leaflet" car là aussi sa maintenance est incertaine. Tout ce travail devait aussi s'appuyer sur une mise à jour préalable des dépendances, notamment les versions de Leaflet et de ses plugins. |
Le gestionnaire "intuitif" actuel :
À moins d'être connaisseur de la législation liée à la protection des données d'observation d'espèces ça m'étonnerai que quelqu'un comprenne à quoi correspondent ces couches et les légendes associées ... A soumettre à un expert UX mais ça m'étonnerai que son retour soit que le gestionnaire est "intuitif".
Dans ce commentaire pourtant tu semblais valider l'utilisation du plugin utilisé. ("J'intégrerai donc nativement Leaflet-LayerTreeControl mais ne l'utiliserai que si au moins une couche additionnelle est déclarée dans la config" > c'est ce qu'on a fait). D'un point de vue "fonctionnel" je trouve pas ça déconnant d'avoir un gestionnaire dédié aux couches de données "GeoNature" et un autre bien séparé pour toutes les données tierces complémentaires qui viennent juste apporter du contexte mais pas des données applicatives.
L.LayerTREEControl
Les utilisateurs qui ne souhaitent pas cette fonctionnalité ... ne l'utiliseront pas. Actuellement j'ai testé une cinquantaine d'applis GeoNature-Atlas et j'en ai trouvé uniquement 2 qui avaient un sélecteur pour les mailles. Donc en effet tout le monde ne souhaite pas forcément aller à ce niveau de configuration. Mais comme tu l'as toi même pointé c'est un besoin déjà évoqué à plusieurs reprises dans d'autres tickets, donc ceux qui voudront pourront l'utiliser et les autres n'auront rien à faire et leur GeoNature ne sera aucunement affecté.
L'utilisation d'un niveau de hiérarchie important n'est pas obligatoire. C'est possible de rester simple : une couche uniquement sans notion de groupe. C'est juste que c'est aussi possible, pour couvrir plusieurs cas d'usages.
Peux-tu en dire plus sur l'aspect "peu fonctionnel" ? 🤔 De manière plus générale, est-ce que ton commentaire signifie que vous ne souhaitez pas intégrer ces changements dans le produit GeoNature-Atlas ? Parce que là il est question d'une exigence spécifiée il y a pratiquement un an, où la démarche était décrite dans des tickets depuis plusieurs mois et sur laquelle tu ne semblais pas avoir émis autant de réserves. C'est un peu délicat et tardif d'émettre ces retours une fois que l'implémentation est déjà réalisée. |
|
Je parlais de l'aspect simple et intuitif du gestionnaire de couche de base de Leaflet car classique et souvent utilisé : Pour le plugin LayerTreeControl, j'avais pas bien capté de quoi il s'agissait et que c'était pour gérer des arbres de couches. Pour moi c'était évident qu'on allait juste ajouter la possibilité d'ajouter des couches externes additionnelles dans le gestionnaire de couches de base de Leaflet. Comme on a dans Geotrek-admin, dans Geotrek-rando, dans les zonages de sensibilité de GNA et dans plein d'autres outils. C'est normal actuellement qu'il n'y ait pas de sélecteur de couches sur les GNA déployés, car cette fonctionnalité n'est actuellement pas implémentée dans une version publiée de GNA. Peu fonctionnel :
Mais sinon, oui oui, c'est clair et OK depuis le début que de pouvoir ajouter des couches additionnelles dans le gestionnaire de couches, même depuis 2020 : #246 (comment) |
|
OK, j'ai regardé un peu plus en détail l'implémentation actuelle et en effet ce n'est pas très satisfaisant selon moi. Mais là l'ajout d'un gestionnaire a pour vocation de regrouper et clarifier tout ça, mais pas d'ajouter encore plus de boutons et de dispersion peu compréhensible. Car en l'état des évolutions :
Donc le fait d'ajouter un gestionnaire de couches ainsi que le floutage des données sensibles nécessite de reprendre le fonctionnement actuel et pas de s'y ajouter à côté. Voilà ce que j'aurai en tête pour regrouper tout ça dans un ensemble plus cohérent :
Un seul gestionnaire de couches, incluant aussi les légendes.
|
|
OK merci pour tes retours @Camille. Je partage ta vision idéale pour l'intégration de cette fonctionnalité. Je ne pense pas que nous pourrons atteindre tous ces objectifs dans le temps dont nous disposons pour cette prestation. Je vais apporter quelques précisions sur le travail en cours de façon concise sans rebondir forcément sur tous les points abordés. espace occupé par le gestionnaire de couches SIG La couche Arcgis utilisée (les annexes du PLUM Nantes) n'est pas la meilleure pour un exemple de fonctionnement. Elle a beaucoup de couches, beaucoup de niveaux d'arborescence et des titres très longs. Elle n'est pas représentative de l'usage qu'on veut faire du gestionnaire de couches SIG. Je pense donc qu'il ne faut pas se focaliser sur la place prise par cette couche exemple. La quantité de données à exposer dans l'atlas sera adaptée par les administrateurs de chaque instance, avec une arborescence plus simple ou pas d'arborescence, moins de couches, des titres moins longs... les légendes Comme tu l'as compris l'utilisation du plugin J'ai examiné le code de l'outil Layers standard de Leaflet et il n'y a aucune gestion des légendes. La capture d'écran que tu as postée doit être basée sur un plugin ou un développement spécifique. pouvoir replier le gestionnaire de couches SIG Comme je l'ai indiqué réduire la place prise par le gestionnaire de couches Peek.28-01-2025.11-59.webmIl s'agit du même fonctionnement que pour le composant Layers standard de Leaflet. Le panneau est développé au survol et réduit à la sortie du curseur. En mode mobile c'est un touch qui développe, et touch sur la carte pour réduire. C'est une solution intermédiaire pour un effort de développement maitrisé. Idéalement il faudrait aller plus loin et fusionner les deux sélecteurs de couches. Cependant, à mon avis, avoir deux outils reste acceptable étant donné que les types d'objets manipulés sont différents :
Je pense qu'on aurait d'ailleurs tendance à vouloir les différencier visuellement si affiché dans le même panneau. définir des couches spécifiques pour des pages/des espèces J'ai ajouté la possibilité de cibler des pages ou des groupes taxononiques pour les couches SIG. Voilà ce que ça donne pour la config : COUCHES_SIG = [
{
'name': 'Zones de protection',
'type': 'wms',
'url': 'https://foo.bar/WMSServer?',
'options': {
'layers': 'zones_protection'
},
'pages': [
'home',
'species'
]
},
{
'name': 'Zones humides',
'type': 'wms',
'url': 'https://foo.bar/WMSServer?',
'options': {
'layers': 'zones_humides'
},
'pages': [
'species'
],
'groups2_inpn': [
'Amphibiens',
'Oiseaux',
]
}
]
|
Voir #528 (comment)
The text was updated successfully, but these errors were encountered: