[Geodata] [Tiger] A few interesting observations on the Tiger2007fedata

[Stephen Woodbridge]

A NEW issue is that some counties do NOT have the *_addr.dbf and 
*_addrfn.dbf files. This is problematic because you can not join them 
with the edges data, which I suppose is fine if there are no addresses 
and I just need to be smarter about handling this case.

tiger2007fe/46_SOUTH_DAKOTA/46113_Shannon
tiger2007fe/46_SOUTH_DAKOTA/46137_Ziebach
tiger2007fe/48_TEXAS/48301_Loving
tiger2007fe/51_VIRGINIA/51029_Buckingham
tiger2007fe/60_AMERICAN_SAMOA/60010_Eastern
tiger2007fe/60_AMERICAN_SAMOA/60020_Manua
tiger2007fe/60_AMERICAN_SAMOA/60030_Rose_Island
tiger2007fe/60_AMERICAN_SAMOA/60040_Swains_Island
tiger2007fe/60_AMERICAN_SAMOA/60050_Western
tiger2007fe/66_GUAM/66010_Guam
tiger2007fe/69_COMMONWEALTH_OF_THE_NORTHERN_MARIANA_ISLANDS/69085_Northern_Islands
tiger2007fe/69_COMMONWEALTH_OF_THE_NORTHERN_MARIANA_ISLANDS/69100_Rota
tiger2007fe/69_COMMONWEALTH_OF_THE_NORTHERN_MARIANA_ISLANDS/69110_Saipan
tiger2007fe/69_COMMONWEALTH_OF_THE_NORTHERN_MARIANA_ISLANDS/69120_Tinian
tiger2007fe/78_VIRGIN_ISLANDS_OF_THE_UNITED_STATES/78010_St_Croix
tiger2007fe/78_VIRGIN_ISLANDS_OF_THE_UNITED_STATES/78020_St_John
tiger2007fe/78_VIRGIN_ISLANDS_OF_THE_UNITED_STATES/78030_St_Thomas

Other issues inline below ...

Bob Basques wrote:
> Stephen,
> 
> I ran into some of these problems with our local dataset.  The
> multiple Zip code assignments is explainable up to 4 (or possible 6)
> by the segment ending up at the same spot where four different zip
> code boundaries come together.  If it's more than four, that would be
> something that would be harder to explain.

Well it is understandable from the point of view that zipcode are NOT 
areas but postal carrier routes and one street segment might be services 
by multiple routes. In fact in many city streets the right and left side 
are often serviced by separate routes. I am just surprised to see it 
here in the census data and surprised to find the it is extremely common 
to find one side that has multiple zipcodes!

I found 466354 cases of this in the tiger data!

> As for the multiple ranges, there are possible valid reasons for
> this.  On is that a long segnet is broken by ranges not at an
> intersection but by some arbitrary line that denotes address
> directionals.  Basiccaly, the segment could have a Zero in the middle
> and go up towards each end.

Yes, but that arbitrary line is NOT represented in Tiger or the street 
segment would have been split at the intersection point.

I found 232723 cases of this in the tiger data!

More food for thought.

-Steve

> Just some food for thought.
> 
> bobb
> 
> 
> 
>>>> Stephen Woodbridge <woodbri at swoodbridge.com> 06/29/08 10:06 PM
>>>> >>>
> Hi all,
> 
> The more I play with this data the stranger it is!
> 
> For example, I am finding lots of segments that have multiple
> zipcodes assigned to them. While there is nothing wrong with this, it
> was unexpected and I wonder if this was done based on merge/join with
> the USPS zip+4 data, and when such a merge was last done?
> 
> tlid|fullname|paflag|mtfcc|fromhn|tohn|side|zip|plus4|statefp|countyfp
>  86841497|"Littlefield
> Rd"|"P"|"S1400"|"2"|"8"|"L"|"01720"|""|"25"|"017" 
> 86841497|"Littlefield
> Rd"|"P"|"S1400"|"4"|"8"|"L"|"01719"|""|"25"|"017" 
> 86841497|"Littlefield
> Rd"|"P"|"S1400"|"3"|"5"|"R"|"01719"|""|"25"|"017" 
> 86841497|"Littlefield
> Rd"|"P"|"S1400"|"1"|"99"|"R"|"01720"|""|"25"|"017"
> 
> I also have found MANY records (like 98287 in 1290 counties
> processed) that have multiple house number ranges where the ranges
> have mixed directionality over the segment. IE: on range increases
> from->to while another range decreases from->to along the segment.
> Some examples (sorry don't have the tlid):
> 
> WARN: merge_hn(a_from, a_to, b_from, b_to) WARN: merge_hn(62, 28,
> 247, 255) WARN: merge_hn(7, 1, 9, 13) WARN: merge_hn(98, 50, 55, 57) 
> WARN: merge_hn(13, 7, 1, 5) WARN: merge_hn(15, 7, 1, 5) WARN:
> merge_hn(600, 100, 602, 606)
> 
> I need to change the program that is processing the data to spit out
>  more details so I can check the data closer and make sure these
> reports are not symptomatic of a bug.
> 
> Some of these look like they might be encoded wrong with respect to 
> direction. For example:
> 
> WARN: merge_hn(7, 1, 9, 13)
> 
> probably is (1-7) and (9-13) which is a continuous range along the 
> street segment that was likely split because of different postal
> codes, except that someone swapped the FROM and TO numbers or did not
> realize the segment direction was reversed.
> 
> Anyway, more food for thought! Anyone else seen these, have any
> thoughts on it?
> 
> Best regards, -Steve W 
> _______________________________________________ Geodata mailing list 
> Geodata at lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/geodata
>