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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >>> To: grass <[email protected]> >>> Subject: [GRASS-user] r.terraflow on massive DEM >>> Message-ID: >>> <CA+irsJjf7xhWgU968D+4+xc2YGJ=_n4xjtp0_weu1zportt...@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@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 >>> [email protected] >>> http://lists.osgeo.org/mailman/listinfo/grass-user >>> >>> End of grass-user Digest, Vol 105, Issue 16 >>> ******************************************* >>> >>> >>> >>> _______________________________________________ >>> grass-user mailing list >>> [email protected] >>> http://lists.osgeo.org/mailman/listinfo/grass-user >>> >> >> _______________________________________________ >> grass-user mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/grass-user >> >> >
_______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
