oscarperpinan / bookvis Goto Github PK

For example, add spaces in margin=FALSE on Pg. 170, and keep
the same format for all code. Being consistent will improve the code readability.

https://rstudio.github.io/leaflet/

https://edzer.github.io/sp/#interactive-maps-leaflet-mapview

http://environmentalinformatics-marburg.github.io/mapview/introduction.html

The panel.flow is not introduced until next section.

Data should be explained: what are the series names referencing?

There are no examples in this book of scaling for better visuals (e.g., log scale something, axis
or color). At least one section would benefit from this. Many real time series and spatiotemporal
data sets are highly skewed and their presentation would benefit from using a log scale, either
on the axis (e.g. time series) or log-color scale (e.g., spatial data).
The wind max data in the book may be a great candidate for displaying highly skewed time
series, before it was truncated at 10 (see below, comment 10).

Both espMap and provinces lack their proj4string definition.

I think the book would benefit greatly with ‘Chapter Wrap-
Up’ sections summarising the key packages/functions and what was achieved in the
chapters. These should be targeted to the readers who read entire chapters and
would like summaries to consolidate what they have learnt. I felt the need for these
when reading the chapters.

When the included R code gets lengthy, it becomes difficult, if not impossible, to follow any explanation associated with it. An example is the code on pp. 33-34 with some explanation on p. 32. I do
not necessarily have a solution but do want to draw the author’s attention
to this issue. Perhaps one possibility would be to enumerate the lines of the
code, and then refer to them in the text for clarity. Another possibility is
to break the code into smaller components, for which explanations could be
provided separately.

Additionally, more care could be taken to prevent code examples from being split onto multiple
pages, sometimes with an entire page between each half of the example.

I strongly recommend adding line numbers for nontrivial code snippets
(that extend beyond several lines), improve formatting (a lot of space is lost with current
formatting) and carefully edit for redundancy (this pertains to both the code and code
output). E.g., at the end of chapter 6, the output of summary function (a few calls) takes
up about four pages. Is this really necessary given that it is not even discussed
sufficiently?

