Bug description
Hello,
In superset 5.0 i have a value which is 38.7. But the scale max limit is calculated as 38 (instead of 39). So the polygone has not the good color of the legend (black instead of dark)
cf printscreen :
Screenshots/recordings
No response
Superset version
5.0.0
Python version
Not applicable
Node version
I don't know
Browser
Firefox
Additional context
No response
Checklist
- [x] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [x] I have searched the GitHub issue tracker and didn't find a similar bug report.
- [ ] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.
Comment From: dosubot[bot]
Hi @jpchenu! I'm Dosu and I’m helping the superset team.
The legend scale limits for deck.gl polygon visualizations in Superset are calculated by the getBreakPoints function, which splits your data range into buckets and rounds the limits based on the bucket size's precision. This rounding can cause decimal max values like 38.7 to be truncated to 38, which leads to the color mismatch you described. The logic does try to add an extra bucket if the max value exceeds the rounded value, but it doesn't always prevent this issue. There aren't configuration options in the UI to control this rounding—only the number of buckets and manual break points can be set, which may not fully resolve the problem for most users. The relevant calculation is centralized in the utility functions, not in the visual component itself.
You can see the calculation logic here.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other 
Comment From: jpchenu
erratum : legend (white instead of dark)
Comment From: jpchenu
I think there is a mistake in getBreakPoints fonction because max value (and min value) should be included in one of the 5 bounds.
Comment From: dosubot[bot]
You're correct—there's a limitation in the getBreakPoints function: it doesn't always guarantee that the min and max values are included in the legend bounds. The calculation splits the data range into buckets and rounds break points based on the bucket size's precision, which can cause the highest value (like 38.7) to fall outside the last legend interval, leading to the color mismatch you observed. This is due to how decimal values, rounding, and bucket alignment interact in the logic. The function tries to add an extra bucket if the max value exceeds the rounded value, but this doesn't always solve the issue. Manual break points can help as a workaround, but there's no UI option to control this rounding directly. More details are in the code here.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
Comment From: jpchenu
Will the feature be fixed ?
Comment From: jpchenu
Can you tell about that to superset team?
Comment From: rusackas
Sounds like a legit bug, but probably not on any of the core committer's current agenda. We'd welcome an investigation/fix if you're up for it, and are happy to review a PR.
@dosu feel free to provide some insights on how to resolve this in the codebase.