OruxMaps NG

[Tronpo]

I was confused when reading your answer, than I saw a typing mistake in my question  ... I had in mind, why in OM slopes are interpreted in degrees ... as you also wrote, it is much more intuitive in %

Aaa I understand, that depends on your configuration, look in settings > units. To configure the units of measurement to use in each case

[kkolesar]

Aaa I understand, that depends on your configuration, look in settings > units. To configure the units of measurement to use in each case

as usual👌

[Off-Track1234]

I have done some more "detective work" on this "Waypoint Navigation" behaviour in OM NG, based on the observations that I do not see the problem in OM 7.4.28 and Tronpo does not see it in OM NG. What has changed, or what is different? A lot has changed in the app of course, but what can the user control?

1. The phone setup:

I use a Samsung A15 with Android 16. Phone settings > Apps > OM NG > Remove Permissions (off); Battery Unrestricted does not solve it.

2. The App setup:

I notice that when route points are listed in next/previous (or in "Waypoints Route") they are in OM NG alphabetical; whereas in OM 7.4.28 they are in correct sequence for the route. This explains why they may be out of the expected sequence for next/previous, but not why some are skipped and missing from that process.

Under "Manage waypoints" in OM NG there is a folder "@All" that was not present in OM 7.4.28. ("@All" has all waypoints from my other folders as well as whatever OM has created). In OM 7.4.28 folder "---" are only the waypoints created by OM on saving a route from a GPX file; marked with the route by "Track" name. I have organised all my own waypoints under other folders. If the "duplicates" in "---" are deleted, the route cannot be used for OM "Waypoint Navigation". (Sadly, OM "Waypoint Navigates" only GPX <wpt> but not <rtept> designated waypoints, but that is another story.)

While trying to make sense of the NG folder paradigm ("@All" and no "---"), I have sorted "@All" various ways (probably alphabetically then by track) and also made new folders into which I copied (not moved or deleted) the duplicate waypoints that OM created on saving a route from GPX files. All of this is logical (to me at least) but it may have something to do with the odd "Waypoint Navigation" behaviour of OM NG for me.

Manually sorting the OM-created points into correct sequence in their unique folder (I have not played again in "@All") did not solve it.

Any other ideas?

[Off-Track1234]

I have just noticed that OM NG seems to have its own ideas about waypoint sorting. I can change to any order I like within a folder. Then when I change folders and return, it has re-ordered however it likes. I cannot predict what it likes, not by Date or Distance or Name or Altitude. Not sure if this has anything to do with the odd "Waypoint Navigation" or if it is a separate problem.

Still seems buggy to me.

[Off-Track1234]

The option under Waypoint for "Default Waypoint sort" in OM 7.4.28 has gone in OM NG.

For me, OM NG seems happier with setting Waypoint > Waypoint navigation > Waypoint Distance ((automatic)) not 80 m (recommended).
This (automatic) setting did not exist in OM 7.4.28; but under TTS > Waypoint Distance, I had 10 m (that distance also works for me in NG).

There is still a problem with next/previous failing to respect the route sequence, but I can live with that until the bug is fixed.

[Off-Track1234]

Alas, with these altered Waypoint Distance settings, Waypoint Navigation sometimes works (well enough) for a while, but then it reverts to the problem of skipped and missing waypoints under next/previous.

I like the ability to hide (duplicated) route waypoints in OM NG, but until these bugs in Waypoint Navigation are fixed I must for safety use the stable OM 7.4.28.

Let's hope that the developer can fix the NG waypoint navigation bugs soon.

[Tronpo]

@Off-Track1234 Investing time in solving and learning is a great decision.
I will try to clarify some things from my knowledge and experience.
Virtual folders are simply for the organization of the database, @all is the sum of all of them, as long as they are not duplicates.
The organization within the folders can be done by dragging and sliding up or down as you wish.
But when they leave and return they will have the computer set to the order criteria again.

OruxMaps has a tendency to offer many possibilities to get things done
Navigation by wp is not my strong point, I have reduced the explanation to the simplest and most practical way I know, to minimize errors.

1- Selection of all points
2- Load points on the map as an active route
3- Start Waypoint Navigation
4- With navigation in progress, I open the on-board computer, the Waypoint list tab
4- With navigation in progress, I open the on-board computer, the Waypoint list tab.
5- Sorted by sliding the WPs in the list in descending order according to my interest

If you want to create a route using the wp.
1- Sort the WPs in descending order in the folder
2 - Load WPs as a route


I hope this is useful to you

[Off-Track1234]

Thanks Tronpo, it seems strange that OM NG allows sorting then re-sorts (I think the default is reverse alphabetical), but that is fine as long as it does not mess up the correct sequence for "Waypoint Navigation" of an imported route.

The method that you demonstrate to create a route for "Waypoint Navigation" may work but it is not the only method that should work in OM (according to the app documentation), or that does work in OM 7.4.28.

It is too cumbersome to recreate complex routes by sorting waypoints in OM (or probably in any app for a small screen).
OM must (as advertised) work for "Waypoint Navigation" in routes imported from GPX.
Most users of complex routes will prepare them on the larger screen of a PC, and import them into OM as GPX.

