Re: [GRASS-user] problems importing vector and raster data via python script
Many thanks. So, the forward slash does not work in windows. (and I know I should not use literal pathnames, but it's just for testing). So either two forward or backward slashs, or one backward. One other question concerning the flags: How can I put two flags at the same time, as for example -o --o for overwriting the projection check and an already existing file? I tried everything: flags='o', flags='-o' flags='o -o' or flags='-o o' flags='o' '-o' but the interpreter isn't happy with this solutions. Is there any way to put several flags? Sonja Glynn Clements a écrit : Sonja Jankowfsky wrote: I'm running a python script under windows/eclipse, where I try to import a shape and a raster file with v.in.ogr and r.in.gdal. grass.run_command(r.in.gdal,'-o', input='E:\pythoninput\mnyzeron5m.asc', output='dem5m', '-o') Python uses backslash as an escape character; if you need to use a backslash in a string literal, either use two backslashes, i.e.: input='E:\\pythoninput\\mnyzeron5m.asc' or use a raw literal, i.e.: input=r'E:\pythoninput\mnyzeron5m.asc' Alternatively, a forward slash will work. But scripts should rarely need to have literal pathnames embedded within them. grass.run_command(v.in.ogr, '-o', dsn='E:\pythoninput\Mercier_ditch.shp', output='ditch2', '-o') run_command() etc use the flags argument to specify flags (without the leading '-'), e.g.: grass.run_command(v.in.ogr, flags='o', dsn=r'E:\pythoninput\Mercier_ditch.shp', output='ditch2') -- Sonja Jankowfsky UR Hydrologie-Hydraulique Cemagref de Lyon 3 bis quai Chauveau CP 220 69336 Lyon Cedex 09 FRANCE Tel : (+33)4 72 20 86 11 Fax : (+33)4 78 47 78 75 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Which version to start working
Hello Markus Is it possible to know, at this stage, what do you mean for long? I mean, for how long will 6.4 version will be supported and when will 7 be realeased? And how about 6.5? Is it much difference from 6.4? Luisa 2010/1/27 Markus Neteler nete...@osgeo.org On Wed, Jan 27, 2010 at 6:18 PM, Luisa Peña luisapena1...@gmail.com wrote: Greetings I've been browsing around GRASS website and GRASS wikis and I pretend to start working on GRASS in a LINUX system. Besides normal GRASS operations I also want to develop a few modules/scripts that I will probably need. What I want to know is from which version should I start? 6.4, 6.5 or 7? If you want to use the scripts in production, use 6.4. This version will be supported for long; things can radically change in 7 without announcement (since it is a development version). But to be ready for GRASS 7 in future, consider to write them in Python, not in Shell script. Hope this helps, Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Which version to start working
Holla Falo mais ou menos português. Obrigado pela informação e pela ajuda no pretend :) Então entre 6.4 e 6.5 não há diferença? Obrigado Luisa 2010/1/27 Luisa Peña luisapena1...@gmail.com Greetings I've been browsing around GRASS website and GRASS wikis and I pretend to start working on GRASS in a LINUX system. Besides normal GRASS operations I also want to develop a few modules/scripts that I will probably need. What I want to know is from which version should I start? 6.4, 6.5 or 7? Thank you all Luisa Peña S.Paulo, Brasil ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GRASS scripts manual tab
Greetings all I've been browsing around the Scripts and, for example i.tasscap /i.oif, has a fine and nice manual tab associated with the function (with pictures, text bla bla bla). How can I do this manual pages to be associated with my own scripts? Best regards Franz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] problems importing vector and raster data via python script
Many thanks also for the link, it works!! Sonja Christian Kaiser a écrit : Sonja, I think you can use something like this: grass.run_command(v.in.ogr, flags='o', dsn=r'E:\pythoninput\Mercier_ditch.shp', output='ditch2', overwrite=True) See the make_command function for the options: http://download.osgeo.org/grass/grass6_progman/namespacepython_1_1core.html#a6745e7335b5bfcc30d89443fc912c63b For the flags not starting with -- but only with - (short flags), I think you can just concatenate them (flags='oc' for example). For the long flags (overwrite, verbose, quiet), they are a separate argument in the run_command function. Hope this helps, Christian On 28 janv. 2010, at 10:38, Sonja Jankowfsky wrote: Many thanks. So, the forward slash does not work in windows. (and I know I should not use literal pathnames, but it's just for testing). So either two forward or backward slashs, or one backward. One other question concerning the flags: How can I put two flags at the same time, as for example -o --o for overwriting the projection check and an already existing file? I tried everything: flags='o', flags='-o' flags='o -o' or flags='-o o' flags='o' '-o' but the interpreter isn't happy with this solutions. Is there any way to put several flags? Sonja Glynn Clements a écrit : Sonja Jankowfsky wrote: I'm running a python script under windows/eclipse, where I try to import a shape and a raster file with v.in.ogr and r.in.gdal. grass.run_command(r.in.gdal,'-o', input='E:\pythoninput\mnyzeron5m.asc', output='dem5m', '-o') Python uses backslash as an escape character; if you need to use a backslash in a string literal, either use two backslashes, i.e.: input='E:\\pythoninput\\mnyzeron5m.asc' or use a raw literal, i.e.: input=r'E:\pythoninput\mnyzeron5m.asc' Alternatively, a forward slash will work. But scripts should rarely need to have literal pathnames embedded within them. grass.run_command(v.in.ogr, '-o', dsn='E:\pythoninput\Mercier_ditch.shp', output='ditch2', '-o') run_command() etc use the flags argument to specify flags (without the leading '-'), e.g.: grass.run_command(v.in.ogr, flags='o', dsn=r'E:\pythoninput\Mercier_ditch.shp', output='ditch2') -- Sonja Jankowfsky UR Hydrologie-Hydraulique Cemagref de Lyon 3 bis quai Chauveau CP 220 69336 Lyon Cedex 09 FRANCE Tel : (+33)4 72 20 86 11 Fax : (+33)4 78 47 78 75 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Sonja Jankowfsky UR Hydrologie-Hydraulique Cemagref de Lyon 3 bis quai Chauveau CP 220 69336 Lyon Cedex 09 FRANCE Tel : (+33)4 72 20 86 11 Fax : (+33)4 78 47 78 75 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Set language in Linux
Hello Glynn Thanks for the tip regarding LC_ALL I tryed to add LANG=es_ES LANGUAGE=es_ES to my /usr/local/grass-6.4.0svn/etc/init.sh and I got the following at my terminal window: (process:2196): Gdk-WARNING **: locale not supported by C library (process:2196): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. What it might be? By the way, How can I have 2 language sets I mean 2 different launchers with 2 different languages? On Wed, Jan 6, 2010 at 7:29 PM, Glynn Clements gl...@gclements.plus.comwrote: Gilbert Ferrara wrote: I want to set GRASS LANGUAGE in a LINUX installation. In Windows is quite easy, just add the following in .../etc/init.bat: set LANGUAGE=es_ES set LANG=es_ES set LC_ALL=es_ES And in LINUX, how is it done? Just add the same text in .../etc/init.sh and it's finished or do I have to do something to this file? These would normally be set in e.g. ~/.profile (or ~/.bash_profile etc; there are quite a lot of files which may be read by the shell) then inherited by all processes. Setting environment variables in Unix is done with e.g.: LANG=es_ES export LANG I'd advise against using LC_ALL, as it overrides LC_NUMERIC. This can cause numbers to use a comma as the decimal separator, which is problematic when writing files (most file formats require a period). GRASS modules only use the LC_MESSAGES category directly, but some programs and (especially) scripts invoke external programs which may be affected by the LC_NUMERIC or LC_ALL settings (scripts which use awk are prone to this, although I think that we have now found them all and forced LC_NUMERIC=C). -- 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] Which version to start working
Hi Luisa, On Thu, Jan 28, 2010 at 10:40 AM, Luisa Peña luisapena1...@gmail.com wrote: Hello Markus Is it possible to know, at this stage, what do you mean for long? I mean, for how long will 6.4 version will be supported and when will 7 be realeased? it is open source - as long as we are interested :) I submitted yesterday some compilation fixes to 6.3. Some months ago even something for 5.5... Typically it works on the complaint basis (I guess): someone has a problem, reports it and the developers (you and me and the community) check what could be done. For many months nobody has asked for GRASS 5, so apparently they migrated to GRASS 6 because of the new shiny functions. But if a backport isn't complicated, it can be done. If it is complicated, better get some money ready :) Or find a volunteer. Or do it yourself and send the changes to us for inclusion in the main version. And how about 6.5? Is it much difference from 6.4? Some, it is a kind of testbed for 6.4 with no intention to ever release it (since we concentrate on 7). So I would use 6.4 and report is there are problems. BTW: we are also pleased to get positive feedback - best published somewhere as success story! cheers Markus Luisa 2010/1/27 Markus Neteler nete...@osgeo.org On Wed, Jan 27, 2010 at 6:18 PM, Luisa Peña luisapena1...@gmail.com wrote: Greetings I've been browsing around GRASS website and GRASS wikis and I pretend to start working on GRASS in a LINUX system. Besides normal GRASS operations I also want to develop a few modules/scripts that I will probably need. What I want to know is from which version should I start? 6.4, 6.5 or 7? If you want to use the scripts in production, use 6.4. This version will be supported for long; things can radically change in 7 without announcement (since it is a development version). But to be ready for GRASS 7 in future, consider to write them in Python, not in Shell script. Hope this helps, Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Max length of sql_query in v.extract
On 28/01/2010 00:45, Markus Neteler wrote: On Wed, Jan 27, 2010 at 8:35 PM, Luigi Ponti lpo...@infinito.it wrote: Hello, Is there a length limit to a where sql statement fed to v.extract? I am getting an ... Error in db_open_select_cursor() ... in the middle of a very long query. Could you please try to analyse with g.gisenv set=DEBUG=3 to identify when it gets lost? And perhaps provide an example based on the Spearfish or North Carolina data sets? Version: WinGRASS-6.4.SVN-r40650-1 (installed in C:\GRASS-64-SVN i.e. no spaces in path; OS Windows 7) Dataset: North Caroline dataset Mapset: user1 vector: census_wake2000 (this actually resides in PERMANENT) Working on the Cmd input box of the wxGUI. I have chosen a case analogous to that where I encountered the error, i.e. a DBF Character field containing 105 different numeric codes (e.g. 050100) one per record: (note that you can find full debug output in a text file available at the following link: https://docs.google.com/leaf?id=0B0EpsfMZ-IZYOTJiYWVmNjUtNGYzMC00NDM5LWI1NDYtZTMyNzg3M2NjOThksort=namelayout=listnum=50 I thought 20,000+ lines was too much for the mailing list but please advice if had better taken a different course of action.) ### START GRASS CMD HISTORY ### g.gisenv set=DEBUG=3 (Thu Jan 28 12:12:34 2010) Command finished (0 sec) (Thu Jan 28 12:12:43 2010) v.extract input=census_wake2000 output=census_extract_all_trt2000 where=(TRT2000='050100')or(TRT2000='050300')or(TRT2000='050400')or(TRT2000='050500')or(TRT2000='050600')or(TRT2000='050700')or(TRT2000='050800')or(TRT2000='050900')or(TRT2000='051000')or(TRT2000='051100')or(TRT2000='051200')or(TRT2000='051400')or(TRT2000='051501')or(TRT2000='051502')or(TRT2000='051600')or(TRT2000='051700')or(TRT2000='051800')or(TRT2000='051900')or(TRT2000='052001')or(TRT2000='052002')or(TRT2000='052101')or(TRT2000='052102')or(TRT2000='052201')or(TRT2000='052202')or(TRT2000='052301')or(TRT2000='052302')or(TRT2000='052401')or(TRT2000='052402')or(TRT2000='052404')or(TRT2000='052405')or(TRT2000='052501')or(TRT2000='052503')or(TRT2000='052504')or(TRT2000='052601')or(TRT2000='052602')or(TRT2000='052603')or(TRT2000='052701')or(TRT2000='052703')or(TRT2000='052704')or(TRT2000='052705')or(TRT2000='052801')or(TRT2000='052802')or(TRT2000='052803')or(TRT2000='052804')or(TRT2000='052805')or(TRT2000='052900')or(TRT2000='053001')or(TRT2000='053002')or(TRT2000='053101')or(TRT2000='053103')or(TRT2000='053104')or(TRT2000='053200')or(TRT2000='053402')or(TRT2000='053403')or(TRT2000='053404')or(TRT2000='053405')or(TRT2000='053406')or(TRT2000='053407')or(TRT2000='053501')or(TRT2000='053505')or(TRT2000='053506')or(TRT2000='053507')or(TRT2000='053508')or(TRT2000='053509')or(TRT2000='053510')or(TRT2000='053512')or(TRT2000='053513')or(TRT2000='053514')or(TRT2000='053515')or(TRT2000='053600')or(TRT2000='053703')or(TRT2000='053706')or(TRT2000='053707')or(TRT2000='053709')or(TRT2000='053710')or(TRT2000='053711')or(TRT2000='053712')or(TRT2000='053713')or(TRT2000='053714')or(TRT2000='053715')or(TRT2000='053716')or(TRT2000='053801')or(TRT2000='053802')or(TRT2000='053900')or(TRT2000='054001')or(TRT2000='054003')or(TRT2000='054004')or(TRT2000='054006')or(TRT2000='054007')or(TRT2000='054008')or(TRT2000='054009')or(TRT2000='054010')or(TRT2000='054102')or(TRT2000='054104')or(TRT2000='054105')or(TRT2000='054106')or(TRT2000='054107')or(TRT2000='054108')or(TRT2000='054109')or(TRT2000='054201')or(TRT2000='054202')or(TRT2000='054301')or(TRT2000='054302')or(TRT2000='054401')or(TRT2000='054402') D3/3: Mapset = PERMANENT D1/3: Vect_open_old(): name = census_wake2000 mapset= PERMANENT update = 0 D1/3: Vect_set_thresh(): thresh = 0.00 [...] D3/3: db_select_int() D3/3: SQL: SELECT cat FROM census_wake2000 WHERE (TRT2000= '050100')or(TRT2000='050300')or(TRT2000='050400')or(TRT2000= '050500')or(TRT2000='050600')or(TRT2000='050700')or(TRT2000= '050800')or(TRT2000='050900')or(TRT2000='051000')or(TRT2000= '051100')or(TRT2000='051200')or(TRT2000='051400')or(TRT2000= '051501')or(TRT2000='051502')or(TRT2000='051600')or(TRT2000= '051700')or(TRT2000='051800')or(TRT2000='051900')or(TRT2000= '052001')or(TRT2000='052002')or(TRT2000='052101')or(TRT2000= '052102')or(TRT2000='052201')or(TRT2000='052202')or(TRT2000= '052301')or(TRT2000='052302')or(TRT2000='052401')or(TRT2000= '052402')or(TRT2000='052404')or(TRT2000='052405')or(TRT2000= '052501')or(TRT2000='052503')or(TRT2000='052504')or(TRT2000= '052601')or(TRT2000='052602')or(TRT2000='052603')or(TRT2000= '052701')or(TRT2000='052703')or(TRT2000='052704')or(TRT2000= '052705')or(TRT2000='052801')or(TRT2000='052802')or(TRT2000= '052803')or(TRT2000='052804')or(TRT2000='052805')or(TRT2000= '052900')or(TRT2000='053001')or(TRT2000='053002')or(TRT2000= '053101')or(TRT DBMI-DBF driver error: SQL parser error: syntax error, unexpected $end processing
Re: [GRASS-user] GRASS scripts manual tab
I think your question was answered here. Bests facu.- *Markus Neteler* neteler at osgeo.org mailto:grass-user%40lists.osgeo.org?Subject=%5BGRASS-user%5D%20manual%20page%20for%20addonsIn-Reply-To=4AB1200D.7050700%40alumni.uv.es /Sun Nov 1 11:11:20 EST 2009/ * Previous message: [GRASS-user] Using GRASS and R at the same time (wxpython) http://lists.osgeo.org/pipermail/grass-user/2009-November/052849.html * Next message: [GRASS-user] manual page for addons http://lists.osgeo.org/pipermail/grass-user/2009-November/052855.html * *Messages sorted by:* [ date ] http://lists.osgeo.org/pipermail/grass-user/2009-November/date.html#52850 [ thread ] http://lists.osgeo.org/pipermail/grass-user/2009-November/thread.html#52850 [ subject ] http://lists.osgeo.org/pipermail/grass-user/2009-November/subject.html#52850 [ author ] http://lists.osgeo.org/pipermail/grass-user/2009-November/author.html#52850 2009/9/16 Facundo Muñoz famuvie at alumni.uv.es http://lists.osgeo.org/mailman/listinfo/grass-user: / // Hi, // I'm using a grass script of my own (say script.sh) which is located in a // separate directory pointed by GRASS_ADDON_PATH. // However, the graphical interface provided by g.parser does not show the // corresponding manual page. // I have a script.sh.html in the same directory. ¿Should I put a copy in // /usr/share/doc/grass-doc/html/? / Yes. / ¿Is there any other environment variable pointing to the add-on // documentation? / AFAIK that's not (yet?) available. Markus / Thanks! // facu.- // ___ // grass-user mailing list // grass-user at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user // http://lists.osgeo.org/mailman/listinfo/grass-user // / Franz Schiller escribió: Greetings all I've been browsing around the Scripts and, for example i.tasscap /i.oif, has a fine and nice manual tab associated with the function (with pictures, text bla bla bla). How can I do this manual pages to be associated with my own scripts? Best regards Franz ___ 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] Problems Running r.flow
Rich Shepard wrote:
In -6.4svn from last Friday's weekly snapshot.
After setting g.region rast=aber5m I tried running r.flow elevin=aber5m
aspin=aber5aspect flout=aberFlowline lgout=aberFlowlength and ran into
resolution problems:
Reading input files: elevation
ERROR: Elevation file's resolution differs from current region resolution
g.region -p reports:
nsres: 4.99982001
ewres: 4.99979979
g.region rast=aber5m -p reports:
nsres: 4.99982001
ewres: 4.99979979
That's a bug in r.flow:
if (!((region.ew_res == hd.ew_res)
(region.ns_res == hd.ns_res)))
G_fatal_error(_(Elevation file's resolution differs from current
region resolution));
Testing floating-point values for exact equality is usually wrong.
E.g. the above code will generate an error even if the values only
differ by one part in one quadrillion (the epsilon for IEEE
double-precision floating point is ~2.22e-16, and represents the
smallest value which can be added to 1.0 without the result being
rounded to 1.0).
Even if you use g.region rast=... to set the current region to the
map's region, the current region may not exactly match due to rounding
errors.
g.region *always* recalculates the resolution as (north-south)/rows
and (east-west)/cols. If you tell it to preserve the resolution, it
adjusts the bounds so that the resulting resolution should remain
unchanged, but rounding errors may ultimately cause it to end up
differing in the least significant digit.
Given that IEEE double precision is sufficient to represent e.g. the
circumference of the earth with an error of roughly 9 nanometres,
rounding errors in the least significant digit really shouldn't be an
issue.
I also get the same error message about the aspect map (derived from the
elevation map) which has the same resolution as above.
Any ideas what's going on? More importantly, how do I get his module
running here?
Try the attached patch. It replaces the exact comparison with a check
that the resolutions agree to within 1ppm.
--
Glynn Clements gl...@gclements.plus.com
Index: raster/r.flow/io.c
===
--- raster/r.flow/io.c (revision 40694)
+++ raster/r.flow/io.c (working copy)
@@ -27,6 +27,7 @@
#include stdio.h
#include stdlib.h
#include unistd.h
+#include math.h
#include grass/glocale.h
#include r.flow.h
#include mem.h
@@ -68,6 +69,12 @@
return G_open_cell_old(fname, mapset);
}
+static int compare_regions(const struct Cell_head *a, const struct Cell_head
*b)
+{
+return (fabs(a-ew_res - b-ew_res) 1e-6 * b-ew_res
+ fabs(a-ns_res - b-ns_res) 1e-6 * b-ns_res);
+}
+
void read_input_files(void)
{
DCELL *barc;
@@ -77,8 +84,7 @@
G_message(_(Reading input files: elevation));
fd = open_existing_cell_file(parm.elevin, hd);
-if (!((region.ew_res == hd.ew_res)
- (region.ns_res == hd.ns_res)))
+if (!compare_regions(region, hd))
G_fatal_error(_(Elevation file's resolution differs from current
region resolution));
for (row = 0; row region.rows; row++) {
@@ -93,8 +99,7 @@
if (parm.aspin) {
G_message(_(Reading input files: aspect));
fd = open_existing_cell_file(parm.aspin, hd);
- if (!((region.ew_res == hd.ew_res)
- (region.ns_res == hd.ns_res)))
+ if (!compare_regions(region, hd))
G_fatal_error(_(Resolution of aspect file differs from
current region resolution));
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.mapcalc question
Hello grass-users, I have a problem running a r.mapcalc procedure: given two maps dir_x, dir_y with 0,1,-1 entries I want to run: r.mapcalc the_map=if(isnull(the_map),the_map[dir_x,dir_y],null()) in order to make a r.water.outlet on many many areas at the same time. The error I get is: syntax error, unexpected NAME, expecting INTEGER or '-' why does dir_x/dir_y does not return an integer here? Using int(dir_x) also does not work. Until now I use a r.mapcalc command with many if, checking the direction of every pixel every time. But this is quite slow. Achim ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Set language in Linux
Gilbert Ferrara wrote: I tryed to add LANG=es_ES LANGUAGE=es_ES to my /usr/local/grass-6.4.0svn/etc/init.sh and I got the following at my terminal window: (process:2196): Gdk-WARNING **: locale not supported by C library (process:2196): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. What it might be? This suggests that you don't have the necessary locale files installed; look in /usr/share/i18n/locales. Some distributions only support UTF-8 locales, in which case you may need to use es_ES.UTF-8. By the way, How can I have 2 language sets I mean 2 different launchers with 2 different languages? Launchers? Generally, the locale is set on a per-user basis. If you want to set the locale for individual processes, you have to set LANG/LC_* yourself, e.g. providing a script which sets the variables before invoking the application. -- 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] Max length of sql_query in v.extract
On Thu, Jan 28, 2010 at 1:34 PM, Luigi Ponti lpo...@infinito.it wrote:
On 28/01/2010 00:45, Markus Neteler wrote:
On Wed, Jan 27, 2010 at 8:35 PM, Luigi Ponti lpo...@infinito.it wrote:
Hello,
Is there a length limit to a where sql statement fed to v.extract?
I am getting an
...
Error in db_open_select_cursor()
...
in the middle of a very long query.
Could you please try to analyse with
g.gisenv set=DEBUG=3
to identify when it gets lost? And perhaps provide an example
based on the Spearfish or North Carolina data sets?
Version: WinGRASS-6.4.SVN-r40650-1 (installed in C:\GRASS-64-SVN i.e. no
spaces in path; OS Windows 7)
Dataset: North Caroline dataset
Mapset: user1
vector: census_wake2000 (this actually resides in PERMANENT)
Working on the Cmd input box of the wxGUI. I have chosen a case
analogous to that where I encountered the error, i.e. a DBF Character field
containing 105 different numeric codes (e.g. 050100) one per record:
(note that you can find full debug output in a text file available at the
following link:
https://docs.google.com/leaf?id=0B0EpsfMZ-IZYOTJiYWVmNjUtNGYzMC00NDM5LWI1NDYtZTMyNzg3M2NjOThksort=namelayout=listnum=50
I thought 20,000+ lines was too much for the mailing list but please advice
if had better taken a different course of action.)
### START GRASS CMD HISTORY ###
g.gisenv set=DEBUG=3
(Thu Jan 28 12:12:34 2010) Command finished (0 sec)
(Thu Jan 28 12:12:43 2010)
v.extract input=census_wake2000 output=census_extract_all_trt2000
where=
[... very long WHERE suppressed...]
(TRT2000='050100')or(TRT2000='050300')or(TRT2000='050400')or(TRT2000='050500')or(TRT2000='050600')or(TRT2000='050700')or(TRT2000='050800')or(TRT2000='050900')or(TRT2000='051000')or(TRT2000='051100')or(TRT2000='051200')or(TRT2000='051400')or(TRT2000='051501')or(TRT2000='051502')or(TRT2000='051600')or(TRT2000='051700')or(TRT2000='051800')or(TRT2000='051900')or(TRT2000='052001')or(TRT2000='052002')or(TRT2000='052101')or(TRT2000='052102')or(TRT2000='052201')or(TRT2000='052202')or(TRT2000='052301')or(TRT2000='052302')or(TRT2000='052401')or(TRT2000='052402')or(TRT2000='052404')or(TRT2000='052405')or(TRT2000='052501')or(TRT2000='052503')or(TRT2000='052504')or(TRT2000='052601')or(TRT2000='052602')or(TRT2000='052603')or(TRT2000='052701')or(TRT2000='052703')or(TRT2000='052704')or(TRT2000='052705')or(TRT2000='052801')or(TRT2000='052802')or(TRT2000='052803')or(TRT2000='052804')or(TRT2000='052805')or(TRT2000='052900')or(TRT2000='053001')or(TRT2000='053002')or(TRT2000='053101')or(TRT2000='053103')or(TRT2000='053104')or(TRT2000='053200')or(TRT2000='053402')or(TRT2000='053403')or(TRT2000='053404')or(TRT2000='053405')or(TRT2000='053406')or(TRT2000='053407')or(TRT2000='053501')or(TRT2000='053505')or(TRT2000='053506')or(TRT2000='053507')or(TRT2000='053508')or(TRT2000='053509')or(TRT2000='053510')or(TRT2000='053512')or(TRT2000='053513')or(TRT2000='053514')or(TRT2000='053515')or(TRT2000='053600')or(TRT2000='053703')or(TRT2000='053706')or(TRT2000='053707')or(TRT2000='053709')or(TRT2000='053710')or(TRT2000='053711')or(TRT2000='053712')or(TRT2000='053713')or(TRT2000='053714')or(TRT2000='053715')or(TRT2000='053716')or(TRT2000='053801')or(TRT2000='053802')or(TRT2000='053900')or(TRT2000='054001')or(TRT2000='054003')or(TRT2000='054004')or(TRT2000='054006')or(TRT2000='054007')or(TRT2000='054008')or(TRT2000='054009')or(TRT2000='054010')or(TRT2000='054102')or(TRT2000='054104')or(TRT2000='054105')or(TRT2000='054106')or(TRT2000='054107')or(TRT2000='054108')or(TRT2000='054109')or(TRT2000='054201')or(TRT2000='054202')or(TRT2000='054301')or(TRT2000='054302')or(TRT2000='054401')or(TRT2000='054402')
D3/3: Mapset = PERMANENT
D1/3: Vect_open_old(): name = census_wake2000 mapset=
PERMANENT update = 0
D1/3: Vect_set_thresh(): thresh = 0.00
[...]
D3/3: db_select_int()
D3/3: SQL: SELECT cat FROM census_wake2000 WHERE (TRT2000=
... first part of very long statement...
'052601')or(TRT2000='052602')or(TRT2000='052603')or(TRT2000=
'052701')or(TRT2000='052703')or(TRT2000='052704')or(TRT2000=
'052705')or(TRT2000='052801')or(TRT2000='052802')or(TRT2000=
'052803')or(TRT2000='052804')or(TRT2000='052805')or(TRT2000=
'052900')or(TRT2000='053001')or(TRT2000='053002')or(TRT2000=
'053101')or(TRT
DBMI-DBF driver error:
SQL parser error: syntax error, unexpected $end processing
This looks suspicious:
lib/dbmi/dbmi_client/select.c
int db_select_int(dbDriver * driver, const char *tab, const char *col,
const char *where, int **pval)
{
int type, more, alloc, count;
int *val;
char buf[1024];
...
/* allocate */
alloc = 1000;
val = (int *)G_malloc(alloc * sizeof(int));
if (where == NULL || strlen(where) == 0)
G_snprintf(buf, 1023, SELECT %s FROM %s, col, tab);
else
G_snprintf(buf, 1023, SELECT %s FROM %s WHERE %s, col, tab, where);
G_debug(3, SQL: %s, buf);
db_init_string(stmt);
db_append_string(stmt, buf);
Re: [GRASS-user] r.mapcalc question
I see, so variables are functions in this case. I've been searching for a while, but I cannot find any tool like grasss r.mapcalc that is a bit more flexible, eg. that can handle recursive tasks. Thanks a lot, Achim Marco Lechner - FOSSGIS e.V. schrieb: Hi Achim, the neighborhood modifier doesn't seem to accept functions (you also could try rand(), ...) Marco Achim Kisseler schrieb: Hello grass-users, I have a problem running a r.mapcalc procedure: given two maps dir_x, dir_y with 0,1,-1 entries I want to run: r.mapcalc the_map=if(isnull(the_map),the_map[dir_x,dir_y],null()) in order to make a r.water.outlet on many many areas at the same time. The error I get is: syntax error, unexpected NAME, expecting INTEGER or '-' why does dir_x/dir_y does not return an integer here? Using int(dir_x) also does not work. Until now I use a r.mapcalc command with many if, checking the direction of every pixel every time. But this is quite slow. Achim ___ 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 mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Max length of sql_query in v.extract
Thanks for your answer, Markus. On 28/01/2010 14:57, Markus Neteler wrote: On Thu, Jan 28, 2010 at 1:34 PM, Luigi Ponti lpo...@infinito.it wrote: On 28/01/2010 00:45, Markus Neteler wrote: On Wed, Jan 27, 2010 at 8:35 PM, Luigi Ponti lpo...@infinito.it wrote: Hello, Is there a length limit to a where sql statement fed to v.extract? I am getting an ... Error in db_open_select_cursor() ... in the middle of a very long query. [...] v.extract input=census_wake2000 output=census_extract_all_trt2000 where= [... very long WHERE suppressed...] (TRT2000='050100')or(TRT2000='050300')or(TRT2000='050400')or(TRT2000='050500')or(TRT2000='050600')or(TRT2000='050700')or(TRT2000='050800')or(TRT2000='050900')or(TRT2000='051000')or(TRT2000='051100')or(TRT2000='051200')or(TRT2000='051400')or(TRT2000='051501')or(TRT2000='051502')or(TRT2000='051600')or(TRT2000='051700')or(TRT2000='051800')or(TRT2000='051900')or(TRT2000='052001')or(TRT2000='052002')or(TRT2000='052101')or(TRT2000='052102')or(TRT2000='052201')or(TRT2000='052202')or(TRT2000='052301')or(TRT2000='052302')or(TRT2000='052401')or(TRT2000='052402')or(TRT2000='052404')or(TRT2000='052405')or(TRT2000='052501')or(TRT2000='052503')or(TRT2000='052504')or(TRT2000='052601')or(TRT2000='052602')or(TRT2000='052603')or(TRT2000='052701')or(TRT2000='052703')or(TRT2000='052704')or(TRT2000='052705')or(TRT2000='052801')or(TRT2000='052802')or(TRT2000='052803')or(TRT2000='052804')or(TRT2000='052805')or(TRT2000='052900')or(TRT2000='053001')or(TRT2000='053002')or(TRT2000='053101')or(TRT2000='053103')or(TRT2000='053104')or(TRT2000='053200')or(TRT2000='053402')or(TRT2000='053403')or(TRT2000='053404')or(TRT2000='053405')or(TRT2000='053406')or(TRT2000='053407')or(TRT2000='053501')or(TRT2000='053505')or(TRT2000='053506')or(TRT2000='053507')or(TRT2000='053508')or(TRT2000='053509')or(TRT2000='053510')or(TRT2000='053512')or(TRT2000='053513')or(TRT2000='053514')or(TRT2000='053515')or(TRT2000='053600')or(TRT2000='053703')or(TRT2000='053706')or(TRT2000='053707')or(TRT2000='053709')or(TRT2000='053710')or(TRT2000='053711')or(TRT2000='053712')or(TRT2000='053713')or(TRT2000='053714')or(TRT2000='053715')or(TRT2000='053716')or(TRT2000='053801')or(TRT2000='053802')or(TRT2000='053900')or(TRT2000='054001')or(TRT2000='054003')or(TRT2000='054004')or(TRT2000='054006')or(TRT2000='054007')or(TRT2000='054008')or(TRT2000='054009')or(TRT2000='054010')or(TRT2000='054102')or(TRT2000='054104')or(TRT2000='054105')or(TRT2000='054106')or(TRT2000='054107')or(TRT2000='054108')or(TRT2000='054109')or(TRT2000='054201')or(TRT2000='054202')or(TRT2000='054301')or(TRT2000='054302')or(TRT2000='054401')or(TRT2000='054402') Yes, that's very long. Would there be a better way of achieving this in GRASS e.g. via *.db.* commands or is v.extract a wrapper for them, and hence they would fail anyway? Kind regards, Luigi [...] I guess that we need to change to dynamic string length allocation here? The cut string is pretty close to the 1023 chars length. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Language of installed manual
Martin: please read on: On Thu, Jan 28, 2010 at 3:27 PM, Luigi Ponti lpo...@infinito.it wrote: Hi all, Not sure why this happens, but some of the manual pages of my WinGRASS-6.4.SVN-r40650-1 installation are in English e.g. v.build.all - Rebuilds topology on all vector maps in the current mapset. while other are in another (not sure which) language e.g. v.buffer - Vytvoøí buffer okolo prvkù zadaného typu (plochy musí obsahovat centroid) Is this a known issue? It is a bugfeature: some want it some not. Ideally both English and the current locale would be used for creating the manual, see enhancement request: https://trac.osgeo.org/grass/ticket/846 Apparently winGRASS-daily was/is build in CZ locale and NLS active. Before compilation, the locale settings should be set to English by defining LANG and LC_MESSAGES variables. IMHO easy to fix on Martin's server. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problems Running r.flow
On Thu, 28 Jan 2010, Glynn Clements wrote: That's a bug in r.flow: if (!((region.ew_res == hd.ew_res) (region.ns_res == hd.ns_res))) G_fatal_error(_(Elevation file's resolution differs from current region resolution)); Try the attached patch. It replaces the exact comparison with a check that the resolutions agree to within 1ppm. Glynn, Perhaps I've specified the region incorrectly, but the patch makes no difference. Upon invoking GRASS I run 'g.region rast=aber5m res=5 -ap' followed by 'r.flow elevin=aber5m aspin=aber5aspect flout=aberFlowline lgout=aberFlowlength' and immediately see: ERROR: Elevation file's resolution differs from current region resolution I'm surprised this issue's not come up before. Thanks, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS scripts manual tab
Thank Glynn But if I just write a script a put it in /Scripts/ I will have to create a HTML page and put it in $GISBASE/docs/html/scriptname.html in order to have a manual right? Regarding Built Scripts using GRASS makefiles, the structure would be something like this? MODULE_TOPDIR = ../.. PGM = SCRIPT NAME include $(MODULE_TOPDIR)/include/Make/Script.make default: script ? Thanks you all On Thu, Jan 28, 2010 at 1:19 PM, Glynn Clements gl...@gclements.plus.comwrote: Franz Schiller wrote: I've been browsing around the Scripts and, for example i.tasscap /i.oif, has a fine and nice manual tab associated with the function (with pictures, text bla bla bla). How can I do this manual pages to be associated with my own scripts? It should appear automatically if there is a manual page at $GISBASE/docs/html/scriptname.html If scripts are built using the GRASS Makefiles, the manual page will be generated by merging the description.html file with the module and option descriptions at the top of the script. -- 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] Set language in Linux
Ok... At /usr/share/i18n/locales/ I have several Files so that might not be the problem. Or is it? (Now I'm a bit lost in this locations vs Translations). Generally, the locale is set on a per-user basis. If you want to set the locale for individual processes, you have to set LANG/LC_* yourself, e.g. providing a script which sets the variables before invoking the application. So I can have a script that, as example, reads third parameter (grass64 -wxpython ES_es) and set the LANGUAGE as Spanish? Thank you On Thu, Jan 28, 2010 at 1:38 PM, Glynn Clements gl...@gclements.plus.comwrote: Gilbert Ferrara wrote: I tryed to add LANG=es_ES LANGUAGE=es_ES to my /usr/local/grass-6.4.0svn/etc/init.sh and I got the following at my terminal window: (process:2196): Gdk-WARNING **: locale not supported by C library (process:2196): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. What it might be? This suggests that you don't have the necessary locale files installed; look in /usr/share/i18n/locales. Some distributions only support UTF-8 locales, in which case you may need to use es_ES.UTF-8. By the way, How can I have 2 language sets I mean 2 different launchers with 2 different languages? Launchers? Generally, the locale is set on a per-user basis. If you want to set the locale for individual processes, you have to set LANG/LC_* yourself, e.g. providing a script which sets the variables before invoking the application. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Ubuntu LTS version of grass 6.4
Hello Anyone know when GRASS 6.4 is likely to be released for Ubuntu 8.04 LTS - as we only use LTS versions of Ubuntu we are still on GRASS 6.2.2 Many thanks Roy -- Roy Sanderson Institute for Research on Environment Sustainability Devonshire Building Newcastle University Newcastle upon Tyne NE1 7RU r.a.sander...@newcastle.ac.uk 0191 246 4835 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Man Page Error: r.sim.water
The command line for r.slope.aspect in the example at the bottom of the page includes ...elev_dx=elev_dx elev_dy=elev_dy. The correct parameter names are dx and dy. Won't run as written. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.mapcalc question
Christian Schwartze wrote: I have a problem running a r.mapcalc procedure: given two maps dir_x, dir_y with 0,1,-1 entries I want to run: r.mapcalc the_map=if(isnull(the_map),the_map[dir_x,dir_y],null()) in order to make a r.water.outlet on many many areas at the same time. The error I get is: syntax error, unexpected NAME, expecting INTEGER or '-' why does dir_x/dir_y does not return an integer here? Using int(dir_x) also does not work. Until now I use a r.mapcalc command with many if, checking the direction of every pixel every time. But this is quite slow. dir_x and dir_y are maps, and as far as I know they can not use in map[x,y] since it expects relative coordinates for the moving window...even though your raster values are in [0,1,-1] To elaborate: the parser only recognises integer literals for the neighbourhood modifier. Apart from that, allowing expressions would require knowing in advance the range of the data, so that it knows how many rows need to be cached. I've been searching for a while, but I cannot find any tool like grasss r.mapcalc that is a bit more flexible, eg. that can handle recursive tasks. For tasks such as this, the alternatives are either to use a general-purpose language such as MatLab/Octave or Python+NumPy/SciPy (which requires reading the entire map into memory), or write a GRASS module in C/C++ (you could use the SWIG bindings to write a complete module in Python, but it would be slow, and the bindings are rather primitive at the moment). The main problem with extending r.mapcalc is that it's a slippery slope; the more features we add, the more features we'll be asked to add and the harder it will be to add such features (as each new feature has to consider interactions with all existing feature). As it stands, r.mapcalc provides just enough glue (or possibly duct tape) to connect other modules together. E.g. by allowing simple pre- and post-processing of the data used or produced by other modules, it saves us from needing to add many relatively simple special-purpose modules as well as adding many features to many existing modules. -- 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] Ubuntu LTS version of grass 6.4
Hi, in the ubuntugis ppa repository you have the 6.5rc5 version for Ubuntu Hardy https://launchpad.net/~ubuntugis/+archive/ubuntugis-unstable?field.series_filter=hardy cheers -- Giovanni -- On Thu, 2010-01-28 at 17:35 +, Roy Sanderson wrote: Hello Anyone know when GRASS 6.4 is likely to be released for Ubuntu 8.04 LTS - as we only use LTS versions of Ubuntu we are still on GRASS 6.2.2 Many thanks Roy ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Ubuntu LTS version of grass 6.4
Giovanni Manghi wrote: Hi, in the ubuntugis ppa repository you have the 6.5rc5 version for Ubuntu Hardy https://launchpad.net/~ubuntugis/+archive/ubuntugis-unstable?field.series_filter=hardy cheers -- Giovanni -- 6.4 was in there at some point, if you really need 6.4 we can probably find and post it in the ubuntugis-stable ppa. Alex ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS scripts manual tab
Hello Franz yes. That's right. If you have a description.html in the same folder as the script, Make will merge Module description with that html file and create the MANUAL tab. And that is the MODULE_TOPDIR Remember you will have to use SUDO and giver permission to run script file as a script (at least I have to do that). Best regards Antonio Thank Glynn But if I just write a script a put it in /Scripts/ I will have to create a HTML page and put it in $GISBASE/docs/html/scriptname.html in order to have a manual right? Regarding Built Scripts using GRASS makefiles, the structure would be something like this? MODULE_TOPDIR = ../.. PGM = SCRIPT NAME include $(MODULE_TOPDIR)/include/Make/Script.make default: script ? Thanks you all __ Information from ESET NOD32 Antivirus, version of virus signature database 4815 (20100128) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problems Running r.flow
Rich Shepard wrote: That's a bug in r.flow: if (!((region.ew_res == hd.ew_res) (region.ns_res == hd.ns_res))) G_fatal_error(_(Elevation file's resolution differs from current region resolution)); Try the attached patch. It replaces the exact comparison with a check that the resolutions agree to within 1ppm. Perhaps I've specified the region incorrectly, but the patch makes no difference. Upon invoking GRASS I run 'g.region rast=aber5m res=5 -ap' followed by 'r.flow elevin=aber5m aspin=aber5aspect flout=aberFlowline lgout=aberFlowlength' and immediately see: ERROR: Elevation file's resolution differs from current region resolution Did you try g.region rast=aber5m without the other options? If that doesn't work, you can try changing the tolerance value to something larger than 1e-6, or simply disabling the test. The test exists to ensure that the data is read cell-for-cell; if any duplicates occurred due to resampling, it would introduce plateaux into the elevation surface. For that purpose, it only matters that the absolute difference between the resolutions is less than ns_res/(2*rows) or ew_res/(2*cols), i.e. a cumulative error of less than 1/2 cell. I'm surprised this issue's not come up before. Same here. It's possible that any rounding error is usually masked by truncation of the value written to the WIND and cellhd files. If it doesn't affect the decimal value written to the file, it won't matter, but if it causes the last decimal digit to change, it will. The files are written using %.15g (i.e. 15 significant figures), while double-precision floating-point has just under 17. There are 11 distinct values which are equal to 5 when written using %.15g, so there's roughly a 9% chance that an error in the least significant bit would affect the decimal representation. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.stream.basins
I am having problems with r.stream basins. I am trying to delineate watersheds above GPSed points. About half of the watersheds are being delineated satisfactorily. The others are very small sub watersheds that are not the correct contributing areas. I imagine that this is because the point is not exactly on the stream? I am using r.watershed to produce the direction map and using a vector layer with points GPSed in the field. Any thoughts would be appreciated. kind regards, -- Stephen Sefick Let's not spend our time and resources thinking about things that are so little or so large that all they really do for us is puff us up and make us feel like gods. We are mammals, and have not exhausted the annoying little problems of being mammals. -K. Mullis ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Flow accumulation and RMMF Soil Erosion Model
Dear GRASS users, I need some help to run flow accumulation couple to the RMMF soil erosion model. Please inform me if somebody has experience or know about it, i really need it for my thesis urgently. Thank you Indeed in advance. Regards, Andry ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problems Running r.flow
On Thu, 28 Jan 2010, Glynn Clements wrote: Did you try g.region rast=aber5m without the other options? Glynn, Not until just now. It's busy calculating maps now. Why does not specifying res or '-ap' make such a difference? Perhaps I can solve future situations like this myself if I better understand what's going on under the hood. Thanks very much, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Interpreting Output: r.flow
I would appreciate someone pointing me to a resource I can read to learn how to interpret the flow line and flow length maps output by r.flow. A number of these modules look very useful but I don't know how to interpret the resulting maps. There's limited insights for some modules in my copy of the GRASS book, 2nd Ed. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.param.scale Incorrect Output
On Thursday 28 January 2010, Rich Shepard wrote: On Thu, 28 Jan 2010, Rich Shepard wrote: I'm stymied trying to get output from r.param.scale that is equivalent to the example on the bottom of the man page. Resetting g.region to the input elevation map without any additional options and adding a zmult factor of 5 appears to help. When the specified param is 'features' I see what should be ridges and channels, but no peaks or pits. Changing the calculated param to either elev or profc yields blank maps when I try to display them with d.rast. Suggestions on how to properly apply this module will be very helpful. Rich ___ Hi, Are you working with data in a projected coordinate system? Are you x,y and z coordinates all in the same units. What is the general nature of the terrain you are looking at? Try adjusting the window size to get generalized features-- remember that the quantification of terrain is a fractal problem. Cheers, Dylan -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Set language in Linux
Gilbert Ferrara wrote: At /usr/share/i18n/locales/ I have several Files so that might not be the problem. Or is it? (Now I'm a bit lost in this locations vs Translations). There's more to it than that. Typically, the files in /usr/share/i18n/locales are source files, which are compiled with localedef to generate /usr/lib/locale/locale-archive. You can use localedef --list-archive to list which locales are defined in the archive. That defines everything *except* for translations: text encoding, numeric format, date format, monetary format, collation rules, etc. Translations are handled separately, as each application has its own messages catalogues. But even if an application has a message catalogue for a particular locale, it won't be used if the base locale isn't defined. -- 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] Compiling r.example in LINUX- Still one error
António Rocha wrote:
Regarding this issue.
Although it's compiling r.example I'm getting the following error:
ERROR: G_getenv(): Variable LOCATION_NAME not set
What does this mean? I need to have a demolocation folder in my
GRASSsvn6.4.0 folder?
The default rule for a module attempts to build the HTML
documentation, which involves running the program with the
--html-description flag to obtain the module/option/flag descriptions.
Running the module requires that GISRC is set and refers to a file
containing settings for at least GISDBASE, LOCATION_NAME and MAPSET. I
don't recall whether those values need to be valid, or just exist.
The rule sets GISRC from RUN_GISRC, which is defined as:
RUN_GISRC =
${ARCH_DISTDIR}/demolocation/.grassrc${GRASS_VERSION_MAJOR}${GRASS_VERSION_MINOR}
You can either copy the demolocation directory from the source tree,
or just change the value of RUN_GISRC to point to a suitable file.
--
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] GRASS scripts manual tab
António Rocha wrote: yes. That's right. If you have a description.html in the same folder as the script, Make will merge Module description with that html file and create the MANUAL tab. And that is the MODULE_TOPDIR Remember you will have to use SUDO and giver permission to run script file as a script (at least I have to do that). That shouldn't be necessary. The script just needs execute permission, which can be set by the script's owner. On a single-user system, there isn't any particular need to even install GRASS. You can either just run bin.arch/grass64 directly, or manually install it into e.g. /usr/local/bin if you want to avoid having to type the full path. The latest installed copy of GRASS on my machine is dated Jun 13 2009. That was probably only done to check that make install still worked. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] importing rasters
Hi everybody, I am trying to import a raster file that is in a location SRTM, into another location LatLong-WGS84 using r.in.gdal I am inside the LatLong-WGS84 location, and once i imported the file i press the button to get the raster file added in the manager. It seems everything all right, the projections match, but when i try to add the raster file, there's anything in the box, that displays only the PERMANENT directory, empty. Many thanks ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.param.scale Incorrect Output
Rich wrote: I'm stymied trying to get output from r.param.scale that is equivalent to the example on the bottom of the man page. even using the Speafish dataset? Resetting g.region to the input elevation map without any additional options and adding a zmult factor of 5 appears to help. It may be (just guessing here) that the module assumes that the x,y and z values are all using the same units (eg all meters or all feet). in that case a zmult of 3.28 would get you pretty close. how reliefy your area is probably makes a bit of a difference as well. When the specified param is 'features' I see what should be ridges and channels, but no peaks or pits. should it have them? (ok, Oregon is for the most part a fairly hilly pace, it probably should). but if you were looking at a floodplain it might not. see feature.c and param.c in the source for the formulas used. maybe it is artificially flat: if it isn't already try using the zscale= option or r.mapcalc to make z match x y scale units. Changing the calculated param to either elev or profc yields blank maps when I try to display them with d.rast. sometimes the colors can be misleading. check with r.univar and if needed rerun 'r.colors -e' to be sure. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Interpreting Output: r.flow
Rich: I would appreciate someone pointing me to a resource I can read to learn how to interpret the flow line and flow length maps output by r.flow. A number of these modules look very useful but I don't know how to interpret the resulting maps. There's limited insights for some modules in my copy of the GRASS book, 2nd Ed. sometime the GRASS 5 manual pages can have a lot of useful info in them too. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Interpreting Output: r.flow
On Thu, 28 Jan 2010, Hamish wrote: sometime the GRASS 5 manual pages can have a lot of useful info in them too. Hamish, More than the 6.4 manual pages? I'll look. Thanks, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problems Running r.flow
Glynn wrote:
Try the attached patch. It replaces the exact comparison
with a check that the resolutions agree to within 1ppm.
...
+static int compare_regions(const struct Cell_head *a, const struct Cell_head
*b)
+{
+return (fabs(a-ew_res - b-ew_res) 1e-6 * b-ew_res
+fabs(a-ns_res - b-ns_res) 1e-6 * b-ns_res);
+}
use GRASS_EPSILON, as it is based on the machine; it doesn't make
assumptions about the units you are measuring in. (or for that matter
that your x and y axes represent distance at all, in the way we usually
think about it)
e.g. for Lat/Long 1e-6 is not enough to accurately represent the
region resolution well for sub-meter data. (1e-6*1852*60 = ~ 11cm)
this may not have come up before because the improved reading/writing
at full %.15g is rather new*, and the old read-write cycle may have,
as your post suggested, quietly rounded all the problems away.
[*] see task #335, https://trac.osgeo.org/grass/ticket/335
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problems Running r.flow
Glynn wrote:
Try the attached patch. It replaces the exact comparison
with a check that the resolutions agree to within 1ppm.
...
+static int compare_regions(const struct Cell_head *a,
const struct Cell_head *b)
+{
+return (fabs(a-ew_res - b-ew_res) 1e-6 * b-ew_res
+fabs(a-ns_res - b-ns_res) 1e-6 * b-ns_res);
+}
Hamish:
use GRASS_EPSILON, as it is based on the machine; it
doesn't make assumptions about the units you are measuring in.
...
e.g. for Lat/Long 1e-6 is not enough to accurately
represent the
region resolution well for sub-meter data. (1e-6*1852*60
= ~ 11cm)
sorry reading again you did say ppm not micron and the code is 1e-6*res,
not simply 1e-6.
a plausible finest resolution of 1e-9 for lat/lon (~.1mm) * 1e-6 = 1e-15
(which is identical GRASS_EPSILON).
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.stream.basins
stephen sefick pisze: Thanks for the response - I moved the values to the closest synthetic stream, and it worked without a hitch. Thank you again for your time. kindest regards, Stephen On Thu, Jan 28, 2010 at 6:37 PM, MS msei...@gmail.com wrote: The points need to coincide with a nearby high value accumulation cell. r.astream.basins allow to make a 'trick' for such situation: create buffer around GPS points, rasterise it and next use it raster as stream map. Note that every point shall have its own category J. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
