sussamb wrote: ↑Thu Dec 21, 2023 5:53 pm
Hmmm ... that shouldn't happen. If you duplicate a route you can make changes without affecting the original, even if it's in the same folder. Exactly what change did you make?
I've experimented more with Duplicates. The changes in a duplicate will not be lit in the original and V/S. So you can remove the unlit part and it won't effect the other (duplicated) route.
If you will move the duplicate route to a different directory and after that Remove it from the original directory, then changes you do in the new (duplicated) route will not affect in any way the original one.
Basecanmp is a complex and not intuitive software (reason many are shy away from it), yet a very powerful one if you know how to use it. It beats any 3rd party software in what you can do with it. Too bad Garmin is not supporting it any longer.
Basecamp stores its route data in a well designed database which avoids unnecessary data duplication.
This behaves something like this....
When you choose to use a particular waypoint, all of the data, name, lat, long, address, postcode, symbol, phone, elevation, comment etc are all stored as one entry in the list of waypoints. Like a lookup table. The entry is given a unique key . the name that you used. Eg MyTown
When you use a waypoint in a route, it simply uses the key - MyTown - in order to access the rest if the data. You cannot have two waypoints in the lookup table that have the same name - it has to be unique.
When you copy a waypoint, say you use the same cafe in a number of different routes, it simply copies the key - MyTown - not the data. When it needs to, it gets the relevant data from the lookup table in the row labelled MyTown.
So you might have a circular route. MyTown, Here, There, SomeWhere, MyTown. MyTown is used twice in the route but its data is stored in the lookup table just once.
If you choose to double click a waypoint -eg MyTown - and change its data, you are actually changing the data in the lookup table. So if you change the symbol, or its lat, long location, it is going to affect every single route that uses the Waypoint with the name MyTown.
When you duplicate a Waypoint, that creates a brand new entry in the lookup table, and it has to have a different name from anything else in the entire database - so by default it gets called MyTown1. The data is also copied from MyTown into the entry for MyTown1 for the time being.
You now have two entries in the table for the same place but they have different rows in the lookup table, so if you change anything related to MyTown, it does not affect any of the points that use MyTown1. They are independent if each other.
This might affect a lot of your routes - if you are modifying your route and you decide to Move your cafe Waypoint so that it is after the coffee stop, on the road that you want to take when you set iff again, then that simple drag and drop changes the data in the lookup table. So although in the route that you are currently looking at, you wanted it on the road heading North from the Cafe, in a different route you might have been heading east when you stopped for coffee. In that route the position of the waypoint has also changed and will no longer be on the correct road.
I often use the same coffee stops, and create Waypoints and use them over and over again. But I also put a route point on the road that I want to take after leaving the cafe. Cafe Exit, or Cafe Exit N.
The Cafe Waypoint is placed as a shaping point so that it makes it easy to ignore.
The Cafe Exit is not a waypoint, but is set as a Via point so that it appears in the trip data and also in the next destinations should I need to restart the route. Select Next Destination shows only Via Points.
I have oversimplified the database stuff, it is more complicated than I have suggested here. But that is the gist of it. Ive related it to just waypoints, but the same ideas apply to routes, and everything else in the system.
But you are familiar with this concept. In your NHS app (uk health service records) your name and phone number appear on many different screens for many different appointments, for many different doctors, chemists, etc.
But there is only one entry in the table. If any one of these users with the right access changes your address or phone number -eg because you have moved - then that change is reflected everywhere in the system - not because the system modifies it everywhere else, but because it appears in only one lookup table.
As for copy and duplicate - Garmin have got to use words that make sense to people. But in this context there are two different operations that need different words. They chose copy for one situation and duplicate for another. They will have considered the options and decided. That's the way it is.
You will also notice a difference in the way that items can be deleted. This one instance of many that point to an entry in the table, or the entry in the table itself - and everything that points to it. Basecamp gives warning messages if the last item to point to the data in the table is about to be deleted.
For anyone looking in that knows more about fully normalised databases than me, please don't pull me up about the liberties that I have taken with the technical details. It's good enough for a broad brush description of why there is a difference between copy and duplicate.
Today, I discovered something really important. I found another way that doesn't work.
jfheath wrote: ↑Tue Dec 26, 2023 8:18 am
As for copy and duplicate - Garmin have got to use words that make sense to people. But in this context there are two different operations that need different words.
I've often thought "Clone" would have been a better choice than "Duplicate", capturing the current state of a point or route, but subject to independent change.
Or maybe just "Reuse" instead of "Copy", making it clear that the data remains the same and nothing is being changed.
But, yes,
They will have considered the options and decided. That's the way it is.
