<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Tom,<div><br class="webkit-block-placeholder"></div><div>It sounds to me like you will need to import your basic vector shapes and then use SQL joins to link them up to the various tables you need. Unless there has been a recent update to the contrary (I saw some things on the dev list, but don't remember the outcome), you cannot do that with the normal DBF files that GRASS uses. You'll need to make SQLite or PostgreSQL your default, import the TIGER tables into one of these systems and then do the joins.</div><div><br class="webkit-block-placeholder"></div><div>Michael<br><div apple-content-edited="true"> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><div><div><div>______________________________</div><div>Michael Barton, Professor</div><div>Professor of Anthropology</div><div>Director of Graduate Studies</div><div>School of Human Diversity & Social Change</div><div>Center for Social Dynamics & Complexity</div><div>Arizona State University</div><div>Tempe, AZ 85287-2402</div><div>USA</div><div><br></div><div>voice: 480-965-6262; fax: 480-965-7671</div><div>www: <a href="http://www.public.asu.edu/~cmbarton">http://www.public.asu.edu/~cmbarton</a></div></div></div></div></div></div></span> </div><br><div><div>On Feb 28, 2008, at 12:08 PM, Tom Russo wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"> <div> <!-- Converted from text/plain format --><p><font size="2">On Thu, Feb 28, 2008 at 10:38:00AM -0700, we recorded a bogon-computron collision of the <<a href="mailto:michael.barton@asu.edu">michael.barton@asu.edu</a>> flavor, containing:<br> ><br> > On Feb 28, 2008, at 8:57 AM, <a href="mailto:grass-user-request@lists.osgeo.org">grass-user-request@lists.osgeo.org</a> wrote:<br> ><br> >> Date: Thu, 28 Feb 2008 08:39:29 -0700<br> >> From: Tom Russo <<a href="mailto:russo@bogodyn.org">russo@bogodyn.org</a>><br> >> Subject: [GRASS-user] Help: Completely confused about multi-layered<br> >> vectors trying to import TIGER/Line files<br> >> To: <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br> >> Message-ID: <<a href="mailto:20080228153929.GA37583@bogodyn.org">20080228153929.GA37583@bogodyn.org</a>><br> >> Content-Type: text/plain; charset=us-ascii<br> >><br> >> I have been trying to wrap my brain around "multi-layered" GRASS vectors<br> >> and<br> >> have only succeeded in wrapping my brain into knots. Perhaps someone here<br> >> with<br> >> a solid understanding of this stuff can help me.<br> >><br> >> I'm trying to figure out how to import TIGER/Line data and actually get<br> >> the<br> >> attributes of areas pulled in. This is trouble.<br> >><br> <br> Michael:<br> <br> Thank you for answering, but your answer has either highlighted how<br> poorly I expressed my question, or thrown into sharper relief how<br> confused I am about this. Some of what you say below was already<br> clear to me, but there's a big gap between "Each vector file (and<br> object) can have more than one key field to link it to an attribute<br> table," (which I knew), "Each key (AKA 'cat in layer #') can link to<br> a line/record in an attribute table (which also must have an<br> identical integer key field, that doesn't HAVE to be called "cat", but<br> often is)."(which I also knew), and the thing I really want to know --- and<br> it is the latter that I think I haven't explained well.<br> <br> > The 'layers' you mention here are 2 very different beasts.<br> ><br> > First OGR. The underlying concept is that some data (e.g., CAD) come in a<br> > file that has multiple 'layers' of vectors that may (or may not) have<br> > different associated data. I don't know TIGER files, so I don't know if<br> > they come this way or not.<br> <br> I'll clarify, then, because that's not exactly how TIGER is layed out.<br> There are a number of vectors, and each is related to one or more<br> tables of attributes, but OGR doesn't make the connection itself --- there<br> are simply common attributes between tables that one is left to associate<br> onesself.<br> <br> The TIGER data comes in a number of files, each containing a series of<br> records. Each file has a different record type. There is a record<br> type that defines nodes in "Complete Chains", a record type for "shape<br> points" that define the vertices (between the nodes) of the chains, a<br> record type for Polygon Internal Points (centroids), a record for<br> polygon attributes, a record for linking chains to polygons (with<br> left/right polygon ids) etc.<br> <br> When unpacked into a directory, OGR views the collection as a set of<br> "layers" (I HATE that this word is used in so many different ways). A quick<br> "ogrinfo" shows:<br> <br> INFO: Open of `/users/russo/TIGER/BC_TGR'<br> using driver `TIGER' successful.<br> <br> Layer name: CompleteChain<br> Geometry: Line String<br> Feature Count: 58942<br> Extent: (-107.196170, 34.869024) - (-106.149575, 35.219639)<br> Layer SRS WKT: [...]<br> MODULE: String (8.0)<br> TLID: Integer (10.0) <- This is a Line ID to link to other tables<br> [... tons more attributes for linear features...]<br> <br> Layer name: AltName <--- table of alternate feature names in addition<br> to the one in CompleteChain<br> Geometry: None<br> Feature Count: 6026<br> Layer SRS WKT:[...]<br> MODULE: String (8.0)<br> TLID: Integer (10.0) <--- this one could be used to relate the<br> alternate names back to linear features<br> RTSQ: Integer (3.0)<br> FEAT: IntegerList (8.0) <--- and this one links to the next table,<br> which actually has the names<br> <br> Layer name: FeatureIds<br> Geometry: None<br> Feature Count: 10235<br> Layer SRS WKT: [...]<br> MODULE: String (8.0)<br> FILE: Integer (5.0)<br> FEAT: Integer (8.0) <--- linking column for AltName table<br> FEDIRP: String (2.0)<br> FENAME: String (30.0)<br> FETYPE: String (4.0)<br> FEDIRS: String (2.0)<br> <br> Layer name: ZipCodes<br> Geometry: None<br> Feature Count: 1827<br> Layer SRS WKT:[...]<br> MODULE: String (8.0)<br> TLID: Integer (10.0) <---- links back to CompleteChain<br> RTSQ: Integer (3.0)<br> [...]<br> <br> Layer name: Landmarks<br> Geometry: Point<br> Feature Count: 448<br> Extent: (-107.119811, 34.889113) - (-106.232580, 35.205106)<br> Layer SRS WKT:<br> GEOGCS["NAD83",<br> DATUM["North_American_Datum_1983",<br> SPHEROID["GRS 1980",6378137,298.257222101]],<br> PRIMEM["Greenwich",0],<br> UNIT["degree",0.0174532925199433]]<br> MODULE: String (8.0)<br> FILE: Integer (5.0)<br> LAND: Integer (10.0) <------ linking column to AreaLandmarks<br> SOURCE: String (1.0)<br> CFCC: String (3.0)<br> LANAME: String (30.0)<br> LALONG: Integer (10.0)<br> LALAT: Integer (9.0)<br> FILLER: String (1.0)<br> <br> Layer name: AreaLandmarks<br> Geometry: None<br> Feature Count: 1292<br> Layer SRS WKT:<br> GEOGCS["NAD83",<br> DATUM["North_American_Datum_1983",<br> SPHEROID["GRS 1980",6378137,298.257222101]],<br> PRIMEM["Greenwich",0],<br> UNIT["degree",0.0174532925199433]]<br> MODULE: String (8.0)<br> FILE: String (5.0)<br> STATE: Integer (2.0)<br> COUNTY: Integer (3.0)<br> CENID: String (5.0)<br> POLYID: Integer (10.0) <----- Linking column to PIP<br> LAND: Integer (10.0) <----- Linking column to Landmarks<br> <br> Layer name: Polygon<br> Geometry: None<br> Feature Count: 18597<br> Layer SRS WKT:<br> GEOGCS["NAD83",<br> DATUM["North_American_Datum_1983",<br> SPHEROID["GRS 1980",6378137,298.257222101]],<br> PRIMEM["Greenwich",0],<br> UNIT["degree",0.0174532925199433]]<br> MODULE: String (8.0)<br> FILE: Integer (5.0)<br> CENID: String (5.0)<br> POLYID: Integer (10.0) <------ Linking column to PIP<br> [tons more attributes]<br> <br> [... a whole lot more "Geometry: none" tables irrelevant to the point...]<br> <br> Layer name: PIP<br> Geometry: Point<br> Feature Count: 18597<br> Extent: (-107.188495, 34.870089) - (-106.149778, 35.218201)<br> Layer SRS WKT:<br> GEOGCS["NAD83",<br> DATUM["North_American_Datum_1983",<br> SPHEROID["GRS 1980",6378137,298.257222101]],<br> PRIMEM["Greenwich",0],<br> UNIT["degree",0.0174532925199433]]<br> MODULE: String (8.0)<br> FILE: Integer (5.0)<br> CENID: String (5.0)<br> POLYID: Integer (10.0) <---- linking column to a bunch of others.<br> POLYLONG: Integer (10.0)<br> POLYLAT: Integer (9.0)<br> WATER: Integer (1.0)<br> <br> This is an intertwined MESS of data, and none of the intertwining is done<br> through OGR.<br> <br> By issuing the original v.in.ogr command:<br> <br> v.in.ogr dsn=~/TIGER/BC_TGR layer=CompleteChain,PIP output=t56015_all \<br> type=boundary,centroid snap=-1<br> <br> (as taken directly from the v.in.ogr man page) I pulled in the linear<br> features (CompleteChain, which includes all the boundaris and<br> non-boundary features) and centroids (PolygonInternalPoint, PIP) with<br> their associated attributes *from their own tables*. But as I<br> mentioned, TIGER is more of a database in normal form, so there are<br> all sorts of interlinked tables with common keys. v.in.ogr (and OGR<br> itself) does not follow the links, so it's up to me to get them linked<br> up somehow.<br> <br> > Now GRASS layers. A disclaimer from me: I think that "layer" is a confusing<br> > term to use here.<br> <br> No argument here. I hate that the word "layer" is used in about three<br> incompatible ways: to denote a vector coverage (as it's used in most<br> GIS literature), as one of a set of tables linked to a vector coverage<br> (in GRASS), and as either a table or a vector element of a collection<br> of tables and vectors (in OGR).<br> <br> > Each vector file (and<br> > object) can have more than one key field to link it to an attribute table.<br> > These key fields are called "cat" (short for category) and are always<br> > integer. So, a vector can have different integer keys attached to a single<br> > object. But instead of calling these cat1, cat2, etc, they are called '<br> > cat in layer 1', 'cat in layer 2', etc. Each key (AKA 'cat in layer #') can<br> > link to a line/record in an attribute table (which also must have an<br> > identical integer key field, that doesn't HAVE to be called "cat", but<br> > often is).<br> <br> I understand that part. What I am not understanding is how to get the right<br> categories to attach to the right elements of these extra database columns.<br> <br> Here's a concrete example. The TIGER/Line file for this can be<br> downloaded (sometime before 2 days are up) from this temporary FTP<br> site: <a href="ftp://ftp.swcp.com/pub/tmp/russo/TGR35001.ZIP">ftp://ftp.swcp.com/pub/tmp/russo/TGR35001.ZIP</a>. The file unzips<br> to all the various records files, and if unpacked into its own<br> directory can be imported into a latitude/longitude GRASS location<br> with the sort of v.in.ogr command I gave above.<br> <br> This TIGER/Line collection has a table with no associated geometry,<br> Landmarks, that has an entry (from ogrinfo -al output):<br> <br> OGRFeature(Landmarks):15<br> MODULE (String) = TGR35001<br> FILE (Integer) = 35001<br> LAND (Integer) = 15<br> SOURCE (String) = J<br> CFCC (String) = D10<br> LANAME (String) = Kirtland Air Force Base<br> LALONG (Integer) = (null)<br> LALAT (Integer) = (null)<br> FILLER (String) = (null)<br> <br> There are a number of rows in the AreaLandmarks table that relate back to<br> this single record through the LAND attribute:<br> <br> OGRFeature(AreaLandmarks):154<br> MODULE (String) = TGR35001<br> FILE (String) = 35001<br> STATE (Integer) = 35<br> COUNTY (Integer) = 1<br> CENID (String) = c4588<br> POLYID (Integer) = 18750<br> LAND (Integer) = 15<br> <br> OGRFeature(AreaLandmarks):155<br> MODULE (String) = TGR35001<br> FILE (String) = 35001<br> STATE (Integer) = 35<br> COUNTY (Integer) = 1<br> CENID (String) = c4588<br> POLYID (Integer) = 18749<br> LAND (Integer) = 15<br> [lots more]<br> <br> that relate back to PIP records through the POLYID field. Those PIP records<br> are:<br> <br> OGRFeature(PIP):18594<br> MODULE (String) = TGR35001<br> FILE (Integer) = 35001<br> CENID (String) = c4588<br> POLYID (Integer) = 18750<br> POLYLONG (Integer) = -106551831<br> POLYLAT (Integer) = 35060558<br> WATER (Integer) = (null)<br> POINT (-106.551831000000007 35.060558)<br> <br> OGRFeature(PIP):18593<br> MODULE (String) = TGR35001<br> FILE (Integer) = 35001<br> CENID (String) = c4588<br> POLYID (Integer) = 18749<br> POLYLONG (Integer) = -106546870<br> POLYLAT (Integer) = 35049120<br> WATER (Integer) = (null)<br> POINT (-106.546869999999998 35.049120000000002)<br> <br> [etc.]<br> <br> and these PIP records are properly attached to centroids in my GRASS vector:<br> <br> > v.info -c layer=2 map=t35001_all<br> Displaying column types/names for database connection of layer 2:<br> INTEGER|cat<br> TEXT|MODULE<br> INTEGER|FILE<br> TEXT|CENID<br> INTEGER|POLYID<br> INTEGER|POLYLONG<br> INTEGER|POLYLAT<br> INTEGER|WATER<br> <br> so somewhere there is a centroid with some category number that has<br> POLYID 18749, which ultimately could be associated with AreaLandmark<br> feature 155 and thence (through LAND attribute 15) to Landmark feature 15 and<br> the name "Kirtland Air Force Base"<br> <br> What I *want* to accomplish is to produce something that I can display<br> and query that represents the collection of AreaLandmarks, which is a<br> subset of the areas initially imported. I should be able to do a<br> "d.vect somevector layer=somelayer" and see only those polygons that<br> have AreaLandmarks attributes, and be able to use d.what.vect to click<br> on those polygons and get the attributes (presumably I'd do a table<br> join between the AreaLandmarks table and Landmarks table so that<br> things like the landmark's name and feature type are all in one table<br> not two).<br> <br> My assumption is that the key concept I am missing is that there must<br> be a way to select, based on records of AreaLandmarks, a subset of<br> vector elements from the full imported collection of areas (whose<br> POLYID attribute is already stored in the table attached to Layer 2 of the<br> vector), assign them new categories for a layer 3, relate those new<br> categories to rows of the AreaLandmarks table, and finally attach the<br> AreaLandmarks table to the new layer through its category values.<br> <br> So my question is how do I do that?<br> <br> <br> I imagine there's some way to do an extraction with v.extract and a<br> where clause to create a vector of only those areas with POLID<br> attributes that appear in the AreaLandmarks table... I hadn't thought<br> about that yet. I'm not sure I can craft the WHERE clause for<br> v.extract that would reference a table that isn't attached to the<br> vector yet, though.<br> <br> > However, once you get the data into GRASS, it is <br> >possible to "upload" data from one attribute table (linked to layer 2, <br> >for example) into another attribute table (linked to layer 1, for <br> >example).<br> <br> I'm sure it's possible, but I still don't understand how to do it in this case.<br> <br> --<br> Tom Russo KM5VY SAR502 DM64ux <a href="http://www.swcp.com/~russo/">http://www.swcp.com/~russo/</a><br> Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1 <a href="http://kevan.org/brain.cgi?DDTNM">http://kevan.org/brain.cgi?DDTNM</a><br> "And, isn't sanity really just a one-trick pony anyway? I mean all you get is<br> one trick, rational thinking, but when you're good and crazy, oooh, oooh,<br> oooh, the sky is the limit!" --- The Tick<br> </font> </p> </div> </blockquote></div><br></div></body></html>