[GRASSLIST:3670] Re: v.extract (5.7) doesn't work on extra fields?

[Radim Blazek]

On Tuesday 15 June 2004 18:23, William K wrote:
> On Jun 15, 2004, at 9:48 AM, Radim Blazek wrote:
> > 1) It is not guranteed that pairs cat-POLYID in tgr_2 and tgr_3 are
> >    identical. It seems that in this case it is true but you should not
> >    rely on that.
>
> I guess this is a result of there being no guarantee that TIGER records
> are sorted by CENPOLYID.  

Yes.

> There is a 1-1 relationship between fields 2
> & 3 by CENPOLYID.  Maybe this should be taken care of in the
> conversion? 

Not in v.in.ogr, it knows nothing about the structure of data it imports.

> - sorting TIGER records by an appropriate unique ID (TLID
> or CENPOLYID).
>
> Maybe I'll do a join by CENPOLYID after conversion, just to get the
> Polygon attribs into the centroid field.
>
> > 2) There are no elements with category of field 4, if you link a table
> >    to field 4, it has no effect, you could overwrite the link of
> >    field 3, but that is not secure as I said above.
>
> So there are specific associations of field numbers and GRASS geometry?
>   or something like that?  like 1=boundaries, 2=centroids/areas?  3 is
> extra? or what?

Any geometrical element in GRASS may have attached none, one or more
categories. Usualy, a category is used as a link to the database table.
Categories are stored with elements in pairs with field. Field number
usually identifies the table, e.g. 
element  field   category
 0         1       123      -> link to table 1
 1         2       456      -> link to table 2

Good way to get idea how the field works is to download
http://mpa.itc.it/radim/g51/data.html
display 'multi', query with d.what.vect and read always
field and table. Or you can query your tgr.

You can also think about field as about layer identifier.
Here it is obvious, you have imported 3 layers: 
CompleteChain,PIP,Polygon 
one field was assigned to each layer.

> I had problems understanding the old vector cat/label thing, I guess
> I'm still not quite getting the new system.  Probably my ArcInfo
> background getting in the way.
>
> > 3) > v.extract -d in=tgr out=tgrzip type=area,centroid field=4
> > list=1-99999
> >    This is wrong as it groups areas by category, not by ZIP.
>
> so v.extract -d works purely on categories?  I guess I was thinking
> that cats were like a table relate to the fields, and it would use the
> field columns (minus the cat).

'list' and 'file' works on categories, 'where' works on attributes.

> > 4) There was a bug in v.extract -d, I fixed that in cvs.
>
> I'm using CVS snapshots (2004-6-5 at that time).  I had heard about the
> bug fix and wanted to try it out.

It was fixed today.

> > 5) ZCTA5 is varchar and v.reclass does not work with varchar column.
> >
> > Here is an example how to do that (Postgres, MySQL will be similar),
> > I know that it is not simple solution for simple task,
> > support for varchar columns and dissolve option in v.reclass
> > should make it easier:
> >
> > v.in.ogr -o dsn=TGR37013/  layer=CompleteChain,PIP,Polygon output=tgr1
> > \
> >             type=boundary,centroid snap=-1
> >
> > echo "create table tgr1_4 as select distinct ZCTA5 from tgr1_3" |
> > db.execute
>
> so far, what I've done.  oh, wait, distinct.
>
> > echo "create table tgr1_5 as select tgr1_2.cat, tgr1_3.ZCTA5,
> > tgr1_4.oid
> >       as zcta5id  from tgr1_2, tgr1_3, tgr1_4 where tgr1_2.POLYID =
> > tgr1_3.POLYID
> >       and tgr1_3.ZCTA5 = tgr1_4.ZCTA5" | db.execute
>
> now I need to pause to wrap my head around this - kinda slow on SQL
> selects still....
>
> ....so: _2.cat -> (POLYID) -> _3.ZCTA5 -> (ZCTA5) -> _4.oid (giving
> each unique ZIP an integer)
>
> > v.db.connect -o map=tgr1 table=tgr1_5 key=cat field=2
> >
> > v.reclass input=tgr1 output=tgr2 field=2 col=zcta5id type=area
> >
> > v.extract -d in=tgr2 out=tgr3 type=area list=0-10000000 new=-1
>
> weeeeeeee!  at least I can script all this.  so, the cat of tgr3
> (dissolved) relates back to the record number of tgr1_5, right?

Yes, to  tgr1_5.zcta5id

> I guess I could rejoin the tables from there to create something
> exportable with ZCTA5 column...
>
> Thanks, I'll give this a try sometime (kinda busy right now ^_^).

Radim