Nouvelle gestion des cartes avec OpenLayers. [Terminé]

[sly]

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

Question lisibilité, le blanc sans fond n'est pas terrible, je préfère donc l'une des deux autres dont le fond du texte est de la couleur des bordures du massif. Entre noir et orange ensuite les deux me vont.

Sinon, tu fais comme tu veux, mais je te conseille de créer un nouveau sujet si tu veux plus d'audience, avec le titre de ce fil de discussion et notre joute technique en serbo-croate qui a suivi, je pense que beaucoup ont décroché !

[sly]

Bonsoir grand chef vaudou.
J'en appelle encore à ta sagesse car je me perd en conjecture:

Tu sais bien parler aux gens ;-) mais hélas, je suis très très mauvais en javascript et j'ai peur de ne pas t'être d'un grand secours sur ce problème qui y semble lié.

Lorsque je l’affiche la même page chargée à partir de easyPHP ou de mon hébergeur (1&1) http://cavailhez.fr/ol2

Sur la page que tu indiques, ton hébergeur ne renvoi pas de charset sur le
content type (Content-Type: text/html) pour te laisser le faire dans le code HTML par ta balise
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />

Bref, selon moi, ça aurait dû marcher, donc ça t'aide pas ;-)

Tentes le coup, remplaces ta page HTML par une page php et envoi la fonction :
header("text/html; charset=iso-8859-1");

(tentes le coup de faire pareil au début de ton proxi.php aussi )

Le fait que ça soit olé olé selon le navigateur indique à mon avis une différence de comportement par défaut face à une information non précisée

[Invité]

Lorsque je l’affiche la même page chargée à partir de easyPHP ou de mon hébergeur (1&1) http://cavailhez.fr/ol2

Si on "bouge" le fond de carte, les étiquettes de massifs ne bougent pas.... (Firefox) on peut donc avoir "Ecrins - Champsaur" du côté de Périgueux, voire de Toronto !
Why ?

[Dominique]

Si on "bouge" le fond de carte, les étiquettes de massifs ne bougent pas.... (Firefox) on peut donc avoir "Ecrins - Champsaur" du côté de Périgueux, voire de Toronto !
Why ?

Cher invité,
merci pour cette remarque fort juste et l'attention portée à nos travaux. Comme dit plus haut, il s'agit de "quelques essais" pour juger des couleurs, il y a encore un peu de travail avant de livrer. Il faudra que j'y pense.
Accessoirement, ça permet de déplacer Tarascon en Chartreuse, ce qui ne manque pas d’attraits!

[Dominique]

Tentes le coup, remplaces ta page HTML par une page php et envoi la fonction :
header("text/html; charset=iso-8859-1");

Rien de mieux (normal, en principe c’est equivalent à la balise META) mais tu as raison : fallait essayer

(tentes le coup de faire pareil au début de ton proxi.php aussi )

Alors là plouf. Ça perturbe curieusement la librairie CURL qui intérroge le serveur et lui fait provoquer une erreur 500.

Le fait que ça soit olé olé selon le navigateur indique à mon avis une différence de comportement par défaut face à une information non précisée

Entièrement d’accord. L’explorateur ne comprend pas qu’il a affaire à de l’ISO. Mais comment lui dire ?

J’ai aussi essayé de déclarer lang=fr et xml:lang=fr aussi bien dans la page que dans le flux. Bernique derechef.

Le plus bizarre, c’est que WRI envoie aux explorateurs un renseignement que comprennent FF et IE qui les fait interpréter correctement les XML avec de l’ISO mais je ne vois pas comment.
Peut être DefaultLanguage fr dans ta conf apache? Mais je ne vois rien dans phpinfo(). (j’ai vu ça sur web, mais je n’ai rien trouvé de semblable dans ma conf)

Bref je sèche. Je vais laisser tomber et continuer à intégrer sur WRI puisque ça marche mais j’aimerais quand même bien comprendre.

[sly]

header("text/html; charset=iso-8859-1");
(tentes le coup de faire pareil au début de ton proxi.php aussi )

Alors là plouf. Ça perturbe curieusement la librairie CURL qui intérroge le serveur et lui fait provoquer une erreur 500.
(...)
Bref je sèche. Je vais laisser tomber et continuer à intégrer sur WRI puisque ça marche mais j’aimerais quand même bien comprendre.

J'adore les chalenges ! plus c'est dur, plus ça me plait, et je suis trop tétu pour accepter que ma super idée n'était pas la bonne. (recevoir une erreur 500 laisse penser qu'on chauffe ;-) )

J'ai donc copié tout en provenance de chez toi sur un autre serveur de chez moi. J'ai tout d'abord eu le même résultat des accents foireux sur FF, j'ai entrepris alors de rajouter l'entête de content-type, et hop ça roule :
http://slyserv.dyndns.org/test-ol/

