Latest Contributions by KennSebesta

@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. ... View more

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. ... View more

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. ... View more

I haven't had a chance to try this yet, but I see it has some potential as a workaround. The immediate limitations I see are 1) needing ~100 bins/buckets-- not just 3-- in order to have a seamless color transition and 2) the need to re-bin across the entire dataset in case the color end-points are changed. But in a pinch, it should work. Ideally, something like HeatmapRenderer would exist for lines. It would be far simpler to be able to update color endpoints and have the renderer take care of the work. I will try to schedule some time to implement the workaround. There's enough complexity that I'll want to write a decent API so that the end programmer interacts with it like s/he would see HeatmapRenderer. ... View more

@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. ... View more

Marvelous! I've started integrating this into my code and am excited by the results.   P.S. IMHO, it's worth building an additional SDK example purely to highlight your code. In part because it's so useful and yet so simple, and in part because the bit of code in the `for j=...` block requires a very high degree of familiarity with the SDK. ... View more

Good thinking. I believe that particular issue has been resolved, but I'll try it with a mouse just to be sure. The issue improved on my computer when I freed up resources, so I feel this points towards a resources  limitation. However, on this same computer no other map displays this problem, and on a brand-new iPad Pro the tiling behavior I describe above is still present (although the system is fast enough that it's merely noticeable, and not an impediment). This hints that the underlying viewer might not be optimized for anticipating user inputs. ... View more

@JA , thanks for the rapid response. Indeed, I was able to make the ENC example work in my application and just came back from using it on a 4 days' sail on the open ocen. The SDK performed admirably, and was our go-to solution when the B&G chartplotter continuously crashed (leaving the autopilot on and the crew locked out, but that's a story for another day). We're very impressed by the suitability and stability of Qt and ArcGIS. Now we'd like to do something very similar to the use case described by the poster in the Java SDK community. Effectively, we'd like to know how far a boat is from running aground. This would be very easy with the geometry engine's intersection algorithm, but first we'd need to extract the local depth contour-- i.e. identify the Safety Contour Line and turn its geometry into an ArcGIS object. ... View more

That certainly does look very good. Which Android device were you using? I tried it on a 2021 iPad Pro 12.9" and it works equally well to your example. My issues might be platform dependent, and in particular RAM-constrained platforms. (I.e., I should close out all the Chrome tabs and see how repeatable it is. : ) I guess a feature request would be to have some tuning params for ENCs. Even though tiles load quickly on our mobile platforms, they still have a loading delay and this seems like something which would be preferable to avoid. On faster platforms, I'm sure the user would appreciate the benefits of preloading neighboring tiles, and not dropping from memory the immediately prior tiles. ... View more

Yes, I see similar performance delays when using that dataset. Although I want to be clear that the delay is not consistent, it is highly dependent on the zoom level, with it slowing down the deeper the zoom. It also somewhat feels like it might be a function of how much data is in the ENC and how much of that data is visible in the viewport. I suspect your MacBook Pro might be substantially faster than my MacBook Air. Have you gotten a chance to try it with mobile? As it stands, on my computer it is not be possible to rapidly scroll and pause at a feature of interest. Instead, I have to pause scrolling every page-width in order to allow the screen to regenerate. Is there no way to adjust the caching? In particular, is there no way to keep already-rendered screens in memory?   ... View more

Thanks, that makes perfect sense. I think what tripped me up is not knowing what "good" looked like in the context of that example. An ENC being simply a geo-referenced dataset, it wasn't clear that successfully loading it was going to lead to a visualization. So when I ran the example and nothing happened, I was wondering, "Is this right? Is this wrong?" In order that others not suffer the same problem, I would strongly suggest that the example includes all files required to run it, esp. a sample ENC dataset. I was really struggling with the program because I didn't even realize things were going wrong, until I found https://community.esri.com/t5/arcgis-runtime-sdk-for-qt/trouble-getting-my-widget-to-display-an-enc/m-p/619973. This was a canonically good example which included everything required[*] to run and so I was able to get stuff sorted out.  [*] taking into consideration your comment that the system automatically looks for the hydrology files in the SDK. ... View more

Thanks. FWIW, you might check out https://community.esri.com/t5/arcgis-runtime-sdk-for-qt/enc-fails-to-load-with-error-message-quot-invalid-argument-quot/m-p/1061268#M4164 for an issue with that implementation. ... View more