add function read_raster_runif

[ToonHub]

I added the function read_raster_runif.

[florisvdh]

Thanks for preparing the function @ToonHub! Nice work.

I propose some small updates in PR #138, where I suggest to drop suppressWarnings() because those warnings are not irrelevant to the user (a proj4string for EPSG:31370 is included in the returned object but it is degraded and should not be used). Instead, a package startup message has been created to give some advice. The rgdal warnings are expected to go away in the future.

[florisvdh]

👍

Fixes #134.

[florisvdh]

Any comments on my proposed pkg startup message? @ToonHub @cecileherr or others?

> library(n2khab)
Attaching n2khab version 0.4.0.9000.

When working with raster objects returned by n2khab, you can safely
mute proj4string degradation warnings:

options(rgdal_show_exportToProj4_warnings = "none")

You must do this before using the n2khab functions depending on 
rgdal or raster, and before loading the latter (or sp).

Do note that those warnings are applicable: the generated proj4string
of 'EPSG:31370' objects is effectively degraded and should not be used.
See https://inbo.github.io/n2khab/#suppressing-rgdal-warnings-about-proj4string-degradation
for more information.

[ToonHub]

Good idea to mention this.

the generated proj4string of 'EPSG:31370' objects is effectively degraded and should not be used.

Is the sentence above correct? I do not really understand what you mean.

[florisvdh]

Is the sentence above correct?

Your question is reason enough to improve it 😉.

Suggestion:

Do note that those warnings are applicable: the proj4string in the
returned raster objects is effectively degraded and should not be used.

Is this more clear? 'is degraded' refers to 'the proj4string'

[florisvdh]

Or:

Do note that those warnings are applicable: in the returned raster
objects, the proj4string is effectively degraded and should not be used.

[ToonHub]

OK. It is more clear now.

[florisvdh]

I'll add an updated message here, thanks.

@ToonHub I also suggest not to include the version and directory specific reference to the n2khab-preprocessing repo. It is done at Zenodo, but there it is for specific data source versions. Here I'd strive to minimal future maintenance of documentation (version independence, directory independence). I'll update according to the approach in other functions.