[postgis-users] TIGER/Line Shapefiles released

Thu Apr 3 17:27:48 PDT 2008

...And in case the images don't persist through the mail server, they're
viewable at:  http://www.giswebsite.com/demos/tiger_overlays.html

On Fri, 2008-04-04 at 01:07 +0100, Jonathan W. Lowe wrote:
> Stephen,
> 
> My initial testing has been on Alameda County (California) TIGER data.
> The two attached image files show an overlay of US Census 2000 Blocks
> over an area south of the UC Berkeley campus.  The offset is the same
> for both Google and OpenStreetMap (OSM).  This suggests that I've made a
> mistake somewhere, because the OSM tiles in the United States are all
> rendered from TIGER linework, so the TIGER census blocks should match
> exactly.
> 
> For the same source shapefile (tabblock00.shp), there's a nearly perfect
> match between block boundaries and streets in the area just South of
> Oakland's Lake Merritt.  It smells like a datum conversion issue...
> 
> The conversion path was from shapefile to PostGIS using shp2pgsql.  I
> used a custom projection of 32767 rather than 4269 because the existing
> srtext for 4269 had a degree value as 0.01745329251994328, but the US
> Census metadata listed a degree value of 0.017453292519943295.  Perhaps
> not significant?  My spatial_ref_sys entries for 4269 and 32767 are
> otherwise pretty similar:
> 
> SRID: 4269
> SRTEXT: GEOGCS["NAD83",DATUM["North_American_Datum_1983",
> 	SPHEROID["GRS 1980",6378137,298.257222101,
> 		AUTHORITY["EPSG","7019"]],
> 		AUTHORITY["EPSG","6269"]],
> 	PRIMEM["Greenwich",0,
> 		AUTHORITY["EPSG","8901"]],
> 	UNIT["degree",0.01745329251994328,
> 		AUTHORITY["EPSG","9122"]],
> 		AUTHORITY["EPSG","4269"]]
> PROJ4TEXT: +proj=longlat +ellps=GRS80 +datum=NAD83 +no_defs
> 
> SRID: 32767 
> SRTEXT: GEOGCS["GCS_North_American_1983",
> 	DATUM["D_North_American_1983",
> 	SPHEROID["GRS_1980",6378137,298.257222101]],
> 	PRIMEM["Greenwich",0],
> 	UNIT["Degree",0.017453292519943295]]
> PROJ4TEXT: +proj=longlat +ellps=clrk66 +datum=NAD27 +no_defs
> 
> To display census block data in OpenStreetMap, I extract it from PostGIS
> with a transform to EPSG 4326, although the coordinates don't seem to
> change as a result.  (This seems correct, as datum=NAD83 and datum=WGS84
> are, for my purposes at least, are essentially identical.)
> 
> Thanks,
> Jonathan
> 
> 2 attachments:  TIGER2007andOSM.png, TIGER2007andGoogle.png
> 
> 
> On Thu, 2008-04-03 at 19:18 -0400, Stephen Frost wrote:
> > Jonathan,
> > 
> > * Jonathan W. Lowe (jlowe at giswebsite.com) wrote:
> > > Have you yet tried overlaying TIGER 2007 linework or census block/tract
> > > polygons over Google or OpenStreetMap tiles?  I'm seeing a good match in
> > > some areas but a significant shift (~50 meters) in others.  Thought it
> > > might be a datum conversion issue, but can't seem to find a match.
> > 
> > I hadn't looked at the linework too much yet or tried to overlay it.
> > I'm curious where you're seeing the differences though because I know
> > that Census is only about half way through their MAF improvment project
> > and I actually have some info about what has been done so far and what
> > hasn't.  It'd be interesting to see if it matches up.
> > 
> > There are a few places (Guam, Hawaii islands) where they actually do use
> > an SRID other than 4269, but my scripts don't yet handle that and I'm
> > guessing that's not what you're referring to anyway. :)
> > 
> > 	Thanks!
> > 
> > 		Stephen
> > 
> > > On Thu, 2008-04-03 at 17:07 -0400, Stephen Frost wrote:
> > > > * Stephen Frost (sfrost at snowman.net) wrote:
> > > > > I think they may have also upgraded their pipe..  I got about 1.41MB/s
> > > > > (11 Mb/s) for the whole transfer.  It's about 22G all told.  I'll
> > > > > probably be trying to load it up into PG on one of our servers tomorrow.
> > > > > It was a bit over 4 hours for me to pull down off of their
> > > > > ftp2.census.gov ftp site.
> > > > 
> > > > Just to update those who might be interested- I've finished the data
> > > > load into one of our servers at work.  It comes to ~60GB on disk in
> > > > PostgreSQL/PostGIS with appropriate indexes in most places and whatnot.
> > > > Based on what I've seen so far, it looks *very* nice, especially the
> > > > hydrogrophy ("areawater").  It also appears to be pretty consistant
> > > > across the layers, which is also good.
> > > > 
> > > > If anyone's interested in the scripts used to load the data (they're
> > > > pretty simple, really), I'd be happy to provide them.
> > > > 
> > > > 	Enjoy,
> > > > 
> > > > 		Stephen
> > > > _______________________________________________
> > > > postgis-users mailing list
> > > > postgis-users at postgis.refractions.net
> > > > http://postgis.refractions.net/mailman/listinfo/postgis-users
> > > 
> > > _______________________________________________
> > > postgis-users mailing list
> > > postgis-users at postgis.refractions.net
> > > http://postgis.refractions.net/mailman/listinfo/postgis-users