Street number is getting identified as house number suffix in US_ADDR ruleset.
Source Input: "50 THREE LAKES DR"
House Number: 50
House Number Suffix: 3
Street Name: LAKES
Street Suffix Type: DR
"3" is geting identified as House Number Suffix where idealy it should be either Street Name or, Street Name prefix.
Is there any other solution other than pattern overriding like editing classifications file.
Street number is geting identified as house number suffix
-
- Premium Member
- Posts: 425
- Joined: Sat Nov 19, 2005 9:26 am
- Location: New York City
- Contact:
Yes, you can edit the classification table for this entry and assign any other class instead of the default "C" (Cardinal Number)...but that will bring other issues when "Three" really mean "3"
I would stay put with the Input pattern overrides
I would stay put with the Input pattern overrides
Julio Rodriguez
ETL Developer by choice
"Sure we have lots of reasons for being rude - But no excuses
ETL Developer by choice
"Sure we have lots of reasons for being rude - But no excuses
Input Records:
CASE 1 : 408-10 CARPENTER AVE NEWBURGH NY 12550
CASE 2 : 2-1 CANTERBURY CT MIDDLETOWN CT 06457
CASE 1 - Actual output from USPS
---------------------------------
408 CARPENTER AVE APT 10
NEWBURGH NY 12550-3352
CASE 2 - Actual output from USPS
---------------------------------
2-1 CANTERBURY CT
MIDDLETOWN CT 06457-4924
How to handle pattern overrides in these cases for the same(syntax) address values,
wherein one case it resolves to Streetnumber/Streetnumber suffix
and in anohter it resolves to Streetnumber and House Number.
CASE 1 : 408-10 CARPENTER AVE NEWBURGH NY 12550
CASE 2 : 2-1 CANTERBURY CT MIDDLETOWN CT 06457
CASE 1 - Actual output from USPS
---------------------------------
408 CARPENTER AVE APT 10
NEWBURGH NY 12550-3352
CASE 2 - Actual output from USPS
---------------------------------
2-1 CANTERBURY CT
MIDDLETOWN CT 06457-4924
How to handle pattern overrides in these cases for the same(syntax) address values,
wherein one case it resolves to Streetnumber/Streetnumber suffix
and in anohter it resolves to Streetnumber and House Number.
vimal.R
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
- Premium Member
- Posts: 425
- Joined: Sat Nov 19, 2005 9:26 am
- Location: New York City
- Contact:
By default the tool will show results as expected by case No. 2 records. Because both cases contradict each other and to avoid changing the default behavior of the tool the approach should lean toward addressing the exception, case No.1, only
I would treat those records after the standardization process.The User Override GUI don't allow to conditionally take actions on a token, based on the value of another one. Anyway in a transfomer is a lot easier and you have more control. Pick those records where City/State is NEWBURGH/NY (Could be a list, so would like to investigate other cities where the addresses follow same standard), take the HouseNumberSuffix where not null and move it to HouseUnitValue
Input Text override is a better approach, but in this case the USADDR Rule Set will consider "408-10" and "2-1" as one single token, and the tool as I mentioned before in the GUI , don't allow substring or range actions on a single token
I would treat those records after the standardization process.The User Override GUI don't allow to conditionally take actions on a token, based on the value of another one. Anyway in a transfomer is a lot easier and you have more control. Pick those records where City/State is NEWBURGH/NY (Could be a list, so would like to investigate other cities where the addresses follow same standard), take the HouseNumberSuffix where not null and move it to HouseUnitValue
Input Text override is a better approach, but in this case the USADDR Rule Set will consider "408-10" and "2-1" as one single token, and the tool as I mentioned before in the GUI , don't allow substring or range actions on a single token
Julio Rodriguez
ETL Developer by choice
"Sure we have lots of reasons for being rude - But no excuses
ETL Developer by choice
"Sure we have lots of reasons for being rude - But no excuses