[postgis-tickets] [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.1.0
 Component:  tiger geocoder  |     Version:  trunk        
Resolution:                  |    Keywords:               
-----------------------------+----------------------------------------------

Comment(by robe):

 Hi all,

 Regarding parcel data. I agree a lot of states have it e.g. MA has pretty
 much full set for the whole state and I use just the Boston piece which I
 get directly from Boston Assessing source so is more detailed.  But I
 think as Steve alluded to, the structure is not consistently kept across
 all states unless you go with a single source like Navteq that has already
 standardized it for you and then for my purposes I care about parcel data
 a lot so I have it more integrated in my workflow than any geocoder can
 and I suspect it might be the case with others wanting that level of
 geocoding. That they wouldn't want to keep two sets when they've got a
 super detailed one handy already.

 On another note, while all these considerations are important, I don't
 want to lose site of my primary goal. That is not to be the very best
 geocoder (or even compete with Google et. al) but  basically creating a
 lightish-weight geocoder that is good-enough for general use and easy
 enough to install for any PostGIS installation.

 Piling on more data, while making the geocoder more accurate I think will
 move it further away from grasp of your general user since it would
 require more disk space, more prepping etc.


 So priority wise, I want to focus on improving the normalization routines
 -- that to me is the biggest bang for the general user right now (it will
 mean better accuracy and speed (you won't be having those 1 minute calls
 in the every 100 30 ms calls) and that already is a bagfull) -- which I've
 been working with Steve to see if I can integrate his PAGC normalizer.  So
 that's where I am with all this.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/1052#comment:29>
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.