Discussion :

[cmail]

1/ A partir de cette page de test toute simple avec 3 niveaux de zoom, si on agit avec les touches - et + on actionne le zoom et la carte verte reste au centre du viewer: Comportement idéal pour moi. C'est simple et très intuitif.

2/ Passons maintenant à l'action du zoom avec la molette de la souris.
Si le curseur est dans la zone verte: En décroissant le zoom, arrivé au minZoomLevel, si on continue de tourner la molette dans le même sens, généralement la carte se décale par unité de distance>> Ce comportement est guère compréhensible. Parce que la molette agit sur le zoom centrée sur le curseur(ce qui, je crois, est la solution retenue dans la primitive, mais cela introduit une première question de ma part comment, simplement, n'agir que sur le zoom et non sur le recentrage de la carte???), puis uniquement sur le déplacement de la carte (fonction assurée par ailleurs par le clic maintenu!). Arrivée en butée sur minZoomLevel, la molette ne devrait plus être active.

Mais plus grave et plus problématique en terme d'ergonomie, quand le curseur est en dehors de la zone verte, la molette fait diminuer le zoom en déplaçant la carte par rapport au curseur dans la logique retenue par l'IGN, ET arrivé au minZoomLevel, un nouveau cran de la molette fait que la carte ne se recentre plus de la même manière (rupture de logique!) mais se repositionne bizarrement en fonction du point de centrage défini dans l'interfaceviewer et de la place du curseur sur le viewer.

Donc en fonction du positionnement du curseur (dans ou hors zone verte) le comportement de la molette au-delà du minZoomLevel n'est pas identique! A mon humble avis, il y a là un problème à corriger.

Mais au-delà, en bref, comment faire simplement (sans s'attaquer à une surcharge bien lourde pour moi!) pour que la molette ait un comportement similaire aux touches de clavier + et -, qui se limite uniquement entre minZoomLevel et maxZoomLevel, sans aucune action de déplacement de la carte qui doit rester du seul domaine du clic maintenu?

[cmail]

Autrement dit.
Sauf erreur de ma part, il y a deux problèmes avec la gestion du zoom via la molette:
1/ Le problème du recentrage de la carte sur le curseur quand on zoom via la molette qui devrait être paramétrable facilement avec une option quelconque.
2/ Le problème quand on atteint les limites minZoomLevel et maxZoomLevel où la molette ne devrait plus être active.

[tcoupin]

Bonjour cmail,

ce que tu observes est le comportement normal de l'API OpenLayers.
D'ailleurs, le double click a le même comportement que la molette.

Pour personnaliser le comportement, il n'y a malheureusement pas d'option.

Tu peux légèrement surcharger comportement du Control Navigation, voici le lien vers la version actuelle http://api.ign.fr/geoportail/api/js/.../Navigation.js

Les fonctions à personnaliser sont :

• defaultDblChange ligne 240
• defaultDblRightClick ligne 251
• whellChange ligne 263 (surtout celle-ci)

Désolé de ne pas avoir de meilleure solution...

[cmail]

ce que tu observes est le comportement normal de l'API OpenLayers.

Oui, mais cela n'empêche pas que ce comportement n'est pas "logique" quand on arrive en limite paramétrée par minZoomLevel et maxZoomLevel .

[jrenard]

Ce comportement est logique d'un point de vue technique dans le sens où c'est une conséquence directe du fonctionnement du zoom molette qui implique deux opérations simultanées: un zoom + un recentrage pour ne pas trop s'éloigner de la position du curseur de la souris au moment du zoom. Donc en limite de zoom, l'opération de zoom ne peut plus être appliquée et seul reste le recentrage, ce qui implique un déplacement de la carte dans la direction du curseur, déplacement qui peut être très conséquent dans le cas où le curseur est en bord de carte.

Mais d'un point de vue fonctionnel, il est vrai que ce n'est ni très logique ni très intuitif, et qu'il vaudrait mieux qu'en limite de zoom la molette ne déclenche plus aucune opération. Nous sommes d'accord là-dessus.

Malheureusement, comme Thibault l'a mentionné, une telle évolution relève d'OpenLayers et non de l'API Géoportail. Donc à moins de s'adresser directement à eux pour leur soumettre le problème, nous ne pouvons pas faire grand chose de notre coté, si ce n'est proposer aux utilisateurs de surcharger ce fontionnement.

[cmail]

Nous sommes d'accord là-dessus.

une telle évolution relève d'OpenLayers et non de l'API Géoportail

Ah! Je croyais qu'il vous arrivait de modifier certaines primitives pour les adapter au Geoportail. Bien sûr dans ce cas, ma demande va rester lettre morte.

[jrenard]

Je croyais qu'il vous arrivait de modifier certaines primitives pour les adapter au Geoportail. Bien sûr dans ce cas, ma demande va rester lettre morte.

C'est juste ! Je parlais d'une solution à effet immédiat ou à très court terme.
A plus ou moins long terme, nous mettons cette évolution dans la pile des possibles, par contre je ne peux pas garantir si elle sera réalisée et quand.

[cmail]

Bien, on va attendre! Parce que les surcharges perso sont très laborieuses, quoique là elles semblent assez simples...