Nouvelle gestion des cartes avec OpenLayers. [Terminé]

[Dominique]

OpenLayers est une alternative à GoogleMap API pour afficher des cartes sur un site web. Pourquoi utiliser l'une plutôt que l'autre ? Techniquement les solutions se valent et mon choix est purement idéologique: utiliser un logiciel libre plutôt que le produit d'une société commerciale (même s’il est ouvert et libre de tous droits).
J’ai fait quelques essais ici: http://www.refuges.info/ol
Si cette initiative vous convient je reprogrammerai les cartes de WRI de cette façon.

A plus long terme, mon but est la convergence de sites de données cartographiques par superposition de couches. Vous pouvez en voir un exemple dans la carte générale. Cliquez sur le + bleu à droite et choisissez vos couches.
Là aussi, donnez moi votre avis sur l’utilisation qu’on peut en faire ou pas sur WRI. On peut envisager l’affichage de cartes de bien d’autres sites.

La suite est destinée aux développeurs:
Architecture logicielle:
Le but est de réduire le plus possible la programmation spécifique en utilisant la gestion des couches par Openlayers: 2 couches sont utilisées:
- Pour les Points j’ai juste appelé le très bon utilitaire d'exportation qui implémente déjà BBOX (sélection de la zone à afficher), la prioritisation et la limite de nombre de points affichés (120). Deux petites modifs sont juste nécessaires pour le rendre compatible avec la forme OpenLayers du paramètre BBOX (&bbox=7.18,45.57,14.13,47.83) et pour générer la balise <schemaUrl> contenant le lien cliquable de chaque point.
- Pour les massifs j’ai créé, sur la base du code de /index.php, l’URL http://www.refuges.info/ol/kml-massifs.php qui délivre les massifs sous forme de flux KML. (attention, cette page n'est destinée à être affichée directement !)

Protocole:
- Le plus logique serait WFS mais, à bien y regarder, il répond en format GML empaqueté dans tout un système de requettage qui n'apporte rien de plus à GML pour un simple affichage de carte.
- GML conviendrait mais je ne suis pas arrivé à afficher des pictogrammes ce qui est bien dommage pour la carte WRI! (si quelqu'un sait comment faire, il sera le bienvenu: XSLT ? SVG ?)
- GeoRSS m'aurait plu mais il n'affiche qu'un type de pictogramme par couche. Donc disqualifié aussi.
- Reste KML qui répond parfaitement au besoin. Bien sur on revient dans le domaine de Google mais seulement par l’origine de la spec qui a été reprise depuis par opengis.

Fichiers:
A part les 2 modifs de l’exportateur, tous les fichiers sont dans /ol
- index.html: la page de test (sans PHP !)
- ol.js: contient le code spécifique s’interfacant avec OpenLayers (notamment une petite bibliothèque pour générer des infobulles style windows, celles d’ OpenLayers ne me convenant pas).
- kml-massifs.php: le générateur du flux KML des massifs
- proxi.php: Un proxi en PHP, comme son nom l’indique: nécessaire dés qu’un flux est généré par un serveur différent de celui de la page initiale, les explorateurs bloquant les HttpRequest dans ce cas.
- La librairie OpenLayers-2.10 (sans modif mais expurgée de tous les fichiers exemples, doc, … qui prennent de la place pour rien)

Bugs: (juste pour vous éviter de me les signaler car je suis en train de les chasser)
- Quand il y a plusieurs couches, une seule est cliquable sous IE8 & FF3.6
- Si un picto est en bord de carte, l’infobulle ne s’efface pas en quittant la carte.
- Il semblerait que les requêtes HttpRequest des couches ne passent pas bien certains serveur proxy. Si vous avez l’occasion de surfer sur un intranet, pouvez vous faire le test ?

Au plaisir de lire vos remarques et à votre disposition pour la suite si vous en voulez.

[sly]

Salut dominique !

Techniquement les solutions se valent et mon choix est purement idéologique: utiliser un logiciel libre plutôt que le produit d'une société commerciale (même s’il est ouvert et libre de tous droits).

Je suis en phase avec toi sur l'idéologie ;-) (d'autant que je doute que la google API soit "libre de tous droits" )

