Re: [GRASS-user] v.in.dxf crashes
On Wed, Nov 26, 2008 at 5:23 AM, Kurt Springs [EMAIL PROTECTED] wrote: It seemed to run fine in the command line. Running it through Wish causes it to crash. I have tried v.in.dxf from current GRASS 6.4 on Linux and it worked for me. So it might be related to Active tcl 8.5. I tried a simple layer and it still crashed. I got the message The application Wish quit unexpectedly. I didn't have this problem with 6.3. I don't think that the wish related part in GRASS 6.3 was different. More likely, did you use a different Tcl version? In Console Messages I get: 11/25/08 1:10:45 PM Terminal[8482] .sdef error: Operation could not be completed. (NSXMLParserErrorDomain error 1549.) 11/25/08 1:10:45 PM Terminal[8482] line number: 2 Hope this means something to someone. Searching in the net shows a couple of similar messages, apparently related to Active tcl 8.5 (and not GRASS). Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Grass-GIS 6.4 on OSX
On Wed, Nov 26, 2008 at 6:55 AM, William Kyngesburye [EMAIL PROTECTED] wrote: On Nov 25, 2008, at 11:22 PM, Glynn Clements wrote: First, note that the Xerces check in the v.in.wfs script is broken; it uses ldd, which (AFAIK) is specifc to Linux. You might want to try removing the lines: if [ -z `ldd $OGRINFO | grep xerces` ] ; then g.message -e OGR needs to be compiled with xerces-c support exit 1 fi Done (in 6.4.svn). I see another problem - OSX does not have lynx. Wouldn't curl or wget work for this, and be more universally available? (curl for OSX) Fixed using curl (in 6.4.svn). I have also fix TMP file cleanup and added cmd history. To test the module (in LatLong location): # fetch registered GRASS users: v.in.wfs wfs=http://mapserver.gdf-hannover.de/cgi-bin/grassuserwfs?REQUEST=GetFeatureSERVICE=WFSVERSION=1.0.0; out=grass_users cheers Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: combining and evaluating vector dbf values
On Tue, Nov 25, 2008 at 9:07 AM, maning sambale [EMAIL PROTECTED] wrote: Nearly there but not quite: The final column should combine the values from the 2 columns, am I right that concat doesn't work with dbf? So this doesn't work echo UPDATE vectormap SET c_COVER = a_COVER || a_value | db.execute Did you try the SQLite driver? Just create a new mapset, define the connection with db.connect (see manual for copy-paste command) and g.copy the map from the DBF mapset into the sqlite mapset. Then the joys of SQL are available. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How to copy vector columns between databases
On 25/11/08 16:29, [EMAIL PROTECTED] wrote: Hi, I have a vector layer FOO which is linked to two tables in layers 1 and 2. The categories for each vector element are different in layer 1 and (e.g. a certain area may have the cat value 51 in layer 1 and a cat value of 42 in layer 2). Let's assume that layer one has a VARCHAR column containing the names of the region (e.g. database_layer_1: 51,Wolfenstein database_layer_2: 42 ) If a new VARCHAR column is added to layer 2 by v.db.adcol, how can the the names from layer 1 be copied into it? [Goal: database_layer_1: 51,Wolfenstein database_layer_2: 42,Wolfenstein ] Unfortunately, v.db.update seems only to work within one layer. An UPDATE/SELECT SQL-statement will not be possible unless a table can be produced which holds the categories for both database layers for each geometry element. How can this be solved ? At this stage, the only way I can see to solve this problem is using v.build option=cdump. This gives you something like this: -- CATEGORY INDEX DUMP: Number of layers: 2 -- Layer 1 number of unique cats: 6 number of cats: 6 number of types: 1 -- type | count 1 | 6 category | type | line/area 1 |1 | 1 2 |1 | 2 3 |1 | 3 4 |1 | 4 5 |1 | 5 6 |1 | 6 -- Layer 2 number of unique cats: 6 number of cats: 6 number of types: 1 -- type | count 1 | 6 category | type | line/area 1 |1 | 1 3 |1 | 2 5 |1 | 3 7 |1 | 4 9 |1 | 5 11 |1 | 6 So, you see that the line/area id can be used to find the correspondance between the category values in both layers (i.e. in this case cat 3 in layer 1 is the same object as cat 5 in layer 2. Unfortunately, there is no script friendly output from v.build (ToDo...), but still it should be possible to wrap this into a script with some python or awk magic. The easiest would probably be to use a real SQL backend (i.e. not dbf) and to add a column with the line id to each feature (i.e. 'v.db.update col=lineid value=$line where=cat=$cat' where $line and $cat are the variables of the script read from the v.build ouput... If you come up with a script, I think that this would be very useful. One thing I have been confronted with before was the desire to create a second layer with exactly the same category values (which didn't start at 1 and which had no regular step as they were statistical id codes of municipalities) which currently isn't possible. But adding a clayer option to v.db.update might be another solution. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How to copy vector columns between databases
Moritz, thanks for your response. I didn't think of the option to use v.build yet and will try to set up an awk-script eventually. One thing I have been confronted with before was the desire to create a second layer with exactly the same category values (which didn't start at 1 and which had no regular step as they were statistical id codes of municipalities) which currently isn't possible. That's where I also started... Thanks, Peter Original-Nachricht Datum: Wed, 26 Nov 2008 14:34:17 +0100 Von: Moritz Lennert [EMAIL PROTECTED] An: [EMAIL PROTECTED] CC: grass-user@lists.osgeo.org Betreff: Re: [GRASS-user] How to copy vector columns between databases On 25/11/08 16:29, [EMAIL PROTECTED] wrote: Hi, I have a vector layer FOO which is linked to two tables in layers 1 and 2. The categories for each vector element are different in layer 1 and (e.g. a certain area may have the cat value 51 in layer 1 and a cat value of 42 in layer 2). Let's assume that layer one has a VARCHAR column containing the names of the region (e.g. database_layer_1: 51,Wolfenstein database_layer_2: 42 ) If a new VARCHAR column is added to layer 2 by v.db.adcol, how can the the names from layer 1 be copied into it? [Goal: database_layer_1: 51,Wolfenstein database_layer_2: 42,Wolfenstein ] Unfortunately, v.db.update seems only to work within one layer. An UPDATE/SELECT SQL-statement will not be possible unless a table can be produced which holds the categories for both database layers for each geometry element. How can this be solved ? At this stage, the only way I can see to solve this problem is using v.build option=cdump. This gives you something like this: -- CATEGORY INDEX DUMP: Number of layers: 2 -- Layer 1 number of unique cats: 6 number of cats: 6 number of types: 1 -- type | count 1 | 6 category | type | line/area 1 |1 | 1 2 |1 | 2 3 |1 | 3 4 |1 | 4 5 |1 | 5 6 |1 | 6 -- Layer 2 number of unique cats: 6 number of cats: 6 number of types: 1 -- type | count 1 | 6 category | type | line/area 1 |1 | 1 3 |1 | 2 5 |1 | 3 7 |1 | 4 9 |1 | 5 11 |1 | 6 So, you see that the line/area id can be used to find the correspondance between the category values in both layers (i.e. in this case cat 3 in layer 1 is the same object as cat 5 in layer 2. Unfortunately, there is no script friendly output from v.build (ToDo...), but still it should be possible to wrap this into a script with some python or awk magic. The easiest would probably be to use a real SQL backend (i.e. not dbf) and to add a column with the line id to each feature (i.e. 'v.db.update col=lineid value=$line where=cat=$cat' where $line and $cat are the variables of the script read from the v.build ouput... If you come up with a script, I think that this would be very useful. One thing I have been confronted with before was the desire to create a second layer with exactly the same category values (which didn't start at 1 and which had no regular step as they were statistical id codes of municipalities) which currently isn't possible. But adding a clayer option to v.db.update might be another solution. Moritz -- Dr. Peter Löwe [EMAIL PROTECTED] Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.dxf crashes
On GRASS 6.3 I use X11 on Mac OS X 10.5.5 (aka Leopard). I agree that the problem is with Active tcl 8.5. Having used the two, I have found X11 to be much more stable. How easy would it be to compile a 6.4 to use X11? Kurt On Nov 26, 2008, at 3:04 AM, Markus Neteler wrote: On Wed, Nov 26, 2008 at 5:23 AM, Kurt Springs [EMAIL PROTECTED] wrote: It seemed to run fine in the command line. Running it through Wish causes it to crash. I have tried v.in.dxf from current GRASS 6.4 on Linux and it worked for me. So it might be related to Active tcl 8.5. I tried a simple layer and it still crashed. I got the message The application Wish quit unexpectedly. I didn't have this problem with 6.3. I don't think that the wish related part in GRASS 6.3 was different. More likely, did you use a different Tcl version? In Console Messages I get: 11/25/08 1:10:45 PM Terminal[8482] .sdef error: Operation could not be completed. (NSXMLParserErrorDomain error 1549.) 11/25/08 1:10:45 PM Terminal[8482] line number: 2 Hope this means something to someone. Searching in the net shows a couple of similar messages, apparently related to Active tcl 8.5 (and not GRASS). Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Going back to 6.3
It was a s a surface raster map generated from an ascii file. It just seems that when v.digit crashes, regardless of the version, I am in for trouble. Kurt On Nov 25, 2008, at 11:51 PM, William Kyngesburye wrote: On Nov 25, 2008, at 10:33 PM, Kurt Springs wrote: If you are using my GRASS 6.3, there is no need to delete ActiveTcl. It has its own internal TclTk X11 binaries that it explicitly uses. In fact, no need to delete 6.3 before installing 6.4. 6.4 actually overwrote 6.3. I'd assumed the reverse would be true. Odd, GRASS 6.3 and 6.4 have different names: GRASS-6.3.app GRASS-6.4.app Also, the surface raster I generated from the ASCII files only displays white now. Is there anyway to recover that once I go back to 6.3? Rasters should be compatible between 6.4 and 6.3. Something when v.digit crashed actually made it unreadable. Also odd - why a vector would affect a raster. Or did you mean surface _vector_? - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind? - The Ruler of the Universe ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.dxf crashes
On Nov 26, 2008, at 9:14 AM, Kurt Springs wrote: On GRASS 6.3 I use X11 on Mac OS X 10.5.5 (aka Leopard). I agree that the problem is with Active tcl 8.5. Having used the two, I have found X11 to be much more stable. How easy would it be to compile a 6.4 to use X11? Not hard at all... Note that not only is the type of TclTk different - Aqua vs X11, but the version as well: 8.4 X11 for GRASS 6.3, 8.5 Aqua for GRASS 6.4. Maybe there is an issue with TclTk 8.5? It's not possible to build a working (for GRASS) TclTk 8.4 Aqua - some Aqua issues were fixed in 8.5. I guess the thing to try is TclTk 8.5 X11, to test if it's a version problem. Do you have a small DXF that crashes for you that I could test with? I tried a simple layer and it still crashed. I got the message The application Wish quit unexpectedly. I didn't have this problem with 6.3. Check for a crashlog in Console.app. This could help. Especially since it would have some paths to verify which wish is running. I don't think that the wish related part in GRASS 6.3 was different. More likely, did you use a different Tcl version? In Console Messages I get: 11/25/08 1:10:45 PM Terminal[8482] .sdef error: Operation could not be completed. (NSXMLParserErrorDomain error 1549.) 11/25/08 1:10:45 PM Terminal[8482] line number: 2 Hope this means something to someone. Searching in the net shows a couple of similar messages, apparently related to Active tcl 8.5 (and not GRASS). Markus ActiveTcl or Aqua TclTk? (google didn't turn up anything for me) sdef... that's scripting (Applescript) definitions for OSX (Wish.app is scriptable, to run a Tcl script). ... the AS dictionary for wish.app opens in Script Editor... Wish.app runs fine alone... hopefully a crashlog will help... - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Earth: Mostly harmless - revised entry in the HitchHiker's Guide to the Galaxy ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How to copy vector columns between databases
On Tue, Nov 25, 2008 at 4:29 PM, [EMAIL PROTECTED] wrote: Hi, I have a vector layer FOO which is linked to two tables in layers 1 and 2. The categories for each vector element are different in layer 1 and (e.g. a certain area may have the cat value 51 in layer 1 and a cat value of 42 in layer 2). Let's assume that layer one has a VARCHAR column containing the names of the region (e.g. database_layer_1: 51,Wolfenstein database_layer_2: 42 ) If a new VARCHAR column is added to layer 2 by v.db.adcol, how can the the names from layer 1 be copied into it? [Goal: database_layer_1: 51,Wolfenstein database_layer_2: 42,Wolfenstein ] Unfortunately, v.db.update seems only to work within one layer. An UPDATE/SELECT SQL-statement will not be possible unless a table can be produced which holds the categories for both database layers for each geometry element. How can this be solved ? g.copy vect=roads,myroads --o v.info -c myroads v.db.addtable myroads table=extratab layer=2 columns=cat integer,label varchar(100) v.db.select myroads layer=2 cat|label - Uffa: this should be set!! Bug in v.to.db :( ... ok, I have made some fixes in SVN (r34494 and r34495) but they don't seem to be sufficient. See related mail on grass-dev. Now you need a join operation (db.execute). Note that this isn't supported with DBF driver: # I use SQLIte here: v.db.connect -p myroads Vector map [EMAIL PROTECTED] is connected by: layer 1 table myroads in database /home/neteler/grassdata/spearfish60/sqlite/sqlite.db through driver sqlite with key cat layer 2 table extratab in database /home/neteler/grassdata/spearfish60/sqlite/sqlite.db through driver sqlite with key cat # bug workaround: db.droptable extratab -f db.copy from_table=myroads to_table=extratab v.db.select myroads layer=2 cat|label 0|no data 1|interstate 2|primary highway, hard surface 3|secondary highway, hard surface 4|light-duty road, improved surface 5|unimproved road # simulate almost empty table (note that I fixed v.db.dropcol right now for layer=2): v.db.dropcol myroads layer=2 column=label v.info -c myroads layer=2 # add new column with desired name: v.db.addcol myroads layer=2 col=names varchar(100) v.info -c myroads layer=2 Displaying column types/names for database connection of layer 2: INTEGER|cat CHARACTER|names v.db.select myroads layer=2 cat|names 0| 1| 2| 3| 4| 5| # now JOIN the names into: echo UPDATE extratab SET names=(SELECT label FROM myroads WHERE extratab.cat=myroads.cat); | db.execute # voilà: v.db.select myroads layer=2 cat|names 0|no data 1|interstate 2|primary highway, hard surface 3|secondary highway, hard surface 4|light-duty road, improved surface 5|unimproved road Nice exercise :) TODO: fix v.to.db for layer1. Cheers Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Grass-GIS 6.4 on OSX
William Kyngesburye wrote: I've seen random ocurrences in wxpython GUI where the titlebar gets covered by the menbar. I think it may have something to do with a mismatching runtime Python vs what GRASS was compiled for. The only parts of the wx GUI which are compiled for any version of [wx]Python are the vdigit and nviz modules. The core GUI doesn't include any compiled code. 2) I'm trying to test a WFS; Grass asks for Xerxes-c support. How do I achieve this in the OSX environment? ? Asks for? My GDAL framework has Xerces support, for ILI and GML formats. There is no xerces program that GRASS can run, so Xerces would have to be used as a library and compiled into GRASS. v.in.wfs uses v.in.ogr to perform the actual work, but this relies upon GDAL/OGR having Xerces support. The script tries to be clever and detect whether this is the case, but the end result is that it often refuses to run simply because it incorrectly concludes that GDAL lacks Xerces support. -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Grass-GIS 6.4 on OSX
William Kyngesburye wrote: I see another problem - OSX does not have lynx. Wouldn't curl or wget work for this, and be more universally available? (curl for OSX) Yes. You just need some way to retrieve the data for a URL. The 7.0 version uses Python's urllib module. -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Grass-GIS 6.4 on OSX
Richard Chirgwin wrote: So which would be safer, to remove the check from v.in.wfs, or try some other workaround? Remove the check. By the way, the error from v.in.wfs is OGR needs to be compiled with xerces-c support. Right. This is printed by the script when it fails to detect Xerces support (in this case, because the check is broken). -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Best way to reconnect tables in grass' databse
Hi All! I think I have questioned something similar but not quite the same several months ago. I moved the grassdb foldes (with all of its locations of course) in another directory and thus, the absolute database path has been changed. I need to re-connect all database tables. I think I am doing the right thing by trying to use the v.db.reconnect.all module. However, I am a bit confused about the appropriate format to be used for the old_database, new_database parameters. Isn't it the absolute paths that are required? Is there a better way to ensure integrity of the grass database while moving it on another place(=directory)? Thank you, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.dxf crashes
On Nov 26, 2008, at 11:42 AM, Michael Barton wrote: On Nov 26, 2008, at 10:00 AM, [EMAIL PROTECTED] wrote: Message: 5 Date: Wed, 26 Nov 2008 10:56:30 -0600 From: William Kyngesburye [EMAIL PROTECTED] Subject: To: Kurt Springs [EMAIL PROTECTED] Cc: GRASS user list [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On Nov 26, 2008, at 9:14 AM, Kurt Springs wrote: On GRASS 6.3 I use X11 on Mac OS X 10.5.5 (aka Leopard). I agree that the problem is with Active tcl 8.5. Having used the two, I have found X11 to be much more stable. How easy would it be to compile a 6.4 to use X11? Not hard at all... Actually, except for NVIZ, you don't even have to compile anything. If you have TclTk for x11, you can just set GRASS_WISH to the wish file for that version of TclTk. You need to do this in your bash .profile file and not in the .grassrc6 file. Then all of GRASS will be in the x11 version except for NVIZ. Michael Except that I bundle the X11 TclTk into GRASS, while the Aqua TclTk is outside GRASS. Chances are Kurt doesn't have an X11 TclTk hanging around, except what would be in GRASS 6.3.app. Since I built 6.4 for TclTk Aqua, I didn't bundle TclTk X11 into it. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history. - Hitchhiker's Guide to the Galaxy ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Grass-GIS 6.4 on OSX
On Wed, Nov 26, 2008 at 6:47 PM, Glynn Clements [EMAIL PROTECTED] wrote: Richard Chirgwin wrote: So which would be safer, to remove the check from v.in.wfs, or try some other workaround? Remove the check. ... or update from SVN or get the next SVN snapshot on Saturday :) Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Best way to reconnect tables in grass' databse
Nikos Alexandris wrote: I think I have questioned something similar but not quite the same several months ago. I moved the grassdb foldes (with all of its locations of course) in another directory and thus, the absolute database path has been changed. I need to re-connect all database tables. I think I am doing the right thing by trying to use the v.db.reconnect.all module. However, I am a bit confused about the appropriate format to be used for the old_database, new_database parameters. Isn't it the absolute paths that are required? For old_database=, it needs to be the exact string which appears as the fourth field of v.db.connect -g, including the trailing / character if it is present. For new_database=, the value is passed directly to v.db.connect's database= option, so it can be in any form which the driver accepts, including variable substitutions for the DBF driver. The default database for the DBF driver is literally: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ By literally, I mean that's how it appears in the dbln file; the driver expands the variables whenever you access the data. Any such maps don't need to be explicitly reconnected if you move the database. -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Best way to reconnect tables in grass' databse
On Wed, 2008-11-26 at 18:52 +0100, Nikos Alexandris wrote: Hi All! I think I have questioned something similar but not quite the same several months ago. I moved the grassdb foldes (with all of its locations of course) in another directory and thus, the absolute database path has been changed. I need to re-connect all database tables. I think I am doing the right thing by trying to use the v.db.reconnect.all module. However, I am a bit confused about the appropriate format to be used for the old_database, new_database parameters. Isn't it the absolute paths that are required? Is there a better way to ensure integrity of the grass database while moving it on another place(=directory)? Thank you, Nikos *** NOTE *** Feel really tired today and I was writing The Text (below) before Glynn's reply showed-up in my Inbox! I hope you see it's comical side and don't get offended :-) *** NOTE *** OK, I don't understand or the descriptions and the names of the modules v.db.connect and v.db.reconnect.all are a bit cryptic :-p * v.db.connect is to be used on one map. And gives with -g the following information: layer[/layer name] table key database driver * v.db.reconnect.all is to be used for all vector maps present on the database (as the name of this modules implies). Question: How should a beginner understand how to fill in the old_database, new_database parameters if the print out of v.db.connect is for one map (including several variables) and v.db.reconnect.all expects something (I suppose one variable or 2?) for all maps? I try different things but I only get errors. An example: # print current db.connect settings db.connect -p driver:sqlite database:/geo/grassdb/peloponnese/hgrs87/PERMANENT/sqlite.db # some table present in the database db.tables -p | grep water samples_water # connection settings of this table (as it was set before moving grassdb in another directory v.db.connect -g samples_water 1 samples_water cat /home/nik/grassdb/peloponnese/hgrs87/PERMANENT/sqlite.db sqlite # of course the old database contains several tables/vector maps # How would I go about to v.db.reconnect.all at once? # Trying to figure-out how this module works # reading the description v.db.reconnect.all help [...] Usage: v.db.reconnect.all old_database=string new_database=string [old_schema=string] [new_schema=string] [--verbose] [--quiet] [...] old_database Name of old database. The database must be in form printed by v.db.connect -g, i.e. with substituted variables [...] # shrug! # hmmm, ok... so I need to look the v.db.connect -g result... !? # wait a second, the v.db.connect -g result gives for one map several stuff # ok... I am a beginner on this. But some programer wrote it, he tested it, others use it. It should work. Yes, it works! I've read it in one message in the mailing list. There was no example though. It doesn't matter. So, Niko, think logical :-) # What on earth should I fill in in the old_database parameter. But it's clearly stated: The database must be in form printed by v.db.connect -g, i.e. with substituted variables # ok, lets try # I will use the output of v.db.connect -g from some map. I'll take my water_samples # OK, I think I'll pick all variables that refer clearly to the database itself. # ??? -- What am I talking now... ? # Ahh, go ahead and try it. ... ... # STOP-STOP-STOP here. STOP right here - right now. # I just read Glynn's mail :-) Let's read first carefuly his reply. # Oh... I really like this community. # I have to admit that beginners/intermediate end-users (including me) ask sometimes things for which they could easily get an answer if they tried a bit more :-) (*possibly* to be continued ;-) Cheers, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Grass-GIS 6.4 on OSX
Markus Neteler wrote: On Wed, Nov 26, 2008 at 6:47 PM, Glynn Clements [EMAIL PROTECTED] wrote: Richard Chirgwin wrote: So which would be safer, to remove the check from v.in.wfs, or try some other workaround? Remove the check. ... or update from SVN or get the next SVN snapshot on Saturday :) Markus Thanks everybody, and I'll report back when I've fixed the script ... Cheers, Richard ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] get ESRI polygon shape with v.out.ogr
Dear list, I would like to export a vectorized raster theme as a ESRI polygon shape from GRASS 6.3. After vectorization of the raster with r.to.vect I get a vector theme with categories. Within this GRASS-layer, it is also possible to fill areas. Hence I run v.out.ogr using the boundary and area option as well as the ESRI shape option. At the end of the process, GRASS tells me that no categories are written. Visualizing the result within another GIS-software, there is just a line theme and thus no way to display filled areas. Any suggestions (AS SOON AS POSSIBLE PLEASE)? Regards Chris _ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Varying results - v.select,v.distance,v.what
On Thu, Nov 20, 2008 at 9:03 PM, Kevin Webb [EMAIL PROTECTED] wrote: ... v.db.connect -p indicates layer#2 is keyed by the cat field yet I don't see a 'cat' field in the v.info output, shouldn't there be a 'cat' column in layer#2 or am I misinterpreting how multiple layers are properly added to a vector? Yes, a cat column should always be there AFAIK. Can you put the packages location somewhere with copy.paste commands to try? Offlist, if needed for privacy. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.dxf crashes
William wrote: Check for a crashlog in Console.app. This could help. Especially since it would have some paths to verify which wish is running. In gis.m look in Help-About System for that. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How to copy vector columns between databases
On 26/11/08 18:09, Markus Neteler wrote: On Tue, Nov 25, 2008 at 4:29 PM, [EMAIL PROTECTED] wrote: Hi, I have a vector layer FOO which is linked to two tables in layers 1 and 2. The categories for each vector element are different in layer 1 and (e.g. a certain area may have the cat value 51 in layer 1 and a cat value of 42 in layer 2). Let's assume that layer one has a VARCHAR column containing the names of the region (e.g. database_layer_1: 51,Wolfenstein database_layer_2: 42 ) If a new VARCHAR column is added to layer 2 by v.db.adcol, how can the the names from layer 1 be copied into it? [Goal: database_layer_1: 51,Wolfenstein database_layer_2: 42,Wolfenstein ] Unfortunately, v.db.update seems only to work within one layer. An UPDATE/SELECT SQL-statement will not be possible unless a table can be produced which holds the categories for both database layers for each geometry element. How can this be solved ? g.copy vect=roads,myroads --o v.info -c myroads v.db.addtable myroads table=extratab layer=2 columns=cat integer,label varchar(100) v.db.select myroads layer=2 cat|label - Uffa: this should be set!! Bug in v.to.db :( ... ok, I have made some fixes in SVN (r34494 and r34495) but they don't seem to be sufficient. See related mail on grass-dev. IIUC, the result is actually correct since myroads does not contain any categories in layer 2 (see my response on grass-dev). But you got us on the right track: there actually is a way to copy cats of one layer to another layer (e.g. here from layer 1 to layer 2): v.db.addcol FOO layer=2 col='cat1 int' v.to.db FOO layer=2 col=cat1 option=query qlayer=1 qcol=cat Only if any of the two layers do not have a table attached do you need the v.db.addtable above, and to make that work you actually need categories in both layers (which isn't the case in Markus' example)... Now you need a join operation (db.execute). Note that this isn't supported with DBF driver: # I use SQLIte here: v.db.connect -p myroads Vector map [EMAIL PROTECTED] is connected by: layer 1 table myroads in database /home/neteler/grassdata/spearfish60/sqlite/sqlite.db through driver sqlite with key cat layer 2 table extratab in database /home/neteler/grassdata/spearfish60/sqlite/sqlite.db through driver sqlite with key cat # bug workaround: db.droptable extratab -f db.copy from_table=myroads to_table=extratab v.db.select myroads layer=2 cat|label 0|no data 1|interstate 2|primary highway, hard surface 3|secondary highway, hard surface 4|light-duty road, improved surface 5|unimproved road This works because v.db.select selects all tuples in the table irrespective of whether these tuples have any corresponding features in the layer. # simulate almost empty table (note that I fixed v.db.dropcol right now for layer=2): v.db.dropcol myroads layer=2 column=label v.info -c myroads layer=2 # add new column with desired name: v.db.addcol myroads layer=2 col=names varchar(100) v.info -c myroads layer=2 Displaying column types/names for database connection of layer 2: INTEGER|cat CHARACTER|names v.db.select myroads layer=2 cat|names 0| 1| 2| 3| 4| 5| # now JOIN the names into: echo UPDATE extratab SET names=(SELECT label FROM myroads WHERE extratab.cat=myroads.cat); | db.execute # voilà: v.db.select myroads layer=2 cat|names 0|no data 1|interstate 2|primary highway, hard surface 3|secondary highway, hard surface 4|light-duty road, improved surface 5|unimproved road Try clicking on any of the roads : do you actually see these results in layer 2 ? TODO: fix v.to.db for layer1. It works AFAIU, you just need to use the query option. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] get ESRI polygon shape with v.out.ogr
christian Brandt wrote: I would like to export a vectorized raster theme as a ESRI polygon shape from GRASS 6.3. After vectorization of the raster with r.to.vect I get a vector theme with categories. Within this GRASS-layer, it is also possible to fill areas. Hence I run v.out.ogr using the boundary and area option as well as the ESRI shape option. At the end of the process, GRASS tells me that no categories are written. Visualizing the result within another GIS-software, there is just a line theme and thus no way to display filled areas. see the example in the v.out.ogr help page. in most vector modules features without category are skipped. areas are a virtual feature type made up of a centroid + a boundary. in most vector maps boundaries are without category, as centroids hold those. no idea why type=boundary,area would fail when type=area works. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.in.wfs [was Re: Grass-GIS 6.4 on OSX]
-- Message: 1 Date: Wed, 26 Nov 2008 21:11:53 +0100 From: Markus Neteler [EMAIL PROTECTED] Subject: Re: [GRASS-user] Grass-GIS 6.4 on OSX To: GRASS user list grass-user@lists.osgeo.org Cc: Richard Chirgwin [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 26, 2008 at 6:47 PM, Glynn Clements [EMAIL PROTECTED] wrote: Richard Chirgwin wrote: So which would be safer, to remove the check from v.in.wfs, or try some other workaround? Remove the check. ... or update from SVN or get the next SVN snapshot on Saturday :) Markus ...well, that worked. The xerces check is dead. Next question, can v.in.wfs do a get capabilities or do I have to have a full URL to the desired feature? RC ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
