Traces GPS = simplification excessive

#1

Bonjour,

Je viens de m’apercevoir que les traces GPS que l’on peut charger quand on rentre une sortie sont simplifiées (réduction du nombre de point) de façon exagérée : 100 à 150m entre les points alors que ma trace d’origine (déjà simplifiée) comporte un point tous les 3-4 mètres.

Aujourd’hui sauf conditions particulièrement défavorable (forêt très dense, canyon très encaissé) la précision du GPS est systématiquement de 5m, parfois moins.
Avec la mise en place progressive de Galiléo il est probable qu’on va descendre au niveau du mètre.

N’est-ce pas préjudiciable de perdre complètement la précision des traces chargée sur C2C ?
100 à 150m ça ne permet plus de trouver un passage étroit dans le brouillard.

Je ne comprends pas ce choix : je suppose que ça n’est pas la taille des fichiers qui est en cause vu que là on arrive à des tailles de fichier ridicules de 10-20 ko alors que la moindre photos fait plusieurs centaines de ko.

Quelqu’un pourrait-il m’expliquer et me dire si on peut faire évoluer ça ?

Merci.

PS 1. L’idée n’est pas de faire une confiance aveugle aux traces, tout comme le topo peut comporter des erreurs ou approximations, il peut y avoir des bugs dans la trace, c’est à chacun de vérifier la cohérence.

PS 2. Je suis assez fasciné par le nombre de CR où on lit que des alpinistes ont perdu une heure ou deux à trouver un passage ou le départ d’une voie alors que si il existait un waypoint bien calé ils auraient trouvé sans coup férir…

#2

Ce défaut a déjà été relevé ; il est en attente d’un gentil développeur bénévole pour le fixer : https://github.com/c2corg/v6_ui/issues/1761

#3

Autant 150m est trop large, autant 3-4m est trop petit. Ca donne des traces avec 5000 points quand on fait un tour de 20km.
Ca alourdit le traitement à l’affichage, surtout sur mobile (ça consomme de la batterie en plus pour rien).
Et quand on veut afficher toutes les traces du coin, si chacune fait 5000 points, c’est encore pire.

#4

Où trouve t-on l’algorithme qui filtre les traces GPS ?

#5

là a priori

#6

Merci !
Visiblement c’est une fonction pré-programmée. Et si on passait le paramètre de ST_Simplify à 1 plutôt que 5 ? Y a t-il moyen de tester ça sur le serveur démo ?

#7

A priori, le 5 ça correspond à 5m en EPSG3857, donc ça veut dire qu’entre deux points gardés, la trace ne s’est pas éloignée de plus de 5m du segment entre les deux.
ça parait cohérent.

Mais si concrètement ça ne donne pas ça, faut peut-être revoir la tolérance passée à l’algo effectivement. Pour tester, je ne sais pas la main qu’il y a sur le serveur de démo donc je peux pas te répondre.
Tu peux peut-être essayer avec l’implémentation de Douglas Peuker dans d3.
Sinon si t’as un postgreSQL avec postgis tu peux tester directement dedans :slight_smile:

#8

En fait Oruxmap m’a gardé 1620 points pour un tour d’une vingtaine de kilomètres, ça fait un fichier de 158ko, pour les smartphones d’aujourd’hui c’est de la rigolade…
(la trace retraitée par C2C ne fait plus que 110 points)

Si pour des raisons d’affichage multitraces il faut simplifier beaucoup, peut-être pourrait-on au moins conserver la trace brute disponible pour le téléchargement ?

J’aurais bien volontiers essayé de regarder dans le code mais je pense que c’est assez largement au dessus de mon niveau de compétence et je ne connais pas Python.

Maintenant si on réduisait simplement le paramètre tolerance de la fonction ST_Simplify qui est actuellement à 5 pour voir ce que ça donne ? (aucune idée de l’unité à quoi ça correspond, ça n’est manifestement ni des mètres ni des degrés)

1 Like
#9

La doc dit que la tolerance est dans la même unité que le polygone ce qui ne m’avance pas à grand chose vu que je ne sais pas ce qu’il y a dans le polygone…

Mais au vu du résultat final on est à un point tous les 150 mètres donc ça n’est manifestement pas 5m

#10

En epsg3857 dont l’unité est le m si je lis bien le code :slight_smile:

Mais je t’accorde que ça se traduit visiblement pas comme ça, même si j’ai pas regardé les traces

#11

Ca serait possible de fournir un exemple de gpx original + lien vers le résultat incorrect ?

#12

Sur une de mes sorties, par exemple: Camptocamp.org

