[Feature request] Track Navigation support

[megabugman]

After importing a track in KML file format, I miss the option to follow (navigate) along that path/track.
This feature is implemented in OsmAnd.

Note: as a temporary workaround, it is possible to add intermediate stops and build a similar route in OM manually.

[biodranik]

This "follow" mode at least should be designed somehow in a safe way. Questions:

1. Is it for foot or for car navigation?
2. Voice? Directions? Vibrate? How it should work?
3. What to do if there is no map under the track?
4. Is the voice "you're too far from the track" notification enough?

[megabugman]

Hi,

1. I like to use it for motorcycle but from my point of view car, bike, foot should be supported.
2. It should work as the normal routing. In normal routing a start and end point and stops (optionally) are included manually. A track normally includes a start/end point and may stops. From my understanding when deviating the application should use voice indication to the next/nearest point in the track.
3. the same procedure as with "normal routing" what happens there.
4. not sure. The application should route to the nearest point until navigation is turned off.
   thanks

[biodranik]

3. the same procedure as with "normal routing" what happens there.

There is no such situation in "normal routing". Because "normal routing" always uses underlying maps data for tracks. And it always knows crossings and directions.

If there is NO maps data under your track, nothing can be done with directions. If underlying maps data is incorrect, then you also won't get proper directions (example: there is a road under the track, but there is no crossing road on the map).

[biodranik]

See also #2384

[dandud100]

This "follow" mode at least should be designed somehow in a safe way. Questions:

1. Is it for foot or for car navigation?
2. Voice? Directions? Vibrate? How it should work?
3. What to do if there is no map under the track?
4. Is the voice "you're too far from the track" notification enough?

Maybe get a look at this android app.

It detects how far the starting point of the .gpx file is away from you first, if it is too far away then it will tell that you should route with (for example) gmaps first as it is not providing conventional street navigation.

When you are at the starting point of the gpx track it will give you voice instructions while driving on the track. It does not rely on normal street data, it just detects left and right turns and say that you need to stay left in 300 meters for example. I really like how it is handled in this app, would be best if you give it a try as my english is not good enough to describe it.

OM could do it like this way except it does not need to say that you need an different map to navigate to the starting point, as it provides conventional street navigation.

OM should definitely not care if there is no map under the track at all. It really does not matter when following a pre recorded track it would be even worse if OM would not stick straight to the track.

[biodranik]

It would be great to see some video + voice recordings on how other apps are doing it for foot and car/bicycle nav.

[Mike-0815]

Hello Alexander and the other devs,

I think, that principally shouldn't be very complicated to implement:

After importing a (gpx/kml) track, OM should try to match it with underlying OSM street-data. If there is no underlying OSM street-data matchable (for example deep in the woods), OM shouldn't complain about that, and use and display the trackpoint(s) recorded in the track, on the map anyway.

If there -IS- underlying street-data available in an imported track, OM should (principally) navigate the user exactly in the same way, how navigation works in OM today, but along the track.

If there is -NO- underlying street-data available, OM should navigate the user from any significant trackpoint to the next significant trackpoint (while always showing the map and the actual location-triangle) anyway. Significant means, that there will be a significant change in direccion between the last and the following trackpoint. OM should tell the user by a compass-like arrow on screen and voice direction, where to go. Voice direccions in the form of "go straight ahead", "turn slightly right", "turn right", "turn back" and so on.
Witch such given voice-direccions, anybody is able to navigate even with display turned off, easily, especially when using a Bluetooth-headset.

There's also an App called "Routes", witch is specialized in loading tracks/routes and guides the user along them. Maybe you'll take a look at it, when this the implementation of this feature become actual/concret.

Kind regards,
Mike

[d-damien]

An idea, not sure it's right : when too far from the track, use pathfinding to add a temporary track to the closest point of the track − remove the temp track when close enough or too far.

But is it not possible to copy what is (was ?) being done in OsmAnd ?

[biodranik]

@cyber-toad are there any specific GPX-only elements that may be important for navigating over importing track? Does KML support something in this regard? It would be great to check what's used/popular on the market now, and make a list or table for GPX and KML of what we are missing now and need to support during the import/conversion.

[cyber-toad]

@cyber-toad are there any specific GPX-only elements that may be important for navigating over importing track? Does KML support something in this regard? It would be great to check what's used/popular on the market now, and make a list or table for GPX and KML of what we are missing now and need to support during the import/conversion.

I'm not sure what elements for navigation do you mean? I think we just need to build a line and track how close user is to this line and we have all geometry already?

[walterjwhite]

I would like to see this feature in OM.

For me, I would expect it to work the same with on or off road, if there is a trail or road to follow that and then limit the voice guidance to only when there is an intersection or change to another road. Whichever mode the user is in for navigation should apply the same rules to the GPX track.

That said, that may be easier to implement for on-road tracks than off-road where the road or trail may disappear. If that happens, what should OM do, follow the track up to some pre-configured distance and beyond that, warn the user that the imported track is not following a known trail or road and manually stitch in that GPX segment?

Additionally, should there be an option to try to use nearby trails or roads prior to importing? Perhaps if users don't want guidance, there could be another option which disables guidance and just shows the route on the map for the user to figure out.

Additionally, the original track is just a vehicle to transfer information into the app. That said, perhaps there could be one last option which allows the user to save the track as an OM route to pull it up next time like a shortcut so that OM doesn't need to do the whole reimport process again? This would be akin to the option in Google Maps to save a shortcut to the home screen. It need not be the home screen, but within the app itself.

For routes that are prepared externally, this would allow OM users to use a track as if it were drawn within the app and benefit from the voice guidance and turn-by-turn directions.

In summary:

1. add option to 'snap' to underlying roads and trails within a given tolerance
2. add option to use segments of GPX track verbatim if there is no road or trail underneath (within the above tolerance) and for a given distance before failing or warning the user
3. add option to enable turn-by-turn navigation for imported GPX tracks
4. add option to save processed GPX track as a planned OM route for future navigation and reduce the need to reprocess the same GPX

[biodranik]

OM's philosophy is "let's keep it simple to use". Fewer options, more convenient, expected behavior.

[Mike-0815]

Exactly Alexander ! That's one of the "magic", the advantage over 99,9% of the navigation-apps OM has and it's philosophy should be kept strictly like this - easy2use, even at the cost of not implementing a function, but NEVER non-intuitive to use and many functions will make this much more difficult to keep. Really good software does even not need a manual !