[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39204: r-rgdal: Reading of vector GIS data causes segfault
From: |
zimoun |
Subject: |
bug#39204: r-rgdal: Reading of vector GIS data causes segfault |
Date: |
Fri, 21 Feb 2020 19:53:22 +0100 |
Hi Arun,
On Thu, 20 Feb 2020 at 18:11, Arun Isaac <address@hidden> wrote:
> > 2. a regression of r-rgdal introduced by your commit
> > f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
>
> Replacing proj.4 with proj in the r-rgdal package seems to fix this
> regression. Can you confirm?
You mean:
guix build --with-input=proj.4=proj r-rgdal
then it compiles a lot... and I do not understand why gdal is
recompiled. Anyway!
So after some CPU burning, I get:
--8<---------------cut here---------------start------------->8---
Testing examples for package ‘rgdal’
Running specific tests for package ‘rgdal’
Running ‘srs_rendering.R’
comparing ‘srs_rendering.Rout’ to ‘srs_rendering.Rout.save’ ...
5c5
< [1] "Rel. 6.2.0, September 1st, 2019, [PJ_VERSION: 620]"
---
> [1] "Rel. 6.0.0, March 1st, 2019, [PJ_VERSION: 600]"
7c7
< [1] "GDAL 3.0.2, released 2019/10/28"
---
> [1] "GDAL 2.4.0, released 2018/12/14"
11c11
<
scot_BNG
---
>
>
> trin_inca_pl03
12c12
< "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000
+y_0=-100000 +ellps=airy +units=m +no_defs"
---
>
>
> NA
13c13
<
trin_inca_pl03
---
>
>
> kiritimati_primary_roads
14c14
<
NA
---
>
> "+proj=utm +zone=4 +datum=WGS84 +units=m
> +no_defs "
16c16
<
"+proj=longlat +datum=WGS84 +no_defs"
---
<
kiritimati_primary_roads
---
>
>
> scot_BNG
18c18
< "+proj=utm
+zone=4 +datum=WGS84 +units=m +no_defs"
---
> "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000
> +ellps=airy +towgs84=446.448,-125.157,542.06,0.15,0.247,0.842,-20.489
> +units=m +no_defs "
22c22
< [1] "+proj=longlat +a=6378137.01 +rf=298.257223563
+towgs84=0,0,0,0,0,0,0 +no_defs"
---
> [1] "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs "
24c24
< [1] "+proj=utm +zone=23 +south +ellps=aust_SA
+towgs84=-57,1,-41,0,0,0,0 +units=m +no_defs"
---
> [1] "+proj=utm +zone=23 +south +ellps=aust_SA +towgs84=-57,1,-41,0,0,0,0
> +units=m +no_defs "
26c26
< [1] "+proj=longlat +datum=WGS84 +no_defs"
---
> [1] "+proj=longlat +datum=WGS84 +no_defs "
28c28
< [1] "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0
+k_0=0.999877420000019 +x_0=600000 +y_0=2200000.00000032
+ellps=clrk80ign +pm=paris +towgs84=-168,-60,320,0,0,0,0 +units=m
+no_defs"
---
> [1] "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0 +k_0=0.9998774200000193
> +x_0=600000 +y_0=2200000.000000325 +a=6378249.2 +b=6356515.000000472
> +towgs84=-168,-60,320,0,0,0,0 +pm=paris +units=m +no_defs "
40c40
< file: SP27GTIF.TIF , SRS: +proj=tmerc +lat_0=36.6666666666667
+lon_0=-88.3333333333333 +k=0.999975 +x_0=152400.30480061 +y_0=0
+ellps=clrk66 +towgs84=-8,160,176,0,0,0,0 +units=us-ft +no_defs
---
> file: SP27GTIF.TIF , SRS: +proj=tmerc +lat_0=36.66666666666666
> +lon_0=-88.33333333333333 +k=0.9999749999999999 +x_0=152400.3048006096 +y_0=0
> +datum=NAD27 +units=us-ft +no_defs
41c41
< file: cea.tif , SRS: +proj=cea +lat_ts=33.75
+lon_0=-117.333333333333 +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
---
> file: cea.tif , SRS: +proj=cea +lon_0=-117.333333333333 +lat_ts=33.75
> +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
42c42
< file: erdas_spnad83.tif , SRS: +proj=tmerc +lat_0=30
+lon_0=-82.1666666666667 +k=0.9999 +x_0=200000 +y_0=0 +ellps=GRS80
+towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
---
> file: erdas_spnad83.tif , SRS: +proj=tmerc +lat_0=30
> +lon_0=-82.16666666666667 +k=0.9999 +x_0=200000 +y_0=0 +ellps=GRS80
> +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
43c43
< file: scaleoffset.vrt , SRS: +proj=utm +zone=18 +ellps=WGS84
+towgs84=0,0,0,0,0,0,0 +units=m +no_defs
---
> file: scaleoffset.vrt , SRS: +proj=utm +zone=18 +datum=WGS84 +units=m
> +no_defs
Running ‘test_proj.R’
comparing ‘test_proj.Rout’ to ‘test_proj.Rout.save’ ... OK
Running ‘tests.R’
comparing ‘tests.Rout’ to ‘tests.Rout.save’ ... OK
Running ‘tripup.R’
comparing ‘tripup.Rout’ to ‘tripup.Rout.save’ ...
266c266
< coords FALSE
---
> coords TRUE
267c267
< holes FALSE
---
> holes TRUE
273c273
< coords FALSE
---
> coords TRUE
274c274
< holes FALSE
---
> holes TRUE
Running vignettes for package ‘rgdal’
Running ‘OGR_shape_encoding.Rnw’
phase `check' succeeded after 18.7 seconds
--8<---------------cut here---------------end--------------->8---
Therefore, I do not confirm, I guess.
All the best,
simon
- bug#39204: r-rgdal: Reading of vector GIS data causes segfault, zimoun, 2020/02/20
- bug#39204: r-rgdal: Reading of vector GIS data causes segfault, Arun Isaac, 2020/02/20
- bug#39204: r-rgdal: Reading of vector GIS data causes segfault, zimoun, 2020/02/21
- bug#39204: r-rgdal: Reading of vector GIS data causes segfault, Arun Isaac, 2020/02/21
- bug#39204: r-rgdal: Reading of vector GIS data causes segfault, zimoun, 2020/02/21
- bug#39204: r-rgdal: Reading of vector GIS data causes segfault, zimoun, 2020/02/21
- bug#39204: r-rgdal: Reading of vector GIS data causes segfault, Arun Isaac, 2020/02/21
- bug#39204: r-rgdal: Reading of vector GIS data causes segfault, zimoun, 2020/02/21
bug#39204: r-rgdal: Reading of vector GIS data causes segfault,
zimoun <=
- bug#39204: r-rgdal: Reading of vector GIS data causes segfault, Arun Isaac, 2020/02/21
- bug#39204: r-rgdal: Reading of vector GIS data causes segfault, zimoun, 2020/02/21
- bug#39204: r-rgdal: Reading of vector GIS data causes segfault, Arun Isaac, 2020/02/22
- bug#39204: r-rgdal: Reading of vector GIS data causes segfault, zimoun, 2020/02/24
- bug#39204: r-rgdal: Reading of vector GIS data causes segfault, Arun Isaac, 2020/02/24
- bug#39204: r-rgdal: Reading of vector GIS data causes segfault, zimoun, 2020/02/25