Jonathan, * Jonathan W. Lowe ([EMAIL PROTECTED]) wrote: > ...And in case the images don't persist through the mail server, they're > viewable at: http://www.giswebsite.com/demos/tiger_overlays.html
You know, I just realized that you were talking about the Census 2000
blocks (tabblock00.shp). Is there some reason you're using that
instead of the current data (tabblock.shp)? They might not want to
update the data from 2000 for historical reasons...
(Note: I havn't actually gone and looked, it just occured to me..)
Thanks,
Stephen
> 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
signature.asc
Description: Digital signature
_______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
