Problem Marks or Waypoint behavior - Symbols - OpenCPN 3.0.2 , 3.1.814 beta exe, 3.1.

[rgleason]

Symptoms: Right click on certain Marks, popup does not show "Waypoint".

Double click on certain Marks and Object Query popup does not show Mark Properties, but Restricted Area or some other chart info. (Also selection of "Position" "Object Query" shows chart information, not the Mark or Waypoint, so there is no way to access the Mark Properties in that manner either.) (see Double-Click-Mark-Problem-Popup.png)

The only way to access Mark Properties for these problem Marks is through the main "Toolbox" by clicking on the "Route Manager" Icon, Waypoint Tab in the list, highlighting the waypoint and selecting "Properties" (see Double-Click-Mark-Problem-Access-Properties.png)

Symptoms Narrowed:
The problem occurs with one type of Mark named "NOAA Tide Prediction Little Narragansett Bay Entrance". Is it a malformed Mark? navobj.xml file at C:\ProgramData\opencpn looks ok and is attached.

Problem: malformed Symbol: Use of "Red Flag" symbol causes the above behavior ..someone's private joke? Don't use it until it is fixed. I'd like to know how to fix it. Problem symbol is located at C:\ProgramData\opencpn\UserIcons\Red Flag.xpm ( also attached but renamed as a .doc file to upload)

Thanks to Jesper for his help figuring this out to this point. Any additional help would be appreciated.
Rick

[rgleason]

Here is a partial navob.xml file

and the Red Flag.xpm symbol a doc.

[JesperWe]

Rick, I just downloaded your files and all seems fine...

I just had a small suspicion: Your icon is very big, and the select radius of OpenCPN will only hit it at a radius around it's center that is smaller than the icon itself. So for example the foot of the flag pole is outside the selection radius.

What happens if you click closer to the center of the icon? (center of bottom edge of the red part)

[rgleason]

I was picking near the exposed part of the flag pole most of the time, but I also picked within the flag and it did not work properly.

Now I see that this symbol has a very restricted area for selection and does not seem to work consistently between 3.0.2 and 3.1.814.

In 3.1.814 and 3.0.2 I can right click in the lower left corner of the red flag (1/4 of the flag) and I get a Mark/Waypoint or Waypoint choice to get to Mark Properties.

In 3.1.814 when I double click in the lower right corner of the red flag (1/4 of the flag) the Mark Properties box comes up.

In 3.0.2 when I double click in that same area (1/4 of the flag) it does not work properly. When I bring the cursor up just a little it seems to work.

I don't know how these areas are defined, but you say these symbols are large or perhaps oversized. Is there a click area within the symbol definition (probably not).

I suppose if the the standard clickable proximity to insertion point was enlarged that would slow down searches for objects too much?

I happen to think this is inconsistent behavior.

Thanks very much for helping me out.

[rgleason]

I opened it in Notepad++ and it is a text file!
Is there a place where there are some instructions?

24x24 pixels?
I'll guess the ff0000 is red and that is repeated by the multiple #a"'s. So what is the shaft?

/* XPM */
static char *dummy[]={
"24 24 3 1",
". c None",
"# c #000000",
"a c #ff0000",
".......###############..",
".......##aaaaaaaaaaaa#..",
"......##aaaaaaaaaaaa#...",
"......##aaaaaaaaaaaa#...",
"......##aaaaaaaaaaaa#...",
".....##aaaaaaaaaaaaa#...",
".....##aaaaaaaaaaaa#....",
".....##aaaaaaaaaaaa#....",
".....##aaaaaaaaaaaa#....",
"....##aaaaaaaaaaaaa#....",
"....##aaaaaaaaaaaa#.....",
"....###############.....",
"...##...................",
"...##...................",
"...##...................",
"..##....................",
"..##....................",
"..##....................",
"..##....................",
".##.....................",
".##.....................",
".##.....................",
"##......................",
"##......................"};

[sinbad7]

Upon creation I always make sure the transparent background center match the center of the icon in order to avoid having to search for the icon center when clicking a waypoint. Icons can sometimes have irregular shapes. i.e. the foot of a lighthouse.

Tore

[HappySeagull]

Rgleason.

# is black because it's colour is 000000
a is red .....ff0000.
both are Hexadecimal ? I think, eh? You might be more used to the 0,0,0 (=black) and 255,0,0 ( = Red )you will see in many image editors' colour pickers,palette tools what-have you...but the hexadecimal is often shown too.
and,
. is the transparent portion.

All are defined in the "header"

so, anyways, ## 's are the angled shaft.

[HappySeagull]

Note what happened when I opened and saved your xpm in GreenfishIconEditor..

