5.8 Hidden Layers don't stay fully hidden

[SoggyPaws]

Hi all,
I've noticed this randomly but always thought it was me and not 5.8.
I have a LOT of layer files... peoples' tracks, waypoint files, route files, for about 6 different countries (we are in SE Asia, and looking toward the Red Sea next year).
I have at least 2 layer files that are completely "routes". These are hidden most of the time. But I notice random waypoints from those routes being visible in OpenCPN after a re-start. I check the layer setting, and it is still hidden. If I unhide the layer, I see the routes that that waypoint is/are in, and when I hide the layer again, the routes and waypoints are all hidden. But if I then, without doing anything else, shut down OpenCPN and start it back up, I see the waypoint again, but not the routes, and not all waypoints.
Here is one of the offending waypoints. It doesn't seem special.

<rtept lat="20.728457114" lon="37.208184188">
      <time>2020-05-02T16:23:36Z</time>
      <name>035</name>
      <sym>diamond</sym>
      <type>WPT</type>
      <extensions>
        <opencpn:guid>5b2bffff-5ce6-404b-a263-c6db19950000</opencpn:guid>
        <opencpn:auto_name>1</opencpn:auto_name>
        <opencpn:arrival_radius>0.050</opencpn:arrival_radius>
        <opencpn:waypoint_range_rings visible="false" number="0" step="1" units="0" colour="#FF0000" />
      </extensions>
    </rtept>

This is more of an annoyance than a big deal, but it could be a sign of something else...? Maybe I've overflowed something? A search of my layers folder in ProgramData\opencpn\ indicates I have 167 items (54 items (files/folders) at the top level of /layers and a bunch of gpx files in folders, ie "Red Sea Tracks" folder holds 5-6 track gpx files that are other cruisers' tracks).
I haven't tried removing most of the layers folders to see whether this is related to "too much stuff" or whether it is something else. Anyone else notice random waypoints from hidden layers showing up after a restart?
Sherry

[nohal]

Sherry...

I would probably first start looking for duplicates in guid and position across my library. The explanation will more likely be there than in anything else. But hard to tell from that single point, that of course looks absolutely normal.

[Antipole]

Sheery... run the Housekeeper JavaScript. This will check for many oddities, including duplicate guids.

From OCPN 5.8, that script will, by default, only check ordinary objects and ignore layers. However, you could simply change the OCPNgetGUID calls to get layer objects only or both ordinary and layers. See the JavaScript plugin User Guide for how to do that. This script is large and complex and not to be meddled with lightly. But those changes are very simple. After the analysis, the script goes on to offer to fix anomalies. If you have changed it to include layer objects, it will happily fix them but those fixes will not be saved and would be lost on a restart of OCPN.

It is, theoretically, possible to include a layer waypoint in a non-layer route. What then happens if the layer is hidden and the route is not? Below is a JavaScript that checks for crossings between layers and ordinary routes and points. The script runs for me but I have no crossings to check.

const ordinary = 0;
const layer = 1;
crossed = 0;
ordinaryPoints = OCPNgetWaypointGUIDs(ordinary);
layerPoints = OCPNgetWaypointGUIDs(layer);
ordinaryRoutes = OCPNgetRouteGUIDs(ordinary);
layerRoutes = OCPNgetRouteGUIDs(layer);

// check for ordinary routes including layer points
for (r = 0; r < ordinaryRoutes.length; r++){
	route = OCPNgetRoute(ordinaryRoutes[r]);
	for (p = 0; p < route.waypoints.length; p++){ // each ordinary route
		pointGUID = route.waypoints[p].GUID;
		for (c = 0; c < layerPoints.length; c++){ // each layer point
			if (pointGUID == layerPoints[c]){
				point = OCPNgetSingleWaypoint(pointGUID);
				print("Ordinary route ", route.name, " includes ", (point.isFreeStanding ? "waypoint ":"routepoint "), point.markName, "  ", point.GUID, "\n");
				crossed++
				}
			}
		}
	}

// check for layer routes including ordinary points
for (r = 0; r < layerRoutes.length; r++){
	route = OCPNgetRoute(layerRoutes[r]);
	for (p = 0; p < route.waypoints.length; p++){	// each layer route
		pointGUID = route.waypoints[p].GUID;
		for (c = 0; c < ordinaryPoints.length; c++){	// each ordinary point
			if (pointGUID == ordinaryPoints[c]){
				point = OCPNgetSingleWaypoint(pointGUID);
				print("Layer route ", route.name, " includes ", (point.isFreeStanding ? "waypoint ":"routepoint "), point.markName, "  ", point.GUID, "\n");
				crossed++
				}
			}
		}
	}
scriptResult(crossed, " crossings found\n");

[Antipole]

I have managed to create the crossed situation I envisaged.

1. Drop a waypoint and name it, say, Test Mark
2. Create a test route which includes the Test Mark
3. Export both to separate .gpx files
4. Delete both route and mark from OpenCPN
5. Add a temp layer by importing the test mark.
6. Import the route as an ordinary route (not layer)

You now have a route which includes an mark in a layer. You can move most of the route points but not the test waypoint.
Hide the layer and hide the route. Now show the route. The mark in the layer is shown, even though the layer is 'hidden'.
If you then hide the route again, the layer waypoint remains visible, even though its layer is hidden.

Run my crossings script. It reports the issue.

[SoggyPaws]

Antipole,
I follow your logic and this could be what has happened.
I will look at the waypoints and routes a little more closely.
Thanks for the link to your script, I will play with it.
Sherry

[wholybee]

I have found that having layers with lots of objects dramatically affects performance. Even if they are off. Rather than turning them off, I move the files to a separate folder, and only move them to the layers folder if I need them. It's a PITA, but seems to work better.

Not really a fix for your issue, but it wouldn't be an issue if you did it that way.

[SoggyPaws]

I finally took the time to run down the source of this issue. And am posting at least my solution here in case anyone else runs into the same thing.

The key to me was that the entire layer was not visible, just some parts of it. This is probably a bug but not a very big one.

I have a set of planning routes and waypoints that a friend made around late 2018. He exported his routes and posted them so others could take advantage of his planning (passage to the Red Sea from India). It is this layer, and another one or two that were created around the same time, likely with the same version of OpenCPN, that when this data is put in a Layer, and then the layer is hidden, and OpenCPN is restarted, some waypoints in the layer are visible after restart even though the layer is turned off. Turning the layer on (making it visible) and turning it off again, will hide these waypoints, as well as the rest of the layer, and they stay hidden until O is restarted again. I don't think this happened in 5.6.x, but maybe I just didn't notice.

What I found was that the waypoints all had a common (unusual) entry.

<opencpn:shared>1</opencpn:shared>

If I remove this line from each waypoint's definition in the layer gpx, then they behave normally. I have attached a zip file of 3 of these layers (with the "shared" waypoints still there) if anyone wants to play with it to see what I mean.

What I suspect happened was that a previous version of OpenCPN added this in the waypoint definition if a waypoint was used in more than one route. But I tried testing if it was still doing it by creating 2 new routes that used the same waypoints in 5.8.4 and I don't see this placed in the automatically-generated waypoints, even if the waypoint is shared between 2 routes. So it's not likely that many recent users would notice this.

I don't know why my first example waypoint in my first post doesn't have a shared line in it. Maybe I randomly picked the wrong waypoint to show as an example.

Attachment wouldn't attach as a zip, so change .pdf to .zip after downloading.

Sherry