But, I'm not fully sure this does the right thing... I feel this is similar kind of problem that we wanted to map grouping variable of grouped_df automatically to group aes, but couldn't (#2378). Are there any smarter way to create mappings automatically?

So if we routinely mapped geometry columns, just like we do with all other data columns, the problem wouldn't exist. Maybe that would be good practice at least within all the ggplot2 documentation and examples?

The downside to your proposed solution is that it is not universal. If a data frame contains a column called geometry but that doesn't contain geometry info then it will break.

However, this got me thinking: Since this is a generic problem that may come up over and over, maybe we could solve it by adding a function such as setup_layer() to the layer ggproto and call it as the very first thing in ggplot_add(), like so:

This comment has been minimized.

I mean, there will be many variants of geom_sf(), which are outside of the ggplot2's scope (for example, I think I'm going to implement geom_sf_label_repel()). So, bundling the process into an internal function sounds smart, but it may not be really helpful for the extension packages of ggplot2.

Now I'm thinking I need something like fortify() for mapping. Let me think a bit more...

This comment has been minimized.

Anyway, this seems reasonable to me. May I create a PR to improve examples?

So if we routinely mapped geometry columns, just like we do with all other data columns, the problem wouldn't exist. Maybe that would be good practice at least within all the ggplot2 documentation and examples?

This comment has been minimized.

Thanks, it seems fine. But, what was in my mind was a bit different; yours won't cover this case:

I feel this is similar kind of problem that we wanted to map grouping variable of grouped_df automatically to group aes, but couldn't (#2378).

IIUC, requires us to create a new Layer (and new Geom and Stat accordingly) to handle a new object. So, if we want to map group variable automatically for grouped_df, we need to re-implement all of existing Geoms.

I think mechanism of auto-mapping should be an generic function because it depends on the class of object, not the type of the geom, in general. This may be too general, though.

I will send a PR that illustrates my idea...

This comment has been minimized.

I hadn't thought about the grouping issue, but I think it can be solved with my approach. The logic would be "if the data frame for this layer has grouping information and a group aesthetic is not set for this layer, then map the grouping information to group for this layer". This can be done in the setup_layer() function, and you could do it in the default layer object to have it happen for all geoms and stats.

The key idea is that there are things that we want to be layer specific but they depend on the global data frame and mapping, and setup_layer() has the required info to make those decisions.

This comment has been minimized.

I'm not sure whether a generic is the right approach, because one data frame could match multiple criteria (for example, both be grouped and contain a geometry column). It seems to me more akin to a checklist of conditions and corresponding actions on the mapping.

This comment has been minimized.

I'm happy to add auto-grouping to my PR, but I'd like to hear @hadley's position first. As it stands right now, the PR is essentially a bug fix, even if it adds a new extension mechanism. If we add auto-grouping, we're fundamentally changing how ggplot2 works and that's not appropriate for the upcoming bug-fix release.

One option could be to implement auto-grouping to make sure the API works and then disable it for the upcoming release. Alternatively, if Hadley thinks this whole approach of setup_layer() is a no-go, at least for now, then there's no point in pushing the code further at this time.