Using: viking-1.6.2 on Linux
Normally when merging route B into route A, Viking adds a line from the end of A to the start of B, leaving a 1-segment continuous route. But sometimes instead it leaves a gap between the end of A and the start of B, and a 2-segment route.
At least one way this happens is if you have ever used "Reverse Route" on route B. This seems to insert a marker (newsegment=yes) at the start of the route. The marker doesn't have any apparent effect there, until you try to merge this route into another route, and then you get a 2-segment route with a gap.
(This applies to Tracks, too. If you Reverse Track, then merge it, you get a gap.)
Steps to reproduce:
1.
Draw route R1 with a few segments.
Draw route R2 with a few segments.
Right-click on R1 and pick: Combine > Merge With Other Tracks..., select route R2 and click OK.
Result: R1 is connected to the former R2 and 1 continuous route exists.
This is correct.
2.
Draw route Q1 with a few segments.
Draw route Q2 with a few segments.
Right-click on Q2 and pick: Reserve Route.
Right-click on Q1 and pick: Combine > Merge with other Tracks..., select route Q2 and click OK.
Result: There is a single route Q1 but it has a gap before the former Q2.
This is not correct.
Explanation:
In viktrack.c function vik_track_reverse() I can see where it adds newsegment=TRUE to the new head of the track or route. Comment is: "First segment by convention has newsegment flag..." But this convention seems not to be applied when a new track or route is drawn, and the track merging function doesn't seem aware of it.
+1
Thanks for taking the time to report. I have been observing this bug for some months (years?) but did not find the time to analyse what actually triggers it. This is with 1.6.1 on Ubuntu 16.04.
r.
Last edit: rooots 2018-04-23
Agreed the new drawing of track & route creation should set the first trackpoint newsegment flag to TRUE.
Then this should mean the track merge function doesn't need to worry about segments.
Some other observations:
I don't think this should be allowed for routes.
I believe the main intention for this method is to merge the potentially multi selected items in time order.
Otherwise the order the items are merged is somewhat undefined (I think it might internally end up alphabetical on the name) - the user has no way to specify this order.
Since routes don't have time, this method is inappropriate.
I sort of think allowing merging multiple tracks without timestamps shouldn't be allowed unless the merge order is user selectable (or stated how the ordering works - at least in the manual).
One should use Append Track as often as necessary instead to get them combined in the order one desires.
c.f. The 'Merge by Time...' which merges all available tracks according to times within a specified closeness.
By definition routes should only have one segment. However ATM this creates routes with multiple segments. Although when the file is saved the route returns to a single segment.
Source code updated
Thanks, just built from the Github code - it appears to be fixed for routes.
However, with combining tracks (both "Combine -> Append Track" and "Combine ->Merge with other Tracks") the issue persists.
r.
Last edit: rooots 2018-05-12
Yes this is intentional behaviour.
You need to explicitly do a Track->Combine->Merge Segments to remove gaps.