Re: [GRASS-user] grass rastercal doesn't work
On 22/04/13 17:58, Eugenio Trumpy wrote: Thank Moritz, your hint partially solved my problem, because now I got a map, but that is not clipped by the mask. What could be the problem now? Difficult to say without more info. Did you redefine your mask after changing the region settings ? Have you tried to display MASK to see if it is set correctly ? Moritz Regards Eugenio Date: Mon, 22 Apr 2013 17:44:29 +0200 From: mlenn...@club.worldonline.be To: frippe12...@hotmail.com CC: grass-user@lists.osgeo.org Subject: Re: [GRASS-user] grass rastercal doesn't work On 22/04/13 17:14, Eugenio Trumpy wrote: Hello everybody, I have problems with r.mapcalc I'm use a fresh compiled grass70 from source in my ubuntu desktop 12.10 the review cod of grass is 55939. I 'm just trying to clip a raster using a mask: first I created a mask from a raster, then I use r.mapcal: new_cut_map=old_map I got a normal conclusion of calculation with 100% done and the specification [Raster MASK present], but the new raster layer seems to be void. I think I have problems with gdal lib? Have you some hints? Check your region settings. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass rastercal doesn't work
Hello Moritz,I Tried just now to redefine the mask, and re-run ther.mapcalc, but I got the sema result:I have the new map but with the same size of the starting one,again seems the mask doesn't work Any other hints or test to do? Regards E. Date: Tue, 23 Apr 2013 09:30:15 +0200 From: mlenn...@club.worldonline.be To: frippe12...@hotmail.com CC: grass-user@lists.osgeo.org Subject: Re: [GRASS-user] grass rastercal doesn't work On 22/04/13 17:58, Eugenio Trumpy wrote: Thank Moritz, your hint partially solved my problem, because now I got a map, but that is not clipped by the mask. What could be the problem now? Difficult to say without more info. Did you redefine your mask after changing the region settings ? Have you tried to display MASK to see if it is set correctly ? Moritz Regards Eugenio Date: Mon, 22 Apr 2013 17:44:29 +0200 From: mlenn...@club.worldonline.be To: frippe12...@hotmail.com CC: grass-user@lists.osgeo.org Subject: Re: [GRASS-user] grass rastercal doesn't work On 22/04/13 17:14, Eugenio Trumpy wrote: Hello everybody, I have problems with r.mapcalc I'm use a fresh compiled grass70 from source in my ubuntu desktop 12.10 the review cod of grass is 55939. I 'm just trying to clip a raster using a mask: first I created a mask from a raster, then I use r.mapcal: new_cut_map=old_map I got a normal conclusion of calculation with 100% done and the specification [Raster MASK present], but the new raster layer seems to be void. I think I have problems with gdal lib? Have you some hints? Check your region settings. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Unix and Grass commands in Windows
Hamish Thanks for your excellent response. Confirmed a few of my suspicions, plus some honest comment/nudges to others. -Appreciate the hard work everybody is putting in! Stephen -Original Message- From: Hamish [mailto:hamis...@yahoo.com] Sent: 22 April 2013 12:27 To: grass-user@lists.osgeo.org; Stephen Brearley Subject: Re: [GRASS-user] Unix and Grass commands in Windows Stephen wrote: Hi Folks Just wondering how best to execute Unix and Grass commands using Grass 6/7.0. I’m running Windows Vista, for GRASS 6.4 it is this one: Start - Programs - GRASS GIS 6.4.3 - GRASS GIS 6.4.3 with MSYS. and had started installing Cygwin, but this seems to be massive, and not even sure if this is the best environment, as some users don’t seem happy about it. It's ok, just overkill for what you want to do. People will always be unhappy with something or other on the internet, I wouldn't let that stop you. :) Yes, the installer is a pain. I had initially thought I could use the Console window, but this appears not to accept Unix commands. type bash at that prompt and it will. (maybe follow by PS1='GRASS:\W ' to get the prompt look back) I'm concerned that the CMD.EXE dos box console in 6.4 is still a bit half baked. The rxvt which runs the MSYS is not ideal either, but at least it generally works and occasionally doesn't, as opposed to the current CMD.EXE (GRASS Command Line + running g.gui) in 6.x, which seems to me lately to be lots of things not working. I don't use this day to day, so take with a grain of salt, maybe mine had a bad day when I tried it. I also tried the included MySys Unix console which appears to be a Bash shell, but this does not recognise Grass commands. there are two menu items: - GRASS GIS 6.4.3 with MSYS - MSYS UNIX Console the second one is just a generic UNIX prompt, the GRASS environment has not been loaded for you. the first one is what you want. What would you recommend is the best option if I want to use Grass quite a lot, but don’t want to convert my PC to a fully fledged Linux system (unless that really is the best option, such as using an emulator). I'd try the GRASS+MSys first. If that has problems, then it's pretty easy to install the free VirtualBox Virtual Machine software, then load something like xUbuntu of the OSGeo Live demo onto it. There are some step by step instructions on how to do that here: http://live.osgeo.org What I like about the Virtual Machines is that it makes the whole OS choice debate a bit moot. Set whichever one you're running to full screen, and there you are. GRASS is still smoother on UNIX (Linux/Mac/...), but we're trying to level the playing field as fast as we can. There are still a few rough edges on Windows, but it's getting much closer. good luck, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.sun use - automaticcaly stopped process ?
On Tue, Apr 23, 2013 at 6:24 AM, Hamish hamis...@yahoo.com wrote:
simogeo wrote:
As said before, I use Ubuntu 12.04 in 64bits.The
wikipage http://grasswiki.osgeo.org/wiki/Large_raster_data_processing
mentions
only memory usage limits for 32bits system. After your
first reply Markus, I thought the 2^31 memory limit would
also maybe affect 64 bits systems.
...
With res=5 or res=1 it's working well but with the raster
resolution (0.2) the process is killed again.
Hi,
just looking in the code, I see a few things which might be
suspicious in the INPUT_part() function,
https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.sun/main.c#L761
maybe something there needs to be off_t instead?
but mainly I think it's just that the module wants a lot of RAM,
and the process gets killed when it asks for too much.
That's why there is the numpartitions option. Try r.sun
numpartitions=a number 1
HTH,
Markus M
here are some tests on a few months old 6.4.svn build
(6.4.3svn.50937) on 64bit linux.
# Mode 2 (integrated daily irradiation) at spearfish
g.region rast=elevation.10m res=${*}
r.sun -s elevation.10m lin=2.5 alb=0.2 day=172 \
beam_rad=b.172 diff_rad=d.172 \
refl_rad=r.172 insol_time=it.172
as you can see, allocating 4gb RAM works ok for me, so it
is likely not a LFS/32/64bit problem.
rows: 27960
cols: 37980
cells: 1061920800
- in swap, 16gb RAM, (~19gb?)
rows: 22368
cols: 30384
cells: 679629312
- 12gb
rows: 18640
cols: 25320
cells: 471964800
- 8.8g
rows: 13980
cols: 18990
cells: 265480200
- 5GB
rows: 6990
cols: 9495
cells: 66370050
- 1.2g
rows: 2796
cols: 3798
cells: 10619208
- 0.2gb time: 37m42s
plotting it out, memory use seems to grow linearly with
number of cells. from earlier experiments, time does as well.
by my calcs, a 6x6 cell region would want ~64gb RAM.
However it would take a long-long time to get there, as in
the last example above, a bit bigger than 3000x3000 cells took
half an hour on a few months old fast i7 cpu w/ 16GB ram.
I don't think Seth's GPU OpenCL acceleration is going to help
there, since GPU RAM is often limited and the I/O to it a bottle-
neck, and even 8 or 16x faster than it w/multithreading would
take would still take too long for Mode 2 daily integration runs.
So I think your best bet is to use a coarser resolution, then
make it finer until you hit a time or RAM limit. Do you have
that fine of a DEM anyway? LiDAR often being binned to 2m cell
size,..
Hamish
___
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] v.label.sa not working with areas?
I'm picking this bug up. I'll continue working on this missing feature. I never got around to implementing it, but now that I see people are using and wanting this feature I'm more than happy to actually work on it! On Mon, Apr 22, 2013 at 3:12 PM, RichardC richtcoo...@hotmail.com wrote: Filed bug report at http://trac.osgeo.org/grass/ticket/1942 http://trac.osgeo.org/grass/ticket/1942 -- View this message in context: http://osgeo-org.1560.x6.nabble.com/v-label-sa-not-working-with-areas-tp5048543p5048778.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ 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] grass vector model, cats and layers concept
That looks nice and clear to me now.
Best,
Ben
On 04/22/2013 10:37 PM, Vincent Bain wrote:
Thank you Ben and Moritz for your comments,
http://www.toraval.fr/telec/catsnlayers_4.zip
Feel free to modify the source svg file,
Vincent.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.sun use - automaticcaly stopped process ?
Hi, Hamish : Thanks again for all precision regarding resolutions and RAM use. All given examples in your last message give me a better idea of what I can do with my dataset/system config. The reason, I want the best resolution is that I'm calculating sun irradiation on buildings (roofs). A 0.2m resolution is ideal. 0.5 can be accurate enough ... 1m is just acceptable! ;-) Will try to optimize my treatment by processing my raster file not on the full extent but on each administrative boundary and then merge them). Markus Metz-3 wrote That's why there is the numpartitions option. Try r.sun numpartitions= 1 Indeed, but I'm calculating shadow and /numpartitions/ option does not work with /-s/ flag (shadow) or /horizon/ option. Thanks anyway. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/r-sun-use-automaticcaly-stopped-process-tp5047682p5049139.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] limitations of r.stream.order
Well, working with subsets of the area worked, It was indeed a RAM limitation. best Carlos On Sun, Apr 21, 2013 at 6:09 PM, Rich Shepard rshep...@appl-ecosys.comwrote: On Sun, 21 Apr 2013, Carlos Grohmann wrote: I need a detail a bit more compatible with topo maps at 1:1.000.000 scale, which I can get if I use a threshold of 25-50 cells. But then, of course, I have a more dense drainage network, and it seems that r.stream.order is having problems dealing with such dense networks. Carlos, Well, if your workstation has sufficient memory for all the calculations then I've no idea what to suggest. The largest area with which I've worked is 125 square miles (however many square kilometers that is) and I can delineate too many drainage basins with 4G RAM. Perhaps working in smaller chunks of area and recombining results will do the job. Otherwise, others with more expertise will need to offer suggestions. Regards, Rich -- Richard B. Shepard, Ph.D. | Integrity - Credibility - Innovation Applied Ecosystem Services, Inc. | http://www.appl-ecosys.com Voice: 503-667-4517 Fax: 503-667-8863 -- Prof. Carlos Henrique Grohmann Institute of Geosciences - Univ. of São Paulo, Brazil - Digital Terrain Analysis | GIS | Remote Sensing - http://carlosgrohmann.com http://orcid.org/-0001-5073-5572 Can’t stop the signal. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Installing an addon in winGRASS 7.0 for complete dummy
Hello there, I have installed GRASS 7.0 on 64 bit Windows 7 and cannot figure out how to install an addon, specifically r.geomorphon. As far as I can tell, it should be possible to run 'Fetch' from the 'Fetch and install extension from GRASS Addons' dialog, find the extension, and install it. But when I click 'Fetch' the dialog never comes back with a list. I just see 'Fetching list of modules...' at the bottom and nothing ever happens. And the instructions under 'Addons' on http://grasswiki.osgeo.org/wiki/Compile_and_Install are beyond my comprehension as are all of the search results I have come up with so far. I am afraid I need very basic instructions. Thanks Evan -- Evan Thoms USGS, Alaska Science Center 4210 University Drive, Anchorage, AK 99508 voice: 907-786-7409 fax: 907-786-7401 eth...@usgs.gov https://mail.google.com/mail/?view=cmfs=1tf=1to=eth...@usgs.gov ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Installing an addon in winGRASS 7.0 for complete dummy
Evan wrote: Hello there, I have installed GRASS 7.0 on 64 bit Windows 7 and cannot figure out how to install an addon, specifically r.geomorphon. Hi, since most Windows computers don't have a common compiler and building environment built in, what we do (i.e. Martin L. does) is run a script every night to build many of the addon modules for Windows, then the addon installer in GRASS detects that it is running on Windows and tries to download the prebuilt module instead of building it from scratch as would happen on the multitude of UNIX variants. A list of published modules ready for public consumption is maintained in the addons repository, in this case r.geomorphon wasn't on the list, so wasn't available from the Windows download site. I've just added it to that list, try again in 4-6 hours from now. But when I click 'Fetch' the dialog never comes back with a list. I just see 'Fetching list of modules...' at the bottom and nothing ever happens. I'd guess that the error-detection code in the extension manager could use a few more checks for possible failure scenarios. it looks like an interesting module, an improvement on r.param.scale's feature method. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
