[GRASS-user] Re: GRASS-user] Help: Completely confused about multi-layered vectors trying to import TIGER/Line files

[Michael Barton]

On Feb 28, 2008, at 8:57 AM, grass-user-request at lists.osgeo.org wrote:

> Date: Thu, 28 Feb 2008 08:39:29 -0700
> From: Tom Russo <russo at bogodyn.org>
> Subject: [GRASS-user] Help: Completely confused about multi-layered
> 	vectors	trying to import TIGER/Line files
> To: grass-user at lists.osgeo.org
> Message-ID: <20080228153929.GA37583 at bogodyn.org>
> Content-Type: text/plain; charset=us-ascii
>
> I have been trying to wrap my brain around "multi-layered" GRASS  
> vectors and
> have only succeeded in wrapping my brain into knots.  Perhaps  
> someone here with
> a solid understanding of this stuff can help me.
>
> I'm trying to figure out how to import TIGER/Line data and actually  
> get the
> attributes of areas pulled in.  This is trouble.
>
> The v.in.ogr documentation has an example of how to do it:
>
>
> v.in.ogr  dsn=~/TIGER/BC_TGR  layer=CompleteChain,PIP  
> output=t35001_all \
>                     type=boundary,centroid snap=-1
>
> which does indeed import the CompleteChain layer and PIP (Polygon  
> Internal
> Point) layers --- it puts the boundaries in layer 1 and the  
> centroids in
> layer 2, and if I do a
>  d.vect t35001_all layer=2
> I can see the areas just fine.

Tom,

I'll focus on the first part of your question in the hopes that it  
will clarify the rest of it.

The 'layers' you mention here are 2 very different beasts.

First OGR. The underlying concept is that some data (e.g., CAD) come  
in a file that has multiple 'layers' of vectors that may (or may not)  
have different associated data. I don't know TIGER files, so I don't  
know if they come this way or not. However, OGR tends to treat all  
vector data in this way. So, for example, if you have a shapefile, it  
treats the DIRECTORY that holds the shapefile as the 'dsn' and the  
shapefile (minus the .shp) as the data 'layer'. In older versions of  
OGR, that was the only way to import stuff. Now, you can just put the  
shapefile (with .shp) in the dsn field and OGR will work it out. But  
the concept holds. So in this case, you need to know which 'layer' you  
want to import from your TIGER data, whether they come in a multi- 
layered file or as multiple files. How the layer is linked with data  
is another matter and can involve GRASS 'layers'.

Now GRASS layers. A disclaimer from me: I think that "layer" is a  
confusing term to use here. I think that "key" or "key field" or  
something along that line would be much more understandable for people  
accustomed to database terminology. In fact, that is what GRASS layers  
are. Each vector file (and object) can have more than one key field to  
link it to an attribute table. These key fields are called  
"cat" (short for category) and are always integer. So, a vector can  
have different integer keys attached to a single object. But instead  
of calling these cat1, cat2, etc, they are called '
cat in layer 1', 'cat in layer 2', etc. Each key (AKA 'cat in layer  
#') can link to a line/record in an attribute table (which also must  
have an identical integer key field, that doesn't HAVE to be called  
"cat", but often is).

The result for a hypothetical TIGER file of census blocks is that a  
block area (=polygon) can be linked to one attribute table via the key  
(="cat") in layer 1, a second attribute table via a key in layer 2,  
and so on. If there are multiple attribute tables linked to the layers  
in your TIGER file, OGR will try to put each table into a separate  
GRASS attribute table and link the proper record of each table to its  
associated vector object with a key in a GRASS layer for each table. I  
don't know how OGR parses the vector objects and attributes of a TIGER  
file internally. However, once you get the data into GRASS, it is  
possible to "upload" data from one attribute table (linked to layer 2,  
for example) into another attribute table (linked to layer 1, for  
example).

I hope this is helpful.

Michael