edzer
commented
4 years ago with former versions, do you mean also former versions of sp? If so, also before 1.4.0? @rsbivand
Open Jean-Romain opened 4 years ago
edzer
commented
4 years ago with former versions, do you mean also former versions of sp? If so, also before 1.4.0? @rsbivand
Jean-Romain
commented
4 years ago Well on my Windows virtual machine my packages are not always up-to-date. In some above mentioned R versions sp was in version 1.3.x. In R 3.5.1 64 bits it is 1.3.2. In R 3.6.1 64 bits it is 1.4.1
rsbivand
commented
4 years ago Which version of rgdal, how installed? The CRAN binaries of rgdal for windows only have pre-barn workflows. With proj 6 and gdal 3, your choice of workflow will stop working. Which other packages are involved?
Roger Bivand Falsensvei 32 5063 Bergen
tir. 3. mar. 2020, 21.14 skrev Jean-Romain notifications@github.com:
Well on my Windows virtual machine my packages are not always up-to-date. In some above mentioned R versions sp was in version 1.3.x. In R 3.5.1 64 bits it is 1.3.2. In R 3.6.1 64 bits it is 1.4.1
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/edzer/sp/issues/75?email_source=notifications&email_token=ACNZ3BEGHWHVEW6BTV5XZYLRFVQLRA5CNFSM4LARTCI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENU7J7Y#issuecomment-594146559, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNZ3BA3LJFFQXZ3M75TL7LRFVQLRANCNFSM4LARTCIQ .
Jean-Romain
commented
4 years ago I'm not a windows user. I only have a virtual machine to reproduce some windows specific issues. I'm installing the packages using install.package and I'm relying on CRAN binaries. I don't actually know how and where gdal and proj are installed. Please tell me how I can get these information on Windows.
The rgdal versions were 1.4.7 (on R 3.6.1) and 1.4.8 (on R 3.5.1 and R 4.0.0).
No other package are involved. I provided a minimal reproducible example. What do you mean by with proj 6 and gdal 3, your choice of workflow will stop working
rsbivand
commented
4 years ago First, if you are a lidR developer, read https://github.com/r-spatial/discuss/issues/28 and the links there to see that your workflows need careful revision to adapt to ongoing changes in sf, sp and rgdal. Then read the output messages on attaching sf or rgdal (rgdal::rgdal_extSoftVersion() too). They display the running versions of PROJ, GDAL, etc. These may have bundled metadata files (Windows and OSX CRAN binaries do bundle metadata files).
Look carefully at:
> cat(strwrap(gsub(",", ", ", wkt)), sep="\n")
PROJCS["NAD83 (2011) / Conus Albers", GEOGCS["GCS_NAD_1983_2011",
DATUM["D_NAD_1983_2011", SPHEROID["GRS_1980", 6378137.0, 298.257222101,
AUTHORITY["EPSG", 7019]], AUTHORITY["EPSG", 1116]], PRIMEM["Greenwich",
0.0, AUTHORITY["EPSG", 8901]], UNIT["Degree", 0.0174532925199433,
AUTHORITY["EPSG", 9102]], AUTHORITY["EPSG", 6318]],
PROJECTION["Albers", AUTHORITY["Esri", 43007]],
PARAMETER["False_Easting", 0.0, AUTHORITY["Esri", 100001]],
PARAMETER["False_Northing", 0.0, AUTHORITY["Esri", 100002]],
PARAMETER["Central_Meridian", -96.0, AUTHORITY["Esri", 100010]],
PARAMETER["Standard_Parallel_1", 29.5, AUTHORITY["Esri", 100025]],
PARAMETER["Standard_Parallel_2", 45.5, AUTHORITY["Esri", 100026]],
PARAMETER["Latitude_Of_Origin", 23.0, AUTHORITY["Esri", 100021]],
UNIT["Meter", 1.0, AUTHORITY["EPSG", 9001]]], VERTCS["NAVD_1988",
VDATUM["North_American_Vertical_Datum_1988", AUTHORITY["EPSG", 5103]],
PARAMETER["Vertical_Shift", 0.0, AUTHORITY["Esri", 100006]],
PARAMETER["Direction", 1.0, AUTHORITY["Esri", 100007]], UNIT["Meter",
1.0, AUTHORITY["EPSG", 9001]], AUTHORITY["EPSG", 5703]]Can you say which dialect of WKT this is?
On my rgdal, I see:
> rgdal::rgdal_extSoftVersion()
GDAL GDAL_with_GEOS PROJ sp
"3.0.4" "TRUE" "6.3.1" "1.4-0"
> cat(rgdal::showSRID(wkt, format="PROJ", multiline="YES"), "\n")
+proj=aea +lat_0=23 +lon_0=-96 +lat_1=29.5 +lat_2=45.5 +x_0=0 +y_0=0 +ellps=GRS80 +units=m +no_defs
Warning message:
In rgdal::showSRID(wkt, format = "PROJ", multiline = "YES") :
Discarded datum NAD83_National_Spatial_Reference_System_2011 in CRS definition
> cat(rgdal::showSRID(wkt, format="WKT1", multiline="YES"), "\n")
PROJCS["NAD83 (2011) / Conus Albers",
GEOGCS["NAD83(2011)",
DATUM["NAD83_National_Spatial_Reference_System_2011",
SPHEROID["GRS 1980",6378137,298.257222101,
AUTHORITY["EPSG","7019"]],
AUTHORITY["EPSG","1116"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","6318"]],
PROJECTION["Albers_Conic_Equal_Area"],
PARAMETER["latitude_of_center",23],
PARAMETER["longitude_of_center",-96],
PARAMETER["standard_parallel_1",29.5],
PARAMETER["standard_parallel_2",45.5],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["Easting",EAST],
AXIS["Northing",NORTH]]
> cat(rgdal::showSRID(wkt, format="WKT2", multiline="YES"), "\n")
PROJCRS["NAD83 (2011) / Conus Albers",
BASEGEOGCRS["NAD83(2011)",
DATUM["NAD83 (National Spatial Reference System 2011)",
ELLIPSOID["GRS 1980",6378137,298.257222101,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["Degree",0.0174532925199433]],
ID["EPSG",6318]],
CONVERSION["unnamed",
METHOD["Albers Equal Area",
ID["EPSG",9822]],
PARAMETER["Latitude of false origin",23,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8821]],
PARAMETER["Longitude of false origin",-96,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8822]],
PARAMETER["Latitude of 1st standard parallel",29.5,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8823]],
PARAMETER["Latitude of 2nd standard parallel",45.5,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8824]],
PARAMETER["Easting at false origin",0,
LENGTHUNIT["metre",1],
ID["EPSG",8826]],
PARAMETER["Northing at false origin",0,
LENGTHUNIT["metre",1],
ID["EPSG",8827]]],
CS[Cartesian,2],
AXIS["(E)",east,
ORDER[1],
LENGTHUNIT["metre",1,
ID["EPSG",9001]]],
AXIS["(N)",north,
ORDER[2],
LENGTHUNIT["metre",1,
ID["EPSG",9001]]]] all of which drop the VERTCS[] node. It was always dropped in PROJ anyway, I think.
I can reproduce the crash on Windows 10, R 3.6.2, sp 1.4-1 and rgdal 1.4-8 (CRAN binaries), which has PROJ 4.9.3 and GDAL 2.2.3, . A work-around is to avoid going back to rgdal in sp::CRS(proj4, doCheckCRSArgs=FALSE), as the string is by default checked in PROJ. The failure occurs in compiled code in rgdal in RGDAL_checkCRSArgs(), but will take time to debug.
To just put the trusted PROJ string into the CRS object, use the work-around. We need active collaboration to find out the dialect of your WKT string, so that our current PROJ >= 6 and GDAL >= 3 workflows do not discard VERTCS[], which your data really do need.
rsbivand
commented
4 years ago On Windows 32-bit, I see:
32-bit
> proj4 = rgdal::showP4(wkt)
> proj4
[1] "+proj=aea +lat_1=0 +lat_2=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=GRS80 +units=m +no_defs "
> crs = sp::CRS(proj4) # crash
Error in sp::CRS(proj4) : conic lat_1 = -lat_2
> which is what you see sometimes (PROJ error).
64-bit
> proj4 = rgdal::showP4(wkt)
> proj4
[1] "+proj=aea +lat_1=0 +lat_2=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=GRS80 +units=m +no_defs "
> and
> proj4 = rgdal::showP4(wkt, morphFromESRI=FALSE)
> proj4
""On Linux, with recent PROJ/GDAL:
> proj4
[1] "+proj=aea +lat_0=23 +lon_0=-96 +lat_1=29.5 +lat_2=45.5 +x_0=0 +y_0=0 +ellps=GRS80 +units=m +no_defs"My best guess is that you are feeding a very modern WKT representation into an old version of GDAL/PROJ. Turning off morphFromESRI= returns an empty string on Win 64-bits predictably. So probably the logic in PROJ (4.9.3) fails if asked to morph from ESRI (the shapefile .prj WKT1 representation) when the WKT isn't 1 but newer. PROJ never returns, so the error is not trapped. PROJ 4.9.3 is not going to be patched, so no point filing a bug there; 7.0.0 was released 1 March. I'll turn all the morph*ESRI to FALSE in rgdal, but lidR and others needs to check WKT strings very carefully.
rsbivand
commented
4 years ago Roll-my-own Windows rgdal binary at http://spatial.nhh.no/R/rgdal/rgdal_1.5-6.zip (PROJ 4.9.3, GDAL 2.2.3), source at http://spatial.nhh.no/R/rgdal/rgdal_1.5-6.tar.gz. The CRS will be trashed, but it should stop crashes. Report back, please.
Jean-Romain
commented
4 years ago Can you say which dialect of WKT this is?
No. Actually I have only few knowledge about projections. I didn't even know there was some dialects of WTK. My rlas package provides the ability to read the raw content of .las and .laz files used to store laser point clouds. My lidR package provides tools to process such point clouds and it tries to transform the raw CRS read 'as is' by rlas into something that fits with the R spatial ecosystem.
In a las file, depending on the format, the CRS is either an EPSG code or a WKT string. When it is an EPSG code I'm doing
tryCatch(sp::CRS(paste0("+init=epsg:", epsg_code)), error = function(e) sp::CRS())when it is a WTK string I'm doing
tryCatch(sp::CRS(rgdal::showP4(wkt_string)), error = function(e) sp::CRS())This is (almost) all the CRS related jobs done by lidR. It belongs in those 2 lines of code. The other parts being only the transfer of the CRS from the input (a point cloud) to the outputs (raster, sp, sf objects).
My best guess is that you are feeding a very modern WKT representation into an old version of GDAL/PROJ
The .las file format 1.4 (with a WTK string) is still pretty rare but are going to be more represented. This is the second file I actually encounter. In the first one the WKT was
wkt = "COMPD_CS[\"Projected\", PROJCS[\"UTM_10N\", GEOGCS [ \"WGS84\", DATUM [ \"WGS84\", SPHEROID [\"WGS 84\", 6378137.000, 298.257223563 ], TOWGS84 [ 0.000, 0.000, 0.000, 0.0000000000, 0.0000000000, 0.0000000000, 0.0000000000 ] ], PRIMEM [ \"Greenwich\", 0.000000 ], UNIT [ \"metres\", 1.00000000] ], PROJECTION[\"Transverse_Mercator\"], PARAMETER[\"Latitude_of_Origin\",0.0000000000], PARAMETER[\"Central_Meridian\",-123.0000000000], PARAMETER[\"Scale_Factor\",0.9996000000], PARAMETER[\"False_Easting\",500000.000], PARAMETER[\"False_Northing\",0.000], UNIT [ \"metres\", 1.00000000]] ], VERT_CS[\"NAVD88 (Geoid03) ContUS\", VERT_DATUM[\"./Resources/CoordSysData/navd88_geo03_contus.bin\", 1 ], UNIT [ \"metres\", 1.00000000] ] ]"
proj4 = rgdal::showP4(wkt)
crs = sp::CRS(proj4)
crs
#> CRS arguments:
#> +proj=tmerc +lat_0=0 +lon_0=-7047.38088010913 +k=0.9996 +x_0=500000 +y_0=0 +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs First, if you are a lidR developer, read r-spatial/discuss#28 and the links there to see that your workflows need careful revision to adapt to ongoing changes in sf, sp and rgdal.
I already read those links (you reported an issue I fixed in lidR https://github.com/Jean-Romain/lidR/issues/299) but to be honest I hardly understand a third of the problem and I'm lost with all the forthcoming changes ; the current state of the art being already confusing (as I said I'm not enough knowledgeable about CRS)
The CRS will be trashed, but it should stop crashes. Report back, please.
I tried in R 3.6.1 x64 and it returned NA without crash.
rsbivand
commented
4 years ago Thanks for checking. I'll be some time before rgdal is released. The problem with the current workflows (after just glancing) is that with LAS 1.4 you will have a WKT representation with VERTCS[], but by converting to PROJ and instantiating an sp::CRS, you lose most of the important information. In principle, using development sf SetFromUserInput branch, becoming master soon, you input the WKT. For sp and PROJ >=6, GDAL >= 3, the WKT can be fed through the new SRS_string= argument to sp::CRS(), which is then used in rgdal.
Unfortunately, passing both of the WKT strings you've provided to the PROJ command line application projinfo leads to errors. There seem to be either unmatched square brackets or other issues. Are the raw LAS files available anywhere for download, with a script to read them? It feels as though either here the copies are incomplete, or that the dialect of WKT used by LAS is not for now compatible with PROJ. If the latter, I'll raise this on the PROJ developers list.
edzer
commented
4 years ago FYI, branch SetFromUserInput has just been merged in master, to be released within 2 weeks.
Jean-Romain
commented
4 years ago The las file is available here. You can read the header of the file in R with
h = rlas::read.lasheader("e1054n0839.las")
h[["Variable Length Records"]][["WKT OGC CS"]][["WKT OGC COORDINATE SYSTEM"]]
#> [1] "PROJCS[\"NAD83 (2011) / Conus Albers\",GEOGCS[\"GCS_NAD_1983_2011\",DATUM[\"D_NAD_1983_2011\",SPHEROID[\"GRS_1980\",6378137.0,298.257222101,AUTHORITY[\"EPSG\",7019]],AUTHORITY[\"EPSG\",1116]],PRIMEM[\"Greenwich\",0.0,AUTHORITY[\"EPSG\",8901]],UNIT[\"Degree\",0.0174532925199433,AUTHORITY[\"EPSG\",9102]],AUTHORITY[\"EPSG\",6318]],PROJECTION[\"Albers\",AUTHORITY[\"Esri\",43007]],PARAMETER[\"False_Easting\",0.0,AUTHORITY[\"Esri\",100001]],PARAMETER[\"False_Northing\",0.0,AUTHORITY[\"Esri\",100002]],PARAMETER[\"Central_Meridian\",-96.0,AUTHORITY[\"Esri\",100010]],PARAMETER[\"Standard_Parallel_1\",29.5,AUTHORITY[\"Esri\",100025]],PARAMETER[\"Standard_Parallel_2\",45.5,AUTHORITY[\"Esri\",100026]],PARAMETER[\"Latitude_Of_Origin\",23.0,AUTHORITY[\"Esri\",100021]],UNIT[\"Meter\",1.0,AUTHORITY[\"EPSG\",9001]]],VERTCS[\"NAVD_1988\",VDATUM[\"North_American_Vertical_Datum_1988\",AUTHORITY[\"EPSG\",5103]],PARAMETER[\"Vertical_Shift\",0.0,AUTHORITY[\"Esri\",100006]],PARAMETER[\"Direction\",1.0,AUTHORITY[\"Esri\",100007]],UNIT[\"Meter\",1.0,AUTHORITY[\"EPSG\",9001]],AUTHORITY[\"EPSG\",5703]]"I also checked the file with lasinfo from LAStools a command line software to process las files. It prints the same string so no issue from rlas itself.
PROJCS["NAD83 (2011) / Conus Albers",GEOGCS["GCS_NAD_1983_2011",DATUM["D_NAD_1983_2011",SPHEROID["GRS_1980",6378137.0,298.257222101,AUTHORITY["EPSG",7019]],AUTHORITY["EPSG",1116]],PRIMEM["Greenwich",0.0,AUTHORITY["EPSG",8901]],UNIT["Degree",0.0174532925199433,AUTHORITY["EPSG",9102]],AUTHORITY["EPSG",6318]],PROJECTION["Albers",AUTHORITY["Esri",43007]],PARAMETER["False_Easting",0.0,AUTHORITY["Esri",100001]],PARAMETER["False_Northing",0.0,AUTHORITY["Esri",100002]],PARAMETER["Central_Meridian",-96.0,AUTHORITY["Esri",100010]],PARAMETER["Standard_Parallel_1",29.5,AUTHORITY["Esri",100025]],PARAMETER["Standard_Parallel_2",45.5,AUTHORITY["Esri",100026]],PARAMETER["Latitude_Of_Origin",23.0,AUTHORITY["Esri",100021]],UNIT["Meter",1.0,AUTHORITY["EPSG",9001]]],VERTCS["NAVD_1988",VDATUM["North_American_Vertical_Datum_1988",AUTHORITY["EPSG",5103]],PARAMETER["Vertical_Shift",0.0,AUTHORITY["Esri",100006]],PARAMETER["Direction",1.0,AUTHORITY["Esri",100007]],UNIT["Meter",1.0,AUTHORITY["EPSG",9001]],AUTHORITY["EPSG",5703]]As a conclusion your advice is to use crs = sp::CRS(SRS_string = wkt). However it returns NA on my computer (Linux, R 3.6.3, PROJ6, GDAL3, sp 1.4.0, rgdal 1.4.8)
wkt = "PROJCS[\"NAD83 (2011) / Conus Albers\" [...]"
proj4 = rgdal::showP4(wkt)
crs = sp::CRS(proj4, doCheckCRSArgs = FALSE)
crs
#> CRS arguments:
#> +proj=aea +lat_0=23 +lon_0=-96 +lat_1=29.5 +lat_2=45.5 +x_0=0 +y_0=0
#> +ellps=GRS80 +units=m +no_defs
crs = sp::CRS(SRS_string = wkt)
crs
#> CRS arguments: NALAS 1.4 you will have a WKT representation with VERTCS[], but by converting to PROJ and instantiating an sp::CRS, you lose most of the important information.
To me it is not a big problem:
RasterLayer or SpatialPoints*), the PROJ format is the way and the vertical CS rarely makes sense.LAS compatible with the R spatial ecosystem.rsbivand
commented
4 years ago None of these raw strings from LAS files (1.4, WKT specified) seem to render as expected in projinfo:
COMPD_CS["Projected", PROJCS["UTM_10N", GEOGCS [ "WGS84", DATUM [ "WGS84", SPHEROID ["WGS 84", 6378137.000, 298.257223563 ], TOWGS84 [ 0.000, 0.000, 0.000, 0.0000000000, 0.0000000000, 0.0000000000, 0.0000000000 ] ], PRIMEM [ "Greenwich", 0.000000 ], UNIT [ "metres", 1.00000000] ], PROJECTION["Transverse_Mercator"], PARAMETER["Latitude_of_Origin",0.0000000000], PARAMETER["Central_Meridian",-123.0000000000], PARAMETER["Scale_Factor",0.9996000000], PARAMETER["False_Easting",500000.000], PARAMETER["False_Northing",0.000], UNIT [ "metres", 1.00000000]] ], VERT_CS["NAVD88 (Geoid03) ContUS", VERT_DATUM["./Resources/CoordSysData/navd88_geo03_contus.bin", 1 ], UNIT [ "metres", 1.00000000] ] ] PROJCS["NAD83 (2011) / Conus Albers",GEOGCS["GCS_NAD_1983_2011",DATUM["D_NAD_1983_2011",SPHEROID["GRS_1980",6378137.0,298.257222101,AUTHORITY["EPSG",7019]],AUTHORITY["EPSG",1116]],PRIMEM["Greenwich",0.0,AUTHORITY["EPSG",8901]],UNIT["Degree",0.0174532925199433,AUTHORITY["EPSG",9102]],AUTHORITY["EPSG",6318]],PROJECTION["Albers",AUTHORITY["Esri",43007]],PARAMETER["False_Easting",0.0,AUTHORITY["Esri",100001]],PARAMETER["False_Northing",0.0,AUTHORITY["Esri",100002]],PARAMETER["Central_Meridian",-96.0,AUTHORITY["Esri",100010]],PARAMETER["Standard_Parallel_1",29.5,AUTHORITY["Esri",100025]],PARAMETER["Standard_Parallel_2",45.5,AUTHORITY["Esri",100026]],PARAMETER["Latitude_Of_Origin",23.0,AUTHORITY["Esri",100021]],UNIT["Meter",1.0,AUTHORITY["EPSG",9001]]],VERTCS["NAVD_1988",VDATUM["North_American_Vertical_Datum_1988",AUTHORITY["EPSG",5103]],PARAMETER["Vertical_Shift",0.0,AUTHORITY["Esri",100006]],PARAMETER["Direction",1.0,AUTHORITY["Esri",100007]],UNIT["Meter",1.0,AUTHORITY["EPSG",9001]],AUTHORITY["EPSG",5703]] 
eliocamp
commented
4 years ago I'm having a perhaps related issue. Using sp::CRS() crashes with strange errors (probably at the C level, but I don't know enough to be sure) but only when knitting!
This is running with reprex:
proj <- sp::CRS("+proj=longlat +datum=WGS84")
proj
#> CRS arguments:
#> +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0Created on 2020-03-24 by the reprex package (v0.3.0)
But if I try to knit this document
---
title: "Untitled"
output: html_document
---
```{r}
proj <- sp::CRS("+proj=longlat +datum=WGS84")
proj
I get. `munmap_chunk(): invalid pointer`.
Strangely, if I remove the last line ("proj"), then I get a different error: `double free or corruption (out)`. Another error I get is `free(): invalid pointer`. It seems that adding or removing valid R code around `proj <- sp::CRS("+proj=longlat +datum=WGS84")` changes the error slightly, but it always fails.
I'm on Ubuntu 64bits and using the latest `sp` package from CRAN (version 1.4-1)
<details>
<summary>Session info</summary>
``` r
devtools::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#> setting value
#> version R version 3.6.3 (2020-02-29)
#> os elementary OS 5.1.2 Hera
#> system x86_64, linux-gnu
#> ui X11
#> language en_US
#> collate en_US.UTF-8
#> ctype en_US.UTF-8
#> tz America/Argentina/Buenos_Aires
#> date 2020-03-24
#>
#> ─ Packages ───────────────────────────────────────────────────────────────────
#> package * version date lib source
#> assertthat 0.2.1 2019-03-21 [1] CRAN (R 3.6.0)
#> backports 1.1.5 2019-10-02 [1] CRAN (R 3.6.1)
#> callr 3.4.2 2020-02-12 [1] CRAN (R 3.6.2)
#> cli 2.0.2 2020-02-28 [1] CRAN (R 3.6.3)
#> crayon 1.3.4 2017-09-16 [1] CRAN (R 3.6.2)
#> desc 1.2.0 2018-05-01 [1] CRAN (R 3.6.0)
#> devtools 2.2.2 2020-02-17 [1] CRAN (R 3.6.3)
#> digest 0.6.25 2020-02-23 [1] CRAN (R 3.6.3)
#> ellipsis 0.3.0 2019-09-20 [1] CRAN (R 3.6.1)
#> evaluate 0.14 2019-05-28 [1] CRAN (R 3.6.0)
#> fansi 0.4.1 2020-01-08 [1] CRAN (R 3.6.2)
#> fs 1.3.2 2020-03-05 [1] CRAN (R 3.6.3)
#> glue 1.3.2 2020-03-12 [1] CRAN (R 3.6.3)
#> highr 0.8 2019-03-20 [1] CRAN (R 3.6.0)
#> htmltools 0.4.0 2019-10-04 [1] CRAN (R 3.6.1)
#> knitr 1.28 2020-02-06 [1] CRAN (R 3.6.2)
#> lattice 0.20-40 2020-02-19 [4] CRAN (R 3.6.2)
#> magrittr 1.5 2014-11-22 [1] CRAN (R 3.6.0)
#> memoise 1.1.0 2017-04-21 [1] CRAN (R 3.6.0)
#> pkgbuild 1.0.6 2019-10-09 [1] CRAN (R 3.6.2)
#> pkgload 1.0.2 2018-10-29 [1] CRAN (R 3.6.0)
#> prettyunits 1.1.1 2020-01-24 [1] CRAN (R 3.6.2)
#> processx 3.4.2 2020-02-09 [1] CRAN (R 3.6.2)
#> ps 1.3.2 2020-02-13 [1] CRAN (R 3.6.2)
#> R6 2.4.1.9000 2020-01-21 [1] Github (r-lib/R6@8e0b318)
#> Rcpp 1.0.4 2020-03-17 [1] CRAN (R 3.6.3)
#> remotes 2.1.1 2020-02-15 [1] CRAN (R 3.6.3)
#> rgdal 1.4-8 2019-11-27 [1] CRAN (R 3.6.2)
#> rlang 0.4.5 2020-03-01 [1] CRAN (R 3.6.3)
#> rmarkdown 2.1 2020-01-20 [1] CRAN (R 3.6.2)
#> rprojroot 1.3-2 2018-01-03 [1] CRAN (R 3.6.0)
#> sessioninfo 1.1.1 2018-11-05 [1] CRAN (R 3.6.0)
#> sp 1.4-1 2020-02-28 [1] CRAN (R 3.6.3)
#> stringi 1.4.6 2020-02-17 [1] CRAN (R 3.6.3)
#> stringr 1.4.0 2019-02-10 [1] CRAN (R 3.6.0)
#> testthat 2.3.2 2020-03-02 [1] CRAN (R 3.6.3)
#> usethis 1.5.1 2019-07-04 [1] CRAN (R 3.6.1)
#> withr 2.1.2 2018-03-15 [1] CRAN (R 3.6.0)
#> xfun 0.12 2020-01-13 [1] CRAN (R 3.6.2)
#> yaml 2.2.1 2020-02-01 [1] CRAN (R 3.6.2)
#>
#> [1] /home/elio/R/x86_64-pc-linux-gnu-library/3.6
#> [2] /usr/local/lib/R/site-library
#> [3] /usr/lib/R/site-library
#> [4] /usr/lib/R/libraryWindows!= Ubuntu.
Please report the output of the startup messages when you execute library(rgdal). The specific versions of PROJ and GDAL matter, and how you installed them and rgdal itself. Please run debug(sp::CRS) and see where the branches go, and report back. Most combinations of versions of sp, rgdal, PROJ and GDAL have been tested without error, but not GDAL 3 and PROJ 5 which is not sensible.
Roger Bivand Falsensvei 32 5063 Bergen
tir. 24. mar. 2020, 23.02 skrev Elio Campitelli notifications@github.com:
I'm having a perhaps related issue. Using sp::CRS() crashes with strange errors (probably at the C level, but I don't know enough to be sure) but only when knitting!
This is running with reprex:
proj <- sp::CRS("+proj=longlat +datum=WGS84") proj
> CRS arguments:
> +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
Created on 2020-03-24 by the reprex package https://reprex.tidyverse.org (v0.3.0)
But if I try to knit this document
title: "Untitled"
output: html_document
proj <- sp::CRS("+proj=longlat +datum=WGS84") projI get. munmap_chunk(): invalid pointer.
Strangely, if I remove the last line ("proj"), then I get a different error: double free or corruption (out). Another error I get is free(): invalid pointer. It seems that adding or removing valid R code around proj <- sp::CRS("+proj=longlat +datum=WGS84") changes the error slightly, but it always fails.
I'm on Ubuntu 64bits and using the latest sp package from CRAN (version 1.4-1) Session info
devtools::session_info()
> ─ Session info ───────────────────────────────────────────────────────────────
> setting value
> version R version 3.6.3 (2020-02-29)
> os elementary OS 5.1.2 Hera
> system x86_64, linux-gnu
> ui X11
> language en_US
> collate en_US.UTF-8
> ctype en_US.UTF-8
> tz America/Argentina/Buenos_Aires
> date 2020-03-24
>
> ─ Packages ───────────────────────────────────────────────────────────────────
> package * version date lib source
> assertthat 0.2.1 2019-03-21 [1] CRAN (R 3.6.0)
> backports 1.1.5 2019-10-02 [1] CRAN (R 3.6.1)
> callr 3.4.2 2020-02-12 [1] CRAN (R 3.6.2)
> cli 2.0.2 2020-02-28 [1] CRAN (R 3.6.3)
> crayon 1.3.4 2017-09-16 [1] CRAN (R 3.6.2)
> desc 1.2.0 2018-05-01 [1] CRAN (R 3.6.0)
> devtools 2.2.2 2020-02-17 [1] CRAN (R 3.6.3)
> digest 0.6.25 2020-02-23 [1] CRAN (R 3.6.3)
> ellipsis 0.3.0 2019-09-20 [1] CRAN (R 3.6.1)
> evaluate 0.14 2019-05-28 [1] CRAN (R 3.6.0)
> fansi 0.4.1 2020-01-08 [1] CRAN (R 3.6.2)
> fs 1.3.2 2020-03-05 [1] CRAN (R 3.6.3)
> glue 1.3.2 2020-03-12 [1] CRAN (R 3.6.3)
> highr 0.8 2019-03-20 [1] CRAN (R 3.6.0)
> htmltools 0.4.0 2019-10-04 [1] CRAN (R 3.6.1)
> knitr 1.28 2020-02-06 [1] CRAN (R 3.6.2)
> lattice 0.20-40 2020-02-19 [4] CRAN (R 3.6.2)
> magrittr 1.5 2014-11-22 [1] CRAN (R 3.6.0)
> memoise 1.1.0 2017-04-21 [1] CRAN (R 3.6.0)
> pkgbuild 1.0.6 2019-10-09 [1] CRAN (R 3.6.2)
> pkgload 1.0.2 2018-10-29 [1] CRAN (R 3.6.0)
> prettyunits 1.1.1 2020-01-24 [1] CRAN (R 3.6.2)
> processx 3.4.2 2020-02-09 [1] CRAN (R 3.6.2)
> ps 1.3.2 2020-02-13 [1] CRAN (R 3.6.2)
> R6 2.4.1.9000 2020-01-21 [1] Github (r-lib/R6@8e0b318)
> Rcpp 1.0.4 2020-03-17 [1] CRAN (R 3.6.3)
> remotes 2.1.1 2020-02-15 [1] CRAN (R 3.6.3)
> rgdal 1.4-8 2019-11-27 [1] CRAN (R 3.6.2)
> rlang 0.4.5 2020-03-01 [1] CRAN (R 3.6.3)
> rmarkdown 2.1 2020-01-20 [1] CRAN (R 3.6.2)
> rprojroot 1.3-2 2018-01-03 [1] CRAN (R 3.6.0)
> sessioninfo 1.1.1 2018-11-05 [1] CRAN (R 3.6.0)
> sp 1.4-1 2020-02-28 [1] CRAN (R 3.6.3)
> stringi 1.4.6 2020-02-17 [1] CRAN (R 3.6.3)
> stringr 1.4.0 2019-02-10 [1] CRAN (R 3.6.0)
> testthat 2.3.2 2020-03-02 [1] CRAN (R 3.6.3)
> usethis 1.5.1 2019-07-04 [1] CRAN (R 3.6.1)
> withr 2.1.2 2018-03-15 [1] CRAN (R 3.6.0)
> xfun 0.12 2020-01-13 [1] CRAN (R 3.6.2)
> yaml 2.2.1 2020-02-01 [1] CRAN (R 3.6.2)
>
> [1] /home/elio/R/x86_64-pc-linux-gnu-library/3.6
> [2] /usr/local/lib/R/site-library
> [3] /usr/lib/R/site-library
> [4] /usr/lib/R/library
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/edzer/sp/issues/75#issuecomment-603528289, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNZ3BF4FTQAUMVZNBYISGDRJEUY3ANCNFSM4LARTCIQ .
Jean-Romain
commented
4 years ago I believed it was to an update of either rmarkdown itself or a lib it depends on. But @eliocamp is right rmarkdown works well. The fails is somehow related to sp or rgdal. You should open a new issue.
library(rgdal)
rgdal: version: 1.4-8, (SVN revision 845)
Geospatial Data Abstraction Library extensions to R successfully loaded
Loaded GDAL runtime: GDAL 3.0.4, released 2020/01/28
Path to GDAL shared files:
GDAL binary built with GEOS: TRUE
Loaded PROJ.4 runtime: Rel. 6.2.1, November 1st, 2019, [PJ_VERSION: 621]
Path to PROJ.4 shared files: (autodetected)
Linking to sp version: 1.3-2 It affects roxygen as well.
eliocamp
commented
4 years ago Here's the result from library(rgdal)
> library(rgdal)
Loading required package: sp
rgdal: version: 1.4-8, (SVN revision 845)
Geospatial Data Abstraction Library extensions to R successfully loaded
Loaded GDAL runtime: GDAL 3.0.4, released 2020/01/28
Path to GDAL shared files:
GDAL binary built with GEOS: TRUE
Loaded PROJ.4 runtime: Rel. 6.2.1, November 1st, 2019, [PJ_VERSION: 621]
Path to PROJ.4 shared files: (autodetected)
Linking to sp version: 1.3-2 Running with debug didn't shine much light into the issue because when run outside markdown, it all works well.
rsbivand
commented
4 years ago Try reinstalling rgdal, it was built against an earlier sp (should not help). Then try install.packages("rgdal", repos="http://R-Forge.R-project.org http://R-Forge.R-project.org")
to try the development version. This will upset your work just like sf 0.9-0, just on CRAN, and also using PROJ 6. Roger Bivand Falsensvei 32 5063 Bergen
tir. 24. mar. 2020, 23.26 skrev Elio Campitelli notifications@github.com:
Here's the result from library(rgdal)
library(rgdal) Loading required package: sp rgdal: version: 1.4-8, (SVN revision 845) Geospatial Data Abstraction Library extensions to R successfully loaded Loaded GDAL runtime: GDAL 3.0.4, released 2020/01/28 Path to GDAL shared files: GDAL binary built with GEOS: TRUE Loaded PROJ.4 runtime: Rel. 6.2.1, November 1st, 2019, [PJ_VERSION: 621] Path to PROJ.4 shared files: (autodetected) Linking to sp version: 1.3-2
Running with debug didn't shine much light into the issue because when run outside markdown, it all works well.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/edzer/sp/issues/75#issuecomment-603536961, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNZ3BFRGFFDO6UDC2I3MGDRJEXQZANCNFSM4LARTCIQ .
eliocamp
commented
4 years ago Reinstalling rgdal (with the usual install.packages from CRAN) fixed it! That was very weird.
rsbivand
commented
4 years ago Thanks. I think you've found a(nother) logic bug in sp 1.4-*, that of rgdal being stale, I'll check tomorrow. Good that re-installing helped.
Roger Bivand Falsensvei 32 5063 Bergen
tir. 24. mar. 2020, 23.36 skrev Elio Campitelli notifications@github.com:
Reinstalling rgdal (with the usual install.packages from CRAN) fixed it! That was very weird.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/edzer/sp/issues/75#issuecomment-603540225, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNZ3BDHQM5ZE6KWOUJJAYLRJEYVRANCNFSM4LARTCIQ .
Jean-Romain
commented
4 years ago Everything looks good on my side as well. Thank you it was a very annoying trouble.
This is a minimal reproducible example that crashes the R session on Windows 64 bits using
sp 1.4.1but also former versionsThis issue is related to lidR #323. For the context the WKT string was read from a LAS file format 1.4.
The bug is not always reproducible. To reproduce it with certainty I restart my virtual machine and run a fresh R session in Rstudio. If I restart an R session after a crash the code fails nicely as expected.