Package: gdal-bin Followup-For: Bug #528557
note that in the resolution to bug #495353 (thanks for digging that out) the closing message states that this is fixed in the 1.6.0 package in experiemental, not the 1.5.x packages currently in Sid. You might try installing those and see how it goes. (and the more testing it gets the sooner it moves into Sid) FWIW, I can confirm the segfault in Etch using gdal 1.5.2-3~bpo40+1 from backports.org and the test data attached to bug #495353. Follows is a gdb backtrace of the standard stripped binaries. If needed I can provide a trace against unstripped gdal/trunk self-built binaries but I think that's not needed or useful as Frankie's already on top of the situation. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1244584256 (LWP 14948)] 0xb70a49f0 in NC_var_shape () from /usr/lib/libmfhdf.so.4 (gdb) bt #0 0xb70a49f0 in NC_var_shape () from /usr/lib/libmfhdf.so.4 #1 0xb6f3119f in nc_get_NC () from /usr/lib/libnetcdf.so.3 #2 0xb6ed2bbf in nc__open_mp () from /usr/lib/libnetcdf.so.3 #3 0xb6ed2c48 in nc__open () from /usr/lib/libnetcdf.so.3 #4 0xb6ed2c81 in nc_open () from /usr/lib/libnetcdf.so.3 #5 0xb7abd1ef in GMTDataset::Open () from /usr/lib/libgdal1.5.0.so.1 #6 0xb7bbadc2 in GDALOpen () from /usr/lib/libgdal1.5.0.so.1 #7 0x08049bbd in ?? () #8 0x08aeb040 in ?? () #9 0x00000000 in ?? () GMT 4.1.2-1.1 (Etch) says: $ grdinfo 3n24s47w14w.grd 3n24s47w14w.grd: Title: GEBCO One Minute Grid 3n24s47w14w.grd: Command: 1.02 3n24s47w14w.grd: Remark: 3n24s47w14w.grd: Normal node registration used 3n24s47w14w.grd: grdfile format: cs (# 8) 3n24s47w14w.grd: x_min: -47 x_max: -14 x_inc: 0.0166667 name: user_x_unit nx: 1981 3n24s47w14w.grd: y_min: -24 y_max: 3 y_inc: 0.0166667 name: user_y_unit ny: 1621 3n24s47w14w.grd: z_min: -7849 z_max: 2585 name: user_z_unit 3n24s47w14w.grd: scale_factor: 1 add_offset: 0 The "cs" format is GMT 3 netCDF legacy format (short) (depreciated) the work-around is to convert to an old style GMT binary .grd using grdreformat. $ grdreformat 3n24s47w14w.grd 3n24s47w14w_Native.grd=bs # then import into GRASS, GRASS> r.in.bin -h -s bytes=2 in=3n24s47w14w_Native.grd out=3n24s47w14w # and set some nice colors GRASS> r.colors 3n24s47w14w rules=- << EOF nv magenta 0% black -7740 0:0:168 0 84:176:248 0 40:124:0 522 68:148:24 1407 148:228:108 1929 232:228:108 2028 232:228:92 2550 228:160:32 2724 216:116:8 2730 grey 2754 grey 2760 252:252:252 2874 252:252:252 2883 192:192:192 2913 192:192:192 100% 252:252:252 EOF aside: comparing the 2' ETOPO2 data to this version of the 1' GEBCO data it is clear that the ETOPO2 data is far superior even though the resolution is twice as coarse. e.g. the ocean trenches are much better defined and magically new seamounts appear. Is the difference the inclusion of the S&S radar altimetry in etopo2? Also it would seem that the entire continental shelf has moves somewhat westward (or is that just further offshore?) in the ETOPO2 data. weird. It would be interesting to compare the two with the GRASS r.roughness addon script. Hamish -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
