Talk:TIGER fixup

From OpenStreetMap Wiki
(Redirected from Talk:Tiger fixup)
Jump to: navigation, search

Discuss the TIGER fixup page here:


Post import tiger instructions

I guess as a new contributor, I am a bit in the dark about a lot of this. I am in a county that does not currently have Tiger data loaded. I see that when Tiger data and other data exist together, they duplicate the same ways. If the entire US is to be uploaded with Tiger data, how are we intended to best use this data? From reading these pages, it sounds not only like the results of converting the data are uncertain, but what we should do with the data is unclear. Shouldn't this page be giving more info on just what the goal is and how to get there?

For example, what data fields in the Tiger data that are imported need to be retained? The info on the tiger conversion seems to be focusing on how to load the data into the OSM database. But once it is in there what is the intent of how to use it?

Shouldn't this be stated before the data is uploaded? Is this page the right place to state it?

-- User:Gnuarm 02:02, 19 October 2007

It's apparently easiest to save your county as an OSM file locally, and then delete it from the database. Let the TIGER upload happen, and apply any fixes from the local file. That way, you don't need to clean up merged data in the same layer, which is a pain. --Colin Marquardt 12:02, 27 November 2007 (UTC)

Tiger not matching Yahoo satellite pics

I tried looking at Tiger data in a few areas and found all the roads skewed from the satellite pictures. Examples are Hana Hawaii, Maalaea Hawaii (both on Maui) and the SW corner of Connecticut (near Greenwich). Some roads even extend into the ocean. Is Tiger right, or is Yahoo imaging right? Whichever is correct how should this be fixed? --Sysmg 3:04pm, 18 March 2008 (EST)

There is no quick answer as to which is right. In some areas the Tiger is correct and the aerial photos are off, in other areas the aerial photos are correctly aligned and the Tiger data is off. With two opinions, you need a third to be a tie breaker. The best tie breaker for this would be GPS readings. Either look for existing GPS tracks that someone has uploaded, or go make some and upload them. Of course, GPS isn't perfect either, so watch your GPS reception to get the best signal you can, also. Amillar 06:30, 19 March 2008 (UTC)
To me it seems quite plausible that there would be a global offset, or maybe something like a proportional drift to 50metres offset towards the West coast while the central U.S. is perfect (for example). this related discuss suggests that hawaii (the westernmost extremity of the TIGER data) suffers from a large offset.
If that is the case it would probably be a bad idea if "mappers to find and apply local corrections". Why correct one neighbourhood, and not all the surrounding cities/countryside? It would be better if we get to the bottom of it, and apply a larger scale correction (To "get to the bottom of it" is the tricky bit. See suggestion below) -- Harry Wood 13:57, 21 April 2008 (UTC)
A global offset is plausible, but not encountered in my experience. In the Portland Oregon area, the older the road is, the more likely that the Tiger data matches GPS tracks. The newer the road, the more likely the Tiger data varies. Do NOT take some samplings at various points in the country and then think you can apply a global correction for it; it doesn't exist. If you read the Tiger docs from the Census Bureau, you will see that TIGER itself is an amalgam of input from multiple sources. The Census Bureau does not have, and never had, an army of surveyors mapping the entire country; it has combined data from USGS, state, and county sources, with some updates of its own. Tiger simply does not have one reference base within itself that can be corrected. Certainly if you find one neighborhood is off, and others around it are off by the same amount, then correct all of them. "Local" does not equal "neighborhood", "Local" equals whatever matches. But do NOT assume that because you found one offset within a range of 5 miles, then it also applies to 50 miles, or 500 miles. Check and recheck it. Amillar 20:31, 21 April 2008 (UTC)
For what it's worth, we have discovered that all the main islands of Hawaiʻi, (except Oʻahu) in the 2007 TIGER data were not in the NAD83 datum. That is why you were seeing the skew in Hana and Maalaea. The 2008 and 2009 TIGER data for these islands uses NAD83 so a reimport would take care of the problem there. Icycle 16:37, 7 October 2009 (UTC)


