The email you link to says the exact opposite of your small text--NearMap-derived OSM contributions made before June 17th will *not* be removed from the ODbL OSM data (assuming you have also agreed to the ODbL+CTs).

I plan on updating the wiki, once I've got my tileset available for general use. (I'm currently working with my hosting company to see what parts of the rendering chain they're willing to install and which ones I need to set up and maintain myself.)

Personally, I'm not too concerned about this.

First off, OSM data can be used (and is being used right now) to fill the coffers of commercial organizations. If you disagree with that, I can't argue with it, but there's no difference there between the current state of affairs and a hypothetical dissolution of OSMF.

Now, it could happen that someone could buy the OSM database in bankruptcy proceedings and then close the dataset: cease publishing planet.osm files and make changes to the data that would never be published. But we would still have the last dataset from before the sale, and the license terms (CC-BY-SA, ODbL, or whatever) would still apply to that data. Nothing would be lost except the future usefulness of the data (assuming no one else forked it and kept going, and I think in those circumstances, someone would do so).

I suppose the worst case would be if someone bought the OSM data rights and tried to keep the community contributions coming in but under a more restrictive data license (like Google's, say). That would probably fall under the view that your contributions were helping to perpetuate an environment of more closed data. My personal comfort when considering such a possibility is that I think large portions of the community, particularly the heaviest contributors, would abandon such a project, leaving it effectively the same as the data dead-end I described above--the new owner gets to use the data, the same as any company can now; we still have the last unencumbered data release; we all lose a future of updates to the data unless someone makes a fork.

If you don't want to contribute further to the project, I can understand that, but the prospect of losing data (which we would if you reject the new CTs) in what I see as a vibrant open data project makes me sad.

"Leave this setup running for a week" was a premature statement, apparently. I got my first really big tile expiration and it wiped out all the rendering I'd done for the past few days.

The rendering process spends most of its time extracting tiles from the metatiles, so I've implemented my old approach of only extracting the changed tiles within my new AMQP setup. The render queues now just get messages of the form 'z/x/y', while the database expiry table has the following fields: zoom, metax, metay, layer, x, y, expired. The expiration process only sends a render message if there are no pending tiles for a metatile, but it will expire individual tiles as it sees them. When a render process gets a render message, it pulls all that metatile's expired tiles from the database, renders the metatile, and then only extracts the changed tiles.

This should put me back into the place I was with my previous setup, where I was able to render all the changed tiles from zoom 11 and up slightly faster than they expired. It'll take a while to get through the backlog of metatiles I already had queued, but the problem shouldn't be getting worse while I'm doing it.

I believe one of the wiki pages points out that the original intent of the TIGER data was to be printed out on clipboards and referred to by census workers walking around neighborhoods. Sub-meter (or even sub-decameter) accuracy wasn't as important as getting the general geometries of the roads relative to each other.

in recent years, the Census Bureau has put more work into getting greater accuracy in their road data, but reimporting their new data into OSM is pretty much a practical impossibiity.

You can write an XML file to add your own presets, which you can then put on the button bar. See http://josm.openstreetmap.de/wiki/TaggingPresets .

I use the USGS's high resolution orthophotography for alignment a lot, so I added a button that just sets the tag "source=USGS Ortho".

Might I suggest using BitTorrent to distribute them? I'm pleased so far with the torrents over at http://osm-torrent.torres.voyager.hr/ .

I do house numbers as part of my process for mapping neighborhoods. My workflow is to make sure the roads are aligned to aerial imagery, possibly drawing houses, too, print the area via walking papers, and then visit and make notes about what's where. I usually just write down the first and last house number on each side of the street, but I try to make other notes if numbers are skipped.

Whether I map each individual address or just an interpolation way depends on how many addresses there are.

You can also right click on the imagery layer in the "Layers" box and select "Change resolution" to have the WMS plugin reload that imagery at the current zoom level.

There are at least a few others. pavi is pretty active.

India is, of course, a big place so the more mappers the better. Welcome to OSM!

Okay, sample rendering added (currently without the lowest, elevation-based layers or the highest layer, which would have town names).

I'll see about a screenshot. My current rendering setup is based off of TopOSM, which renders things into a lot of separate layers, which in turn makes one-off renderings more difficult. (Plus I'm doing the base layer differently and I probably have another four to five days of processing before it's ready to be integrated with the other layers.)

As for SVGs, I didn't think of that, since it's a relatively new development. I don't think it would buy me much; just not having to render the SVGs in the Gimp.

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.