Désactiver le calcul automatique des données altimétriques pour les itinéraires importés depuis un parser

[bruhnild]

Actuellement pour deux itinéraires identiques provenant d'une instance geotrek-admin avec segmentation dynamique et d'une instance geotrek-admin sans segmentation dynamique (sans tronçons, comme c'est le cas avec l'agrégateur), les valeurs de dénivelés peuvent être différentes de plusieurs dizaines à plusieurs centaines de mètres.

Voilà comment est calculée l'altimétrie pour deux itinéraires identiques provenant de deux instances avec et sans segmentation dynamique :

• Sur une instance avec tronçons, la géométrie 3D d'un itinéraire est calculée à partir de la somme des géométries en 3D des tronçons parcourus.
• Sur une instance sans tronçon, l'altimétrie est calculée à partir de la géométrie de l'itinéraire importé (parser). La géométrie 2D de ce dernier en 4326 est reprojetée en projection locale (2154), puis transformée en 3D. La 3D est créée en utilisant des point intermédiaires tous les 25 mètres (voir le paramètre ALTIMETRIC_PROFILE_PRECISION sur https://geotrek.readthedocs.io/en/2.104.2/install/advanced-configuration.html). Il y a donc une perte de précision suite à ces transformations.

Afin d'éviter ces différentiels de valeurs, il faudrait désactiver le calcul automatique des données altimétriques (pente, longueur, altitude) pour les itinéraires importés depuis des parsers. De cette façon, les valeurs de pente de l'itinéraire importé seraient identiques avec celles de l'itinéraire d'origine (provenant de l'instance avec segmentation dynamique).

Si un itinéraire importé ou créé dans geotrek-admin est amené à être modifié, il faudrait que le calcul de la pente soit de nouveau opérant.

[camillemonchicourt]

Ou alors homogénéiser la manière de calculer l'altimetrie des itinéraires ?

Je m'interroge sur la fait qu'avec segmentation dynamique, l'altimetrie de l'itinéraire soit la somme de l'altimetrie des tronçons qu'il emprunte. Si un itinéraire emprunté des tronçons partiellement, l'altimetrie calculée est donc fausse ?

On peut aussi importer des données sans altimetrie et il est alors utile de la calculer lors de l'import. Donc je dirai plutôt qu'il faut fixer une règle (ou une variable adaptable) pour définir qu'on ne calcule pas l'altimetrie si elle est fournie dans la donnée source, sinon la calculer. Et que cela soit adaptable au niveau du parser pour pouvoir forcer le recalcul lors de l'import même si l'altimetrie est fournie dans la donnée source importée.

[babastienne]

Ou alors homogénéiser la manière de calculer l'altimetrie des itinéraires ?

Pas simple en l'état, car déjà ne serait-ce qu'en important un itinéraire d'un geotrek à un autre il y a plusieurs conversions d'effectuées dans des systèmes de projection différents donc il ne pourra pas y avoir le même résultat.

Perso plus je me plonge dans le sujet plus je trouve ca compliqué et tordu. Par exemple le seuil de précision d’échantillonnage : dans Geotrek il est à 25m par défaut, pourquoi ? Si on diminue le seuil on pourrait croire que la précision sera plus grande mais en fait la valeur augmente exponentiellement, ce qui fait qu'un itinéraire avec 800m de D+ avec une précision de 25m passe à 1600m de D+ avec une précision de 5m.

Il y a un contexte historique de décisions prises dans Geotrek que je n'ai pas, et je pense que le fait de tout vouloir rattacher aux tronçons créé une complexité importante.

Après ceci dit j'ai fait quelques tests et pour une même trace GPX importées dans 6 outils différents j'obtiens 6 dénivelé positifs différents, allant parfois du simple au double. Donc la problématique n'est pas inhérente qu'à Geotrek j'ai l'impression.

[babastienne]

En gros calculer le même dénivelé exactement sur deux instances qui ne supportent pas la même gestion de stockage des contenus me semble très compliqué, d'où la proposition de ce ticket de simplement récupérer une valeur altimétrie lorsqu'elle existe pour ne pas la re-calculer.

[camillemonchicourt]

Je parlais d'homogénéiser le mode de calcul des altimétries que l'on soit avec ou sans segmentation dynamique. Dans les 2 cas, je ne vois pas pourquoi on n'utilise pas la géométrie de la topologie, mais qu'on agrège celle des tronçons de la topologie. Cela complique selon moi et est même faux si on prend les tronçons dans leur globalité, une topologie pouvant utiliser une partie seulement de certains tronçons.

Sur les MNT, les seuils, les lissages, il faut voir ces 2 tickets :

• https://github.com/GeotrekCE/Geotrek-admin/issues/840
• https://github.com/GeotrekCE/Geotrek-admin/issues/1452 Cela explique clairement pourquoi, augmenter la précision du MNT augmente les effets de bord et augmente le dénivelé de manière fausse.

Le soucis n'a pas de rapport avec le fait que les itinéraires sont associées aux tronçons. Par contre pour l'altimétrie des itinéraires (et autres topologies), il n'y a pas de raison de ne pas utiliser la géométrie résultante de la topologie. Je ne vois pas de raison à utiliser la somme des altimétries des tronçons empruntés par les topologies.

Je suis d'accord sur la possibilité de garder l'altitude fournie par la source lors d'un import. Mais je pense qu'il faut garder la possibilité de recalculer toutes les altitudes automatiquement lors d'un import, même si celle-ci est fournie par la source, pour que toutes les données agrégées soient cohérentes.

[babastienne]

Côté CD39, on a réussi à obtenir une configuration de calcul d'altimétrie sur l'agrégateur qui permet d'obtenir des résultats proches de ceux existants dans la base GTA de travail. Pour cela les paramètres retenus sont les suivants :

ALTIMETRIC_PROFILE_PRECISION = 24
ALTIMETRIC_PROFILE_AVERAGE = 4

Toutefois, après étude, le CD39 observe que les dénivelés sont toujours éloignés d'autres référentiels, particulièrement dans le cas des longs itinéraires. Ci-dessous le retour effectué par le département :

Pour info, j’ai également téléchargé ces parcours dans les outils VisuGPX et Garmin Connect qui étaient nos références avant d’utiliser Géotrek.

J’ai remarqué une différence croissante du D+ pour les parcours au-delà de 50 km.

Exemple pour les parcours VTT, VisuGPX et Garmin restent assez homogènes du Tour des Cinq Lacs (23 km) jusqu’à l’Echappée Jurassienne VTT (295 km).

A partir de l’Arcadienne (57,3 km), le D+ de Jura Outdoor commence à augmenter pour atteindre une différence de 2450 m de D+ sur l’Echappée Jurassienne VTT.

Idem pour les parcours de cyclisme sur route où les différences sont croissantes à partir de la boucle Jura Monts Rivières (69 km).

Nous communiquons depuis 10 ans sur le Tour du Jura Loisirs (158 km / 1 000 m D+) et le Tour du Jura Sport (252 km / 4 000 de D+)

Voici les valeurs présentées aujourd’hui sur Jura Outdoor : Tour du Jura Loisirs (158 km / 1647 m D+) / Tour du Jura Sport (252 km / 5240 m D+)

Fichier des comparaisons entre outils : 2024.04.12 Comparatif Deniv parcours Géotrek.xlsx