[postgis-devel] [PostGIS] #1052: Tiger Geocoder 2010 Geocode() "squishing" toward end of block

[PostGIS]

#1052: Tiger Geocoder 2010 Geocode() "squishing" toward end of block
-----------------------------+----------------------------------------------
  Reporter:  mikepease       |       Owner:  robe         
      Type:  enhancement     |      Status:  reopened     
  Priority:  medium          |   Milestone:  PostGIS 2.0.0
 Component:  tiger geocoder  |     Version:  trunk        
Resolution:                  |    Keywords:               
-----------------------------+----------------------------------------------

Comment(by reholl):

 A couple thoughts I might add.  TIGER does in fact store "theoretical"
 address ranges, typically by 100s I believe, and it gets even more fun
 when they have a range, for example 9100-9198, then if someone actually
 lives at 9100, they'll store another value there for the supposed privacy
 protection of the person living at 9100.  I believe it's due to something
 called "Title 13" somewhere in federal statutes.

 One thing I'm not sure if this has contributed to some of the reported
 errors, but there is no guarantee in TIGER that fromhn < tohn.  The from
 and the to correspond simply to the drawing order of the points in the
 street edge geometry, so that if the points were entered in opposition to
 address flow order, then fromhn will be > tohn.  They are ''usually''
 consistent between the assignment of the 'L' or 'R' in the side of street
 in the addr table and the edge geometry.  But I believe there would then
 be cases in the line interpolation that if the initial % comes out as 60,
 you would want to convert that to 40.

 Then, as far as dealing with the 'squishing' effect because of true vs.
 theoretical address ranging, there will occasionally be addressing
 jurisdictions where true and theoretical coincide pretty well.  For
 example, in Boulder CO I noticed that house numbers jump by more than two
 as you go up the street, so the theoretical address range will be more
 completely used.  Here in the Austin TX area, house numbers jump by 2.

 I've never come up with a good idea how to overcome the squishing if you
 do not have some clear idea what the max true address on a segment is.
 Perhaps some kind of statistical thing that builds over time for an area
 that observes that addrs are likely being squished?  That wouldn't be very
 reliable.

 I do believe google makes heavy use of actual parcels with stored true
 addresses.  You sure see them displayed often, and my own address appeared
 smack in the middle of my displayed parcel.

 I never considered the interpolation error of failing to assume the house
 is not right on the lot line for the lowest and highest addresses on a
 segment (i.e., not nudging them inward).  The squishing effect is so
 extreme, it never occurred to me

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/1052#comment:25>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.