This is so buggy as to be unusable in OM NG. The import works, but the "Waypoint Navigation" is wholly unreliable. It worked fine for the same routes in the same device (with all the same relevant settings that I can find) in OM 7.4.28.

I like the ability to hide (duplicated) route waypoints in OM NG (which is stated by the developer to be the way forward), but until these bugs in "Waypoint Navigation" are fixed I must for safety use the stable OM 7.4.28.

Let's hope that the developer can fix the NG waypoint navigation bugs soon.
The problems are fairly thoroughly documented above, and I am happy to help in any way within my ability.

[Tronpo]

Thanks Tronpo, it seems strange that OM NG allows sorting then re-sorts (I think the default is reverse alphabetical), but that is fine as long as it does not mess up the correct sequence for "Waypoint Navigation" of an imported route.

The method that you demonstrate to create a route for "Waypoint Navigation" may work but it is not the only method that should work in OM (according to the app documentation), or that does work in OM 7.4.28.

It is too cumbersome to recreate complex routes by sorting waypoints in OM (or probably in any app for a small screen).
OM must (as advertised) work for "Waypoint Navigation" in routes imported from GPX.
Most users of complex routes will prepare them on the larger screen of a PC, and import them into OM as GPX.

This is so buggy as to be unusable in OM NG. The import works, but the "Waypoint Navigation" is wholly unreliable. It worked fine for the same routes in the same device (with all the same relevant settings that I can find) in OM 7.4.28.

I like the ability to hide (duplicated) route waypoints in OM NG (which is stated by the developer to be the way forward), but until these bugs in "Waypoint Navigation" are fixed I must for safety use the stable OM 7.4.28.

Let's hope that the developer can fix the NG waypoint navigation bugs soon.
The problems are fairly thoroughly documented above, and I am happy to help in any way within my ability.

If you are going to use a route created with Wp as gpx. Import the gpx to the track manager database. From this manager load it to the viewer and use it for navigation, in this way no order should be altered

[Off-Track1234]

I already tried that. It has the bugs described above.

[Off-Track1234]

Some more observations that might assist the developer:

These bugs affect saved routes loaded by Routes > Manage tracks/routes > select one > Follow > Waypoint navigation, as well as imported routes loaded by Routes > Track/route tools > Load KML/GPX file > select one > Waypoint navigation.

The problem with next/previous failing to respect the route sequence is always apparent (in NG).

The problem of skipped / missing waypoints is erratic, so harder to troubleshoot (but even more dangerous to anyone who trusts it). It seems to be triggered when there is a GPS fix and Maps > Map tweaks > Enable/Disable GPS map scrolling is altered, particularly when scrolling is disabled (but not always or immediately). Sometimes it is hard to trigger at all. Maybe some combination of settings/events in NG? Flaky for the user.

[Tronpo]

Some more observations that might assist the developer:

These bugs affect saved routes loaded by Routes > Manage tracks/routes > select one > Follow > Waypoint navigation, as well as imported routes loaded by Routes > Track/route tools > Load KML/GPX file > select one > Waypoint navigation.

The problem with next/previous failing to respect the route sequence is always apparent (in NG).

The problem of skipped / missing waypoints is erratic, so harder to troubleshoot (but even more dangerous to anyone who trusts it). It seems to be triggered when there is a GPS fix and Maps > Map tweaks > Enable/Disable GPS map scrolling is altered, particularly when scrolling is disabled (but not always or immediately). Sometimes it is hard to trigger at all. Maybe some combination of settings/events in NG? Flaky for the user.

Would you mind sending me an example gpx, I can't reproduce your mistake in any way. I don't have a PC, everything was built from OruxMaps, with the planner or creating wp.

[orux]

Some more observations that might assist the developer:
These bugs affect saved routes loaded by Routes > Manage tracks/routes > select one > Follow > Waypoint navigation, as well as imported routes loaded by Routes > Track/route tools > Load KML/GPX file > select one > Waypoint navigation.
The problem with next/previous failing to respect the route sequence is always apparent (in NG).
The problem of skipped / missing waypoints is erratic, so harder to troubleshoot (but even more dangerous to anyone who trusts it). It seems to be triggered when there is a GPS fix and Maps > Map tweaks > Enable/Disable GPS map scrolling is altered, particularly when scrolling is disabled (but not always or immediately). Sometimes it is hard to trigger at all. Maybe some combination of settings/events in NG? Flaky for the user.

Hello!

When you load a GPX file and start waypoint navigation, the app strictly follows the navigation order in which the waypoints appear in the GPX. Make sure that the order in which they appear in the GPX is the order you want to follow (for example, open the GPX with a text editor, or open the trip computer view, waypoint list tab, where you will see the waypoints in the navigation order). It's possible that the order in which they appear doesn't correspond to the order you want to follow them, in which case you should order them using the tools Tronpo mentioned.


If the waypoints are not in the correct order in the GPX file, following the route shown below, you have the option to 'follow the route' instead of navigating by waypoints. This will allow you to navigate by waypoints in the order determined by the route displayed below.

