non-ASCII string in CRS

[Nowosad]

One of the datasets in the spDataLarge package is study_mask. I have tried to update its CRS using the idea from #1319. It works well until I check the package with CMD check, which returns warning found non-ASCII string due to the use of degree symbols.

 Warning: found non-ASCII string
(...)

      USAGE[

          SCOPE["unknown"],

          AREA["World - S hemisphere - 84<c2><b0>W to 78<c2><b0>W - by country"],

          BBOX[-80,-84,0,-78]],

      ID["EPSG",32717]]' in object 'study_mask'

Please see line 1002 at https://travis-ci.org/github/Nowosad/spDataLarge/builds/671497311#L1002.

# install.packages("spDataLarge", repos = "https://nowosad.github.io/drat/", type = "source")
library(spDataLarge)
library(sf)
#> Linking to GEOS 3.8.0, GDAL 3.0.4, PROJ 7.0.0

st_crs(study_mask)
#> Coordinate Reference System:
#>   User input: EPSG:32717 
#>   wkt:
#> PROJCRS["WGS 84 / UTM zone 17S",
#>     BASEGEOGCRS["WGS 84",
#>         DATUM["World Geodetic System 1984",
#>             ELLIPSOID["WGS 84",6378137,298.257223563,
#>                 LENGTHUNIT["metre",1]]],
#>         PRIMEM["Greenwich",0,
#>             ANGLEUNIT["degree",0.0174532925199433]],
#>         ID["EPSG",4326]],
#>     CONVERSION["UTM zone 17S",
#>         METHOD["Transverse Mercator",
#>             ID["EPSG",9807]],
#>         PARAMETER["Latitude of natural origin",0,
#>             ANGLEUNIT["degree",0.0174532925199433],
#>             ID["EPSG",8801]],
#>         PARAMETER["Longitude of natural origin",-81,
#>             ANGLEUNIT["degree",0.0174532925199433],
#>             ID["EPSG",8802]],
#>         PARAMETER["Scale factor at natural origin",0.9996,
#>             SCALEUNIT["unity",1],
#>             ID["EPSG",8805]],
#>         PARAMETER["False easting",500000,
#>             LENGTHUNIT["metre",1],
#>             ID["EPSG",8806]],
#>         PARAMETER["False northing",10000000,
#>             LENGTHUNIT["metre",1],
#>             ID["EPSG",8807]]],
#>     CS[Cartesian,2],
#>         AXIS["(E)",east,
#>             ORDER[1],
#>             LENGTHUNIT["metre",1]],
#>         AXIS["(N)",north,
#>             ORDER[2],
#>             LENGTHUNIT["metre",1]],
#>     USAGE[
#>         SCOPE["unknown"],
#>         AREA["World - S hemisphere - 84°W to 78°W - by country"],
#>         BBOX[-80,-84,0,-78]],
#>     ID["EPSG",32717]]

^{Created on 2020-04-06 by the reprex package (v0.3.0)}

[edzer]

Have you tried adding

Encoding: UTF-8

do DESCRIPTION?

[Nowosad]

I have tried it - Nowosad/spDataLarge@835287c.
Sadly, this issue is still here - Line 936 at https://travis-ci.org/github/Nowosad/spDataLarge/builds/671515610#L936.

[edzer]

I don't know. Maybe it's an idea to distribute these objects as GeoPackage files, rather than R native objects?

[edzer]

(I looked up how we did that in package units; there, we use file R/sysdata.rda, which escapes the rules of files loaded by data(xxx); I don't think that would be the solution for this package, but haven't tried)

[Nowosad]

Thanks for trying to help @edzer. PROJ5 does not save the USAGE tag (see below), so for now I will save the study_mask object with the this CRS representation.

> st_crs(study_mask) 
Coordinate Reference System:
  User input: EPSG:32717 
  wkt:
PROJCS["WGS 84 / UTM zone 17S",
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
            SPHEROID["WGS 84",6378137,298.257223563,
                AUTHORITY["EPSG","7030"]],
            AUTHORITY["EPSG","6326"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4326"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",-81],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",10000000],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AXIS["Easting",EAST],
    AXIS["Northing",NORTH],
    AUTHORITY["EPSG","32717"]]

[josesamos]

Please, how have you saved the object with this CRS representation?

I have the same problem, I don't know how to remove the non-ASCII strings from the CRS.

[Nowosad]

My temporary solution was to save CRS using a system with PROJ5. However, I have no idea what is the best approach with PROJ6 or PROJ7....

[josesamos]

Thank you! The only solution I have found for now is to save the layer using a non-projected CRS.

[edzer]

I don't know what the consequences are from stripping a wkt from its AREA field, but I would try to not do that: it solves an R problem, but may create new problems down the spatial stack (GDAL, PROJ): will two otherwise identical crs' still compare "equal" when one has the AREA field, but the other doesn't, now and in future versions of the libs? Probably, at some stage sf will also stop accepting old-style crs objects...

[Nowosad]

@edzer do you know of any way how to either: (a) remove the larger field (e.g. USAGE) - then I would try to compare how PROJ behave without it, or (b) ask PROJ not to return the USAGE field?

[edzer]

No and no, and personally I would strongly advice against either of a or b. I consider this as an idiosyncrasy of R package checking - one that may go away one day. One way out is putting data in sysdata.rda, another way is to not have your WKT in R data files. You could easily provide functions that create the datasets on the fly, e.g. by reading from external file or by combining an R object without WKT with a crs object on the fly. Examples that come to mind that do this are rnaturalearth, maps, and s2. Even sf loads nc from an external file. Binary objects stored in R packages are always at some stage out of sync with the packages that need to understand them. This is not the case when they are created.

[Nowosad]

Thanks for this comment @edzer - it is very helpful.