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