Animate queue length on activities

[lindeloev]

I would like to show queue lengths during playback and perhaps change the text of the activities or edges accordingly. For example, in the animate_process(patients, mode = "relative") example, it can be hard to see how many patients are actually started on an activity or between any two activities at a given time. I can think of two approaches to this:

• Specific: support something like animate_process(patients, activity_queue = TRUE, edge_queue = FALSE).
• Generic: support something like animate_process(patients, activity_show_latest_event_attribute = "queue_length") where queue_length is then an event attribute in the eventlog. The user can then code the queues into event attributes themselves - or any other attribute they may want to display.

We visualize an assembly lines where there are physical constraints on the number of tokens that can reside at a given edge. This feature would be great at visualizing bottlenecks and their causes.

[fmannhardt]

How would you want to show them? In theory you can change the shape parameters of a token at any time using the following approach:
https://bupaverse.github.io/processanimateR/articles/use-external-data-to-change-tokens.html
Maybe cases stuck in a queue could be shown as larger tokens?

Of course, this still has the overplotting issue which can be mitigated a bit by using the jitter parameter, but in the best case we would have something like merging tokens together such as in Fluxicon Disco or Fuzzy Miner in ProM.

Token merging is unfortunately not so trivial with the current rendering engine where each token is a separate SVG element and everything is precomputed as declarative SMIL animation.

[lindeloev]

I was thinking something like the Inductive Visual Miner from the ProM package. Here's a short recording using the patients dataset: https://youtu.be/4Czi4HguC4Q.

Mapping to token size is definitely a possible visualization. But I think animating it on the activities/edges makes more sense in two ways:

1. The queue length is a property of an ensemble of cases at a particular time and place in the model - not the individual case. So it may be better to visualize at the activity/edge than on the token.
2. Numerical info would be much easier to read. Some of our edges are capacity-limited and it matters whether they are full (bottleneck) or almost-full. It's hard to discriminate 50 from 60 cases. I think the tokens do not currently have a text aesthetic? (would be hard to read anyway)

In any case, thanks Felix for your great work on process mining in ProM and in R!

[fmannhardt]

This is being worked on in this pull request:
#33

Thanks to @lindeloev for making this possible.

[fmannhardt]

New PR: #35