We should consider to store the data files outside the repo if they are not necessary for rendering the workshop documentation. Data files might, with the time, make the size of the repo very big and cloning it will be come slow.

Originally posted by @manuGil in #1 (comment)

Thanks @manuGil for pointing this out. I opened an issue for this.

• Instructors update the four lessons in PRs according to the feedback before the end of March mid-May
  • Part 1 - intro to R
  • Part 2 - vector data
  • Part 3 - raster data
  • Part 4 - OSM & GIS
• The team reviews the updates (reviewers assigned in the PRs) before mid-April end of May

The cheatsheet will be a handout with all functions, terms, and guidelines that participants can refer back to during the workshop. It should be concise, comprehensive and clear. We can use visuals as in package cheatsheets (see sf cheatsheet for instance).

Let's keep this issue open to collect ideas while working on the cheatsheet.

Consider restructuring the setup page around operating systems rather then tools, as suggested by @manuGil in #4 (comment)

We can do this after the workshop in Feb. '24

I am documenting here an issue I came across while trying to build the intro lesson. The build process would throw an error when trying to install the required Matrix package. The error is in the log shown in the Build panel. While searching for a solution, I learned that this is an issue on macOS with Apple M1 processors, so people working on Windows or Intel-based macs might not experience it.

The solution, as described here:

1. Create a file ~/.R/Makevars (if it does not exist yet)

2. Add the following to ~/.R/Makevars

FC      = usr/local/opt/gcc/bin/gfortran
F77     = /usr/local/opt/gcc/bin/gfortran
FLIBS   = -L/usr/local/opt/gcc/lib

3. Restart R

4. The installation of the package should not be an issue during the build process anymore. You can also try to install the failing package (in my case Matrix) manually from source by calling install.packages("Matrix", type = "source")

Create a template out of the workshop script considering our experience, feedback received and updated content.

• all code used in the lesson should follow the tidyverse style guide
• we should agree on a pipe operator (native or magrittr) and use it consistently throughout the lesson

Once we ready to share the lesson with The Carpentries community, we can gain more visibility by:

• submitting it to the Incubator Lesson Spotlight;
• writing a blog post on The Carpentries Blog;
• advertising the lesson on various mailing lists.

• Include Arch and Fedora as OS's in test setup workflow
• Apply catching to workflow

I started collecting feedback from lesson-level PRs that apply across lessons in the form of a checklist:

• #9

  • Lesson 1
  • Lesson 2
  • Lesson 3
  • Lesson 4

• questions are written in first person

• the same phrasing is used for objectives

• #10

• harmonise naming of exercises/challenges and precede all challange callout headings with Challenge:

  • Lesson 1
  • Lesson 2
  • Lesson 3
  • Lesson 4

Good to have, but not essential:

• all code chunks should have a unique name (unnamed chunks are auto-named by default)
  • Lesson 1
  • Lesson 2
  • Lesson 3
  • Lesson 4

          > Should we add GIS resources here or in the pre-workshop email?

I suggest we include resources in the lesson websites and maybe collect and share them at the end of the workshop. I open an issue on this.

Originally posted by @cforgaci in #1 (comment)

This is a list of the main updates we need to make based on the feedback and our reflection on the GDCU workshop in Feb. 2024. Each item in the list is a separate issue with assignees.

• #37
• #35
• #34
• #33
• #36

I made a figure illustrating the digital height canopy model. I thinks this illustrates it in a slightly better way. What do you think? How can I improve on it?

Originally posted by @manuGil in #3 (comment)

In future runs of the workshop, we can make the icebreaker into something more interactive, like @ClementineCttn and I did in a TTPT seminar we gave some time ago. More than an icebreaker, this can also be an extra motivation to use R.

See ClementineCttn/BK-TT-Rbanism and this issue in particular: ClementineCttn/BK-TT-Rbanism#3

Update setup instructions according to the feedback received and issues observed during the workshop:

• Installation information is shown both in the table at the top of the setup page and in the callout blocks further down on the page. To avoid confusion, remove the table and make sure installation instructions are easily found in one place.
• Specify versions of all software to be installed as well as system requirements (e.g., minimum OS versions)
• Test new setup instructions on macOS, Windows and Linux
• Consider also #11

While following the instruction to install depentences here:https://carpentries-incubator.github.io/r-geospatial-urban/

