...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 ([EMAIL PROTECTED]) 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 ([EMAIL PROTECTED]) 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@postgis.refractions.net
> > > > http://postgis.refractions.net/mailman/listinfo/postgis-users
> > >
> > > _______________________________________________
> > > postgis-users mailing list
> > > postgis-users@postgis.refractions.net
> > > http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
