[résolu] Données refuges.info non visibles.
-
- Messages : 539
- Enregistré le : 28 févr. 2013, 17:28
- Localisation : Montagne noire
[résolu] Données refuges.info non visibles.
Salut,
Quand je vais sur http://www.refuges.info/nav.php?zoom=8& ... fuges.info par exemple (pareil partout) je ne vois pas les pictogrammes WRI.
Notez que si j'ajoute d'autres calques ça marche sans aucun soucis.
Pour pouvoir les activer il me faut cliquer sur le «uniquement» en haut à gauche, qui se trouve dans une case sans titre.
Tchuusssss
Quand je vais sur http://www.refuges.info/nav.php?zoom=8& ... fuges.info par exemple (pareil partout) je ne vois pas les pictogrammes WRI.
Notez que si j'ajoute d'autres calques ça marche sans aucun soucis.
Pour pouvoir les activer il me faut cliquer sur le «uniquement» en haut à gauche, qui se trouve dans une case sans titre.
Tchuusssss
-
- Messages : 387
- Enregistré le : 08 mars 2004, 23:32
-
- Messages : 3704
- Enregistré le : 08 avr. 2006, 21:58
C'est le bug d'affichage intermittent des couches GML/SLD
Il n'apparaissait que très rarement avant la migration, mais beaucoup plus souvent depuis
Comme je soupçonne un problème d'asynchronisme entre plusieurs, flux, il ne serait pas étonnant que les nouvelles extraction soient plus longues (ou plus courtes) et révèlent ce bug
Il n'apparaissait que très rarement avant la migration, mais beaucoup plus souvent depuis
Comme je soupçonne un problème d'asynchronisme entre plusieurs, flux, il ne serait pas étonnant que les nouvelles extraction soient plus longues (ou plus courtes) et révèlent ce bug
Dominique http://chemineur.fr
-
- Messages : 5041
- Enregistré le : 29 févr. 2004, 17:59
- Localisation : Chambéry - Savoie
Quand même bizarre, on a testé le truc pendant des jours, et je n'ai pas remarqué une seule fois l'affichage de ces ronds orangeDominique a écrit : Il n'apparaissait que très rarement avant la migration, mais beaucoup plus souvent depuis
Modifié en dernier par sly le 08 mars 2013, 18:04, modifié 1 fois.
-
- Messages : 3704
- Enregistré le : 08 avr. 2006, 21:58
-
- Messages : 387
- Enregistré le : 08 mars 2004, 23:32
-
- Messages : 3704
- Enregistré le : 08 avr. 2006, 21:58
Tantôt aborted, tantôt canceled (donc par le JS !)yip a écrit :peut etre lié aux 2 downloads "aborted" qui précèdent toujours les 2 bons downloads de massifgml et epoxrtation ?Dominique a écrit :On a des ronds oranges quand le chargement du SLD n'a pas pu se faire
Mais je ne vois pas ce qui provoquerait ces erreurs
J'ai en effet construit la classe GMLSLD pour appeler en parallèle les GML & SLD, mais ça ne justifie pas les erreurs.
Une idée ?
Dominique http://chemineur.fr
-
- Messages : 387
- Enregistré le : 08 mars 2004, 23:32
Tu as raison Dominique, il semblerait bien que ce soit un probleme d'asynchro
du code correctif dans GMLSLD.js
--- Theorie pour les layers Aborted
Il paraitrait (voir lien en bas) que la cause des Aborted serait que UN SEUL objet XMLhttpRequest (autrement dit un Protocol HTTP d'openlayers) est utilise.
Comme les requetes sont asynchrones, Un seul objet XMLhtReq se retrouve a lancer plusieurs requetes.
Il est pas la deesse Shiva aux mille bras, donc il ABORT la precedente a chaque fois. Du moins partirait en cacahuète.
Une solution que j'ai testee et qui marche est de passer le SLD en synchrone (async: false;)
Ainsi, il n'y a plus de requetes aborted. les layers peuvent rester async:true. (j'avais aussi passé le SLD en async:false du temps de WFS)
Question Bonus : cela arrive t il paske tout ceci se passe dans la meme classe ? l'objet XHR a t il le même constructeur pour le SLD et le GML ?
Cela arriverait il en sortant le SLD de la classe (l'objet XmlHtpRequest est peut etre alors correctement cloné)?
--- Reminicence des style par defaut OpenLayers
Je crois bien que le probleme des styles par defaut d'OL (bug en cours) vient de la.
Voici 2 theories, je ne sais pas laquelle est bonne
--- 1ere explication style par defaut
Comme c'est asynchrone, pendant que la demande du style transite dans les tuyaux, il s'occupe de creer les layers GML.
Apres quoi il se tourne les pouces en attendant les réponses.
Quand les reponses arrivent, ils les traite et applique les styles (onsuccess).
Le style arrive quasiment toujours avant les layers (sans surprise quand on connait la difference de boulot pour le serveur).
Maintenant, prenons le cas ou le SLD, parti le premier de WRI, a pris une mauvaise option sur les autoroutes de l'information et se retrouve bloque dans les paquets TCP a la rocade de Bagnolet.
Le layer le double et arrive le premier chez OL.
Les directives du layer lui disent d'appliquer le SLD.
Seulement voila, pas de SLD (en plus du bug de variable), donc, pouf, style par defaut Orange.
--- 2e explication style par defaut
Maintenant prenons le cas ou OL tourne sur un PC asthmatique, au CPU ras la gueule.
Il met tellement de temps que quand la reponse du style arrive, ce qui va vite, il n'a pas encore fini de creer les layers.
Tant pis, seance tenante, il laisse tout en plan, et traite et applique le style.
Il l'applique a quoi ? a des layers qui existent pas
layers = [] Donc il applique quedale et on se retrouve avec le style OL default Orange.
Pas grave, Normalement, des que les layers arrivent, ils sont senses appliquer le SLD:
this.setStyle (sldFile);
Seulement voila, la variable sldFile ne peut pas exister (correctif du debut). re-plouf.
source : http://blog.haraldkraft.de/2011/12/fire ... x-request/
Voila l'idée. Je connais pas les implications eventuelles alors je te laisse décider quoi faire
(En fait ça a rien a voir avec le bug reporté au départ par Leo ça viendra)
du code correctif dans GMLSLD.js
Code : Tout sélectionner
OpenLayers.Request.GET({
url: options.urlSLD,
async: false;
Code : Tout sélectionner
if (OpenLayers.Layer.GMLSLD.prototype.sldFiles[options.urlSLD])
//this.setStyle (sldFile);
this.setStyle (OpenLayers.Layer.GMLSLD.prototype.sldFiles[options.urlSLD]); // car sldFile est une variable hors de ce scope.
--- Theorie pour les layers Aborted
Il paraitrait (voir lien en bas) que la cause des Aborted serait que UN SEUL objet XMLhttpRequest (autrement dit un Protocol HTTP d'openlayers) est utilise.
Comme les requetes sont asynchrones, Un seul objet XMLhtReq se retrouve a lancer plusieurs requetes.
Il est pas la deesse Shiva aux mille bras, donc il ABORT la precedente a chaque fois. Du moins partirait en cacahuète.
Une solution que j'ai testee et qui marche est de passer le SLD en synchrone (async: false;)
Ainsi, il n'y a plus de requetes aborted. les layers peuvent rester async:true. (j'avais aussi passé le SLD en async:false du temps de WFS)
Question Bonus : cela arrive t il paske tout ceci se passe dans la meme classe ? l'objet XHR a t il le même constructeur pour le SLD et le GML ?
Cela arriverait il en sortant le SLD de la classe (l'objet XmlHtpRequest est peut etre alors correctement cloné)?
--- Reminicence des style par defaut OpenLayers
Je crois bien que le probleme des styles par defaut d'OL (bug en cours) vient de la.
Voici 2 theories, je ne sais pas laquelle est bonne
--- 1ere explication style par defaut
Comme c'est asynchrone, pendant que la demande du style transite dans les tuyaux, il s'occupe de creer les layers GML.
Apres quoi il se tourne les pouces en attendant les réponses.
Quand les reponses arrivent, ils les traite et applique les styles (onsuccess).
Le style arrive quasiment toujours avant les layers (sans surprise quand on connait la difference de boulot pour le serveur).
Maintenant, prenons le cas ou le SLD, parti le premier de WRI, a pris une mauvaise option sur les autoroutes de l'information et se retrouve bloque dans les paquets TCP a la rocade de Bagnolet.
Le layer le double et arrive le premier chez OL.
Les directives du layer lui disent d'appliquer le SLD.
Code : Tout sélectionner
this.setStyle (sldFile);
--- 2e explication style par defaut
Maintenant prenons le cas ou OL tourne sur un PC asthmatique, au CPU ras la gueule.
Il met tellement de temps que quand la reponse du style arrive, ce qui va vite, il n'a pas encore fini de creer les layers.
Tant pis, seance tenante, il laisse tout en plan, et traite et applique le style.
Il l'applique a quoi ? a des layers qui existent pas
Code : Tout sélectionner
for (i in layers)
Pas grave, Normalement, des que les layers arrivent, ils sont senses appliquer le SLD:
this.setStyle (sldFile);
Seulement voila, la variable sldFile ne peut pas exister (correctif du debut). re-plouf.
source : http://blog.haraldkraft.de/2011/12/fire ... x-request/
Voila l'idée. Je connais pas les implications eventuelles alors je te laisse décider quoi faire
(En fait ça a rien a voir avec le bug reporté au départ par Leo ça viendra)
-
- Messages : 3704
- Enregistré le : 08 avr. 2006, 21:58
:YIP J'étais bien d'accord avec toutes tes déductions et me suis mis dare dare à patcher à tout va... à grand coup d'analyse de ce qui remonte sur le réseau...
... pour qu'un message d'erreur enfin débusqué par le async: false ne vienne débusquer le mystère:
L'ERREUR des débutants en apprentissage des premiers pas en informatique: la variable sldFile de la ligne 65 de GMLSLD.js n'était pas initialisée !!! D'ou erreur aléatoire
Tout marche impec chez moi sur les traces réseau
A vous de vérifier que le problème est bien résolu dans tous les cas
Dominique http://chemineur.fr