[GRASS-user] r.terraflow on massive DEM

[Daniel Victoria]

That's a good point Thayer. Will do. Will do

On Tue, Jan 13, 2015 at 1:02 PM, Thayer Young <thayeray at yahoo.com> wrote:

> Daniel,
>
> Before you go through the trouble of recompiling you may want to try
> downloading a smaller SRTM DEM from Earth Explorer and make sure it works
> with r.terraflow.  I would recommend making sure r.terraflow works at all
> on your system.  Then scale up to the full mosaic and see if you still have
> a problem.
>
> -Thayer
>
>
>   ------------------------------
>  *From:* Daniel Victoria <daniel.victoria at gmail.com>
> *To:* Charlie Shobe <chsh5846 at colorado.edu>
> *Cc:* Thayer Young <thayeray at yahoo.com>; "grass-user at lists.osgeo.org" <
> grass-user at lists.osgeo.org>
> *Sent:* Tuesday, January 13, 2015 9:17 AM
> *Subject:* Re: [GRASS-user] r.terraflow on massive DEM
>
> Ouch! That means that probably, the person who imported the data,
> converted it to integer without knowing...
>
> Anyway, I'll still need to recompile r.terraflow if I'm to use on such a
> large region (ncol=141114 x nrow=14048).
>
> Thanks
> 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/ce375c70/attachment-0001.html>