I would like to see what folks think about mass removing the TIGER tags from “reviewed” items.
A proposal to get us started discussing:
items with tiger:reviewed=yes - it is safe and correct to remove all tiger:* tags from these items even in a mass mechanical edit
items with no tiger:reviewed tag but residual tiger:* tagging - it is presumed that this is equivalent to the case above
I do not have plans to work on this in the immediate future but it’s nice to have some things to point folks to who want to try and learn more about JOSM etc.
Personally, I used to rigorously remove tiger:reviewed=* or set it to yes back in 2008, but then I gave up the following year and never looked back. These days, I ignore it just like all the other tiger:*=* keys. At least tiger:name_base=* can occasionally help me untangle the many accidental merges made in Potlatch 1. And tiger:county=* can help me recover lost data from back when we incorrectly assumed we didn’t need to distinguish name:left=* from name:right=* and ref:left=* from ref:right=* on a county line road.
That said, some other mappers have personally adopted this key in their respective areas of interest, using it in conjunction with Overpass as sort of a poor man’s MapRoulette. Removing tiger:reviewed=yes could be disruptive to them, but I’d be interested in helping these users migrate to MapRoulette or another tasking manager.
Ironically, in the suburban areas where I often map, if you were to remove all the tiger:*=* tags from a street, I would have to give the street much more scrutiny. Typically, many non-TIGER streets are poorly drawn ML extractions or segmented GPS traces with incorrect start and end points, or with street names copied from copyrighted sources that I have to follow up on. From this perspective, keeping tiger:reviewed=yes but removing the other tiger:*=* tags would be the safer option.
For all of the uses above, I think there are better and clear options ex: looking at newly mapped roadways is easier that “all roadways without any tiger tags”. ex: untangling roadways, the history still has all the tag info to do this etc.
I would very much like to unburden these tags from the hundreds of implied meanings they have to various folks. If there’s some useful aspect of the tag for people, let’s make another tag that is very concrete about what it means to them.
The history isn’t always easily accessible anymore. TIGER was imported county by county, so the county line roads common in the Midwest were imported twice as overlapping ways, each connected to a different set of roads. The community rallied around a campaign to delete each redundant ways and connect all the roads to the remaining way.
Unfortunately, most of us were unaware that a county line road could legitimately have more than one name, so OSM ended up only knowing about a County Road 123 but not the County Road 567 that’s one and the same. Fortunately, most mappers at the time didn’t care about deleting tiger:*=* tags, so at least there was a paper trail to know which version we kept. My typical workflow was to edit in Potlatch 1, which had a unique undelete function, so that I could easily perform a manual three-way merge. (JOSM and Level0 can undelete too, but you have to know the way ID, which is just about impossible if you’re looking at an old “changeset” from before changesets existed.)
Unfortunately, I and others were still under the assumption that the whole street was known by one name or the other, so the undeleted name went into alt_name=* rather than name:left=* or name:right=*. Now, when we go back and fix up these streets a third time, we need to consider not only these previous mistakes but also any legitimate edits made in the meantime, for example because of E911 street renames.
Ultimately, I don’t feel very strongly about keeping tiger:county=*. Browsing deleted ways is nigh impossible at this point, now that Potlatch 1 has been discontinued. The more robust solution is to keep a local copy of TIGER handy in QGIS. (I’m unsure if the TIGERweb layer can show these overlapping names.)
Definitely support removing all the other (non-reviewed) tiger tags as I think those have all served their purpose. By the time the botmode expanded the names, circa 2011, that had lived out its useful life.
An additional note I’d toss out in the proposal is that for any way with tiger reviewed=no but the last user neither Dave Hansen nor Botmode, this can be assumed to be verified. The level of verification cannot be determined but at least it lets you know that some other mapper has made an update.
Is this segment of road named “Arlington Mine Road” as suggested by TIGER, is it an extension of Palen Pass Road (which is the name BLM currently supplies for the track to the northwest), or is it unnamed?
The way is tagged with tiger:reviewed=yes so the remaining tiger:* tags could be removed, but it is helpful to note that the name came from TIGER even though the way was split at some point in the past and it’s at version 1.
That said, keeping the tiger:* tags will not make this easier to figure out. And removing them would only make me marginally less suspicious of the name. So, even if the cleanup wouldn’t be helpful here, it’s not particularly harmful either.
I aggressively remove tiger tags when they are redundant or incorrect. If they aren’t, I update the “real” tags to make the tigers redundant, then remove them.
I find them useful as a checklist though. I run an Overpass query to find unreviewed rural roads to clean up.
That said, I’m all in favor of the proposed mech edit here! I think as long as tiger:reviewed=yes is still recommended as an option, this cleanup task should be run every year or two.
I have qualms about this until rural roads are in a better state, I’m afraid - where a “better state” is one in which unpaved roads are consistently tagged as such, and where things that aren’t roads aren’t tagged with a highway= tag.
At present, it is possible to (just about) use heuristics from TIGER tags to significantly improve lower-hierarchy road parsing in the rural US. In particular, tiger:county and tiger:name_base can be employed in the service of guessing which roads might be paved despite the lack of any post-import editing activity.
I would love surfaces to be consistently tagged so that this isn’t necessary, but we’re still some way off that[1], and right now removing these tags would make bike routing in the rural US harder.
(Personally I don’t use tiger: tags other than these two and tiger:reviewed. I’d be plenty happy to see :cfcc, :separated, :source, :tlid and :upload_uuid go. But most of these are already in the unofficial editor discard list, I think.)
I did consider this but it’s not a very reliable heuristic. Quite a lot of bulk edits have been applied to the data, from purely mechanical tidying to things like “apply a 30mph speed limit to all highway=residential in Hinksville County”, which gives you the entertaining situation of a drainage ditch tagged with highway=residential and maxspeed=30 mph.
Apart from in Nebraska. If we could have 50 more Stretch Longfellows that would be great. ↩︎
I’m continually amazed by the gymnastics your router performs. You make it look so easy, until anyone muses about deleting anything. Do you happen to have a GitHub repository so that @danieldegroot2 can file an issue asking you to publish a taginfo project file?
I’m not opposed to this at all. As it is, once it’s obvious an object could be subject of a Ship of Theseus debate, I just lop the tiger:*=* as redundant.
I actually was just considering putting TIGER tags back on some neighborhood streets where they have been removed, but thought I should check what the community thinks first, and I found this topic.
Since consensus seems to be they need to be removed, I won’t put them back where they already have been, but I would like to see them stay for now. Sometimes they’re pretty helpful. When a road seems to be named wrong, I can look to see what TIGER thought it was named. Most times when name is wrong, so is the tiger:name, but it’s at least a check that can give some insight, particularly in rural areas where roads can have several names and the tiger:name may be different from any other name currently tagged on the road.
The ones that I check all the time that I would hate to see removed are tiger:zip_left and tiger:zip_right. I know that zip codes are not exclusively tied to a particular geographical area, but as a practical matter, 99.9% of the time if you’re wondering what the zip code of a building is, you can correctly find out from checking the tiger:zip tags nearby.
Usually when mappers have already removed the tiger tags, they do not go in an replace it with a postal_code tag, so then I’m left still wondering what the zip code is in a particular area of the city. That’s the main reason I was considering restoring tiger tags on some roads where they have been removed, but instead I’ll just add the postal_code tag.
You can achieve this same effect by looking at the latest TIGER layer – no need to put tagging directly on the object. Also, TIGER data can change over time, so it’s best to look at the most recent year’s edition. You can turn it on as a layer in JOSM – perhaps it’s possible in iD as well?
While the data are older (>16+ years older…like a good whiskey?) I do sometimes find the CFCC data useful when improving TIGER’s imported rail data (where CFCC begins with B, rather than A, for regular vehicular roads). It is hard to describe exactly when and how this is helpful, but I have found myself glad those (CFCC “B-prefix”) data were there. Similarly, ithe CFCC “A-prefix data” (for roads) still could be useful in not-too-difficult-to-imagine contexts or use cases.
So, I would wholesale-delete these tags only with some trepidation. Now, if there is tiger:reviewed=yes or no tiger:reviewed tag at all, mmm, I think it’s OK to delete the other TIGER tags…mmm, mostly, I think. Apologies this is a bit fuzzy; no whiskey was involved.