Need support - wacky results

4 posts / 0 new
Last post
pnoonan
Need support - wacky results

The API is not able to find the following addresses:

  • 141 E 4th St., St. Paul, MN 55101, United States
  • 141 E 4th St, Saint Paul, MN 55101, United States

Sometimes, if I'm typing it into Mapquest.com and not running it through my application code, it is able to find this address:

  • 141 E 4th St, Saint Paul, MN 55101

Any reason why this or any other address would be so difficult for Mapquest to locate? 

In the past, I'd run into issues with the address lookup and the response was that I needed to include "United States". In this case, it seems like including the country is detrimental. In my application code, the API seems to be responding with its first "best guess", which can be hundreds of miles off. I can't see anything in the response to indicate that it has a low level of confidence, etc., other than, say, that the zip code is different. 

Is there anything we can do with results like this? We do have a paid subscription to this service. We are using the results to calculate mileages and fuel costs. The inconsistency and unpredictability here makes this API very difficult to work with. According to our clients, this seems to have happened a couple of times in the last week or so.


MQBrianCoakley
Thanks for the information.
Thanks for the information. This has been forwarded to the geocode team's bug queue. There are several things being mishandled in this particular instance (E 4th St vs 4th St E, St vs Saint, and returned quality codes) so I'm not sure how to better handle this one. But in general, using the quality code should indicate how a result is handled whether it be used, ignored, or ask the user for more information.

pnoonan
Thanks for submitting the bug

Thanks for submitting the bug report. In this case, the quality code is "L1BAC". Breaking this down, it means:

  • L1: that Mapquest found a street location
  • B: confidence in the street name is "good - should be fairly similar, even if not exactly as specified."
  • A: confidence in the Adminitrative area is "exact - locations that exactly correspond to the input location, as defined by the address elements specified."
  • C: confidence in the Postal Code is "approx - should be somewhat similar to the input location as specified.

http://www.mapquestapi.com/geocoding/geocodequality.html#granularity

In our case, the field that has the highest level of confidence, the Administrative Area, is actually very far off. I'm not sure how we are supposed to guage by these confidence codes whether or not the result is suitable for actual use. We would almost need to develop some sort of scoring system. "Approx" or a "C" grade, to me, still would imply a sort of acceptable degree of confidence. Is that not the intent? Just wondering if this is part of the bug or if we should be filtering out anything that comes back with a C. 


MQBrianCoakley
The quality is part of the
The quality is part of the bug I forwarded to the team. There are at least 3 issues with this address. This one is a doozy. Let us know if there are any others.