normalize_address() confused by internal component

[mikepease]

There are certain cases where normalize_address() incorrectly parses the address.

Consider an address with no street type like below AND an internal component. Remove the internal component and it works. Or add a street type and it works.

—INCORRECT select * from normalize_address('901 Mainstreet Fl 1 Hopkins MN 55343')

—INCORRECT select * from normalize_address('901 Mainstreet, Fl 1, Hopkins, MN 55343')

—CORRECT! select * from normalize_address('901 Main street, Fl 1, Hopkins, MN 55343')

—CORRECT! select * from normalize_address('901 Mainstreet Hopkins MN 55343')

[mikepease]

Another example:

select * from normalize_address('2301 BEACH FRONT LN SW, Rochester, MN 55902') —Gets confused by "FRONT" in street name —Remove "FRONT" from secondary_unit_lookup table and the normalizer works correctly.

[mikepease]

—This also normalizes and subsequently geocodes correctly by adding a hyphen.

select * from normalize_address('2301 BEACH-FRONT LN SW, Rochester, MN 55902')

[mikepease]

Another example:

select (addy).*, rating from geocode('5435 US HIGHWAY 14, ROCHESTER, MN 55904') —This gets the correct location, but take out "US" and it gets the wrong address number

—Wrong answer select (addy).*, rating from geocode('5435 HIGHWAY 14, ROCHESTER, MN 55904')

—Also wrong answer select (addy).*, rating from geocode('5435 HWY 14, ROCHESTER, MN 55904')

[woodbri]

PAGC tools handles Mainstreet Fl 1 correctly, and the Beach Front Ln with and without the hyphen, and US HWY 14 and HWY 14 (this last one is more related to how the geocoder constructs the queries, my geocoder get the same location for both of these).

[woodbri]

My last comment might be slightly incorrect with respect to the split word like beach front. The standardizer will standardize them, but searching for them still requires some kind of fuzzy searching. My geocoder finds some of these. But this is a larger discussion about how to do fuzzy searching that we should do in email, and then summarize in another ticket.

[robe]

Seems to work well:

SELECT  pprint_addy(a), a.internal 
   FROM pagc_normalize_address('901 Mainstreet Fl 1 Hopkins MN 55343') As a;

Yields:

                 pprint_addy                  | internal
----------------------------------------------+-----------
 901 MAINSTREET, # FLOOR 1, HOPKINS, MN 55343 | # FLOOR 1

— this one might have been caused by my over abbreviating —

SELECT pprint_addy(a), a.streetname, a.location, a.stateabbrev 
  FROM pagc_normalize_address('2301 BEACH FRONT LN SW, Rochester, MN 55902') AS a;
-- but still acceptable -- 
                pprint_addy                | streetname | location  | stateabbrev
-------------------------------------------+------------+-----------+-------------
 2301 BCH FRONT Ln SW, ROCHESTER, MN 55902 | BCH FRONT  | ROCHESTER | MN

SELECT pprint_addy(a), a.streetname, a.location, a.stateabbrev, a.predirabbrev, a.postdirabbrev
  FROM pagc_normalize_address('2301 BEACH FRONT LN Southwest, Rochester, MN 55902') AS a;

                pprint_addy                | streetname | location  | stateabbre
v | predirabbrev | postdirabbrev
-------------------------------------------+------------+-----------+-----------
--+--------------+---------------
 2301 BCH FRONT Ln SW, ROCHESTER, MN 55902 | BCH FRONT  | ROCHESTER | MN
  |              | SW

Anyrate will consider it a non-issue now.

[robe]

yap I was over abbreviating. the original pagc tables were fine.now it returns

BEACH FRONT as it should at r11244