Thread: Is US Dual Ranges broken in 10.0 sp4 if you map ZIP? very slow w/o?

Case 1:
Streets are in file geodatabase and mapped addresses, type, street name, etc.
Mapped L/R city
Mapped L/R State
Did not map L/R Zip
Results: very slow

Case 2:
Streets are in file geodatabase and mapped addresses, type, street name, etc.
Mapped L/R city
Mapped L/R State
Mappe L/R Zip 'CORRECTION: DID MAP L/R Zip Initial post had this incorrect'
Results: 0 candidates

Am I missing something? The L/R Zip is Canadian FSA, example: H3X

Originally Posted by harrybowman

Case 1:
Streets are in file geodatabase and mapped addresses, type, street name, etc.
Mapped L/R city
Mapped L/R State
Did not map L/R Zip
Results: very slow

Case 2:
Streets are in file geodatabase and mapped addresses, type, street name, etc.
Mapped L/R city
Mapped L/R State
Did not map L/R Zip
Results: 0 candidates

Am I missing something?

This might be a similar situation to a problem I was having a few weeks ago.

It seems that the 10.x locators are a little more particular than we've seen in the past; you may need to map your zip codes.

Originally Posted by harrybowman

Did an experiment. Instead of the real FSAs as Postal Code (ex: h3x) used a fake: 12345. Worked. OK....why?

Ohhhh.... Canandian data.... All bets are off! No; just kidding... Thats a really good question!