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: [email protected] > 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]> Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