J'ajouterais qu'au delà de l'idéologie, le système d'affichage de carte est dépendant du bon vouloir/fonctionnement de google, et ça n'est pas forcément très agréable.

La manifestation à court terme c'est ça :
http://code.google.com/intl/fr/apis/map ... script/v2/
"The Google Maps Javascript API Version 2 has been officially deprecated as of May 19, 2010."
En bref, celle que nous utilisons risque bien de s'arréter de fonctionner d'ici 3 ans, et, bien que l'évolution vers la version 3 ne soit sans doute pas trop difficile, j'ai horreur qu'on me l'impose.

J’ai fait quelques essais ici: http://www.refuges.info/ol
Si cette initiative vous convient je reprogrammerai les cartes de WRI de cette façon.

Impressionnant ! Tu as déjà réussi à tout convertir vers OpenLayers ! Sacré travail...

A plus long terme, mon but est la convergence de sites de données cartographiques par superposition de couches. Vous pouvez en voir un exemple dans la carte générale. Cliquez sur le + bleu à droite et choisissez vos couches.
Là aussi, donnez moi votre avis sur l’utilisation qu’on peut en faire ou pas sur WRI. On peut envisager l’affichage de cartes de bien d’autres sites.

Mon avis est toujours plus où moins le même, ça me va tant qu'au niveau utilisation on ne se retrouve pas submergé par tout un tas d'informations venues d'ailleurs et qui n'intéressent pas forcément l'utilisateur habituel de refuges.info

