et également merci à Christophe pour la mention de PiGallery2.
Je vais probablement me servir de tout ça comme source d'inspiration.
Ça tombe à pic : je suis justement en train de me préparer pour un petit voyage où je compte partager mes photos depuis un blog avec une carte interactive. Et je suis en train de programmer un truc pour ça, avec un peu de chance j'aurai fini à temps. Ça tombe tellement à pic que je me suis un instant demandé si je n'allais pas jeter une semaine de travail pour reprendre l'idée de ce journal telle quelle. Mais je vais persister.
Je n'ai pas nécessairement besoin de traces GPX (mais ce serait chouette de l'avoir), par contre l'idée serait d'avoir des articles de blog (des "étapes") dans lesquelles il y a des photos.
Sans Javascript, le site statique généré ressemblerait à un blog classique, mais avec Javascript, le visiteur pourra se balader sur une carte et dans une visionneuse, dans l'esprit « progressive enhancement » le plus fidèle. La visionneuse devrait permettre de se balader dans les descriptions et d'afficher les photos, avec une option pour rester dans la même étape ou pour traverser la visite entière. Les photos seront affichées avec un petit descriptif s'il est fournit.
Un flux RSS serait généré pour que les deux seules personnes au monde avec un lecteur RSS puissent être notifiées des mises à jour.
Le site serait généré à partir d'un dossier Nextcloud partagé publiquement (c'est du WebDAV très standard derrière, mais Nextcloud génère aussi des miniatures et je compte réutiliser ça au moins dans un premier temps). Un bouton importer irait interroger le dossier et stocker les infos dans une petite base SQLite à partir de laquelle le blog serait généré. Seuls les fichiers changés seraient réévalués, c'est aussi là que la base SQLite est justement utile, mais restant "sobre" comme le dit l'article.
Le dossier partagé contiendrait des fichiers Markdown avec front matter qui décrivent ces fameuses étapes, très compatible avec ce qu'attendrait un générateur de sites statiques tel qu'Hugo. Ces fichiers Markdown afficheraient des photos et ces photos peuvent contenir des données GPS. Dans le front matter des étapes, on pourrait définir une date, une localisation gps, voire un noeud OSM. Les localisations GPS des images seraient récupérées mais pourraient aussi être spécifiés dans les fichiers d'étape : ça permettra d'ajouter les localisation à la main directement dans le fichier d'étape sans devoir utiliser des outils complexes ou en ligne de commande, quitte à ajouter les localisations aux fichiers eux-mêmes dans un second temps.
Et par défaut, si la localisation manque pour une photo, c'est la localisation de l'étape qui sera utilisée, donc ça pourra ne pas être trop fastidieux au pire.
Nextcloud ayant un éditeur Markdown WYSIWYG, ou le dossier pouvant être synchronisé sur un appareil doté de l'éditeur markdown de son choix, le tout serait utilisable par quelqu'un qui n'est pas technique. Je le sais déjà, j'ai déjà un site de recettes reposant sur un système comme ça, mis à jour avec succès par quelqu'un d'autre que moi. Et si l'outil venait à disparaitre, le blog ne disparaîtrait pas avec puisqu'il serait entièrement consultable avec n'importe quel éditeur Markdown standard.
# Merci pour le partage
Posté par raphj (site web personnel) . En réponse à la dépêche Photos et traces gps dans un blog statique. Évalué à 4. Dernière modification le 02 juin 2025 à 16:55.
et également merci à Christophe pour la mention de PiGallery2.
Je vais probablement me servir de tout ça comme source d'inspiration.
Ça tombe à pic : je suis justement en train de me préparer pour un petit voyage où je compte partager mes photos depuis un blog avec une carte interactive. Et je suis en train de programmer un truc pour ça, avec un peu de chance j'aurai fini à temps. Ça tombe tellement à pic que je me suis un instant demandé si je n'allais pas jeter une semaine de travail pour reprendre l'idée de ce journal telle quelle. Mais je vais persister.
Je n'ai pas nécessairement besoin de traces GPX (mais ce serait chouette de l'avoir), par contre l'idée serait d'avoir des articles de blog (des "étapes") dans lesquelles il y a des photos.
Sans Javascript, le site statique généré ressemblerait à un blog classique, mais avec Javascript, le visiteur pourra se balader sur une carte et dans une visionneuse, dans l'esprit « progressive enhancement » le plus fidèle. La visionneuse devrait permettre de se balader dans les descriptions et d'afficher les photos, avec une option pour rester dans la même étape ou pour traverser la visite entière. Les photos seront affichées avec un petit descriptif s'il est fournit.
Un flux RSS serait généré pour que les deux seules personnes au monde avec un lecteur RSS puissent être notifiées des mises à jour.
Le site serait généré à partir d'un dossier Nextcloud partagé publiquement (c'est du WebDAV très standard derrière, mais Nextcloud génère aussi des miniatures et je compte réutiliser ça au moins dans un premier temps). Un bouton importer irait interroger le dossier et stocker les infos dans une petite base SQLite à partir de laquelle le blog serait généré. Seuls les fichiers changés seraient réévalués, c'est aussi là que la base SQLite est justement utile, mais restant "sobre" comme le dit l'article.
Le dossier partagé contiendrait des fichiers Markdown avec front matter qui décrivent ces fameuses étapes, très compatible avec ce qu'attendrait un générateur de sites statiques tel qu'Hugo. Ces fichiers Markdown afficheraient des photos et ces photos peuvent contenir des données GPS. Dans le front matter des étapes, on pourrait définir une date, une localisation gps, voire un noeud OSM. Les localisations GPS des images seraient récupérées mais pourraient aussi être spécifiés dans les fichiers d'étape : ça permettra d'ajouter les localisation à la main directement dans le fichier d'étape sans devoir utiliser des outils complexes ou en ligne de commande, quitte à ajouter les localisations aux fichiers eux-mêmes dans un second temps.
Et par défaut, si la localisation manque pour une photo, c'est la localisation de l'étape qui sera utilisée, donc ça pourra ne pas être trop fastidieux au pire.
Nextcloud ayant un éditeur Markdown WYSIWYG, ou le dossier pouvant être synchronisé sur un appareil doté de l'éditeur markdown de son choix, le tout serait utilisable par quelqu'un qui n'est pas technique. Je le sais déjà, j'ai déjà un site de recettes reposant sur un système comme ça, mis à jour avec succès par quelqu'un d'autre que moi. Et si l'outil venait à disparaitre, le blog ne disparaîtrait pas avec puisqu'il serait entièrement consultable avec n'importe quel éditeur Markdown standard.
Bref, à suivre.