'Attach to road' performance #19642
-
|
I explore some new multi-day hiking trails and I often import tracks as GPX from hiking websites. They are always made of many points connected with straight lines. To use the full potential of OsmAnd I try to attach them to roads. I have never successfully attached to road any of them. It just seems to take forever. I just waited an hour for a 1.3k points track and nothing happened. I tested with smaller tracks and even 14 points took a few seconds. 100 points probably less than a minute. You can find an example track here I'm using iOS. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 19 replies
-
|
I always look for a different import format to avoid using 'Attach to road' because I find the performance very poor. |
Beta Was this translation helpful? Give feedback.
-
|
@Yaqana Your track is made for pedestrian profile, and it is 153 km long (this is quite a lot!). |
Beta Was this translation helpful? Give feedback.
-
|
@DmitryAlexei thanks for reply! I was just curious if it's expected or it's a bug. Using "attach to road" on long tracks would be the simplest way for my case, but if the app is not meant to do that then I can live without it |
Beta Was this translation helpful? Give feedback.
-
|
@Yaqana |
Beta Was this translation helpful? Give feedback.
-
|
Instead of using paid route planner apps, we recommend using OsmAnd web https://osmand.net/map/ |
Beta Was this translation helpful? Give feedback.
-
|
Tracks produced in Route Planners like OsmAnd and others are naturally snapped to the (osm) road network.
It concerns the performance comparison of another FREE attach to road offer. |
Beta Was this translation helpful? Give feedback.
-
|
Significant performance improvement is achieved with new attaching algorithm, please give it a try with 4.8 nightly build |
Beta Was this translation helpful? Give feedback.
-
|
"After import, a (compatible) app does not need to add extra like TBT. When I follow the posted file with Simulated Navigation I am missing road names? Also no turn instructions at the round about? While I can see the route on the map it is a driving distraction to have to keep watching the screen for every turn. It also gives directions in a curve where there is no turn available (micro turn instructions)? This is not what I would expect. The file does not give proper turn by turn instructions in my opinion. If I manually add the route to OsmAnd then I get road names, I get proper instructions at roundabouts and there are no micro turn instructions. This is what I would expect from an imported GPX file. |
Beta Was this translation helpful? Give feedback.
-
|
A compatible app means so is NOT usefull for OsmAnd. |
Beta Was this translation helpful? Give feedback.
-
|
I am not trying to promote any app! I am only trying to find out why the GPX file import process is not working so that OsmAnd is more usable for me and other users. And may I politely remind you that you asked me for the app name. I quote from your post, "What routing service do you use as your track source ?" I would like to work with OsmAnd in resolving what is a problem for many users. I can look through previous post here and find many post related to the problem I am reporting. I would like to find a solution. Perhaps the exported GPX file from the routing service is corrupt or perhaps the import algorithm has a bug? Maybe I am the problem? I expect GPX files to be transferable between routing and navigation services. By this I mean not just the route but also the navigation instructions should work. Is the GPX file format so loosely defined it makes the files incompatible or only partially compatible between services? I know some major navigation companies have their own GPX file format. Shame on them! If the GPX format is so broken then shouldn't this be in the documentation so users would know what the limitations are? Here is what I am going to do. I will create a route in OsmAnd and save the route. I will also create the exact same route with a routing service and also save. I will then export both to GPX 1.1 file format (If I remember correctly the OsmAnd documentation says OsmAnd is compatible with GPX version 1.1). I will import both into OsmAnd and compare their navigation behavior. I will also compare file formats to ascertain the difference and report back here in a new thread. Does this sound like a good plan? If you have any constructive suggestions for my plan I would like to hear them? |
Beta Was this translation helpful? Give feedback.
-
|
That you communicate which service you use is good information. Considering each service always offers this (very) differently. The definition of gpx1.1 (Y2004) does not specify how TBT instructions should be added. So a performant uniform file exchange mode between apps is unfortunately not there. Such so do result in just a lot of chaos and fumbling. I do show you a very simple but decent track file (yes track, no typo) exchange method inclusive the TBT and via points. The fact that two apps read and use this perfectly is quite unique. Anyway, I don't decide what the developers of OsmAnd will or will not eventually ever implement. Find another example here: Import gpx route discussion |
Beta Was this translation helpful? Give feedback.
-
@Sonwon1 maybe a better approach might be to involve yourself in specific issue conversations with the label "and-gpx-track" https://github.com/osmandapp/OsmAnd/issues?q=is%3Aopen+is%3Aissue+label%3Aand-gpx-track |
Beta Was this translation helpful? Give feedback.
@Yaqana Your track is made for pedestrian profile, and it is 153 km long (this is quite a lot!).
For long tracks with huge number of points Attach to roads option may work slowly. Please refer to our documentation https://osmand.net/docs/user/navigation/setup/gpx-navigation/#attach-to-roads
As a workaround, you can increase the threshold distance. You can also cut your track into smaller pieces and attach them one by one.