Il y a bien entendu un paradoxe caché dernière ces lignes, je suppose que si ton but c'est "la convergence", c'est sans doute pas pour qu'un obscur menu lointain de refuges.info active cette fonctionnalité, mais bien pour qu'elle soit visible non loin des fonctions habituelles. Et c'est là que je m'inquiète (toujours cette peur de l'inconnu), mais n'étant pas dans ta tête, je te fais confiance pour respecter cette volonté initiale du site.

Au final, je l'ai bien fait en rajoutant le fond de carte "rando" qui dispose de donnée venu d'ailleurs, et ça n'a pas reçu trop de commentaires négatifs.

== Partie pour développeur ==

Deux petites modifs sont juste nécessaires pour le rendre compatible avec la forme OpenLayers du paramètre BBOX (&bbox=7.18,45.57,14.13,47.83) et pour générer la balise <schemaUrl> contenant le lien cliquable de chaque point.

Je suppose que tu parles de l'export au format gpx, penses bien que l'export au format gpx est utilisé par deux composants :
- l'export proprement dit (au format gpx pour le télécharger)
- l'affichage sur carte google API

Aucune raison que l'ajout d'un paramètre ne change quoi que ce soit, mais penses-y.

- Pour les massifs j’ai créé, sur la base du code de /index.php, l’URL http://www.refuges.info/ol/kml-massifs.php qui délivre les massifs sous forme de flux KML. (attention, cette page n'est destinée à être affichée directement !)

Je ne sais plus du tout comment l'export des polygones fonctionnait, c'est yip qui l'avait fait. Sinon rien n'empêche de mener une réflexion plus lointaine sur le "est-ce toujours utile" ?
La page d'accueil rame de façon assez importante, le nom des massifs n'est pas lisible, au final, est-ce que la page d'accueil ne gagnerait pas à être une simple liste texte des massifs couverts ?

Protocole:
- Le plus logique serait WFS mais, à bien y regarder, il répond en format GML empaqueté dans tout un système de requettage qui n'apporte rien de plus à GML pour un simple affichage de carte.
- GML conviendrait mais je ne suis pas arrivé à afficher des pictogrammes ce qui est bien dommage pour la carte WRI! (si quelqu'un sait comment faire, il sera le bienvenu: XSLT ? SVG ?)
- GeoRSS m'aurait plu mais il n'affiche qu'un type de pictogramme par couche. Donc disqualifié aussi.
- Reste KML qui répond parfaitement au besoin. Bien sur on revient dans le domaine de Google mais seulement par l’origine de la spec qui a été reprise depuis par opengis.

Pour la petite histoire, yip qui est à l'origine du code pour la google API avait tenté au début de passer par les trucs "déjà fait" de la google API afin d'économiser le développement coté JS pour se concentrer juste sur le coté php
(il avait tenté les formats GML et KML) le bilan était qu'il manquait toujours un petit quelque chose dans l'implémentation google API.

Peut-être que OL permettrait de circonvenir à ces défauts, je ne sais pas...

Il a fini par utiliser mon générateur gpx (qui à l'origine ne servait qu'a exporter pour les GPS) et il s'est avéré que l'écriture du parseur en js, avec les libraires de gestion xml était tout à fait réalisable et avec plus de liberté.
( cf gmaps.js )

Évidement, cette démarche "entre moi et moi" c'est compromettre la compatibilité avec des tiers.
Mais j'ai beaucoup de mal à croire à cette "interface qui va chercher chez tout le monde"
Chez Openstreetmap, je vois un peu comment ça avance du coté des API (XAPI, nominatim,openstreetbugs,namefinder) elles deviennent soit surchargée, soit ses auteurs la délaisse, soit elles changent sans trop prévenir.

De sorte qu'il faut régulièrement suivre ce qui se passe chez les partenaires voir si l'url n'a pas changée, le format n'a pas changé, le site n'a pas coupé alors qu'une intégration du contenu donne plus d'autonomie au détriment de la fraîcheur.

Sans trop d'expérience séculaire là dedans, je dirais que si quelqu'un veut les données de refuges.info, ça me semble préférable de les télécharger, les traiter, les incorporer puis les afficher, ça sera plus stable que d'espérer que notre interface sera maintenue, et au niveau ressources ça utilise celle du site afficheur et non du notre

[Dominique]

je suppose que si ton but c'est "la convergence", c'est … pour qu'elle soit visible non loin des fonctions habituelles

Ma proposition est celle de la carte “Carte générale” de la page de test: des couches non activées par défaut avec le nom du site bien en clair. Suivant nos discussions précédentes, c’est ce qui m’a paru le plus adéquat notamment pour ne pas risquer de confondre avec les données internes du site. En supposant que celui qui clique sur « pyrenees-refuges.com » et voit apparaître de nouveaux points aura bien compris à quoi il a affaire.

je te fais confiance pour respecter cette volonté initiale du site

Tu peux, en démocrate irréductible et souhaitant seulement aider je ne me conformerai qu’à l’avis général. D’autant plus que si vous ne voulez pas de mes propositions je peux très bien les réaliser ailleurs. (ce que j’ai déjà fait dans d’autres temps)
Dites moi seulement si cette proposition vous intéresse.

Je suppose que tu parles de l'export au format gpx

Oui, en fait c’est le même utilitaire qui exporte plein de formats dont le KML qui m’intéresse.
- La première modif n’est pas disruptive car elle n’active rien tant qu’on n’utilise pas le paramètre &bbox=…
- La deuxième est seulement dans le code qui génère du KML. Donc ne touche pas aux exportations GPX. L’inconnue ici était le comportement des destinataires des exportations en KML qui voient arriver une nouvelle balise. Le principal destinataire du KML est GoogleEarth avec lequel j’ai fait quelques tests et qui semble bien l’accepter. Je ne pense pas que des GPS utilisent ce format en entier et de toutes façon ce que j’ai fait est conforme à opengis 2.2.

Aucune raison que l'ajout d'un paramètre ne change quoi que ce soit, mais penses-y.

En fait la modif est faire depuis une dizaine de jours et ne semble pas avoir posé de pb. Je sais bien que cet utilitaire est central, que les cartes de JM l’utilisent et j’ai fait plein de tests de non régression.

Je ne sais plus du tout comment l'export des polygones fonctionnait, c'est yip qui l'avait fait.

C’est très bien conçu et documenté. Je n’ai repris que la boucle principale et pas touché aux fonctions de base. De sorte que je n’ai pas eu à modifier les fichiers existants. Mon générateur de flux tient tout dans un petit fichier PHP de 80 lignes qui se plugge sur le reste.

est-ce que la page d'accueil ne gagnerait pas à être une simple liste texte des massifs couverts ?

Je ne pense pas. Un bon dessin vaut toujours mieux qu’un long discours. Par contre, il faut que je regarde si on ne peut pas afficher le nom des massifs sur la carte. On avait bien cherché avec JM et pas réussi avec GGM, mais peut être avec le fameux KML ?

j'ai beaucoup de mal à croire à cette "interface qui va chercher chez tout le monde"

J’ai abandonné l’idée depuis longtemps. Il n’y a trop de normalisations (GML, KML, GeoRSS, Vcards, …) et encore, chacune de ces specs admet de nombreuses variantes sans parler des différence d’implémentation et des bugs. J’ai essayé de réécrire la page point de WRI au format Vcard pour qu’elle soit lisible par un parser tout fait : C’est un cauchemar. Je n’ai aucun espoir de le faire faire par N webmestres qui n’ont rien à faire de mes petits travaux. Il faut s’interfacer sur ce qui existe.
Je me tourne vers la notion d’agrégateur de flux. C’est la façon dont sont réalisées les couches pyrenees-refuges.com & lacsdespyrenees.com de la page générale : Chemineur pompe ces sites avec des parsers spécifiques et les restitue au format « moi & moi » (KML avec BBOX et limite).
C’est ce qui m’a amené à m’intéresser à DRUPAL qui possède des modules aggregator, feeds & des aides à la construction de parsers. Quelques développements à venir sur Chemineur…

De sorte qu'il faut régulièrement suivre ce qui se passe chez les partenaires voir si l'url n'a pas changée, le format n'a pas changé, le site n'a pas coupé alors qu'une intégration du contenu donne plus d'autonomie au détriment de la fraîcheur.

YES ! J’ajoute que quand on agrège des bases géographiques qui parlent du même sujet on se retrouve avec des doublons qui nécessitent un gros travail de modération. Un site agrègateur n’est pas une sinécure.

au niveau ressources ça utilise celle du site afficheur et non du notre

Bien sur l’agrégateur doit servir de cache. Pas question de surcharger le site initial.

Autre sujet à traiter avec attention : la licence et l’autorisation du site agrégé :
N’ayant jamais eu de retour actif sur une telle coopération (la plupart n’ayant absolument rien compris à mes explications foireuses) j’ai fait le choix dans Chemineur de réaliser l’agrégation puis de prévenir le site en question de ce que j’avais fait en me mettant à leur disposition pour le retirer à la moindre demande. Ne visant que des sites non commerciaux je ne pense pas m’exposer à grand chose de grave.

Si cette initiative vous convient je reprogrammerai les cartes de WRI de cette façon.

Donc, je fais quoi ? (maintenant que le plus gros est fait, l’intégration dans les pages ne sera pas un gros travail).

[sly]

Dites moi seulement si cette proposition vous intéresse.

Oui

Donc, je fais quoi ? (maintenant que le plus gros est fait, l’intégration dans les pages ne sera pas un gros travail).

On intègre, je te laisse cependant gérer les retours de bugs ;-)

[Dominique]

2 cartes passées sur Openlayers ce soir:

- la vignette sur la page des points
Rien de spéctaculaire à première vue, à part que le logiciel n'est plus Google!
La vignette est maintenant navigable par déplacement ou molette de la souris
J'ai laissé le fond de carte de google car il contient beaucoup plus de noms que ceux d'OSM ou dérivés qui ne permettent pas de localiser l'endroit. Un ajout à letuffe.org ?

- la carte de la page de création/modification
A noter l'ajout d'un marqueur dont le déplacement permet de mofifier les coordonnées du point
Grosse galère sur openlayers qui ne permet pas d'activer de "listener" sur plusieurs couches. Résultat : impossible d'afficher le nom des cabanes au survol si on veut aussi gérer le marqueur.

Petite modif de l'export KML qui ne gérait pas la taille des différentes icones.

Un petit défaut: le chargement de la bibliothèque dure quelques secondes lors du démarrage de la première page. Aprés, c'est fluide jusqu'au rechargement de l'explorateur: A suivre!

Testé sur IE 6, 7, 8, FF 2.0 & 3.6.11, Chrome 7.0, Opera 10.63, Maxthon 2.5, K-Meleon 1.5.
Ne marche pas sur IE 5.5 & FF 1.x (normal et pas grave)
Signalez moi tout comportement anormal

[sly]

- la vignette sur la page des points
Rien de spéctaculaire à première vue, à part que le logiciel n'est plus Google!
La vignette est maintenant navigable par déplacement ou molette de la souris

Rien à dire, si en plus ça ajoute des fonctions, tant mieux !

J'ai laissé le fond de carte de google car il contient beaucoup plus de noms que ceux d'OSM ou dérivés qui ne permettent pas de localiser l'endroit. Un ajout à letuffe.org ?

A noter au passage que l'adresse préférable d'accès est maintenant : http://map.refuges.info (a priori plus de pérennité, et indiquant que c'est fait pour/par/en lien avec refuges.info)

Sinon, j'affiche déjà tout ce que je peux ou presque sur "mes" cartes rando, le problème c'est le manque de donnée dans openstreetmap.

En bref, je ne pense pas que le contenu d'openstreetmap ne puisse/ne devrait se substituer à la carte "relief" que propose google à court ou moyen terme comme choix de carte par défaut.

Je l'ai toutefois "poussé" un peu avec le lien juste en dessous de la vignette, mais je ne sais pas si c'est préférable en fin de compte. M'enfin du moment que l'accès aux autres cartes reste simple et bien visible pour le quidam moyen

- la carte de la page de création/modification
A noter l'ajout d'un marqueur dont le déplacement permet de mofifier les coordonnées du point
Grosse galère sur openlayers qui ne permet pas d'activer de "listener" sur plusieurs couches. Résultat : impossible d'afficher le nom des cabanes au survol si on veut aussi gérer le marqueur.

Pas dramatique lorsque l'on ajoute/modifie, le gain en ergonomie à pouvoir bouger le marqueur vaut largement cette très légère perte.

Très sympa comme ajout.

Note pour plus tard sur la grosse carte :
Je ne sais pas si ça peut se faire (je suppose que oui) mais je trouve le petit "+" bleu sur la droite par défaut d'openlayers pour choisir les couches un choix érgonomique vraiment médiocre. Cela ne prend en effet pas trop de place, ce qui est bien, mais est trés déroutant pour un non habitué et fait qu'en gros personne ne pense à appuyer sur ce "+".

[Dominique]

Je ne sais pas si ça peut se faire (je suppose que oui) mais je trouve le petit "+" bleu sur la droite par défaut d'openlayers pour choisir les couches un choix érgonomique vraiment médiocre. Cela ne prend en effet pas trop de place, ce qui est bien, mais est trés déroutant pour un non habitué et fait qu'en gros personne ne pense à appuyer sur ce "+".

Facile: il suffit de changer le .PNG qui va bien (et patcher un peu la librairie dans laquelle la taille est câblée en dur).
Dis moi si ce nouvel onglet te va.
Attention: il faudra peut être vider les caches des explorateurs.
Note: on peut aussi changer de couleur, mais j'ai peur que ça ne se voit pas sur tous les fonds de cartes.

[sly]

Rien à dire, impeccable.

Le mot français "cartes" étant plus parlant qu'un obscure "+" blanc (oui oui, blanc, parfois, c'est obscure)

