wradlib / wradlib-docs

wradlib documentation

README

wradlib is designed to assist you in the most important steps of processing weather radar data. These may include: reading common data formats, georeferencing, converting reflectivity to rainfall intensity, identifying and correcting typical error sources (such as clutter or attenuation) and visualising the data.

To anyone who wants to use a bleeding edge version of wradlib from this repository:

wradlib uses GitHub Actions for Continuous Integration. This means that once new code is pushed to the wradlib repository, a suite of tests and checks are run. In case the tests run without failure, a new documentation will be built on readthedocs and is available at the wradlib documentation website.

Below you see the status of wradlib. A green status indicates that the current revision of wradlib did pass the tests successfully. You should be aware of that a green status is not a guarantee that the latest revision is bug free. It just means that our tests did not find any bugs. Also, the status of code coverage, of ReadTheDocs documentation builds and of availability of wradlib conda package is displayed.

Package Status

Item	Status
Github Latest
Github Release
Codecov
RTD Latest
RTD Stable
Anaconda Latest
Anaconda Version

Documentation

For further information on wradlib (getting started, library reference, development setup, ...), please see our homepage:

https://wradlib.org

Specific information for developers is available via the wradlib-wiki.

Citing wradlib

You can cite wradlib using the DOI below, or select the fitting zenodo DOI if you want to cite a distinct wradlib version by following the link.

User forum

In order to stay tuned, we recommend that you register to the openradar discourse.

Found any bugs or want to add wishes

Create an issue here.

wradlib-docs's Issues

Use no conda in rtd build

As we do not need to execute wradlib code (besides install stuff), we are mocking out those dependencies. Unfortunately the creation of the conda env consumes quite some time. My suggestion would be to step back to a pip only solution and relying on some packages from the rtd install. This speeds up the build process significantly.

ENH: Cutting Releases

The docs are rendered at readthedocs. The correct tag setup need to be created there. For rendering the docs wradlib is installed from the strip1.0.0-branch at the moment.

After switching branches in wradlib (strip1.0.0 -> master) wradlib need to be installed from master branch. In normal operation nothing is changed and latest will be created.

If we have a wradlib tagged release, we want to create dedicated tagged docs using the rendered wradlib-notebooks from the named render branch (eg. 1.0.0). This can be done by creating a tagged release here too (same as wradlib-version).

If readthedocs runs for a tagged release, the correct wradlib-tag gets installed and the correct rendered wradlib-notebooks branch is fetched.

Proposal:

• wradlib release tag: 1.0.0 (considering semver)
• wradlib-notebooks branch: 1.0.0
• wradlib-docs release tag: 1.0.0 (considering semver).

Following this proposal we just have to create a tagged release and the correct wradlib-release and the correct wradlib-notebooks branch will be installed to create the final docs.

Using this scheme, this can be reproduced any time.

Conda activation

Since conda 4.4.0 (released december 2017) the activation process has been reworked. This should be reflected in the docs.

Change notebook links to point to correct version

Currently we have hyperlinks in the notebooks pointing to the latest compiled wradlib documentation. For the notebooks (in wradlib-notebooks) this is probably the best solution always pointing to the latest available compiled docs.

For the docs itself it is somewhat counterintuitive if you link from the stable version to latest. The suggestion would be to identify these links (they all begin with https://docs.wradlib.org/en/latest/) and correct them to the needed version. This can be done within conf.py where the correct version is already identified.

Thoughts?

Add section of wradlib usage

• in organizations
• in projects
• in papers etc.
• etc.

Revise documentation for wradlib v1.19

The documentation has aged a bit. Some sections could be removed and some sections need update.

• Anaconda/Miniconda/Miniforge
• Bleeding edge code available on testpypi
• Installing via pip
• Dependencies / optional dependencies
• Jupyter HowTo notebook
• Bibliography