Navigation on all tracks

[balloni55]

Hi willy,
sorry for late response. After i downloaded the "de.tts" and stored it in  Locus/data/tts, i hear outdoor under real conditions the voice with direction instruction Thanks for your help.
For me the instructions when i am away from the right track are not always clear and understandable.
For example, i reache a crossroad where i have to go left to follow the track. I go right (the car keep standing at the crossroad?) after 100 Meters i hear  "100 M von 6 Stunden" and see the navigation arrow on my possition.
The information "X Stunden" relats to my last moving direction and this is for me not allways clear where i have to go.
My hobby is aviation , an there direction infos always discribed in degrees. east=90°, south=180°, west=270°, North= 0°/360°
A clear and understandable instruction for my example above wil be "100 Meter nach 90 Grad"
Please do not missunderstand me, you, tommi and menion did a great work, perhaps i can do a little assist for a better solution.

Another thing i have noticed, (i nowhere read about that), if my selectet track is near an "official car-road", and my position is clother to these car-road  as to my selected track, locus himselfe creates an alternative track named "tesselate" and these created track doesnt end at my trackend. Where can i disable these funktion?

Nice weekend wolfgang

[tommi]

Hi willy,
sorry for late response. After i downloaded the "de.tts" and stored it in  Locus/data/tts, i hear outdoor under real conditions the voice with direction instruction Thanks for your help.

So it was just a problem with the missing tts file? Thougt in absence the current official solution with fixed translation would kick in

For me the instructions when i am away from the right track are not always clear and understandable.
For example, i reache a crossroad where i have to go left to follow the track. I go right (the car keep standing at the crossroad?) after 100 Meters i hear  "100 M von 6 Stunden" and see the navigation arrow on my possition.
The information "X Stunden" relats to my last moving direction and this is for me not allways clear where i have to go.
My hobby is aviation , an there direction infos always discribed in degrees. east=90°, south=180°, west=270°, North= 0°/360°
A clear and understandable instruction for my example above wil be "100 Meter nach 90 Grad"
Please do not missunderstand me, you, tommi and menion did a great work, perhaps i can do a little assist for a better solution.

