Re: [GRASS-user] Help for Wx-Georrectifier
Kim Besson wrote: Greetings I'm starting to use Wx Georrectifier (Geometric Correction) and, in a couple of messages from a few weeks I saw that some help for Georrectifer was added to GRASS but I didn't find anything. could anyone point me out? Im using WinGRASS 6.4.0 (stable). The help is part of the new Georectifier in wxGUI (File - Manage Ground Control Points) which is available only in 6.4.1 and above. The latest 6.4 Windows installer is available here [1] Markus M [1] http://josef.fsv.cvut.cz/wingrass/grass64/ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] using r.mode- Can different resolutions be a problem?
Thanks Markus. By the way, just one last question: If I have pixel values that I don't want to apply r.mode (for instance 0), can I transform them to null (using r.mapcalc) and then apply r.mode? Isn't there any issue regarding null values? Thanks On Sat, Oct 30, 2010 at 5:34 PM, Markus Neteler nete...@osgeo.org wrote: It will work of course but not necessarily be statistically significant (think for example at a high resolution base map and a just one-pixel cover map...). So some careful reasoning is recommended. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.param.scale curvatures: are really OK
Hi while I modified r.param.scale for my purposes I noticed that some formulas for curvatures differs from that I know: for example: plan curvature: is (2.0 * (b * d * d + a * e * e - c * d * e) / pow(e * e + d * d, 1.5)); probably shall be: ( (b * d * d + a * e * e - 2.0 *(c * d * e)) / pow(e * e + d * d, 1.5)); profile curvature: is return (-2.0 * (a * d * d + b * e * e + c * e * d) / ((e * e + d * d) * pow(1.0 + d * d + e * e, 1.5))); probably shall be: return (- (a * d * d + b * e * e + 2.0* (c * e * d)) / ((e * e + d * d) * pow(1.0 + d * d + e * e, 1.5))); Of course threre could be reasons why little different formulas are used but I do not see any. This formulas is in grass 6.4, 6.5 and 7.0 and I assume in older version too. regards Jarek ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Help for Wx-Georrectifier
Hi Markus Thanks. I do have a weekly snapshot 6.4.1 but I don't have that yet. is it possible to integrate that part in a earlier version of 6.4.1? Thanks Kim By the way, How can I check which release am I using and, what changes have occured since my release? 2010/11/2 Markus Metz markus.metz.gisw...@googlemail.com Kim Besson wrote: Greetings I'm starting to use Wx Georrectifier (Geometric Correction) and, in a couple of messages from a few weeks I saw that some help for Georrectifer was added to GRASS but I didn't find anything. could anyone point me out? Im using WinGRASS 6.4.0 (stable). The help is part of the new Georectifier in wxGUI (File - Manage Ground Control Points) which is available only in 6.4.1 and above. The latest 6.4 Windows installer is available here [1] Markus M [1] http://josef.fsv.cvut.cz/wingrass/grass64/ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Help for Wx-Georrectifier
On Tue, Nov 2, 2010 at 10:31 AM, Kim Besson kimbesson1...@gmail.com wrote: Hi Markus Thanks. I do have a weekly snapshot 6.4.1 but I don't have that yet. is it possible to integrate that part in a earlier version of 6.4.1? The easiest way really is to get an updated snapshot. By the way, How can I check which release am I using g.version -r prints the GIS library revision number and time (not necessarily the latest change included in your version). and, what changes have occured since my release? This you could see here: https://trac.osgeo.org/grass/log/grass/branches/releasebranch_6_4/ but it may be quite a bit, the version you are using must be older than 5 weeks (it's about 5 weeks ago that I added the new GCP Manager to the wxGUI in 6.4) Markus M 2010/11/2 Markus Metz markus.metz.gisw...@googlemail.com Kim Besson wrote: Greetings I'm starting to use Wx Georrectifier (Geometric Correction) and, in a couple of messages from a few weeks I saw that some help for Georrectifer was added to GRASS but I didn't find anything. could anyone point me out? Im using WinGRASS 6.4.0 (stable). The help is part of the new Georectifier in wxGUI (File - Manage Ground Control Points) which is available only in 6.4.1 and above. The latest 6.4 Windows installer is available here [1] Markus M [1] http://josef.fsv.cvut.cz/wingrass/grass64/ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] About Add created map into layer tree flag
Hi, 2010/11/2 Luisa Peña luisapena1...@gmail.com: I have produced 2 or 3 python scripts and I realized that, in some of them, I get an extra flag in Required tab (Add created map into layer tree) and in others scrips I just get the Close dialog on finish. Why is that? this option is available when the module has at least one raster/vector/raster3d output. Then the output maps can be automatically added into the layer tree. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] d.rast.arrows in high quality plot
Dear all, I'm trying to plot arrows, representing length proportional to magnitude in a printable high resolution map (with d.rast.arrows). Here is what I tried: #!/bin/sh export GRASS_WIDTH=1 export GRASS_HEIGHT=1 export GRASS_PNGFILE=testpng.png export GRASS_PNG_COMPRESSION=0 #export GRASS_RENDER_IMMEDIATE=TRUE export GRASS_TRUECOLOR=TRUE g.region fig_arrows d.mon start=PNG d.rast map=backgro...@permanent d.rast map=magnitude_...@permanent d.rast.arrow map=direction_...@permanent type=compass arrow_color=black grid_color=none x_color=black unknown_color=red skip=12 scale=20 magnitude_map=magnitude_...@permanent d.mon stop=PNG eog $GRASS_PNGFILE Unfortunately the plotted arrows are quite slim now... is there another solution to achieve this goal? Many thanks, Niklas -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch: number of rasters
On Tue, Nov 2, 2010 at 2:03 PM, razmjoo...@faunalia.co.uk wrote: Dear all Is there a limit on the number of rasters for r.patch? How funny, we had the same question at the same time... :) From GRASS 6.4+ there is no more limit despite the limit of open files per process (which depends on the operating system; for Linux it is usually 1024 files). To increase that: The limit of open files per process was reached (64bit Linux: 1024 files; ulimit -n) To overcome this limit, the nofile parameter needs to be increased in the /etc/security/limits.conf file. Here an increase to 1500 files (use * instead of neteler to aply it to all users): #domain type item value neteler hardnofile 1500 But myself, I got troubles when having registered the maps with r.external: GRASS 6.4.1svn (patUTM32):~ r.patch in=`g.mlist type=rast pattern=dtm00* sep=comma mapset=dtm_1m_external` out=dtm_trentino_2m ERROR 1: TIFFOpen:/geodata/base_cartography/pat_DTM_LIDAR_2007_UTM_WGS84/geotiffs/dtm000501.tif: Too many open files WARNING: Unable to open '/grassdata/patUTM32/dtm_1m_external/cell_misc/dtm000501/f_format' WARNING: quantization file [dtm000501] in mapset [dtm_1m_external] missing WARNING: Unable to open raster map dtm000...@dtm_1m_external ERROR: One or more input raster maps not found So far I could not find out the reason. Here I am using 500 files registered with r.external. Help welcome, Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch: number of rasters
Hi Markus Many thanks for your response. In the past versions, the patched raster used to have an odd values. I use Grass 6.4 from Ubuntu 10.10 64 bit repo. Cheers Sab On Tue, Nov 2, 2010 at 2:03 PM, razmjoo...@faunalia.co.uk wrote: Dear all Is there a limit on the number of rasters for r.patch? How funny, we had the same question at the same time... :) From GRASS 6.4+ there is no more limit despite the limit of open files per process (which depends on the operating system; for Linux it is usually 1024 files). To increase that: The limit of open files per process was reached (64bit Linux: 1024 files; ulimit -n) To overcome this limit, the nofile parameter needs to be increased in the /etc/security/limits.conf file. Here an increase to 1500 files (use * instead of neteler to aply it to all users): #domain type item value neteler hardnofile 1500 But myself, I got troubles when having registered the maps with r.external: GRASS 6.4.1svn (patUTM32):~ r.patch in=`g.mlist type=rast pattern=dtm00* sep=comma mapset=dtm_1m_external` out=dtm_trentino_2m ERROR 1: TIFFOpen:/geodata/base_cartography/pat_DTM_LIDAR_2007_UTM_WGS84/geotiffs/dtm000501.tif: Too many open files WARNING: Unable to open '/grassdata/patUTM32/dtm_1m_external/cell_misc/dtm000501/f_format' WARNING: quantization file [dtm000501] in mapset [dtm_1m_external] missing WARNING: Unable to open raster map dtm000...@dtm_1m_external ERROR: One or more input raster maps not found So far I could not find out the reason. Here I am using 500 files registered with r.external. Help welcome, Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch: number of rasters
On Tue, Nov 2, 2010 at 4:41 PM, razmjoo...@faunalia.co.uk wrote: Hi Markus Many thanks for your response. In the past versions, the patched raster used to have an odd values. No, this is rather impossible (perhaps you refer to the odd number of pixels in a moving raster window). I use Grass 6.4 from Ubuntu 10.10 64 bit repo. Master question: how many files do you plan to patch? Markus Cheers Sab On Tue, Nov 2, 2010 at 2:03 PM, razmjoo...@faunalia.co.uk wrote: Dear all Is there a limit on the number of rasters for r.patch? How funny, we had the same question at the same time... :) From GRASS 6.4+ there is no more limit despite the limit of open files per process (which depends on the operating system; for Linux it is usually 1024 files). To increase that: The limit of open files per process was reached (64bit Linux: 1024 files; ulimit -n) To overcome this limit, the nofile parameter needs to be increased in the /etc/security/limits.conf file. Here an increase to 1500 files (use * instead of neteler to aply it to all users): #domain type item value neteler hard nofile 1500 But myself, I got troubles when having registered the maps with r.external: GRASS 6.4.1svn (patUTM32):~ r.patch in=`g.mlist type=rast pattern=dtm00* sep=comma mapset=dtm_1m_external` out=dtm_trentino_2m ERROR 1: TIFFOpen:/geodata/base_cartography/pat_DTM_LIDAR_2007_UTM_WGS84/geotiffs/dtm000501.tif: Too many open files WARNING: Unable to open '/grassdata/patUTM32/dtm_1m_external/cell_misc/dtm000501/f_format' WARNING: quantization file [dtm000501] in mapset [dtm_1m_external] missing WARNING: Unable to open raster map dtm000...@dtm_1m_external ERROR: One or more input raster maps not found So far I could not find out the reason. Here I am using 500 files registered with r.external. Help welcome, Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: g.extension (e.g. to install i.landsat.toar)
Hi Markus. I have installed grass-dev but now there is another problem (there is a problem of permissions for the folder creation and does not solve if I create the folder before launching g.extension): g.extension i.landsat.toar Fetching i.landsat.toar from GRASS-Addons SVN (be patient)... Ai.landsat.toar/landsat_set.c Ai.landsat.toar/local_proto.h Ai.landsat.toar/main.c Ai.landsat.toar/description.html Ai.landsat.toar/landsat.c Ai.landsat.toar/earth_sun.c Ai.landsat.toar/landsat.h Ai.landsat.toar/landsat_met.c Ai.landsat.toar/Makefile Ai.landsat.toar/earth_sun.h U i.landsat.toar Estratta revisione 44172. Compiling i.landsat.toar... mkdir -p /build/buildd/grass-6.4.0/dist.i686-pc-linux-gnu/include/grass mkdir: impossibile creare la directory `/build/buildd/grass-6.4.0/dist.i686-pc-linux-gnu': Permesso negato make: *** [/build/buildd/grass-6.4.0/dist.i686-pc-linux-gnu/include/grass] Errore 1 ERRORE: Compilation failed, sorry. Please check above error messages. Thanks -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/g-extension-e-g-to-install-i-landsat-toar-tp5662708p5698083.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] Re: g.extension (e.g. to install i.landsat.toar)
On Tue, Nov 2, 2010 at 5:16 PM, Gabriele N. gis...@libero.it wrote: Hi Markus. I have installed grass-dev but now there is another problem (there is a problem of permissions for the folder creation and does not solve if I create the folder before launching g.extension): g.extension i.landsat.toar Fetching i.landsat.toar from GRASS-Addons SVN (be patient)... A i.landsat.toar/landsat_set.c A i.landsat.toar/local_proto.h A i.landsat.toar/main.c A i.landsat.toar/description.html A i.landsat.toar/landsat.c A i.landsat.toar/earth_sun.c A i.landsat.toar/landsat.h A i.landsat.toar/landsat_met.c A i.landsat.toar/Makefile A i.landsat.toar/earth_sun.h U i.landsat.toar Estratta revisione 44172. Compiling i.landsat.toar... mkdir -p /build/buildd/grass-6.4.0/dist.i686-pc-linux-gnu/include/grass mkdir: impossibile creare la directory `/build/buildd/grass-6.4.0/dist.i686-pc-linux-gnu': Permesso negato make: *** [/build/buildd/grass-6.4.0/dist.i686-pc-linux-gnu/include/grass] Errore 1 ERRORE: Compilation failed, sorry. Please check above error messages. I have fixed this 1-2 weeks ago (for 6.4.1 and later). Please get the updated script here: http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/scripts/g.extension/ and try again with this version. You can simply replace the one you have with this one or rename it or whatever you prefer. Please let me know if it helps (maybe more tweaks are needed but we are getting closer!). Cheers Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.out.pov scale question
I have not heard anything back on this, so decided to go to the source code of r.out.pov. I figured out the answer and wanted to post it, in case it is useful to anyone else, or someone might want to add it to the help page. Here is what I figured out. 1) scale, and hftype are independent. So, first each cell is multiplied by scale (so, if a cell elevation is 12m and scale is 10, then the new value is 120.) The default value of scale is 1.0. If hftype is set to 1, then each cell is multiplied by 65535/(maximum elevation value in the map). So, when using hftype=1, the correct scaling in the POV ray file is the maximum height in the map. For example, if the maximum elevation is 1086 m, then this should go in the POV file: scale 1391, 1086, 1810 // dx,dz,dy of extent in meters Finally, I believe that there is a bug in r.out.pov! It seems that bias is read in, in order to apply a bias to the height field, however hfBias is the variable that is actually being used for the calculations, and it is never assigned a value. And bias is not actually used in any calculations. --Adam On Oct 27, 2010, at 9:07 AM, Adam Dershowitz, Ph.D., P.E. wrote: I have been trying to use r.out.pov but something is not clear to me from the documentation, and examples I can find on the web. If I use hftype=0 (the default) then, as I understand it it, each step, from 0-65535 represents one map unit (meters in my case). That is giving me too much stair-stepping in POVRAY. I think that part of the issue is that there is too much rounding of elevations. So, I decided to try hrtype=1. As I understand it that will scale the height of the image to use more of the range (my map just goes from 61-1086 meters). But, I can't seem to figure out how much it scales by. There is also the scale= option in r.out.pov, but I am not sure if that is a multiplier or a divider? This is important because I need to then scale the heighfield in my POV file. If I use hrtype=0 then this is correct: scale dx, 65535, dy But, if I use hftype=1, what is the correct value for the above scale command? Is it 65535/1086 (max height in the map?) 65535/(1086-61) (vertical range of my map?) If I use scale=10 then should it be? scale dx, 65535/10, dy scale dx, 65535*10, dy scale dx, 10, dy Or should I use scale=0.1? Or should I use r.out.pov scale=65535/1086 Thanks, --Adam ___ 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
[GRASS-user] Re: r.param.scale curvatures: are really OK
Hello, I cannot really answer your question, but I have been working with a combination of your fuzzy modules for GRASS and r.param.scale in order to accomplish a fuzzified version of Wood's morphometric feature extraction method. In doing so, I noticed that the results of r.param.scale param=feature differ very much from the results of this same module in Wood's original software Landserf, by using the same slope and curvature thresholds. Do you think this can be an associated issue to what you mentioned? All I can say is that the formula you described (the one used in GRASS) is exactly the same that is in Wood's Ph.D. thesis, which in turn is based in Evans (1979) work, as you probably already know. By the way, great fuzzy modules! Best regards, Marcello. Jarek Jasiewicz wrote: Hi while I modified r.param.scale for my purposes I noticed that some formulas for curvatures differs from that I know: for example: plan curvature: is (2.0 * (b * d * d + a * e * e - c * d * e) / pow(e * e + d * d, 1.5)); probably shall be: ( (b * d * d + a * e * e - 2.0 *(c * d * e)) / pow(e * e + d * d, 1.5)); profile curvature: is return (-2.0 * (a * d * d + b * e * e + c * e * d) / ((e * e + d * d) * pow(1.0 + d * d + e * e, 1.5))); probably shall be: return (- (a * d * d + b * e * e + 2.0* (c * e * d)) / ((e * e + d * d) * pow(1.0 + d * d + e * e, 1.5))); Of course threre could be reasons why little different formulas are used but I do not see any. This formulas is in grass 6.4, 6.5 and 7.0 and I assume in older version too. regards Jarek ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/r-param-scale-curvatures-are-really-OK-tp5696388p5698886.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] Re: g.extension (e.g. to install i.landsat.toar)
Markus, still does not work. I saw some differences compared to the old script. To understand ... which is the part that has been changed to fix this? GRASS 6.4.0 (utm_wgs84):~ g.extension i.landsat.toar Fetching i.landsat.toar from GRASS-Addons SVN (be patient)... Ai.landsat.toar/landsat_set.c Ai.landsat.toar/local_proto.h Ai.landsat.toar/main.c Ai.landsat.toar/description.html Ai.landsat.toar/landsat.c Ai.landsat.toar/earth_sun.c Ai.landsat.toar/landsat.h Ai.landsat.toar/landsat_met.c Ai.landsat.toar/Makefile Ai.landsat.toar/earth_sun.h U i.landsat.toar Estratta revisione 44172. Compiling i.landsat.toar... mkdir -p /build/buildd/grass-6.4.0/bin.i686-pc-linux-gnu mkdir: impossibile creare la directory `/build': Permesso negato make: *** [/build/buildd/grass-6.4.0/bin.i686-pc-linux-gnu] Errore 1 ERRORE: Compilation failed, sorry. Please check above error messages. GRASS 6.4.0 (utm_wgs84):~ g.extension i.landsat.acca Fetching i.landsat.acca from GRASS-Addons SVN (be patient)... Ai.landsat.acca/tools.c Ai.landsat.acca/local_proto.h Ai.landsat.acca/main.c Ai.landsat.acca/description.html Ai.landsat.acca/algorithm.c Ai.landsat.acca/Makefile U i.landsat.acca Estratta revisione 44172. Compiling i.landsat.acca... mkdir -p /build/buildd/grass-6.4.0/bin.i686-pc-linux-gnu mkdir: impossibile creare la directory `/build': Permesso negato make: *** [/build/buildd/grass-6.4.0/bin.i686-pc-linux-gnu] Errore 1 ERRORE: Compilation failed, sorry. Please check above error messages. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/g-extension-e-g-to-install-i-landsat-toar-tp5662708p5699112.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] r.patch: number of rasters
Markus Neteler wrote: Here an increase to 1500 files (use * instead of neteler to aply it to all users): #domain type item value neteler hardnofile 1500 But myself, I got troubles when having registered the maps with r.external: GRASS 6.4.1svn (patUTM32):~ r.patch in=`g.mlist type=rast pattern=dtm00* sep=comma mapset=dtm_1m_external` out=dtm_trentino_2m ERROR 1: TIFFOpen:/geodata/base_cartography/pat_DTM_LIDAR_2007_UTM_WGS84/geotiffs/dtm000501.tif: Too many open files This message matches strerror(EMFILE): #define EMFILE 24 /* Too many open files */ It's possible that some library (i.e. GDAL or TIFF) has its own limit, and returns EMFILE if the limit is reached. But I'd start by assuming that you're hitting an OS limit. WARNING: Unable to open '/grassdata/patUTM32/dtm_1m_external/cell_misc/dtm000501/f_format' WARNING: quantization file [dtm000501] in mapset [dtm_1m_external] missing WARNING: Unable to open raster map dtm000...@dtm_1m_external ERROR: One or more input raster maps not found So far I could not find out the reason. Here I am using 500 files registered with r.external. I assume that it's holding multiple open descriptors per map. Note that 7.0 will typically have at least 2 open descriptors per map: one for the raster data, the other for the null data. But not for r.external linked files, which don't have a separate null file. 6.x doesn't keep the null file open, which reduces the number of open descriptors at the expense of performance (open() can be fairly expensive). Run r.patch under gdb, set a breakpoint on G_fatal_error(). When the breakpoint is hit, ls -l /proc/pid/fd (where pid is the PID of the r.patch process) to see *which* files it has open. Or run r.patch under strace, and manually examine the output to see which files are open()ed and which are close()d. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] d.rast.arrows in high quality plot
Hi Niklas, Same for me: the PNG driver draws thinner and thinner arrows when you increase the resolution. If you lower the resolution it's okay though. If you do need such a high resolution (for a poster?), you might try the CAIRO driver (g.manual displaydrivers) which behaves quite differently when producing PNGs. Arrows are drawn with a thicker pen indeed (even at high pixel resolution) but you might be surprised by the raster rendering... and files get very large. Nicolas Le mardi 02 novembre 2010 à 16:12 +0100, Niklas Neckel a écrit : Dear all, I'm trying to plot arrows, representing length proportional to magnitude in a printable high resolution map (with d.rast.arrows). Here is what I tried: #!/bin/sh export GRASS_WIDTH=1 export GRASS_HEIGHT=1 export GRASS_PNGFILE=testpng.png export GRASS_PNG_COMPRESSION=0 #export GRASS_RENDER_IMMEDIATE=TRUE export GRASS_TRUECOLOR=TRUE g.region fig_arrows d.mon start=PNG d.rast map=backgro...@permanent d.rast map=magnitude_...@permanent d.rast.arrow map=direction_...@permanent type=compass arrow_color=black grid_color=none x_color=black unknown_color=red skip=12 scale=20 magnitude_map=magnitude_...@permanent d.mon stop=PNG eog $GRASS_PNGFILE Unfortunately the plotted arrows are quite slim now... is there another solution to achieve this goal? Many thanks, Niklas ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch: number of rasters
I am having about 700 LiDAR tiles (~4 GB). Did it a couple of hours ago and all worked well...the DTM looks as I expected! The problem I had last year when I did it last, there were 1000+, values for one tile were changed. Never investigated the problem. Simply changed the region and things worked smoothly. Many thanks Sab On Tue, 2010-11-02 at 16:54 +0100, Markus Neteler wrote: On Tue, Nov 2, 2010 at 4:41 PM, razmjoo...@faunalia.co.uk wrote: Hi Markus Many thanks for your response. In the past versions, the patched raster used to have an odd values. No, this is rather impossible (perhaps you refer to the odd number of pixels in a moving raster window). I use Grass 6.4 from Ubuntu 10.10 64 bit repo. Master question: how many files do you plan to patch? Markus Cheers Sab On Tue, Nov 2, 2010 at 2:03 PM, razmjoo...@faunalia.co.uk wrote: Dear all Is there a limit on the number of rasters for r.patch? How funny, we had the same question at the same time... :) From GRASS 6.4+ there is no more limit despite the limit of open files per process (which depends on the operating system; for Linux it is usually 1024 files). To increase that: The limit of open files per process was reached (64bit Linux: 1024 files; ulimit -n) To overcome this limit, the nofile parameter needs to be increased in the /etc/security/limits.conf file. Here an increase to 1500 files (use * instead of neteler to aply it to all users): #domain type item value neteler hardnofile 1500 But myself, I got troubles when having registered the maps with r.external: GRASS 6.4.1svn (patUTM32):~ r.patch in=`g.mlist type=rast pattern=dtm00* sep=comma mapset=dtm_1m_external` out=dtm_trentino_2m ERROR 1: TIFFOpen:/geodata/base_cartography/pat_DTM_LIDAR_2007_UTM_WGS84/geotiffs/dtm000501.tif: Too many open files WARNING: Unable to open '/grassdata/patUTM32/dtm_1m_external/cell_misc/dtm000501/f_format' WARNING: quantization file [dtm000501] in mapset [dtm_1m_external] missing WARNING: Unable to open raster map dtm000...@dtm_1m_external ERROR: One or more input raster maps not found So far I could not find out the reason. Here I am using 500 files registered with r.external. Help welcome, Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
