Mark geom_map() as superseded

[yutannihilation]

I believe we are already in the mood of moving away from geom_map() as geom_sf() almost superseded it. But, AFAIK, this hasn't been discussed formally so far. Considering we keep developing many codes around geom_sf(), I think it's good to mark geom_map() soft-deprecated before we face difficulties about the different behaviors between them.

Here I file this issue to discuss what functionalities are missing from geom_sf() and its related functions, which might drive people to fall back to geom_map(). Any thoughts?

Edit: to be clear, I don't think we can remove geom_map() considering its wide spread usages (so I chose the word "soft-deprecated"). Still, I believe we can discourage the usage of geom_map() to prevent further confusions by improving geom_sf() or providing some alternatives.

[yutannihilation]

One thing in my mind is map_data() for sf.

[microly]

geom_map can accept data.frame object, but geom_sf has to use sf object.

Before deprecate geom_map, I think #3659 , #3655 and #3654 should be accomplished.

[yutannihilation]

Agreed, those ongoing pull requests are definitely needed to replace geom_map(). Thanks.

[microly]

Maybe, sf_data() is needed to transform data.frame to sf for geom_sf(), just as map_data() did for geom_map().

It can be another solution for #3659 , #3655 and #3654.

As I mentioned, #3655 (comment), it is a issue about data, so just handle the data.

[yutannihilation]

sf_data() is needed to transform data.frame to sf for geom_sf()

Isn't this can be done with st_as_sf(coords = c("x", "y"))...?

[microly]

1.st_as_sf() can only output point(s), if the input is a data.frame.
However, the users may want to draw a line or a polygon.

2.Sf indeed supply more constructor, such as st_linestring and st_polygon, to create a line or polygon.
But it is too complicated for ggplot2 users, I think most of them are not familiar with the internal structure of sf geometry.

3.So, a light weighted and user friendly sf_data() would be needed.
It can only handle point, line, polygon and polygon with hole, this is enough for ggplot2 users because the geometry (points) and multiple geometry (multipoint) look the same in the plot.

it may be sth like:

sf_data(data, coords = c("x", "y"), crs = 4326, group = NULL, subgroup = NULL, type = c("point", "line", "polygon"))

data, a data.frame
coords, just like the coords for st_as_sf
crs, coordinate reference system
group, for creating a line or polygon
subgroup, for the hole in the polygon, just like geom_polygon
type, sf geometry type

This is a tentative suggestion, please forgive me if it is wrong~

[clauswilke]

@microly I agree with your general thoughts on this, but I'd like to propose a different approach: How about a geom_map_sf() that takes exactly the same inputs at geom_map() but then converts everything into the sf framework?

[yutannihilation]

1.st_as_sf() can only output point(s), if the input is a data.frame.
However, the users may want to draw a line or a polygon.

Ah, makes sense. But, I'm a bit skeptical about implementing it in ggplot2. IIUC, in the pre-sf days, we needed to define ggplot2's own convention about the map data and provide the utilities (like various fortify() methods) for this. So, I feel something like sf_data() should belong to sf (or some sf extension package).

How about a geom_map_sf() that takes exactly the same inputs at geom_map() but then converts everything into the sf framework?

Sounds good. But, isn't it possible to convert data.frame transparently in Layer$setup_layer() (when some option like convert = TRUE is specified) so that we don't need another geom?

[microly]

@clauswilke
Wonderful idea!

@yutannihilation
I think it could be done in the stat step.

[yutannihilation]

I feel the geometry column should be determined before stat. Probably it also can be done in the stat step, but setup_layer() seems the better place to me.

ggplot2/R/layer-sf.R

Lines 29 to 37 in 0183011

	# automatically determine the name of the geometry column
	# and add the mapping if it doesn't exist
	if ((isTRUE(self$inherit.aes) && is.null(self$mapping$geometry) && is.null(plot$mapping$geometry)) ||
	(!isTRUE(self$inherit.aes) && is.null(self$mapping$geometry))) {
	if (is_sf(data)) {
	geometry_col <- attr(data, "sf_column")
	self$mapping$geometry <- as.name(geometry_col)
	}
	}

[microly]

@yutannihilation
sorry, I misunderstand your comment.

Another geom seems to be needed.
For short, geom_sf() is for sf object, geom_map_sf() is for data.frame.
This would be more clear and user-friendly.

As I see, a lot of ggplot2 users do not have enough knowlege about spatial data object, such as sf.

[microly]

Just like the author of #3717, a lot of ggplot2 users know few about sf.
They just want to throw a data.frame into ggplot2 and get a map as easily as possible.
Then, geom_map_sf() fill the bill.

[clauswilke]

@yutannihilation When you say "so we don't need another geom", do you mean we just modify geom_map() so it works with coord_sf(), either as default or when a specific parameter is set? This sounds reasonable to me. The current geom_map() code is only a thin wrapper around geom_polygon() anyways, so a more general geom_map() would simply provide two alternative wrappers.

[microly]

@clauswilke
Agreed!

We can just refactor the geom_map().

[yutannihilation]

@microly
I see, I agree with you to some extent. Having different geoms for sf and for data.frame sounds good.

@clauswilke
I meant to say about extending geom_sf() to accept data.frame with conversion, but modifying geom_map() sounds reasonable to me.