This is more a question than an issue, but how are we supposed to plot a choropleth map (or just any data-depending plot) using sf ?
When plotting a sf object, all the attributes are plotted, for example :
nc <- st_read(system.file("shape/nc.shp", package="sf"))
plot(nc) # This plots all the attributes
But when there is only 1 attribute, it plots a non filled map :
nc2 <- nc %>% select(AREA, geometry)
plot(nc2)
And there's a problem with character columns, avoiding the default plot :
nc3 <- nc
nc3$FIPS <- as.character(nc3$FIPS)
plot(nc3) # Error in cut.default(x, n) : 'x' should be numeric
Of course, converting to sp, it works as it should :
spplot(as(nc2, "Spatial"))
What's the good way ?
And is there a possibibility to plot using ggplot2 ? The old fortify seems irrelevant here, but couldn't find the proper syntax.
Thanks! I fixed the single map plotting in https://github.com/edzer/sfr/commit/5ca05199231e91576bdcd968fb048ca45eed7377. Should character columns be plotted as a factor?
As of ggplot2 support, we're aware, an hope to address it soon, as of within weeks. See also https://github.com/edzer/sfr/issues/88 .
Yes, I think characters should be considered as factors for the plotting 👍
Another issue I just found, probably related to #42 : when doing a summarise, although the data seems correct, I think there's wrong binding somewhere, as the plots are not displayed correctly :
nc <- st_read(system.file("shape/nc.shp", package="sf"))
summary(nc$BIR79)
plot(nc, col = nc$BIR79) # or plot(nc, col = sf.colors(nc$BIR79))
Each region got its own color, all is fine
nc2 <- nc %>%
mutate(CNTY_2 = str_sub(CNTY_, start = 1, end = 2)) %>%
group_by(CNTY_2) %>%
summarise(BIR79 = sum(BIR79)) %>%
mutate(CNTY_2 = as.factor(CNTY_2))
summary(nc2$BIR79)
plot(nc2, col = nc2$BIR79)
plot(nc2)
Whether for numerical or factor data, all the geoms have the same color. The dissolved geom shape looks right, but there's obviously some issue with the link to the attributes.
the issue is that here, nc2 is GEOMETRY because it is a mix of POLYGON and MULTIPOLYGON features; whether this is good or bad, they were indeed not plotted correctly; now fixed by https://github.com/edzer/sfr/commit/c8010ac2eee1bca1aa7a2765daec426fa5b20059
piping through st_cast("MULTIPOLYGON") would have solved it in another way.
Comming back to the issue of how to plot character variables:
sp::spplot does not plot character data in any sensible wayfactors are fundamentally different, and am reluctant to treat character variables, by default, as factors for the sake of plotting them. My proposal to "correctly" plot character attributes is to write the character information as text string at the location of the geometry.@mtennekes what do you think?
Actually, I don't regard characters as fundamentally different from factors. I think the main difference is that character variables typically have many unique values whereas factors only have a handful/dozen of levels. I agree that it makes much more sense to plot characters as text and factors by other aesthetics.
sf are supported in tmap, at least for those sf objects that can be converted to Spatial objects. For tmap, this character/factor discussion is not an issue, since by default, empty maps are drawn. The user has to specify which aesthetic is used.
The following should work (if not, let me know):
library(devtools)
install_github("mtennekes/tmaptools")
install_github("mtennekes/tmap", subdir = "pkg")
library(sf)
library(tmap)
nc <- st_read(system.file("shape/nc.shp", package="sf"))
tm_shape(nc) +
tm_polygons("BIR74")
tm_shape(nc) +
tm_text("FIPS")
tm_shape(nc) +
tm_polygons(names(nc)[1:14]) +
tm_layout(panel.labels = names(nc)[1:14])
ttm() # switch to interactive mode (handy to find out that nc stands for North Carolina:)
tm_shape(nc) +
tm_polygons("BIR74")
I'm speachless.
Trying the 14 panel maps _after_ the ttm() switch, I see that their response is not synced. Is there a way to sync them, just like the last plot in this post?
Tnx! It should work like that: tmap imports latticeView/sync from mapview for interactive small multiples.
By default sync is used, unless the free coordinates are used (in ggplot2 terminology, scales="free").
On my machine, the htmlwidget got stuck when trying to show 14 leaflet windows. With 4:
tm_shape(nc) +
tm_polygons(names(nc)[1:4])
nc$CNTY_ID2 <- cut(nc$CNTY_ID, 4)
tm_shape(nc) +
tm_polygons("BIR74") +
tm_facets(by="CNTY_ID2", free.coords = TRUE)
Strange. On my compute, both examples are not synced; tried chrome and firefox.
Also in the RStudio viewer pane?
You could try this:
tm_shape(nc) +
tm_polygons(names(nc)[1:4]) +
tm_layout(panel.labels = names(nc)[1:4]) +
tm_facets(free.coords=FALSE)
Just to check our session info. For tmap and tmaptools, I'm obviously using the latest github versions.
devtools::session_info()
Session info -----------------------------------------------------------------------------------------------------------------------------
setting value
version R version 3.3.2 (2016-10-31)
system x86_64, mingw32
ui RStudio (1.0.44)
language (EN)
collate English_United States.1252
tz Europe/Berlin
date 2016-12-22
Packages ---------------------------------------------------------------------------------------------------------------------------------
package * version date source
bitops 1.0-6 2013-08-17 CRAN (R 3.2.3)
boot 1.3-18 2016-02-23 CRAN (R 3.3.2)
class 7.3-14 2015-08-30 CRAN (R 3.3.2)
classInt 0.1-23 2015-09-29 CRAN (R 3.2.3)
coda 0.18-1 2015-10-16 CRAN (R 3.2.3)
codetools 0.2-15 2016-10-05 CRAN (R 3.3.2)
colorspace 1.3-1 2016-11-18 CRAN (R 3.3.2)
DBI 0.5-1 2016-09-10 CRAN (R 3.3.1)
deldir 0.1-12 2016-03-06 CRAN (R 3.2.3)
devtools * 1.12.0 2016-06-24 CRAN (R 3.3.1)
digest 0.6.10 2016-08-02 CRAN (R 3.3.1)
e1071 1.6-7 2015-08-05 CRAN (R 3.2.3)
foreach 1.4.3 2015-10-13 CRAN (R 3.2.3)
gdalUtils 2.0.1.7 2015-10-10 CRAN (R 3.2.3)
gdata 2.17.0 2015-07-04 CRAN (R 3.2.3)
geosphere 1.5-5 2016-06-15 CRAN (R 3.3.1)
gmodels 2.16.2 2015-07-22 CRAN (R 3.2.4)
gtools 3.5.0 2015-05-29 CRAN (R 3.2.3)
htmltools 0.3.5 2016-03-21 CRAN (R 3.2.4)
htmlwidgets 0.8 2016-11-09 CRAN (R 3.3.2)
iterators 1.0.8 2015-10-13 CRAN (R 3.2.3)
jsonlite 1.1 2016-09-14 CRAN (R 3.3.1)
KernSmooth 2.23-15 2015-06-29 CRAN (R 3.3.2)
lattice 0.20-34 2016-09-06 CRAN (R 3.3.2)
latticeExtra 0.6-28 2016-02-09 CRAN (R 3.3.0)
leaflet 1.0.1 2016-02-27 CRAN (R 3.2.3)
LearnBayes 2.15 2014-05-29 CRAN (R 3.2.3)
magrittr 1.5 2014-11-22 CRAN (R 3.2.3)
mapview 1.2.0 2016-09-18 CRAN (R 3.3.2)
MASS 7.3-45 2016-04-21 CRAN (R 3.3.2)
Matrix 1.2-7.1 2016-09-01 CRAN (R 3.3.2)
memoise 1.0.0 2016-01-29 CRAN (R 3.3.0)
munsell 0.4.3 2016-02-13 CRAN (R 3.2.3)
nlme 3.1-128 2016-05-10 CRAN (R 3.3.2)
osmar 1.1-7 2013-11-21 CRAN (R 3.2.3)
plyr 1.8.4 2016-06-08 CRAN (R 3.3.1)
png 0.1-7 2013-12-03 CRAN (R 3.2.3)
R.methodsS3 1.7.1 2016-02-16 CRAN (R 3.3.0)
R.oo 1.21.0 2016-11-01 CRAN (R 3.3.2)
R.utils 2.5.0 2016-11-07 CRAN (R 3.3.2)
raster 2.5-8 2016-06-02 CRAN (R 3.3.2)
RColorBrewer 1.1-2 2014-12-07 CRAN (R 3.2.3)
Rcpp 0.12.8 2016-11-17 CRAN (R 3.3.2)
RCurl 1.95-4.8 2016-03-01 CRAN (R 3.2.3)
rgdal 1.2-4 2016-11-15 CRAN (R 3.3.2)
rgeos 0.3-21 2016-10-20 CRAN (R 3.3.2)
roxygen2 5.0.1 2015-11-11 CRAN (R 3.2.4)
satellite 0.2.0 2015-09-10 CRAN (R 3.2.3)
scales 0.4.1 2016-11-09 CRAN (R 3.3.2)
sf * 0.2-8 2016-12-21 Github (edzer/sfr@07ff099)
sp 1.2-3 2016-04-14 CRAN (R 3.2.5)
spdep 0.6-8 2016-09-21 CRAN (R 3.3.1)
stringi 1.1.2 2016-10-01 CRAN (R 3.3.1)
stringr 1.1.0 2016-08-19 CRAN (R 3.3.1)
tmap * 1.6-1 <NA> local
tmaptools * 1.0 2016-12-21 local
udunits2 0.13 2016-11-17 CRAN (R 3.3.2)
units 0.4-1 2016-12-09 CRAN (R 3.3.2)
viridisLite 0.1.3 2016-03-12 CRAN (R 3.2.5)
webshot 0.3.2 2016-06-23 CRAN (R 3.3.1)
withr 1.0.2 2016-06-20 CRAN (R 3.3.1)
XML 3.98-1.5 2016-11-10 CRAN (R 3.3.2)
yaml 2.1.14 2016-11-12 CRAN (R 3.3.2)
Also in Rstudio viewer.
```
sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.1 LTS
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=en_GB.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_GB.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=en_GB.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] tmap_1.6-1 sf_0.2-8 sp_1.2-3
loaded via a namespace (and not attached):
[1] gtools_3.5.0 splines_3.3.2 lattice_0.20-34 mapview_1.2.0 colorspace_1.2-6 viridisLite_0.1.3
[7] stats4_3.3.2 htmltools_0.3.5 yaml_2.1.14 XML_3.98-1.5 R.oo_1.20.0 e1071_1.6-7
[13] DBI_0.5-1 R.utils_2.4.0 RColorBrewer_1.1-2 plyr_1.8.4 foreach_1.4.3 rgeos_0.3-21
[19] munsell_0.4.3 raster_2.5-8 osmar_1.1-7 R.methodsS3_1.7.1 htmlwidgets_0.8 codetools_0.2-15
[25] coda_0.18-1 latticeExtra_0.6-28 httpuv_1.3.3 crosstalk_1.0.0 class_7.3-14 gdalUtils_2.0.1.7
[31] spdep_0.6-8 Rcpp_0.12.8 KernSmooth_2.23-15 geosphere_1.5-5 xtable_1.8-2 udunits2_0.13
[37] scales_0.4.1 classInt_0.1-23 satellite_0.2.0 gdata_2.17.0 jsonlite_1.1 webshot_0.3.2
[43] leaflet_1.0.2.9010 mime_0.5 deldir_0.1-12 rmsfact_0.0.3 png_0.1-7 digest_0.6.10
[49] gmodels_2.16.2 shiny_0.14.2 tmaptools_1.0 grid_3.3.2 rgdal_1.2-5 tools_3.3.2
[55] bitops_1.0-6 LearnBayes_2.15 magrittr_1.5 RCurl_1.95-4.8 MASS_7.3-45 Matrix_1.2-7.1
[61] iterators_1.0.8 R6_2.2.0 boot_1.3-18 units_0.4-1 nlme_3.1-128
Ah, it's mapview 1.2.0 <-> leaflet 1.0.2.9010 that is causing trouble.
Also, the example from latticeView doesn't work anymore on my machine:
## Not run:
library(sp)
library(raster)
data(meuse)
coordinates(meuse) <- ~x+y
proj4string(meuse) <- CRS("+init=epsg:28992")
## view different aspects of same data set
m1 <- mapview(meuse, zcol = "soil", burst = TRUE)
m2 <- mapview(meuse, zcol = "lead")
m3 <- mapview(meuse, zcol = "landuse", map.types = "Esri.WorldImagery")
m4 <- mapview(meuse, zcol = "dist.m")
latticeView(m1, m2, m3, m4) # 4 panels
sync(m1, m2, m3, m4) # 4 panels synchronised
I only see the first plot:

In tmap, the small multiples work, but indeed not the syncing. Any ideas @tim-salabim and @mdsumner ?
Update: now I've tried mapview to the latest github version (1.2.18). The problem of seeing only the first plot seems to be solved, but the syncing still doesn't work.
I believe the reason for syncing not working anymore is to do with an update made to leaflet. Maybe @bhaskarvk or @timelyportfolio have more wisdom regrading this?
I would be more than happy to debug if you can provide me with a minimal reproducible example.
@bhaskarvk sure:
library(mapview)
m1 <- mapview(breweries91)
m2 <- leaflet() %>% addTiles() %>% addCircleMarkers(data = breweries91)
sync(m1, m2)
This is supposed to produce a synchronised view of the two windows, as in https://edzer.github.io/sp/#interactive-maps-leaflet-mapview
The function in question is https://github.com/environmentalinformatics-marburg/mapview/blob/develop/R/latticeView.R
Thanks Tim, and I presume this works with the CRAN versions on leaflet/mapview but not with the dev versions ? I haven't introduced any compatibility breaking change but I'll try and debug this at my end.
Yes Bhaskar, it should work with the CRAN versions but definitely does not work with current dev versions. I'm not sure if it is related to this:
https://github.com/rstudio/leaflet/issues/308#issuecomment-253610276
which also worked before (the var map = HTMLWidgets.find('#' + el.id); that is). As we use something similar in sync this may be relevant. All of these were originally written by @timelyportfolio
In that case the fix there too would be to change the JS code in mapview accordingly.
Actually upon more reading this looks like you're syncing 2+ HTML Widgets. This will need more debugging.
I am open to alternative/better htmlwidgets solutions. Maybe a widget in itself?
Yes the more I think about it, the more it makes sense to have it as a widget in itself.
I'm back from an extended disconnect. I'll be happy to try to debug the syncing. My one fear with a widget in itself is disruption of the workflow meaning once you produce the synced view then subsequent changes to any of the sub-views will not flow through to the synced widget. Perhaps, we could explore a formula or something I'm not real familiar with binding.
I think the first thing to do is debug var map = HTMLWidgets.find('#' + el.id);. I am not intimately familiar with HTMLWidgets JS codebase, but it seems to me that HTMLWidgets.find is for getting hold of the DOM for the widget, which is not the same thing as the widget JS Object. At least that was the issue in rstudio/leaflet#308.
I have just submitted a pull request https://github.com/environmentalinformatics-marburg/mapview/pull/53 to fix this. @bhaskarvk, your guess was correct, and I just needed to add getMap() to the HTMLWidgets.find(...). Please test and report back. Thanks.
Cool! Thanks so much. I will merge this when I am back in civilization w
access to a computer. Most likely next week
On 3 Jan 2017 20:03, "timelyportfolio" notifications@github.com wrote:
I have just submitted a pull request environmentalinformatics-
marburg/mapview#53
https://github.com/environmentalinformatics-marburg/mapview/pull/53 to
fix this. @bhaskarvk https://github.com/bhaskarvk, your guess was
correct, and I just needed to add getMap() to the HTMLWidgets.find(...).
Please test and report back. Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/edzer/sfr/issues/118#issuecomment-270194817, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACsgwG9tVI1JgT9yXk1nG0bsugIPxGBwks5rOpt6gaJpZM4LQu9o
.
The sync issue now fixed in the latest mapview develop version.
confirmed!