The open.mapquestapi.com API no longer works

[jmathai]

Calls to open.mapquestapi.com redirect to their updated API page. The new API is not backwards compatible and causing tests to fail.

[clach04]

I was going to open a similar issue :-)

I've jotted some notes down below however progressing this is not a priority for me, I'm putting my time into adding support for reverse_geocoder/reverse_geocode (offline) - longer term (and possibly a research path that may be worth checkout out), checkout https://github.com/geopy/geopy it supports MapQuest and a lot of other providers. I've not used it so can't vouch for it other than a cursory read.

reverse_geocoder/reverse_geocode with my minimal testing is looking suitable, I need to crunch it through my photos to see if it actually is suitable for my use case 🤞

NOTES:

• MapQuest base URL has changed
• actual url has changed (no php)
• arguments have changed
• payload has changed and parse_result() has no idea

URL and api change

old sample

https://open.mapquestapi.com/nominatim/v1/reverse.php?format=json&key=KEY_GOES_HERE&lat=37.7719809722222&lon=-122.298968972222

new sample

http://www.mapquestapi.com/geocoding/v1/reverse?key=KEY_GOES_HERE&location=37.368,-122.03&includeRoadMetadata=true&includeNearestIntersection=true

Payload change

parse (etc.) are expecting a dict like (note mappings in comments):

{
    'address': {
        'default': u'California',
        'country': u'United States of America',  # MapQuest field: ["results"]["locations"][0]["adminArea1"]  "US"
        'state': u'California',  # MapQuest field: ["results"]["locations"][0]["adminArea3"]  "CA"
        'city': u'Sunnyvale'  # MapQuest field: ["results"]["locations"][0]["adminArea5"]  "Sunnyvale"
    }
}

Current mapquest payload looks more like:

{
  "info": {
    "statuscode": 0,
    "copyright": {
      "text": "© 2022 MapQuest, Inc.",
      "imageUrl": "http://api.mqcdn.com/res/mqlogo.gif",
      "imageAltText": "© 2022 MapQuest, Inc."
    },
    "messages": []
  },
  "options": {
    "maxResults": 1,
    "ignoreLatLngInput": false
  },
  "results": [
    {
      "providedLocation": {
        "latLng": {
          "lat": 37.368,
          "lng": -122.03
        }
      },
      "locations": [
        {
          "street": "312 Old San Francisco Rd",
          "adminArea6": "Heritage District",
          "adminArea6Type": "Neighborhood",
          "adminArea5": "Sunnyvale",
          "adminArea5Type": "City",
          "adminArea4": "Santa Clara",
          "adminArea4Type": "County",
          "adminArea3": "CA",
          "adminArea3Type": "State",
          "adminArea1": "US",
          "adminArea1Type": "Country",
          "postalCode": "94086",
          "geocodeQualityCode": "P1AAA",
          "geocodeQuality": "POINT",
          "dragPoint": false,
          "sideOfStreet": "R",
          "linkId": "0",
          "unknownInput": "",
          "type": "s",
          "latLng": {
            "lat": 37.36798,
            "lng": -122.03018
          },
          "displayLatLng": {
            "lat": 37.36785,
            "lng": -122.03021
          },
          "mapUrl": ""
        }
      ]
    }
  ]
}

[jmathai]

payload has changed and parse_result() has no idea

🤣 That's the quick conclusion that I came to. I believe the fix should be isolated though.

[jmathai]

Documenting some inconsistencies with the MapQuest API and how to detect errors.

1. ['info']['statuscode'] != 0 means an error (docs).
2. ['options']['maxResults'] == -1 means Not Found (I think). And the case is not consistent between statuscode and maxResults.
   • However, it does not mean that ['results'] or ['results']['locations'] have a length of 0.

Edit: I'm not sure what maxResults == -1 means but it DOES NOT mean Not Found. I also believe the following is true: the data itself has changed (i.e. lat/lon for Sunnyvale, CA is different now and CA is returned instead of California.

[jmathai]

I created branch mapquest-fix to stage my work so far which can be tracked in gh-426.

[jmathai]

Took a break and came back with a much simpler change to get it working. @clach04 thanks for the comment - it got me thinking differently about the fix.