# GPX Viewer

[Suite de mes expérimentations](/david/2024/03/25/) de la veille à la fois en cartographie et en *web components*. Je me suis demandé s’il était possible de faire un composant qui ne dépende pas de uMap pour afficher une trace GPX. Le fait d’avoir passé une heure à trouver la bonne [CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) pour arriver à afficher une carte m’a d’une certaine manière motivé (c’était une journée galère).

Il se trouve qu’il existe [leaflet-gpx](https://github.com/mpetazzoni/leaflet-gpx) qui fait exactement ce que je voulais. Il ne me restait « plus qu’à » en faire un composant web, ce que j’avais déjà [fait par ailleurs](https://gitlab.com/umap-project/leaflet-webcomponents/) :

{{ extra }}

Alors en fait, comme rien n’est jamais simple en JS, il a fallu que j’adapte le plugin qui n’était pas compatible avec les modules JS et que je fasse des galipettes pour que ça finisse par tomber en marche 🤸. Cet écosystème est merveilleux (quel métier !). J’ai quand même [remonté le problème](https://github.com/mpetazzoni/leaflet-gpx/issues/153).

Au passage, inspiré par [le travail de Knut Hühne](https://blog.k-nut.eu/leaflet-microdata-html-webcomponent) sur la sémantique des données d’une carte, je me suis demandé si j’allais définir un [itinerary](https://schema.org/itinerary) pour un [Trip](https://schema.org/Trip) avec des [GeoCoordinates](https://schema.org/GeoCoordinates) mais ça m’a fait tirer un fil beaucoup trop long. Je garde l’idée sous le coude [pour mes propres recherches](https://umap-project.gitlab.io/leaflet-webcomponents/) dans le domaine cela dit.

Un composant de plus, je ne suis pas très satisfait de celui-ci car j’avais l’espoir d’arriver à quelque chose de facilement réutilisable. J’aurais au moins commencé à mettre les doigts dans le XML du format GPX. Il est possible de définir plusieurs segments au sein d’une même trace. Il peut y avoir pas mal de métadonnées, notamment de mise en forme de la trace mais aussi de caractéristiques (biologiques, physiques, etc).

---

> [en] The fact is that we can’t rely on any single website to hold the whole world’s knowledge, because it can be corrupted sooner or later. The only solution is a distributed architecture, with many smaller websites connecting with each other and sharing information. This is where ActivityPub comes in, the protocol used by Mastodon, Lemmy, Peertube and many other federated social media projects.
>
> I have worked on Lemmy for the past four years, bringing it from a prototype to a fully functional Reddit alternative. I wrote the entire federation code and became very familiar with the protocol. ==I realized that the same technology easily be used to create a federated encyclopedia.== As no one else took up such a project, I finally decided to do it on my own and create Ibis. Thanks to my previous experience with the tech stack and the ActivityPub library I created, I was able to complete a proof of concept in a relatively short time of four months.
> 
> <cite>*[Announcing Ibis, the federated Wikipedia Alternative](https://ibis.wiki/article/Announcing_Ibis,_the_federated_Wikipedia_Alternative@ibis.wiki)*</cite>

Wikipedia décentralisé, je dis oui ! Merci [Alex](https://alexsirac.com/activitypub-powered-wikis/).

C’est important pour [diverses](/david/2024/02/29/) [raisons](/david/2024/03/07/).

---

> [en] I think it’s time to admit that my hobby is buying stuff for my new hobby.
>
> <cite>*Chris Hallbeck*, [sur masto](https://mastodon.social/@Chrishallbeck/112153815963114685)</cite>

*Touché.*

#apprentissage #technique #web