Waypoints Disappearing

[nohal]

Originally Posted by fgd3

By "display vs. route manager inconsistency" I think you mean the problem of existing waypoints disappearing when a route that uses them is hidden from view. Is that right?

By inconsistency i mean that the WPT is not displayed on chart, but it's shown as displayed in the route manager (and there's nothing the user can do about it now) That's what's the OP's problem and that's what I'm going to fix as I consider it to be a bug.

Pavel

[fgd3]

Originally Posted by nohal

By inconsistency i mean that the WPT is not displayed on chart, but it's shown as displayed in the route manager (and there's nothing the user can do about it now)

I understand now.

Routes and tracks have a field in the route manager to make them visible or invisible. Waypoints don't. Will you make visibility switchable for all waypoints or just those shared by routes?

There must have been a reason waypoint visibility wasn't made switchable. It certainly makes sense to me that waypoints should always be visible, lest the user keep dropping new marks where he already has one but has forgotten it because he can't see it.

Wouldn't it be better to just make the waypoints visible all the time?

Originally Posted by nohal

That's what's the OP's problem and that's what I'm going to fix as I consider it to be a bug.

Pavel

I went back and re-read all the posts in this thread. Actually the OP's problem was a lack of understanding of how routes work with shared waypoints. But I agree the disappearance of shared waypoints when the routes that use them are hidden is a bug. However, your fix doesn't really fix the bug, it just allows the user to switch it on or off.

In another sense, it isn't a bug at all. I think of a bug as a coding error that fails to implement the design correctly. In this case the design appears to have been implemented faithfully but the results are undesirable.

Fabbian

[nohal]

Originally Posted by fgd3

I understand now.

Routes and tracks have a field in the route manager to make them visible or invisible. Waypoints don't. Will you make visibility switchable for all waypoints or just those shared by routes?

The waypoint visibility is switchable the same way as routes and tracks - just click the icon in the first column.

There must have been a reason waypoint visibility wasn't made switchable. It certainly makes sense to me that waypoints should always be visible, lest the user keep dropping new marks where he already has one but has forgotten it because he can't see it.

Wouldn't it be better to just make the waypoints visible all the time?

I think it's much better to let the user decide what he want's to have displayed. The question might perhaps be when certain features' visibility is switched - There certainly are users like me, who prefer the shared waypoints to disappear with the routes and there certainly are users like you who think it should not be so. No way to please both at the same time.

I went back and re-read all the posts in this thread. Actually the OP's problem was a lack of understanding of how routes work with shared waypoints. But I agree the disappearance of shared waypoints when the routes that use them are hidden is a bug. However, your fix doesn't really fix the bug, it just allows the user to switch it on or off.

In another sense, it isn't a bug at all. I think of a bug as a coding error that fails to implement the design correctly. In this case the design appears to have been implemented faithfully but the results are undesirable.

The behavior I'm going to fix certainly is a bug. The visibility has to be settable even for shared waypoints which is not the case now.

Pavel

[fgd3]

Originally Posted by nohal

The waypoint visibility is switchable the same way as routes and tracks - just click the icon in the first column.

I didn't realize that. You're right. If waypoint visibility is switchable it should be switchable even for shared waypoints in a hidden route. Using the icon instead of a separate column is what threw me off. It is definitely wrong to have the route manager indicate the waypoint is visible when it isn't.

I noticed another inconsistency when experimenting with routes and waypoints. If I create a waypoint, then create a route which uses that waypoint the "Delete all" button in the waypoints tab won't delete that waypoint. But I can select that waypoint and delete it with the "Delete" button, which changes the route in which it was used. A waypoint can be deleted even if it is used in multiple routes.

Should you be able to delete a waypoint that is used in one or more routes without any warning?

Fabbian

[nohal]

Originally Posted by fgd3

