Re: [GRASS-user] Error while starting GRASS6.4
Luis Lisboa wrote:
Good Evening
I have just installed GRASS 6.4 in a Linux and I got this error while
trying to start GRASS with WXPYTHON.
/usr/lib64/python2.4/site-packages/wx-2.8-gtk2-unicode/wx/_core.py:14448:
UserWarning: wxPython/wxWidgets release number mismatch
warnings.warn("wxPython/wxWidgets release number mismatch")
Could anyone telm what this means? Is this a normal error?
Hmm, this is a warning, not an error. I got grass with wxGUI fully up
and running on a system giving me this warning (Fedora 12 64bit). OK, I
had to replace swig with a working version in order to get both wxnviz
and wxdigitizer working, but the wxPython/wxWidgets release number
mismatch warning itself had no effect on the functionality of the grass
wxgui. With the standard swig version, the wxdigitizer was not working,
but wxnviz and the wxgui worked.
Just keep going with the wxgui, it might work.
Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: CYGWIN
Luigi Ponti wrote: > > There is no grass.py. It existed for a brief time, but the "grass" > > module was replaced with a "grass" package containing multiple > > modules, then later split into two subpackages, "script" and "lib". > > > The package is described in the programming manual -- I should have > explored better: > http://download.osgeo.org/grass/grass6_progman/pythonlib.html > > The progman page above says that the code is in lib/python/ while in my > osgeo4w GRASS 6.4.0svn r36506 > http://trac.osgeo.org/osgeo4w/wiki/pkg-grass > > the code seems to reside into etc/python. The code is in lib/python in the source tree; it gets installed into $GISBASE/etc/python. The startup scripts add $GISBASE/etc/python to PYTHONPATH, so "import grass.script" etc should work for any Python script run from within a GRASS session. > > The change was made to accomodate the SWIG bindings for the GRASS > > libraries in the "grass.lib" package, so the scripting functions were > > moved from "grass" to "grass.script". > > Would the lib subpackage you mentioned be any useful in developing GRASS > scripts? (I could not find it in my osgeo4w installation.) The grass.lib package contains bindings for the functions in the main GRASS libraries. The bindings are generated automatically from the header files using SWIG; not all of them are usable. grass.lib allows you to call GRASS library functions from Python, while grass.script is designed for running GRASS commands. Programming at the library level is harder, almost completely untested, and more likely to change from one version to the next. Also, Python isn't exactly a fast language; processing maps in Python will typically be much slower than in C (and probably not significantly simpler, as the Python bindings are just bindings; you still have to e.g. allocate and free buffers explicitly). -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] i.ortho.photo
Franz Schiller wrote: > A few weeks ago I sent an email to users mailing list asking about > i.ortho.photo and why it isn't available at WinGRASS and if it was available > at GRASS in LINUX OS. > Unfortunely when I run I got this error: > > Exception in thread Thread-19 > Traceback (most recent call last): > File "/usr/lib64/python2.4/threading.py", linhe 442, in > __bootstrap > sel.run() > File "usr/local/grass6.4.0RC5/etc/wxpython/gui_modules/g > cmd.py" line 530, in run > stderr=subprocess.PIPE) > File "/usr/lib64/python2.4/subprocess.py", line 550, in > __init__ > erread,errwrite) > File "/usr/lib64/python2.4/subprocess.py", line 993, in > _execute_child > raise child_exception > TypeError: execv() arg 2 must contain only strings > Traceback (most recent call last): > File "/usr/local/grass-6.4.0RC5/etc/wxpython/wxgui.py", > line 1035, in OnXTerm > > p=gcmd.Command(cmdlist) > File "/usr/local/grass-6.4.0RC5/etc/wxpython/gui_modules g > cmd.py", line 347, in __init__ > > Debug.msg (3, "Command(): cmd='%s', wait=%s, returncode=%d, > alive=%s" % \ > TypeError > : > sequence item 2: expected string, list found > > > Question: Is this function available at GRASS 6.4 without problems or it > might be some problem from my installation? I think that this is a bug in the wxGUI. See: https://trac.osgeo.org/grass/ticket/693#comment:11 Note to grass-dev (or anyone else who's interested): I'd be interested in an answer to this part: > Does GMFrame.OnXTerm() work at all for anything on any platform? The above error is almost exactly what I would expect from GMFrame.OnXTerm() in all cases. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Error while starting GRASS6.4
Luis Lisboa wrote:
> I have just installed GRASS 6.4 in a Linux and I got this error while trying
> to start GRASS with WXPYTHON.
>
> /usr/lib64/python2.4/site-packages/wx-2.8-gtk2-unicode/wx/_core.py:14448:
> UserWarning: wxPython/wxWidgets release number mismatch
> warnings.warn("wxPython/wxWidgets release number mismatch")
>
> Could anyone telm what this means? Is this a normal error?
I would interpret the error as indicating that wxPython ends up
loading a version of wxWidgets other than the one for which it was
built.
Either the wxPython installation is broken, or you have another
version of wxWidgets on the system which is taking precedence.
--
Glynn Clements
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Compiling GRASS 6.4.0RC5 on AIX 5.3
Mike Waldron wrote: > The source code tweaks I had to make were mainly to resolve conflicts > with variable declarations in the math.h include file. These didn't > cause a problem on Linux, but the xlc compiler on AIX would choke on > these. Also, there were several include references to , > which on AIX is located in , so again a peculiarity with AIX. FWIW, POSIX specifies . Linux has both, but is just: #include In 7.0, the only two source files which use are r.drain/main.c and r.fill.dir/main.c; all others use . I've fixed this in 7.0 with r40022. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: CYGWIN
On 14/12/2009 18:17, Glynn Clements wrote: Luigi Ponti wrote: But when I do /db.test test1/ errors arise: [...] My guess is that this is a problem with Cygwin and Windows 7. I have eventually reverted back to GRASS 6.3.0 for now, after fixing some missing dll's. I am not sure what is wrong with 6.4 vs 6.3 but I need a functional GRASS/Cygwin version to run some bash scripts while I port them to Phython. I wouldn't consider the supplied db.test test case failing to equate to "non-functional"; it's the test case which is wrong, not db.select. You are right: I used the wrong words -- thanks for the explanation. I will keep trying to get 6.4.0-RC5 compiled on Cygwin/Windows 7. Thanks again for sharing your configure options. [...] If you care about the exact format of floating-point values output from db.select, note that future versions will behave like 6.4.0-RC5, not like 6.3.x. Good to know, thanks. Also, is it even possible to do Python scripting in the native Windows GRASS 6.4.x? Yes. For example, I noticed that some of the GRASS scripts that have been translated to Python require a grass.py package, which I don't see in my osgeo4w installation. There is no grass.py. It existed for a brief time, but the "grass" module was replaced with a "grass" package containing multiple modules, then later split into two subpackages, "script" and "lib". The package is described in the programming manual -- I should have explored better: http://download.osgeo.org/grass/grass6_progman/pythonlib.html The progman page above says that the code is in lib/python/ while in my osgeo4w GRASS 6.4.0svn r36506 http://trac.osgeo.org/osgeo4w/wiki/pkg-grass the code seems to reside into etc/python. The change was made to accomodate the SWIG bindings for the GRASS libraries in the "grass.lib" package, so the scripting functions were moved from "grass" to "grass.script". Would the lib subpackage you mentioned be any useful in developing GRASS scripts? (I could not find it in my osgeo4w installation.) Thanks and regards, Luigi Some early scripts use "import grass", but for current versions (including 6.4.0-RC5), you need e.g. "import grass.script as grass". ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: grass-user Digest, Vol 44, Issue 47
On Dec 15, 2009, at 11:21 AM, grass-user-requ...@lists.osgeo.org wrote:
Date: Tue, 15 Dec 2009 18:20:56 +
From: Gilbert Ferrara
Subject: [GRASS-user] NVIZ on wxpython 6.4
To: grass-user@lists.osgeo.org
Message-ID:
Content-Type: text/plain; charset="iso-8859-1"
Greetings you all
I'm new at this mailing list and I have a question related with NVIZ
module.
I saw in previous messages that NVIZ is available at WinGRASS using
TclTK.
But at LINUX it also requires tcltk, right?
Ok I used the command: nviz elevation vect=roadsmajor
points=firestations
This should be: nviz elevation=rastermap vect=roadsmajor
points=firestations
elevation is an argument. You need a raster map as in elevation=mymap
Michael
and I get NVIZ window totally jammed. And when I unselected
"surface" I got
this error window:
Bad window path name ".help_shell"
bad window path name ".help_shell"
while executing
"winfo reqwidth $_top"
(procedure "DynamicHelp::_show_help" line 22)
invoked from within
"DynamicHelp::_show_help .middle.panelarea.panels.main.midt.b2 317
323"
("after" script)
Question: Does any one LINUX User, has the same problem? Or knows
how to fix
this?
Thanks
Gilbert
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] i.ortho.photo
i.ortho.photo requires an xterm using XWindows. Windows doesn't have XWindows or xterms. This will not work on Windows until it is rewritten so as not to require an xterm. There are a handful of other older GRASS modules that require an xterm (e.g., i.class, r.digit). Michael On Dec 15, 2009, at 11:21 AM, grass-user-requ...@lists.osgeo.org wrote: Date: Tue, 15 Dec 2009 17:51:08 + From: Franz Schiller Subject: [GRASS-user] i.ortho.photo To: grass-user@lists.osgeo.org Message-ID: Content-Type: text/plain; charset="iso-8859-1" Greetings A few weeks ago I sent an email to users mailing list asking about i.ortho.photo and why it isn't available at WinGRASS and if it was available at GRASS in LINUX OS. Unfortunely when I run I got this error: Exception in thread Thread-19 Traceback (most recent call last): File "/usr/lib64/python2.4/threading.py", linhe 442, in __bootstrap sel.run() File "usr/local/grass6.4.0RC5/etc/wxpython/gui_modules/g cmd.py" line 530, in run stderr=subprocess.PIPE) File "/usr/lib64/python2.4/subprocess.py", line 550, in __init__ erread,errwrite) File "/usr/lib64/python2.4/subprocess.py", line 993, in _execute_child raise child_exception TypeError: execv() arg 2 must contain only strings Traceback (most recent call last): File "/usr/local/grass-6.4.0RC5/etc/wxpython/wxgui.py", line 1035, in OnXTerm p=gcmd.Command(cmdlist) File "/usr/local/grass-6.4.0RC5/etc/wxpython/gui_modules g cmd.py", line 347, in __init__ Debug.msg (3, "Command(): cmd='%s', wait=%s, returncode=%d, alive=%s" % \ TypeError : sequence item 2: expected string, list found Question: Is this function available at GRASS 6.4 without problems or it might be some problem from my installation? Thanks Franz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: GRASS-user] Error while starting GRASS6.4
You have the wrong version of wxpython to go with your version of
python I think.
You might need to upgrade to Python 2.5 and get a wxpython version to
match.
Michael
On Dec 15, 2009, at 11:21 AM, grass-user-requ...@lists.osgeo.org wrote:
Date: Tue, 15 Dec 2009 17:29:30 +
From: Luis Lisboa
Subject: [GRASS-user] Error while starting GRASS6.4
To: grass-user@lists.osgeo.org
Message-ID:
Content-Type: text/plain; charset="iso-8859-1"
Good Evening
I have just installed GRASS 6.4 in a Linux and I got this error
while trying
to start GRASS with WXPYTHON.
/usr/lib64/python2.4/site-packages/wx-2.8-gtk2-unicode/wx/_core.py:
14448:
UserWarning: wxPython/wxWidgets release number mismatch
warnings.warn("wxPython/wxWidgets release number mismatch")
Could anyone telm what this means? Is this a normal error?
Thanks
Cheers,
Luis
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] NVIZ on wxpython 6.4
Greetings you all
I'm new at this mailing list and I have a question related with NVIZ module.
I saw in previous messages that NVIZ is available at WinGRASS using TclTK.
But at LINUX it also requires tcltk, right?
Ok I used the command: nviz elevation vect=roadsmajor points=firestations
and I get NVIZ window totally jammed. And when I unselected "surface" I got
this error window:
Bad window path name ".help_shell"
bad window path name ".help_shell"
while executing
"winfo reqwidth $_top"
(procedure "DynamicHelp::_show_help" line 22)
invoked from within
"DynamicHelp::_show_help .middle.panelarea.panels.main.midt.b2 317 323"
("after" script)
Question: Does any one LINUX User, has the same problem? Or knows how to fix
this?
Thanks
Gilbert
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Questions related with wxpython modules in Windows
Hello Martin and everyone I've just installed GRASS 6.4 on a LINUX machine, because I wanted to test Vector digitzer from in wxpython, and I get this warning at console: WARNING: Vector digitizer is not available (No module named grass6_wxvdigit). According to your previous message it should be working but neither digitizer option (in map display) and "Start editing" button (from layer manager) on selected vector map is working. Although, v.digit, from tcltk is still working Question: Am I the only one that can operate Vector_Digitizing_Tool in wxpython? * * *Thanks* * * *Best regards* * * *Franz* On Thu, Dec 3, 2009 at 10:31 AM, Martin Landa wrote: > Hi, > > 2009/12/3 Franz Schiller : > > [...] > > > Are these options "blocked" only in Windows or also in Linux? > > Thanks for your help > > No, wxGUI vector digitizer should work on Linux and Mac OS X. > > Martin > > PS: Please keep discussion on ML. > > -- > Martin Landa * http://gama.fsv.cvut.cz/~landa > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] i.ortho.photo
Greetings A few weeks ago I sent an email to users mailing list asking about i.ortho.photo and why it isn't available at WinGRASS and if it was available at GRASS in LINUX OS. Unfortunely when I run I got this error: Exception in thread Thread-19 Traceback (most recent call last): File "/usr/lib64/python2.4/threading.py", linhe 442, in __bootstrap sel.run() File "usr/local/grass6.4.0RC5/etc/wxpython/gui_modules/g cmd.py" line 530, in run stderr=subprocess.PIPE) File "/usr/lib64/python2.4/subprocess.py", line 550, in __init__ erread,errwrite) File "/usr/lib64/python2.4/subprocess.py", line 993, in _execute_child raise child_exception TypeError: execv() arg 2 must contain only strings Traceback (most recent call last): File "/usr/local/grass-6.4.0RC5/etc/wxpython/wxgui.py", line 1035, in OnXTerm p=gcmd.Command(cmdlist) File "/usr/local/grass-6.4.0RC5/etc/wxpython/gui_modules g cmd.py", line 347, in __init__ Debug.msg (3, "Command(): cmd='%s', wait=%s, returncode=%d, alive=%s" % \ TypeError : sequence item 2: expected string, list found Question: Is this function available at GRASS 6.4 without problems or it might be some problem from my installation? Thanks Franz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: v.breach addon
Yes, it worked with sqlite db connection. Luís On Mon, 2009-12-14 at 15:52 -0500, M S wrote: > Luis: > > I noticed you mentioned you had run it with sqlite and dbf database > drivers. Mine is mapped to sqlite currently. I see some v.to.db > commands in the script, but do I understand correctly that you didnt > have issues using sqlite as backend? ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Error while starting GRASS6.4
Good Evening
I have just installed GRASS 6.4 in a Linux and I got this error while trying
to start GRASS with WXPYTHON.
/usr/lib64/python2.4/site-packages/wx-2.8-gtk2-unicode/wx/_core.py:14448:
UserWarning: wxPython/wxWidgets release number mismatch
warnings.warn("wxPython/wxWidgets release number mismatch")
Could anyone telm what this means? Is this a normal error?
Thanks
Cheers,
Luis
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: v.breach addon
M S pisze: Kubuntu 9.10 64bit, using GRASS 6.5. I ran v.breach on a stream network extracted with r.stream.extract. It runs through the program, and puts up an error dialogue at v.parallel. Attached is the log file. It looks like a negative number is being passed to v.parallel. I saw in the documentation this might be a problematic module in the script for non-metric coordinate system. Below is the portion of the output box from the module. Note the error 11 lines down. --- Building topology for vector map ... Registering primitives... 100 primitives registered 259 vertices registered Building areas... 0 areas built 0 isles built Attaching islands... Attaching centroids... Number of nodes: 100 ERROR: value <-0.1> out of range for parameter Number of primitives: 100 Number of points: 0 Number of lines: 100 Number of boundaries: 0 Number of centroids: 0 Legal range: 0-1 Description: Creates parallel line to input vector lines. Keywords: vector, geometry --- Should I look in the script for this portion, and check if it is a metric issue? or does this seem like a different problem? A different one. v.parallel used to accept negative offsets to distinguish left/right. Now (after v.parallel2 replaced it) it doesn't accept negative offsets anymore. Maciek 2009/12/14 Maciej Sieczka : Luís Ferreira pisze: I used v.breach with both SQLite and dbf, with ETRS89 metric negative coordinates, from 20m to 2m resolution and worked fine. System: Ubuntu 9.10 Karmic Koala, 64 bits, GRASS 6.4SVN. But I remember to see some warnings like yours. Are these warnings critical? Visually, the interpolated DEMs with v.surf.rst are coherent. I'll let you know next time I take a hobbyist look at v.breach. But I really don't know when it will be. Good luck. Maciek On Mon, 2009-12-14 at 04:57 +0100, Maciej Sieczka wrote: @Luís: I applied most your of patch. Thanks! Are you sure that's all errors? I keep on getting warnings like: WARNING: Unable to get point on line: cat = 1 offset = 2.831711 (line length = 0) at v.segment calls in the script, and a crash at v.in.ascii. -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Compiling GRASS 6.4.0RC5 on AIX 5.3
Since the configure script is assuming that the ldAix script is in $SRCDIR, it should probably be included with the source, or a flag should be added to point to where it is. It's apparently needed to create the lib.exp file when building shared libraries, although I ended up building static libraries to get the compile to succeed. This script comes from the TclTk package, specifically /usr/local/lib/tcl8.4 in my case. The source code tweaks I had to make were mainly to resolve conflicts with variable declarations in the math.h include file. These didn't cause a problem on Linux, but the xlc compiler on AIX would choke on these. Also, there were several include references to , which on AIX is located in , so again a peculiarity with AIX. Mike Glynn Clements wrote: Mike Waldron wrote: Yes, I copied the ldAix script from the Tcl/Tk package. After attempting all the suggestions, I finally used --disable-shared on the configure command, and all but a handful of modules successfully compiled. I was able to individually address the ones that failed through Makefile edits and several small source code/header file edits. Is there anything which ought to be changed in GRASS itself? ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] g.region (was v.to.rast conversion)
Giacomo Piva wrote: > Hamish wrote: > I followed the instructions in the chapter "Automated usage of grass" in > the Markus's book and I created a bash script in order to prepare the > grass enviroment: > > #!/bin/bash > LOCATION=test > > GISBASE=/usr/local/grass-6.5.svn > GISDBASE=/usr/local/share/grassdata > > rm $HOME/.grassrc6 > rm -rf "$GISDBASE/$LOCATION" #cleaning LOCATION > > TMPDIR=$$.tmp > mkdir -p $GISDBASE/$TMPDIR/temp > > echo "LOCATION_NAME: $TMPDIR" > $HOME/.grassrc6 > echo "MAPSET: temp" >> $HOME/.grassrc6 > echo "DIGITIZER: none" >> $HOME/.grassrc6 > echo "GISDBASE: $GISDBASE" >> $HOME/.grassrc6 > > export GISBASE=$GISBASE > export GISRC=$HOME/.grassrc6 > export PATH=$PATH:$GISBASE/bin:$GISBASE/scripts > > After these lines I run the v.in.ogr module to import the vector: > v.in.ogr -o -e dsn=./test_data/test_data.shp output=grass_map > > And the following is the error i get. > ERROR: region for current mapset is not set > run "g.region" > > I tried to get the g.region help message, also I tried to reset the > region (with g.region -d) and to set a default region (with g.region -s) > but I get always the same error. You have to create a valid location and mapset. It isn't enough that the directories exist; they have to contain certain files. At an absolute minimum, you need the $GISDBASE/$LOCATION_NAME/$MAPSET/WIND file. You may also need the $GISDBASE/$LOCATION_NAME/PERMANENT directory and some or all of the files: $GISDBASE/$LOCATION_NAME/PERMANENT/DEFAULT_WIND $GISDBASE/$LOCATION_NAME/PERMANENT/MYNAME $GISDBASE/$LOCATION_NAME/PERMANENT/PROJ_INFO $GISDBASE/$LOCATION_NAME/PERMANENT/PROJ_UNITS $GISDBASE/$LOCATION_NAME/$MAPSET/VAR If your automated sessions all use the same projection, you can use an existing location, and only generate a new mapset for each automated session. Then you only need to create the mapset directory and the WIND file (which can be copied from ../PERMANENT/DEFAULT_WIND). Alternatively, you can create a "skeleton" database, and make a copy of that for each session. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] g.region (was v.to.rast conversion)
Hi, Giacomo Piva wrote: Giacomo Piva wrote: [...] I should convert a shapefile into a raster file (GeoTIFF format) at a given resolution and I want to use the GRASS modules as a command line tools. I followed the instructions in the chapter "Automated usage of grass" in the Markus's book and I created a bash script in order to prepare the grass enviroment: #!/bin/bash LOCATION=test GISBASE=/usr/local/grass-6.5.svn GISDBASE=/usr/local/share/grassdata rm $HOME/.grassrc6 rm -rf "$GISDBASE/$LOCATION" #cleaning LOCATION TMPDIR=$$.tmp mkdir -p $GISDBASE/$TMPDIR/temp echo "LOCATION_NAME: $TMPDIR" > $HOME/.grassrc6 echo "MAPSET: temp" >> $HOME/.grassrc6 echo "DIGITIZER: none" >> $HOME/.grassrc6 echo "GISDBASE: $GISDBASE" >> $HOME/.grassrc6 export GISBASE=$GISBASE export GISRC=$HOME/.grassrc6 export PATH=$PATH:$GISBASE/bin:$GISBASE/scripts After these lines I run the v.in.ogr module to import the vector: v.in.ogr -o -e dsn=./test_data/test_data.shp output=grass_map According to the grass book, the v.in.ogr command should include the location option: v.in.ogr -o -e dsn=./test_data/test_data.shp output=grass_map location=$LOCATION then go to the newly created location (set the environment variables accordingly and update .grassrc6), set the region extends and resolution to your demands, run v.to.rast, then r.out.gdal. IMHO, it is easier to use the GUI. Hope that helps, Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] V.overlay very slow
Thanx again Markus, you always saving me :D patch followed by v.clean with break,rmdupl and later v.build make it really fast! Markus Metz-2 wrote: > > If you just want to create one big vector with all features present in > several other vectors, try v.patch followed by v.clean. > > For cleaning after patching areas, you will need at least to break > polygons and remove duplicates. If topology is still not correct, try > cleaning small angles at nodes followed by breaking lines, then remove > duplicates. If topology is still not correct, snapping vertices may be > necessary, here try a very small threshold first. Also see the v.patch > manual. > > Hope that helps, > > Markus > > > incanus wrote: >> Hi all, >> I'm trying to join a large set of "vectorial tiles" that i have, into a >> unique vectorial map. What i'm doing is something like this, for each >> "tile" >> (in the example is called filaN): >> >> v.overlay ainput=sumaFilas atype=area alayer=1 binput=fila6 btype=area >> blayer=1 output=sumaFilas2 operator=or olayer=1,0,0 >> v.db.addcol map=sumaFilas2 layer=1 'columns=union INTEGER' >> v.db.update map=sumaFilas2 layer=1 column=union value=1 >> v.dissolve input=sumaFilas2 output=sumaFilas2 layer=1 column=union >> --overwrite >> g.remove vect=sumaFilas >> g.rename vect=sumaFilas2,sumaFilas >> >> At first, the v.overlay is instant, but when processing the map number >> 100, >> it can be several hours. >> >> Anyone knows an alternate way to do this? >> The first solution I adopted was making this by rows of 100 "tiles", and >> then joining the rows (what i'm doing in the example above). It worked >> for >> me since i only has todo a "small" map (1 week of processing), but now i >> need to do one MUCH more big. >> >> Thanx in advance if anyone knows something.. or not :) >> Andres >> > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > > -- View this message in context: http://n2.nabble.com/V-overlay-very-slow-tp4169783p4170405.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: grass-user Digest, Vol 44, Issue 45
If you are using a current version of GRASS (and current version of gdal if you are on Linux or Mac), run the location wizard to create a new location and mapset in the same projection as your problematic one (I'm assuming that you are not in an xy location). You get to the location wizard from the "create location" button on the startup screen. Select the new location and mapset and start GRASS. Try 'display region' from the configure menu or type g.region -p from the command line. Do you have any different results? Michael On Dec 15, 2009, at 7:56 AM, grass-user-requ...@lists.osgeo.org wrote: Date: Tue, 15 Dec 2009 08:46:44 +0100 From: Giacomo Piva Subject: Re: [GRASS-user] g.region (was v.to.rast conversion) To: grass-user@lists.osgeo.org Message-ID: <4b273ee4.5070...@meeo.it> Content-Type: text/plain; charset=UTF-8; format=flowed Giacomo Piva wrote: Hamish wrote: Giacomo Piva: First of all, thanks for your reply. To clarify my problem, i want to specify that the main problem is that all command that involves the g.region always returns the reported error (ERROR: default region is not set.) also the "help". I found a similar discussion here: http://lists.osgeo.org/pipermail/grass-user/2009-November/052988.html Where the solution was to use of the SVN version of the grass. I already tried to use that version, bunt nothing changed. Any me any suggestions? maybe the rc5 bug is now gone, but the corrupted WIND file still remains in your mapset. try 'g.region -d' to reset it. does it work from a newly created mapset? Hamish Hi Hamish, Maybe it could be usefull to do a backward step. I should convert a shapefile into a raster file (GeoTIFF format) at a given resolution and I want to use the GRASS modules as a command line tools. I followed the instructions in the chapter "Automated usage of grass" in the Markus's book and I created a bash script in order to prepare the grass enviroment: #!/bin/bash LOCATION=test GISBASE=/usr/local/grass-6.5.svn GISDBASE=/usr/local/share/grassdata rm $HOME/.grassrc6 rm -rf "$GISDBASE/$LOCATION" #cleaning LOCATION TMPDIR=$$.tmp mkdir -p $GISDBASE/$TMPDIR/temp echo "LOCATION_NAME: $TMPDIR" > $HOME/.grassrc6 echo "MAPSET: temp" >> $HOME/.grassrc6 echo "DIGITIZER: none" >> $HOME/.grassrc6 echo "GISDBASE: $GISDBASE" >> $HOME/.grassrc6 export GISBASE=$GISBASE export GISRC=$HOME/.grassrc6 export PATH=$PATH:$GISBASE/bin:$GISBASE/scripts After these lines I run the v.in.ogr module to import the vector: v.in.ogr -o -e dsn=./test_data/test_data.shp output=grass_map And the following is the error i get. ERROR: region for current mapset is not set run "g.region" I tried to get the g.region help message, also I tried to reset the region (with g.region -d) and to set a default region (with g.region -s) but I get always the same error. I'm very new with GRASS and I cannot understand if there is a problem in the installation, or it is a bug (as it seemed), or I'm not working in the proper way. Thanks (also for the patience) No suggestions? ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Error while onitializing GRASS6.4 with wxpython
Greetings all I have installed and compiled GRASS6.4 in an Linux server. It's working OK in text mode and it opens the menu with tcltk. But when I run grass64 -wxpython I get this errors: Traceback (most recent call last): File "/usr/local/grass-6.4.0RC5/etc/wxpython/gis_set.py", line 33, in ? from gui_modules import globalvar File "/usr/local/grass-6.4.0RC5/etc/wxpython/gui_modules/globalvar.py", line 55, in ? CheckForWx() File "/usr/local/grass-6.4.0RC5/etc/wxpython/gui_modules/globalvar.py", line 44, in CheckForWx except (ImportError, ValueError, wxversion.VersionError), e: UnboundLocalError: local variable 'wxversion' referenced before assignment Error in GUI startup. If necessary, please report this error to the GRASS developers. Switching to text mode now. Do anyone has a clue of what is not right with WXPYTHON GUI startup? Thanks Best Regards Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] V.overlay very slow
If you just want to create one big vector with all features present in several other vectors, try v.patch followed by v.clean. For cleaning after patching areas, you will need at least to break polygons and remove duplicates. If topology is still not correct, try cleaning small angles at nodes followed by breaking lines, then remove duplicates. If topology is still not correct, snapping vertices may be necessary, here try a very small threshold first. Also see the v.patch manual. Hope that helps, Markus incanus wrote: Hi all, I'm trying to join a large set of "vectorial tiles" that i have, into a unique vectorial map. What i'm doing is something like this, for each "tile" (in the example is called filaN): v.overlay ainput=sumaFilas atype=area alayer=1 binput=fila6 btype=area blayer=1 output=sumaFilas2 operator=or olayer=1,0,0 v.db.addcol map=sumaFilas2 layer=1 'columns=union INTEGER' v.db.update map=sumaFilas2 layer=1 column=union value=1 v.dissolve input=sumaFilas2 output=sumaFilas2 layer=1 column=union --overwrite g.remove vect=sumaFilas g.rename vect=sumaFilas2,sumaFilas At first, the v.overlay is instant, but when processing the map number 100, it can be several hours. Anyone knows an alternate way to do this? The first solution I adopted was making this by rows of 100 "tiles", and then joining the rows (what i'm doing in the example above). It worked for me since i only has todo a "small" map (1 week of processing), but now i need to do one MUCH more big. Thanx in advance if anyone knows something.. or not :) Andres ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] V.overlay very slow
Hi all, I'm trying to join a large set of "vectorial tiles" that i have, into a unique vectorial map. What i'm doing is something like this, for each "tile" (in the example is called filaN): v.overlay ainput=sumaFilas atype=area alayer=1 binput=fila6 btype=area blayer=1 output=sumaFilas2 operator=or olayer=1,0,0 v.db.addcol map=sumaFilas2 layer=1 'columns=union INTEGER' v.db.update map=sumaFilas2 layer=1 column=union value=1 v.dissolve input=sumaFilas2 output=sumaFilas2 layer=1 column=union --overwrite g.remove vect=sumaFilas g.rename vect=sumaFilas2,sumaFilas At first, the v.overlay is instant, but when processing the map number 100, it can be several hours. Anyone knows an alternate way to do this? The first solution I adopted was making this by rows of 100 "tiles", and then joining the rows (what i'm doing in the example above). It worked for me since i only has todo a "small" map (1 week of processing), but now i need to do one MUCH more big. Thanx in advance if anyone knows something.. or not :) Andres -- View this message in context: http://n2.nabble.com/V-overlay-very-slow-tp4169783p4169783.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] g.region (was v.to.rast conversion)
> > I should convert a shapefile into a raster file > (GeoTIFF format) at a given resolution and I want to use the > GRASS modules as a command line tools. > > I followed the instructions in the chapter "Automated > usage of grass" in the Markus's book and I created a bash > script in order to prepare the grass enviroment: > > > > #!/bin/bash > > LOCATION=test > > > > GISBASE=/usr/local/grass-6.5.svn > > GISDBASE=/usr/local/share/grassdata > > > > rm $HOME/.grassrc6 > > rm -rf "$GISDBASE/$LOCATION" #cleaning LOCATION > > > > TMPDIR=$$.tmp > > mkdir -p $GISDBASE/$TMPDIR/temp > > > > echo "LOCATION_NAME: $TMPDIR" > $HOME/.grassrc6 > > echo "MAPSET: temp" >> $HOME/.grassrc6 > > echo "DIGITIZER: none" >> $HOME/.grassrc6 > > echo "GISDBASE: $GISDBASE" >> $HOME/.grassrc6 > > > > export GISBASE=$GISBASE > > export GISRC=$HOME/.grassrc6 > > export PATH=$PATH:$GISBASE/bin:$GISBASE/scripts > > > > After these lines I run the v.in.ogr module to import > the vector: > > v.in.ogr -o -e dsn=./test_data/test_data.shp > output=grass_map > > > > And the following is the error i get. > > ERROR: region for current mapset is not set > > run "g.region" > > > > I tried to get the g.region help message, also I tried > to reset the region (with g.region -d) and to set a default > region (with g.region -s) but I get always the same error. > > > > I'm very new with GRASS and I cannot understand if > there is a problem in the installation, or it is a bug (as > it seemed), or I'm not working in the proper way. > > > > Thanks (also for the patience) > > > > No suggestions? (I have like 5000 emails in my mailing list inbox, sorry if I missed yours) If you are new to grass I would recommend using GRASS_BATCH_JOB instead of setting the enviro vars by hand. Then the grass startup script takes care of all of that for you. see the wiki page for more. http://grass.osgeo.org/wiki/GRASS_and_Shell#GRASS_Batch_jobs Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
