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.)
|
