Open iantei opened 2 months ago
Some possible solution and checks which can be incorporated to handle this issue:
Use colors.get(label)
instead of colors[label]
, this would return None which would result in matplotlib using a default color. The issue with this is this might obscure the case like this where the color mapping is not handled properly.
bar = ax.barh(y=bar_label, width=mode_prop, height=bar_height, left=bar_width, label=values_to_translations.get(label, label), color=colors.get(label))
Add ['other'] in the list of mode_values
. When this 'other' cannot be traced into the labels["MODE"], it will defaulted to use the dedupe_color of "UNKNOWN"'s color.
mode_values = ([mode["value"] for mode in labels["MODE"]] + ['other']) if "MODE" in labels else []
purpose_values = ([mode["value"] for mode in labels["PURPOSE"]] + ['other']) if "PURPOSE" in labels else []
replaced_values = ([mode["value"] for mode in labels["REPLACED_MODE"]] + ['other']) if "REPLACED_MODE" in labels else []
Since this other
doesn't have baseMode
, would it be appropriate to use "UNKNOWN"'s to represent this?
For all the current deployment custom-labels including default label-options , label-options.json's MODE has "value":"other"
EXCEPT ca-ebike for which it is "value":"other_mode"
The issue is happening because of the dependency on the list of keys of MODE from the deployment-custom labels.
We are mapping the
colors_mode
andcolors_replaced
in the following way:This way, colors_mode will have the mapping for
other_mode
:[color_palette_number] retrieved from the BASE_MODES, but will not have any mapping forother
.We generate
other
label to merge all small entries. Therefore, when we call the below function:It can't find colors['other']. Therefore, resulting in the issue observed above.