[postgis-devel] [PostGIS] #1052: Tiger Geocoder 2010 Geocode() "squishing" toward end of block
PostGIS
trac at osgeo.org
Fri Oct 14 17:52:05 PDT 2011
#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.
More information about the postgis-devel
mailing list