Thanks, for the reply. Once it is determined which is right, is there a reasonable way to move the Tiger data en mass, or adjust the imaging? Or is that beyond my newbie capability? --Sysmg 11:41am, 21 Mar 2008 (EST)

I think that's a very important question. Maybe we should do something systematic and possibly try to apply a more global correction here. I suppose we should start by recording a few samplings of accuracy in various corners of the U.S., to determining exactly what the offset is between TIGER data and reality (and between Yahoo! Aerial Imagery and reality).
Note however that "reality" needs to be measured by multiple concurring GPS tracks, preferably from different users, because I think some people can be a little bit too "proud" about how accurate their GPS unit is. Personally I find my GPS sometimes records tracks with an inacurrate offset of 15/20 metres. This makes it look like Yahoo imagery is offset, but when I compare with other people's tracks I can see my GPS is wrong. Guess it gets a bad initial fix or something.
There were some guys out mapping in San Francisco last weekend. I guess they probably measured reality with multiple readings. I wonder how well TIGER data lines up there.
-- Harry Wood 09:31, 21 April 2008 (UTC)
If you are CERTAIN that the Yahoo images are off in your area, because you compared them to multiple GPS tracks, then no, there is no way for us to fix them permanently. You can manually adjust the alignment in JOSM or Potlatch for your editing session. In the more likely case that the Tiger data is incorrect, select the area with JOSM and drag it as far as needed to line it up. Amillar 20:31, 21 April 2008 (UTC)
OK. That answers my question. We don't try to apply a global correction because it isn't as simple as that. Let's summarise on the page. -- Harry Wood 21:12, 21 April 2008 (UTC)

Fixing Highways

How do we tag e.g. "State Highway 128" (in CA)? I have used ref=128 highway=primary. --Colin Marquardt 12:02, 27 November 2007 (UTC)

The highway tag is good as either primary or secondary, based on your discretion of its importance compared to the roads around it. The ref tag should probably be "CA 128" to distinguish it from Interstate, US highway, or county road numbers. There may not be any others with the same number in the immediate area you are working on, but it is easier to be consistent and avoid the problem completely. --Amillar 16:15, 28 April 2008 (UTC)
Here's the system I would suggest (this is voluntary, just my preference): No prefix for primary state roads, Wisconsin or Missouri lettered 'trunk' routes, or New York State Reference Routes. No ref for parkways or expressways that have no numerical shields in the field, e.g. the Garden State Parkway (this does not apply to state or county surface roads with internal route designations, e.g. NJ 324 or Atlantic County Route 631). FM and RM for Texas farm- and ranch-to-market roads). US for federal (U.S.) highways. I- for Interstates. Secondary routes (Montana, Pennsylvania, Tennessee, etc.) and all county roads are parenthesised (e.g. (501) for County Route 501).CrystalWalrein 04:15, 5 September 2008 (UTC)
That is terribly inconsistent and hard to remember. Use a route relation instead. After adding the way to the relation you can then remove the redundant name and ref tags from the way.--Elyk 04:29, 20 March 2009 (UTC)

Expanding Street Names

In OSM, we don't normally use abbreviations such as Rd for Road. The TIGER import however created many such names. Could we safely expand a name like "Petrified Forest Rd" to "Petrified Forest Road" when "tiger:name_type" is "Rd"? There are also a lot of unambiguous abbreviations such as "Hwy" and "Expwy". The only ambiguous ones I can think of right now is "St" which could be "Saint" or "Street"; and "E" which could be used in "E Street" and "Silverado Trail East". --Colin Marquardt 23:14, 27 November 2007 (UTC)

Outdated data

