How to add support for more recipes?

[juliohm]

I really enjoy AoG for statistical work, and would like to explore it for geometric work as well.

We have a custom Viz recipe in Meshes.jl that displays any collection of geometries with a color option. How to make it compatible with AoG? show_aesthetics shows zero methods for Viz Is there a documentation somewhere explaining how to add methods? The following code should work in theory:

data(geotable) * mapping(:geometry) * visual(Viz) |> draw

Related question

We define the recipe in a Makie.jl extension, so the Viz type is not exported by default. We can get access to it using Viz = Base.get_extension(Meshes, :MeshesMakieExt).Viz, but I wonder if there is a better way. The functions themselves (i.e., viz an viz!) are defined in the source without methods, and implemented in the extension, so they can be easily exported.

[jkrumbiegel]

One problem with mapping(:geometry) is that the separate scale mechanism only really works if there's one column per scale. The geometric overloads were added in a phase of AoG's development when it was still intended as a thin layer over Makie, basically just grouping and passing data on. Which you could of course also do with Vector{Polygon} etc. But this doesn't work for extracting scale names etc, that whole mechanism depends on one normal column per mapping entry.

[juliohm]

Sorry, I am not sure I understood the answer.

that whole mechanism depends on one normal column per mapping entry.

You mean we need a Tables.jl table with a simple geometry column? That is the case here. What are the extra assumptions about this column that AoG needs?

[jkrumbiegel]

No I mean, for each scale or aesthetic, like X, Y, Color, etc. you would want one column because the label is derived from the column name, scales can be passed via =>, etc. If you bundle aesthetics together, and that's essentially what a "geometric" column is, then you lose that. Currently that data doesn't go throught the scales mechanism at all so it just works if everything is float but units etc. would be broken I think.

The work I did for PumasAI was scoped pretty much just for statistical plotting so geometry was not a focus. I just tried to not break what was already working, but it's not well integrated.

[juliohm]

Got it. So from what I am getting, you are saying that the current support with visual(Poly) is kind of an exception to the rule, and that it might be removed in the future given the current scope of AoG. I like it that the package has a clear scope. At least people can set expectations on what features can or cannot be supported moving forward.

I will close the issue. Thank you for clarifying it.

[jkrumbiegel]

I'd be happy to improve it but I had no good ideas yet how to do that, given that the whole grammar-of-graphics concept is so column-oriented.