Bug in ENC `twoDepthShades` rendering

KennSebesta · ‎06-08-2021

It looks like there is a minor color fill bug when setting

EncEnvironmentSettings.displaySettings.marinerSettings.twoDepthShades = false

This should enable the four-color mode, which in particular should show a different color for areas below the shallow depth vs above it. However, I only get three shades and am missing the critical safe/shallow coloration.

The following images are taken from a viewpoint in the Boston harbor area, at 42.34, -70.99.

The first image is from a custom QML app:

The second image is from NOAA ENCOnline.

In the second image, the area between Safe and Shallow is colored differently from the area inside the Shallow contour.

The NOAA map is rendered using ArcGIS, so this points toward a coloration bug in the SDK itself. I don't have any experience with the other SDKs so can't verify if this behavior exists across all SDKs or is only in the Qt/QML one.

JamesBallard1 · ‎06-08-2021

Hi @KennSebesta ,

I cannot reproduce what you're seeing at https://www.nauticalcharts.noaa.gov/ENCOnline/enconline.html. Can you confirm if some other Maritime display properties are needed to display the four-color mode? Here's what I did (see screenshot from online viewer). At that long/lat the section in question displays identical to your Runtime screenshot.

KennSebesta · ‎06-08-2021

@JamesBallard1 thanks for the rapid response. I think the difference we're seeing is that NOAA ENCOnline sets different default depths. Here's what I'm using:

These are the same depths I have in my settings for my Qt app.

JamesBallard1 · ‎06-08-2021

@KennSebesta thanks for the info. I see what you're seeing in the online viewer now. I don't have the offline dataset for that region near Boston to display and troubleshoot with Runtime, but I do see that this is working as intended with the sample dataset.

Here's some code I added to test it:

Component.onCompleted: {
    // set resource path
    EncEnvironmentSettings.resourcePath = dataPath + "/ENC/hydrography";

    // load the EncExchangeSet
    encExchangeSet.load();

    EncEnvironmentSettings.displaySettings.marinerSettings.shallowContour = 1.8;
    EncEnvironmentSettings.displaySettings.marinerSettings.safetyContour = 3.5;
    EncEnvironmentSettings.displaySettings.marinerSettings.deepContour = 10.0;
}

MapView {
    id: mapView
    anchors.fill: parent

    CheckBox {
        checked: false
        text: qsTr("Two-color depth zones")
        onCheckStateChanged: {
            EncEnvironmentSettings.displaySettings.marinerSettings.twoDepthShades = (checkState === Qt.Checked);
        }
    }

(view in My Videos)

KennSebesta · ‎06-10-2021

So this bug is clearly sporadic. I'm trying to find a way to systematically recreate it. I can't quite figure out what's triggering it It might be setting other EncEnvironmentSettings.displaySettings settings, or maybe it's related to already having an instance of the ENC loaded into memory, e.g. if I'm running the desktop app multiple times simultaneously.

This is going to be hard to explain, so bear with me.

I have observed the following behavior:

INITIALLY...

With shallowContour at 1.81, I was able to make four colors appear by removing all additional EncEnvironmentSettings.displaySettings settings, beyond the four used in your post. I was able to add `EncEnvironmentSettings.displaySettings.marinerSettings.displayCategories.standardDisplay = true;` to provoke the system to fail to show four colors.

AND THEN...

I was no longer able to get all four colors to appear, not even by reverting to the prior known-good condition. I only got all four colors to appear by closing all instances of my app.

AND NOW...

By making shallowContour be 1.81, four colors fail to appear, but all four appear at shallowContour at 1.8. However, setting `EncEnvironmentSettings.displaySettings.marinerSettings.displayCategories.standardDisplay = true; `no longer causes the failure.

REPRODUCEABILITY

Yes, no, maybe-so? I have tried recreating it with the AddEncExchangeSet example, and so far that works perfectly every time. No matter `1.8` or `1.81`, or setting any other EncEnvironmentSettings, etc... So there is some critical difference between our two apps.

KennSebesta · ‎06-10-2021

Bit of an update. By grabbing the NOAA ENC for Boston Inner Harbor (https://charts.noaa.gov/ENCs/Agreement.shtml?US5MA11M), I can reproduce this with the AddEncExchangeSet example.

*Currently*, I cause the failure by toggling between `shallowDepth = 1.8` and `shallowDepth = 1.81`.

Curious, I went back to the NOAA ENCOnline viewer. It turns out that this display issue is reproducible in their online viewer as well. What's strange is that it's highly dependent on the exact values.

I'm not a big believer in coincidences. 1.80m = 5.906ft, 1.801m = 5.909ft, so there's no magic threshold being crossed in another unit system.

Playing around, I realized that 1.81 becomes valid once the safe depth goes above 3.6.

This might be a NOAA or S-57 thing, where 0.30m is approximately 1ft (although 1.8m is 5'10 3/4", not 6ft!), and all data is being forced into the closest foot bucket. That would be wrong, but considering the imprecision there might be nothing which can be done about it.

Likewise, with the ENC provided sample dataset, it looks like the settings have a similar effect, but for a different range of values. I'm beginning to think that what I'm seeing is an interaction with some underlying feature of the dataset which is subtle but relevant. (I'm learning here, so apologies for not understanding the full extents of the ENC's backend.)

Where this is a problem and winds up displaying bug-like behavior is with unit conversion. As my app's backend is in standard units, I convert any non-standard user units (feet or fathoms) into metric. So if a user inputs 5' 11" as the keel depth, this gets converted into 1.8034m.

P.S. This still doesn't explain the inconsistency I saw in my app, but I'm willing to chalk that up to make_clean hiccups.

JamesBallard1 · ‎06-10-2021

@KennSebesta thanks for the update. If you feel there's a Runtime bug here, please log an issue with support so we can follow up. There is a fair amount of complexity here, so we'd need to dedicate some time and resources to chasing this down further.

HydroExpert · ‎06-21-2021

@KennSebesta All screenshots in this thread are correct.

It isn't clear what your expectations are so if you can just post one screenshot that you think is incorrect and state why you think is incorrect I may be able to explain why it's like that. The relevant parameters are the 3 depth values and whether you are using 2 or 4 depth shades.

KennSebesta · ‎06-29-2021

@HydroExpert, I think after working with this a little while longer there is no programming bug, rather the problem lies between the expectations and the reality. The documentation is silent as to the fact that the depth contour lines are a hardcoded feature of the underlying data and thus cannot be adjusted by any ENC viewer settings.

I don't claim that the results don't make programatic sense-- they do--, however they do not make lay sense. As such, it would probably be a good idea to make it clear in the docu that the depth contour colors are not, by design, faithful to the depth contour color setting.