Au Pays des "bugs"
Bonjour,
La version TwoNav 6.2 promet une accélération de la synchronisation Go Cloud, dans leur rédaction TwoNav indique qu'il n'est plus nécessaire d'attendre 10 minutes..
Avant : Selon le modèle de GPS on pouvait devoir attendre 10 minutes après la mise sur ON ou entre deux mises à jour (J'ai un GPS pour lequel c'était dans la foulée du Boot et l'autre parfois 8 minutes plus tard). Mais quand le 'train de la synchronisation" était passé c'était bon la liste des routes avait été actualisée.
Maintenant : Effectivement la synchronisation se fait dans la foulée du boot... Mais ce qui a été mis à jour n'apparait pas dans la liste des routes. (La mise à jour a bien été faite mais elle ne se voit pas, c'est ballot !) . Ensuite il faut attendre le "train de synchronisation suivant" pour que la liste soit actualisée. Donc a priori une minute vu que TwoNav écrit toutes les minutes. Et bien NON, c'est une peu plus "pervers".. a priori le GPS s'il n'a rien a mettre dans le Wagon de la synchronisation ne fait aucune actualisation, et si Land n'a rien a envoyé au GPS il ne se passe rien. Donc vous pouvez attendre longtemps ou vius devez provoquer une synchronisation (OFF/ON). En faisant ce test j'ai attendu 10 minutes.
En conclusion c'est pire qu'avant .. Bravo TwoNav et ils osent livrer ces versions bancales!!
Un autre BUG plus insidieux ...
Si l'utilisateur utilise une carte "Officielle" distribuée par TwoNav (IGN,OSM, etc.) et si cet utilisateur fixe par exemple une échelle à 2 m / pixel sur un TERRA ou TRAIL la distance de carte visualisée en aval (sens du déplacement) est de 2 m x 400 pixels (il y a 400 pixel entre votre position et le bas du bandeau supérieur TRAIL, TERRA, ANIMA) donc ca fait 800 m. (Cross a priori c'est 500 pixel et ROC deux fois moins en gros).
Si l'utilisateur utilise une carte ou tuile de carte produite par MOBAC ou QGIS (Carte gratuite tout à fait légale et conforme aux spécifications TwoNav) dans les mêmes conditions il n'y a plus que 520 m de carte devant la position.
Ou est l'erreur ?
Le rapport entre ces deux distance 520 m/ 800m = 0.65
En fait 0.65 correspond au cosinus de la latitude de la carte dans le cas de cet essais.
Mobac ou Qgis appliquent les spécifications qui régissent la définition des cartes.
Les taille des tuiles sont définies pour un niveau de zoom à l'équateur (wiki-openstreetmap-Zoom_levels 0 a 20).
Mais plus on se rapproches des pôles plus la taille d'une maille ou tuile se réduit, en fonction de la latitude.
TwoNav GPS ne tient pas compte de la latitude de la carte pour calculer l'échelle, pour les cartes non distribuées par TwoNav.
La solution est assez simple et fonctionne:
Vous définissez la distance que vous voulez voir sur votre écran, un exemple simple 400 m pour un TERRA (TRAIL, AVENTURA)
Donc en théorie 400 m / 400 pixel = 1 m/pixel a ajuster en configuration échelle de carte fixe
En pratique 1 m x (inverse cosinus de la latitude du centre carte) , soit ente 1.35 (tout au sud) et 1.7 tout au nord.
Donc pour notre exemple de 400 m mettre 1.35 (Vers menton) et 1.7 (Vers la panne) au lieu de 1 m.
CDLT
-
Interesting how much programming capacity was spent into the ability to do some synchronization without cable. If those ressources were spent on something essential like making mpvf creation workable again or .... let me be hopeful ... adding an adress search into the mpvf creation process ..., but no, that would be a really practical thing to have in the software instead of using a cable less often.
Let's keep window dressing and keep selling the user vector maps, that are older than 4 years and keep the fingers crossed nobody will realize it!
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
1 Kommentar