Proposal for mechanical edit: remove all tiger:* tags for items with tiger:reviewed=yes

As an orthogonal discussion to these:

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.

1 Like

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.

2 Likes

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.

Here’s a particular puzzle I’m currently working on: Way: ‪Arlington Mine Road‬ (‪560630777‬) | OpenStreetMap

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.


  1. Apart from in Nebraska. If we could have 50 more Stretch Longfellows that would be great. ↩︎

1 Like

If I’ve understood your use case, any roadway with surface and tiger:reviewed=yes could have all the tiger:* tags removed. Is that correct?

Is the heuristic using tiger:county and tiger:name_base as a proxy described somewhere? I would love to know more.

2 Likes

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? :grin:

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.

1 Like