Le problème était donc bien au niveau de proxi.php, sauf qu'ayant fait un peu rapidement l'autre fois, j'avais mal écris le correctif.
c'est
header("Content-Type: text/html; charset=iso-8859-1");


La conclusion que l'on peut faire de tout ça, c'est que
placer ça dans l'entête xml coté refuges.info :
<?xml version="1.0" encoding="ISO-8859-1"?>
semble tout simplement inutile/hors norme/érroné

edit :
Après moultes nouvelles recherche, non, ce "prologue" est correct et même obligatoire par la norme xml (quand on est pas en UTF-8). Et l'ouverture direct par firefox en dépend et est, semble-t-il, bien géré. Le problème est donc lié, d'une façon ou une autre, à la librairie OpenLayers ou à javascript qui ne se base que sur l'encoding type donné par apache.

[Dominique]

Merci Sly,

1/ Pb sur le proxi : hum! J'ai les mêmes en chargeant directement un fichier dans le répertoire. C'est d’ailleurs ce que j'aurais du mettre comme exemple pour investiguer

2/ Pb dans la librairie. ça me plait bien conceptuellement: on ne traite pas correctement les flux rapatriés... donc ça peut très bien être au niveau d'Openlayers.
ça me plait moins quand le pense aux 1mo compactés qu'il va falloir décortiquer. D'autant que je ne suis pas non plus un fervent adepte du javascript et que je n'ai que très peu d'outils de debug.

[sly]

1/ Pb sur le proxi : hum! J'ai les mêmes en chargeant directement un fichier dans le répertoire. C'est d’ailleurs ce que j'aurais du mettre comme exemple pour investiguer