I noticed another inconsistency when experimenting with routes and waypoints. If I create a waypoint, then create a route which uses that waypoint the "Delete all" button in the waypoints tab won't delete that waypoint. But I can select that waypoint and delete it with the "Delete" button, which changes the route in which it was used. A waypoint can be deleted even if it is used in multiple routes.

Should you be able to delete a waypoint that is used in one or more routes without any warning?

Fabbian

Good catch, I think we should at least issue a warning in such a case.

Pavel

[fgd3]

Originally Posted by nohal

Good catch, I think we should at least issue a warning in such a case.

Pavel

Do you know how many routes use a shared waypoint? Your warning could be something along the lines of "This waypoint is used in n routes. Are you sure you want to delete it?" (where you would supply the current value for n).

Fabbian

[nohal]

Yes, I can count them which is OK when deleting a single waypoint. A bit more complicated logic has to be used while deleting all...
We basically have a choice of
A) keeping the current behavior (shared not deleted at all) - logically incorrect as the user said yes to deleting ALL before
B) Issuing a new question "Some of the waypoints you want to delete are used in one or more routes, do you really want to delete them?" and in case of a yes delete all - I don't like this one as it brings new dialog window, needs more clicking etc.
or C) do the math in a advance and in case of shared wpts existence show a modified dialog giving the user all the options at once (delete just the ones not shared, delete all or cancel the whole operation). This one I like the most.

Pavel

[JesperWe]

Originally Posted by nohal

or C) do the math in a advance and in case of shared wpts existence show a modified dialog giving the user all the options at once

In which case I really need to do a common multiple choices radio button dialog class, since I just put two new similar dialogs into the code. I almost did it then, but was too lazy... Tell me if you go for that, and I'll do it.

[nohal]

Jesper...
In this case I think I can survive with a wxMessageBox with button style set to wxYES | wxNO | wxCANCEL
But I will sure find some use for it if it will be available

Pavel

[fgd3]

Originally Posted by nohal

Yes, I can count them which is OK when deleting a single waypoint. A bit more complicated logic has to be used while deleting all...
We basically have a choice of
A) keeping the current behavior (shared not deleted at all) - logically incorrect as the user said yes to deleting ALL before
B) Issuing a new question "Some of the waypoints you want to delete are used in one or more routes, do you really want to delete them?" and in case of a yes delete all - I don't like this one as it brings new dialog window, needs more clicking etc.
or C) do the math in a advance and in case of shared wpts existence show a modified dialog giving the user all the options at once (delete just the ones not shared, delete all or cancel the whole operation). This one I like the most.

Pavel

If you copied the waypoints into the routes instead of trying to share the objects that wouldn't be an issue.

How about adding a column "Shared in Routes" to the route manager and populating that column with the number of routes in which the waypoint is shared? Just seeing the numbers might warn some users away from the "Delete all" button.

The "Delete all" dialog box could simply include a reminder that "n routes using shared waypoints will be modified. Delete anyway/Delete only unshared/Cancel". The same dialog box would work for deleting a single waypoint since the number of routes would include only those which shared that waypoint.

Fabbian

[nohal]

Originally Posted by fgd3

If you copied the waypoints into the routes instead of trying to share the objects that wouldn't be an issue.

I really don't understand your obsession with this idea But as I said several times before: It will not solve anything. It would simplify a few things in the code if we said sharing is totally bad and we want to get rid of it. We don't want to say that. Well, at least I don't want to as I think sharing waypoints is a very viable feature and use it all the time.
That your particular way of using marks and routes is different really does not mean that the whole design is broken - we gave you freedom to use it your way, please leave us with ours...

How about adding a column "Shared in Routes" to the route manager and populating that column with the number of routes in which the waypoint is shared? Just seeing the numbers might warn some users away from the "Delete all" button.

The "Delete all" dialog box could simply include a reminder that "n routes using shared waypoints will be modified. Delete anyway/Delete only unshared/Cancel". The same dialog box would work for deleting a single waypoint since the number of routes would include only those which shared that waypoint.

