I'm more or less doing hypsometric coloring, too. The lowest layer of my rendering is a relief-colored image based on the same data as the hillshading. The colors I'm using are pretty subtle, though. See my previous diary entry for some examples of the different colors that can show up.

Basically, since I'm doing very gradual color changes, there's practically no difference between NED and SRTM colors for my current rendering.

According to the USGS, the NED data comes from a variety of sources, including SRTM (where there's nothing better, presumably).

However, the USGS also has aerial photography for much of the US that's often higher resolution than Yahoo's. They have WMS capability URLs at http://seamless.usgs.gov/wms_services.php?layerid=15 . Note that while any data produced by the USGS is public domain (since they're part of the US federal government), some of the aerial photography in their WMS layers has been produced by others and is licensed to the USGS. In the WMS capabilities, the licensed layers are marked as "VIEW ONLY"; we can't use those in OSM.

Having the hillshading in an overlay would be nice (it would shade the roads, too, which would increase the illusion of depth), but I'm primarily rendering for use on my phone, and the program I'm using (MapTool for WebOS) only supports a single tile layer.

I know I could interpolate more pixels into the SRTM data with gdal_translate, but it ends up taking up significantly more disk space. I already don't have enough space to do hillshading for the entire US, so I only get the pretty underlays for the east coast at the moment.

It might be something with the ordering of trunk bridge rendering. I've seen a similar bug at osm.org/go/ZZd8tnZu , where the trunk bridge is the highest of the three bridge layers. I haven't spent time figuring out what causes the bug yet, though.

Ah, that makes sense. I was using a 4,2 dasharray, so there wasn't room for the gaps to show up.

Interestingly, that means I could make a line of circles if I wanted to.

Thanks for pointing that out!

Hmm. Mapnik 2 sounds like it'll have a number of features I could really use, ones that I was planning on working around by having a script that generated some rules based on database queries. migurski's convinced me to stick with cascadenik (since complicated stylesheets seem to be feasible with it, and I really hate having to repeat myself, especially when experimentally changing rules).

migurski, that query is really interesting. I assume the !BBOX! gets filled in by mapnik when it actually runs the query. The way collection is very interesting. (I'm still learning how all of this works together, so I didn't know about ST_Collect() or that Mapnik would work with MULTILINE geometries.) I suppose I could just try this (but I'd have to rework a bunch of rules first), but I initially tried using Cascadenik's outline symbolizer for bridges (with the thought that I might be able to skip the casing pass in a lot of cases), but when I had a divided highway at lower zoom levels, the second way's rendering drew its bridge outline on top of the first way. Am I correct in surmising that grouping the ways in a tile together like you have would avoid that artifact (because the outlines for both ways would be drawn together, followed by the main lines)?

That's a reasonable set of criteria. I tend to go with the US Highway Functional Classification System ( osm.wiki/Highway_Functional_Classification_System ) for tagging primary/secondary/tertiary/unclassified. So the designation of who maintains the road is less important than how the road functions: non-motorway/trunk roads that are central to moving traffic between regions are primary, roads that feed traffic into the primaries are secondary, and roads that feed traffic into the secondaries are tertiary. Anything for local traffic (i.e. not used as a through street) is residential if it's used for accessing residences in an urban/suburban setting, and unclassified otherwise (rural, or used for accessing business/industry in an urban setting).

Unfortunately, there's not really a "correct" set of rules. A lot of the classification is fuzzy, so take a look at what other people have done in your area, if possible (don't blindly trust the classifications from the TIGER import; they're often reasonable but not always best).

I think I found the roundabout. Was it in front of the ECDC building? I restored it. If it's one-way (which it probably is, but I didn't want to assume), please make sure it points the right way and mark it oneway. I also straightened up the nearby hospital and a few other buildings.

If you feel like downloading an editing program, I suggest JOSM. It has several builtin functions for making things prefectly circular (I used that on the roundabout) and for straightening buildings so they only have right angles (I used that on the hospital). Potlach is great for quick edits, but more detailed changes are a lot easier with JOSM.