Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Implement geom_sf_label() and geom_sf_text() #2761
This PR closes #2742.
It's very convenient that
However, adding flexibility to
You can restart just one particular failed build by clicking on the reload icon to the right of it. In this way, you won't mess up the builds that already succeeded.
I have a few comments/questions:
(Disclaimer: I'm not a GIS expert but a guy who just wants to add labels on
In sf package (and probably in simple feature access), they are always written as capital. So, I felt it's more natural to use capital letters for computed variables so that we can distinguish them from ggplot's coordinates. That said, I'm still wondering whether they are essentially the same thing,
Thanks, this sounds nice.
Different. As described above,
Your suggestion is about when the first step succeeds but doesn't return
For example, consider we have a
library(ggplot2) library(sf) #> Linking to GEOS 3.6.1, GDAL 2.2.3, proj.4 4.9.3 mat_poly_xy <- rbind( c(1, 1), c(-1, 1), c(-1, -1), c(1, -1), c(1, 1) ) poly_xy <- st_polygon(list(mat_poly_xy)) poly_xy #> POLYGON ((1 1, -1 1, -1 -1, 1 -1, 1 1))
In this case, we can choose a point on the polygon by
d_poly_xy <- st_sf(geometry = st_sfc(poly_xy)) d_pt_xy <- st_point_on_surface(d_poly_xy) xy <- st_coordinates(d_pt_xy)
So we can combine the coordinates with the original data
cbind(d_pt_xy, xy) #> Simple feature collection with 1 feature and 2 fields #> geometry type: POINT #> dimension: XY #> bbox: xmin: 0 ymin: 0 xmax: 0 ymax: 0 #> epsg (SRID): NA #> proj4string: NA #> X Y geometry #> 1 0 0 POINT (0 0)
But, if the polygon has
mat_poly_xym <- cbind(mat_poly_xy, 1) poly_xym <- st_polygon(list(mat_poly_xym), dim = "XYM") poly_xym #> POLYGON M ((1 1 1, -1 1 1, -1 -1 1, 1 -1 1, 1 1 1)) d_poly_xym <- st_sf(geometry = st_sfc(poly_xym)) st_point_on_surface(d_poly_xym) #> Error in CPL_geos_op("point_on_surface", x, numeric(0), integer(0), numeric(0), : GEOS does not support XYM or XYZM geometries; use st_zm() to drop M
The Z and M issue still isn't entirely clear to me. Do I understand correctly that the default setup fails if the geometries contain Z or M coordinates? In this case, wouldn't it be better for the default to remove Z and M and then run
#' @param fun.geometry #' A function that takes a `sfc` object and returns a `sfc_POINT` with the #' same length as the input. If `NULL`, `function(x) sf::st_point_on_surface(sf::st_zm(x))` will be #' used.
Generally, yes. (It may not fail depending on what
Does this look better to you?
A couple of documentation style issues, and needs a news bullet; otherwise looks good!