[3.0.2] Hotkey Issues

[nkiesel]

Hi,

very nice to have the hotkeys for toggling the map displays. Some suggestions/problems:

1. After turning off the lights, double-clicking does not show the light information in the object query. I think it should (i.e. the filter should only affect the map view, not the details view)
2. Some information (e.g. SBDARE aka "seabed area", and ground cables) are really only interesting when planning to anchor. Would be nice to have a hotkey for these as well (or perhaps combine with "rocks"?)
3. Lights hotkey also changes the buoy labels (from light description to object name). Most of the time (read: always unless it's night) object names are way more useful. Not a big problem anymore guess because I can just always switch off the lights.

</nk>

[JesperWe]

Originally Posted by nkiesel

very nice to have the hotkeys for toggling the map displays. Some suggestions/problems:

1. After turning off the lights, double-clicking does not show the light information in the object query. I think it should (i.e. the filter should only affect the map view, not the details view)

Glad you like it
I thought pt 1 was a really good suggestion, so that has been implemented.

[cagney]

Talking about lights in vector charts.....
There is a thing that worries me, but I don't know if there is anything at all to do about it.



Look at this raster chart.Look at the white sector to the NE of Kirkley light. It clearly leads through a safe channel to the entrance to Lowestoft Hbr.The sector is extended from the light through the critical part of the approach. It's absolutely clear what the purpose of the white sector is.



Now look at a vector chart. The sectors are only marked very close to the light. Where the sector is really helpful, there is no info at all, not even in the object query. It is not, without some work, clear what the white sector is intended for. The only thing i can think of doing, to help the situation, is to manually extend the sectors with some tracks.
I have checked other vector charts as well and this seems to be a general weakness.

"You always have the gps", someone says. Well, last time I was i Lowestoft some lights were built on rails to be easily moved as shifting sandbars required. This is a place where I, at night, would trust a white sector more than a gps and a one year old chart.

Can anything be done in OpenCPN, to improve the sector lights display?

Thomas

[JesperWe]

Originally Posted by cagney

Can anything be done in OpenCPN, to improve the sector lights display?

Not the first time this has been mentioned either.
I am sure it can, question is how hard it is.
Presently the sector leg lengths are hard coded to 25mm.
Not sure exactly why, lots of legacy code in that department....

[nkiesel]

Originally Posted by JesperWe

Glad you like it
I thought pt 1 was a really good suggestion, so that has been implemented.

Great. Now wondering about the other hot keys (e.g. my "A" for Anchor I submitted yesterday). Most of them completely hide the objects (e.g. rocks), so perhaps can be justified that a double-click on a hidden rock does not show the rock info in the details. But of course there is always a bottom, so perhaps I should add a similar logic to my patch. Other option would be to always turn off all filters for the details. Not sure if that would get too messy.

</nk>

[nkiesel]

Perhaps scale the sector leg length using the light visibility?

[JesperWe]

Originally Posted by nkiesel

Great. Now wondering about the other hot keys (e.g. my "A" for Anchor I submitted yesterday). Most of them completely hide the objects (e.g. rocks), so perhaps can be justified that a double-click on a hidden rock does not show the rock info in the details.

Yes I think so. LIGHTS is always attached to some other object (tower, buoy, beacon etc) so you know you are clicking on something that probably has lights. Showing random invisible objects does not seem like a good user interface philosophy.

[nkiesel]

Just re-built from git to test the "always show light information in object query window" and I first thought it was broken because more often than not it did not show the light properties. However after some debugging it turns out that I just clicked a few pixels away from the object. The confusing part of this was that all the other properties were shown (I tried with Point Conception light tower near Santa Barabara, CA).

Turns out the problem is that s57chart:oesLatLonSelectObject returns false. It has some special code for LIGHTS, and that seems to create a smaller pick box than the standard box used for all other objects. Was that intended or can we enlarge that box a bit?

[JesperWe]

No it creates a select region that is the same size as for all other point objects. Without that code the region would be the entire area covered by the sector arcs and legs (very large).

How lold was your github pull? The "Correct cm93 cell logic on Object Query." is an important fix for CM93 results, it might be that problem you are seeing.

[nkiesel]

Originally Posted by JesperWe

No it creates a select region that is the same size as for all other point objects. Without that code the region would be the entire area covered by the sector arcs and legs (very large).

How lold was your github pull? The "Correct cm93 cell logic on Object Query." is an important fix for CM93 results, it might be that problem you are seeing.

I respectfully disagree. Looking at the code, you construct a box of 2*select_radius width and 2*select_radius height around the light position, and then check if the clicked position is inside this box. For all other objects, you use the object's box and temporarily expand it by 2*select_radius in width and height. So basically lights are penalized of having an physical dimension of 0. I checked in the debugger and even the fog signal of a buoy has a width and height that is 2 times larger than the select_radius.

So perhaps of using 0 as box size, you could use the dimension of one of the closely related objects (obviously hand-waving here; I don't know S57 enough to know if a light even always has something it's attached to).

[JesperWe]

OK, true. The LIGHTS object in itself does not render, it's the sectors that do. Thus it has a box of 0x0 pixel. But the rendered area of the sector is too big so we have to shrink it.

Small explanation of how it works: There is no rule in S57 that says a light has to be attached to something, it is just an object with attributes for it's sector like everything else. In practice you will almost always have a tower or buoy at the same location, although I've seen occurrences of lights on many different things (including _extgn, which is kind of interesting...)

But there is really no way in the data to know what the light belongs to. And one light object is just one sector, so a multiple sector light is actually multiple light objects. And the database is not sorted so they are not even processed together. For example a tower might appear between two sectors or before or after, and there could be unrelated objects intermixed too.

I agree with you that lights get an unfair treatment. Since we do not know the BBox of the possible other object that the light "belongs to" from a user perspective, what we can do is give it a bigger radius so that it gets more even. Let's try 2 x select_radius and see if that feels better.