Open rsbivand opened 4 years ago
Thanks. I tried to reproduce these warnings (and error) in a docker container running GDAL 3.0.2 and PROJ 6.2.1 and rgdal 1.5-2. I don't see the warnings you got, but get several of this kind:
< Warning messages:
< 1: In spTransform(pts, CRS("+proj=utm +zone=29 +datum=WGS84")) :
< NULL source CRS comment, falling back to PROJ string
< 2: In spTransform(pts, CRS("+proj=utm +zone=29 +datum=WGS84")) :
< NULL target CRS comment, falling back to PROJ string
Was that to be expected?
The waarnings, yes certainly - they seem to come from pre-cooked objects (say from data()
) where the "CRS"
object is used as-is rather than regenerated as it would be if read with rgdal. If regenerated, the WKT2 comment would be added and would be used, but the warning is seen when there is no comment()
and transformation falls back onto the PROJ string for proj_create()
.
Could you destill the voluminous details to see whether you find the error I found? I cannot confirm that you are using my fork sp 1.3-3 - install R-Forge rgdal first, then my github fork sp which requires rgdal >= 1.5-1?
Thanks! With the sp fork, I get a clean check:
This is after correcting the error I found, right? Or can you not reproduce the error? If not, a change I made last night to accommodate plotKML may have cut in.
This was with fresh (Today) installs from github (sp) and r-forge (rgdal).
But had you changed the affected package from the CRAN release? Can you reproduce the error I found (non-identical crs strings - I guess 6.2.0 inserts +no_defs:
> CRS("+proj=longlat +ellps=WGS84")
CRS arguments: +proj=longlat +ellps=WGS84 +no_defs
Warning message:
In showSRID(uprojargs, format = "PROJ", multiline = "NO") :
Discarded datum Unknown_based_on_WGS84_ellipsoid in CRS definition
I checked the CRAN release. No errors here, but I can reproduce the ones you report at https://github.com/r-spatial/gstat/issues/56.
No taxidata anywhere. Re-running on my work machine by ssh, still ill at home. Error in tests still present. Further LaTeX errors (extra non-basic LaTeX packages missing). Error in:
* checking tests ...
Running ‘tracks.R’
ERROR
Running the tests in ‘tests/tracks.R’ failed.
Last 13 lines of output:
> checkDim(res, dim)
>
> # Check coercion to SpatialPointsDataFrame.
>
> res = lapply(all, function(x) as(x, "SpatialPointsDataFrame"))
There were 15 warnings (use warnings() to see them)
> checkClass(res, "SpatialPointsDataFrame")
> dim = c(7, 5, 6, 6, 12, 12, 24)
> checkDim(res, dim)
>
> # Check proj4string methods.
>
> stopifnot(all(sapply(all, function(x) proj4string(x) == "+proj=longlat +ellps=WGS84")))
Error: all(sapply(all, function(x) proj4string(x) == "+proj=longlat +ellps=WGS84")) is not TRUE
Execution halted
Go to tests/track.R, do until all
created:
> sapply(all, proj4string)
[1] "+proj=longlat +ellps=WGS84 +no_defs" "+proj=longlat +ellps=WGS84 +no_defs"
[3] "+proj=longlat +ellps=WGS84 +no_defs" "+proj=longlat +ellps=WGS84 +no_defs"
[5] "+proj=longlat +ellps=WGS84 +no_defs" "+proj=longlat +ellps=WGS84 +no_defs"
[7] "+proj=longlat +ellps=WGS84 +no_defs"
> unique(sapply(all, proj4string))
[1] "+proj=longlat +ellps=WGS84 +no_defs"
> stopifnot(all(sapply(all, function(x) proj4string(x) == "+proj=longlat +ellps=WGS84")))
Error: all(sapply(all, function(x) proj4string(x) == "+proj=longlat +ellps=WGS84")) is not TRUE
What is difficult here? Re-do after re-installing rgdal with Tom's mess from yesterday:
> unique(sapply(all, proj4string))
[1] "+proj=longlat +ellps=WGS84 +no_defs"
> stopifnot(all(sapply(all, function(x) proj4string(x) == "+proj=longlat +ellps=WGS84")))
Error: all(sapply(all, function(x) proj4string(x) == "+proj=longlat +ellps=WGS84")) is not TRUE
If you are running this on the correct basis, you cannot pass the test, because:
> crs = CRS("+proj=longlat +ellps=WGS84")
Warning message:
In showSRID(uprojargs, format = "PROJ", multiline = "NO") :
Discarded datum Unknown_based_on_WGS84_ellipsoid in CRS definition
> crs
CRS arguments: +proj=longlat +ellps=WGS84 +no_defs
> comment(crs)
[1] "GEOGCRS[\"unknown\",DATUM[\"Unknown based on WGS84 ellipsoid\",ELLIPSOID[\"WGS 84\",6378137,298.257223563,LENGTHUNIT[\"metre\",1],ID[\"EPSG\",7030]]],PRIMEM[\"Greenwich\",0,ANGLEUNIT[\"degree\",0.0174532925199433],ID[\"EPSG\",8901]],CS[ellipsoidal,2],AXIS[\"longitude\",east,ORDER[1],ANGLEUNIT[\"degree\",0.0174532925199433,ID[\"EPSG\",9122]]],AXIS[\"latitude\",north,ORDER[2],ANGLEUNIT[\"degree\",0.0174532925199433,ID[\"EPSG\",9122]]]]"
that is, crs
in the test is not being created using sp 1.3-3 (my fork). Do debug(CRS)
to see where it goes. You seem to be branching back to:
Browse[2]> rgdal::checkCRSArgs("+proj=longlat +ellps=WGS84")
[[1]]
[1] TRUE
[[2]]
[1] "+proj=longlat +ellps=WGS84"
Which of:
packageVersion("rgdal") < "1.5.1"
or
!rgdal::new_proj_and_gdal()
is TRUE for you?
The test in trajectories can only pass if both are TRUE, I think, and your declared setting should send the PROJ string to rgdal::checkCRSArgs_ng()
, not rgdal::checkCRSArgs()
.
It was something else, but I found the problem now.
I'm not sure that it is easy to check for equality without pushing the test string out through the same runtime normalisation procedure, something like:
slot(crs, "projargs") == slot(CRS("+proj=longlat +ellps=WGS84"), "projargs")
which then uses the runtime CRS in play (old and new should both work) - that is do not test just string values without passing them through the constructor (same for st_crs()
). We still have a problem with coverage and tests (a fetish IMO) if the CRS/crs are stored in an rda/rds object, so not generated with the same runtime representation.
This also works:
> comment(crs) == comment(CRS("+proj=longlat +ellps=WGS84"))
[1] TRUE
Warning message:
In showSRID(uprojargs, format = "PROJ", multiline = "NO") :
Discarded datum Unknown_based_on_WGS84_ellipsoid in CRS definition
Looks like renaming all +ellps=
to +datum=
, and skipping literal proj4string
identicals, did the job. Will try gstat next.
Won't this only work for +datum=WGS84
? We know that only WGS84, NAD83 and NAD27 are permitted at present; I don't know that this will continue unconditionally. I feel that to avoid having to come back to this each time PROJ tightens PROJ string handling, we can't rely on what may work now. We know that importFromProj4()
is asymmetric re. exportToProj4()
, and I've also found that proj_create()
is picky (does not like +init=
in the instantiation string).
I agree that we need to skip literal proj4string identicals.I don't yet see a clear path to testing equality.
* checking examples ... OK
* checking for unstated dependencies in ‘tests’ ... OK
* checking tests ... ERROR
Running ‘tracks.R’
Running the tests in ‘tests/tracks.R’ failed.
Last 13 lines of output:
> checkDim(res, dim)
>
> # Check coercion to SpatialPointsDataFrame.
>
> res = lapply(all, function(x) as(x, "SpatialPointsDataFrame"))
There were 15 warnings (use warnings() to see them)
> checkClass(res, "SpatialPointsDataFrame")
> dim = c(7, 5, 6, 6, 12, 12, 24)
> checkDim(res, dim)
>
> # Check proj4string methods.
>
> stopifnot(all(sapply(all, function(x) proj4string(x) == "+proj=longlat +ellps=WGS84")))
Error: all(sapply(all, function(x) proj4string(x) == "+proj=longlat +ellps=WGS84")) is not TRUE
Execution halted
with GDAL 3.0.4 and PROJ 6.3.0
Current github master resolves error.
Running revdep checks for current rgdal on R-Forge - see:
https://stat.ethz.ch/pipermail/r-sig-geo/2019-November/027801.html
shows the errors in the attached test log, related to use of PROJ&/GDAL3 and required changes to sp and rgdal. If useful find a regerence to a docker image in this thread:
https://github.com/r-spatial/discuss/issues/28
Changes will occur quite fast, and packages need to be prepared.