[sly]

J'ai changé le titre pour moins d'obscurité de la discussion et inciter les trouveurs de bugs à nous rejoindre.

Aller, je commence :

Sur les mini cartes passées sous OpenLayers, le distinguo d'icone n'est plus fait entre les cabanes ou refuges qui ont comme statut détruit/fermé ou normal.

Idem pour celles ayant le "manque un mur"

La manière de gérer cela en base et la relation avec les icones n'est peut-être pas satisfaisante ou trop usine à gaz et je suis ouvert à en rediscuter ou l'expliquer si besoin

[Dominique]

Sur les mini cartes passées sous OpenLayers, le distinguo d'icone n'est plus fait entre les cabanes ou refuges qui ont comme statut détruit/fermé ou normal.

Bien vu. Je ne l'avais pas vu.
En fait, je ne fais rien sur le sujet... je me contente d'invoquer l'export KML et de l'envoyer à la couche qui va bien. C'est donc l'export qui ne marche pas. D'ailleurs, si tu fais un export KML vers GoogleEarth, tu as le même problème.
Reste à corriger l'exportateur. Dans fonctions_exportations.php ligne 114 $row->id_point_type n'est pas calculé en fonction des paramètres additionnels : tu as fait le calcul dans la gen GPX mais pas dans les autres. (c'est un peu spaghetti par là, si tu vois ce qu'il faut faire, je préfère que tu gères)

