[GRASS-dev] r.in.gdal slow with input of type=UInt16
jachym.cepicky at gmail.com
Fri May 25 19:15:40 CEST 2007
Frank Warmerdam píše v Pá 25. 05. 2007 v 10:07 -0400:
> What is the size of soils.tif? brk() is the memory allocated which suggests
> to me that the process may be taking an unreasonable amount of memory and that
> this is causing problems.
-rw-r--r-- 1 jachym jachym 1,4M 2007-05-24 17:50 /tmp/soils.tif
> If you hadn't just created it with r.out.gdal, I'd suspect that soils.tif
> was a dangerous sort of file, such as a 1bit fax compressed file all in
> one strip. But that clearly can't be the case.
if I export soils to soils.tif with type=UInit32 , back import works
> The fact that things stall just after creating the histogram file makes
> me wonder if it has something to do with histogram creation. But I can't
> see any obvious reason creating a histogram of a 16bit file should be slow.
> You might want to actually run r.in.gdal in gdb, and break and get
> tracebacks a few times. I find this a useful technique to identify
> what a program is doing when it appears unexpectedly stalled.
> I presume a "gdal_translate soils.tif soils2.tif" is fast? If so, that
> suggests it isn't the actual GDAL operation that is slow.
yes, it is fast,
thanks for this hints
e-mail: jachym.cepicky at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?=
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070525/f179b5d4/attachment.bin
More information about the grass-dev