Discussion :

[cmail]

Sur cette page de test , je perds la fonction du clic enfoncé déplacé (pour déplacer la carte) quand je suis sur mon kml départemental (ou kml des fleuves). Celui-ci est toujours présent quand je suis sur la carte ign.
Comment réactiver cette fonction sur les kml ?

[jrenard]

On est sur le coup, le temps de faire quelques essais sur le code de cette page de test et on essaie de revenir avec une solution satisfaisante.

[Viglino]

Bonjour,

Le problème vient du Control.SelectFeature, il faut préciser qu'il ne doit pas garder l'évènement clic pour lui lorsqu'on clique sur un objets (en particulier un polygone).
Il faut ajouter aux options du OpenLayers.Control.SelectFeature :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

handlersOptions:{feature:{stopDown:false}}

Ou de façon plus radicale modifier la valeur par défaut d'OL : OpenLayers.Handler.Feature.prototype.stopDown= false;

@+

[cmail]

Bonjour Jean-Marc, (Je crois que je t'ai appelé Marc la dernière fois! )
1/ A mes premiers essais, OpenLayers.Handler.Feature.prototype.stopDown= false; répond à ma question.
2/ Par contre ta première réponse me laisse perplexe. A moins que je me plante dans l'écriture, j'ai écrit dans mon code sur ma page d'essai :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 var clickCtrlOpts = OpenLayers.Util.extend(viewer1.getMap().getPopupDefaults('KML'), {
			onSelect : clicCommune,
				autoActivate : true,
		handlersOptions : {
				feature : {
					stopDown : false
				}
			}
		});
clickCtrl = new OpenLayers.Control.SelectFeature([layerCommune1, layerEau1], clickCtrlOpts);

Ce qui correspond bien à ta proposition. Non? Et pourtant cela n'est pas ici opérationnel, mais je dois avoir fait une erreur ailleurs...

[Viglino]

Bonjour,

Oui c'est bien cela (voir ici http://www.developpez.net/forums/d10...polygones-kml/).
Par contre, l'API ajoute automatiquement un SelectControl aux couches KML (qui lui n'a pas l'option stopDown=false).
Il faut désactiver le comportement par défaut de l'API.
Il me semble qu'il faut ajouter "preventDefaultBehavior : true" à la création du layer KML, au même niveau que les formatOptions :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

viewer1.getMap().addLayer("KML",nom,href,opt,{formatOptions :{extractStyles : true}, preventDefaultBehavior : true });

@+

[cmail]

Par contre, l'API ajoute automatiquement un SelectControl aux couches KML (qui lui n'a pas l'option stopDown=false).

OK.

Il me semble qu'il faut ajouter "preventDefaultBehavior : true" à la création du layer KML, au même niveau que les formatOptions :

Très juste. J'avais négligé... Mais à mes premiers essais, ce paramètre est seulement nécessaire sur 1 seul des kml chargés. A confirmer par un plus grand nombre de possibilités...

[cmail]

Je reprends cette discussion sous un autre aspect (sujet étroitement lié): la gestion du curseur lors du clic maintenu-déplacé.

En faisant appel à OpenLayers.Handler.Feature.prototype.stopDown= false; on perd le css "cursor: move" quand on fait le clic maintenu. Par contre quand on paramètre preventDefaultBehavior : true, on le retrouve bien, mais on perd alors le "cursor: pointer" sur les features cliquables

Et je m'y perds un peu pour rationaliser le tout, surtout en faisant appel à OpenLayers.Handler.Feature.prototype.stopDown= false; que je privilégie...

[cmail]

Encore un constat autour du clic maintenu déplacé:
Sur vos exemples officiels, par exemple http://depot.ign.fr/geoportail/api/d...ortalLike.html, après l'utilisation des outils de mesure (longueur et surface), on perd le clic maintenu déplacé. Ce n'est pas logique et normal. Non?

[jrenard]

Bonjour Christian,

On ne perd pas vraiment le clic maintenu-déplacé, car il suffit de re-sélectionner l'outil main pour le récupérer (ce qui est somme toute logique: si l'outil de déplacement n'est pas sélectionné, le déplacement n'est pas possible).

Mais derrière cela se cache peut-être la suggestion suivante: lorsque l'on décoche un outil de mesure ou de recherche, l'outil main devrait être re-sélectionné par défaut, de manière à ce qu'au moins un outil soit sélectionné ?

Dans ce cas, c'est à discuter.

[cmail]

