Generalizing plots/guides and codifying multi-axis/multi-scale relationships

[mjskay]

Following up on a point in the discussion of @teunbrand's talk: I think there's an interesting question about how to construct a flexible and general approach for multi-panel coordinated charts (e.g. ones that share scales, or ones that highlight subsets / zoom in on parts of a chart, etc), perhaps one that blurs (or even eliminates) the distinction between a "chart" and a "guide". Put another way, is it possible to construct a general yet easy-to-use approach to create both multi-panel charts and guides within a unified framework?

Related to this, I have been trying to find a particular paper on generalizations of parallel coordinate plots and facets that I saw some years ago. This paper is one example of the genre (I don't think it's the one I am thinking of, but it's close): J. H. T. Claessen and J. J. van Wijk, "Flexible Linked Axes for Multivariate Data Visualization," in IEEE Transactions on Visualization and Computer Graphics, vol. 17, no. 12, pp. 2310-2316, Dec. 2011, doi: 10.1109/TVCG.2011.201 archived PDF

You can get the general idea from looking at some figures:

(it's worth noting some of these are probably more to demo the power of the abstraction than to suggest "good" plot types ;) )

I think there's something potentially very powerful at the intersection of a generalized multi-plot / multi-scale system and a generalized plot/guide system. Naturally it would be outside ggplot's current rendering pipeline, but perhaps an extension could make create its own rendering pipeline for it while making using of ggplot's layer abstraction (to support the existing ecosystem).

[EvaMaeRey]

Perhaps tangential, but I'm seeing pcp in the examples, and @heike and coauthors just added ggpcp to the ggplot2 extension gallery: ggplot2-exts/gallery#206 (with link to a paper)

[EvaMaeRey]

Cory's https://corybrunson.github.io/ggalluvial/articles/ggalluvial.html also comes to mind - looking at aesthetics axis1, axis2 axis3 etc... And the labeling is handled as a layer. @corybrunson

[corybrunson]

I've been meaning for years to incorporate Heike &al's hammock ribbons from {ggparallel} into {ggalluvial}! I don't fully understand them but i gather that they are more delicately put together to reduce biased readings.

[EvaMaeRey]

The approaches to like-in-kind arbitrary number of variables mapping is interesting. Deserves some eye emoji! 👀 👀 👀

aes_pcp() in ggpcp https://heike.github.io/ggpcp/

Had a peak at ggsankey too that seems to take a different approach from ggaluvial's axis1, axis2; more similar to the to_lodes_form .... Or the combine data manipulation |> ggplot() function discussed in #18 and some of the other options discussed there..

[corybrunson]

Oh neat—i do something similar in {ordr} with ord_aes() (or maybe aes_ord()). On my long list of low priorities is to make it work without duplicatively passing it the ordination model.(which was already passed to ggbiplot()), and it looks like they've figured out the solution for their case.

[teunbrand]

I don't really think this blurs the line between guide and chart, because in my mind, these are all different coord systems :)
Coords are in control over position guides and their placement, so I imagine the challenge is mostly getting the data parts correct. Just think of coord_radial() with a partial circle that will place the radius axis in all kinds of angles.

That said, I don't think these plots make for good data storytelling because it is hard to follow what is going on. If you want to understand some multidimensional relationship between datapoints then yes, you could use these type of charts, but you'll be a lucky plotter if there is one other person who can follow along.

Major limitation in ggplot2 currently is that x and y are hardcoded position aesthetics, which makes the implementation of these linked-axes, 3D or even 1D charts pretty gnarly. For a 1D representation you can think of a calender where there is 1 dimension (time), but you want to display it like a calendar so x is the day of the week and y is the week in the month.

[mitchelloharawild]

For a 1D representation you can think of a calender where there is 1 dimension (time), but you want to display it like a calendar so x is the day of the week and y is the week in the month.

I'm currently experimenting with nested coordinate systems (similar to ggh4x::facet_nested()) to accomplish this. Essentially the parent coordinate system (calendar) positions sub-coordinate systems (cartesian, polar, etc.) in a calendar arrangement.

It's early days, but I hope my ggtime talk in February can motivate some discussion on coord and position.

[EvaMaeRey]

And wrapper scale_discrete_manual()!

[mjskay]

The guides/coords/layer (subchart)? discussion is really interesting! I guess at a very high level I think guides from a functional perspective as decoding a viz channel.

Interesting perspective - as someone who doesn't use formal legends much (I usually prefer direct labeling) I haven't thought about that distinction before. I usually try to put information on how to decode something as close as possible to that thing, which is usually in the chart itself.

[EvaMaeRey]

It's early days, but I hope my ggtime talk in February can motivate some discussion on coord and position.

Really interested to see what you come up with. A coord, from a user perspective, sounds fantastic.

[EvaMaeRey]

I usually try to put information on how to decode something as close as possible to that thing, which is usually in the chart itself.

Maybe annotation/direct labeling should be added to 'guides' work. And legendry's axes and legends are a subset all the guide work that can happen. I do think it's a strength that ggplot2 gives us out-of-the-box legends and axes for exploratory work or plots that just require a quick turn around; and mostly admire folks that direct label and do custom and in-chart guidance work. 🙌

[heike]

Cory, I’m not sure how much the sine illusion (the illusion that makes the bands appear thinner in the middle, particularly when the bands have a steep slope) actually affects alluvial plots. All the bands start out at the same angle at both sides - that might be enough to counteract the effect. I guess it would be a fun study to try out! Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Cory Brunson ***@***.***> Sent: Wednesday, January 22, 2025 6:59:07 PM To: teunbrand/ggplot-extension-club ***@***.***> Cc: Heike Hofmann ***@***.***>; Mention ***@***.***> Subject: Re: [teunbrand/ggplot-extension-club] Generalizing plots/guides and codifying multi-axis/multi-scale relationships (Discussion #76) Caution: Non-NU Email I've been meaning for years to incorporate Heike &al's hammock ribbons from {ggparallel}<https://urldefense.com/v3/__https://heike.github.io/ggparallel/__;!!PvXuogZ4sRB2p-tU!FhpP6R50IfmT3CtMKmWHjdElCACn0ZK4eYwzoLQ7dIzr3KNy0H7ilFVPaxOrV0cD_OBcLed065WOwZYnOdjdY2-HNg$> into {ggalluvial}! I don't fully understand them but i gather that they are more delicately put together to reduce biased readings. — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/teunbrand/ggplot-extension-club/discussions/76*discussioncomment-11923263__;Iw!!PvXuogZ4sRB2p-tU!FhpP6R50IfmT3CtMKmWHjdElCACn0ZK4eYwzoLQ7dIzr3KNy0H7ilFVPaxOrV0cD_OBcLed065WOwZYnOdgjzgIucA$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AAAWVUQTPBA42PKAPL6544D2MA5FXAVCNFSM6AAAAABVT7UOESVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOJSGMZDMMY__;!!PvXuogZ4sRB2p-tU!FhpP6R50IfmT3CtMKmWHjdElCACn0ZK4eYwzoLQ7dIzr3KNy0H7ilFVPaxOrV0cD_OBcLed065WOwZYnOdg_E1SSpw$>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[corybrunson]

Hi @heike ! Thanks for clarifying. I'll need to re-read your hammocks plot paper. I'm interested in some other data viz literacy/bias studies too, and i'm game to collaborate. : )

[EvaMaeRey]

@corybrunson I tried reaching out to the @ggtern address but mail bounced back. I don't know if you had other ideas about how to reach out. Really like the message of the abstract, and does sound like a great fit for speaker.

In order to produce ggtern, it was necessary to overcome a number of design issues, such as finding a means to modify existing geometries designed for a 2D Cartesian coordinate system and permitting them to function in an environment that requires an additional spatial aesthetic mapping. In the present paper, we provide examples of this package in its most basic form followed by a demonstration of its ease of use, particularly if one is familiar with, and has a predilection towards using ggplot2 on a regular basis.

[corybrunson]

I finally had a brief look at the internals of {ggtern}. It's structured differently than i'm used to, but it looks accessible enough for someone to reconcile it with recent {ggplot2} updates and maintain it going forward, if Hamilton cannot be found. (CRAN will confer maintainer status to a new person if they reach out to the existing maintainer and don't hear back.) I have no plans to do this, and i hope Hamilton returns to the project, but i think it worth mentioning.

For the record:

• Here's the most recent snapshot of Hamilton's website from the Wayback Machine: https://webcf.waybackmachine.org/web/20230128170408/http://www.ggtern.com/
• Here's the Bitbucket repo for the package itself: https://bitbucket.org/nicholasehamilton/ggtern

[willgearty]

I've been using {ggtern} for ages, and my understanding is that it requires a LOT of work to maintain because it has a modified version of many {ggplot2} internals. It basically breaks with every single {ggplot2} update. Just something to keep in mind if someone is looking to take on ownership.

[teunbrand]

I'm not going to publicly rant about this, but here is some discussion from a while ago: tidyverse/ggplot2#3561 (comment).

[corybrunson]

Thank you @willgearty and @teunbrand ! I had not looked closely enough.

Are the two ways forward at the linked comment still generally agreed to be the only two? It seems weird that such a natural extension could not be rigged in a different way using a clever new coordinate system or other ggproto, together with a standard adaptation process applied to other ggprotos. But i've never contributed to {ggplot2} and could be way off base.

[teunbrand]

The issue is that the x/y position scales are hardcoded in mostly the coord/facet/layout infrastructure. It's not impossible to accommodate other scales (e.g. tidyverse/ggplot2#6080), but is very invasive to upend that infrastructure. It'd involve adjusting the formals of a bunch of ggproto methods, that almost never goes down great with reverse dependencies.