[GRASS-user] How to copy vector columns between databases

["Peter Löwe"]

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 <mlennert at club.worldonline.be>
> An: peter.loewe at gmx.de
> CC: grass-user at lists.osgeo.org
> Betreff: Re: [GRASS-user] How to copy vector columns between databases

> On 25/11/08 16:29, peter.loewe at gmx.de 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
<peter.loewe at gmx.de>





Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger