[GRASSLIST:5449] Re: problems with r.in.srtm

[William K]

On Jan 19, 2005, at 5:59 PM, samuel cavalcante wrote:

> hi william,
>
>
>> First, r.in.srtm is meant to run on zip file as
>> downloaded.  It
>> automatically unzips it, creates the support files
>> and imports it.  It
>> figures out the extents of the srtm tile from the
>> file name, so you
>> can't rename it.  It goes thru an intermediate
>> geotif, so if it worked
>> it should have left behind a tiff as well.  It
>> probably stopped because
>> it coouldn't find the zip.
>
> i forgot to say, but i did so, using the zip
> file...after all it generates only  .proj , .bil and
> an other i didn't remember (.hdr?)
>
prj, bil and hdr, and if it had completed, also tif.

> ok, thanks
>
> another word about: apparently both data are in he
> same "region" and in the same projection..but
> r.in.gdal returns me the same error message (something
> like: the data i am trying  to import doesn't fit in
> the location)..even if i extend the region boundaries
> the data also doesn't fit...
>
probably the bug - the extents generated by r.in.srtm are bogus and 
probably aren't even close to your region.

Looks like Markus was thinking about this too - after talking to him, 
he's got a new version in CVS now.  This fixes this bug, and has some 
other improvements to simplify and speed up the importing.  Update your 
CVS or wait for the snapshot.  Should be in beta 2 whenever it comes 
out.

-----
William Kyngesburye <kyngchaos at charter.net>
http://webpages.charter.net/kyngchaos/

"History is an illusion caused by the passage of time, and time is an 
illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy