Reading problems are expected with raster-dependent functions if PROJ >= 6

[florisvdh]

This will affect all three read_GRTSmh***() functions, and is directly connected to rspatial/raster#78.

Due to changes in PROJ, the usage of +init=epsg:XXXX should be avoided, as listed here.

Planning to make a fix in below lines, probably similar to Nowosad/raceland@423758c - i.e. code which exports the full proj4string.

./R/GRTSmh.R:338:        crs(result) <- "+init=epsg:31370"
./R/GRTSmh.R:435:        crs(r) <- "+init=epsg:31370"
./R/GRTSmh.R:610:            crs(r) <- "+init=epsg:31370"

Note that above code already was a (temporary) workaround in order to prevent a warning, see #61.

More ideally, the above crs<- statements can be skipped: the CRS is in the files. However, because the returned proj4string did not exactly match the one of st_crs(31370), it was overwritten to prevent warnings in later processing steps.

In the long run, this will not suffice as it can be expected that raster will undergo changes as well. Also its successor terra is a package to keep an eye on.