[GRASS-user] v.buffer: circles around points
Hi, I'm starting to use v.buffer to create circles around points on Lat/Long vector maps. When entering a value for the distance parameter for v.buffer to create circles for points on lat/long maps, is the distance entered the radius of the circle or is it the diameter? or some other variable? Thanks in advance, Sharon ___ 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, 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, 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): > >> > >> # > >> 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 > >> 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] 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
Markus Neteler wrote: > Here an increase to 1500 files (use * instead of neteler to aply > it to all users): > > # > 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 > 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//fd" (where 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 ___ 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 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 ... 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 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 ... 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
[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
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
Re: [GRASS-user] Re: g.extension (e.g. to install i.landsat.toar)
On Tue, Nov 2, 2010 at 5:16 PM, Gabriele N. 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 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 ... > 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
[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 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 ... 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] r.patch: number of rasters
On Tue, Nov 2, 2010 at 4:41 PM, 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, 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): >> >> # >> 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 >> 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, 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): > > # > 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 > 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 2:03 PM, 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): # 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 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] 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] About "Add created map into layer tree" flag
Hi, 2010/11/2 Luisa Peña : > 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 * 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] About "Add created map into layer tree" flag
Greetings 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? Thanks Luisa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.patch: number of rasters
Dear all Is there a limit on the number of rasters for r.patch? Cheers Sab ___ 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 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 >> >> 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
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 > 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
[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] 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 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
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