/* XPM */
static char *gleasonGFIE[] = {
"24 24 4 1 0 0",
"  c #000000",
"! c #FF0000",
"# c #FFFFFF",
"$ c None",
"$$$$$$$               $$",
"$$$$$$$  !!!!!!!!!!!! $$",
"$$$$$$  !!!!!!!!!!!! $$$",
"$$$$$$  !!!!!!!!!!!! $$$",
"$$$$$$  !!!!!!!!!!!! $$$",
"$$$$$  !!!!!!!!!!!!! $$$",
"$$$$$  !!!!!!!!!!!! $$$$",
"$$$$$  !!!!!!!!!!!! $$$$",
"$$$$$  !!!!!!!!!!!! $$$$",
"$$$$  !!!!!!!!!!!!! $$$$",
"$$$$  !!!!!!!!!!!! $$$$$",
"$$$$               $$$$$",
"$$$  $$$$$$$$$$$$$$$$$$$",
"$$$  $$$$$$$$$$$$$$$$$$$",
"$$$  $$$$$$$$$$$$$$$$$$$",
"$$  $$$$$$$$$$$$$$$$$$$$",
"$$  $$$$$$$$$$$$$$$$$$$$",
"$$  $$$$$$$$$$$$$$$$$$$$",
"$$  $$$$$$$$$$$$$$$$$$$$",
"$  $$$$$$$$$$$$$$$$$$$$$",
"$  $$$$$$$$$$$$$$$$$$$$$",
"$  $$$$$$$$$$$$$$$$$$$$$",
"  $$$$$$$$$$$$$$$$$$$$$$",
"  $$$$$$$$$$$$$$$$$$$$$$"
};

it changed all the symbols. They're arbitrary. Still looks the same though. There's actually a thread on icons.
http://www.cruisersforum.com/forums/...tml#post691003

[HappySeagull]

RGleason...ummm... maybe not "hexadecima"l. "HTML colour" is what irfanview calls 'em and it would know. I sure don't.

[rgleason]

Thanks for the thread, which I've read quickly and for the additional information about making and modifying Symbols - Icons.

From Moosemonkey post #50

Unfortunately, this is not possible within the icon properties. The icons remain the same size as you zoom in or out within OpenCPN. ...

So I wonder why a symbol such as Red Flag which I believe is 24x24 only has a responsive selection area of less than 1/16 that pixel area? Doesn't the search work within the 24x24 pixel area, even though there are transparent pixels within those bounds?

Happy Seagull thanks, I'm going to try greenfish editor too.

[JesperWe]

This is the way it works: The selection area is defined as an 8 pixel radius around the lat/long point of the mark. There is no way to change that inside the icon definition file.

Exactly where the graphical icon ends up relative to this point depends a bit on how big it is. For a 16x16 pixel icons (like the ones that come with O) it is the center at pixel 8x8. For other icons it should be the center of the defined bitmap, which of course might be different from the visually perceived center (especially if you have lots of transparent pixel margins).

Changes in the mark icon code between the releases might have shifted the exact point slightly, but it shouldn't be by much.

[rgleason]

Thanks, that's the answer I guess, selection area is independent of transparency.
Selection Area = 8 pixel radius
Normal Symbol Area = 16 x 16
Red Flag Symbol Area = 24 x 24

So we either should:
1. Not make or use big symbols, larger than 16 x 16
2 Ask for the selection area to be the pixel area of the particular symbol, if that can be done and makes sense to do so without causing processor delay.

[JesperWe]

It's not so much the CPU load as the fact that the selection code has no clue about the bitmap used to represent the mark visually. It just knows the marks lat/long. The mark does not have the concept of area to it. It's a point.

So making mark selection operate on an area defined by the icon is more than a few hours work...

[sinbad7]

rgleason..

What kind of bitmap is giving you problems... obviously a transparent one..?
Perhaps the new code only accepts certain type of bitmaps?


Jesper..

Any solution yet to the Toolbox crash in the Win7 version?

Tore

[rgleason]

JesperWe,

I understand, it requires finding and reading the xpm file, 3rd line for the w x h pixel. The user database at c:\programdata\opencpn\navob.xml (on my computer) has each mark's position and icon symbol file name, so that would have to be opened and certain records and fields read. This requires opening and reading two files for each proximity double click or right click. Nowadays that's not a great burden, however it is undeniable that it would require more programing.

I think of our CAD program's database and the many varied user defined symbols and files that it has open all the time, and doing real-world scaling and scaling other symbols such as text to print scale, and I know this can be done sometime, somehow (scaling the selection area to the size of the symbol). -Perhaps even taking the average of the width and height and using that for the radius.

The reason I think the proximity double and right click would be a good thing to improve on at some point, is that to some users trying to double click or right click on a mark, lets say it is 24x24 and it therefore has a smaller target area of 8 pixel radius, at some tense moment in bad conditions, this behavior would be worse than irritating. -Please believe me, even in good conditions, the Red Flag symbol target area is too small (I never, for the longest time, was able to get Mark Properties up, until I accessed through the Route Manager.) Once I got into it, I found out how small and difficult the select area is. This may seem like a small thing, but it boils down to user expectations and the possibility that you might need the position information quickly.

Sinbad7, its "Red Flag", an oversize 24x24 graphic. The transparency bits are not the issue, the xml and other details are described above in the first post I believe.

I am not suggesting this be done right now, but I think it should be scheduled for some improvement.

JesperWe and others thanks for all your help in understanding the behavior.