I am basically doing
UsaGeocoder usaGeocoder = new UsaGeocoder("/path/to/data");
usaGeocoder.MatchMode = MatchMode.ExactMatch;
Collection<geocodermatch> matchResults = geocoder.Match("2014 Bennet Ave", "75206");
and am getting a single match back that has name-value pairs of [Street, Bennet Drive] and [Zip, 27520].
That seems way off. I would prefer it return no match rather than a match halfway across the country. Is there something else I need to set, or is this a bug? Incidentally,
Collection<geocodermatch> matchResults = geocoder.Match("2014 Bennet Ave", "DALLAS", "TX");</geocodermatch>
gives the same result, but I do note that if I do just
matchResults = geocoder.Match("75206");
I do get a single match back that has a correct name-value pair of </geocodermatch>[Zip, 75206].
I am basically doing
I was unable to recreate this issue, It worked fine on my side. What’s the version do you reference? Could you please attach the data here? It’ll help me to reproduce this issue.
Well, the MapSuiteGeocoder.DLL is version 18.104.22.168. The Geocoder data set was downloaded on 17Aug2015; I don’t see anything in there that signifies a version, but the newest file in there is the zipBBX.txt, dated 22Jun2015.
I’ve added an example that demonstrates the issue, for me at least. And I had the street wrong above, it was “2014 BENNENT AVE”.
AddressBug.zip (26.8 KB)
Thanks for your sample. The UsaGeocoder will math the closest house number if there is no street found or StreetNumberMatchingMode is ClosestMatch. Please try using the Geocoder.
Here attached is the sample.
003_002_001_GeoCoderBug.zip (4.25 KB)
Hi Peter, thanks for the sample. A couple observations:
Both google maps and bing find this address (though google’s suggestion starts out with the 27520 match). OpenStreetMap does not. I assume this is a data related issue, then, and OSM just does not have it in the data set, and hence neither does the GeoCoder?
In your sample, using the StreetMatchingPlugin alone provides no matches; I need to add at least the ZipDbfMatchingPlugin to get any matches, presumably for the same reason as above?
It looks like the UsaGeocoder’s StreetMatchingPlugin already has StreetNumberMatchingMode set to ExactMatch. But even if I explicitly create it as
UsaGeocoder usaGeocoder = new UsaGeocoder(dataPath, StreetNumberMatchingMode.ExactMatch);
it still returns the Bennent Drive, 27520 match. It would be nice if there was some way to tell it to pay more attention to the zip than the street, so that even if it can’t find a street match, you would at least get the right city.
I guess the reason why it gets the not matched results is that the street name is incorrect. It should be 2014 Bennett Ave not 2014 Bennent Ave.
As I mentioned before, the UsaGeocoder will math the closest house number if there is no street found or StreetNumberMatchingMode is ClosestMatch. For example we search “2014 BENNENT Ave 75206” and there is no street found and then it will get the result by the order: “BENNENT”, “BENNENT AVE” and then get the closest house number on the streets. So it will return the Bennent Drive, 27520 match.
I think good way for you to pay more attention to the zip is using the ZipDbfMatchingPluging to match by Zip if detects the zip is incorrect.
Hope it’s helpful.
So, I understand the name mismatch, that is, the address is incorrect and it should be Bennett.
And I guess I understand that it then tries to find a matching street for BENNENT AVE and then just BENNENT and eventually finds BENNENT DRIVE. But it seems like it should also look at the second part of the information it is given and consider the zip code and use that to determine that it is in fact not a match.
To put this another way, if I do
Collection<geocodermatch style=“color: #333333; font-family: frobisherlight, arial, helvetica, sans-serif; line-height: 18.2px;”> matchResults = geocoder.Match(“510 PARK AVE”, “75206”);
</geocodermatch>I get no results. Why don’t I get back a match of “PARK DRIVE”, “27520” ? What’s special about “BENNENT”?
But yes, I’ve added zip code validation to make sure that the result matches the given zip code, it just seems like I shouldn’t have to do that.
Here are more details to explain the behaviors you met.
Basically, when we search for a street with a zip code, we think the street name is the key part with the highest priority and the zip code is only treated as a filter condition. If there is no matched result by the street name part, then it will return no result. If we found some results simply with street name, then we will use the zip code to filter the results. However, there did have one special case: if there is only one matched result found with street name, then it will not go into use the zip code filter any more, we believe this is an enhancement to improve the user experience like other map services like Google or Bing, you can try “510 PARK AVE 75206” in Google Map and the google map will correct it as “510 Park Ave 75201”.
Therefor, for the “Bennent Ave, 75206”, we can find a match by “Bennent Ave”, we can find only one street item matched, then we will not use the zip code filter and use the matched zip code instead. But for “510 PARK AVE 75206”, we can find a lot of “Park Ave”, but none of them are verified by “75206” zip code, so, no matched item returned.
Actually, I would prefer you to use Match(string searchText), it will include zip info no matter whether there is a street is found. For your case, you can use some codes as below to fit your requirement:
//matchResult = usaGeocoder.Match(“Bennent Ave 75206”);
matchResult = usaGeocoder.Match(“Park Drive 75206”);
foreach (GeocoderMatch item in matchItems)
if (item.NameValuePairs[“Zip”] == zipcode)
// exactly what we need to find.
// zip code is not incorrect. let’s get zip code info.
else if (item.NameValuePairs.ContainsKey(“Zip”))
// let’s get the zip info
Please let us know if you have any questions.
Hi, Troy. Thanks for the explanation. I’ve updated my code to do zip code validation.
Any question please let us know.