Just wanted to comment on general TIGER uploads, especially in New Jersey. Most of them are far out of date and do not reflect current traffic configurations. One example (which I've corrected) is the designation of New Jersey Route 180 (Bay Avenue in Stafford Township), which has not existed for nearly thirty years. CrystalWalrein 04:02, 5 September 2008 (UTC)

Tiger Accuracy Examples

I made two trips, one from Portland to Seattle and one from Portland to Newport, OR on the coast. Most of the trips were highway driving, which has given me some interesting insight into the TIGER data. The US Census Bureau documentation says that TIGER is a composite of multiple sources, and the highways show it.

US highway 20 in Oregon had some interesting artifacts. In Lincoln county, the way was a rough approximation of the road, with typical TIGER misalignment. As soon as it crossed into Benton county, the way was an exact match with my GPS track and the Yahoo aerial photos.

Interstate highway 5 in Washington state was interesting too. In Cowlitz county, I-5 was a single way with poor accuracy, but as soon as it crossed into Lewis county, it became dual ways with accurate placement. Based on the tiger:tlid tags, it looks like the dual ways were original Tiger data and not later OSM edits.

I expected that US highways and Interstate highways would be consistent for their whole length. But in retrospect, I imagine that not only do they export at county levels, much of the TIGER database was probably built by importing data at county level too. --Amillar 15:23, 15 March 2009 (UTC)

Cleaning up TIGER data

Hello, I'm completely new here and have a basic question. The area where I live is filled in with TIGER data and little else. The data is not bad, but there are a number of problems, such as missing street names, street segment connections that do not exist, poor accuracy, etc. I could easily fix a number of these. My question is, is there any reason why I should not just jump in and start making fixes? I saw something about new TIGER updates coming. Would it be better to wait until the process is complete? Being completely new here I'm not sure yet how to do something as simple as giving a name to a street segment. The TIGER streets have a lot of data fields. I assume I can figure out how to add a missing name and set the tiger_review field to "yes". Also, in "play" mode I was able to split a street at a node, but unable to see how to delete a split-off segment. There are some obvious errors in my neighborhood that would require something like that. Perhaps it is clearer in actual edit mode. Anyway, before I started editing for real I thought I'd ask whether I should. I'd hate to make a bunch of edits only to have them overrun by some mass TIGER update or some such. Thanks! Pfly 04:00, 20 March 2009 (UTC)

My guess is that the TIGER uploaders will try not to overwrite anyone's contributions (unless it's just a few edited streets or something). Setting tiger:reviewed to yes sounds like a good idea, if you don't find that too inconvenient. But OSM stores the history of each feature, so they'll be able to tell if you've changed something regardless. – Minh Nguyễn (talk, contribs) 21:00, 13 May 2009 (UTC)
Yes absolutely. The people working on import scripts would never do anything to overwrite people's contributions. You are very much encouraged to get stuck in and make some of the corrections described on this page. In particular, use the yahoo aerial imagery to straighten out the street positions, and add other map features you know of.
To delete the split off segment, select it and press 'shift' & 'delete' (assuming you're using the Potlatch editor)
-- Harry Wood 11:53, 14 May 2009 (UTC)

All of my pre-TIGER edits based on my own WAAS GPS traces were deleted by what I assume was the TIGER import. For instance, check out my 108689 changeset. It's kind of odd that there isn't even a changeset associated with the delete; the nodes are just gone. Should I assume that this was a one time thing for the initial TIGER import? I don't want to spend my time editing, only to have the changes deleted, without even an option to revert the delete. Unixxx 19:38, 12 June 2010 (UTC)

Wow. That's an old changeset 108689. I think you must have been a victim of the first attempt TIGER import, which was cleaned up rather crudely with a raw database delete. That kind of thing hasn't happened in a long time. You were mapping the U.S. in the early days! hmmm wonder if we can rescue that data -- Harry Wood 12:10, 13 June 2010 (UTC)

I'd be interested in knowing the outcome of this tale. Was the original data recoverable in some form? --Ceyockey 01:17, 8 December 2011 (UTC)

Simplifying TIGER Roads

In several rural places within New Jersey and presumably elsewhere, I've found that the TIGER roadways have extra needless nodes within a way. Streets that are as straight as an arrow have many nodes in a straight (or near straight) line. Is there any policy for removing these superfluous nodes? As long as they don't participate in any other way, is there harm in removing them? It seems like OSM is needlessly storing information. The extra nodes also add "bumpiness" to the rendering of the otherwise straight roads.

A good example of this is Carranza Road, in Burlington County, NJ. The actual road is a straight line between two bends, however the TIGER representation has 100+ nodes - all in a near straight line - between the two bends in the road. It's needless precision that doesn't reflect reality.

-- Johnjreiser 16:16, 20 July 2009 (UTC)

Yep. I've seen this in TIGER data too. If there's unnecessary nodes along a straight section.... delete them! -- Harry Wood 17:52, 20 July 2009 (UTC)

Which tags do I change/delete?

My street is mislabeled in the TIGER data and I wanted to go in and fix it (and a couple of other roads in the area). Do I fix the incorrect tiger:* tags or do I just delete them when I correct the "normal" OSM tags (such as name)? - Cafemusique 11:06, 11 October 2009 (UTC)

If you have a street where the 'name' tag is wrong, it may be a wildly inaccurate placement of some other nearby street, in which case try to line up the whole neighbourhood grid differently. Otherwise I guess it must be some out of date data or something. Difficult to know what went wrong there, but the best thing to do is delete all the tags, or even delete the way itself, and re-create it as you would map it. highway=residential with right name. -- Harry Wood 19:00, 11 October 2009 (UTC)

When to remove "reviewed" tag?

When something has been reviewed, we are supposed to remove the "tiger:reviewed" tag. What level of review should be used before removing this tag? When I do a ground survey and verify the street names I have been removing the tags. However, for some things that are close to me but can't be reached (because there is no access, like railroad tracks) I have been removing this tag when I align it by Yahoo images.

However, for more distant locations that I have been aligning with Yahoo images I haven't been removing this tag. Most of them are tracks that I don't know the grade and/or access. These I haven't been marking as reviewed, though what I have been doing has been improving the quality of data. I have also been adding tracks, where they can be seen from the Yahoo images. Is this what should be done in cases like this? — Val42 00:17, 31 October 2009 (UTC)

All fair questions, but my answer would be: Ignore the reviewed tag. It's not useful. You've found it confusing, or at least you've had pause for thought about what it really means. Many other people have had the same. That's a waste of time and energy which could have gone into doing more fixup. See also Talk:Import/Guidelines#reviewed tag -- Harry Wood 19:13, 17 March 2010 (UTC)

Fields like tiger:tlid and tiger:source

I probably missed this somewhere ... what is the current thinking on removal or retention of fields like tiger:tlid and tiger:source? --Ceyockey 01:19, 8 December 2011 (UTC)

Validity and utility of tiger:zip_left and _right

I'm wondering whether anyone has found utility in the tiger:zip_left and tiger:zip_right data? If this were accurate, it could be quite useful. Does anyone have a sense of how accurate this information is? --Ceyockey 01:21, 8 December 2011 (UTC)

Finding roads that need to be reviewed?

I have been verifying TIGER roads and correcting them. Currently, I download a small area in JOSM, and look for roads with the yellow highlight indicating TIGER:reviewed=no , but I need a better way of doing this, without requiring a download. How can I see which roads need to be verified online? It would be nice to plan a mapping trip without having to first use a map editor. Mtc (talk) 15:33, 16 August 2016 (UTC)

You can use the TIGER Edited Map to get an idea which areas are most in need of some mapping love. It's not updated immediately, though; what you see might be a few weeks old. --Lyx (talk) 19:28, 16 August 2016 (UTC)