Fichier gpx original
2017-12-24_09-37-35.gpx (325,6 Ko)

#13

GPX issu d’Oruxmap
2018-01-14 0852__20180114_0852.gpx (217,0 Ko)

La course correspondante est : https://www.camptocamp.org/outings/959416/fr/col-de-la-cicle-voie-normale-depuis-notre-dame-de-la-gorge

#14

Bon n’ayant pas de base postgis sous la main, j’ai bricolé rapidement avec ol qui a aussi une implémentation de Douglas Peuker.

Mais l’epsilon donne visiblement pas trop le même résultat (pourtant j’ai pris garde de travailler en 3857)

En revanche , ça me fait quand même réfléchir à comment c’est implémenté. Actuellement, quand on l’uploade, c’est simplifié côté serveur. Point

  1. Pourquoi ne pas utiliser ol pour simplifier en amont ? ça limiterait les transferts, voire ça permettrait d’avoir une gestion plus fine. Du genre, on simplifie avec telle tolérance, mais si la trace est très longue et que du coup il reste plus que x points, on simplifie plus fort
  2. Il ne faut peut-être pas le même paramètre de tolérance pour quand on télécharge le gpx d’une sortie ou d’un iti, ou quand on veut l’afficher dans la page
  3. c’est stocké directement dans la base de données, pas comme les images. Donc on ne peut pas juste dire qu’on a qu’à stocker une trace de 2Mo, ça n’est pas vraiment équivalent

@alexduchablais @Tintin et autres devs, des avis ?

#15
  • je pense que c’est important d’avoir un seuil de tolérance. Si la trace est en dessous, pas besoin de la simplifier.
  • je ne mettrai pas de limitation en poids (sauf cas exceptionnel pour les raids si vraiment ça fait des fichier trop lourd pour des traces de plusieurs dizaines de km). À nous de trouver le bon paramétrage de simplification pour avoir la juste et nécessaire précision.
  • un critère intéressant, mais je ne sais pas si ça peut se trier facilement dans les entêtes du fichier gpx : si c’est un fichier brut sorti de GPS, alors il y a peut être besoin de simplifier. Si c’est un fichier « dessiné » sur skitrack et consort ou sous SIG, alors on peut penser que la précision de la trace est voulue et qu’il n’y a pas lieu de tenter de la supprimer
#16

euh, je sais pas si je suis clair, mais c’est le fonctionnement de l’algorithme de Douglas-Peucker d’avoir un seuil. La question c’est la valeur à prendre.
L’algorithme enlève des points, mais ne modifie pas ceux qu’il garde, c’est important à noter

#17

je tenterai d’abord avec 1m max d’écart par rapport au segment généré par les deux points entourant le point considéré.

#18

En général pour un tracé il n’y a pas de date/heure associés aux points de la trace.
Mais bon, rien n’interdit de faire un tracé de plusieurs milliers de points si c’est fait avec un outil ad-hoc… (peu courant sans doute)

Vous pourriez demander à Strava comment ils font pour gérer les traces parce que chez eux ça doit représenter des volumes stratosphériques :slight_smile: ( je rigole hein, Strava c’est de la big company commerciale )

Plus proche de nous il y a visugpx, lié à skitour (je ne sais pas trop si c’est Jeroen qui gère ça en direct ou si quelqu’un d’autre a repris cette partie)
=> l’upload est limité à 2 mo ce qui me semble une solution simple coté serveur.
Forcément c’est moins simple pour l’utilisateur qui a des fichiers plus gros et qui n’est pas à l’aise avec les jongleries GPX mais en cherchant un peu il y a plein d’outils sur le net.

Et il ne me semble pas que les traces soient simplifiées.
Il y a juste des opérations de retraitement sur les altitudes (intéressantes d’ailleurs mais il faut comprendre les subtilités)

Sinon je suis un peu béotien mais ça me semble étonnant de stocker du xml dans une base de données. Surtout que le gpx/xml ça se compresse très bien (ratio de 6-8 sur ce que j’ai sous la main)

#19

J’ai testé l’algorithme de simplification douglas peuker sous qgis et le paramètre de simplification de la fonction postgis ne correspond pas à celui de qgis…
Je suis plutôt à 15 pour avoir un rendu type c2c

#20

Ce n’est pas du XML qui est stocké, mais une ligne au format postgis.
Le gros avantage, c’est qu’on peut profiter de toutes les fonctions de postgis sur les lignes !
Par exemple trouver les itinéraires voisins d’une trace de sortie, et les associer automatiquement (ou au moins proposer une liste des itinéraires voisins). C’est une fonctionnalité qui est dans les tuyaux.