[postgis-devel] parse_address and standardize_address

[Stephen Woodbridge]

On 10/23/2014 8:24 PM, Brian M Hamlin wrote:
> Hi - a bit of feedback on the functions..
>
> I have three sets of address, in descending order of "cleanliness", and
> ran both functions on the three sets just now..
> PostGIS 2.2 trunk and Postgres 9.4b3  (yes three, typo in that ticket)
>
> epa_addrs2 16384;  chanced_addrs 11078; rec_addrs 25110
>
> epa_addrs2 has a lot of noisey and badly formatted addrs.. the other two
> have some ordinary problems
>
> parse_address(addr) does not need lex/gaz rules, and will do its best
> with whatever you throw at it.. meanwhile standardize_address(addr) does
> take lex/gaz rules, and did not complete two of the three sets.. I got
> an error condition returned
>
> ERROR:  standardize_address() can not be passed an intersection.
>    I have not characterized *all* the cases where this error is
> returned, but it seems like the phrase is covering more cases than a
> real "intersection". I will move on to the TIGER data in the geocoder
> rather than more of this right now, but I wanted to let people see this..

Brain,

This error message means the the address you passed in was was passed to 
parseaddress() and it interpreted the address as being an intersection. 
This is determined by the fact that parseaddress() return a value in the 
"street2" field.

You should be able to find these records with something like:

select * from mytable
  where (parse_address(address_field)).street2 is not null;

The function

   standardize_address('lex', 'gaz', 'rules', 'address string')

calls parse_address internally to split the address into micro and macro 
components.

You can avoid this by first calling parse_address() on your table to 
construct the micro and macro components, then calling

   standardize_address('lex', 'gaz', 'rules', micro, macro)

Hope this helps.

-Steve