[DebianGIS-dev] Bug#528557: gdal-bin: gdalinfo segmentation fault with GMT and NetCDF files

[Hamish]

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