Cell space: Automatically visualise color attribute of Cells

[EwoutH]

Currently, you manually need to define how you are going to visualise the cells in a cell space in Solara. I think it would be very convenient, if Solara would automatically use the Cell.color attribute for visualisation. This color attribute can be any valid Matplotlib color.

[quaquel]

No, absolutely not. This would break the clean separation between the model and how it is visualized. We should really abide by the MVC pattern.

What if you want to use altair? matplotlib colors are not valid for that. So, you would need to map. What if you want to use plotly or a custom html5 animation? Again, you would have to map it somehow. MVC is an established pattern for UI design that exists for a very good reason and has been around for over 40 years.

[EwoutH]

That's a harsh stance.

My goal is to make visualisation of cell spaces more simple and straightforward, inspired by this discussion and a lab sessions I attended yesterday that dealt with a similar problem (coincidentally).

But honestly, and while you probably make valid arguments, it doesn't feel like a constructive or exciting setting to explore, path find, or find the root cause.

[quaquel]

Sorry for being blunt.

I understand and agree with your aim. The UI side of things needs further development. However, we should design this with care such that is expandable an done in proper way for all of MESA.

The issue here is broader than color-coding cells. We ideally also need meaningful defaults for agent portrayal and other parts of MESA models.

So, what is needed is a default "controller" layer in MVC language that the user can interact with or customize. This controller layer could have defaults for colors of cells, and the various visual elements of agents. If designed well, this can then be used by the different backends (altair, matplotlib, plotly?, others?) to render the UI.

[EwoutH]

Appreciated, thanks.

I’m curious how such a controller layer would look. One thought is that an additional layers could complicate or obfuscate the inner workings. Also, it could help with debugging if the visual representation of the Agent or Cell is present in the Agent/Cell instance itself.

For example, a user could make color or shape a fixed value, but also define it as a Python property, so it gets determined dynamically. If you visualize using matplotlib, you use their colors and shapes, and if you use Altair you use those. I’m not certain designing, building, explaining, documenting and maintaining our own translation layer for that is worth it.

But I’m open to explore both options further, and maybe we come up with something even better in the process.

CC @Corvince.

[quaquel]

Not sure yet. This issue is linked to a range of other outstanding issues and thoughts I have. First, there is #2437 / #2549, which are about the visualization of voronoi meshes. Then there is the open problem that we currently cannot visualize the cells in new-style networks. There is also the open issue of #2438 about the styling of grids. Moreover, I have been updating the sugarscape example, and here I am stuck that the current visualization of property layers allows you only to specify the visual encoding of individual layers but you can't mask out parts of the layers (As done in the current visualization code of sugarscape).

The common denominator across these is that the user, at points, might want to explicitly control how the space itself is to be visualized. At present, there are no good hooks for taking control of this in the space drawing functions. The space drawing functions focus on visualizing the agents in the space and make some assumptions here and there on how the space itself is to be visuallized.

A first step, thus, seems to refine the space drawing stuff to separate out more cleanly the visualization of the agents in the space from the visualization of the space. A logical solution for this would be to generalize

    if propertylayer_portrayal:
        draw_property_layers(space, propertylayer_portrayal, ax=ax)

to be something more like

    if space_portrayal:
        space_portrayal(space, a_bunch_of_callables, ax=ax)

We might even make it possible to pass your own space_portrayal function if you want full control, while having meaningful defaults as well. This space_portrayal function would break down into: visualize cells, visualize cell borders, visualize property layers.

[EwoutH]

We might want to branch into 4.0 and remove the old spaces. That would clean up a lot and also reduce branching options in the visualisation.

[quaquel]

We could also for now limit the space portrayal itself to new style spaces only.