It's possible that the older free version (7.4.28) reordered the waypoints according to the underlying route, but this likely caused the opposite problem: people wanted to navigate using waypoints in the order shown in the GPX file, which seemed more logical, since you don't want to follow the underlying route when navigating by waypoints. Maybe I have to add that option: 'Waypoints navigation reordering the waypoints based on the attached route'.

If this isn't the issue, please attach the problematic GPX file so we can investigate the cause.


orux

[Off-Track1234]

I will attach a simple example GPX file, but remember the problem of skipped / missing waypoints is erratic. You may not see it at first. I have not been able to get deeper to the cause (tried GPS interval, waypoint indicator circles etc) but the developer may have more insight. What has changed in coding relevant to straight-line navigation since 7.4.28?

Thanks for the advice on an alternative (roundabout) way. The old way for next/previous order seems more logical to me. And I have a suggestion for improvement. Here is why:

Those who navigate off the beaten track (off-track hikers, boaters, flyers) use a planned route and an app to help with navigation. The app only needs to give distance and bearing to the next route point. The human brain does the remainder: deciding on an actual course based on topography, weather, tides or whatever is relevant, to get to that next route point. GPX (and probably derivative formats like KML) route files have two major sections: <wpt> (an alphabetical list in case someone wants to recreate those designated points as waypoints) and <rtept> (in the sequence used to create the route). Not every <rtept> needs to be designated as a <wpt>, some are just used to mark the intended route. So when we choose "straight-line navigation" (called "Waypoint navigation" in OM) we want to be given the distance and bearing to every <rtept> in correct sequence for the route (not in alphabetical sequence). We do not want to skip any <rtept> that happens not to be a designated <wpt>. That is why we prepared the route - to follow it, in full. Why would anyone want a method that took them over that cliff, or rocks, or restricted airspace, that they went to the trouble of planning a route around? So for straight-line navigation (whatever you choose to call it) please make it easy to get the distance and bearing to every <rtept> in the sequence they are planned (and listed) in the route. Sure we can remember to create a <wpt> for each <rtept> then re-order the <wpt> list somehow (a lot of work in each GPX file), but why force this on us?

Following a beaten track is different of course. For that we want to 'follow the route' as you say; with all the wonderful options in OM for alarms if we wander off the route etc. Is there any scenario in which a user wants to 'follow the route' for straight-line navigation (not vary from straight lines in such a route)? Maybe there is, but I can't think of one. Maybe others will chip in if this is actually useful to them (remember we are talking about straight-line navigation used off the beaten track, not following a route along a beaten track).

Anyway, thanks for considering. Let me know if I can help somehow.

Edit: I see now that KML can be much more variable, depending where it was made. Garmin KML (for example) uses a folder of named 'via points' for what are in GPX called <rtept>s, with a separate folder for line properties including coordinates which correspond to the 'via point' sequence. Some other makers provide nothing equivalent to a named 'via point'; only folders of ' track' or 'path' coordinates (not named). So it is best to stick with GPX; but Orux is said to prefer KML. In any case, it may be harder to set up OM for straight-line navigation of route points in some versions of imported KML files. But Orux is very good at this stuff. 


Edit 2: I have removed the GPX file because it is not a problem in the file, it is a problem in the way OM (lately) handles imported GPX files. According to the GPX specification, <wpt> is an unordered list, whereas <rte> is an ordered list (in the sequence that defines the route geometry). The problem is that for straight-line navigation of a route in an imported GPX file, OM (lately) expects the <wpt> list to be sorted. For straight-line navigation of the route, OM (lately) uses the <wpt> list order when it should use the <rte> list order. OM 7.4.28 did better, using the <wpt> list in the order of the <rtept>s in the <rte> list. It would be better still just to use the <rte> list, because then any 'shaping points' would be used properly (many GPX makers do not include these under the <wpt list> and OM ignores such points, probably because it does not create them, but this is dangerous for straight-line navigation of an imported route).

There are possibly two underlying problems:

(1) OM offers straight-line navigation of a route only as "waypoint navigation", which is dangerous as described above because it does not correctly follow route geometry.

(2) The concepts of "track" and "route" have become confused (not just in OM). Either can be navigated by software these days. A route should be a sparse set of major turns or locations along a path to be navigated. A track is a much more dense set of points that describe the fine geometry of a path, whether recorded in transit or taken from a map. Navigating (or planning to navigate) a track does not make it a route. Both concepts are useful, but they should be kept different. In navigation of a route, there is still a place for the human brain: to decide on an actual course based on topography, vegetation, weather, tides or whatever is relevant, to get to that next route point.

Happily these things are easily fixed in OM, if the developer is so inclined. Just offer straight-line navigation of a route from <rte> in imported GPX files. And understand that the concepts of <trk> and <rte> are usefully different when creating GPX files (this is best practice in GPX, as it uses the GPX tags the way they were intended).

[Off-Track1234]

PS Orux:

I tried 'follow the route' as you suggested. It gives me no bearing (top dashboard) and no ability for next/previous (button bar or route / navigation options). So it seems not to help for the purpose described above.