OpenCPN Routes Problem

[bilgewater]

Has anyone run into this and have a workaround. I recently upgraded to OpenCPN v-2.3.1 and it's been a smooth transition and it works very well with one exception. Now I seem to be having route conflicts in the route manager dialog box which I never had before.

Example: I have a route named Campbell River to Prince Rupert that was previously created. I display this route on the chart and make some changes with the waypoints and I change the route properties including "Name" "Depart From" and "Destination". Then I export it as as a new route "Campbell River to Ketchikan AK".

Now to use it...If I import "Ketchikan" into the route manager I get "Prince Rupert". If I import "Prince Rupert" I get "Prince Rupert"

So I created a new one called "Campbell River to Ketchikan NEW". I can import that one but I can't import "Prince Rupert" and vise versa so a slightly different problem. ie: They both open but I can't have them in the dialog box at the same time.

I've tried it with other routes and I get the same varying results. My work around for now is to have a route open and simply trace a new route over top and make the necessary changes, it's time consuming particularly if I follow it exactly because a dialog box keeps coming up asking me if I want to use nearby waypoint but it does work. Is there another workaround out there? If there's no other workaround, I'm just getting it out there so it might be corrected on the next version .

[fgd3]

Originally Posted by bilgewater

So I created a new one called "Campbell River to Ketchikan NEW". I can import that one but I can't import "Prince Rupert" and vise versa so a slightly different problem. ie: They both open but I can't have them in the dialog box at the same time.

1. Explanation

The reason you can't import both routes is OpenCPN sees them as a single route because they share the same guid (globally unique identifier). You can open the .GPX files with Notepad (or any other text editor). Search for "guid". You'll find a line that looks like this:

<opencpn:guid>320f0000-f587-4b97-9f20-aa5b2d060000</opencpn:guid>

There's a guid for the <rte> (route) and one for each <rtept> (route point)

When you change anything in the route properties OpenCPN should regenerate the <rte> guid but it doesn't. When you change anything about a waypoint in a route OpenCPN should regenerate the <rtept> guid but it doesn't.

There are two ways to fix it. The program logic can be changed to regenerate a guid when the object to which it applies is changed or guids can be removed from the .GPX files. I think both alternatives need to be considered, because I don't see the advantage to attaching a guid to every route and waypoint.


2. Workaround

Until this bug is repaired you can work around the problem like this. Open the .GPX file with Notepad and do a global search and replace changing every occurrence of "guid" to "wrongguid" (or any other string you prefer). OpenCPN won't recognize the new string as a guid so it will ignore it. (All the guid strings are identified as OpenCPN extensions, so they don't affect other programs that might read the file.) The next time you import the route OpenCPN will generate new guids. When you export the route the .GPX file will be written with the new guid strings and the "wrongguid" strings will be gone.

Fabbian

[bilgewater]

Thanks very much Fabbian, that works great and it's much quicker than my workaround. I can certainly live with that no problem at all.
Steve

[fgd3]

I posted a bug report for both 2.3.1 and 2.4 beta on Flyspray so this should get fixed pretty soon.

Fabbian

[bilgewater]

Thanks Fabbian, I saw where you posted that.
There is only one other minor bug as well but I believe it's concerned with the suplimentary software WXtides Harmonic file. It seems that some of the current dialog boxes that pop up are giving the correct information but it says "Feet" on the left side and it should say "Knots"
Example: west coast Canada, just off Johnstone Strait, "Current Pass"
050 25.0292N 125 54.0692W and some of the secondary stations around it including Race Pass, Ransom Point, off Broken Island and there are many more, this is just an example. Some are correct like just SE of here Ripple Point and Seymour Narrows are correct.
Steve

[nohal]

Well,
the guid is there to actually identify the route. If we keep changing it all the time, how much time will pass until a question like "I made an error while playing with my route, tried to open the GPX backup, but now have two routes. Why?" will arise? When thinking about it, there is a logical bug, but the solution in my eyes should be much more careful than changing the guid all the time (and loosing ALL the advantages it brings in knowing that we actually DO work with the same navobject). Import/export time comes to my mind and even then I can imagine cases when changing a guid is definitely not viable.

