sdsr icon indicating copy to clipboard operation
sdsr copied to clipboard

Try with tmap v4

Open olivroy opened this issue 2 years ago • 1 comments

Do not merge, just want to test if the book builds with tmap 3.99.9000

olivroy avatar Jan 17 '24 22:01 olivroy

@edzer when you have time, could you trigger a new run to help identify potential bugs in tmap v4?

olivroy avatar Feb 06 '24 17:02 olivroy

tmap_grob() has been added to tmap v4 (which was the reason it failed the last time) Works as of r-tmap/tmap@66304f18cc14804195e2275d7040142bad0553a9!

olivroy avatar Jul 24 '24 14:07 olivroy

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?

olivroy avatar Jul 24 '24 14:07 olivroy

There you go!

edzer avatar Jul 24 '24 15:07 edzer

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?

edzer avatar Jul 25 '24 08:07 edzer

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 avatar Jul 25 '24 14:07 mtennekes

@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.

rsbivand avatar Jul 25 '24 14:07 rsbivand

Most likely no more 3 series release, but I guess packageVersion("tmap") >= "3.99" would do the trick. (@olivroy ?)

mtennekes avatar Jul 25 '24 15:07 mtennekes

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.

olivroy avatar Jul 25 '24 15:07 olivroy

@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) image

olivroy avatar Jul 25 '24 15:07 olivroy

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.

rsbivand avatar Jul 25 '24 15:07 rsbivand

@olivroy Thx! Where can I find the reproducible code for your example? @rsbivand Could you share pol_pres15?

mtennekes avatar Jul 25 '24 15:07 mtennekes

@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.

olivroy avatar Jul 25 '24 15:07 olivroy

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!

rsbivand avatar Jul 25 '24 16:07 rsbivand

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")
)

rsbivand avatar Jul 25 '24 18:07 rsbivand

... 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 avatar Jul 25 '24 19:07 mtennekes

@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) image

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 avatar Jul 25 '24 19:07 mtennekes

@mtennekes thanks, will check tomorrow while travelling.

rsbivand avatar Jul 25 '24 19:07 rsbivand

#124 doesn't yet have the alignment fixes, they will follow.

rsbivand avatar Jul 26 '24 11:07 rsbivand

@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

rsbivand avatar Jul 26 '24 15:07 rsbivand

@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.

rsbivand avatar Jul 26 '24 17:07 rsbivand

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.

rsbivand avatar Jul 26 '24 18:07 rsbivand