[postgis-devel] [PostGIS] #1118: Street pretypes that aren't directional prefixes

[PostGIS]

#1118: Street pretypes that aren't directional prefixes
----------------------------+-----------------------------------------------
 Reporter:  robe            |       Owner:  robe         
     Type:  defect          |      Status:  new          
 Priority:  medium          |   Milestone:  PostGIS 2.0.0
Component:  tiger geocoder  |     Version:  1.5.X        
 Keywords:                  |  
----------------------------+-----------------------------------------------

Old description:

> Example:
>
> Camino del Rio is an example as noted in:
> http://www.postgis.org/pipermail/postgis-users/2011-July/030152.html
>
> normalize_address doesn't handle these at all and tiger data is
> inconsistent as to how it represents these.
>
> So for example:
>
> In tiger: Camino del Rio is represented as having
>
> fullname:
> Cam del Rio
>
> name:
> del Rio
>
> and pretypabrv:
> Cam
>
> But in other locations of the world you'll see it listed as
>
> fullname:
> Cam del Rio
>
> no pretyabrv
>
> The two wasy to handle this would be to introduce a new:
> norm_addy object -- the pretypabbrv
>
> and another table to store these lookup alternative spellings
> and changing geocode to handle this new field and changing the
> normalize_address as well.
>
> OR (2) which I am leaning toward.
>
> have a pretypeabbrv lookup and just during the geocode process,
> compare tiger street names against all normalized street name forms (e.g.
> basically replacing any of these if they start at the beginning of the
> streetname with the abbreviated form and comparing with the
> normalize_address.
>
> Option 2 seems much easier to implement and will also handle many cases
> such as the case of St. vs. Saint.

New description:

 Example:

 Camino del Rio is an example as noted in:
 http://www.postgis.org/pipermail/postgis-users/2011-July/030152.html

 normalize_address doesn't handle these at all and tiger data is
 inconsistent as to how it represents these.

 So for example:

 In tiger: Camino del Rio is represented as having

 fullname:
 Cam del Rio

 name:
 del Rio

 and pretypabrv:
 Cam

 But in other locations of the world you'll see it listed as

 fullname:
 Cam del Rio

 no pretyabrv

 The two wasy to handle this would be to introduce a new:
 norm_addy object -- the pretypabbrv

 and another table to store these lookup alternative spellings
 and changing geocode to handle this new field and changing the
 normalize_address as well.

 OR (2) which I am leaning toward.

 have a pretypeabbrv lookup and just during the geocode process,
 compare tiger street names against all normalized street name forms (e.g.
 basically replacing any of these if they start at the beginning of the
 streetname with the abbreviated form and comparing with the
 normalize_address.

 Option 2 seems much easier to implement and will also handle many cases
 such as the case of St. vs. Saint.


 Example to test:


 So now:

 {{{
 SELECT pprint_addy(addy), ST_AsText(geomout), rating
 FROM geocode('477 Camino del Rio South, San Diego, CA 94115');
 }}}

--

Comment(by robe):

 actually highways are on this list so I have partially taken care of this
 in r7641 by gluing this on to front.  Solution for things like Camino
 probably easiest to mark them as highways.  Only issue I have now is that
 if I add Camino to list of street types as and mark as a highway, my
 normalize cuts of the Rio.  This is yet another bug in the normalizer
 which I have to address.

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