Pavel

[bilgewater]

Originally Posted by nohal

Well,
the guid is there to actually identify the route. If we keep changing it all the time, how much time will pass until a question like "I made an error while playing with my route, tried to open the GPX backup, but now have two routes. Why?" will arise? When thinking about it, there is a logical bug, but the solution in my eyes should be much more careful than changing the guid all the time (and loosing ALL the advantages it brings in knowing that we actually DO work with the same navobject). Import/export time comes to my mind and even then I can imagine cases when changing a guid is definitely not viable.

Pavel

Understood...What about a features request for a button in the route manager dialog box for a "SAVE AS" to save a new route to the GPX folder based on the currently displayed route or the selected route in the route manager dialog box.

Edit: Just noticed a Sticky thread in this forum called feature requests. I'll post it there.

[fgd3]

Originally Posted by nohal

Well,
the guid is there to actually identify the route. If we keep changing it all the time, how much time will pass until a question like "I made an error while playing with my route, tried to open the GPX backup, but now have two routes. Why?" will arise? When thinking about it, there is a logical bug, but the solution in my eyes should be much more careful than changing the guid all the time (and loosing ALL the advantages it brings in knowing that we actually DO work with the same navobject). Import/export time comes to my mind and even then I can imagine cases when changing a guid is definitely not viable.

Pavel

All a guid can tell you about an object is that it is different from an object with a different guid. It's supposed to tell you that two objects with the same guid are in fact the same, but it doesn't unless you regenerate the guid any time the object is changed. OpenCPN's failure to do that is why this discussion got started.

When you change any attribute of a route it becomes a different route. It needs to have a different guid so the two routes will be recognized as different.