Fabbian

What would the counting be good for except taking more space and giving me more work? As we both know, people don't pay attention even to what the programs explicitly tell them to pay attention to.
Even with the dialog requiring user to say "Yes, I really want to delete the shared waypoints and modify my routes!", there will be a support request "The program said something and now most of my routes are modified and all waypoints gone, help!" sooner or later...

Anyway, this thing is already done in my personal code tree in a way I consider improving the behavior, so more suggestions to change it AFTER the next beta when everybody knows what we are actually talking about, please.

Pavel

[kiltym]

I just wanted to provide another use case for the current "referenced" functionality as I am very much opposed to simply copying the Mark to the Route. This is something I do very frequently, and seems that others would also be doing the same thing.

1) In a cruising guide, you get a waypoint for a safe entrance to a harbor. You put this in OpenCPN as a Mark.
2) I then create a route from my current anchorage, to this harbor, re-using the Mark I created based on the cruising guide.
3) I also create a route, from this new anchorage, to the next place I am heading, again, using the same Mark in that Route.
4) I then go to the anchorage, and upon entering and anchoring, notice I feel I should have been in a slightly different place then recommended by the guide book. I compare my actual track to the route after I am anchored. I then make a decision to move this Mark to a slightly different position in OpenCPN.

This change in the Mark location I would want to effect the Mark, and any route that uses that Mark, as it does now.

If the Mark were copied to the route, I would be changing only 1 mark/waypoint, and also since they are all 3 stacked on top of each other, would have to do it 3 times also.

[Viking Sailor]

Originally Posted by kiltym

I just wanted to provide another use case for the current "referenced" functionality as I am very much opposed to simply copying the Mark to the Route. This is something I do very frequently, and seems that others would also be doing the same thing.

1) In a cruising guide, you get a waypoint for a safe entrance to a harbor. You put this in OpenCPN as a Mark.
2) I then create a route from my current anchorage, to this harbor, re-using the Mark I created based on the cruising guide.
3) I also create a route, from this new anchorage, to the next place I am heading, again, using the same Mark in that Route.
4) I then go to the anchorage, and upon entering and anchoring, notice I feel I should have been in a slightly different place then recommended by the guide book. I compare my actual track to the route after I am anchored. I then make a decision to move this Mark to a slightly different position in OpenCPN.

This change in the Mark location I would want to effect the Mark, and any route that uses that Mark, as it does now.

If the Mark were copied to the route, I would be changing only 1 mark/waypoint, and also since they are all 3 stacked on top of each other, would have to do it 3 times also.

Knowing what needs to be changed and making the change is a lot better then blindly allowing the software to change something that shouldn't be changed.

When arriving you had no problem adjusting your course to enter the anchorage safely. Before leaving you need to think about your departure and plan how you will leave the anchorage safely. Departure may not be via the same point that you used for arrival. So, now you have two routes, one for arriving and one for departing. And, they may or may not share a common waypoints.

If for no other reason then safety, each route on a chart should always be considered and planned independently. The inconvenience and additional work involved in dealing with each route is trivial. It is in fact a good thing as it requires the navigator to think about each route without prior assumptions.

[kiltym]

Originally Posted by Viking Sailor

Departure may not be via the same point that you used for arrival. So, now you have two routes, one for arriving and one for departing. And, they may or may not share a common waypoints.

Yes, obviously. If I am leaving by another entrance/exit, I would not use the same waypoint.

But most of the places I have been, I enter and leave through the same path, and in turn, some common marks among multiple routes.

It is good we can all decide what is best for themselves and the situation. You can easily say "No" to the question about using "Nearby Waypoint" while creating your route and do as you suggest. But, currently, if you say you want to use the nearby waypoint, OCPN doesn't offer the functionality quite correctly.

I was just offering another use case besides the racing example given in an earlier post.