404
+ +Page not found
+ + +diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 0000000..e69de29 diff --git a/404.html b/404.html new file mode 100644 index 0000000..242cc63 --- /dev/null +++ b/404.html @@ -0,0 +1,136 @@ + + + +
+ + + + + + + +Page not found
+ + +If this is the first time you want to use this template, please go through the Github training first. This will give you the neccesary background knowledge to understand what is happening here.
+Use this as template when you start a new project by clicking "Use this template" in the top right.
+Then follow all the descriptions below.
+All code written for ALLFED should follow the PEP 8 Style Guide for Python. Especially important are: +* Keep the code well documented +* Every function needs a docstring in this form:
+def count_line(f, line):
+ """
+ Counts the number of times a line occurs. Case-sensitive.
+
+ Arguments:
+ f (file): the file to scan
+ line (str): the line to count
+
+ Returns:
+ int: the number of times the line occurs.
+ """
+
+.py
files. To make this easier you can use linter (auto-formatter) that change your code to be formatted in PEP 8 when you safe it. E.g. here for Spyder or VS Code.
+We want to create reliable code. This means, as much of the code needs to be automatically tested, to make sure that everything runs as intended. Therefore, every reasonable function should have some kind of assert
that tests if it works. We use pytest pytest as our main test suit. All tests that you put in the tests folder in here are automatically run every time you push code. You can read more about testing here. To adapt the testing.yml to your repository you just have to adapt the requirements in requirements.txt. Everything else should work on its own. You can find an example of how a test file should look like in the tests folder. Once you go the testing set up, also make sure to add the testing badge to the readme of your repository. Simply change the URL to your repository in this badge:
You don't have to test every possible function. Just make sure that those are tested where you are doing custom analysis.
+Documenting your code is only one part of the documentation we want to create. Every larger repository needs: +* a readme file that explains what the repository is for and how it is organized, which should contain: + - A one-sentence description of your project + - A longer description of your project + - Installation instructions + - General orientation to the codebase and usage instructions + - Links to papers + - Links to extended docs + - License
+All the things for the small projects, but also:
+* An automated documentation via Gitub Actions. This is already set up in this repository. Is uses the code from this post and combines it with this one. It also is setup that it will only look for python files in the src folder. So, make sure that everything is in there (you can changes this behavior in the main function of automate_mkdocs.py
). To get it running do the following
+ * Change the names in mkgendocs.yml
and mkdocs.yml
so they fit your repository
+ * go to Settings --> Pages
+ * select deploy from a branch as source
+ * select gh-pages as branch at root (for this option to pop up the docs.yml
file has to have run succesfully at least once, this should happen when you push anything in your repository)
+ * The end result will look something like this
+ * The automated documentation part is still a bit wip, if you run into problems contact florian@allfed.info
+* Create a visual representation of how the different files interact with each other
Every time you come across a problem that you do not plan to fix in the next day, please open an issue in the repository to make sure that it does not get lost. This also allows you to assign tasks to other coders on the team. For a short intro to issues, see here.
+All ALLFED repositories should be citable by release. For this we use Zenodo. This has to be activated by an Admin (so either Florian or Morgan). Once you have a manuscript where you need to cite the repository let them know and they will activate it. This will also create a doi badge, which should be included in the readme, like this:
+All plots created for ALLFED should look and feel the same. You can activate the ALLFED style by simply starting your code with:
+plt.style.use("https://raw.githubusercontent.com/allfed/ALLFED-matplotlib-style-sheet/main/ALLFED.mplstyle")
If you need to create your plots in ALLFED style, while being offline just download the file and change the path to local.
+For published maps we use the Winkel Tripel projection. You can use it by reprojecting the CRS of your data on geopandas to +proj=wintri
. The function in the example below can be used to include a border on your map, and modify the ALLFED plotting style to make sense for a map plot.
# Add border to map, remove gridlines and ticks (after activating ALLFED style)
+def plot_winkel_tripel_map(ax):
+ border_geojson = gpd.read_file('https://raw.githubusercontent.com/ALLFED/ALLFED-map-border/main/border.geojson')
+ border_geojson.plot(ax=ax, edgecolor='black', linewidth=0.1, facecolor='none')
+ ax.set_axis_off()
+
+world = gpd.read_file(gpd.datasets.get_path('naturalearth_lowres')) # Example world dataset
+world = world.to_crs('+proj=wintri') # Change projection to Winkel Tripel
+
+ax = world.plot() # Plot the map
+plot_winkel_tripel_map(ax) # Modify style and add border
+plt.show()
+
+The result should look like this:
+ +Important note: The Winkel Tripel projection is a compromise projection used purely for visuals. It is not equal-area, conformal, or equidistant. This means that the areas, angles, and distances are not preserved. We use this projection to make our maps as easy to read as possible, but if you need to do any calculations on the map, you need to use a different appropriate projection to get the correct results. To learn more about map projections with geopandas, see here.
+This repository already has the folder structure we use for repositories. Every folder has an additional readme, to tell you what needs to go in there.
+For some repositories it makes sense to make them installable via pip (e.g. a model we want to share easily). In this case you can use the explanation here. This repository already contains a setup.py that can be used for that. If you want to install it to your local environment just run pip install -e .
while being in the folder that contains setup.py.
Every ALLFED project is run in its own virtual environment. Therefore, every project needs an environment.yml
file. The one in this repository is only an example and should not be used for any actual project. To create and organize virtual environments we use conda.
Please make sure to include version numbers in your environment.yml
. Otherwise it will be really annoying to get it to run again in the future.
Every ALLFED project needs a requirements file that specifies what packages are needed to run the project. You can find an example file in the repository. If you use a lot of packages you can use pipreqg to find them all.
+ALLFED publishes its code in Open Access. For this we use the Apache 2.0 License. This license allows very free use of the code, but makes sure that ALLFED cannot be sued if something goes wrong with the code. The license template in this repository needs to be adapted when a new project is created. You can include the following license badge in your readme:
+ +The .gitignore file is the default one for Python. Make sure you change it when using another programming language.
+This is strongly based on the "Good Research Code Handbook". If something here confuses you, it makes sense to read about it there. Pretty good explanations.
+ +.load_config(
+ config_path
+)
+
+Load and return the configuration from the specified YAML file.
+.get_file_stats(
+ directory
+)
+
+Calculate statistics for CSV files in the given directory.
+.generate_overview(
+ config_path, output_dir
+)
+
+Generate an overview of GCR research based on config and CSV files.
+ +