[GRASS-user] r.terraflow on massive DEM

Tue Jan 13 10:52:33 PST 2015

Well, r.terraflow does run on my machine.
It took 52 minutes to process the following region:

projection: 3 (Latitude-Longitude)
zone:       0
datum:      wgs84
ellipsoid:  wgs84
north:      18:59:59S
south:      22S
west:       52W
east:       49:59:59W
nsres:      0:00:01
ewres:      0:00:01
rows:       10801
cols:       7201
cells:      77778001

My computer is a core i3 (Win7) and I gave the process only 600mb of ram.

Now, the thing is, my main interest is to fill the voids in the SRTM data.
So I though about using r.terraflow to get the filled elevation. Should I
continue on that path or would it be better to use r.fill.null on a large
dataset?

Thanks
Daniel

On Tue, Jan 13, 2015 at 1:46 PM, Daniel Victoria <daniel.victoria at gmail.com>
wrote:

> Charlie,
>
> I just downloaded some SRTM 1arc sec. from EarthExplorer. The data is
> supplied in 3 different file types, GeoTIFF, DTED or BIL and they are all
> in Integer values (Int16). No floating point elevation values.
>
> Cheers
> Daniel
>
> On Tue, Jan 13, 2015 at 12:12 PM, Charlie Shobe <chsh5846 at colorado.edu>
> wrote:
>
>> Hi Daniel,
>>
>> I believe that SRTM data does in fact provide floating point elevation
>> values, so you may want to try working with the DEM as type FCELL from the
>> very beginning. I don't know if this will help solve your problem, but the
>> last time I brought in SRTM (1 arc second) data it was type FCELL and
>> contained several decimal places of precision.
>>
>> Good luck,
>>
>> Charlie
>>
>>
>> On Jan 13, 2015, at 4:00 AM, Daniel Victoria <daniel.victoria at gmail.com>
>> wrote:
>>
>> Stephan, I'll give r.watershed a try and let it run for a couple of days.
>> Thanks
>>
>> Thayer, I used r.recode because the person that sent me the data messed
>> up the null values. So in order to fix that I did:
>> 1) use r.external to bring the data to Grass
>> 2) fix null values with r.recode, which was faster than r.null
>>
>> But I gave up on that path and since imported the data (r.in.gdal) and
>> fixed the null values with r.null.
>> I'm also using integer values (CELL type) because from what I heard, SRTM
>> does not provide floating point data.
>>
>> Now I tried to run r.terraflow but I got a type error which asked me to
>> use r.terraflow.short. Since I don't have that command in my grass
>> instalatin, I converted the SRTM data to float. But that was to no avail
>> since it's now giving me a dimensions type overflow error and asking me to
>> change the dimension_type and recompile.
>>
>> I'll give r.watershed a try. If that does not work, I'll see if I can
>> recompile.
>>
>> Thanks
>> Daniel
>>
>> On Mon, Jan 12, 2015 at 9:22 PM, Thayer Young <thayeray at yahoo.com> wrote:
>>
>>> With regards to the size of DEM, if you can get the command to run it
>>> may take several days to finish, this is more than twice the size of the
>>> Washington State DEM that took the authors 33 hours in 2003 (Arge, Chase,
>>> Halpin, Toma, Urban, Vitter, Wickremesinghe  Efficient Flow Computation on
>>> Massive Grid Terrain Datasets Geoinformatica Volume 7 Issue 4, December
>>> 2003 Pages 283 - 313 ).  My mid-2014 computer runs at about twice the
>>> speed quoted in the paper.
>>>
>>> Did you r.recode it to make it smaller?  In flat areas you need the data
>>> contained after the decimal point to allow the flow a chance to make it
>>> down hill, otherwise you can get streams going no where near where they do
>>> in real life.  I have never tried running r.terraflow on an integer raster,
>>> I know that it works on decimal rasters.
>>>
>>> -Thayer
>>>
>>>
>>>
>>>  ------------------------------
>>>
>>> Date: Mon, 12 Jan 2015 09:59:40 -0200
>>> From: Daniel Victoria <daniel.victoria at gmail.com>
>>> To: grass <grass-user at lists.osgeo.org>
>>> Subject: [GRASS-user] r.terraflow on massive DEM
>>> Message-ID:
>>>     <CA+irsJjf7xhWgU968D+4+xc2YGJ=_n4xJtP0_WeU1ZpoRTt9ng at mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>>
>>> Hi list,
>>>
>>> I'm trying to run r.terraflow on a very large DEM but I wander if it's
>>> __too large__.
>>>
>>> The region dimensions are:
>>> ncol=141114
>>> nrow=140487
>>> Data type = CELL
>>>
>>> The map is actually a reclass map of a raster that I imported using
>>> r.external.
>>>
>>> When I run r.terraflow I get:
>>>
>>> r.terraflow elevation=srtm_brasil at PERMANENT filled=srtm_fill
>>> direction=flowdir swatershed=sink accumulation=flowacc tci=srtm_tci
>>> directory=E:\terraflow_temp
>>>
>>> WARNING: raster srtm_brasil is of type CELL_TYPE --you should use
>>> r.terraflow.short
>>> ERROR: [nrows=140487, ncols=141114] dimension_type overflow -- change
>>> dimension_type and recompile
>>> (Mon Jan 12 09:57:18 2015) Command finished (0
>>> sec)
>>>
>>> However, I don't have an r.terraflow.short command
>>> I'm running Grass 7.0.0beta4 from OsGeo4W
>>>
>>> Cheers
>>> Daniel
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL: <
>>> http://lists.osgeo.org/pipermail/grass-user/attachments/20150112/a27c139f/attachment-0001.html
>>> >
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> grass-user mailing list
>>> grass-user at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>>> End of grass-user Digest, Vol 105, Issue 16
>>> *******************************************
>>>
>>>
>>>
>>> _______________________________________________
>>> grass-user mailing list
>>> grass-user at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>>
>> _______________________________________________
>> grass-user mailing list
>> grass-user at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20150113/a2356d84/attachment-0001.html>