Travel tracker

La liste de fonctionnalités n'est pas une liste de souhaits. Chaque élément est quelque chose que l'acteur en place fait mal ou refuse de faire, noté pendant que je m'en servais vraiment en voyage.

Des traces GPS éditables. Un mauvais point dans Polarsteps est définitif. Ici une trace se corrige, parce qu'un téléphone au fond d'une poche dans un tunnel produit du charabia, et prétendre le contraire empoisonne chaque statistique en aval.

Map-matching et accrochage à la route. Des points épars reliés par des lignes droites, ce n'est pas un itinéraire. Reconstruire le vrai chemin, c'est ce qui donne un sens au chiffre de distance.

Début et fin de voyage manuels. Pas de frontière de minuit qui décide qu'un seul trajet faisait deux jours.

Un indicateur de santé du suivi, visible. Le pire échec ici est silencieux : les permissions sont révoquées, l'exécution en arrière-plan est tuée, et tu découvres des semaines plus tard qu'un pays entier manque. Si le suivi casse, l'application doit le dire d'elle-même.

De vrais exports. CSV et JSON des données brutes, plus des rapports PDF avec vitesse moyenne, altitude et température max/min — pas juste un livre photo imprimé.

Région, état et pays visités comme statistique de première classe, plutôt que quelque chose qu'on compte à l'œil sur une carte.

Google Photos lié par EXIF, avec correspondance sur le GPS et l'horodatage et une reprise manuelle, au lieu du modèle de suggestion faible.

Kotlin plutôt que React Native, décidé sur une exigence et non sur une préférence. Un GPS en arrière-plan fiable est le produit, et sur React Native l'option fiable est une bibliothèque payante tandis que celle de l'Android natif est gratuite et standard. Apprendre un nouveau langage coûtait moins cher que cette dépendance.

Jetpack Compose avec les défauts de Material 3, en m'appuyant sur le système de design au lieu de le combattre. Le design n'est pas mon point fort et Material 3 est un meilleur designer que moi.

Mapbox plutôt que Google Maps, choisi après avoir découvert que c'est ce que Polarsteps utilise lui-même — un signal raisonnable pour cette charge précise.

Un service Rust pour le travail géospatial : simplification d'itinéraire, map-matching, et calcul des statistiques de vitesse, altitude et distance. C'est la forme de charge où Rust gagne sa place plutôt que d'être choisi pour le plaisir.

PostgreSQL avec PostGIS, et pg-boss pour les jobs, ce qui veut dire pas de Redis du tout. À cette échelle, Redis serait un second bout d'infrastructure à garder en vie sans aucun bénéfice.

NestJS sur le back-end, en réutilisant le plan d'architecture des projets précédents sur une infrastructure séparée. Le quatrième projet à partir de ce document au lieu d'une page blanche.