Wolfgang, I fully understand that people with e.g. aviation background prefer this solution. But if you have no sunlight or even night it's hard to judge the cardinal direction if you don't want to avoid picking the phone out of the bag (which is one of the most important point for this audio navigation!). Willy and I discussed exactly this as well and we came to the conclusion that the already existing solution (this off-track guiding is part of our proposal to Menion but it's nothing new) is ok. What is bad is the translation which is already an old discussion, see *your* response here: http://forum.locusmap.eu/index.php?topic=301.msg22033#msg22033.
Menion told me that he wants to make the waypoint generation good and later concentrate on TTS improvements.

Another thing i have noticed, (i nowhere read about that), if my selectet track is near an "official car-road", and my position is clother to these car-road  as to my selected track, locus himselfe creates an alternative track named "tesselate" and these created track doesnt end at my trackend. Where can i disable these funktion?

What is this? I never heard about that. We also should be aware Locus' only information for the waypoint generation is the original track.
Could you provide us such an example? (if for privacy reasons via PM/dropbox)

@Willy: Sorry, I could not hold on me any longer, already waited some hours before I responded 

[balloni55]

So it was just a problem with the missing tts file?

there was only an english .tts  file ,  my language is german.

if you don't want to avoid picking the phone out of the bag

ok, i understand.
Perhaps it is possible to create two different  selectable announcements?

Could you provide us such an example?

in these picture you see the example, my track on farmingroutes is parallel the Street and in this example the end of both tracks are the same position, because it is an official steet.
Both tracks i send you and willy per PM

[tommi]

Another thing i have noticed, (i nowhere read about that), if my selectet track is near an "official car-road", and my position is clother to these car-road  as to my selected track, locus himselfe creates an alternative track named "tesselate" and these created track doesnt end at my trackend. Where can i disable these funktion?

@Menion (or if anybody else should know):
Can you explain by which function of Locus such a gpx header will be created:

Code: [Select]

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<gpx version="1.0" creator="Locus Android"
 xmlns="http://www.topografix.com/GPX/1/0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:locus="http://www.locusmap.eu"
 xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd">
<trk>
<name><![CDATA[Tessellated]]></name>
<desc><![CDATA[If the <tessellate> tag has a value of 1, the line will contour to the underlying terrain

If the <tessellate> tag has a value of 1, the line will contour to the underlying terrain


[Joachim Buhl]

Hallo All

I did a test with the new guiding navigation feature this afternoon and it was not very good. To be precise it was so bad, that I changed back to "normal" guiding because otherwise I maybe did not find the way out of the forest again.
I did the test in an unknown area for me on very small paths with a mountainbike. The track had several crossings within itself. See here:

I planned the track on the computer with not many points, what means, that the track is often besides the real way. See here for example:

Why I did that? I recognized earlier this week that the new navigation test routine simplifies tracks before it gives them the voice notifications. See what I mean:
Original track with a lot of points (recorded track):

Track now with notifications text:high:

too much notifications, not feasable.

Track with text:medium:

here now ok, but:

no notifications on real crossings.

Back to my test today......So I decided not to do to much points, because otherwise I have to trust the simplification algorithm which I don't want, see pictures above.
This leads to the following problems:
1. When I start the navigation, it starts in "car" mode. This mode does not only mean, that I get the notifications which were "calculated", it also means that my "GPS position" sticks to the track. As long as I am not too far away from the track, I do not see my real position. That means if the track is besides the way I'm also besides the way. And if there is a crossing and I could not see were I am in real, I do not know where to go.
2. The map orientation with the compass is also locked somehow in "car" mode. In normal guiding mode I can move my handle bar around to see where exacly the track is going to. In "car" mode the map is not moving.
3. The 50m notification is far to late. You often hear the 50m notification, when you have to go right immediately.
4. If your off the track (I set 50m with three beeps), the following happens:

I'm coming from the right and followed wrong the red arrows. I get three beeps from the first red arrow on, but because of the sticking to the track, I did not see on the map, why I'm wrong. At the red point I can see on the map, that I took the wrong way and there is a line which should lead me to the blue point. Meanwhile I got a lot of beeps. So I go back in opposite to the red arrows (beep, beep, beep) and I'm on the track again (beep, beep, beep). I'm on the right track now, but I get beeps. And I get beeps until I reached the blue point.
5. The automatic display activation is activated from an upcoming notification. If after that notification, the next notification follows right away (within the display timeout) the timeout is not resetted. So the display goes off although there is the next upcoming notification.
6. The display goes off, although I'm beside the track (beep, beep, beep) and I'm trying to get back on track.

To sum it up:
I have to turn at 50m notifications (to late), on crossings where I cannot see where I am (sticked to the track), where I cannot see where to go (no compass movement of map) and when I'm on track,  I hear beeps (sticking) and after recognizing that I'm wrong I cannot see where to go (display is off) and after finding the right way again, I hear beeps further on and I miss the next turn because the display is off (timeout).

Proposal:
1. No sticking. Position behavior like in the old guiding mode.
2. Compass moving map, like in the old guiding mode.
3. 50m notification earlier
4. When your off the track, always pointing back to the nearest point and not the next notification point
5. Reset of display timeout with each single notification
6. Blocking of display off, when away from the track

Thanks

Good night

[tommi]

Joachim, thank you for opening our eyes  .
I cannot remember of a hard core user of guiding/navigation like you but I'm happy that it's not only me who wants improvements in this area (I request that now for two years).

Well, this is now the very first implementation of the algorithm Willy and I proposed. We already discussed with Menion stuff to be improved (in the now available implementation compared to the proposal at that time and also new improvements in the proposal).
We know (independent of your test):
- Detection of turns to be improved.  Already proposed improvements to Menion.
- TTS output (too much oriented on speed of cars, generally to be improved, Menion plans to do but I do not expect this to happen in the next days)

But:
We decided to propose (and independent of us Menion had the same idea) a system with "magnetic" behaviour, means it is expected that the user stays on track and just GPS reception might be not optimal but user does not go off (otherwise after some distance and time he will get offtrack notifications). This forbids to create tracks which are on purpose too far off the actual path (which you did because you were not happy with track simplification (which is btw. not part of our proposal).
In addition you used a recorded track which seems to be so inaccurate that the algorithm detects slight turns where the actual road is straight. Hmh, there this system somehow reaches its limits as it has only knowledge of the underlying track, it has absolutely no knowledge how accurate it is.

Regarding the display off behaviour I agree with you.

Regarding the pointing back to the track when you're off I agree it might be better if it pointed you back to the nearest point.

Seems you don't use TTS off track guiding but just the beep. TTS would give you more information.

Questions to you:
What is the minimum distance between turns in your course?
Would you provide me your tracks?

I'm not sure if a hard core user like you (GPS in the forest track) will be sacrificed by a feature like this completely but I'm sure we will see better results than now whereby already this is much better in terms of turn detection than the old "Notify when switching to another point".

Have fun on your bike and take always some breadcrumbs with you ,
tommi

[Joachim Buhl]

Hello Tommi

Thanks for answering me, and special thanks for reading my long post.
First of all I want to say, that the guiding feature of Locus and its other abilities (Display on/off, vector maps, MTB themes...) is currently the best in market.
To make it even better we have to discuss what we really need. And this is something, what I do not understand about your approach.

If we talk about the "non hard core" users, the navigation ends up on ways of the category "Waldautobahnen", forest highways.
For these users you do not have to find an algorithm to make notifications out of a track (angle, distance...), but you should use also the map information itself. For this category the routing tools are working better than all possible algorithm. You have also not the problem with sticking, because the track is "planned" directly on the map data. You solve the problem of how to handle 90° turns, without the need of an notification, because the way just makes a turn. Remember https://getsatisfaction.com/locus/topics/difference_between_guiding_and_navigation
So for this we need a possibility to "translate" a GPX track into a calculated route with using the map data, which exists.
This means Locus needs better routing calculation suppliers (not only A to B, but along a track), or Locus needs an own routing engine.
The current function of planning with Locus is not so bad, if Menion eliminates the useless notification on the connection point of two following segments. See picture "test7" in the link above ("Go east on unnamed road").

For the "hard core" users, the routing with map data (small paths) does not work right now (see my link).
For that problem we need a short term solution. Therefore your algorithm could be helpful, but than we need it without sticking, with moving map and so on. So in the end we need old guiding behavior with a better algorithm using TTS and the opportunity to get additional notification, when your off the track (https://getsatisfaction.com/locus/topics/choose_notify_when_switching_to_another_point_and_notify_when_too_far_away_from_track_at_the_same_time).
To solve the problem of 90° direction changes on a way and the problem of going straight but changing ways we need manual notifications (https://getsatisfaction.com/locus/topics/text_to_speech_reading_waypoints).
For a long term solution we need navigation calculation with map data also for small paths.

To sum it up: Trying to do navigation without using the existing map routing data does not make sense for long term. For short term working on a better algorithm to make navigation without map information is senseless combined with car navigation behavior.

Proposal:
1. New, better (your) algorithm with old guiding + off the track notification + manual TTS readed waypoints.
2. Optimization of notifications when planning tracks with navigation in Locus (No "Go east on unnamed road")
3. Better routing of the external services on small paths or an own routing engine for Locus

I'm looking forward to see how this will develop and I like to discuss about the right way to go.

Thanks

Bye

PS.: Minimum distance between turns is about 15-20m

[Joachim Buhl]

Hello All

To 1. I'm corious about the Waypoint generator and I'm really looking forward to test it. For all tests, I'm your man.
        So I tested bikeroutetoaster for 1min. It does not even know the first path in the forest 

To 2. Is the walking modus of the navigation module also "magnetic"?
          Yes, we need the waypoint guiding messenger. Adding and deleting notification waypoints and TTS ability of waypoints will help alot.

I use a Sony Xperia Neo. It uses also Glonass satellites and is even compared to some garmins relativly accurate. The compass is also not so bad. If I'm standing on a Y crossing, I can turn the handle bar and can see on the map where to go, thats possible.

I also rerouted my track from yesterday with Mapquest within Locus. Menion removed the useless notification on the connection between the segments and does not even mentoined it  .
The result is not so bad. The track is accurate on the path, the notifications are dependend to the map data (no useless direction changes when the path makes a curve) and the ability to delete single notifications is already there.
No magnetic (smallest possible) behavior, compass moving map, adding TTS waypoints manual and I think we would have 90%.
Optimization of display On/Off should also be possible in short term.

Thanks

Bye

[tommi]

Hi Joachim, Willy,
basically I agree with all you both wrote.
Joachim, your results with the generated waypoints were worse than needed due to using medium setting.
Medium setting means that the algorithm can detect turrns  with a distance down to 75m in best case. In worst case it's only 150m.
For high setting its 25/50m.
My improved proposal should make it possible to have always ability to detect turns with distance down to 25m in the high setting. However I wish this parameter could be freely configured by the user (minimum expected distance between turns). On the other hand if you set this on low values the danger for false positives exists (turn instructions where is only some deviation in the track.

I personally prefer to plan routes with brouter, sometimes tweaking it by setting extra via points. brouter does not create directional infos, only trackpoints. Here the help of the waypoint generator is perfect (with the well known restrictions, no knowledge of track, generates infos if there is only a curve, is relying on the quality of the input track).

If you, Joachim, are happy with using Mapquest I'm absolutely fine with it. Use the instrument which gives you the best results.

[Bucky Kid]

Hiyas and thanks to menion for this great feature. I had similar idea in the past already so I wanted to make a couple of suggestions to improve this:
1. allow user to edit the navigation commands at way-points where necessary and mass delete the auto-generated navigation commands by Locus where they're superfluous (or just offer choice to add manual navigation commands by user from scratch). The reason is someone (like me) can use dense routes to follow the trail shape accurately. My idea is that user should not to be flooded by needless voice instruction to avoid then missing truly important way-point. Instead that I would prefer to place navi commands only at points where they're necessary (regardless on current trail shape).
2. I don't know how the voice navigation works but I think it' would be nice if Locus spoke out an notification of route change in some advance and then again very close to the point of direction change like it is done in classic car navigations. It would also be useful if user could choose count and distances of voice notifications preceding the navigation point and if Locus offered a possibility of vibrating event at the same time.
3. Hopefully this useful feature will soon be included in public version of Locus 

[Joachim Buhl]

Hello Willy

Thanks for your test.
I've looked to your pdf, not in detail, but I think you experienced the same like I did in my test.
Newest version, planned track on MTB trails.
Shortest distances possible:

To much information.
Modified distances until first important notifications disappears:


To compare: Rerouted track with MapQuest (by foot):


To be honest: I think it is simple not possible to get good results without taking the map data into account - period.

So in my opinion Locus should go on with Routing function as followed:
1. Manual instruction editor (delete, create and also customized notifications (TTS))
2. Offroad navigation modus without to much stickyness and with compass map orientation.
3. Automatic rerouting of GPX tracks with routing providers (Mapquest...)

Thanks

[Joachim Buhl]

Hello Guys

Whats new to navigation over the last beta versions?

Today I did a navigation route with Mapquest and the annoying "you reached your destination" after each single segment is there again. I thought Menion removed that. Now its there again.

Is the timeout for the display activation changed meanwhile, so that on follow up notifications the display is still activated even for the last one?

What is the plan about the wish to remove and add navigation notification manually?

Thanks

Bye

[Joachim Buhl]

Hello

Follow up from here http://forum.locusmap.eu/index.php?topic=3318.new#new .

@Tommi: Yes, I can see my "real" position on the record and also on the end of the heading line.
                   I could live with that. A big point on the end of the line would be nice though.

I've been out two days ago with navigation mode on the mountainbike. The magnetic behavior and the missing moving map (compass) is really a nogo. Together with the fact, that the notifications come very late (at 50m notification its 10m in real) the current navigation mode is useless for mtb-navigation.

And to be honest. I cannot see a big difference between the "old" guiding along a track with TTS and the new "navigation generator" in respect to the notifications, that are given. To make it more precise: The potential advantages of the "navigation generator" is meaningless compared to the disadvantages of magnetic behavior and missing moving map.

Thanks

[tommi]

Together with the fact, that the notifications come very late (at 50m notification its 10m in real) the current navigation mode is useless for mtb-navigation.

The late (and regarding distance wrong) notifications are not the problem of the new navigation generator algorithm I proposed and Menion implemented but a problem of still not improved TTS output. Menion promised this to come...

And to be honest. I cannot see a big difference between the "old" guiding along a track with TTS and the new "navigation generator" in respect to the notifications, that are given. To make it more precise: The potential advantages of the "navigation generator" is meaningless compared to the disadvantages of magnetic behavior and missing moving map.

You are right, the navigation generator is only one step (but not a small one) for offline (and offroad) navigation.

[Menion]

Today I did a navigation route with Mapquest and the annoying "you reached your destination" after each single segment is there again. I thought Menion removed that. Now its there again.

Is this really happen? I'm checking it precisely, and found another small problem with end point but this seems to be correct and no middle point remain in generated track. Is this happen also with newly created tracks? (because it should happen in case, you use any older track that is already stored with this bug)

Is the timeout for the display activation changed meanwhile, so that on follow up notifications the display is still activated even for the last one?

There were no change. Do not understand from your sentence if there is any problem or you miss any feature. This "Turn on display" feature, really just turn on display if is off. Display is then turned off after time you have defined in your devices settings

What is the plan about the wish to remove and add navigation notification manually?

I would like to do it. Seems to be good idea, not too complicated to do. So it's just matter of time. Currently I have some other important tasks, so I would like to work on it at start of next year (to make it all this guiding/navigation) perfectly work on next spring season

I've been out two days ago with navigation mode on the mountainbike. The magnetic behavior and the missing moving map (compass) is really a nogo. Together with the fact, that the notifications come very late (at 50m notification its 10m in real) the current navigation mode is useless for mtb-navigation.

So what would be optimal solution from your field experience? Allow to use "Navigation system in Locus" (not guiding) together with ability to turn off snapping on track?

What about late notifications? I do not have such experiences from my rides on bike or in car. Locus compute distance that should be said, by time to cross minus one second. So if you ride 36km/h, then Locus should say last notification 10 seconds before cross. This means 10 m/s * 10 sec = 100 m. 100 m - distance per 1 sec = 90 m, so you should hear notification 90 metres before cross. Weren't there any problems in GPS signal? Because this should have effect of course

And to be honest. I cannot see a big difference between the "old" guiding along a track with TTS and the new "navigation generator" in respect to the notifications, that are given. To make it more precise: The potential advantages of the "navigation generator" is meaningless compared to the disadvantages of magnetic behavior and missing moving map.

I'm sure it's much more precise.