Sondage pour votre futur cadeau de noël 2025

Comments

11 comments

  • Avatar
    Bernard Perrot

    Comment voyez vous le futur de TwoNav ? 

    0
    Comment actions Permalink
  • Avatar
    Marek WEGLORZ

    Hi!

    Cross is just fine considering its size for hiking/bicycle use.

    Nevertheless, I would welcome significant software improvement:

    1. re-routing needs improvement, e.g., when you ride in opposite way to the destination it shall go forward and look for the nearest crossings (now, it instantly wants to go back);

    2. Strava live-segments shall be implemented;

    3. "the climb-pro" feature (zoom in of the climbs) seems to be obligatory in the bicycle units A.D. 2025.

    Land? I don't need it that much, as I plan my routes with 2nd party websites.

    Happy New Year 2025!

    Cheers, Mark   

    0
    Comment actions Permalink
  • Avatar
    Thierry CHARLÈS

    Thanks, It take your request.

     when you ride in opposite way to the destination it shall go forward and look for the nearest crossings (now, it instantly wants to go back);

     

    It seems to me that you are certainly using a "*.gpx" file format for your routes with guidance, if you translate to "*.trk" format this confusion does not occur.

    In a file in *.gpx format, including a track and WayPoints (This format does not distinguish the maneuver points), there are two blocks of data the track points and the WayPoints. All the WayPoints are "in the same list", which does not allow to distinguish the Waypoints in chronological order of passage. It will jump to the closest to your position.

    In a file in *.trk format, there are no more WPT but maneuver points (or turn by) which are included with the track points in a single file and in the order of progression.

    This is a limitation due to the *.gpx format.

    Make your guided routes directly with Fast Track in *.trk format or if you use a *.gpx format (or import a *.gpx with guidance => what I sometimes do) you have to convert it to *.trk and make the adjustments by hand.

    No GPX manufacturer offers a guidance solution in gpx format, these files are all in a proprietary format.

    Best regards

     

    0
    Comment actions Permalink
  • Avatar
    Marek WEGLORZ

    Hi!
    No, I always record *.trk.
    I meant routing to destination with official Vmap.
    Cheers,
    Marek

    0
    Comment actions Permalink
  • Avatar
    Thierry CHARLÈS

    Hi,

    I also use the *.trk format, and vmap type maps, with alerts at 20 m.
    But I do not see the errors you mention

    Can you put a link to one of these files that is on your GoCloud, in order to analyze it to understand the cause.

    Bests regards

    Thierry

    0
    Comment actions Permalink
  • Avatar
    Bernard Perrot

    "In a file in *.gpx format, including a track and WayPoints (This format does not distinguish the maneuver points), there are two blocks of data the track points and the WayPoints. All the WayPoints are "in the same list", which does not allow to distinguish the Waypoints in chronological order of passage. It will jump to the closest to your position."

    This is not entirely accurate... In a GPX file, you have to distinguish the waypoints listed at the beginning of the file (<wpt>), independently of the track, from those that can be specified inside the <trkpt> tags. This possibility works very well, and the GPX file editing application that I wrote works like this, and the GPX files containing the direction indications that are exported via this application are perfectly recognized by Land.

    If there is a wish that I would formulate as an evolution at Twonav, it is the abandonment of the .TRK format, and use instead GPX, or if necessary .FIT. The TRK format is too closed (and primitive, without formal syntax...) for it to allow Twonav products, and particularly software, to be useful for other users.

    Cela n'est pas parfaitement exact... Dans un fichier GPX, il faut distinguer les waypoints listés au début du fichier (<wpt>), indépendament de la trace, de ceux qu'il est possible de spécifier à l'intérieur des balises <trkpt>. cette possibilité fonctionne très bien, et l'application d'édition de fichiers GPX que j'ai écrite fonctionne ainsi, et les fichiers GPX comportant les indications de directions qui sont exportés via cette application sont parfaitement reconnus par Land.

    S'il y a un souhait que je formulerais comme évolution chez Twonav, c'est l'abandon du format .TRK, et utiliser à la place GPX, ou si nécessaire .FIT. Le format TRK est trop fermé (et primitif, sans syntaxe formelle...) pour que cela permette aux produits, et particulièrement logiciels, de Twonav d'avoir une utilité pour les autres usagers.

    0
    Comment actions Permalink
  • Avatar
    Thierry CHARLÈS

    hi,

    The error that Mareck mentions I reproduced it in drawing from *.gpx files, including guidance information and designed outside the Land ecosystem. I also encounter it regularly in another universe than that of TwoNav with files in *.fit format, and it is also sometimes reported at Garmin. What I noticed in the case of TwoNav and external import of *.gpx files having guidance data. These files in gpx 1.1 formats have only two blocks of data, (analysis with notepad) the list of track points and a block of WPT (which can be at the beginning or at the end depending on the source of the GPX). Once imported by Land or the GPS, if the route includes round-trip portions or loops, the WPTs that have close coordinates are poorly taken into account (poorly transposed either in the GPX after importing Land or in the Land trk, in fact the order of passage is lost for the close WPTs). The short-term solution in the Land universe is to switch to TRK format, and to correct by hand. The purpose of this answer is simply to help him solve his problem in the short term, for the wishes the question will be postponed. Bernard, you have chosen another implementation, that's good, but Marek would have to use your tool. That said, I have another GPS that uses a *.fit format, in the case cited by Mareck it's the same (round trip or crossing) the guidance gets tangled up. At this stage from what I have been able to use, the *.trk format of Land is the only one that allows round trips on a common branch or crossings without error.

    En français

    L'erreur que mentionne Mareck je l'ai reproduite à dessin a partir de fichier *.gpx, comprtant des informations de guidage et conçuts a l'extérieur de l'éco système Land. Je le rencontre aussi régulièrement dans un autre univers que celui de TwoNav avec des fichiers au format *.fit, et c'est aussi parfois reporté chez Garmin. Ce que j'ai constaté dans le cas de TwoNav et d'import externe de fichiers *.gpx ayant des données de guidage. Ces fichiers au formats gpx 1.1 n'ont que deux blocs de données, (analyse avec notepad)  la liste des points de trace et un bloc de WPT (Qui peut être au debut ou a la fin selon la source du GPX) . Une fois importés par Land ou le GPS, si l'itinéraire comporte des portions A/R ou des boucles,  les WPT qui ont des coordonnées proches sont mal pris en compte (mal transposés soit dans le GPX apres l'import de Land soit dans le trk de Land, cocretement l'ordre de passage est perdu pour les WPT proches). La solution a court tereme dans l'univers de Land est de passer au format TRK, et de corriger a la main. Le but de cette réponse est simplement de l'aider a solutionner son problème a court terme, pour les voeux la question sera reportée. Bernard tu as choisis une autre impémentation c'est bien, mais il faudrait que Marek utilise ton outil. Cela dit j'ai un autre GPS qui utilise  un format *.fit, dans le cas cité par Mareck c'est pareil (aller / retour ou croisement) le guidage se prends les pieds dans le tapis. A ce stade de ce que j'ai put utiliser le format *.trk de Land est le seul qui permet les aller retour sur une branche commune ou les croisements sans erreur.  

    Cordialement

    Thierry

    0
    Comment actions Permalink
  • Avatar
    Thierry CHARLÈS

    Hi,

    Example on the left a "gpx" with guidance (external creation to TwoNav),

    the WPTs are all listed at the beginning, followed by the trkpt

    On the right the same gpx but opened and saved via Land, we see that the guidance information is extracted from the WPTs (by proximity criterion) and integrated into the nearest trkpt (Hence the confusion on the A:R or crossing portions)

    Exemple a gauche un "gpx" avec guidage (création externe a TwoNav),

    les WPT sont tous listés au début, suivent les trkpt

    A droite le même gpx mais ouvert et sauvé via Land, ont voit que les informations de guidage sont extraites des WPT (par critère de proximité) et intégrée au trkpt le plus proche (D'ou la confusion sur les portions en A:R ou croisements)

    If we use the *.trk format the distinction is clearer in the file. But if originally it was a GPX (as on the left above) the source of confusion will be preserved, it must be corrected by hand by moving the point on the screen

    Si on utilise le format *.trk la distinction est plus nette dans le fichier. Mais si a l'origine c'était un GPX (comme a gauche ci dessus) la source de confusion sera conservée il faut corriger a la main en déplaçant le point sur l'écran

    Pour l'avenir, le futur la question mérite d'être posée.

    Au vu des retour sur d'autres forum dédiés a d'autre matériel je n'ai pas encore constaté de solution miracle. La seule efficace que j'ai constatée c'est de tracer directement au format *.trk avec Land

    For the future, the question deserves to be asked.

    In view of the feedback on other forums dedicated to other equipment, I have not yet seen a miracle solution.

    The only effective one I have seen is to trace directly in *.trk format with Land

    Cordialement

     

    0
    Comment actions Permalink
  • Avatar
    Marek WEGLORZ

    Hi!

    in my opinion, the routing has nothing in common with the tracking.

    Edit: I see that we misunderstood each other since you both are takin' about so called "breadcrumb navigation" (with use of either *.gpx, *trk, *.fit pre-planned tracks), and I mean a v-map routing (such as we use in the Google Maps).

    What makes me mad is such behaviour described in my post above.

    The map: EasternEuropeN23Q1.vmap

    Look at this picture: I'd like to follow the left hand side road ahead, though my Cross Plus v. 5.9.4 makes me to come back (which is weird):

    Cheers,

    Marek

    P.S. Garmin, TwoNav Anima and Sportiva navigate appropriate and follow the road ahead.

    0
    Comment actions Permalink
  • Avatar
    Thierry CHARLÈS

    Hello

    If I understand correctly, you are expressing the need for a route calculation integrated into the GPS that is more advanced than the simple primitive routing currently integrated into the GPS (which I never use).

    Best Regards

    Thierry

    0
    Comment actions Permalink
  • Avatar
    Marek WEGLORZ

    Hi Thierry,
    You're right, I considered the "autorouting" which is implemented in the official TwoNav *.Vmap.
    I use it quite often.
    Unfortunately it cannot properly recalculate the "on-road" mode when you go in the opposite direction to the destination (what I've shown in the picture).

    Edit: for more information how IT works, see this link: https://support.twonav.com/hc/en-us/articles/115001078991-Automatic-route-calculation-in-Twonav
    Cheers,
    Marek

    0
    Comment actions Permalink

Please sign in to leave a comment.