Try with tmap v4
Do not merge, just want to test if the book builds with tmap 3.99.9000
@edzer when you have time, could you trigger a new run to help identify potential bugs in tmap v4?
tmap_grob() has been added to tmap v4 (which was the reason it failed the last time) Works as of r-tmap/tmap@66304f18cc14804195e2275d7040142bad0553a9!
Seems like it works! Failure is due to my lack of write access to the gh-pages branch. I fixed the action to make sure rendering is not attempted from a PR.
If you want, you could merge the PR and revert the changes quickly, so that I could investigate the diff in the gh-pages branch?
There you go!
Look at figure 14.3 here: https://edzer.github.io/sdsr/14-Areal.html (end of page): is this a problem with tmap_grob(), @mtennekes? Other changes compared to https://r-spatial.org/book/: tmap_arrange() in Figure 15.8 no longer align; @rsbivand maybe you want to take a look? When will tmap 4 be submitted to CRAN?
Will look into it. (https://github.com/r-tmap/tmap/issues/905, see workaround with grid viewports)
Submission data of tmap4 is still unclear, but I within the next 1 or 2 months.
@mtennekes Which version number can we safely test against? Will there be any releases after 3.3.4 in the 3 series? So:
packageVersion("tmap") >= "3.4"
will mean tmap4? The current master is 3.99.9001, which is less than "4", so:
packageVersion("tmap") >= "4"
doesn't work.
Most likely no more 3 series release, but I guess packageVersion("tmap") >= "3.99" would do the trick. (@olivroy ?)
Yes, I proposed v3.99 as a way to clearly tell that this is the version before v4 and to make sure that everyone who installed the dev version would be notified when the official v4.0 version was published.
@mtennekes, you may want to look at https://github.com/edzer/sdsr/commit/ba6ff4625325b9f67f93c662691a079aa23eced1#diff-b37651b81ffc90e4a289d5aaf89ea0e72aba6aaeca427ec96c14163840f5ca70 for a diff of going from v3 to v4 looks like in the wild! I find the diff quite satisfying generally, thanks to your work!
Something else that I noticed was the alignment of legends (left = v3, right = v4)
I am pretty lost. What does:
-- tmap v3 code detected --
[v3->v4] tm_fill(): migrate the argument(s) related to the scale of the visual variable 'fill', namely 'breaks', 'palette' (rename to 'values') to 'fill.scale = tm_scale(<HERE>)'
[v3->v4] tm_fill(): migrate the argument(s) related to the legend of the visual variable 'fill', namely 'title' to 'fill.legend = tm_legend(<HERE>)'
tm_facets: the argument free.scales is deprecated. Specify this via the layer functions (e.g. fill.free in tm_polygons)
[cols4all] color palettes: use palettes from the R package cols4all. Run 'cols4all::c4a_gui()' to explore them. The old palette name "-YlOrBr" is named "yl_or_br" (in long format "brewer.yl_or_br")
Multiple palettes called "yl_or_br found: "brewer.yl_or_br", "tol.yl_or_br". The first one, "brewer.yl_or_br", is returned.
[plot mode] fit legend/component: Some legend items or map compoments do not fit well, and are therefore rescaled. Set the tmap option 'component.autoscale' to FALSE to disable rescaling.
for:
tm_shape(pol_pres15) +
tm_fill(c("locm_pv", "locm_std_pv", "locm_p_pv"),
breaks=c(0, 0.0005, 0.001, 0.005, 0.01,
0.05, 0.1, 0.2, 0.5, 0.75, 1),
title = "Pseudo p-values\nLocal Moran's I",
palette="-YlOrBr") +
tm_facets(free.scales = FALSE, ncol = 2) +
tm_layout(panel.labels = c("Analytical conditional",
"Permutation std. dev.",
"Permutation rank"))
Trying the first problem:
> summary(st_drop_geometry(pol_pres15[,c("locm_pv", "locm_std_pv", "locm_p_pv")]))
locm_pv locm_std_pv locm_p_pv
Min. :0.00000 Min. :0.00000 Min. :0.003898
1st Qu.:0.09156 1st Qu.:0.09236 1st Qu.:0.090872
Median :0.36983 Median :0.36934 Median :0.368652
Mean :0.41594 Mean :0.41625 Mean :0.416880
3rd Qu.:0.71003 3rd Qu.:0.70879 3rd Qu.:0.715713
Max. :0.99940 Max. :0.99950 Max. :0.998800
> tm_shape(pol_pres15) +
+ tm_polygons(fill=c("locm_pv", "locm_std_pv", "locm_p_pv"),
+ fill.scale = tm_scale(breaks = c(0, 0.0005, 0.001, 0.005, 0.01, 0.05, 0.1, 0.2, 0.5, 0.75, 1), values="br_or_yl")
+ )
Error: Incorrect values for layer polygons, aesthetic fill; values should conform visual variable "fill".
With:
> tm_shape(pol_pres15) + tm_polygons(fill=c("locm_pv"), fill.scale = tm_scale(breaks = c(0, 0.0005, 0.001, 0.005, 0.01, 0.05, 0.1, 0.2, 0.5, 0.75, 1)), palette="brewer.yl_or_br")
-- tmap v3 code detected --
[v3->v4] tm_polygons(): migrate the argument(s) related to the scale of the visual variable 'fill', namely 'palette' (rename to 'values') to 'fill.scale = tm_scale(<HERE>)'
gets YlOrBr, but the breaks are wrong, with:
tm_shape(pol_pres15) + tm_polygons(fill=c("locm_pv"), fill.scale = tm_scale(breaks = c(0, 0.0005, 0.001, 0.005, 0.01, 0.05, 0.1, 0.2, 0.5, 0.75, 1)), values="brewer.yl_or_br")
the palette is blues, but the breaks are as specified. No attempts to get facets to work have suceeded.
@olivroy Thx! Where can I find the reproducible code for your example?
@rsbivand Could you share pol_pres15?
@mtennekes this is from spDataLarge. data(pol_pres15, package = "spDataLarge"). I also opened r-tmap/tmap#907 to follow-up there for the alignment issue.
Please use the SDSR source. Start with the scripts folder in https://github.com/edzer/sdsr, I ran first source("14_Area.R", echo=TRUE), then in the same session source("15_Measures.R", echo=TRUE) using the RData object stored from ch. 14. As of now, I have:
tm_shape(pol_pres15) + tm_polygons(fill=c("locm_pv", "locm_std_pv", "locm_p_pv"), fill.scale = tm_scale(breaks = c(0, 0.0005, 0.001, 0.005, 0.01, 0.05, 0.1, 0.2, 0.5, 0.75, 1), values="-brewer.yl_or_br"), fill.free=FALSE, lwd=0.01) + tm_facets_wrap(columns=2, rows=2)
and am struggling to set the panel labels and legend title (about line 186 in 15_Measures.R). Removing the legend box edges would be very helpful, and returning the legend fill boxes to squares too!
Getting there:
tm_shape(pol_pres15) +
tm_polygons(fill=c("locm_pv", "locm_std_pv", "locm_p_pv"),
fill.legend = tm_legend("Pseudo p-values\nLocal Moran's I", frame=FALSE),
fill.scale = tm_scale(breaks = c(0, 0.0005, 0.001, 0.005, 0.01, 0.05, 0.1, 0.2, 0.5, 0.75, 1),
values="-brewer.yl_or_br"),
fill.free=FALSE, lwd=0.01) +
tm_facets_wrap(columns=2, rows=2) +
tm_layout(panel.labels = c("Analytical conditional", "Permutation std. dev.", "Permutation rank")
)
... returning the legend fill boxes to squares too!
Do you mean squares with normal instead of rounded corners? If so:
tm_shape(pol_pres15) +
tm_polygons(fill=c("locm_pv", "locm_std_pv", "locm_p_pv"),
fill.legend = tm_legend("Pseudo p-values\nLocal Moran's I", frame=FALSE, item.r = 0),
fill.scale = tm_scale(breaks = c(0, 0.0005, 0.001, 0.005, 0.01, 0.05, 0.1, 0.2, 0.5, 0.75, 1),
values="-brewer.yl_or_br"),
fill.free=FALSE, lwd=0.01) +
tm_facets_wrap(columns=2, rows=2) +
tm_layout(panel.labels = c("Analytical conditional", "Permutation std. dev.", "Permutation rank"))
@mtennekes, you may want to look at ba6ff46#diff-b37651b81ffc90e4a289d5aaf89ea0e72aba6aaeca427ec96c14163840f5ca70 for a diff of going from v3 to v4 looks like in the wild! I find the diff quite satisfying generally, thanks to your work!
Something else that I noticed was the alignment of legends (left = v3, right = v4)
Is my answer here https://github.com/r-tmap/tmap/issues/907 any useful, @rsbivand ?
PS: In my version of the data object (outcome of script 15, there weren't any yellow negative data points in pol_pres15$hs_C_II
@mtennekes thanks, will check tomorrow while travelling.
#124 doesn't yet have the alignment fixes, they will follow.
@mtennekes Yes, using ´tm_layout(meta.margins = c(.2, 0, 0, 0))´ does help, as you show in https://github.com/r-tmap/tmap/issues/907
@mtennekes
PS: In my version of the data object (outcome of script 15, there weren't any yellow negative data points in pol_pres15$hs_C_II
The iseed is fed through to the parallel RNG for the permutation sampling, but on reflection the count of cores being used will also affect the result.
Using spdep::set.coresOption(max(detectCores()-1L, 1L)), I think that the outcomes will vary when the number of cores used differs. Interesting point!
Maybe I should note this in the spdep help pages, and in the text of ch 15. @JosiahParry ? If say observation 500 is in shard/slice 1 in one run, and in shard/slice 2 in a run with more cores, it will not see the same RN stream to sample with.
library(spdep)
data(afcon, package="spData")
get.coresOption()
resI_p <- localmoran_perm(afcon$totcon, nb2listw(paper.nb), iseed=1L)
set.coresOption(1L)
resI_p1 <- localmoran_perm(afcon$totcon, nb2listw(paper.nb), iseed=1L)
all.equal(resI_p, resI_p1)
set.coresOption(2L)
resI_p2 <- localmoran_perm(afcon$totcon, nb2listw(paper.nb), iseed=1L)
all.equal(resI_p, resI_p2)
## [1] "Attributes: < Component \"ncpus\": Mean relative difference: 1 >"
## [2] "Mean relative difference: 0.2307796"
set.coresOption(NULL)
The returned "ncpus" attribute is new (in boots_licd branch, not yet committed), returning the CPU count in the object.
