Florence Birée a écrit 127 commentaires

On a pas souvent fait du hors-pistes (bon, c'est quand même amusant quelques fois quand on est sûr de soi), et c'est vrai que dans la montagne noire, c'est pas très complet (contrairement à Saint-Affrique, par exemple).

Je m'étais posé la question de faire participer les gamins à OpenStreetMap, mais vu comme le camp était déjà ambitieux (10 jours d'itinérance à monter et démonter la tente tous les jours), ça représentait trop de travail. Mais je garde l'idée pour des moments plus propices.

J'utilise le Genie BGT31, qui fait tout ce qu'on peut demander à un GPS de rando, qui possède des outils pour récupérer les données sous linux (via un script perl ou gpsbabel), et surtout, si on l'achète via StorageDepot, qui permet de faire un don de 10% du prix à la fondation OpenStreetMap.

(Et le service commercial de StorageDepot a l'air cool, en tout cas ils sont très réactifs pour répondre par mail.)

En changeant deux lignes du template html, tu peux appeler un autre serveur de tuiles (OpenStreetMap ou autre, voir même ton serveur de tuile perso monté pour l'occasion). Par contre, j'aime bien dans ce genre d'appli avoir une vrai carte glissante, et pas juste une image ne contenant que la rando : c'est toujours intéressant d'aller voir ce qu'il y a autour, ou de pouvoir dézoumer pour se situer par rapport aux endroits qu'on connaît...

Les css du rendu final sont bien sûr personnalisables à souhait, et j'ai fait les premières un peu à l'arrache dans l'urgence. J'aime bien avoir la liste plutôt que des bulles au survol sur la carte (probablement parce que les bulles font en général ramer mon pauvre petit pc, que ce soit avec google maps ou openlayers), mais encore une fois, c'est un template html et un css à modifier, donc chacun peut avoir son rendu préféré facilement.

On pourrait d'ailleurs imaginer un petite bibliothèque de couple template html / css. S'il y a des gens intéressés, à votre éditeur de texte !

Pour le survol, je suis tombé sur un problème de javascript avec OpenLayers : on peut soit générer un événement au survol des traces des étapes, soit sur les points (photos et lieux des étapes). J'ai donc choisi les photos et les lieux des étapes.

À priori, ce serait possible de faire les deux en changeant beaucoup de choses dans le code javascript, mais je ne suis pas trop motivé pour le faire pour l'instant (le javascript et moi...)

L'idée, c'est plutôt de fonctionner avec le GPS allumé en permanence (du début à la fin de chaque étape), en mode « data logger » : le GPS enregistre un point toute les n secondes (ou n mètres).

Ensuite, cette trace permet d'afficher le chemin de l'étape, et permet aussi de localiser la photo. Journey2web fait appel pour cela à gpscorrelate, qui regarde l'heure de la photo, et cherche le point correspondant dans la trace GPS (en faisant éventuellement de l'interpolation). La précision de la localisation de la photo dépends alors de la précision de la trace, et de la précision de la correspondance entre l'heure du GPS et celle de l'appareil photo.

Deux disques qui lâchent en même temps ? On est quand même sur une proba assez faible, non ?...

Si les deux disques ont été achetés en même temps, et ont eu la même vie, pas tant que ça...

Sur mon eeepc 701, le RC6 semble se porter à merveille (mais peut-être qu'il faudrait attendre un peu plus pour que le test soit concluant).

Par contre, c'est le "pcie_aspm=force" qui pose problème : en sortie de veille (suspend to ram), l'ordinateur se freeze quelques secondes après le réveil (peut-être au moment où laptop-mode essaye d'ajuster ses paramètres en fonction de l'état de la machine). En supprimant cette option, tout fonctionne à nouveau à merveille.

Le lien est corrigé, merci.

Pour la simplification des traces (et pareil pour les photos : orientation selon les infos exif, réduction de la taille), je le fais pour l'instant en amont, à l'aide de GPSBabel (et ImageMagick), je l'avais intégré dans mes scripts qui récupèrent les données depuis le GPS et l'appareil photo.

En attendant d'intégrer ça proprement dans Journey2web, j'ai copié collé les commandes que j'utilise sur le wiki de journey2web, vu que ça peut servir : http://dev.filyb.info/journey2web/wiki/tips

Ce que fait Digikam, c'est ce que fait Journey2web par un appel à gpscorrelate (correlation entre les dates des photos et la position GPS) : ce n'est pas le but premier de Journey2web (si tu lui donnes des photos qui ont déjà été géolocalisées, par exemple avec Digikam, il va le prendre en compte).

Par rapport à la solution que tu proposes, Journey2web est plutôt un remplacement de Google Maps, se basant sur OpenStreetMap, et dont tu peux mettre le résultat produit sur ton propre serveur. C'est vraiment un outil pour publier les données, pas tellement pour les créer ou les gérer.

(On pourrait très bien imaginer qu'il y ait un module d'exportation Journey2web dans Digikam... mais faut quelqu'un pour l'écrire ;-) )

Je connais (et ait utilisé) syj aussi, je pense que ça ne remplit pas exactement le même objectif : syj permet de créer et de partager un itinéraire, de façon user-friendly, d'ailleurs, mais s'arrête là (c'est très pratique pour expliquer à quelqu'un par mail comment se rendre quelque part).

Journey2web se concentre plus sur la présentation des étapes, photos, profiles d'altitudes, etc... et pas du tout sur la création des données (les traces doivent être déjà existantes... crées par un GPS, Viking... ou syj ;-) ). Enfin, Journey2web créé des fichiers statiques à déposer sur un serveur. Dans certains cas, ça peut être bien pratique !

Your web browser is too old to use with Movim.

... me dit le site de démo alors que j'utilise la dernière version de luakit.

C'est mal de faire des suppositions hazardeuses sur le user-agent !

Et après on se retrouve à surfer sur la version mobile du site avec son ordi quand on est sur une connexion pourrie (56k, 3G, wifi capté dans des conditions acrobatiques)...

Avoir des pages de faible taille, ça me paraît être un objectif pertinent quelque soit le terminal utilisé (qui n'a pas de rapport avec la qualité de la connexion disponible...).

Alors c'est dommage de le lier à des contraintes relatives à la taille de l'écran (j'avoue d'ailleurs que je préfèrerai parfois voir un site en vue « mobile » sur mon EeePC 701 et son écran en 800x480, même quand j'ai la connexion qui poutre de renater).

Donc arrêtons de mélanger taille d'écran, qualité de la connexion, et type de périphérique !

Il y en a pourtant déjà un (voir plusieurs) d'écrits (latex, pdflatex…)

Ben non, il manque paint, c'est très utilisé professionnellement pour imprimer le texte écrit dans notepad en collant une impression écran !

Il n'a peut-être pas d'amis

Mais si, j'en ai 41, regarde : http://per.sonn.es/Florian+Bir%C3%A9e (bientôt 42 !)

on en apprend plus sur ta vie privée depuis linuxfr et sur ton site, que si tu avais une page facebook

Ça c'est pas ma vie privée, c'est ma vie publique, puisque je le publie.

Super !

Bon, je me suis fait la mienne, avec une limite en ex, et en limitant aussi la largeur de section#container pour que le tout reste centré. C'est ici : http://florian.biree.name/public/linuxfr.css

Tu es myope ou quoi ?

Non, je ne crois pas, au contraire ;-)

On ne m'a jamais diagnostiqué aucun problème de vue, merci de ta sollicitude ! Et mon empan visuel me convient d'ordinaire plutôt bien : j'arrive à lire un bouquin de poche paragraphes par paragraphes, sans avoir à bouger les yeux pour lire chaque ligne.

Mais là, sur un écran 24", à environ 60 cm aussi, c'est vraiment pas confortable.

C'est une extension pour luakit ?

(Sinon, readability proposait à une époque un bookmarklet (donc quelque chose de multi-navigateur, si bien codé), mais ça ne semble plus être le cas.)

...ne pas avoir de compte facebook. Si si, ça marche même avec Firefox, et sans extension !

Cool, enfin quelque chose d'à-peu-près lisible !

La seule chose qui manque, à mon avis, c'est de rétrécir la largeur du texte à environ 60 ou 80 caractères. Cela évite de déplacer le regard sur une ligne lorsqu'on lit, c'est beaucoup plus reposant et on lit beaucoup plus vite (c'est ce que font les journaux avec leurs colonnes, c'est ce qu'essaye de faire LaTeX avec ses grosses marges). Alors évidemment, ça paraît complètement aberrant sur nos stupides écrans ultra-wide d'avoir une colonne de texte avec deux gros blancs de chaque côté, et de devoir scroller pour lire tout le texte, mais au final, c'est tellement confortable !

(Sinon, j'ai un bug avec le formulaire pour commenter : il y a un trou d'une dizaine de ligne entre les boutons « B », « I », « ul », etc et le textarea du commentaire. Navigateur : luakit/webkit)

(Ah... on parle de Coral, au temps pour moi. Mieux que coral, il suffit que linuxfr cache les avatar (comme précisé dans la spec), et on peut garder son avatar sur son serveur derrière sa box.)

Si. Tu dépends de nyud.net

Gné ? Explique-moi d'où tu sors ça ?

La spec : http://www.pavatar.com/spec/

Non, au contraire ! Tu ne dépends pas d'un service tiers pour avoir ce que tu veux :

Tu veux une url -> tu passes par un rétrécisseur -> tu arrives sur le bon site.

Tu veux un avatar -> tu récupère l'avatar sur le serveur de son propriétaire.

Tu n'as pas la faiblesse que si le rétrécisseur tombe, tu ne peux plus accéder au site que tu voulais, alors même que celui-ci est encore en ligne. Là, si le serveur hébergeant le pavatar tombe, tu n'as plus d'avatar, comme quand le site que tu veux visiter tombe, tu ne peux plus le voir. (Mais rien n'interdit le site utilisant les pavatar de les mettre en cache !)

Justement, sur un site pavator only, ça oblige à l'avoir, ce coin de serveur.

Ce n'est pas le cas quand (comme ici) on peut aussi uploader son avatar à la place d'utiliser un système externe.