Unwanted marks circles

[Didier B]

Originally Posted by did-g

Easiest is to replace every number with a value not 0
like
<opencpn:waypoint_range_rings visible="false" number="3"

in navobj.xml
and navobj.xml.changes


with
<opencpn:waypoint_range_rings visible="false" number="0"

And ask Jon Gough what he intended.

Currently if the number attribute is not 0 rings are always displayed after editing a waypoint.

Done,

found over 100 occurences in navobj.xml
and ove r20 in navobj.xml.changes


tanks !

[hsi88]

I just installed V5.0 and a few of the new plugins (Squiddio, etc). Range rings appeared around all the Squiddio waypoints. With the instructions I was able to turn them off. I did not touch any options at all. This started as a result of the new install. Just a FYI.

[reflectionsv37]

This is definitely a bug. After installing the 5.0 in parallel I had the same thing happen with my existing waypoints. Mine were 1 ring with 1 mile range. After some research, I discovered that the default was set in the new feature in the settings file. This default appeared to be applied to all existing waypoints. But the change did not immediately take effect. Only after calling up a a waypoint and updating it(simply clicking ok rather than cancel) the range ring appeared.

These waypoints were imported from a file that was previously exported by 4.8.6. Checking that file confirmed that they were set to zero, zero at time of importing. Exporting the 5.0 file confirmed that all waypoints were changed to 1,1 after the update.

I am certain that I did not change the default settings for waypoints. I know others who have experienced the same thing. This is a bug.

[cagney]

There must be something more to this problem than just importing 4.8.x objects into 5.0.0. I tested with exported gpx files of tracks, routes and POI:s created about a year and half ago and found not a single circle when imported. I never used circles around marks at all. Perhaps it shows up only if you already have circles on some imported marks?

Thomas

[reflectionsv37]

I may not have been clear. The waypoints had already been imported into 4.8. They were present when I upgraded to 5.0. When I initially started 5.0 there were no rings showing showing on any waypoints with the exception of some anchor marks I had dropped and intentionally placed around. Those were 3-4 rings spaced at .01nm.

Terry on Valhalla had told me that there was an issue with 5.0 where range rings showed up on some of his waypoints. I checked a couple of my waypoints, and sure enough, the range rings were set to 1 ring with a spacing of 1 mile. I clicked cancel and the ring still didn't appear. I thought that was unusual and called the waypoint back up and clicked OK. After I clicked OK the range ring appeared. I check a few more waypoints and the behavior was the same. This matches up with what others are saying above about the rings appearing once a waypoint is updated. I think a key point here is that the waypoint had the range rings specified in the waypoint properties but they were not showing until the waypoint was updated.

In my situation, I discovered the default for waypoints was set to 1 range ring, at 1 mile, colored red. All of my waypoints were set to the default. I assumed that the default was probably incorrectly set to 1 ring, 1 mile and red during the installation and during the installation, that default was applied to all waypoints in the file that did not have range rings set. Were talking about 450 waypoints.

To correct this I exported the waypoints and used a text editor to first count the number of waypoints affected, every waypoint had the rings set, and then performed a find and replace to change them to zero. At the same time, I also added the necessary text to limit the scale on the chart for the waypoint to show. I deleted the existing waypoints and then imported the updated file and everything was correct.

Whoa! Wait a minute. I just went back into 5.0 and the range ring code is back in the waypoint properties again. I deleted all the waypoints. Shut down 5.0. Open 5.0 again and imported the file again. Even though all waypoint properties in the imported file are set to false, they import with the coding set to true, but don't display until updated. I have no idea what is going on.

I'll export a sample of these waypoints for testing. Stand by.

[did-g]

Hi,
It's now a known bug, with setting rings number to zero the only workaround.


For the next O version either the visible parameter will be back in the dialog box or the functionnality will be removed, ie on load if visible false set rings number to zero and don't save visible attribute.

[reflectionsv37]

Okay! I think I have an idea on what is going on. Looking at my waypoint files from a prior versions, the waypoint rings are all coded as

<opencpn:waypoint_range_rings visible="false" number="1" step="1" units="0" colour="#FF0000" />

All of these were created in prior versions of OCPN. It appears that they don't show after the update to 5.0 because "visible" is set to false even though "number" is set to 1. After an update "Visible" gets set to true and the range ring shows up.

I have no idea how "number" was set to 1 in my waypoints. I certainly didn't set so it must have defaulted to that from somewhere. Perhaps the .ini file?

