Yeah. I’d definitely look for tiger:reviewed to find roads that don’t have trustworthy surface info. cfcc is pretty useless considering every road that you’d have to worry about adding surface data to would just be… A41
In due time I’d love to consider a mass edit to just remove the tags to stop confusing mappers.
I’m beginning to nod my head in agreement, but let’s be careful here before we all scream for tag deletion bots running deep into the night. What it appears we’ve “built” with TIGER data (tags) are a whole bunch of assumptions that keep stacking ever higher. For example, yes, @Richard using tiger:reviewed for making more than a coin-flip’s worth of determination about surface is sensible, but what about the converse: when there is no such tag, it may still be true that if the surface isn’t well tagged, it’s still a big unknown w.r.t. surface. You’d have to dig into the history of the datum to see if tiger:reviewed ever WAS on it, and when, and perhaps what might have happened so that it was removed, with only poor-worthiness “guesswork-level” logic, most likely.
Stated succinctly (nearly impossible with TIGER, unless you go very deep, and I won’t here): you can’t always remove tiger:* tags willy-nilly without some consequences, but eventually we want to do exactly that.
I’ll delete tiger:reviewed if I add surface tags, but I usually keep it if the edit is just a minor adjustment.
What it appears we’ve “built” with TIGER data (tags) are a whole bunch of assumptions that keep stacking ever higher.
Absolutely. IMO the best move is to make focused guidance on how to handle the tags, so we can methodically separate ourselves from the tiger:* stuff.
There’s another thread on the US forums where they’re using MR to add surface data in California.
I feel that going forward, this kind of work may be an important part of shedding all the old tiger:* tagging.
–SherbetS
Worse than “not helpful”, it’s “actively misleading”. “tiger:zip” codes aren’t ZIP codes, they’re ZCTA codes. These are a Census-derived approximation to ZIP codes, useful mainly for interpreting Census-derived statistics.
How the rest of the world is doing it without the tiger:reviewed 
Consider there is no more tiger:reviewed, so a mapper removed it. Either there he set a surface, then there should be no issue. Or there is no surface defined, well then there might be assumptions done in the renderer. The assumptions possible by tiger:cfcc have been made already during the import. For me nothing you going to loose here. Anyway the issue of missing surface you will have for everything not taken over from TIGER, more or less like everywhere else. So deleting everything but the tiger:reviewed would make sense and keep tiger:reviewed as a machine-readable status indicator, whether the object has been reviewed.
Mmmm, mostly true, I’ll say, but not necessarily always true. Many people forget a significant amount of imported TIGER data were railway=rail, and while they were “fairly noisy,” (with what are now well-understood and surmountable limitations, thanks to newer tags like owner=* and operator=*) they were also “good enough” to have become seriously improved over the last 15 years: today these data are now “pretty decent and still improving.” It is estimated TIGER-imported rail data (in the USA, of course, that’s the only place we have such data) are approximately 75% completely reviewed, but that is a “compromise estimate.” It remains difficult to derive hard numbers about this, because the data have spent 15 years getting both “smeared” and “deliberately improved,” resulting in “much, much better data, but messy as to a measurable value of their actual level of improvement since import.”
In the rail examples I gave, the tiger:cfcc turned out to be quite helpful to make determinations between things like rail mainlines, sidings, industrial spurs and other similarly and quite distinctly taggable ways in OSM — and so they largely have been. This is the best example I can think of for “hey, don’t delete a tiger:* tag until you’re 100% certain there are absolutely no more use cases where semantic value can be ‘wrung out’ of them.” (Imagine a slightly-damp washcloth that you think of as containing “no more moisture” and you twist and squeeze it as hard as you can and get a few more precious drops of fluid). I’m pretty sure we have neither imagined fully nor squeezed out all of the semantic value that (still) might remain in tiger:= tagging. It’s just plain difficult to “fully imagine” all the possible use cases where semantic value might be extracted before the final “goodnight” of deletion happens.
And that is (just) for tiger:cfcc. (Which I’ll be the first to say, is actually a fairly useful tag, at least for what I did with some rail data improvements). Other tiger:= tags? Well, please chime in here and now, everyone.
True, yes I was only talking about the highways, not about the railways.
Better to verify the name against the latest TIGER Roads overlay or a more reliable source. Often TIGER 2005 did things like assign a road name to the next road over (typical with minor residential side streets off a major road).
On the other hand, tiger:name_base can be handy for sorting out a mess where someone long ago merged multiple ways incorrectly or deduplicated county line roads without using name:left and name:right. You can easily tell which tiger:name_base_# goes on the left or the right based on the corresponding tiger:county in the version before deduplication.
I eventually managed to tease out the names on either side of this road, but it required trawling through the histories of all the connected ways that it had been split from over the years – and using Potlatch 1’s deleted ways visualization, which we no longer have access to. This would’ve been more difficult if someone had already stripped out tiger:county from all the roads.