Closed Robinlovelace closed 6 years ago
jannes-m
commented
6 years ago Reviewer comment: Location analysis and geomarketing are not the same! I like the comparison between (landscape) ecological analysis and location analysis though. @Robinlovelace we have talked about this. I also thought that location analysis is just a part of geomarketing. But Robin, you are the native speaker, and if you say geomarketing is not a common term, we can respond accordingly.
Robinlovelace
commented
6 years ago Interestingly, it seems I'm wrong about geomarketing: it's more common than 'store location analysis' and even 'location analysis' although strangely, all terms seem to be in long-term decline: https://trends.google.com/trends/explore?date=all&q=geomarketing,%22store%20location%20analysis%22,%22location%20analysis%22
I think my opinion was based on the academic side of things but in the 'real' world it seems that geomarketing is common parlance. I suggest we differentiate between them based on our understanding of the terms' uses in academic and industry. I found this article useful but @jannes-m I think you know more about this than me so I trust your view on the best response for the reviewer and, more importantly, the readers :book:
Robinlovelace
commented
6 years ago Thanks for mopping-up those last pesky issues @jannes-m. Final job: draft an email thanking the reviewers for very useful feedback. Mental not to self: do that (remind me if you don't get something on this later in the week)!
osmdata::getbb()was in the development version of osmdata. Was fixed on 2018-02-22 when the osmdata 0.0.6 was sent to CRAN - see https://cran.r-project.org/package=osmdata - We agree that the description of the code in c7 was clunky at times. To address we have re-written the description of the code at the outset of c7 to make it clearer (see this commit) [RL]Chapter 7 [RL]:
Chapter 8 [JM]:
pryr::object_size(poi)) than its vector representation (28.1 MB;pryr::object_size(shops)).reviewer two
Chapter 5:
[x] 2.1 [RL] Page 98, 2nd paragraph – Didn't understand why was 'geosphere::alongTrackDistance' used to calculate 1 degree distance, instead of 'geosphere::distGeo' like on the previous page? - You are right, this is confusing and was therefore deleted. Thanks for spotting this.
[x] 2.2 [RL] Page 101, 1st paragraph – UTM zones are also divided by latitude zones, not just by longitude, with the most commonly used division is to north (N) and south (S). This should be mentioned to avoid confusion. For example, the 'rgdal::make_EPSG' list has 120 projections matching the description 'WGS 84 / UTM zone', rather than 60, because each of the 60 zones has a separate north and south variant.
[x] 2.4 [JN] Page 108, Table 5.1 – Perhaps the heading should say this applies to the specific 'cat_raster' example. The current heading may be interpreted as though the table applies to any given NAD83 and WGS84 rasters.
[x] 2.5 [JN] Page 109, Table 5.2 – Same as previous comment. - Thanks. We improved the tables' captions.
[x] 2.6 [JN] Page 112, 4th paragraph – It should be mentioned what is the algorithm used by the 'st_point_surface' function. For example, is there a random component or is it deterministic? - We have added a link to the answer on stackoverflow explaining this algorithm - https://gis.stackexchange.com/a/76563/20955 .
[x] 2.7 [RL] Page 113, 1st code section – Perhaps it was mentioned elsewhere; if not, text should emphasize that the distance arguments are given in CRS units, or as 'units' objects.
[x] 2.8 [JN] Page 114, 1st code section – Better to use 'st_geometry(nz)' rather than 'nz$geometry'. The latter is specific to the case when the geometry column is named "geometry", the former is general for any 'sf' layer.
[x] 2.9 [RL] Page 118, 2nd paragraph – Seems like there is missing text, as the paragraph starts with "There are two different ways to subset points..." but I can't find where these ways are described.
[x] 2.10 [RL] Page 118, last paragraph – The paragraph and following code section (on aggregation with 'dplyr') are repeated on the next page, so should be omitted here.
st_union(). See https://github.com/Robinlovelace/geocompr/commit/848c41e64d337c51267fd2d3a616d3a45ad64bf6 - any feedback on this welcome.[x] 2.11 [JN] Page 119, Figure 5.14 – The color key in this figure refers to population, but units are in "mln" which on first glance can be confused with "min", e.g. "0 mln to 20 min". Why not use exponential notation, e.g. "0×106 – 20×106"? - We decided to avoid using exponential notation in our book.
[x] 2.12 [JN] Page 119, 3rd paragraph – Perhaps it would better to start Section 5.3.7 with an introduction on what geometry transformations are useful for. The next page gives one example – splitting a MULTI* geometry so that separate attributes can be given for each individual part. Another very common use is transforming a series of points into a LINESTRING, as shown on the left in Figure 5.15. For example, this is used on chronologically ordered point observations of a moving object, person or animal, such as in GPS device recordings or geo- referenced social media posts. If there is room maybe another example can be added where a collection of points referring to different objects are combined to MULTIPOINT by object, then casted to LINESTRING geometries per object. - Thank you for this suggestion. We added a few sentences of when geometry casting can be useful.
[x] 2.13 [RL, JN, JM - to discuss] Page 123, code sections – The code sections on this page mix 'sf' and 'raster' objects in the same expressions. However, currently, 'raster' (Version 2.6-7) is officially only compatible with 'sp' objects. Thus, for example, the fact that function 'rasterize' works with the 'sf' object named 'us_states' can be viewed as a coincidence. The problematic nature of this situation is unmentioned as far as I can see. Unless the compatibility is clearly discussed (i.e. why does this code work? In which other cases using 'sf' objects in 'raster' function will not work?), less experienced readers may be under the impression that 'sf' and 'raster' are undoubtedly compatible, and will be surprised when encountering different cases. In my opinion it would be even better to avoid the confusion altogether by converting an 'sf' object to 'sp' each time it is used in conjugation with a 'raster' function, using 'as("Spatial")'. Though this makes the code a little longer and less elegant, it emphasizes the fact that 'raster' is currently compatible only with 'sp' and gives a clear universal rule for the reader, i.e. always convert to 'sp' data structure when using a vector layer inside a 'raster' function. Relying on incidental compatibility between 'raster' and 'sf' is also a little more dangerous in terms of keeping the code sections in the book up-to-date. If the underlying structure of these two packages changes, any undocumented compatibility may disappear. For documented methods this is less likely. (Unless there is something I'm missing here – such as the intention of 'raster' authors to maintain the above-mentioned compatibility and make it officially documented in the future). - Every vector object in now converted to Spatial in raster functions. We also added a text block recommending using
as(sf_obj, "Spatial")inside of the raster functions in Chapter 2.[x] 2.14 [JM] Page 125, 1st paragraph – I thought the introduction to section 5.4 mixes several concepts and thus may be unclear. First, georeferencing with ground control points and orthorectification (first two bullet points on page 125) are very common in spatial analysis, especially in remote sensing, however they are usually done in desktop GIS software such as ArcGIS or ERDAS. The process of locating control points, choosing the right transformation model, and evaluating the registration error are inherently interactive and thus unsuitable to be done with R, or any other programming language for that matter. Along with digitizing new data, this is perhaps the most notable example of a spatial analysis step that does not fit into an automated non-interactive work-flow. I think this needs to be mentioned to give a fuller picture of R's strengths and limitations in spatial analysis. - You are completely right. We state now that R is not the best choice for each step in a spatial analysis workflow especially if manual intervention is required. We now point also to Chapter 10 Bridges to GIS software where we discuss in more detail the advantages/disadvantages of using R as a GIS and a Desktop GUI.
[x] 2.14.2 [JM] Second, section 5.4 goes on to review diverse raster geometry manipulations, such as changing the extent, aggregation, resampling and vectorization. Perhaps a short introduction can introduce these operations and say when are they necessary (though some examples are given later on, such as resampling to align different rasters prior to spatial analysis). - We now explicitly state that these operations are mostly needed for aligning several images. We have added that raster aggregation is often used to decrease runtime and/or save disk space.
[x] 2.15 [JM] Page 127, 1st paragraph – Should be more specific: moving towards (0,0) starting from a cell center? Or cell corner – if so which one? - In fact, you could use any cell corner of the input raster. We now say so in the text.
[x] 2.16 [JM] Page 128, footnote – An example of temporal aggregation can also be placed in this section. Even repeating the example from the docs of function 'raster::stackApply' can be useful to demonstrate the point. - Thanks! We now point to
stackApply()in the footnote saying that the docs provide a good idea how to do a temporal aggregation.[x] 2.17 [JM] Page 129, 1st paragraph – The fact that bilinear disaggregation gives back the original raster values was not intuitively clear to me. I even felt the need to run the code and see that it is indeed correct (and it was). In practice aggregation usually leads to information loss, and the original raster can no longer be reconstructed. Perhaps replace this example with a more realistic one, such as using a raster with random values. - We completely agree with you, the example is somewhat misleading. We replaced the artificial dataset by a real-word dataset (
data("dem", package = "RQGIS")).Chapter 7 [RL]:
Chapter 8 [JM]:
mapply-loop by a simplefor-loop which makes the code chunk much more understandable.mapply(),lapply(), i.e. all the base R stuff. On the other hand, R newbies nowadays most likely encounter first the tidyverse implementations before and if at all realizing that you can do the same with base R. On the other hand,map()really does exactly the same aslapply(). Hence, we kept themap()-syntax. We now also point explicitly to sources where to look uplapply()and friends. We additionally refer to the split-apply-combine approach.clump(). This makes the workflow here so much easier!! Thanks again for pointing this out.reduce()bydo.call(ls, rbind)which at least is a bit more familiar. Thanks!Other:
library(sf); new_obj = st_as_sfc("CIRCULARSTRING(0 0, 1 1, 1 0)"); plot(new_obj)reviewer three
as(sf_obj, "Spatial")inside of the raster functions in Chapter 2.**UNCLEAR
FIXED