The following error occurs int he last installation call using brew: (MacOS Sonoma)

$ brew install gdal2
Warning: Formula gdal2 was renamed to osgeo/osgeo4mac/osgeo-gdal.
Warning: Formula gdal2 was renamed to osgeo/osgeo4mac/osgeo-gdal.
Error: osgeo/osgeo4mac/osgeo-gdal: Invalid bottle tag symbol

The following worked. There is a typo on the name of the formula
$ brew install gdal

          Use city names here

Originally posted by @cforgaci in #5 (comment)

I noticed that some headings do not render well when they include a code bloke.
For example, the following Rmarkdown snipped produces a heading without white spaces between sf and adjacent words:

# The `sf` package

`sf` stands for Simple Features which is a standard defined by the Open Geospatial Consortium for storing and 
accessing geospatial vector data. PostGIS uses the same standard; so those of you who used PostGIS, might
find some resemblances with the functions used by the `sf` package. 

Results:

The core of the issue is that the Rmarkdown parser removes any white spaces at the beginning and end of a string surrounded by backticks (`). Explained here

I tried several ways to trick the parser, but they did not work. Notice this only affects the headings and not the paragraph below the heading. This might be because headings and paragraphs have different styles.

I suggest we avoid using code blocks in the headings so that white spaces are rendered properly. For example, using # The 'sf' Package instead. Note that this will rendered the heading using uppercase (that's define by the style template), but it will maintain the white spaces.

We can offer this as an alternative to those who want to use a datastet that is more relatable for their participants.

@tobyhodges, while populating the repository with our updated lessons, I am experiencing issues with building the workshop website at the Setup Package Cache step.

I am pasting in the last lines of output from that step:

  - Downloading mgcv from CRAN ...                OK [file is up to date]
  - Downloading nlme from CRAN ...                OK [file is up to date]
  - Downloading DBI from CRAN ...                 OK [file is up to date]
  - Downloading MASS from CRAN ...                	ERROR [curl: (22) The requested URL returned error: 404]
  ---
  Standard error:
  → Searching for and installing available dependencies
  → Restoring any dependency versions
  ---
  Backtrace:
  1. base::tryCatch(sandpaper::manage_deps(path = wd, quiet = FALSE), error = functio…
  2. base::tryCatchList(expr, classes, parentenv, handlers)
  3. base::tryCatchOne(expr, names, parentenv, handlers[[1L]])
  4. global value[[3L]](cond)
  5. sandpaper::manage_deps(path = wd, quiet = FALSE)
  6. callr::r(func = callr_manage_deps, args = args, show = !quiet, …
  7. callr:::get_result(output = out, options)
  8. callr:::throw(callr_remote_error(remerr, output), parent = fix_msg(remerr[[3]]))
  ---
  Subprocess backtrace:
   1. renv::restore(project = path, library = renv_lib, lockfile = renv_lock, …
   2. renv:::renv_restore_run_actions(project, diff, current, lockfile, rebuild)
   3. renv:::retrieve(packages)
   4. local handler(package, renv_retrieve_impl(package))
   5. renv:::renv_retrieve_impl(package)
   6. renv:::renv_retrieve_repos(record)
   7. (function() { …
   8. base::warning(error)
   9. base::withRestarts({ …
  10. base::withOneRestart(expr, restarts[[1L]])
  11. base::doWithOneRestart(return(expr), restart)
  12. global (function (e) …
  Execution halted
  Error: Process completed with exit code 1.

I did notice a failed check while merging the lesson PR, but I thought I could solve it afterwards. The same failed check is visible in the PR of another lesson.

You should also be able to see the output of the workflow directly: https://github.com/carpentries-incubator/r-geospatial-urban/actions/runs/7695754050

What can I do to make this check pass? Thanks in advance and please let me know if I can provide more info!

@KyriJanssen, @fcjerome, can you add your workshop slides in instructors\4-gis-slides.qmd, please? If you do not have your slides in quarto you can do this by creating a new quarto file, pasting in the content of my slides and then adapting it with your content. Let me know if you need help with this.

Originally posted by @cforgaci in #5 (comment)

I saw that you started to assign stars to challenges. Can you make an overview of all the challenges of the workshop and list the stars here? Thanks!

Update the data and values in lesson 1 to more urban datasets. Make sure that the data is in English, anticipating the use of the lesson outside NL as well.