In any event, that appears to be what is happening, but I'm not sure how you fix it for everyone. It doesn't appear that the visible flag is controllable so I guess you could make a pass through waypoints and set "number" to 0 for any waypoint that has "visible" set to false.

[rgleason]

though all waypoint properties in the imported file are set to false, they import with the coding set to true, but don't display until updated.

with
<opencpn:waypoint_range_rings visible="false" number="0"
And ask Jon Gough what he intended.
Currently if the number attribute is not 0 rings are always displayed after editing a waypoint.

All of these were created in prior versions of OCPN. It appears that they don't show after the update to 5.0 because "visible" is set to false even though "number" is set to 1. After an update "Visible" gets set to true and the range ring shows up.

Note:

Ocpn_waypoint properties are different than O waypoints and Ocpn_waypoints are stored in a completely different ODnavobj.xml file located here C:\ProgramData\opencpn\plugins\ocpn_draw_pi\data
Ocpn_Draw has its own import export functions for OD waypoints, so lets try to be careful clear about what is happening here. Does this effect occur with both O waypoints and Ocpn_Draw waypoints?


I believe it involves just opencpn waypoints and navobj.xml and involves the default settings in the new waypoint extensions. Why can't the imported file's properties for each waypoint be used such that there is no change in visible appearance? I would think that would be the original intent.

[did-g]

Originally Posted by rgleason

Note:
Ocpn_Draw has its own import export functions for OD waypoints, so lets try to be careful clear about what is happening here. Does this effect occur with both O waypoints and Ocpn_Draw waypoints?

I believe it involves just opencpn waypoints and navobj.xml and involves the default settings in the new waypoint extensions. Why can't the imported file's properties for each waypoint be used such that there is no change in visible appearancne? I would think that would be the original intent.

Hi,

AFAIK it's only O waypoints but it was written by Jon. I asked him and something was lost in latest O WP dialog box re design.


So do we want the ability to keep around number of rings with an option for displaying/hiding them, or setting the number to 0 is enough?

[reflectionsv37]

The first quote you listed of mine was incorrect. My fault. There is no way to know the status of the visible flag in 5.0 as it is not an option for the range rings that you can set. I am assuming that, internally, this flag is being checked to determine if a range ring is should be displayed since it doesn't show when the waypoint is first imported. If you export one of those waypoints after an update, the visible flag is set to true.

I am not talking about O_Draw waypoints. These are the normal opencpn waypoints. The problem is that sometime in the past waypoints were created with a default of range rings = 1 and visible set to false. This has changed in 5.0 If you look at properties in a 4.x version there is a check box for "Show Range Rings" in 5.0 it is gone and is now being set automatically based on the setting of number of range rings.

I have checked the import and an export of the same waypoint before and after an update. If range rings is greater than zero than an update sets the visible flag to true. Try it yourself!

Somewhere in the past, the default when creating a waypoint was to set the range ring visible flag to true and the number of rings to 1. This is creating a problem in 5.0 due to the visible flag being internally manipulated based on the value of range rings.

[reflectionsv37]

I can all but guarantee you somewhere in the update code of the waypoint properties exists the code...

If Number of range rings > zero
Set Range Rings Visible to True.

[bdbcat]

reflections37...


Pretty close, functionally the same...

    m_bShowWaypointRangeRings = (bool)g_iWaypointRangeRingsNumber;

Lets be sure this gets into Flyspray, so not forgotten.


Thanks for the persistence

Dave

[reflectionsv37]

My pleasure Dave!

I'll write it up and add it to flyspray tomorrow. It's getting late here in Malaysia.

If it wasn't obvious, I'm an old COBOL programmer!

[rgleason]

I always wondered...

AFAIK is a slang abbreviation ...It means "As far as I know" and is used to convey a lack of complete knowledge.

...range rings were set to 1 ring with a spacing of 1 mile. I clicked cancel and the ring still didn't appear. I thought that was unusual and called the waypoint back up and clicked OK. After I clicked OK the range ring appeared. ...the rings appearing once a waypoint is updated. I think a key point here is that the waypoint had the range rings specified in the waypoint properties but they were not showing until the waypoint was updated. ...default 1mile. 1ring, red ...default was applied to all waypoints in the file that did not have range rings set.

--So when importing navobjects don't apply the default! Accept what is in the file! ???

[reflectionsv37]

Rick, we seem to have some problem communicating. What is the point of most recent comment? I certainly have no idea, but it appears you still do not understand what is happening here.

--So when importing navobjects don't apply the default! Accept what is in the file! ???