Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aggregate.sf does not return an object with the same length as by #452

Closed
Robinlovelace opened this issue Aug 3, 2017 · 5 comments
Closed

Comments

@Robinlovelace
Copy link
Contributor

Reproducible example:

# with sp
library(sp)
# from ?aggregate.Spatial
data("meuse")
coordinates(meuse) <- ~x + y
data("meuse.grid")
coordinates(meuse.grid) <- ~x + y
gridded(meuse.grid) <- TRUE
meuse.grid$part.a[1:3] = 2
abc = rgeos::gUnaryUnion(as(meuse.grid, "SpatialPolygons"), meuse.grid$part.a)
x = aggregate(meuse[c("zinc", "copper")], abc, mean)
nrow(x)  # 3 features outputed
#> [1] 3

# with sf
library(sf)
#> Linking to GEOS 3.5.1, GDAL 2.1.3, proj.4 4.9.2, lwgeom 2.3.2 r15302
meuse_sf = st_as_sf(meuse)
abc_sf = st_as_sf(abc)
x_sf = aggregate(meuse_sf[c("zinc", "copper")], abc_sf, mean)
nrow(x_sf)
#> [1] 2
@edzer
Copy link
Member

edzer commented Aug 18, 2017

I think it works as documented.

@Robinlovelace
Copy link
Contributor Author

Thanks for the response and sorry for the slow reply. Just taken a look over the latest version of the documentation and it seems that the behaviour when the aggregating object (y) does not intersect with the target object (x) is not mentioned, introducing ambiguity.

Given many sf useRs will be coming from sp (as acknowledged in the very useful work going into #210 ) it's likely that they will assume the same behaviour in equivalent sf functions, especially for commonly used and generic methods like aggregate(). So if the behaviour is different, I think it should be stated and demonstrated, e.g. with an example such as that created in my 1st PR on this issue https://github.com/r-spatial/sf/pull/451/files.

My view is that aggregate() will be much more useful to users and less surprising if it always returns the geometry in y, hence my first stab at trying to address this in #453 . Sure there are better ways of doing this but seems to work as I would expect and as sp does in the example above.

@edzer
Copy link
Member

edzer commented Aug 28, 2017

I've merged your #451 PR.

I looked at

d = data.frame(a = 1:4, b = factor(c("a", "a", "b", "b"), levels = c("a", "b", "c")))
> aggregate(d[1], list(b = d$b), mean)
  b   a
1 a 1.5
2 b 3.5

and noted that it doesn't give output (NA) for b values having level c.

@Robinlovelace
Copy link
Contributor Author

Here's another reprex showing behaviour under my PR version:

devtools::install_github("robinlovelace/sfr", ref = "aggregate")
#> Skipping install of 'sf' from a github remote, the SHA1 (ce84f94d) has not changed since last install.
#>   Use `force = TRUE` to force installation
library(sp)
# from ?aggregate.Spatial
data("meuse")
coordinates(meuse) <- ~x + y
data("meuse.grid")
coordinates(meuse.grid) <- ~x + y
gridded(meuse.grid) <- TRUE
meuse.grid$part.a[1:3] = 2
abc = rgeos::gUnaryUnion(as(meuse.grid, "SpatialPolygons"), meuse.grid$part.a)
x = aggregate(meuse[c("zinc", "copper")], abc, mean)
nrow(x)  # 3 features outputed
#> [1] 3

# with sf
library(sf)
#> Linking to GEOS 3.5.1, GDAL 2.2.1, proj.4 4.9.2, lwgeom 2.3.3 r15473
meuse_sf = st_as_sf(meuse)
abc_sf = st_as_sf(abc)
x_sf = aggregate(meuse_sf[c("zinc", "copper")], abc_sf, mean)
nrow(x_sf)
#> [1] 3

@Robinlovelace
Copy link
Contributor Author

Useful to have an example showing non-spatial behaviour. I think that example is rather specific to factor data. Another example that I think supports keeping the geometry of y is:

d = data.frame(a = c(1:3, NA), b = c("a", "a", "b", "c"))
aggregate(d[1], list(b = d$b), mean)
#>   b   a
#> 1 a 1.5
#> 2 b 3.0
#> 3 c  NA

@edzer edzer closed this as completed in ce84f94 Aug 28, 2017
Robinlovelace added a commit to geocompx/geocompr that referenced this issue Aug 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants