I compiled GDAL from CVS today and tried to import landsat data:
Problem:
following happens without using paramter -o:
r.in.gdal in=p192r027_7k20000620_z33_nn61.tif out=p192r027nn61
A datum name wgs84 (WGS_1984) was specified without transformation parameters.
Note that the GRASS default for wgs84 is towgs84=0.000,0.000,0.000.
Segmentation fault
with parameter -o import with r.in.gdal works:
r.in.gdal -o in=p192r027_7k20000620_z33_nn61.tif out=p192r027nn61
A datum name wgs84 (WGS_1984) was specified without transformation parameters.
Note that the GRASS default for wgs84 is towgs84=0.000,0.000,0.000.
Over-riding projection check.
Proceeding with import...
100%
CREATING SUPPORT FILES FOR p192r027nn61
SETTING GREY COLOR TABLE FOR p192r027nn61 (8bit, full range)
I compiled GDAL from CVS today and tried to import landsat data:
Problem:
following happens without using paramter -o:
r.in.gdal in=p192r027_7k20000620_z33_nn61.tif out=p192r027nn61
A datum name wgs84 (WGS_1984) was specified without transformation
parameters.
Note that the GRASS default for wgs84 is towgs84=0.000,0.000,0.000.
Segmentation fault
with parameter -o import with r.in.gdal works:
...
maybe you can run it through a debugger and post the results of a
back-trace?
Maybe recompile GRASS after recomiling GDAL?
If you configure with:
CFLAGS="-g -Wall" ./configure ...
then the gdb output gets a whole lot more informative.
On Thu, 10 Feb 2005 11:52:44 +1300
Hamish <hamish_nospam@yahoo.com> wrote:
> I compiled GDAL from CVS today and tried to import landsat data:
>
>
> Problem:
>
> following happens without using paramter -o:
>
> r.in.gdal in=p192r027_7k20000620_z33_nn61.tif out=p192r027nn61
> A datum name wgs84 (WGS_1984) was specified without transformation
> parameters.
> Note that the GRASS default for wgs84 is towgs84=0.000,0.000,0.000.
> Segmentation fault
>
>
> with parameter -o import with r.in.gdal works:
...
maybe you can run it through a debugger and post the results of a
back-trace?
(gdb) run in=p192r027_7k20000620_z33_nn61.tif out=muell
Starting program: /usr/local/grass-6.0.cvs/bin/r.in.gdal in=p192r027_7k20000620_z33_nn61.tif out=muell
(no debugging symbols found)...[Thread debugging using libthread_db enabled]
[New Thread 1086230496 (LWP 4835)]
ERROR 1: /usr/local/lib/gdal_GRASS.so: undefined symbol: _ZN11GDALDataset10AdviseReadEiiiiii12GDALDataTypeiPiPPc
ERROR 1: /usr/local/lib/gdal_GRASS.so: undefined symbol: _ZN11GDALDataset10AdviseReadEiiiiii12GDALDataTypeiPiPPc
A datum name wgs84 (WGS_1984) was specified without transformation parameters.
Note that the GRASS default for wgs84 is towgs84=0.000,0.000,0.000.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1086230496 (LWP 4835)]
0x405f7781 in ____strtod_l_internal () from /lib/tls/libc.so.6
(gdb)
Note that the above messages indicate that you have conflicting
versions of some source. Likely you have a gdal_GRASS.so that
was compiled against a different version of GRASS than you are
using. The AdviseRead method was recently added to GDAL.
There is no problem with compiling an older gdal_grass driver,
but the binaries have to be built against a compatible version of
GDAL to what they run under.
PS. I am subscribed to this list, but I have all [GRASS5* messages
go into a special GRASS folder which I unfortunately do not check often.
If you need something specifically from me, don't hesitate to email
me directly but be careful to edit the [GRASS5 part out of the subject
if it is related to a grass thread.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent