Open mkaulisch opened 1 week ago
Will check but use of such syntax where the lowest tier variable is determining the color is not advisable. All rows are unique in the model
and it is being assign a color for each row. Since the palette has fixed number of colors, and it is cycling through them (in a wierd way for sure).
If you switch the syntax to:
treemap weight, by(brand model rep78) ///
addtitles colorby(brand)
the output is more reasonable.
I tried this and I am puzzled:
encode model, gen(model_n) label(l_model_n)
recode model_n (1/20 = 1 "A-C") (21/53 = 2 "C-O") (54/73 = 3 "O-Z"), gen(model_nr)
treemap weight, by(brand model_nr) ///
addtitles colorby(model_nr) ///palette(hhu_color_fak) colorprop
name(brand_model_nr, replace) //
In my understanding of colorby() all three values of model_nr should have the same color across the brands. But they don't...
and in my real world example it leads me to the question whether I could also be able to control for the first layer colors if I want the second layer categories across the first layer to have the same color...
My example is that I have organizational units that contribute to different subjects and different units may contribute to one subject... Of course I can switch it and say which units contriute to the subject but I wanted to focus on to which subjects does a unit contribute...
like the example above would be:
treemap weight, by(model_nr brand ) ///
addtitles colorby(model_nr) ///palette(hhu_color_fak) colorprop
name(brand_model_nr, replace) //
will check tonight.
Currently, the colors are inherited from the topmost layer. For color variations within layers such that 2nd or 3rd layer categories have the same color implies re-writing the base color functions. I can think about in future releases which might take a while.
-colorprop- crashes treemap if colorby is defined as the second or third layer:
This code works:
This treemap-command crashes with an unintuitive error: