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? 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 "Boy Genius".) > > Regards, _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
