C’est différent. Pour visugpx la page ne sert qu’à ça. Pour une page de sortie c2c, par exemple, c’est avant tout les infos de la sortie, la trace est un complément. Il n’est pas question d’avoir une page avec 2Mo pour dessiner sur la carte, c’est mauvais en terme de performance
Les infos sont dans la base (et pas en xml) car elles servent avant tout pour faire des traitements géographiques dans les requêtes (Récupérer les traces situées dans une bbox, etc)
Ok je comprends mieux la logique.
Du coup pourquoi ne pas stocker à part le gpx original (un peu comme une photo) et le resservir tel quel pour qui veut le télécharger ?
Je dis ça c’est surtout à cause de la simplification forte qui est faite actuellement qui dégrade trop le gpx pour une ré-utilisation en trace sur le terrain ( c’est mon point de vue en tous cas)
Si la simplification est moins forte et qu’on a des segment de moins de 10m la gestion séparée des gpx se justifierait moins.
Sans rentrer dans les détails ce n’est pas impossible mais pas forcément la bonne manière de procéder.
Déjà parce que les formats gpx y’a un peu de tout (traces, routes, waypoints, multisegments,…) et qu’il y a un traitement pour uniformiser ça, parce que pour simplifie la cohérence des données tu veux un stockage unique, parce à partir de la donnée tu sors un gpx un kml, ou …
Bref un tas de raisons qui font que c’est pas juste yakafokon (ce qui veut pas dire que ça doit pas évoluer hein, juste que y’a toute une réflexion à faire en amont quand même)
Ceci dit un truc simple serait déjà de trouver une tolérance acceptable, exprimée pour postgis, ça serait un changement simple et probablement suffisant
si vous voulez jouer avec le simplify de ol (drag and droppez un .gpx, puis modifiez l’input)
Ne me fais pas dire ce que je n’ai pas dit !, j’ai juste posé une question pas dit ce qu’il fallait faire… (je suis assez bien placé pour connaitre la différence…)
Je me base juste sur le cas de visugpx qui a priori procède comme ça (en tous cas le fichier téléchargeable semble identique au fichier uploadé)
Mais C2C n’est pas visugpx vous n’avez ni le même objectif ni les mêmes contraintes…
Comme je n’ai pas mis les mains dans le cambouis de C2C je me garderai bien de faire des reproches ou de dire ce qu’il y aurait lieu de faire…
Petite remarque (constructive hein !) en passant :
Sauf erreur ll me semble que dans les fichiers gpx qu’on télécharge depuis C2C il manque l’en-tête :
<?xml version="1.0" encoding="utf-8" ?>
(avec éventuellement standalone="yes" )
le fichier démarre direct par <gpx...
Certains logiciels le prenne tel quel mais d’autres n’aiment pas.
Pour ça le yakafokon ne doit pas être insurmontable 
Ma phrase en se voulait pas agressive ! Juste dire que c’est pas forcément réglé en 3min
Quoi ? mais c’est un scandale avec tout ce qu’on a payé pour la V6… 
Allez on vous le dit pas assez, bravo pour le boulot réalisé avec ses (grandes) qualités et ses (petits) défauts…
Même si un certain nombre d’utilisateurs autour de moi râlent et ne viennent plus ou en tous cas moins sur C2C, je suis persuadé qu’ils reviendront une fois qu’ils auront digéré la nouvelle approche.
pour le coup ça utilise la fonction de openlayers
c’est peut-être à eux qu’il faut suggérer la modif https://github.com/openlayers/openlayers/blob/master/src/ol/format/gpx.js
Bravo pour ton outil de démo !
Sur une majorité de trace que j’avais dessinées, je trouve qu’il ne faut pas monter au dessus de 10.
Sur l’exemple bessanese_S.gpx (31,3 Ko), ça se dégrade au dessus de 5. Vu le poids du-dit fichier, finalement, pourquoi le simplifier ?
Je n’ai pas les réponses toutes prêtes 
Je ne sais même pas le réel impact de la taille de la géométrie dans la base pour les perfs Vu que y’a des index et tout, ça doit pas être si pire. Ma principale inquiétude, c’est que pour les pages avec une trace GPX associée, on écrit la liste des points dans la page. Et c’est franchement une mauvaise idée d’avoir 2Mo de points juste pour afficher une petite carte (pensez aux mobiles par exemple)
Peut-être que stocker dans la base une version ‹ correcte+ › et servir une version plus simplifiée pour l’affichage serait ok, je ne sais pas trop…
Dans le cas de ton dernier fichier, il ne fait que 350 points de base. C’est sûr qu’il ne va pas être bien gros au final. Mais certains outils sortent des traces gpx parfois assez importantes (on avait eu un cas de mémoire à 11Mo…)
Si vous voulez faire des comparaisons avec la v5, ça utilisait gpsbabel pour la simplification camptocamp.org/ParseGeo.class.php at master · c2corg/camptocamp.org · GitHub
enfin je pense qu’on est tous d’accord pour dire que la simplification actuelle est trop forte
Par contre en dehors d’un aspect esthétique, franchement (dans l’outil ol), 10-15 ça donne quand même une très bonne précision pour une utilisation pratique.
On pourrait commencer avec ça, mais faudrait trouver l’équivalent en postgis 
question complètement novice, et qui a une portée plus générale que pour la seule question des traces gps : lors d’une chargement d’une page, le type de terminal (smartphone, tablette, ordi) et / ou le type de connexion (3/4g, wifi, …) est-il connu du serveur ? Auquel cas serait-il possible d’adapter le contenu, avec des données dégradées dans le cas d’un petite connexion, et les données totales dans le cas d’une connexion illimitée ?
Rien de vraiment utilisable actuellement.
Je préfèrerais une approche où on simplifié moins dans la base, on regarde la taille et éventuellement on restreint la taille renvoyée dans le document, quitte à télécharger un version plus précise quand on agrandit la carte où qqch du genre
Hello,
Est-ce que le sujet avance ou est-ce repoussé à des jours meilleurs ?
c’est repoussé à un moment où je ou qqun d’autre pourra tester les valeurs du epsilon pour postgis en 3856 
au moins pour se faire une idée de ce que la simplification donne pour plusieurs valeurs.
A partir de là on peut avancer sur le problème de ce qu’on veut stocker exactement, sevrir dans la page, etc…
D’autres avis seraient appréciables
remarque naïve (désolé si c’est débile) c’est normal, que les lignes de codes que tu indiques soient dans le répertoire « migration » ?
Pas faux. J’ai peut être dit des conneries sur où c’est fait dans le code actuel