General information

Aim and purpose

The goal of the project is to implement a GIS analysis using FOSSGIS software in an automated way using QGIS model builder or scripts. During the project you will learn and practice how to …

• implement a GIS analysis in an automated way.

• find suitable open data and FOSSGIS tools for your analysis

• compare different FOSSGIS tools to select a suitable one for your task.

• present and defend your results and methodology.

• discuss the limitations and uncertainties of your own and others GIS analyses.

The projects should be done in groups of 2 students.

Project groups

Please check the group project table for information on the presentation dates and the assigned feedback groups.

Project Deliverables and time schedule

Item	Description	Format	Due
Form Groups			27.11.
Proposal	Project idea + implementation plan	.md	2.12.24
Presentation	15 minute presentation + 10 min questions	.pdf	15.1. - 29.1.
GitLab/GitHub Repository	Models, scripts and documentation	GitLab	15.4.
Blog Post	Documentation of the project results as .md or pdf file.	GitLab	15.4.
Code review	3 issues for bugs, questions and suggestions on GitLab	GitLab	15.4.

1. Proposal

Describe your project idea and potential implementation plan in bullet points (max. 1 page). See template. After submission, each group will discuss their project proposal with one of the course instructors for 15-20 minutes. Submisson via GitLab, see instructions.

2. Presentation

This is only an interim presentation, so your analysis does not need to be finished. But you should have at least implemented a part of your analysis so your feedback group can test your model or script.

• 15 minute presentation, followed by 10 min questions/discussion

Content: For example

1. General idea

2. Brief overview of the method and data

3. Current state

4. Challenges and current problems

There will be another project group assigned as a feedback group. They will ask questions after the presentation and review the repository

3. Project documentation

The documentation of your project is divided into two parts:

1. Blog post: Summary of what you did, why and what you found out targeted at non-GIS experts, i.e., someone who just wants to know what you found out.

2. GitLab/GitHub repository: Details on your method and implementation targeted at GIS experts, i.e., some one who would like to reproduce your analysis.

3.1 Blog Post

The final report should not follow the classical scientific paper format. Instead, you should write a blog post targeted at readers with little to no GIS knowledge. This means, leave out details of the method and implementation which are not relevant for the reader to understand the results of the project. These details should be contained in your project’s GitLab repo. So the blog post should contain a more general description of what you did.

Format

• 1000 to 1500 words

• Markdown file or pdf contained in your git repository

Suggested structure

1. Introduction: Give background information, describe the problem/question (why is it relevant?) and explain what your goal/research question is

2. Method: Only include the parts of the method which are essential for the reader to understand the results of your project. So leave out unnecessary details about the implementation. Write it in a way that can (more or less) be understood by people with no or little GIS knowledge. If applicable, you may add links to the documentation in your git repository so readers can find more details.

3. Results: Describe your results with suitable and well designed figures. Interpret your results and explain what they mean in regard to your initial task/question.**

4. Conclusion: What is your conclusion? What did you learn? What are the next steps?

Examples

Here are some examples from the GIScience Research Group Blog, so you get an idea, but you do not have to stick to their structure.

• High-resolution maps of carbon dioxide emissions

• Exploring the Value of Microsoft ML Roads for OSM Data Quality Analysis

3.2 GitHub/GitLab repository

The feedback group and other students/users should be able to execute your scripts/models to reproduce your results. Create a GitLab (or GitHub) repository in which you document your method as well as your implementation (e.g. scripts, QGIS models). Your target audience are GIS people.

Your repository may be structured like this:

• README.md: The readme should give the user an overview of what the program does, how to install it and how to use it. You may use this README Template to get started. It should contain at least the following sections.

  • General information about the project

  • Software requirements including versions

  • How to install the required software

  • How to run your scripts/models

• documentation: Folder which contains one or several markdown files, in which you describe your methodology in more detail than you describe it in the blog post. Please document your methodology in a way that it can be understood and reproduced by people with GIS knowledge, but without giving a click-by-click tutorial.

• scripts: Folder containing all scripts, make sure they are properly formatted (e.g. use comments)

• models Folder containing all QGIS models, make sure they are properly formatted

• sample_data: Folder containing some small sample data so the user can test the program. Should not be larger than 50MB. Otherwise provide them via HeiBox.

• blog_post: Add your blog post as .md or .pdf (see section 3.1. Blog post)

IMPORTANT ADVICE: Designate one person create and upload/edit data in the repo to avoid having conflicts when mulitple people edit the same files on gitlab

Here are two examples from the previous year:

• ResChecker

• Air Quality Index in Delhi

4. Code review by feedback group

As soon as the presenting group has published a first model or script, the designated feedback group will give them feedback on it, so you learn how to describe your method and implementation in way that others are able to understand and use it.

Tasks:

• Execute the scripts/models provided in the git repository to reproduce the results.

• Create at least 3 issues in the GitHub repo to report bugs, give advice what to improve or ask questions about the methodology/implementation.

5. Option for 5 ECTS

By default you get 4 ECTS for this course. For 5 ECTS, you can do the following bonus task: Create a website of your blog post using GitHub Pages.

Your task is to publish the blog post of your final project as a public website using GitHub Pages, which basically lets you host websites for free on GitHub.

Follow these steps:

1. Create a GitHub account

Create a free GitHub account if you don’t have one yet.

2. Create a new GitHub repository

Create a new empty repository on GitHub. Add the markdown file of your blog post to the repository.

3. Turn your GitHub repository into a website

Turn your GitHub repository into a simple website following these instructions. Make sure that your website including figures is appropriately formatted.