Tentative Plotlylight Extension package

[ConnectedSystems]

Initial support for visualizations based on PlotlyJS via PlotlyLight.

Reason for this PR

Recently, the need to showcase some kind of results visualization to support RRAP-related work and future projects have been (re-)raised.

This PR provides an initial/tentative implementation of the scenarios visualization method.

I've elected to leverage Julia's extension package system to support a single plot type (scenario outcomes) using PlotlyLight given the issues outlined further below and the comparatively small visualization capability required. Analysts/Modellers can continue performing assessments "offline".

As it is an extension package, the usual workflow remains the same:

using PlotlyLight
using ADRIA

dom = ADRIA.load_domain(...)
scens = ADRIA.sample(dom, 128)
rs = ADRIA.run_scenarios(dom, scens, "45")

r_tac = ADRIA.metrics.scenario_total_cover(rs)
p = ADRIA.viz.scenarios(rs, r_tac)

Further Background / Context

In the early days of ADRIA there was a strong push for some kind of user interface.

Attempts had been made previously in MATLAB GUI before my time on this project. In retrospect I should have pushed back on the idea of a UI completely as ADRIA was not mature enough to support anything of the sort at the time. ADRIA was barely more than a loose assortment of scripts and the underlying programmatic interfaces were constantly changing. Updates to formalize contracts/interfaces would most likely break the UI. Not to mention a likely change in languages.

The second "attempt" after the initial migration to Julia was a web-based dashboard written in Python Plotly. I do not know why Python was selected, as Plotly had become available for Julia some time before this (although based on some reports I saw at the time, it had some issues). But an initial Python implementation had been written (see here).

To support the web dashboard an Oxygen.jl web service was set up. What was lacking was a mature analysis/visualization pipeline. At the time, the analysis/visualization interfaces had not yet been fully written (what is now the viz, metrics, analysis, submodules), so again, the visualization methods were essentially a loose assortment of functions/scripts except now spread in two languages and, at times, with duplicate functionality. I tried to put in some structure but doing this and working on ADRIA itself, it was all a bit much.

Scenario data was being served by Oxygen for processing in Python. The full scenario set needed to be passed to Python/JS to support specific types of analyses which required the full dataset. While the data processing itself was not so time consuming (although at times orders of magnitude slower compared to Julia), the constant data passing and conversion of scenario outcomes from matrices to JSON was horrendously slow.

After this, I made to call to switch to Makie given time/effort were better spent:

1. Maturing analysis and assessment capabilities
2. Address issues with the ecosystem model
3. Building interfaces to support interoperability with other RRAP models
4. Data processing would ideally stay in Julia given the comparatively high volume of data
5. There wasn't actually a strong need for a user interface or interactivity at the time
6. Packages like PlotlyLight didn't exist at the time.

I was also banking on community efforts to support interactivity (either local or web-based) in the Makie ecosystem would mature in the intervening time (from memory this was ~3 years ago).

Current state

The Makie ecosystem ADRIA depends on for visualizations, however, has not yet progressed to support client-side interactivity.
This was hoped to be done via WGLMakie and Bonito (then JSServe). While possible, WGLMakie requires an active Julia server/runtime to be running in the background for interactive 2D plots until functionality is ported across to Three.js.

Although we now have a fairly mature and stable set of methods to support analyses and assessments and a consistent set of visualization methods and a (semi)-standardized approach for their use, there are some concerns:

• Some methods have exploded in complexity (e.g., taxonomy vizualizations) and could use a revisit/rewrite
• The Makie package itself is quite a heavy dependency
• The Plotly ecosystem is more mature and has greater support across languages

If this extension package is accepted, I suggest we only port/re-create the visualizations needed. It may be that we don't need web-based interactivity for the vast majority of plot types in the short-term.

PlotlyLight was selected over PlotlyJS.jl as @arlowhite is a javascript aficionado and the Javascript API is more mature compared to the Julia one and would hopefully ease cognitive burden.

[ConnectedSystems]

@arlowhite @DanTanAtAims

See working example here:

https://github.com/open-AIMS/MADAME-api/blob/7e8b3ed98f8d7182722efe3f37c55468fdd19f55/src/routing/model_run.jl#L66