I would like to see more commented explanations
(under ##) in the code, and also done this more consistently, even if these
might seem obvious to the author. For example, more comments should be
added to:
• Maybe the code on p. 15 (and carrying over to p. 16);
• The 2nd code insert on p. 26 (and carrying over to p. 27); some expla-
nation is presented before the code but it may not be obvious to what
part of the code it applies;
• The 2nd code insert on p. 34;
• The code on pp. 39, 40–42.

Along similar lines, I struggled to under-
stand some of the visualization methods presented in the manuscript. For
example, here are some questions regarding the horizon graph (Section 3.2.2,
p. 19):

As stated in the manuscript (p. 19), Figure 3.6 displays the variations
of solar radiation around the time average with an horizon graph using
a row for each time series.

What is meant by the “time average”? I am guessing that it is the average across the time series for the various times considered.
• What are ±∆ i in Figure 3.6?
• I could not understand why in Figure 3.6, some (fixed) time instances
have variations with different values, represented by several colors/shades
(such as light/dark red or blue/red, etc).
For example, here are some questions regarding the ThemeRiver graph (Sec-
tion 3.3, p. 27):
• The explanation mentions the x-axis at the center of the graph. But
strictly speaking, there is no x-axis in Figure 3.12.
• Similarly, the layers are said to be symmetrical around the x-axis. But
is it immediately obvious how this symmetry is obtained?
The author should be more thoughtful with many of the explanations, not
hesitating to make them lengthier and to include even those comments that
might seem obvious.

https://cran.r-project.org/web/packages/tmap/vignettes/tmap-nutshell.html

For example, chapter 8: includes more than mapping of proportional symbols,
chapter 11: perhaps rename to “Vector Fields” or “Directional Features” to avoid confusion with GIS
“vector” data (point/line/polygon)

1. Colors do not match categories (¿bug in levelplot?)
2. This is not needed anymore:

catTheme <- modifyList(rasterTheme(),
                         list(panel.background = list(col='lightskyblue1'),
                              regions = list(col= pal)))

I found myself second-guessing at various places of
the manuscript about what exactly the author means. For example, here is
a passage from the beginning of Chapter 4 (p. 47):

But, what if instead of displaying the time evolution we want to confront
the variables between them? Section 4.1 proposes the scatterplot matrix solu-
tion with time as a grouping variable. Section 4.2 uses an enhanced scatter-
plot with time as a conditioning variable. Section 4.1.1 includes a digression
about the hexagonal binning for large datasets.

What does the author mean by “confront the variables”? What about
time taken as a “grouping variable” or “conditioning variable”? The author
should not presume that these will somehow be obvious to readers. (By the
way, “digression” carries a negative undertone and should probably also be
replaced.)

http://www.infoelectoral.mir.es/docxl/04_201105_1.zip is not working
Recent data available here: http://www.infoelectoral.mir.es/infoelectoral/docxl/02_201606_1.zip

For example, the caption of Figure 8.4
is ‘Annual average of N O 2 measurements in Madrid.’ A much more useful caption
for the reader would be ‘Annual average of N O 2 measurements in Madrid obtained
using spplot in conjunction with Stamen maps.’ In general, it would be very useful
if the figure captions contain some information on how they were generated (given
the scope of the book). A small typo – on Pg. 136, ‘figure 9.1’ should be uppercase.

https://stat.ethz.ch/pipermail/r-sig-geo/2014-April/020911.html

http://rpubs.com/alobo/vectorOnraster

I think that more cross-referencing
could be done. For example, hill shading is discussed in Section 10.1.1 but then
re-discussed (as though it’s the first time) in Section 12.2.2. On this note, this made
me wonder whether the index is accurate as only one page number is given for ‘Hill
shading.’

• Should one have Sections 5.2-5.4 as subsections of Section 5.1?
• I would suggest to rethink what and how figures should be included.
E.g. should both Figures 5.3 and 5.4 be included? Should Figure 5.2
be that large?
• Should Section 6 be moved to the beginning (as Section 3)?
• Should all the summary outputs be included in Section 6?

oscarperpinan/spacetime-vis#6

Given the amount of code in the book, I think the reader would
benefit if there was some colouring. Functions and arguments in particular could be
standing out, and comments (which are currently grey and easy to gloss over) can
also be given a distinct colour. I understand that this is a very personal preference
though.

For example, I cannot read the text in Figure 8.10,
in Figure 10.5, or in Figure 10.7. Also, while the figures are overall very well done,
some figures need to be annotated more – e.g., Figure 9.1 should have ‘% votes’ to
label the colour legend.

I like some of the observations and lessons
deduced from the displayed figures, as e.g. on p. 16, p. 22, p. 30. I would
encourage the author to spend even more time discussing these observations.
For example, on p. 22, I would suggest including answers to some of the
questions raised. (By the way, “extraordinary measurements” in one of the
questions sounds too strong; what about “unusual” or “outlying”?) I would
also suggest to include similar discussions for all key graphs of the manuscript,
for example, these seem to be missing for key graphs in Chapter 5.

This book is all about making the
reader understand how to generate visualisations in R. As such every piece of code
or argument, except the obvious ones, should be explained. For example, I am not
told why first = TRUE is required on Pg. 116, nor what gridded() does on Pg. 121
(I know the latter, but just by coincidence). If the reader is not given this insight it
will be difficult for him/her to apply the functions to his own data.

• P. 17, l. -13: Cleveland should have a reference. L. -2: Figure 3.4 or 3.5?

• P. 18 and in many places elsewhere: the month abbreviation should be changed from Spanish to English.

• P. 19, l. 3 of Section 3.2.2: “and” appears twice; l. 5: no need for “J.” in the reference; l. 18: INDEX?

• P. 30, l. 3: “I” or “we”?

• Page 16 - code: Does not run. Issues with “annotate” function.

• Page 17 - text: Typo, should be implementS

• Page 24 - code: The latticeExtra package shares names (ie "layer") with the ggplot2 package so this code does not run if ggplot2 masks latticeExtra. Generally more code comments would make the examples more useful as templates to be customized.

• Page 30 - code: The panel.flow function is not introduced until later in the chapter, making this example non-functional at the time it is introduced. This example would also benefit from the data being explained earlier (what are the series names referencing?)

• Page 38 - code: These xts calls are depreciated and should be updated

• Page 40 - code: gridSVG examples did not create interactive files on my machine.

• Page 53 - code: variable name “month” should be “Month” (2 instances on this page)

• Page 63 - code: missing comma in xyplot example (line 2)

• Page 63 - code: “glayer_” function throws errors as written

• Page 64 - code: “glayer” function also throws errors

• Page 67 - code: another “glayer” issue:

• Error in layer(panel.pointLabel(x, y, labels = group.value, col = palOrdered[group.number], : unused argument (superpose = TRUE)

• I think it is something messed up in the “myTheme” formatting list provided.

• Page 76 - code: gridSVG example does not work

• Table of contents, sections 3.4 and 5.6 don't follow the same caps scheme as rest of TOC (and actual section text)

• Page 17 auto.key = true or false? Different in text and code block.

• Page 19 "and and", misspelled "lighter", and some kind of reference malfunction "INDEX"

• Page 21 what is delta_i? A standard deviation? Why the subscript?

• Page 27 "legend is confusing" in 3.10 but remains unchanged in updated figure 3.11. Is it still confusing? (Was it ever confusing?)

• Page 49 "evotranspiration" misspelled. Should be evapotranspiration

• Fig 4.3, p54: white corresponds to "zero" (no bin counts) and "30" (max of scale). Black or grey would be more appropriate for zero since black corresponds to one. In the current figure, white bins could either be empty or 30; not always clear.

• Page 64 typo: function use(s)

• Page 65 fig 5.3: is there more updated data (beyond 2010)? Would be interesting to see how this changed in the past 7 years

• Page 84: a lot of wind max was removed. How was threshold = 10 chosen? (For better visuals?) looking at figure 3.1, it looks like the distribution of wind max may be too truncated.

• Page 85: spatio-temporal or space-time, not "spatio-time" behavior

• Page 88, last code block: complete.cases() is maybe more succinct

• Page 90 last code block: same as above (maybe one example of each?)

Often the aspect ratios used in the figures make the exploration of the time series harder in
this manuscript (e.g., having a figure that is too tall distorts the dependence observed).

Time series: http://jkunst.com/highcharter/

Maps: http://jkunst.com/highcharter/highmaps.html

Try this:

https://mvuorre.github.io/post/2016/2016-03-24-github-waffle-plot/
https://github.com/hrbrmstr/waffle

In rasterST instead of:

ffmpeg -r 6 -b 300k -i Rplot%02d.png output.mp4

I have to use

ffmpeg -r 6 -i Rplot%02d.png -b:v 300k output.mp4

There is a new package sf by E. Pebesma:

Support for simple features, a standardized way to encode spatial data, in R.

It includes a base plot method. Develop a grid method?

Recent version of sp 1.2.0 provides panel.ggmap which is based on the (non-exported) function bb2merc:

function (x, cls = "ggmap") 
{
    WGS84 = CRS("+init=epsg:4326")
    merc = CRS("+init=epsg:3857")
    if (cls == "ggmap") {
        b = sapply(attr(x, "bb"), c)
        pts = cbind(c(b[2], b[4]), c(b[1], b[3]))
    }
    else if (cls == "RgoogleMaps") 
        pts = rbind(x$BBOX$ll, x$BBOX$ur)[, 2:1]
    else stop("unknown cls")
    bbox(spTransform(SpatialPoints(pts, WGS84), merc))
}

There is a demo: demo(webmap).

https://github.com/mitchelloharawild/ggquiver

Example in Dropbox/R/rgl/nightLights.R

• Everything can be written using org-mode. No more latex files are needed.
• Use org-ref for bibliographic references.

For example, add spaces in margin=FALSE on Pg. 170, and keep
the same format for all code. Being consistent will improve the code readability.

There are instances when code examples are presented before the dependencies needed to
execute them have been introduced.

• The Bivariate Choropleth Maps: A How-to Guide page could be useful for the section devoted to choropleth maps.

• Colorcoded map: regional population structures at a glance

sp 1.2.0 includes the new class SpatialMultipoints (an unique feature can be represented with multiple locations):

c1 <- expand.grid(x = 1:3, y = 1:3)
c2 <- expand.grid(x = 4:6, y = 4:6)
c3 <- expand.grid(x = 7:9, y = 7:9)
msp <- SpatialMultiPointsDataFrame(list(c1, c2, c3), data.frame(a = 'A', b = 'B', c = 'C'))
spplot(msp)

http://rstudio.github.io/dygraphs/

In choropleth the URL has changed. Now it is ftp://www.ine.es/pcaxis/mapas_completo_municipal.rar

 The visible layers are alterable by keys:
 x-axis: LEFT / RIGHT arrow key
 y-axis: DOWN / UP arrow key
 z-axis: PAGE_DOWN / PAGE_UP key

 Press and hold left mouse-button to rotate the cube. Press and
 hold right mouse-button to move the cube. Spin mouse-wheel or
 press and hold middle mouse-button and move mouse down/up to zoom
 the cube.

 The visible layers are alterable by keys:
 x-axis: LEFT / RIGHT arrow key
 y-axis: DOWN / UP arrow key
 z-axis: PAGE_DOWN / PAGE_UP key
 Note: In RStudio cubeView may show a blank viewer window. In this
 case open the view in a web-browser (RStudio button at viewer:
 "show in new window").

 Note: Because of key focus issues key-press-events are not always
 recognised within RStudio at Windows. In this case open the view
 in a web-browser (RStudio button at viewer: "show in new window").

 Press and hold left mouse-button to rotate the cube. Press and
 hold right mouse-button to move the cube. Spin mouse-wheel or
 press and hold middle mouse-button and move mouse down/up to zoom
 the cube.

https://procomun.wordpress.com/2013/04/24/stamen-maps-with-spplot/
sp provides the function sp:::web2merc.
Support for Google Earth or OpenStreetMap background maps in sp::plot and spplot. Maps returned by function GetMap in package RgoogleMaps and function get_map in package ggmap are now understood by plotting functions in sp. In particular, sp::plot now has an argument bgMap, spplot now has panel functions panel.RgoogleMaps and panel.ggmap; See demo(webmap) for examples.
As these maps assume a web mercator projection, sp::plot issues a warning if the object to be plotted does not have a CRS containing "+init=epsg:3857"