Ah, I've tried to deal with this same entrance before, Glassman! It's somehow reassuring that I wasn't overlooking something obvious. The syntax FK270673 describes makes sense to me at first glance and certainly conveys sufficient information to accurately describe the situation.

Ah, I've tried to deal with this same entrance before, Glassman! It's somehow reassuring that I wasn't overlooking something obvious. The syntax FK270673 describes makes sense to me at first glance and certainly conveys sufficient information to accurately describe the situation.

Welcome! Hope you have lots of fun!

Have you looked at using the National Elevation Dataset instead of SRTM data? There are no gaps in coverage across CONUS, AK, and HI, It's available in 1/3rd arcsec for most of the US (1/9th for ~10% of the US), and it is quality controlled and frequently updated. In fact, they updated tiles covering about 10% of the US this past December, 6% in February, and another 11% this April!

It is a USGS publication, compiled from USGS and other US Government Publications (including SRTM in parts of AK), so it should be fine for any OSM use.

For most of the US, there's no need to rely on the old, low-res yahoo imagery, as the USGS makes a wide variety of recent, 1 meter or better imagery available over WMS, all products of the US Gov. and totally usable for OSM purposes. For example, Seattle and most of western Washington are available at .3m resolution in imagery taken May 2009.

I've been putting off writing a diary/guide about how to get it going, but I this yahoo outage is a good reason to get off my butt and do it.

I think that the solution to this lies in QA efforts that focus on the end product - routes - and not the data. The 250 Cities Project was an example of this sort of approach:

http://wiki.openstreetmap.org/wiki/TIGER_fixup/250_cities#Maps

But this is of course just the start of the possibilities. 250 Cities used a blanket approach looking for high ratios of Route Length to Geographic Distance; altering this just slightly to take into account scaling effects, terrain effects, population density effects, and street-layout style effects and adjust the ratio thresholds should make it possible to extend the 250 Cities effort to a 1000 Cities, 1000 Routes project -- fix the intercity grid for the 1000 largest cities in the US and fix 1000 Routes within each city prioritized by population density. This is a big project, but is tractable if an effort and be coordinated and sustained for a decent amount of time.

Another approach that should come online is comparing calculated routes to the OSM .gpx database with a blended heuristic/trained probabilistic filter interposed. This could be a significant source of routing data, especially if we can port the Waze source (http://world.waze.com/wiki/index.php/Source_code) to draw from and report to OSM rather than Waze's databases. This approach can be especially helpful in detecting plausibly-short but illegal routes (missed turn restrictions, one-ways, etc.) and in detecting new routes as they are created through construction.

Further, the existing QA tools such as KeepRight should incorporate or be integrated into planning/coordination/progress tracking tools that allow estimation of work remaining and visualization of progress made on definable sub-tasks (no duplicate nodes within a certain county, for example). This has featured prominently in the 250 cities project and the various duplicate nodes projects, for example, and really helps drive participation.

So -- let's do this! :)

Great news! Just wanted to leave a note of encouragement -- getting data into OSM is really the easy part; building visualizations and other access methods is a whole other story and your work in that direction is inspiring and beautiful.

Thanks!

Another way to approach this, in addition to encouraging use of error-checking tools like http://keepright.ipax.at, is to make sure that the tools that people use to map encourage the practices that result in good topology. Just a simple check for unconnected ways as they are created and a quick, easy to dismiss pop-up message explaining OSM topology practices in potlatch would go a long way!

I know I was confused about this at first :) Then I learned to love the 'm' and 'j' keys in JOSM :P

Tomash -- generally if the TIGER data shows a boundary along a road or stream, the boundary falls in the middle of that road or stream _as they exist in reality_, not as they exist in the TIGER database. Perhaps the best approach to to add the segment of the road or stream that the the boundary follows to a relation defining the boundary. This way you don't have to worry about pinning the two ways together, and as the road or stream gets updated to a (presumably more accurate) alignment, the boundary will get the upgrades as well.

There's active discussion about whether to do this with a relation of type=boundary or as a type=multipolygon with a boundary=administrative key:

http://wiki.openstreetmap.org/wiki/Talk:Relation:boundary#Use_type.3Dmultipolygon_instead

After quite a bit of consideration, I believe I come down on the type=multipolygon side of the discussion, but in either case it's better than trying to keep boundaries and the underlying ways the follow synchronized!

Well, one way that OSM is so great is that we can fix this routing problem right now! The pedestrian section that forms the center of La Rambla really isn't connected to anything -- neither the streets that flank it or adjoining streets from the side. Thus the routing engine can't find pedestrian routes that cross it!

I think the best thing to do here is to replace the area tagged as highway=pedestrian with a line tagged the same (plus tag the width). Then connect footways from adjoining streets where crossings exist et voila!