Fails to parse certain US address (Like the ones on Highways)

[ChandanNM]

We are using this library in our application. Has worked fairly well for most of the US addresses, however fails for certain unusual valid ones like - "N95W18000 Appleton Ave, Menomonee Falls, WI 53051" or other highway addresses. Can this library be enhanced to handle those ?

[hassansin]

I'm getting following for the above address:

{ street: 'N95W18000 Appleton',
  type: 'Ave',
  city: 'Menomonee Falls',
  state: 'WI',
  zip: '53051' }

Is it supposed to be different?

[simpixelated]

Not sure how common this is, but when there's a street type in the name of the street, I'm getting incorrect results. e.g. "3180 N Harbor Dr, San Diego, CA 92101, USA" results in:

{number: "3180", street: "N", type: "Harbor"}

Will need to dig into the code to see if there's an easy fix, but maybe you could look for two occurrences of type and assume the first one is meant to be part of the street name?

[cgirod3]

+1 to ^. I came here with a similar issue, 34 E Terrace Ave, Flagstaff, Arizona 86001, United States fails to parse, likely due to Terrace being a type? Not sure if this is being monitored still.

Also potentially unrelated, 540 E, Ogden, Utah 84404 fails to parse though is valid

[aannecchiarico]

Fails to parse highway addresses for example: "112 LEE RD 795"

[cody-lettau]

Has anyone figured out a fix for these issues?

[liamhession]

The case of "3180 N Harbor Dr, San Diego, CA 92101, USA" not being parsed correctly, plus others I've seen, is fixed by removing the ", USA" portion. So if you input "3180 N Harbor Dr, San Diego, CA 92101" at http://hassansin.github.io/parse-address/ you'll see it parsed as desired.

[canand2810]

Hello all this address => 2631 HIGHWAY J BOURBON MO 65441 is getting parsed like below "number": "2631", "street": "HIGHWAY", "city": "J BOURBON", "state": "MO", "zip": "65441" } But i think the street should be HIGHWAY J. Is there a fix for this