[GRASS-dev] r.in.gdal slow with input of type=UInt16

[Jachym Cepicky]

hi Frank,
Frank Warmerdam píše v Pá 25. 05. 2007 v 10:07 -0400:

> Jachym,
> 
> 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
fast

> 
> 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

Jachym
-- 
Jachym Cepicky
e-mail: jachym.cepicky at gmail.com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?=
	=?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?=
	=?ISO-8859-1?Q?_zpr=E1vy?=
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20070525/f179b5d4/attachment.bin