[OSM-talk] OSM TIGER-based map quality

Christopher Schmidt crschmidt at metacarta.com
Fri Apr 4 14:12:48 BST 2008


On Fri, Apr 04, 2008 at 01:53:24PM +0100, Jonathan W. Lowe wrote:
> 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
> > http://crschmidt.net/osm/history.html?type=way&id=21456366)
> 
> 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?

That is exactly what I am suggesting, based on an examination of the
objects in the area you're looking at: all of them have been updated
several times (as the history URL above demonstrates) by a single user
in what seems to clearly be a cleanup effort. (This was based on using
an OpenLayers map to select 10 different streets based on the lonlat I
observed in your JOSM instance and view the history for each.)

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

No: what you're encountering is TIGER misalignment with reality. OSM is
much closer to reality in this instance than TIGER.

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

Right. Because TIGER is wrong :)

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

That is correct.

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

I would have expected it to be more significant by a factor of about
two, from observation, but I could be mis-guessing the scale here: I'm
used to working in Cambridge, rather than SF. In any case, the
misalignment is just a standard misalignment of TIGER data to reality:
OSM is much closer to reality, despite the initial import being from
TIGER.

> > 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
> "Boy Genius".)

I'm now "Meta Ninja", since I have to manage other ninjas, and Leslie
Hawthorn (Summer of Code organizer) told me I was too old, at 23, to be
a Boy Genius anymore. :)

Regards,
-- 
Christopher Schmidt
MetaCarta




More information about the talk mailing list