[GRASS-user] Distributed modeling animation rendered in GRASS70
All, After running a distributed hydrologic model I did some shell/GRASS scripting to import the NEXRAD radar precipitation data and model output flow grids into GRASS 7. Making use of ps.map, I generated a series of hourly (2185) png images. Markus Neteler pointed me to the GRASS location http://grasswiki.osgeo.org/wiki/Movies, where I simply did this: mencoder "mf:///home/teaiii/grass/data/output/png_files/*.png" -mf fps=15 -o type=png out.avi -ovc lavc -lavcopts vcodec=mpeg4:vhq:vbitrate=1800 -ffourcc MP4 I posted the resulting video on Mimeo: https://vimeo.com/111696348 There should be a High-def version available at some point. Cheers! Tom ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] A question before I embark on a programming exercise
Moritz, I need to be sure I understand this line: down_id = if(dir=1, id[1,1], if(dir=2, id[0,1], if(dir=3, id[-1,1] etc dir=1 is what direction?; dir=2 is what direction?, etc. Is dir=1 directly to the 'East', dir=3 directly 'south', dir=5 directly 'west' and dir=7 directly 'north' Also, does the indexing [0,1] refer to the [x,y], i.e., [column, row] so that [0,1] refers to the same column, but one row below? Which would imply from your line that dir=2 is directly 'south'?? I apologize for being dense about this, I just need to be sure — sorry… I did get the first part to work using r.mapcalc to get the pixel indexing: id = (row() - 1)*Ncolumns + col() Regards, Tom On Wed, Nov 12, 2014 at 7:30 AM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > On 12/11/14 05:10, Thomas Adams wrote: > >> I need to generate an ascii text file from a flow direction grid that >> consists of (among a couple other things that don't really matter at >> this point) for each pixel: >> > > Rainer has already given you a whole program, but here's a decomposition > in simple (untested) r.mapcalc steps: > > >> (1) a unique integer identifier (1 -- N) for the pixel >> > > r.mapcalc "id = row()*N + col()" # where N = nb cols * 10 > > (you might have to watch out for integer overflow, though) > > (2) the integer identifier of the downstream pixel (assuming there is >> ONLY one) >> > > Calculate flow direction in SFD mode and use something like this: > > r.mapcalc down_id = if(dir=1, id[1,1], if(dir=2, id[0,1], if(dir=3, > id[-1,1] etc > > > (3) the x,y location of the pixel (presumably, the lower left corner of >> the pixel) >> > > center of pixel: > r.mapcalc x = x() > r.mapcalc y = y() > > if you want the lower left corner: > > r.mapcalc x = x() - ewres()/2 > r.mapcalc y = y() - nsres()/2 > > > Then export everything with > > r.stats -1 in=id,x,y,down_id > > Moritz > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] A question before I embark on a programming exercise
Johannes, Thank you very much for the useful suggestions. I greatly appreciate your comments! I'll post my results once I work through things. Best, Tom On Wed, Nov 12, 2014 at 7:42 AM, Johannes Radinger < johannesradin...@gmail.com> wrote: > Hi Tom, > > what comes into my mind is following approach (not tested): > > 1) calculate flow direction using r.watershed for each pixel of your map > 2) transforming raster to vector points (r.to.vect), adding some columns > for your results (X, Y, ID). This step should provide you already with > unique IDs for your cells/points. > 3) With v.to.db you can update the X and Y coordinate of your cell center > and together with the raster resolution you can get the lower left corner > as desired. > 3) By knowing the flow direction for each point you should be able to > calculate the X and Y coordinate of the downstream cell (adding or > substracting your cell dimensions from the cell center, correct for > diagonal flow). When you know X and Y of your downstream cell then you > should be able to also get the ID of the downstream cell (most probably a > SQL query I guess) > > Maybe there are easier ways > > hope it works, > Johannes > > On Wed, Nov 12, 2014 at 5:10 AM, Thomas Adams wrote: > >> All: >> >> I need to generate an ascii text file from a flow direction grid that >> consists of (among a couple other things that don't really matter at this >> point) for each pixel: >> >> (1) a unique integer identifier (1 -- N) for the pixel >> (2) the integer identifier of the downstream pixel (assuming there is >> ONLY one) >> (3) the x,y location of the pixel (presumably, the lower left corner of >> the pixel) >> >> has anyone already done something like this? >> >> It's needed (along with some header information) as an input file for a >> gridded distributed hydrologic model, identifying the flow connectivity >> from pixel to pixel for streamflow routing purposes. I have already >> formulated conceptually how to do this, but if someone has already done >> such a thing, why reinvent the wheel?? >> >> Any help is appreciated. >> >> Regards, >> Tom >> >> >> ___ >> grass-user mailing list >> grass-user@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user >> > > -- Thomas E Adams, III 718 McBurney Drive Lebanon, OH 45036 1 (513) 739-9512 (cell) ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] A question before I embark on a programming exercise
Hi Tom, what comes into my mind is following approach (not tested): 1) calculate flow direction using r.watershed for each pixel of your map 2) transforming raster to vector points (r.to.vect), adding some columns for your results (X, Y, ID). This step should provide you already with unique IDs for your cells/points. 3) With v.to.db you can update the X and Y coordinate of your cell center and together with the raster resolution you can get the lower left corner as desired. 3) By knowing the flow direction for each point you should be able to calculate the X and Y coordinate of the downstream cell (adding or substracting your cell dimensions from the cell center, correct for diagonal flow). When you know X and Y of your downstream cell then you should be able to also get the ID of the downstream cell (most probably a SQL query I guess) Maybe there are easier ways hope it works, Johannes On Wed, Nov 12, 2014 at 5:10 AM, Thomas Adams wrote: > All: > > I need to generate an ascii text file from a flow direction grid that > consists of (among a couple other things that don't really matter at this > point) for each pixel: > > (1) a unique integer identifier (1 -- N) for the pixel > (2) the integer identifier of the downstream pixel (assuming there is ONLY > one) > (3) the x,y location of the pixel (presumably, the lower left corner of > the pixel) > > has anyone already done something like this? > > It's needed (along with some header information) as an input file for a > gridded distributed hydrologic model, identifying the flow connectivity > from pixel to pixel for streamflow routing purposes. I have already > formulated conceptually how to do this, but if someone has already done > such a thing, why reinvent the wheel?? > > Any help is appreciated. > > Regards, > Tom > > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] A question before I embark on a programming exercise
Awesome, Moritz! Thank you so much... Tom On Wed, Nov 12, 2014 at 7:30 AM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > On 12/11/14 05:10, Thomas Adams wrote: > >> I need to generate an ascii text file from a flow direction grid that >> consists of (among a couple other things that don't really matter at >> this point) for each pixel: >> > > Rainer has already given you a whole program, but here's a decomposition > in simple (untested) r.mapcalc steps: > > >> (1) a unique integer identifier (1 -- N) for the pixel >> > > r.mapcalc "id = row()*N + col()" # where N = nb cols * 10 > > (you might have to watch out for integer overflow, though) > > (2) the integer identifier of the downstream pixel (assuming there is >> ONLY one) >> > > Calculate flow direction in SFD mode and use something like this: > > r.mapcalc down_id = if(dir=1, id[1,1], if(dir=2, id[0,1], if(dir=3, > id[-1,1] etc > > > (3) the x,y location of the pixel (presumably, the lower left corner of >> the pixel) >> > > center of pixel: > r.mapcalc x = x() > r.mapcalc y = y() > > if you want the lower left corner: > > r.mapcalc x = x() - ewres()/2 > r.mapcalc y = y() - nsres()/2 > > > Then export everything with > > r.stats -1 in=id,x,y,down_id > > Moritz > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] d.out.file / d.save - Shell-script use issues
I kindly ask command line users of d.* commands, especially those using d.* commands in scripts, to test and participate in discussions concerning d.* commands in GRASS GIS 7. For example, d.out.file was added (relatively) lately to 7 and there is new command d.to.rast. They are designed to work with wxGUI (including wx monitors). Thanks, Vaclav [GRASS-dev] d.out.file http://lists.osgeo.org/pipermail/grass-dev/2014-February/067362.html [GRASS-user] d.out.file - Shell-script use ? http://lists.osgeo.org/pipermail/grass-user/2014-November/071238.html wxGUI d.mon and g.gui monitor command line support http://trac.osgeo.org/grass/ticket/2233 Saves the contents of the active display monitor to a graphics file http://grass.osgeo.org/grass70/manuals/d.out.file.html Saves the contents of the active display monitor to a raster map http://grass.osgeo.org/grass70/manuals/d.to.rast.html On Wed, Nov 12, 2014 at 4:13 AM, Glynn Clements wrote: > > César Augusto Ramírez Franco wrote: > > > As far as I understand, d.out.file only works with X monitors, > > This appears to be the case, although I have no idea why. > > The basic operation of d.out.file is to run "d.save" to extract the > list of commands used to generate the display, then replay those > commands on a PNG/PS/cairo monitor. > > The functionality on which d.save relies isn't specific to a > particular driver. > > -- > Glynn Clements > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] A question before I embark on a programming exercise
On 12/11/14 05:10, Thomas Adams wrote: I need to generate an ascii text file from a flow direction grid that consists of (among a couple other things that don't really matter at this point) for each pixel: Rainer has already given you a whole program, but here's a decomposition in simple (untested) r.mapcalc steps: (1) a unique integer identifier (1 -- N) for the pixel r.mapcalc "id = row()*N + col()" # where N = nb cols * 10 (you might have to watch out for integer overflow, though) (2) the integer identifier of the downstream pixel (assuming there is ONLY one) Calculate flow direction in SFD mode and use something like this: r.mapcalc down_id = if(dir=1, id[1,1], if(dir=2, id[0,1], if(dir=3, id[-1,1] etc (3) the x,y location of the pixel (presumably, the lower left corner of the pixel) center of pixel: r.mapcalc x = x() r.mapcalc y = y() if you want the lower left corner: r.mapcalc x = x() - ewres()/2 r.mapcalc y = y() - nsres()/2 Then export everything with r.stats -1 in=id,x,y,down_id Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] A question before I embark on a programming exercise
Rainer, Thank you very much. I just downloaded everything via git. I greatly appreciate your help. Best, Tom On Wed, Nov 12, 2014 at 1:28 AM, Rainer M Krug wrote: > Thomas Adams writes: > > > All: > > > > I need to generate an ascii text file from a flow direction grid that > > consists of (among a couple other things that don't really matter at this > > point) for each pixel: > > > > (1) a unique integer identifier (1 -- N) for the pixel > > (2) the integer identifier of the downstream pixel (assuming there is > ONLY > > one) > > (3) the x,y location of the pixel (presumably, the lower left corner of > the > > pixel) > > > > has anyone already done something like this? > > Well - I have done something similar, i.e. simulated water dispersal, in > a package which is at [1]. The actual function is at [1]. After reading > your mail again, it seems to be different, but it still might give you > some ideas. > > Cheers, > > Rainer > > > > > It's needed (along with some header information) as an input file for a > > gridded distributed hydrologic model, identifying the flow connectivity > > from pixel to pixel for streamflow routing purposes. I have already > > formulated conceptually how to do this, but if someone has already done > > such a thing, why reinvent the wheel?? > > > > Any help is appreciated. > > > > Regards, > > Tom > > ___ > > grass-user mailing list > > grass-user@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/grass-user > > > Footnotes: > [1] https://github.com/rkrug/seedDisp > > [1] https://github.com/rkrug/seedDisp/blob/master/R/waterDispGRASS.R > > -- > Rainer M. Krug > email: Rainerkrugsde > PGP: 0x0F52F982 > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] t.rast.accumulate ValueError: could not convert string to float:
Hi, I have an 3hr raintrate data in GRASS STRDs. I tested running a 10day accumulation but I get valuerror. Details below: GRASS 7.0.0 (rainfall):~/trmm > t.info 3hr_rainrate + Space Time Raster Dataset -+ || + Basic information -+ | Id: 3hr_rainrate@PERMANENT | Name: .. 3hr_rainrate | Mapset: PERMANENT | Creator: ... maning | Temporal type: . absolute | Creation time: . 2014-11-12 18:44:43.567312 | Modification time:.. 2014-11-12 19:04:43.527267 | Semantic type:.. mean + Absolute time -+ | Start time:. 2014-07-09 00:00:00 | End time:... 2014-07-20 03:00:00 | Granularity: 3 hours | Temporal type of maps:.. interval + Spatial extent + | North:.. 22.0 | South:.. 4.0 | East:.. 155.0 | West:... 115.0 | Top: 0.0 | Bottom:. 0.0 + Metadata information --+ | Raster register table:.. raster_map_register_491d12cc26d2460d9591bd699f6beb43 | North-South resolution min:. 0.25 | North-South resolution max:. 0.25 | East-west resolution min:... 0.25 | East-west resolution max:... 0.25 | Minimum value min:.. 0.0 | Minimum value max:.. 0.0 | Maximum value min:.. 9.39 | Maximum value max:.. 38.32 | Aggregation type:... None | Number of registered maps:.. 89 | ++ GRASS 7.0.0 (rainfall):~/trmm > t.rast.accumulate input=3hr_rainrate@PERMANENT output=10day_accumulation start="2014-07-09" granularity='1 days' cycle='10 days' basename=10day_accum Processing cycle 2014-07-09 00:00:00 - 2014-07-19 00:00:00 Traceback (most recent call last): File "/usr/lib/grass70/scripts/t.rast.accumulate", line 507, in main() File "/usr/lib/grass70/scripts/t.rast.accumulate", line 393, in main limits_lower = float(limits_vals[0]) ValueError: could not convert string to float: -- cheers, maning -- "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] d.out.file / d.save - Shell-script use issues
César Augusto Ramírez Franco wrote: > As far as I understand, d.out.file only works with X monitors, This appears to be the case, although I have no idea why. The basic operation of d.out.file is to run "d.save" to extract the list of commands used to generate the display, then replay those commands on a PNG/PS/cairo monitor. The functionality on which d.save relies isn't specific to a particular driver. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] A question before I embark on a programming exercise
Thomas Adams writes: > All: > > I need to generate an ascii text file from a flow direction grid that > consists of (among a couple other things that don't really matter at this > point) for each pixel: > > (1) a unique integer identifier (1 -- N) for the pixel > (2) the integer identifier of the downstream pixel (assuming there is ONLY > one) > (3) the x,y location of the pixel (presumably, the lower left corner of the > pixel) > > has anyone already done something like this? Well - I have done something similar, i.e. simulated water dispersal, in a package which is at [1]. The actual function is at [1]. After reading your mail again, it seems to be different, but it still might give you some ideas. Cheers, Rainer > > It's needed (along with some header information) as an input file for a > gridded distributed hydrologic model, identifying the flow connectivity > from pixel to pixel for streamflow routing purposes. I have already > formulated conceptually how to do this, but if someone has already done > such a thing, why reinvent the wheel?? > > Any help is appreciated. > > Regards, > Tom > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user Footnotes: [1] https://github.com/rkrug/seedDisp [1] https://github.com/rkrug/seedDisp/blob/master/R/waterDispGRASS.R -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
