[GRASSLIST:4242] Re: Generating new linked attribute table after v.overlay
Radim Blazek
blazek at itc.it
Tue Aug 24 13:05:07 EDT 2004
I think that one v.overlay + SQL should be enough. If you run
v.overlay ainput=seismicinterclean binput=vegereclass \
output=seismicvegetemp operator=or
you get a table linked to field 1 which has in 'a' column cats from
'seismicinterclean' and in 'b' from 'seismicvegetemp'.
You can for example add a new column
alter table seismicvegetemp add column newtype integer;
and update this column in sql:
update table seismicvegetemp set newtype = b where a is null;
update table seismicvegetemp set newtype = 1001 where a = 1 and b = 1;
update table seismicvegetemp set newtype = 1002 where a = 1 and b = 2;
etc.
then v.reclass col=newtype and v.db.connect to a new table with
all (old+new) vegetation types.
Radim
PS: It is not possible to update a category value of different field
without table. It is however possible to update to one table
a query from another table linked to other field:
v.to.db option=query field= qfield=
On Tuesday 24 August 2004 18:05, Craig Aumann wrote:
> No, its two polygon layers: trails and vegetation. I see I have confused
> you by using state class and vegetation interchangeably.
>
> The trail polygon layer comes from buffering line features. The
> vegetation layer does not represent trails - it treats the landscape as
> vegetation type without any human disturbances. What I want is to end up
> with a single new vegetation layer which treats the trail as distinct
> vegetation classes which are assigned by me: i.e., TRAIL-PINE,
> TRAIL-ASPEN which result from the trail passing through PINE stands or
> ASPEN stands. Thus, the final vegetation layer will look like:
>
> --------------------------------------
>
> | PINE | Trail-Pine | PINE |
>
> --------------------------------------
>
> where before there just a single "PINE" polygon. Why do I want this?
> Because this layer forms the input to a vegetation succession model. It
> allows me to say that the successional dynamics of TRAIL-PINE vegetative
> polygons are different from the successional dynamics of PINE polygons.
>
> In the code below, I got as far as adding rows into the attribute table
> associated with the new TRAIL-VEGETATION layer. The problem is, that
> the vegetation class the trail intersected is in Field 1 (i.e., ASPEN,
> PINE), and I have linked the attribute table to Field 2 which now
> contains distinct LINK_KEYs. How can I copy or get the cat values in
> field 1 to the right rows in the attached attribute table via field 2?
>
> Once these values are upload, I can then easily assign new vegetative
> state codes (Pine -> Trail-Pine. Aspen -> Trail-Aspen) using SQL
> queries.
>
> The following steps (which I know how to do) is to create the new
> vegetative layer - which is done by first removing the trail polygons
> from the original vegetative layer (NOT overlay) followed by merging in
> the TRAIL-VEGETATION polygons using an OR overlay. Given that I have
> created distinct LINK_KEYs I should be able to link this final
> vegetative layer to the modified attribute table and I'm off to the
> races.
>
>
> I hope this clear things up. Perhaps there is an entirely different way
> to do this.
>
> Cheers!
> Craig
>
> On Tue, 2004-08-24 at 02:48, Radim Blazek wrote:
> > I worry that I haven't got what you exactly want.
> > You have 3 polygon layers?:
> > - trail (one or more cats?)
> > - vegetation
> > - states
> > Do you need a table with area_size, vegetation_type, state
> > in the trail (or outside trail)?
> >
> > Radim
> >
> > On Monday 23 August 2004 20:36, Craig Aumann wrote:
> > > I'm afraid that's only part of the solution I need. Imagine you have a
> > > trail (represented as a polygon in a separate map layer) running
> > > through different kinds of vegetation types. Each polygon in the
> > > vegetation map links off to an attribute table. I want to overlap the
> > > trail with the vege map so that I know which parts of the trail are in
> > > which types of vegetation and upload this information to the original
> > > attribute table so that each distinct trail-vegetation type polygon
> > > links to its own record in the database. After this, I will then do
> > > another v.overlay (with option NOT) so that the trail will then be
> > > represented with distinct vegetative types (i.e., TRAIL-ASPEN, or
> > > TRAIL-PINE) in the map.
> > >
> > > See my code below for precisely what I mean.
> > >
> > > ## Set the CAT values according to the vegetative classes.
> > > v.reclass input=vegelayer output=vegereclass type=area \
> > > field=2 col=cover
> > >
> > > ## Do the overlay.
> > > v.overlay ainput=seismicinterclean binput=vegereclass bfield=1 \
> > > output=seismicvegetemp operator=and
> > >
> > > ## Create new CAT values in field 2. These will be used so that each
> > > ## vegetative polygon in the overlay links to a single row in the
> > > ## table. I add 1000000 to ensure these values are distinct from the
> > > ## previous values used to link this table to the original "vegelayer"
> > > ## map.
> > >
> > > v.category input=vegereclass output=seismicvegetemp2 \
> > > option=add field=2
> > > v.category input=seismicvegetemp2 output=seismicvegetemp3 \
> > > option=sum field=2 cat=1000000
> > >
> > >
> > > ## Connect the map to this table.
> > > v.db.connect -o map=seismicvegetemp3 table=play_att \
> > > field=2 key=link_key \
> > > driver=pg database="dbname=alpac_netdown,user=caumann"
> > >
> > > ## Create new rows in the table for each new polygon
> > > ## resulting from the overlay.
> > > v.to.db map=seismicvegetemp3 field=2 option=cat type=centroid
> > >
> > >
> > > NOW, HOW DO I UPLOAD THE CAT VALUES IN FIELD 1 (WHICH CONTAIN THE
> > > VEGE STATE CLASS THIS POLYGON INTERESECTED) TO THE TABLE SO
> > > THAT I CAN EXECUTE QUERIES AND ASSIGN NEW STATE CLASSES USING THOSE
> > > VALUES?????
> > >
> > >
> > > Cheers!
> > > Craig
> > >
> > > On Mon, 2004-08-23 at 03:57, Radim Blazek wrote:
> > > > Reclass first input vectors by state ID (v.reclass col=STATE),
> > > > then run v.overlay and the table linked to field 1 contains
> > > > what you want.
> > > >
> > > > Radim
> > > >
> > > > On Saturday 21 August 2004 00:54, Craig Aumann wrote:
> > > > > I'm working in 5.7.
> > > > >
> > > > > Suppose we have two polygons which have attributes linked to an
> > > > > associated PostGRESQL database.
> > > > >
> > > > > i.e.
> > > > >
> > > > > ----------------
> > > > >
> > > > > | 1 | 2 |
> > > > >
> > > > > -----------------
> > > > >
> > > > > linking off to a table:
> > > > >
> > > > > LINK_KEY STATE
> > > > > 1 57
> > > > > 2 59
> > > > >
> > > > >
> > > > > I now overlay another polygon:
> > > > > ----------------
> > > > >
> > > > > | 10 | 11 |
> > > > >
> > > > > *******************
> > > > >
> > > > > | 12 | 13 |
> > > > >
> > > > > ******************
> > > > >
> > > > > | 14 | 15 |
> > > > >
> > > > > -----------------
> > > > >
> > > > > and what I want to do is end up with an associated table linked to
> > > > > the result of the overlay that looks like this:
> > > > >
> > > > > LINK_KEY STATE NEW_STATE
> > > > > 10 57 57
> > > > > 11 59 59
> > > > > 12 57 157
> > > > > 13 59 159
> > > > > 14 57 57
> > > > > 15 59 59
> > > > >
> > > > > I need a few kicks in the right direction (alright, I need to have
> > > > > my hand held in a major way!) to figure out how to proceed
> > > > > following v.overlay to ensure that each new polygon resulting from
> > > > > the overlay has one (and only one!) unique link_key into the new
> > > > > attribute table AND also how to do the associated query processing
> > > > > based on the STATE (and other columns) of the original polygons
> > > > > (stored in their original linked table above) which the overlaid
> > > > > polygon intersects.
> > > > >
> > > > >
> > > > > Thanks!
> > > > > Craig
More information about the grass-user
mailing list