lorsque l'on décoche un outil de mesure ou de recherche, l'outil main devrait être re-sélectionné par défaut, de manière à ce qu'au moins un outil soit sélectionné ?

Oui. Si je ne dis pas de bêtise, comme l'outil main (qui donne accès au clic maintenu déplacé) est appelé au chargement de l'api, et que l'utilisateur moyen est habitué à cette ressource d'origine (sans vraiment faire le lien direct!), il est perturbé quand il quitte les outils de mesure (ou de recherche) de ne pas le retrouver automatiquement... Ce qui fut mon cas! D'autant plus que le déplacement par les touches du clavier reste toujours actif contrairement à ce que tu dis

si l'outil de déplacement n'est pas sélectionné, le déplacement n'est pas possible

...
Si vous n'accédez pas (hélas!) à cette demande, pouvez-vous me dire comment je dois mettre en place les conseils de Viglino et dans quelles surcharges, car mes essais ne sont vraiment pas concluants!

[jrenard]

D'autant plus que le déplacement par les touches du clavier reste toujours actif contrairement à ce que tu dis [COLOR=#3E3E3E]...

Certes, la rigueur aurait dû me faire dire "si l'outil main n'est pas sélectionné, le déplacement à la main (ie. à la souris) n'est pas possible". Ce qui reste logique, n'est-ce pas ?

[mga_geo]

Non ce n'est pas logique : la main est sélectionnée par défaut au chargement de l'api. Après déselection d'un autre outil, il faut revenir au mode par défaut.

[cmail]

Un constat:
Après avoir sélectionné l'outil de recherche.
1/ Si on le ferme en recliquant sur l'icone "jumelle" on perd bien l'outil "déplacement à la main">> choix actuel de l'IGN.
2/ Mais si on le ferme en cliquant sur le x du panneau de recherche, l'outil "déplacement à la main" est sélectionné automatiquement. ++

Du point de vue d'un utilisateur rigoureux, il y a dans cette alternative une équivoque à régler. A vous de voir...
De mon coté, je pense que le "déplacement à la main" doit être systématiquement validé quand on ferme un outil.

(Cette approche de rationalisation permettrait aussi d'éviter la double (voire triple avec le bouton d'impression que je n'aborderai pas ici) approche d'utilisation des boutons d'outils, et qui n'est pas très ergonomique pour des utilisateurs lambda :
1/ les deux boutons "déplacement à la main" et "se rapprocher" sont sur le mode "exclusion alternative" : on passe de l'un à l'autre, mais le double clic sur ces boutons n'a aucun effet.
2/ Alors que les autres boutons (mesure et recherche) intègrent ce double clic pour l'ouverture et la fermeture des outils.)

Bref, de mon coté, sans préjuger sur vos décisions, comment opérer correctement pour remettre systématiquement le "déplacement à la main" quand je quitte les outils de mesure?

[jrenard]

Un constat:
Après avoir sélectionné l'outil de recherche.
1/ Si on le ferme en recliquant sur l'icone "jumelle" on perd bien l'outil "déplacement à la main">> choix actuel de l'IGN.
2/ Mais si on le ferme en cliquant sur le x du panneau de recherche, l'outil "déplacement à la main" est sélectionné automatiquement. ++

Judicieuse remarque. Sur le fond, j'adhère à ton analyse : il y a une certaine incohérence dans le fonctionnement. Le mieux serait encore qu'on la corrige de notre coté.
On va voir ce qu'on peut faire.

[jrenard]

Bonjour Christian,

Bref, de mon coté, sans préjuger sur vos décisions, comment opérer correctement pour remettre systématiquement le "déplacement à la main" quand je quitte les outils de mesure?

Je reviens sur ce point. En attendant que nous corrigions ça de notre coté, une façon de faire peut être la suivante : sur chaque outil (de mesure, de géolocalisation), ajouter une fonction onclick. Cette fonction teste l'état actif/inactif du bouton via son nom de classe (à savoir est-ce que le nom de classe se termine par "ItemActive" ou "ItemInactive"). Si l'état est actif, cela signifie que le bouton est en cours de déselection, et alors on force la réactivation de l'outil de déplacement à la main. Le code suivant, à répéter sur chaque bouton nécessaire en adaptant le nom d'id et le nom de classe (mais dans le nom de classe, en conservant toujours "ItemInactive") :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
// Activation du déplacement à la fermeture de l'outil
document.getElementById("OpenLayers.Control.Measure_601").onclick = function() {
	if (document.getElementsByClassName("olControlMeasurePathItemInactive").length!=0) {
		viewer.getMap().getControlsByClass("OpenLayers.Control.Navigation")[0].activate();
	}
};

[cmail]

Merci Jeremy
A cet url le résultat de tes conseils qui m'amène quelques questions complémentaires (J'en profite!)