If you make an error playing with your route and you want to revert to the saved .gpx copy, delete the route before you import the .gpx file. (If the route was created after 2.3.0 you can't import the .gpx file without deleting the route.)

If you've changed the route and want the new revision to replace the old route export it under the original filename. If you've changed the route and want the revised route treated as a new route save it under a new filename. (Right now OpenCPN won't let you do that because the guid error makes it think both routes are the same, but I'm sure that will be fixed.)

When you edit a text file and save it back under the same filename is it still the same document? No. It's a different document which has replaced the original document but has the same name. What do you do if you want to keep the original document and the revised one? You save the revised text under a different filename.

So what if you saved the revised document under the original filename and later you discover a file with that same name in another directory? You wonder "Is this an earlier version of the document or a copy of the current revision?" To find out you look at other attributes of the two files: file size, date and time created or modified.

What are "ALL the advantages it brings in knowing that we actually DO work with the same navobject"? What advantage would be lost in generating a new guid for a waypoint that has been moved or renamed? What advantage would be lost in generating a new guid for a route that includes a different waypoint?

"Import/export time comes to my mind and even then I can imagine cases when changing a guid is definitely not viable." How about sharing some of those cases? Of course you wouldn't generate a new guid when importing a .gpx file that already had guids and you wouldn't generate a new guid when exporting a route that hadn't changed, but that was never suggested anyway.

Fabbian

[nohal]

Fabbian,
of course this bug will be fixed and if nobody will be faster it will probably be me who fixes it as I wrote this piece of code anyway...
The fix is not very complicated be it whatever, complicated is my current geographic position and size of a computer that fits in my backpack actually
But I would like to do it the right way - and think that regenerating the guids the way you suggest is a bit too aggressive approach. Would a dialog asking you what you want to do if there's a conflict in guids at import time (replace existing/regenerate guids/cancel) satisfy your needs or is there some other case you have on mind that would not be possible with it?
Why don't I want to change guid that often? Because I'm not convinced that moving a waypoint always makes it a completely new waypoint and I don't think changing a letter in a route name makes it a different route.
Right now it would really not be a big deal, but what I have on my mind for the future is making it possible for the plug-ins that need own data and maybe even online services to interact with OpenCPN and thus don't want to throw away the id's when it's not necessary.

Comments of course welcome

Pavel

[Ptizef]

May be a function 'Duplicate' would fix the problem as this would create a new identical nav object but with a different guid ?
If you want both modify and keep the old one , you have to create first a 'copy' and then modify.
Jean Pierre

[fgd3]

Originally Posted by nohal

Fabbian,
of course this bug will be fixed and if nobody will be faster it will probably be me who fixes it as I wrote this piece of code anyway...
The fix is not very complicated be it whatever, complicated is my current geographic position and size of a computer that fits in my backpack actually
But I would like to do it the right way - and think that regenerating the guids the way you suggest is a bit too aggressive approach. Would a dialog asking you what you want to do if there's a conflict in guids at import time (replace existing/regenerate guids/cancel) satisfy your needs or is there some other case you have on mind that would not be possible with it?
Why don't I want to change guid that often? Because I'm not convinced that moving a waypoint always makes it a completely new waypoint and I don't think changing a letter in a route name makes it a different route.
Right now it would really not be a big deal, but what I have on my mind for the future is making it possible for the plug-ins that need own data and maybe even online services to interact with OpenCPN and thus don't want to throw away the id's when it's not necessary.

Comments of course welcome

Pavel

I didn't mean to give the impression that I was impatient about getting this fixed. Quite the opposite. I was trying to remind other readers a fix was in the works so they could live with a workaround until it's done. I appreciate your concern with doing it the right way. That's my concern, too, which is why I'm participating in this discussion. Getting it right is harder than it seems at first look.

Any dialog that mentions guids would only confuse 99% of the users. Until the issue came up in 2.3.0 I didn't know what a guid was. Furthermore, I think it's not good design to require more user intervention than necessary.


WAYPOINTS

A waypoint is nothing more than a latitude and longitude pair (LL). We give it a nickname for mnemonic convenience. You can't move a waypoint. What you can do is use the same nickname to refer to a different location. The graphical user interface makes it look like you're moving a waypoint when you drag it, but what you're really doing is pointing that nickname at a different LL. The LL is the waypoint's defining characteristic. If that is different the waypoint is different. If the opera company moves two miles away it's a new waypoint even though we still call its building the opera house. It's OK to reuse names, but a different LL is a different waypoint.


ROUTES

A route is a path through a series of locations. It is represented as a linked list of route points. (A lot of misconceptions result from the conflation of route points and waypoints. A waypoint can serve as a route point, but they're not quite the same.) Plan a route that goes from LL1 to LL2 to LL3 and call it R1. Now plan a route from LL1 to LL4 to LL3 and call it R2. R1 and R2 are different routes, not because they have different names, but because they follow different paths and visit different locations. If, instead of creating R2 we just edit R1 to replace LL2 with LL4 we still have a new route which replaced the old one. It follows a different path and visits different locations. It's a new route. Let's say you normally drive from home, past the post office, to your office. One day a friend suggests you go by the opera house instead of the post office. He says "I'll show you a new route."

Fabbian

[nohal]

Fabbian,
I understand your point perfectly and your logic is 100% right. But I still think it's just one of the points of view you can apply to this problem. When I'm navigating the races and add another waypoint for a tack because the weather changes, I personally don't consider it being a new route, while applying the strict logic you described, it of course is.
Don't worry, whatever the solution will be, it will not be bothering the user with terms like guid...

Pavel

[fgd3]

Originally Posted by nohal

Fabbian,
I understand your point perfectly and your logic is 100% right. But I still think it's just one of the points of view you can apply to this problem. When I'm navigating the races and add another waypoint for a tack because the weather changes, I personally don't consider it being a new route, while applying the strict logic you described, it of course is.
Don't worry, whatever the solution will be, it will not be bothering the user with terms like guid...

Pavel

1. You don't add a waypoint, you add a route point. A waypoint is a saved (named) reference to a location. It isn't necessarily a destination, but it can become one. A route point is a location you have chosen as a destination, either intermediate or ultimate. When you click on a waypoint and select "Go to Mark/WP" that waypoint is used as a route point. When you create a route by clicking on various points on the chart those route points aren't even saved as waypoints. They go away when you delete the route. It may seem to be a semantic quibble, but a correct understanding of what you're doing makes for a correct program design.

2. When you add a new route point in response to a weather change that forces a tack you've created a new route even if you don't think of it that way. It doesn't matter how you think of it but it matters how the program handles it. Even if the program treats it as a new route you can go on thinking about it just as you do. Most of us find it convenient to think the sun rises in the east and sets in the west, but an astronomy program has to know the sun rotates from west to east.

3. When you add that new route point are you going to export that route to a file? Probably not. You're probably going to scrap it at the end of the race, right? So in that case it doesn't matter if you regenerate the guid.

4. What's the big deal about trying to conserve guids? The ITU X.667 recommendation for UUIDs (X.667*:*Information technology - Open Systems Interconnection - Procedures for the operation of OSI Registration Authorities: Generation and registration of Universally Unique Identifiers (UUIDs) and their use as ASN.1 object identifier components) suggests they can be used as transaction IDs. It's not like there's any shortage of them.

5. I wonder if perhaps you're trying to do two contradictory things with guids. On the one hand, you want to identify objects as belonging to OpenCPN. For that to work you need to generate a single guid for OpenCPN and use it to tag every object that OpenCPN "owns". On the other hand, you're trying to distinguish objects that OpenCPN is using. To do that you need a different guid for each different object. Could something along those lines be related to your reluctance to generate new guids?

Fabbian

[nohal]

Originally Posted by fgd3

1. You don't add a waypoint, you add a route point. A waypoint is a saved (named) reference to a location. It isn't necessarily a destination, but it can become one. A route point is a location you have chosen as a destination, either intermediate or ultimate. When you click on a waypoint and select "Go to Mark/WP" that waypoint is used as a route point. When you create a route by clicking on various points on the chart those route points aren't even saved as waypoints. They go away when you delete the route. It may seem to be a semantic quibble, but a correct understanding of what you're doing makes for a correct program design.

Correct. But it is a bit of a semantic quibble Have a look at the GPX schema docs - GPX 1.1 Schema Documentation - especially the wpt, rtept and trkpt elements...

2. When you add a new route point in response to a weather change that forces a tack you've created a new route even if you don't think of it that way. It doesn't matter how you think of it but it matters how the program handles it. Even if the program treats it as a new route you can go on thinking about it just as you do. Most of us find it convenient to think the sun rises in the east and sets in the west, but an astronomy program has to know the sun rotates from west to east.

The program doesn't think about it as a new route and it would be a bad and unefficient design if it did. If it did, we would have to recreate the instance of a navobject every time something changes. A route point is just a property of a route, there is absolutely no need to think of a route as a new navobject (and implement it that way) when one of it's properties changes. To say the least it would be an unefficient waste of resources. The most visible example here is a track (which we left out from the discussion so far, but in fact is very similar to the route, especially from the implementation point of view)

3. When you add that new route point are you going to export that route to a file? Probably not. You're probably going to scrap it at the end of the race, right? So in that case it doesn't matter if you regenerate the guid.

guid is used as an unique identifier to the navobject. Designed to allow binding other information to it and, well, identify it internally as well. While for the later we could easily change it to your proposal (even though I think there is no reason to do it), the former would be lost.

4. What's the big deal about trying to conserve guids? The ITU X.667 recommendation for UUIDs (X.667*:*Information technology - Open Systems Interconnection - Procedures for the operation of OSI Registration Authorities: Generation and registration of Universally Unique Identifiers (UUIDs) and their use as ASN.1 object identifier components) suggests they can be used as transaction IDs. It's not like there's any shortage of them.
5. I wonder if perhaps you're trying to do two contradictory things with guids. On the one hand, you want to identify objects as belonging to OpenCPN. For that to work you need to generate a single guid for OpenCPN and use it to tag every object that OpenCPN "owns". On the other hand, you're trying to distinguish objects that OpenCPN is using. To do that you need a different guid for each different object. Could something along those lines be related to your reluctance to generate new guids?

Not at all, the reason for not regenerating the guid has nothing to do with the conservation of guids or shortage of them. My reluctance originates from the fact that regenerating the guid is in contradiction to one of the main points of the design - being able to (as) persistently and universally (as possible) identify each navobject to allow even more info (not storable in GPX) to be bound to it. The reasoning here goes far beyond being able to say OpenCPN created the object - that would be done in a different way if we needed it, which we don't.

The problem we have to solve is pretty easy. And would not be there at all if we were doing Open/Save logic in addition to Import/Export trying to supplement both the cases now (and currently having an error in the logic it uses). That's all the problem there is and the question is how to handle it. I'm really convinced that the solution is different than the one you propose though.

Pavel

[fgd3]

Originally Posted by nohal

Correct. But it is a bit of a semantic quibble Have a look at the GPX schema docs - GPX 1.1 Schema Documentation - especially the wpt, rtept and trkpt elements...

That's an excellent example of the point I made earlier that thinking about the problem the wrong way leads to a bad design. A route is an ordered list of route points (not waypoints) representing a series of intermediate destinations (not turn points--you can put multiple route points in a straight line) leading to a final destination.

Naming the basic point structure wptType was unfortunate. Things would be clearer if waypoints and route points had been defined as different types which inherit their characteristics from a common point type.

Originally Posted by nohal

A route point is just a property of a route,

That's the persistent error in your thinking that has led to this problem.

Originally Posted by nohal

there is absolutely no need to think of a route as a new navobject (and implement it that way) when one of it's properties changes. To say the least it would be an unefficient waste of resources. The most visible example here is a track (which we left out from the discussion so far, but in fact is very similar to the route, especially from the implementation point of view)

From an implementation and user interface perspective I agree that it is easier to reuse the existing route structure rather than create a new one every time a route is edited. But you need to recognize that's merely an implementation shortcut and take into account that the user has actually created a new route. If you're tagging routes with guids and you create a new route you need a new guid.

Originally Posted by nohal

guid is used as an unique identifier to the navobject. Designed to allow binding other information to it and, well, identify it internally as well. While for the later we could easily change it to your proposal (even though I think there is no reason to do it), the former would be lost.

Here again I see you trying to use the guid for two purposes which appear contradictory to me. Never once in this discussion have you brought forward a specific example of how the guid for a waypoint or route will be used for anything other than identifying the object internally.

Adding the guid extension to the .gpx files created two problems. The first resulted when you incorrectly computed guid. That required everyone to remove the guids from their .gpx files (by changing the "guid" strings in their files to "wrongguid" strings). The second requires anyone who wants use an existing route as the foundation for new routes to remove the guids from the affected .gpx files.

We haven't seen any benefit from the addition of guids to the .gpx files. There's vague talk about binding information to other objects but nothing specific. Perhaps the best thing for now would be to remove the guid extensions from the .gpx files until some actual need for them develops.

Originally Posted by nohal

The problem we have to solve is pretty easy. And would not be there at all if we were doing Open/Save logic in addition to Import/Export trying to supplement both the cases now (and currently having an error in the logic it uses). That's all the problem there is and the question is how to handle it. I'm really convinced that the solution is different than the one you propose though.

Pavel

It doesn't matter whether you call it "Import" or "Open". You'd have the same problem. When the user tries to import a route and it has the same guid as a route previously imported you don't allow him to import the route. When a user exports (whether you call it "Export", "Save", or "Save As" doesn't matter) a route you use the same guid it had when it was imported even though it is in fact a new route going to different locations.

I'm really convinced that the solution I proposed is exactly correct if you're going to continue exporting guids. If you eliminate the guid from importing and exporting the problem goes away by itself.

Fabbian