Nouvelle gestion des cartes avec OpenLayers. [Terminé]
-
- Messages : 3705
- Enregistré le : 08 avr. 2006, 21:58
Oups, désolé pour tes commentaires. C'est vrai que je te dis de t'en occuper et que je m'y mets.
Les icônes sont maintenant toutes à la taille 16*16 (sauf la ville ou j'ai fait un if en dur).
L'emmerdant, c'est que GoogleEarth affiche des icones grossies, raison pour laquelle JM avait mis un <scale>0.5 mais comme j'utilise le même export KML pour la carte et G.E. je ne peux plus jouer dessus
Une autre optimisation serait de compresser en .js.gz la librairie openlayers (1Mo !) qui prend une bonne quinzaine de secondes à charger (du moins sur ma liaison ADSL antique). Mais je n'ai pas bien l'habitude de faire ça et je n'y arrive pas
Les icônes sont maintenant toutes à la taille 16*16 (sauf la ville ou j'ai fait un if en dur).
L'emmerdant, c'est que GoogleEarth affiche des icones grossies, raison pour laquelle JM avait mis un <scale>0.5 mais comme j'utilise le même export KML pour la carte et G.E. je ne peux plus jouer dessus
Une autre optimisation serait de compresser en .js.gz la librairie openlayers (1Mo !) qui prend une bonne quinzaine de secondes à charger (du moins sur ma liaison ADSL antique). Mais je n'ai pas bien l'habitude de faire ça et je n'y arrive pas
Dominique http://chemineur.fr
-
- Messages : 5041
- Enregistré le : 29 févr. 2004, 17:59
- Localisation : Chambéry - Savoie
Tu peux toujours faire muter ce paramètre selon le cas, ça reprendra tout de même 95% du codeDominique a écrit :Oups, désolé pour tes commentaires. C'est vrai que je te dis de t'en occuper et que je m'y mets.
Les icônes sont maintenant toutes à la taille 16*16 (sauf la ville ou j'ai fait un if en dur).
L'emmerdant, c'est que GoogleEarth affiche des icones grossies, raison pour laquelle JM avait mis un <scale>0.5 mais comme j'utilise le même export KML pour la carte et G.E. je ne peux plus jouer dessus
C'est bon, j'ai géréUne autre optimisation serait de compresser en .js.gz la librairie openlayers (1Mo !) qui prend une bonne quinzaine de secondes à charger (du moins sur ma liaison ADSL antique). Mais je n'ai pas bien l'habitude de faire ça et je n'y arrive pas
-
- Messages : 5041
- Enregistré le : 29 févr. 2004, 17:59
- Localisation : Chambéry - Savoie
-
- Messages : 3705
- Enregistré le : 08 avr. 2006, 21:58
OK je ne touche pas. Dis moi quand tu as fini. J'entame la carte des massifs et, comme je veux mettre des étiquettes, il y a du développement en local.sly a écrit :A noter que je commence à bosser (week end pluvieux de M...) sur une gros nettoyage des fonctions d'exportations
Qu'as tu fait pour la compression ? Apache mod deflate ? J'ai l'impression que c'est + rapide.
Dominique http://chemineur.fr
-
- Messages : 5041
- Enregistré le : 29 févr. 2004, 17:59
- Localisation : Chambéry - Savoie
-
- Messages : 3705
- Enregistré le : 08 avr. 2006, 21:58
Je pense aussi, c'est de base très bien fait. Il y a juste quelques effets de bords des ajouts récents.sly a écrit :Au fait, je disais "gros nettoyage" mais ce sera plutôt "petit nettoyage"
Mon problème sur la compression, c'est sur chemineur ou je n'ai pas d'action sur apache (à moins que ??? une variable dans un coin). A moins qu'ils ne l'aient mis de base ? c'est leur intérêt aussi. En principe, je devrais pourvoir gziper les .js, mais je n'arrive pas à les inclure.
Dominique http://chemineur.fr
-
- Messages : 5041
- Enregistré le : 29 févr. 2004, 17:59
- Localisation : Chambéry - Savoie
J'ai le nez dans le code depuis un moment, et je t'ai trouvé un peu médisant l'autre fois, ce n'est pas si mal que ça je trouve ;-). Bon, c'est sûr, y'aurait moyen de faire en sorte qu'une bonne partie du texte et le squelettes des kml/gpx parte dans des fichiers plats de type "templates" histoire de rendre la lecture plus simple mais bon...Dominique a écrit :Je pense aussi, c'est de base très bien fait. Il y a juste quelques effets de bords des ajouts récents.
Je viens donc de terminer pas mal de mes modifications, j'ai modularisé un peu plus encore, j'ai tout bougé dans des fonctions, et j'ai corrigé ton horrible bidouille basée sur mon immonde magouille qui consistait à inventer des faux id de type de point pour faire les icones des trucs fermés/sommaires.
Visiblement, je n'ai pas cassé openlayers qui affiche désormais bien les cabanes en ruines/détruites en plus de celles fermées.
(mon googlearth semble par contre me donner une erreur style <schemaURL> error truc, tu pourrais vérifier que tu arrives à ouvrir les kml ?)
si ça se trouve ça marche, dans firefox, tu fais "bouton droit -> information sur la page" et tu compares la taille annoncée (celle téléchargée) et la taille réélle du fichierMon problème sur la compression, c'est sur chemineur ou je n'ai pas d'action sur apache (à moins que ??? une variable dans un coin). A moins qu'ils ne l'aient mis de base ? c'est leur intérêt aussi. En principe, je devrais pourvoir gziper les .js, mais je n'arrive pas à les inclure.
-
- Messages : 3705
- Enregistré le : 08 avr. 2006, 21:58
tout à fait d’accord. Merci pour le ménage, j’avais fait les modifs à la serpe avec juste un commentaire d’alerte en attendant qu’une bonne âme... J’y jetterai un coup d’oeuil.sly a écrit : je t'ai trouvé un peu médisant l'autre fois, ce n'est pas si mal que ça je trouve .
Rien vu (kml, kmz OK). Essaye de désinstaller / reinstaller GGE ? Si <schemaURL> pose pb, j’essayerai d’utiliser un autre tag. Je voulais faire sans modifs openlayers, mais comme il est quasiment impossible de faire quelque chose un tant soit peu évolué avec sans charcuter en profondeur et que je m’y suis mis, je ferai autrement. Signale moi si le pb persiste. Je ne sais pas si quelqu’un utilise nos bases sous KML, mais ce serait dommage que ça ne marche passly a écrit : mon googlearth semble par contre me donner une erreur style <schemaURL> error truc, tu pourrais vérifier que tu arrives à ouvrir les kml ?)
Merci pour le tuyau. Mais non, ce n’est pas activé (pour éviter les pb de compatibilité arrière ?) Je vais creuser le point, mais Openlayers sur chemineur n’est pas pour tout de suite…sly a écrit : si ça se trouve ça marche, dans firefox, tu fais "bouton droit -> information sur la page" et tu compares la taille annoncée
Un autre point quand j’aurais fini (encore pas mal de boulot pour faire un bon truc sur ), il faudra que je rebuilde la librairie. J’imagine que je ne me sert pas des 1mo de code mignifié !
Templates & co. Effectivement, ou aurait un peu de lisibilité à gagner. Mais c’est un point très sensible. Une grosse concertation avant.
A propos, on doit barber les non informaticiens avec nos divagation. Quid d’un forum développeurs à portée limitée ?
Dominique http://chemineur.fr
-
- Messages : 5041
- Enregistré le : 29 févr. 2004, 17:59
- Localisation : Chambéry - Savoie
Franchement, t'emmerde pas, ça vient sans doute de mon coté, je mettrais à jour mon GGE qui doit dater et tout devrait rentrer dans l'ordre.Rien vu (kml, kmz OK). Essaye de désinstaller / reinstaller GGE ? Si <schemaURL> pose pb, j’essayerai d’utiliser un autre tag.
Je voulais faire sans modifs openlayers, mais comme il est quasiment impossible de faire quelque chose un tant soit peu évolué avec sans charcuter en profondeur et que je m’y suis mis, je ferai autrement.
Et je suis d'accord avec toi, autant trifouiller le moins possible la lib OpenLayers, sinon ce sera la galère le jour où on voudra la mettre à jour.
Et puis même chez moi ça marche, je dis "ignorer l'erreur" et tout semble s'afficher correctement ensuite.
C'est souvent cette raison invoqués par les hébergeurs (toujours la faute à cette vieillerie d'IE 6 qui foire sur des css deflatés), mais bon, j'ai trouvé la solution, il suffit de n'activer DEFLATE que pour le HTML/JSMerci pour le tuyau. Mais non, ce n’est pas activé (pour éviter les pb de compatibilité arrière ?)sly a écrit : si ça se trouve ça marche, dans firefox, tu fais "bouton droit -> information sur la page" et tu compares la taille annoncée
voir : http://httpd.apache.org/docs/2.0/mod/mod_deflate.html
Le jeu en vaut-il la chandelle ?, sur wri la taille téléchargée fait 230k au final et chargée une fois pour toute la visite.il faudra que je rebuilde la librairie. J’imagine que je ne me sert pas des 1mo de code mignifié !
brooaaaouff (soupir égoïste du "moi ça me dérange pas" ;-) ), ils n'ont qu'a pas lire non ?A propos, on doit barber les non informaticiens avec nos divagation. Quid d’un forum développeurs à portée limitée ?
On peut bouger cette discussion vers la zone modérateur et laisser juste un message disant "gros changement en cours sur les cartes ,prévenez vous en cas de problèmes" ?
Ma philosophie sur wri a toujours été un truc du genre :
- je rajoute des fonctions, des options et des trucs en faisant le minimum de tests (pour optimiser mon temps passé/nouveautés obtenues), et si une fonctionnalité foire ou un bug apparaît, je compte sur les utilisateurs pour faire les testeurs
-
- Messages : 3705
- Enregistré le : 08 avr. 2006, 21:58
L'erreur style <schemaURL> en était bien une:
schemaURL n'est pas une balise mais un attribut de la balise ExtendedData. Comme la récupération était dans une fonction ajoutée par moi ça marchait quand même sur la petite carte.
J'ai donc recodé avec une balise ExtendedData cette fois ci suivant la norme (enfin je crois...). Dis moi si tu vois toujours quelque chose.
Garde ta version GGE: elle est plus précieuse que la mienne qui doit être paramétrée pour ignorer les erreurs.
Au fait la correction est dans fonctions_exportations-sly.php (le fichier actif aujourd'hui)
Note: comme il y a aussi une modif dans /ol/ol.js il faut vider les caches!
schemaURL n'est pas une balise mais un attribut de la balise ExtendedData. Comme la récupération était dans une fonction ajoutée par moi ça marchait quand même sur la petite carte.
J'ai donc recodé avec une balise ExtendedData cette fois ci suivant la norme (enfin je crois...). Dis moi si tu vois toujours quelque chose.
Garde ta version GGE: elle est plus précieuse que la mienne qui doit être paramétrée pour ignorer les erreurs.
Au fait la correction est dans fonctions_exportations-sly.php (le fichier actif aujourd'hui)
Note: comme il y a aussi une modif dans /ol/ol.js il faut vider les caches!
Dominique http://chemineur.fr
-
- Messages : 5041
- Enregistré le : 29 févr. 2004, 17:59
- Localisation : Chambéry - Savoie
Et hop, quelle magie ! Plus d'erreurDominique a écrit : J'ai donc recodé avec une balise ExtendedData cette fois ci suivant la norme (enfin je crois...). Dis moi si tu vois toujours quelque chose.
Rhô... quel oubli de ma part, je ne suis pas nombriliste à ce point, c'était mon fichier de travail temporaire que j'ai oublié de supprimé... sans quoi j'aurais vu que le code y faisait référence, je corrige et j'en profite pour nettoyer un bon paquet de -OLD -sly -date qui commence à encombrer la vue et on va finir par mettre le code au mauvais endroit.Au fait la correction est dans fonctions_exportations-sly.php (le fichier actif aujourd'hui)
Willy avait peut-être raison, un truc de controle de source ça serait plus facile quand on bosse à plusieurs
-
- Messages : 3705
- Enregistré le : 08 avr. 2006, 21:58
Bof. j'utilise professionnellement mais c'est très très lourd. Si un jour on est 20 à développer pourquoi pas ?sly a écrit :Willy avait peut-être raison, un truc de controle de source ça serait plus facile quand on bosse à plusieurs
Par contre, une version de dev avec un url qui va bien ???
Dominique http://chemineur.fr
-
- Messages : 3705
- Enregistré le : 08 avr. 2006, 21:58
Pour info (au cas ou ça générerait un bug), par souci d'homogénéité et pour pouvoir les afficher plus facilement, j'ai renommé 2 massifs (à partir de phpMyAdmin)
Mont Cenis - Grand Paradis => Mont Cenis-Grand Paradis
Sainte Victoire/Var => Sainte Victoire-Var
Mont Cenis - Grand Paradis => Mont Cenis-Grand Paradis
Sainte Victoire/Var => Sainte Victoire-Var
Dominique http://chemineur.fr
-
- Messages : 5041
- Enregistré le : 29 févr. 2004, 17:59
- Localisation : Chambéry - Savoie
N'ayant jamais utilisé, j'ai voulu rêver que ça serait mieux. Mais je veux bien te croire que pour 2.5, ça fait un peu rouleau compresseur.Dominique a écrit :Bof. j'utilise professionnellement mais c'est très très lourd.
je faisais ça pendant un temps sur une machine locale, mais j'ai fini par abandonner car c'est un peu pénible lorsqu'il y a des modifications de base de donnée (structure ou même données) et il faut surtout bien penser à tous ces problèmes de chemins d'accès qui ne sont pas toujours les mêmes.Par contre, une version de dev avec un url qui va bien ???
Bref, peut-être tout simplement une zone /dev sur le serveur afin d'utiliser la même base quand même mais pouvoir faire plusieurs essais sur le code.
Mais finalement ça revient un peu à se qu'on fait : copier dans -old.php ou -sly.php, faire des essais et transférer ensuite.
A voir
-
- Messages : 3705
- Enregistré le : 08 avr. 2006, 21:58
Bonsoir grand chef vaudou.
J'en appelle encore à ta sagesse car je me perd en conjecture:
Je génère un flux XML (du KML en fait) en ISO-8859-1 : http://refuges.info/exportations/massifs-kml.php
Lorsque j’affiche ce flux via openlayers sur une page chargée à partir de WRI http://refuges.info/ol2 tout marche bien sur IE*, FF et Chrome.
Lorsque je l’affiche la même page chargée à partir de easyPHP ou de mon hébergeur (1&1) http://cavailhez.fr/ol2 rien ne s’affiche en IE*, FF affiche mal les caractères accentués tandis que Chrome s’en sort bien. Donc pb global sur l’interprétation de ISO-8859-1 (si je génère le même flux en UTF8, tout marche bien)
Je jure que les fichiers sur ces 2 serveurs sont les mêmes.
La source du flux est toujours WRI (et j'ai le même problème avec les exportations KML des points) donc ça ne vient pas de la source KML.
Comme il y a des pb sur IE6 IE7 IE8 et FF, même si l'effet n'est pas exactement le même, le pb de base ne vient pas de l’explorateur.
Comme j’ai exactement le même pb sur 1&1 et easyPHP et pas du tout sur WRI, la différence doit venir de la façon dont apache délivre les pages.
Comme tu es un grand spécialiste des paramètres optimisants de APACHE, peut être as tu configuré quelque chose pour ISO / UTF ?
Pas grave me diras tu pour le déploiement sur WRI puisque ça marche, mais j’aimerais savoir pourquoi. Ne serait ce que pour le reproduire ailleurs.
Au passage, ceci dévoile quelques essais de la carte des massif.
J’ai bien peur que ça soit très coloré. 3 variantes de couleur :
http://refuges.info/ol2
http://refuges.info/ol2/gris.html
http://refuges.info/ol2/blanc.html
Tous: dites moi ce que vous préférez
J'en appelle encore à ta sagesse car je me perd en conjecture:
Je génère un flux XML (du KML en fait) en ISO-8859-1 : http://refuges.info/exportations/massifs-kml.php
Lorsque j’affiche ce flux via openlayers sur une page chargée à partir de WRI http://refuges.info/ol2 tout marche bien sur IE*, FF et Chrome.
Lorsque je l’affiche la même page chargée à partir de easyPHP ou de mon hébergeur (1&1) http://cavailhez.fr/ol2 rien ne s’affiche en IE*, FF affiche mal les caractères accentués tandis que Chrome s’en sort bien. Donc pb global sur l’interprétation de ISO-8859-1 (si je génère le même flux en UTF8, tout marche bien)
Je jure que les fichiers sur ces 2 serveurs sont les mêmes.
La source du flux est toujours WRI (et j'ai le même problème avec les exportations KML des points) donc ça ne vient pas de la source KML.
Comme il y a des pb sur IE6 IE7 IE8 et FF, même si l'effet n'est pas exactement le même, le pb de base ne vient pas de l’explorateur.
Comme j’ai exactement le même pb sur 1&1 et easyPHP et pas du tout sur WRI, la différence doit venir de la façon dont apache délivre les pages.
Comme tu es un grand spécialiste des paramètres optimisants de APACHE, peut être as tu configuré quelque chose pour ISO / UTF ?
Pas grave me diras tu pour le déploiement sur WRI puisque ça marche, mais j’aimerais savoir pourquoi. Ne serait ce que pour le reproduire ailleurs.
Au passage, ceci dévoile quelques essais de la carte des massif.
J’ai bien peur que ça soit très coloré. 3 variantes de couleur :
http://refuges.info/ol2
http://refuges.info/ol2/gris.html
http://refuges.info/ol2/blanc.html
Tous: dites moi ce que vous préférez
Dominique http://chemineur.fr