[GRASS-user] Help: Completely confused about multi-layered
vectors trying to import TIGER/Line files
Dylan Beaudette
dylan.beaudette at gmail.com
Thu Feb 28 10:57:48 EST 2008
On Thu, Feb 28, 2008 at 7:39 AM, Tom Russo <russo at bogodyn.org> wrote:
> 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.
>
> Thing is, TIGER data has almost no usable attributes in the PIP layer itself
> --- this is nothing more than a centroid with an attribute "POLYID", telling
> nothing about the area. To get that information, one needs additional tables
> linked to the POLYID field. The TIGER data tries to be a normal form database,
> so there are many tables with no geometry that relate back to linking fields
> in the attribute tables that are attached to geometry.
>
> There's another table in the TIGER data called "Polygon" that has more
> attributes related to the census, such as congressional district and such.
> Actual names and types of areas (parks, military installations, etc) are
> linked through two tables, AreaLandmarks and Landmarks --- the first links
> POLYID to a LAND attribute (an integer) and the second links the LAND
> attribute to an actual name --- there is a many-to-one relationship between
> AreaLandmarks and Landmarks. The latter table actually contains the feature
> class code that tells you what type of landmark the polygon represents. Not
> every polygon has a matching record in AreaLandmarks, only those that actually
> represent landmarks. The other polygons are just administrative regions or
> other artificial areas. On top of that, there appear to be some records of
> Landmarks that do NOT have any connection to records in AreaLandmarks -- these
> are point landmarks, and so the Landmarks layer of the TIGER data also has
> point geometry. Where there is a relationship between Landmarks and
> AreaLandmarks I suppose the Landmark point would be usable as a label point.
>
> Attaching the "Polygon" records to the centroids seems an easy problem, as
> every centroid has a Polygon record with attributes, and all that's needed
> is a table join on the POLYID field between the table already attached to the
> centroids and the Polygon table imported with db.in.ogr. I can do that.
>
> The AreaLandmarks are another matter --- only a small fraction of the
> polygons have associated AreaLandmarks. For example, in the TIGER/Line data
> for Bernalillo County, New Mexico, there are 18597 PIP and Polygon records,
> but only 1292 AreaLandmarks records. This makes it seem to me that
> AreaLandmarks would be a prime candidate for a third "layer" in the
> "t35001_all" vector. My problem is selecting the geometric objects to tie to
> the records of the AreaLandmarks table.
>
> I have tried a number of naive things that didn't work. First, I tried to
> add a "cat" field to the AreaLandmarks table, then use an SQL UPDATE query
> to copy the cat column of the table associated with the PIP records (which
> gets called "t35001_all_2" by the v.in.ogr import) that have POLYIDs that
> match the ones in the AreaLandmarks:
>
> echo "UPDATE t35001_AreaLandmarks SET cat=(SELECT cat FROM t35001_all_2 WHERE t35001_all_2.POLYID=t35001_AreaLandmarks.POLYID)" | db.execute
>
> and then adding AreaLandmarks as a third database connection. That SQL
> update worked fine in the sense that the AreaLandmarks table got the right
> cat values out of the layer 2 table, but the approach didn't work, because
> as far as I understand it the categories of objects in layer 2 haven't
> actually been assigned to geometric objects for layer 3 yet, so linking this
> way is meaningless at this step. Attaching the table gives me some warnings,
> and apparently attaches no database records to any geometry at all.
>
> So then I tried creating a new reclassified vector with
>
> v.reclass in=t35001_all out=foo col=POLYID layer=2 type=centroid
>
> setting the categories of layer 2 in the new vector to be equal to the POLYID
> of layer 2 in the old vector without copying the table, then doing:
>
> echo "UPDATE t35001_AreaLandmarks SET cat=POLYID" | db.execute
>
> and attaching that table to layer 2 of the reclassified vector. This sorta
> kinda worked, in that the AreaLandmarks records were attached to features
> properly, but left a very large fraction of the features without database
> connections. So I could display vector "foo" and use d.what.vect to query
> my new attributes, but there were 17305 polygons out of 18597 that I could
> click and get a warning of a missing database entry --- I would rather have
> only the polygons that have an AreaLandmarks record show up at all when
> displaying this layer.
>
Hi Tom,
TIGER data (in its current format) is a beast to work with-- in any
GIS. I have found that the simplest way to get "normal" looking data
out of the TIGER files was with the tutorial on processing these data
using PostGIS [1]. There are excellent instructions on the GeoServer
page [1] that make use of basic PostGIS functionality, along with some
self-contained java utilities. Following those instructions I was able
to get *most* of the point, line, and polygon data (with meaningful
attributes) extracted to simple tables in PostGIS. It would be a
simple matter to export to GRASS from there.
I think that you can get 2000 TIGER data, by county, from our favorite
'leading GIS vendor' for free [2]. That format should be simpler to
use.
There is also tiger2shp [3] which is now distributed for free (Windows).
Finally, it looks like the US Census will be moving away from the
current data format, and will be henceforth distributing their data as
shapefiles [4]. Hurray!
1. http://geoserver.org/display/GEOSDOC/Loading+TIGER+data
2. http://www.esri.com/data/download/census2000_tigerline/index.html
3. http://tnatlas.geog.utk.edu/downloadfree.htm
4. http://www.census.gov/geo/www/tiger/future/future_tl.html
> Since I'm rambling now, I'll just cut to the chase and ask my question:
>
> Given a GRASS vector with two attached database tables, one of which (layer
> 2, attaching attributes to centrois) has a key field POLYID, how can I create
> a new layer using a third, much smaller table, that also has a POLYID field,
> such that the new layer only contains that subset of centroids where the
> third layer table's POLYID matches layer 2's POLYID for that centroid?
>
> At some later point I'll worry about the Landmarks point layer and its
> associated attributes, after I've figured out what the story is with
> connecting the AreaLandmarks to the subset of centroids.
>
> I am convinced that if I truly understood how layers work in GRASS then my
> question's answer would be self-evident, but I also know that "if A then B"
> is a true statement when both A and B are false. I have been completely
> unable to piece together a thorough (or even marginal) understanding from man
> pages and even the third edition "Open Source GIS: A GRASS GIS Approach"
> book. Any help anyone can give me would be greatly appreciated.
I cannot offer any insight into the GRASS vector/layers system right
now, but there are several good threads from a couple of months ago on
this very topic (vector/layers/confusion).
Good luck,
Dylan
> --
> Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/
> Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
> "And, isn't sanity really just a one-trick pony anyway? I mean all you get is
> one trick, rational thinking, but when you're good and crazy, oooh, oooh,
> oooh, the sky is the limit!" --- The Tick
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
More information about the grass-user
mailing list