On Feb 28, 2008, at 8:57 AM, [EMAIL PROTECTED] wrote:
Date: Thu, 28 Feb 2008 08:39:29 -0700
From: Tom Russo <[EMAIL PROTECTED]>
Subject: [GRASS-user] Help: Completely confused about multi-layered
vectors trying to import TIGER/Line files
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
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
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
