I’ve been systematically reviewing all roads in areas using the tasking manager to divide them up. Although I do end up removing tiger:reviewed, I still have to review all roads, not just those still having tiger:reviewed. This is because the original edit may have removed it for other reasons. Or even more common I still review new roads created since TIGER having only a highway= and name.
My concern is areas like this (New Mexico) with swathes of untouched TIGER data. None of these remotely approximate what is understood in the rest of the developed world (and much of the US) as a residential road.
Right now the only way to broadly fail safe on these is to use the presence of the tiger:reviewed=no tag as a signal that the road is potentially not, actually, a road. The US community has had 17 years to clean up this data and has hardly scratched the surface[1].
It would seem really counter-productive, after so much effort on the Trails Stewardship Initiative and similar, to bulk delete one of the few signals that can be used to keep people out of encountering trouble in the backcountry.
If anyone is seriously proposing a bulk edit to remove these, then I would suggest as part of the same edit, any affected highway=residential, tiger:reviewed=no ways (in rural areas, at least) are changed to the “fixme” tag that is highway=road.
Apart from the magnificent Stretch Longfellow. ↩︎
5 Likes
Since you used the word “signal”, do you merely penalize such roads on the possibility that they haven’t been reviewed to the standard needed by your users? Or do you blot them out entirely, expecting the tag to be removed when enough review has taken place? I think the possibility that data consumers might take the latter, binary approach is one reason for the occasional angst about this key being set unrigorously. But a bigger factor is probably that some people are using it as their personal to-do list, so they want anyone who comes along to share their (usually unwritten) process.
Either way, I’m not so sure that tiger:reviewed=no is the only way to detect unreviewed roads. After Ito World’s TIGER Edited Map went away, we developed several Overpass queries to approximate whether even a modicum of review had taken place. Some of these queries focus on who last touched the way and when, to detect either the original import or a subsequent mass edit of road names. The most thorough one does the same for each node forming the way. Ideally, TIGERMap would take a harder look at authorship metadata instead of relying on a tag that often doesn’t get touched even after very thorough review. Would that be feasible for cycle.travel too?
This approach would probably be more plausible now than back 15 years ago when we started questioning the tiger:reviewed=* key, especially if “affected” is evaluated based on authorship metadata or even revision history. To minimize churn, it could happen at the same time as the mass removal of other TIGER tags.
That said, if you’re concerned that these aren’t even roads, not even tracks, then it touches on the debate about whether highway=road can imply a non-vehicular trail of some sort. There isn’t consensus on a single tag that can mean either a road or a path.
It goes back to @ZeLonewolf’s question of whether this is an urgent need. There may be a pragmatic alternative in being more chill about tiger:reviewed=*, understanding that this approach to tracking cleanup is better than nothing but far from ideal. That attitude requires some flexibility on the part of everyone.
1 Like
Rest assured, source=* doesn’t work like in Wikipedia. People don’t go around stickering [citation needed] on everything lacking this key. As long as your manual contributions can be corroborated by the usual sources that are built into the editor – such as the TIGER Roads overlay – there should be little scrutiny over the accuracy or provenance of your changes. Bulk imports do need more documentation, but that’s a different issue.
You probably saw lots of source=* tags on ways before settling on this approach. Many old imports tagged source=* on each way or even each node, because they took place before API v0.6 introduced the concept of changesets. Nowadays, most mappers prefer to put source=* on the changeset, because a source=* tag on an element needs to be maintained going forward as the other attributes change.
Ironically, OpenHistoricalMap has gone in the other direction, expecting source=* on the element, not the changeset, and expecting it more often, similar to Wikipedia:
Why the discrepancy? For the most part, the OSM community only expects sources as an alibi against charges that you copied from a copyrighted source like Google Maps. OHM involves a lot more research than field observation or remote sensing, so it’s harder to just assume that a mapper used a particular set of sources. OHM also intends to be used in an academic context, so the source information is used more extensively as a starting point for further research, making it even more important to avoid the appearance of plagiarism. If I map something based on a copyright-free GIS basemap and cite the URL on the changeset, but the URL goes dead at some point, that’s not a huge problem for OSM. But OHM would really want to correct that URL to avoid misleading researchers. Unfortunately, it isn’t possible to change a changeset’s metadata after closing it.
Sorry if this wasn’t fully explained to you originally. The changeset comment feature doesn’t leave very much room for explanation like this forum does.
3 Likes
I think it is very useful to be able to build maps that give folks ideas of things to work on. Using tiger:reviewed happens to be a extremely easy way for me to do this. From that perspective, I would prefer it remain (or we trick me into using some other metric! 
) as it does motivate folks to spend time on the map tidying and working on things.
FWIW I don’t think blowing away the TIGER tags helps us one way or the other. The goal really isn’t about those tags at all. It’s about having a high quality roadway network in the database. I would love to have a group of folks get together to identify ongoing improvements we would like made to the road network in the US and how to tackle them. Some problems just need folks pointed at them, others we’re going to have to create and apply some tooling… but none of that is impossible.
4 Likes
Definitely, QA reports are important, especially in map form! But I find it kind of unfortunate that, with all the cutting-edge technology that has gone into TIGERMap, we’re still forced to key off a key that was pretty much obsolete in 2008. Rereviewing ways such as this power line could result in some marginal improvement, but more likely it’s just going to be an exercise in manually deleting tiger:reviewed=no tags after much distraction. Maybe we could find a more efficient way to triage this data.
We already have Overpass queries that can produce a more accurate report of unreviewed TIGER, which you can customize depending on what you consider to be review. But if people prefer the superior experience of filtering TIGERMap, maybe we can find some way to reimplement these queries there.
If your only interaction with the tags is to delete them, I can see why this conversation may seem tedious but it’s pretty obvious to me that many many mappers find ways to contribute meaningful edits based off this keying. If you know an area well and think the keys are a distraction, I encourage you to remove them. I did this for big chunks of the Seattle region.
Overpass (and similar) and TIGERMap serve totally different audiences. One is a query language for power users and the other helps generate a reward loop that many folks find motivating. The filtering aspect is very fun but secondary to its purpose.
Also lol I seem to have missed one: TIGERMap
That’s the thing: I don’t remove the tag, ever, despite having reviewed huge swaths of TIGER in my day mapping uphill both ways in the snow. Fussing over this tag reduces the amount of TIGER that I can review in a sitting. Instead, I use other metadata to find things that need review, and I certainly get a kick out of knocking those issues off the map. Could TIGERMap make it easier for others to do the same?
If anyone here wants to use tiger:reviewed=no as a to-do list because it’s easy, then by all means, but you should acknowledge the caveats. Don’t expect everyone to use the tag exactly as you do. This isn’t a highway=trunk tag that has to mean the same thing to everyone. 
1 Like
Yeah, I stopped changing this key about 12 years ago, but I don’t see a real need to zap it. Didn’t JOSM used to remove certain tiger tags when an object was changed? That may be appropriate to add for the remaining tiger tags, including reviewed
Prior to your comments I have not seen your standard. I do see you have begun reviewing my work, unfortunately I can’t verify my data is accurate under 2m, so I did not modify those ways. Feel free to continue removing the source tag as they are updated to community standards, they will provide you a means of tracking the changes.
Thank you for the clarification. I’ll change how I source changes from now on and try to keep changesets more granular to the source.
Until I have a more accurate source of data I guess I will cease my efforts to update the tiger roads as to not make more work for @DUGA
Is the core disagreement about how “aligned” counts as aligned? I guess I have lost the original disagreement. Is there an example of a way that @blocal186 finds satisfactory and @DUGA does not? The ones I can see in the various links above seem fine but some of those have edits after the initial edits by @blocal186.
3 Likes
Should we introduce a new highway=unverified tag to tackle this problem?
Honestly, I wish Grab and Facebook had gone with something like highway=road when they dumped a ton of random highway=residential roads all over Asia. A lot of these turn out to be agricultural tracks, old roads that narrow into single tracks, or even completely impassable or inexistent paths. An intermediate highway tag could have been a great motivator for on-the-ground surveys to verify and properly classify them. Instead, we’re still stuck dealing with outdated and incorrect data from years ago.
When TIGER was originally imported, virtually every way in the entire U.S. was essentially unverified. If TIGER had had consistently superb geometry and road classification but no names or surface data, we probably wouldn’t have introduced tiger:reviewed=no at all, because we could just look for missing name=* or surface=* tags. The primary reason for this key was that a significant percentage of the geometry was suspect – even the existence of some of these roads was in doubt. Some mappers just happened to want to fix up other things while they were at it; that’s why discussions like this keep taking place.
TIGER had data about road classification, however flawed, that we could at least try to associate with highway=* classifications as a stopgap. In that sense, TIGER started out ahead of the automated mapping you’re referring to, but the geometry was a lot worse.
Unfortunately, TIGER’s quality varied wildly from county to county based on submissions from the local authorities. The rural counties tended to classify all their minor roads the same as all the urban counties classified their minor roads. TIGER’s “Local, neighborhood, and rural road, city street, unseparated” classification conflated tree-lined residential cul-de-sacs with unimproved roads out in the wilderness, so the fateful decision was made to tag them all as highway=residential instead of highway=unclassified. (Vehicular trails had a different TIGER classification that became highway=track.)
By coincidence, cycle.travel’s use case tends to send cyclists out into rural counties, which also have enjoyed less attention from mappers doing cleanup. So tiger:reviewed=no has served as a useful heuristic for that router, even when mappers like me don’t go to the lengths that some in this thread apparently expect. I certainly did not have the tools to verify geometry to within ten meters out in the hollers of rural West Virginia, but I could still improve things a lot!
2 Likes
I have looked into this sort of approach in the past and concluded it doesn’t really work without a full history planet, unfortunately. And when you have to process a full history planet on every map update just to work out whether a highway is actually a road or not, something has gone very wrong somewhere.
What I’d really like to see is a bulk edit of rural highways using something like this. That would go further and faster to fix the problem than pretty much anything else. Generally I’m of the school of thought that bulk edits hinder the development of community, but when it’s been 17 years and there’s no sign of the problem getting sorted any time soon, I tend to think desperate measures are needed.
I’ve added surfaces tags to rural roads in half the counties in Minnesota over the past two months. I think having machine learning info would have sped things up slightly, but a small amount of organized volunteers is probably sufficient. I got started because I was planning a long ride and wanted to stay off paved rural highways as much as possible. Maybe we could leverage the “gravel” cyclist community to get this moving.
As an aside, tigerreviewed status was only barely correlated with having a surface tag.
No editing implies no community.
TIGER tags are of limited usefulness. Back in the day I convinced the JOSM developers to highlight tiger:reviewed=no with a yellow swipe, as if hit by a highlighter. That was useful in my quest to review all roads wherever I edited, which was a substantial area. It has since disappeared and it’s now not worth the effort of seeking out unreviewed roads to correct their alignment or indeed even existence (cuz TIGER is just that way).
I don’t know of any possible use for them other than an indication that nobody has touched them since they were imported.
Here, here!
If I understand correctly, you’d need the full history because someone might’ve touched the way since the abbreviation expansion bot went through in the 2010–2013 timeframe, but this doesn’t give you enough confidence that the edit constitutes “review”? What if instead you consider whether any of the nodes making up the way have been touched more recently or by someone other than a bot? One of the logistical problems with tiger:reviewed=* has been that mappers often want to clean up only one end of a long way without even glancing at the rest. In theory, finding a run of untouched nodes on a way, subject to some distance threshold, would enable you to make a more fine-grained decision than considering the way from end to end. Granted, that sounds like a pain.
It’s great to see this project is still being developed. Even if it doesn’t result in an automated import, it could accelerate the pace of surface tagging as part of some human-in-the-loop workflow that’s less tedious than what we’d do otherwise. This could be for surface=* what the TIGER Battlegrid was for geometry and the TIGER Roads overlay is for name=*. I’d much rather focus on possibilities like this than see folks yelling at each other over the finer nuances of a generically named Boolean key.
1 Like