Error calculo distancia, altitud y distancia entre puntos editando o creando track version 10
La nueva versión 10 no funciona los calculos creando o editando track, ya que no es capad de calcular la distancia, altitud y distancia entre puntos sino estas continuamente usando la Herramienta "Calcular altitud del suelo para cada punto", lo que hace que sea tedioso editar o dibujar un track.
Todo esto no ocurría con la versión 9.8 cuando podías trabaja con archivos ecw y asc para altitudes de forma offline, y tampoco es compatible con archivos formato COG.
¿Hay alguna solución para ello?
Gracias.
-
La nueva versión 10 no funciona con la creación de trazas ni con la edición de cálculos, ya que no es capaz de calcular distancia, altitud y distancia entre puntos si no se utiliza continuamente la herramienta "Calcular la altitud del terreno para cada punto", lo que la hace tediosa. .
No he notado este problema, sería bueno especificar cómo lo usas, para intentar reproducir lo que observas.
- La herramienta Fast Track que se vuelve utilizable en Land 10, abre automáticamente un DEM, ¿cómo logras tener que abrirlo nuevamente?
Un ejemplo del mismo track creado con Land 10 (Fast Track) y QmapShack (BRouter):
Para la distancia la diferencia es insignificante;
Para las altitudes: El DEM es el mismo (IGN FRANCIA), la diferencia es insignificante con hipótesis idénticas para tener en cuenta la diferencia de altitud (5 m); 93 mo 95 m. En cambio, si cambio el umbral tenido en cuenta para Land a 3 m, la diferencia de altura aumenta un 13%, lo cual es normal.
No, no hay ningún error a este nivel, ciertamente un problema de empleo de tu lado.
Seguimiento de estos 4 km con Fast Track me llevó dos minutos....
The new version 10 does not work with the calculations of creating or editing tracks, because it is not able to calculate the distance, altitude and distance between points if you do not continuously use the "Calculate ground altitude for each point" tool, which makes it tedious.
I have not noticed this problem, it would be good to specify how you use it, in order to try to reproduce what you see.
- The Fast Track tool that becomes usable in Land 10, automatically opens a DEM, how do you do to have to re-open it?
An example the same track created with Land 10 (Fast Track) and QmapShack (BRouter):
For the distance the difference is insignificant;
For the altitudes: The DEM is the same (IGN FRANCE), the difference is insignificant with identical assumptions of taking into account the elevation difference (5m); 93 m or 95 m. On the other hand, if I change the threshold for Land to 3 m, the difference in elevation increases by 13%, which is normal.
No, there is no bug at this level, a problem of use on your side certainly.
La nouvelle version 10 ne fonctionne pas avec les calculs de création ou d'édition de traces, car elle n'est pas capable de calculer la distance, l'altitude et la distance entre les points si vous n'utilisez pas continuellement l'outil "Calculer l'altitude au sol pour chaque point", ce qui le rend fastidieux.
Je n'ai pas constaté ce problème, ça serait bien de préciser comment vous l'utilisez, afin de tenter de reproduire ce que vous constatez.
- L'outil Fast Track qui devient utilisable dans Land 10, ouvre automatiquement un DEM, comment faites vous pour avoir a le re ouvrir?
Un exemple la même trace cree avec Land 10 (Fast Track) et QmapShack (BRouter):
Pour la distance l'écart est insignifiant;
Pour les altitues : Le DEM est le même (IGN FRANCE), la différence est insignifiante avec des hypothéses de prise en compte du denivelé identiques (5m); 93 m ou 95 m. Par contre si je change le seuil de prise en compte pour Land a 3 m, l'écart de denivelé grimpe de 13% ce qui est normal.
Non il n'y a pas de bug a ce niveau, une problème d'emploi de votre coté certainement.
CDLT
-
Hello
In Land 10.1, creating a new track automatically opens the "local" relief map (CDEM). If the user uses FastTrack this action automatically opens an OSM map. The only "bug" that exists in this version is that if a relief map is already open and deselected (crossed out eye) the altitudes are not integrated into the track, that said it is enough to make the map visible. It is strange the description of the defect does not correspond to the Land 10.1 version for Windows
Cdlt
-
Bonjour
J'ai moi aussi constaté des problèmes de calculs d'altitude dans la verfsion Land 10.1Tellement importants, fréquents mais aléatoires que j'ai émis il y a une douzaine de jours un ticket au support : "Depuis quelques temps, les calculs d'altitude sont tout à fait aléatoires, quelque soit la carte DEM utilisée.
J'ai fait cet apres midi plusieurs essais, en changeant de cartes, et / ou en redémarrant Land. Cf le fichier joint.
Le dernier = plus aucune carte de relief n'est reconnue"Le document que j'ai joint à ma demande était le suivant :
https://drive.google.com/file/d/10hpjekFWVIy0A8vtwNwX75cIdwaBE0F3/view?usp=sharing
La réponse de twonav a été de me faire tester la version 10.3.1 de Land, version non encore publiée. La plupart des erreurs y sont corrigées, sauf une importante et systématique : il faut calculer 2 fois les altitudes, le 1er calcul est faux, le 2nd est juste.
La réponse finale de twonav à ce jour: "Oui, c'est étrange qu'il y ait une différence entre la première fois et la deuxième. Nous allons partager avec le département de développement pour analyser."A suivre, donc
Cordialement
-
Bonjour
J'ai moi aussi constaté des problèmes de calculs d'altitude dans la verfsion Land 10.1Tellement importants, fréquents mais aléatoires que j'ai émis il y a une douzaine de jours un ticket au support : "Depuis quelques temps, les calculs d'altitude sont tout à fait aléatoires, quelque soit la carte DEM utilisée.
J'ai fait cet apres midi plusieurs essais, en changeant de cartes, et / ou en redémarrant Land. Cf le fichier joint.
Le dernier = plus aucune carte de relief n'est reconnue"Le document que j'ai joint à ma demande était le suivant :
https://drive.google.com/file/d/10hpjekFWVIy0A8vtwNwX75cIdwaBE0F3/view?usp=sharing
La réponse de twonav a été de me faire tester la version 10.3.1 de Land, version non encore publiée. La plupart des erreurs y sont corrigées, sauf une importante et systématique : il faut calculer 2 fois les altitudes, le 1er calcul est faux, le 2nd est juste.
La réponse finale de twonav à ce jour: "Oui, c'est étrange qu'il y ait une différence entre la première fois et la deuxième. Nous allons partager avec le département de développement pour analyser."A suivre, donc
Cordialement
-
Bonjour,
Dans Land 10.1 il y a un problème de sélection du DEM, il faut que l'œil devant la carte du relief soit cochée.
Dans les diagrammes que tu publie:
- Comme ce ne sont pas les mêmes DEM/SRTM il n'est pas anormal qu'il y ai des différences,
- Un DEM IGN ce sont des mailles de 5x5 m pour le relief IGN, or sur certains sites la taille de mailles ca peut aller a des tailles de mailles de 100m, de plus ces DEM (SRTM NASA ou ASRZE, ou..) comportent des erreurs, sur le site de distribution figure cette mise en garde.
- Ensuite il y a les hypothèses de prise en compte des ascensions que l'on peut ajusté dans Land
Donc, sur les diagrammes que tu publie je ne vois rien d'anormal
Si je prends par exemple une trace identique, avec un DEM identique (ci -dessous) il ne reste que l'hypothèse de prise en compte du relief, qui est différente entre les deux diagrammes:
Land : Distance12,67 km, dénivelé 154 m. seuil de prise en compte 3 m
QmapShack : Distance14,67 km, dénivelé 140 m. seuil de prise en compte 5 m
Il y a un écart de 2 km sur la distance
CDLT
-
En France on a la chance d'avoir une bonne base de données des reliefs, c'est celle de l'IGN, d'ici quelques mois elle sera encore plus précise suite au relevés LIDAR.
Pour les utilisateurs de LAND/TwoNav nous avons une seconde chance, Bernard Perrot a créer et mis en ligne les DEM (SRTM) complié a partir de la base de donnée IGN.
Ces altitudes sont une bonne référence, ce qui est vu ou constaté ailleurs (Kommot, autres sites, ) est approximatif, les données d'altitudes proviennent de SRTM beaucoup moins précis que ceux issus de l'IGN.
Quand on "parles" altitudes ou dénivelé, la source de données est primordiale.
Cdlt
-
Bonjour Thierry,
La trace initiale, validée sur komoot = 850 m
Tu dis "il n'est pas anormal qu'il y ait des différences quand le DEM change".
Evidemment, à quelques mètres, voire dizaines de mètres. Ainsi, entre 800 et 900 m je ne m'étonnerais pas.Mais je m'étonne que tu ne vois rien d'anormal quand cette même trace passe d'un profil lissé à un profil "écervelé" puis en esacleir et à
- 2326 m (Western Europe Relief.cdem, d'accord ce n'est pas une carte très précise, mais quand même)
- 1444 m, la même trace, la même carte, 2 mn plus tard
- 2448 m (RGEALti Rando.tybern), là c'est du précis
- 2175 m, la même trace, la même carte, 2 mn plus tard
- 2488 m, la même trace, la même carte, 2 mn plus tard
- 2672 m, la même trace, la même carte, 2 mn plus tard
Soit un facteur de 1 à 3 !Tu dis aussi que l'oeil de la carte DEM doit être coché. Evidemment (quoique...).
Regarde la dernière copie d'écran : elle indique une erreur "aucun fichier CDEM chargé" alors que la carte est bien cochée dans l'arborescence.
Le support m'a confirmé il y a 10 jours, je cite, "La version actuelle a un problème de calcul des altitudes", et il m'a demandé de tester la future version 10.3.
Voila le résultat des tests que j'ai faits (avec une autre trace) et que je leur ai envoyés
Trace utilisée 1-Lacaune.trk (en PJ)
Dénivelé calculé par komoot (apres passage en gpx) : 1130 m
Dénivelé calculé par openrunner (apres passage en gpx) : 1112 mDénivelé calculé avec la Carte Western Europe Relief.cdem
1er essai : 1939 m
2ème essai : 1615 mDénivelé calculé avec la Carte RGEAlti-Auvergne.cdem (rando.tybern)
1er essai : 1758 m
2ème essai : 1099 mDénivelé calculé avec la Carte Auvergne-RGEAlti5m-L93-v1.cdem (compegps)
1er essai : 1398 m
2ème essai : 1099 mDénivelé calculé avec la carte World Base relief :
1er essai : 1615 m (identique à la carte Western Europe)
2ème essai : idem 1615 mMes réflexions :
- plus d'erreur "aucun relief cdem chargé", erreur qui se produit aléatoirement avec land 10.1
- aucun profil en escalier sur tous les essais effectués
- la surestimation de World et Europe relief (1615 m) ne me surprend guère car ces cartes ne sont guère précises
- reste apparemment à régler la question des "essais" : à chaque changement de carte, le 1er calcul est faux, le second semble correct. Sauf pour World relief où le résultat est invariant même après fermeture / ouverture de Land 10.3Je vous ai envoyé un rapport d'état avec ce n° de ticket
La bonne dénivelée tourne autour de 1099 m (2èmes esssais de RGEAlti) avec openrunner à 1112 m et komoot 1130 m (fourchette de 3 %, il n'y aurait rien à dire).
Le support a partagé mes tests avec le service développement, le cas est en cours d'analyse. Je suppose qu'il sera réglé à la publication de la version 10.3
Et pour finir, quelques tests faits à l'instant https://drive.google.com/file/d/113DcH8I9AMUuiQ_dPczAjHQJD4DmsBiX/view?usp=sharing
Notre correspondant espagnol raison de dire qu'il y a des problèmes de distance et d'altitudeCordialement.
-
Thierry,
Suite à ton dernier message, c'est bien les données de Bernard Perrot que j'utilise par défaut.
Les RGEAlti de TwoNav sont identiques (même source je pense)
Ce problème d'altitude (et de distance) n'existait pas sur les versions précédentes, au contraire, on avait des altitudes qui correspondaient pratiquement à 1 m près aux altitudes des points cotés sur les cartes IGN 1/25000.Denis
-
Même trace, mêmes DEM (Données IGN) Compilées par Bernard pour Land, et par "BiBi" pour Qmap
Ce que calcule Qmap (seuil a priori 5 m)
Ce que calcule Land 10.3.1 (seuil 3 m)
Ce que calcule Land 10.1 (seuil ajusté a 3m)
Land 10.1, ils ont intégré la correction du cas ou plusieurs DEM sont ouvert et que la trace passe sur les bords. Le bug c'est cette histoire de sélection ou pas du DEM (il est dans la liste mais grisé), donc a chaque foi qu'on ouvre il faut vérifier ça. A priori si la carte est bien sélectionnée (ligne non grisée) ca marche.
C'est corrigé dans Land 10.3.1, il y a d'autres bugs mais plus celui la.
Je ne compare jamais avec Kommot, ou un site en ligne, ni avec Strava (voir comment ils ont créer leur base de donnée en ligne bien expliqué sur leur site en ligne)
Si tu vois le profil vertical (10.1) en escalier clic sur recharger les altitudes au cas ou, mais je n'ai jamais vu ce défaut, ni jamais vu non plus la ligne relief active sans relief chargé.
Cdlt
-
Thierry
Komoot ou openrunner : quand la trace a un dénivelé fourni par Land qui varie dans un rapport de 1 à 3, c'est une façon de savoir quelle est approximativement la bonne dénivelé. Sans tirer d'autre conclusion vu qu'il peut y avoir des variations minimes de l'un à l'autre, je ne suis pas à 10 m près !
Le profil en escalier : le rechargement des altitudes ne change rien.
Concernant la ligne relief, je constate à l'instant :
- si ouverture de Land avec la ligne relief chargée mais non active : erreur "pas de relief chargé"
- si, alors, activation de la ligne relief : calcul des altitudes (faux !)
- si, alors, désactivation de la ligne relief, pas d'erreur de relief non chargé, mais calcul (faux) des altitudes.
D'où une conclusion (provisoire ?) : pour que le calcul des altitudes se fasse, il faut que la carte DEM ait été activée au moins une fois dans la session (sic !).
On aimerait juste que le calcul soit juste.Pire, si ouverture de Land avec la ligne relief activée, puis désactivée, alors calcul des altitudes (toujours faux) malgré, en même temps, erreur pas de relief chargé ; d'accord il faut être tordu pour désactiver la ligne relief avant de calculer les altitudes, c'est juste pour démontrer que ça ne tourne pas rond !
Cordialement
-
Bonjour,
On aimerait juste que le calcul soit juste.
Si j'ai bien lu ce que tu as écrit, ils t'ont donné la version suivante, donc tu peux constater par toi même si la correction est bonne ou pas.
Il n'y a pas en soi un défaut de calcul de dénivelé ou des altitudes, mais un défaut de sélection ou de chargement, l'indication de l'état chargé n'est pas fiable.
Si dans cette version, on prend soin de bien sélectionner le relief, il se charge et il n'y a pas de défaut de calcul.
Ensuite, vu qu'il y a une nouvelle version dans le tuyau, c'est préférable de concentrer l'énergie sur cette nouvelle version pour ceux qui l'on a disposition vu que c'est ce qu'on devrait avoir prochainement.
De ce que j'ai pu voir et constater de la version 10.1, c'est que si le relief est bien sélectionné c'est bon.
Les variations entre un calcul sur le DEM IGN et les sites en ligne ca peut être important, tout dépend de l'endroit géographique.
Regarde bien si avec la version suivante ca n'existe plus !
Cdlt
-
Thierry
Excuse le syndrome de gros doigts sur le clavier, le message est parti à l'insu de mon plein gré !
Thierry
Avec 10.3.1, il reste une erreur facheuse : il faut calculer 2 fois les altitudes : le 1er calcul, carte relief chargée mais activée ou non, donne un résultat faux ; les calculs suivants sont invariants
-
Suite,
Je n'ai pas constaté cette erreur, mais reporte là vers TwoNav plus on est nombreux a tester moins il devrait rester de défauts.
Donc suite a ton constat je lance un test basé sur un futur projet pour 2025 la "Stoneman".
L'étape 1 ayant été préparée avec QmapShack sur le DEM LIDAR de la Wallonie 1 m x 1 m :
- 17.8 Km / Asc 480 m
Donc je la retrace avec Land 10.3.1, Land n'est pas configuré pour ça ce n'est pas le BON DEM.
- Ouverture du DEM qui couvre les Ardennes et la Belgique => Source "Sony" taille des mailles 25m x 25 m. (C'est un DEM issu de SRTM internationaux et réputé corrigé des erreurs par la source)
17,93km, dénivelé : 608 m (+ 128m ; +25%)
Pour localiser la cause de l'écart, import dans Land de la trace crée par Qms (Avec les données d'altitudes)
- Aucune différence sur le calcul du dénivelé fait par Land au départ,
- Suite à l'ouverture du DEM SONY, 608 m
- Suites a plusieurs recalcul, le dénivelé reste à 608 m
- La trace conçue par Qms (BRouter) avec le DEM Wallonnie LIDAR.
- Les calculs de dénivelés faits par QMS 480 m et Land 497 m sont similaires,
- L'écart (17 m, 3.5 %) est du à l'effet du seuil de prise en compte du relief plus faible dans le cas de Land (3m) .
- Comme la trace est importée avec ses altitudes (GPX) c'est le logiciel donc Land (dans le cas de Land) qui fait le calcul du dénivelé.
- Par conséquent le calcul fait par Land est correct , car les deux logiciels indiquent un dénivelé cohérent, et la petite différence s'explique.
Entre la trace construite par Land qui importe le relief du DEM Sony ( 25 x 25 m) et la trace importée (DEM LIDAR 1 m x 1 m) l'écart en dénivelé est de l'ordre de 25 % , cet écart est imputable à la différence entre les deux DEM.
Ensuite il y a un écart sur la distance, Land 10.3.1 a un petit problème (bug) pour assimiler la datation importée. C'est a priori dû (a vérifier quand la correction sera appliquée) a ce défaut de prise en compte des dates, dans un fichier importé avec des WPT, ce qui est le cas.
Je ne constate pas le défaut que tu relate, mais reporte le vers TwoNav.
Cdlt
-
Thierry,
Le DEM Sonny, j'ai pratiqué avant les RGEAlti.
"L'écart de 25 % est imputable à la différence entree les 2 DEM". Certes ! Mais aussi entre la différence de distance des 2 traces (15 %) ?J'ai déjà alerté le support de ces problèmes avec des exemples, des cpies d'écran etc... Il est à l'étude ar le service du développement.
Merci de tes lumières fort compétentes.
Denis
-
Suite..
Certes ! Mais aussi entre la différence de distance des 2 traces (15 %) ?
Alors, c'est un truc qui m'interpelle depuis un moment, en théorie une trace est un nombre de points "i" et on fait la somme des distances élémentaires calculées entre ces points i.
Exemple ici même trace réalisée soit avec Land (Fast Track) ou QMS (B router), les données c'est OSM importées aujourd'hui, le nombre de point (comme l'exemple d'avant) est quasi identique/
Par rapport au cas ci dessus il n'y a pas d'écart sur la distance.
Toujours l'écart de dénivelé pour les mêmes raisons
La différence en distance semble apparaitre si on manipule le temps sur la trace importée.
Cdlt
Please sign in to leave a comment.
Comments
19 comments