[OSM-talk] OSM TIGER-based map quality
Jonathan W. Lowe
jlowe at giswebsite.com
Fri Apr 4 13:53:24 BST 2008
On Fri, 2008-04-04 at 07:05 -0400, Christopher Schmidt wrote:
> On Fri, Apr 04, 2008 at 08:29:56AM +0000, Jonathan W. Lowe wrote:
> > When overlaying OSM with the recently available TIGER 2007 shapefile
> > data for Census Blocks in Alameda County (California), I'm encountering
> > both an offset and difference in relative position of the linework. In
> > short, OSM's data looks a lot more accurate and consistent -- streets
> > that should be straight actually look straight in OSM, but often zig-zag
> > in the TIGER 2007 edges and tabblock shapefiles. For a visual, visit:
> > http://www.giswebsite.com/demos/tiger_overlays.html
> Um, isn't this the whole point of OSM? The TIGER data was imported so
> that it could be improved manually by users. This doesn't include just
> the geometry either: attributes have been changed as well. (See
Thanks, Chris -- are you suggesting that the TIGER 2007 reissue from the
US Census is not lining up with OSM in some (rather extensive) areas
because the geometry in those areas has been completely improved
manually since the upload of TIGER completed earlier this year. Yes,
obviously, such a major improvement in accuracy from manual attention is
one of the (many) wonderful benefits of OSM -- I guess I'm just
surprised that so much manual editing could have been accomplished for
such an extensive area given the short time TIGER has been available for
editing in OSM. Is there any existing interface for visualizing which
features have changed in OSM for a given area?
If that is indeed the case, since the Census Blocks come from the same
topologic source as the streets do, I wonder if there's any existing
routine that would enable me to run the same edits on the Census Blocks
geometries, or use the OSM streets to derive Census Block boundaries and
then conflate the Block identifiers. Thinking out loud here...
> > Any observations or ideas about where the misalignment might come from?
> This misalignment is common in TIGER: It's designed for 1:100000
> accuracy. Anything more than that (you're at about 1:7500 there) is not
> going to be accurate. (Or at least likely to not be.)
I may not be communicating the scenario clearly enough -- TIGER
misalignment is common with other non-TIGER data certainly, but TIGER
data is not misaligned with other TIGER data of the same issue. I'm
encountering what I thought was the latter case.
TIGER data models both visible physical features such as streets, but
also invisible census data collection boundaries such as blocks and
tracts. The block and tract boundaries and the street centerlines are
derived from the same single topologic source, so when viewed together,
line up perfectly unless one or the other has been altered independently
since original release. The 2007 shapefile issue confirms this --
linestrings in the "edges" shapefile perfectly match the polygon
boundaries in the "tabblock" shapefile. But neither match the OSM
geometry, at least using the conversion and display methods I've used
within Berkeley's geographic extents. Since all the data has the same
parentage, I initially thought there would be a tighter match between
TIGER 2007 and OSM TIGER, but not if the editing to OSM TIGER has been
as extensive as you seem to be suggesting.
> > Though it smells partially like a datum problem, that path hasn't
> > yielded any solutions yet.
> Doubtful. You'd have a more significant shift.
Experimenting with NAD27 to NAD83 conversions actually produces a
similar shift, depending on the region. But I agree -- it seems to be
something else. Hm.
> This is the real power of OSM at work. See it, and marvel in its glory.
Yes, marvelous it most certainly is. I currently use OSM (via an
OpenLayers client) with multiple existing customers and have supported
the whole ethos of open-source in published articles, starting with one
on PostGIS, since 2001, so am no stranger to the glory. (You and I met,
Chris, at FOSS4G2006 in Switzerland, where you introduced yourself as
More information about the talk