1/ Tout d'abord, pourquoi sur l'outil MeasurePolygon on constate quelques dysfonctionnements: le style se perd, la mesure ne s'effectue pas... Mais on retrouve bien le clic maintenu après.
2/ Comme les 2 OpenLayers.Control.Measure traités sont référencés par leur id, on introduit leur indice. Ce qui me chagrine un peu car en fonction des modifs incessantes, celui-ci peut changer... J'essaye donc de les attaquer (soit en getElementsByClassName, soit via jquery) par leur class olButton, mais cela ne répond pas. Ton retour me serait utile pour mieux comprendre leur ordonnancement.
3/ Tu nous dis :"En attendant que nous corrigions ça de notre coté...." Cela veut dire que dans la prochaine version, cela sera intégré? Pour savoir à quel moment j'enlèverai ces rustines....

[jrenard]

1/ Tout d'abord, pourquoi sur l'outil MeasurePolygon on constate quelques dysfonctionnements: le style se perd, la mesure ne s'effectue pas... Mais on retrouve bien le clic maintenu après.

Je ne reproduis pas ce comportement. Ce qui me praît étrange, c'est que je ne reproduis pas non plus la récupération du clic maintenu après coup. M'as-tu bien donné la bonne url ?

2/ Comme les 2 OpenLayers.Control.Measure traités sont référencés par leur id, on introduit leur indice. Ce qui me chagrine un peu car en fonction des modifs incessantes, celui-ci peut changer... J'essaye donc de les attaquer (soit en getElementsByClassName, soit via jquery) par leur class olButton, mais cela ne répond pas. Ton retour me serait utile pour mieux comprendre leur ordonnancement.

Je suis entièrement d'accord avec toi, et je suis tout autant chagriné. Je me suis heurté aux mêmes problèmes en utilisant les noms de classe, et pour l'instant je ne vois pas comment contourner cela. D'où ma suggestion d'utiliser l'id, avec les contreparties négatives que cela engendre.

3/ Tu nous dis :"En attendant que nous corrigions ça de notre coté...." Cela veut dire que dans la prochaine version, cela sera intégré? Pour savoir à quel moment j'enlèverai ces rustines....

Je ne peux rien promettre. Je suis en train de fouiner un peu dans le code bas niveau pour essayer de cibler une correction. Mais pour l'instant je n'en suis qu'au stade de l'exploration.

[cmail]

Je ne reproduis pas ce comportement.

Comme c'est étrange car je confirme :
1/ Sous chrome ou IE, ici, je n'ai pas la perte du style dans la mesure du polygone, mais la correction n'est pas prise en compte puisque le clic maintenu ne se retrouve pas. Tu dois avoir fait tes essais avec un de ces navigateurs. Non?
2/ Par contre sous FF, la correction est bien prise en compte pour les 2 outils, mais le style disparait (pas de trace bleue) dans la mesure du polygone. Je n'avais testé que sous FF.

Pour l'ancien 2. Je vais essayer de comprendre à tête reposée...

Pour l'ancien 3. Tiens moi au courant de tes prochaines avancées pour se coordonner au mieux...

[jrenard]

Comme c'est étrange car je confirme :
1/ Sous chrome ou IE, ici, je n'ai pas la perte du style dans la mesure du polygone, mais la correction n'est pas prise en compte puisque le clic maintenu ne se retrouve pas. Tu dois avoir fait tes essais avec un de ces navigateurs. Non?
2/ Par contre sous FF, la correction est bien prise en compte pour les 2 outils, mais le style disparait (pas de trace bleue) dans la mesure du polygone. Je n'avais testé que sous FF.

J'ai beau faire des tests sous tous les navigateurs, de mon coté je réitère à chaque fois ce que je disais plus haut : aucune perte de style sur les polygones, et aucun retour au clic déplacement à la déselction de l'outil de mesure.

[cmail]

???? Je maintiens ce que j'écrivais.

aucune perte de style sur les polygones

Je parle bien du style (color bleu...) attaché à la "Mesure" des surfaces (et non des polygones "verts").

aucun retour au clic déplacement à la déselction de l'outil de mesure

Sous FF?

C'est vraiment étrange?
L'url de test est bien http://essai.obs43.fr/essai2014-12-0.html?