fix: IndexError associated with HeatMap

[spacetimeengineer]

I use this library to create a heatmaps on my acoustics application which lets me retrieve data on click. Unfortunately, I encountered an index error that caused the session to break when the x value was out of bounds. This patch makes the clicking outside of bounds a non-issue. It is just a small patch but for my applications it works great. I am just passing the fix along to you. Please feel free to do with it what you will.

[spacetimeengineer]

This code implements a patch to prevent IndexErrors that occur when clicking on heat map areas outside of the defined bounds.

[hoxbro]

Likely also needed for y.

Can you share a minimal, reproducible example (MRE)?

[spacetimeengineer]

To reproduce my error, you'll need a test .nc dataset file, which I can provide. These files are approximately 100 MB, and I'm not sure how or where to send them. After obtaining the file, you'll need to open it using SoundScope and run the main script from this repository: SoundScope GitHub.

It may take me some time to isolate this issue from the application for a minimal example. Please let me know how you’d like to proceed.

[hoxbro]

I think it should be possible to reduce the files to synthetic data.

[spacetimeengineer]

Regarding y, I haven't encountered that issue myself, but it might be worth exploring. You can reproduce the problem in another application by clicking the color bar on the heatmap legend and checking the logs. The x value will consistently be out of bounds. While this may not cause widespread issues, it does affect a specific data loading system I've implemented, resulting in improper loading of records associated with each cell. To observe this, click the color bar in the legend when an on-click watcher is set up like this:

watcher_heatmap = heatmap_tap.param.watch(
    callback_heatmap_selection, ["x", "y"], onlychanged=False
)  # Watcher for heatmap tap events

[codecov]

Codecov Report

Attention: Patch coverage is 20.00000% with 4 lines in your changes missing coverage. Please review.

Project coverage is 88.76%. Comparing base (0d97cb0) to head (25f9735).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
holoviews/plotting/bokeh/callbacks.py	20.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6438      +/-   ##
==========================================
- Coverage   88.76%   88.76%   -0.01%     
==========================================
  Files         323      323              
  Lines       68678    68681       +3     
==========================================
+ Hits        60962    60963       +1     
- Misses       7716     7718       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[spacetimeengineer]

Ill see what I can do.

[spacetimeengineer]

I’d like to take a moment to appeal to you regarding this fix. While I don’t have a direct personal stake in this matter, I’m confident that implementing this change—or something effectively equivalent—would be highly appreciated by many users. Addressing this issue, whether through this merge or a similar approach that resolves the affected execution path, would have a meaningful positive impact.

For context, I attempted to replicate the issue in a simplified script using your latest documentation, and everything worked flawlessly—commendable work on that front! However, the codebase I’m working with seems to trigger this error in a deeply nested scenario that’s difficult to isolate without sharing a significant portion of the project.

A bit of background: I was hired to lead the development of this project, which I didn’t initialize. Consequently, I’m unfamiliar with some of the earlier development artifacts that may be contributing to this error. The project uses Holoviews as part of a complex infrastructure spanning multiple repositories, originally developed by marine scientists. Diagnosing and isolating the root cause within this intricate setup is beyond my capacity and the time remaining in my contract.

The challenge is compounded by the fact that the project is actively growing. As I prepare to step away, others on the team will need to manually apply this fix—or something similar—after every commit to avoid disruptions. We avoid forking your code because we value absorbing the ongoing features and improvements you add.

I understand this is a challenging situation, but I genuinely believe implementing this fix (or an equivalent solution) would benefit a broad range of scientists and other users who may face similarly complex, hard-to-reproduce issues. Thank you for taking the time to consider this!

[hoxbro]

Don't worry the fix will be part of the next release.

Haven't done anything since the last thing I heard from you was that you wanted to provide a MRE.

[spacetimeengineer]

I know! and I did and I gave it my best shot and waited as long as I could because I thought it was the right thing to do. I also didn’t want to impose. Unfortunately, I couldn’t get it done in time. I am only getting back to you now. Regardless, this is wonderful news. Thank you!