[sly]

ok.

Si je trouve un peu de temps, je m'occupe de factoriser et nettoyer un peu ce code et supporter plus modulairement les différents types d'export possible

[Dominique]

Si je trouve un peu de temps, je m'occupe de factoriser et nettoyer un peu ce code et supporter plus modulairement les différents types d'export possible

En attendant qu'une bonne âme remette tout au propre, j'ai charcuté le plat de spaghettis à grand coup de ketchup, parmesan et un bon coup de gril pour stabiliser le tout. ça pue mais ça affiche les bonne icônes.
Le premier qui a une bonne occasion de rester scotché à son écran une bonne semaine refait tout à zéro.

[Dominique]

Pour info, je vais standardiser la taille des icones à 16x16 pour éviter de tout recalculer à partir des .PNG à chaque export.
Je n'ai pas vu d'impact quelque part. Dis moi si tu en connais.

[sly]

Si je trouve un peu de temps, je m'occupe de factoriser et nettoyer un peu ce code et supporter plus modulairement les différents types d'export possible

En attendant qu'une bonne âme remette tout au propre, j'ai charcuté le plat de spaghettis à grand coup de ketchup, parmesan et un bon coup de gril pour stabiliser le tout. ça pue mais ça affiche les bonne icônes.
Le premier qui a une bonne occasion de rester scotché à son écran une bonne semaine refait tout à zéro.

ha ! Ceci explique donc pourquoi je voyais des fichiers datés de pas longtemps... c'est que tu étais dessus toi aussi. Bon, j'étais en train de rajouter des commentaires pour m'y retrouver, j'espère que je n'ai rien cassé, car évidement, pour des commentaires, je n'ai pas fais de copie de sauvegarde...

A chacun son tour de faire une bétise ?

PS: à noter que je ne suis pas fan du "tout refaire de zéro" le bidule à besoin d'un toilettage, d'accord, mais je ne vois pas de défaillance grossière dans l'architecturation du code

[sly]

Pour info, je vais standardiser la taille des icones à 16x16 pour éviter de tout recalculer à partir des .PNG à chaque export.
Je n'ai pas vu d'impact quelque part. Dis moi si tu en connais.

Le seul dont je me souvienne, mais qui ne doit plus avoir lieu d'être, c'est lorsque l'API google utilisait l'export en kml, yip avait remarqué des défauts dans l'implémentation avec les tailles d'icones.
(un truc du genre il fallait du 32x32 obligatoirement) ce qui, vraisemblablement n'est plus valable avec l'export GPX pour google maps