Seltsame Einfügung von Wegpunkten / Strange insert of waypoints

Eine von Freunden erhaltenen Track versuche ich möglichst genau in Kurviger-Format zu bringen. Dazu setze ich Wegpunkte dort, wo die rote Linie vom Kurviger-Vorschlag abweicht.
Manchmal, aber schon des öfteren, erhalte ich beim “Setze als Zwischenziel” eine falsche Nummer und erst nach dem Verschieben in der Wegpunktliste die erwünschte Route.

Ich hoffe, man kann das nachvollziehen (einfach Wegpunkt 7 löschen und neu einfügen).

A track obtained from friends I try to get as accurate as possible in Kurviger format. To do this I set waypoints where the red line deviates from the Kurviger suggestion.
Sometimes, but quite often, I get the “set as a stopover” a wrong number and only after moving in the waypoint list the desired route.
I hope you can test that behavior (just delete waypoint 7 and reinsert it).


Uhm… wow that is one interesting case, thanks for the great posts (with links and screenshots and everything, nice :slight_smile: ). From a first glance I would say there is definitely something buggy going on there, because usually I would have just advised you to

  1. Click on the route
  2. Then drag that marker

Instead of placing a marker “in empty space”. But even that gives me the 38!
Not only that, if I then click “back” in the browser and try to place the marker again, it places multiple markers somewhere and gives me 40 there. That is really really interesting :smiley:
And yes it is testable/reproducible for me. I think our next task should be to find out “from when on” this problem happens. What’s the smallest possible route with which we can reproduce this behaviour

This route does have more than one issue.

If you look at the “turn instructions list” there are some U-turns witch make me suspicious:

  • at WP 4
  • at WP 11
  • at WP 19
  • at WP 20
  • at WP 22
  • at WP 23
  • at WP 25
  • at WP 26

To debug this route, you need to check each waypoint with a U-turn and check what is going on there.

  • Is there an issue with the imort?
  • or does Kurviger not like some parts of the route because some roads are blocked?


1 Like

Thanks for the detailed report! I will have to take a closer look to the algorithm, something is off here. If you move waypoint 37 and 38 slightly, it works fine. Maybe there is an issue if two waypoints are exactly placed over each other? I will further investigate this.

Okay - up to now I only took the .gpx-File from my friend and tried to solve the major discrepancies.
Now I further changed the file - no more U-turns, no more two WP at the same location and no blocked roads - but the problem still exists.

Yeah that’s a good point! I also looked for things like that and noticed that some markers are exactly on crossings, some are sliiiiightly off the road and some are on the “wrong side of the road” (which could mak the problems on highways). But I wasn’t able to pinpoint an exact problem

Even worse, I could swear that when removing the first 3 waypoints, the bug becomes non-deterministic and after page refresh sometimes appears and sometimes doesn’t. But that might have been due to caching, not sure on this yet

WP 2 and 20 are still on the same location :wink: once this is changed, it seems to work for me. I will have a look at this issue, this is indeed weird.

1 Like

Uupps - I’ve missed that … seems really to work now. THANKS!
Now I’ve to look at all other files for “double WPs” (may be a “feature” of BaseCamp :wink:).

Hmm, not entirely, Kurviger loves to duplicate waypoints, too, at the end and beginning of a road, I’ve just not been able to consistently reproduce this, there’s a forum post coming at some point about this as soon as I can prove it :smiley:

Thanks for the report, I could identify the issue in the code and created a fix. It will be available for the website shortly.

BTW: I moved this discussion to the category website and app since the issue exists in both platforms.

This issue should be resolved for the website, please let us know if you find any other issues related to waypoint placement.

Uhhh works nicely. So what was it? Feels a bit like an array index/counting/looping problem, am I close? :smiley:

Yes :+1:. It’s a bit complicated to explain without going into detail, but when designing the algorithm I haven’t considered the edge case of two waypoints being at exactly the same position, except for start/end. It essentially ended up always using the later waypoint in this case and the rest of the algorithm failed due to that.