(2/ j'y pense même pas)

As-tu tenté mon correctif ? le fait que le xml soit dans un fichier plat ou rapatrié par le proxi.php ne change pas le problème à mon avis.

[Dominique]

Bonsoir,
Le correctif marche à merveille dans toutes les configurations. Bravo tu as bien cerné le pb.
Effectivement, OL adapte exclusivement son interprétation du flux sur le header.

J’ai commencé à regarder la librairie et pensé à monter un ticket, voir à proposer une correction mais je me suis ravisé :

- D’abord on n’est pas les seuls à s’être posé la question : http://www.mail-archive.com/users@openl ... 02367.html mais tous l’ont résolu côté serveur (en général Mapserver ou Geoserver) http://osgeo-org.1803224.n2.nabble.com/ ... 27702.html

- Au départ j’étais réticent à implémenter une solution au niveau du proxi parce que je vise toujours les échanges multisites et que le proxi est sur le serveur et la librairie sur le terminal.
Mais en y regardant de plus prés, sur une architecture multisites producteurs- consommateurs, le proxi est sur le site consommateur. On maîtrise bien tous les flux traités par l’agent sur le site générant la page puisque l’agent ne peut accéder qu’a des flux issus de son serveur ou passant par son proxi.

- Autre remarque : j’ai probablement généré moi même le problème puisque je n’ai pas utilisé le proxi livré avec les exemples OL (un truc en .GCI qui invoque /usr/bin/env python et que je n’ai même pas essayé de faire tourner sur windows / easyPHP). Bref, le proxi à pb, c’est moi qui l’ai pondu en 5 minutes sans un regard sur tous les IF python du .CGI qui devaient bien servir à quelque chose… Je réalise maintenant que ce proxi.cgi fait partie du package OL.

Reste soit à faire marcher le proxi.cgi sur le serveur (qui à l’avantage de traiter aussi les requêtes POST et le https), soit à compléter le mien. Je pense que ton correctif + un petit if sur le content type reçu m’ira bien pour l’instant, l’essentiel étant de comprendre ce qui ne marchait pas sous peine de le voir ressurgir à un moment ou à un autre. Merci pour ton aide.

[Dominique]

Bonjour
J’ai mis en service la nouvelle carte des massifs sur la page d’accueil.

A cette occasion, j’ai fait une relivraison complète de la librairie et de ses annexes avec quelques corrections de problèmes… Avec le fameux correctif SLY bien sur !
Je suis aussi passé sur GoogleMap API v3 (qui n’utilise plus de clé). Même si l’afficheur est Openlayers, il faut quand même appeler une API minimale pour accéder aux images des fonds de cartes.
Petit effet de bord: l’API v3 m’oblige à augmenter la largeur de la carte vignette dans la page des points parce qu'en dessous de 320px google considère que son copyright n’est pas lisible et affiche un affreux message sur lequel il faut cliquer. Exemple: http://www.refuges.info/ol2/test-gg.html

Fichiers modifiés :
/index.php
/point.php
/point_formulaire_modification.php
/include/style.css.php
/exportations/massifs-kml.php
/ol2/...
/include/fonctions_affichage_points.php
/include/fonctions_polygones.php
Comme d’hab, signalez moi tout problème ou suggestion.

[sly]

Avec le fameux correctif SLY bien sur ! :P

Je coyais que ce n'était pas nécessaire sur refuges.info et qu'un proxi sur wri était de trop puisque les données et l'interface venait du même domaine ?

Comme d’hab, signalez moi tout problème ou suggestion.

Pour la page d'accueil je propose de ne pas utiliser le fond maps.refuges.info

En effet, mon service de carte et susceptible d'être moins disponible que d'autres et en cas de panne, ça veut dire qu'on ne peut pas changer et que donc, je suppose, rien ne va s'afficher.

J'ai cependant bien noté que l'histoire du copyright non visible va nous casser les ....... pour les trop petites vignettes de droite.

Sinon, pas grand chose à dire, l'affichage des noms de massifs est un sacré plus par rapport à avant.

Dans le détail, il est marrant de voir le nom du massif en blanc sur noir si on survol le polygone, et en noir sur blanc si on survol le nom

[Dominique]

Avec le fameux correctif SLY bien sur !

Je coyais que ce n'était pas nécessaire sur refuges.info et qu'un proxi sur wri était de trop puisque les données et l'interface venait du même domaine ?

Tient c’est vrai ça! bonne remarque, je n’ai aucune suite dans les idées…
Je viens de virer tous les appels proxi et header, ça marche aussi bien… et ça ira plus vite.

Pour la page d'accueil je propose de ne pas utiliser le fond maps.refuges.info
En effet, mon service de carte et susceptible d'être moins disponible que d'autres et en cas de panne, ça veut dire qu'on ne peut pas changer et que donc, je suppose, rien ne va s'afficher.

Hum. Snif. Grosse déception. J’aime bien l’ensemble de couleurs. Et puis je n’ai pas noté de manque de disponibilité.
Et puis, je n’ai pas galéré sur OL pour afficher du GG non ?
Comme je ne peux pas m’y résoudre, j’ai trouvé un compromis: j’ai ajouté un switcher à la grande carte et basculé les petites sur OSM (là, c’est fiable non ?).
Au passage, j’ai fait un zoom arrière car j’ai pensé que ces cartes centrées sur une île ou un coin de l’Europe centrale n’étaient pas très parlantes.
Comme d’hab, signalez moi…

EDIT: il faudra vider les caches (appuyer sur "F5") car j'ai remonté les sytles dans le .CSS

[sly]

Et puis je n’ai pas noté de manque de disponibilité.

Car tu n'es pas 100% du temps à vérifier ;-) Moi qui suis dans les entrailles du truc, je peux affirmer que tout n'est pas parfait. Cela nécessite de grosses ressources et la machine que j'utilise peut rapidement saturer. Sans parler des nombreuses périodes de maintenance et de l'absence de sauvegarde et de redondance disque.

Et puis, je n’ai pas galéré sur OL pour afficher du GG non ?

De manière plus général, il n'y a pas grande chose à la hauteur de GG, à part IGN/géoportail.

Openstreetmap, tant sur la qualité de service, que sur le contenu en est encore loin et je préfère le considérer comme second choix

basculé les petites sur OSM (là, c’est fiable non ?).

Disons un peu plus que maps.refuges.info, mais c'est toujours loin de GG
http://wiki.openstreetmap.org/wiki/Tile_usage_policy
et toujours sans garanti d'aucune sorte

Mais bon, faisons comme ça. On changera le par défaut le jour où.

[Dominique]

Curieux que tu ne pousses pas open...
Mais tes raisons sont bonnes, pas de pb pour remettre les fonds GG. Il faut 2'
Dis le moi si tu préfères

[sly]

Curieux que tu ne pousses pas open...

Je préfère me considérer "pragmatique militant". Je ne convaincrais pas du bien fondé de l'open en imposant quelque chose de qualité encore médiocre.

Mais openstreetmap avance à grand pas, j'ai donc commencé par le mettre en option, puis sur certains liens, et lorsque l'état atteint tant en qualité qu'en quantité sera "suffisant", alors je n'hésiterais pas à le mettre en par défaut partout.

Mais tes raisons sont bonnes, pas de pb pour remettre les fonds GG. Il faut 2'
Dis le moi si tu préfères

Comme je le disais, et c'est d'autant plus vrai pour la vue de loin, si c'est compliqué restons comme ça, ça me va.
(je viens de tester avec maps.refuges.info coupé, et hors mis le fond blanc, les polyones sont toujours là avec leur nom, donc ça reste utilisable)