[postgis-users] TIGER/Line Shapefiles released
Jonathan W. Lowe
jlowe at giswebsite.com
Fri Apr 4 06:00:13 PDT 2008
On Fri, 2008-04-04 at 14:52 +0300, Nick Black wrote:
> On Fri, Apr 4, 2008 at 11:01 AM, Jonathan W. Lowe <jlowe at giswebsite.com> wrote:
> > On Thu, 2008-04-03 at 20:31 -0400, Stephen Frost wrote:
> > > Jonathan,
> > >
> > > * Jonathan W. Lowe (jlowe at giswebsite.com) 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..)
> >
> > I haven't yet confirmed whether the 2007 version of Census Blocks
> > maintains a 1:1 match with the associated statistics in SF1, so was
> > starting with the 2000 version. However, positionally, the two Census
> > Block versions (tabblock00 and tabblock) are identical. And they both
> > positionally match the single 2007 edges data. (I've added a third
> > screen shot to www.giswebsite.com/demos/tiger_overlays.html to
> > illustrate.)
> >
> > Has anyone else seen the same misalignment between TIGER (2007 and/or
> > 2000) when overlaying on other datasets?
> >
> > It's still a mystery how OpenStreetMap's tiles for Berkeley, which are
> > based on TIGER, don't seem to duplicate the zig-zag qualities of the
> > edges data I've downloaded from TIGER 2007.
>
>
> The TIGER data in OSM has been corrected, which is why it is more
> accurate than the 2007 TIGER data.
>
> The roads seen in this view:
>
> http://openstreetmap.org/?lat=37.86537&lon=-122.26671&zoom=16
>
> have been edited by OSM users Speight and David Muir Sharnoff since
> TIGER was imported a few months ago. Maybe next time the Census
> bureau will be able to rely on OSM ;-)
Thanks, Nick, and congrats on the recent funding! Do you mean that ALL
the roads seen in that view (in other words, all the TIGER data for that
section of South Berkeley, has been edited by Speight and Sharnoff since
January? If just a subset, is there a way to view the change locations
graphically?
Unfortunately, since OSM captures mainly physically visible features,
the invisible TIGER boundaries representing census data collection are
now orphaned in their inaccurate state unless the same edits can be
reapplied to the census block geometries or unless edited OSM TIGER data
can be used to (re)derive census block boundaries.
> Something is definitely
> > missing in the puzzle, but it doesn't sound like the issue is with the
> > PostGIS conversion part of the process, so, thanks for the help to this
> > point -- I'll check with the OpenStreetMap community next.
> >
> >
> >
> > >
> > > 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 (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
> > > >
> > > > _______________________________________________
> > > > 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
> >
>
>
>
More information about the postgis-users
mailing list