Latitude/Longitude - major defect (multiple MapQuest API)

6 posts / 0 new
Last post
webaccount
Latitude/Longitude - major defect (multiple MapQuest API)

MapQuest APIs are not responding with the correct Latitude and Longitude.

 

I've been leveraging the place-search.js solution for when we are unable to grab coordinates from the users local machine.  The problem is that results coming back from the API are dropping trailing 0's.  This results in the user location shifting locations in certain scenarios.  Take the following example:

  1. Search for 3032 Riders Pass, Odessa, FL 33556
  2. Response comes with the following latitude & longitude:
    • 28.20248
    • -82.608696
  3. When we use that latitude and longitude on the MapQuest map, the location renders as 3036 Riders Pass (or google the coordinates for that matter)
  4. The actual latitude and longitude is as follows:
    • 28.202480
    • -82.608696
  5. Note the trailing zero was dropped by the MapQuest API up front.

This problem is not isolated to places-search.js and I believe is a fundamental flaw in the MapQuest Search API.  I suspect you are leveraging FLOAT for the data type which is NOT correct as that will drop all trailing zeros or Latitude/Longitude coordinates, resulting in all sorts of locations coming back wrong (especially with locations that have multiple trailing 0s).

Please let me know if there is an option for this to be patched or I will need to reach out for a refund on my account as my companies' enterprise product cannot function with this break.

 

Also, places-search.js has compatibility issues with IE 11 which surprises me as I'd expect that to be a supported browser.  Error code below:

'URLSearchParams' is undefined

 

I'm quite happy with the other functionality, stability, etc... but these two bugs are simply unmanagable.


MQBrianCoakley
The issue is the two

The issue is the two different methods used to find addresses. The search for 3032 Riders Pass uses the geocoder which returns two lat/lngs: one for routing (snapped to the road) and one for display (over the parcel, building or other display indicator). In this case, the result is a point geocode which is an address specific location.

 

Reverse geocoding the geocode response is returning in interpolated address which may or may not match the geocode input since interpolation is an educated guess, not exact. The reverse geocoder is not intended to return exact addresses in all cases. While 200 million addresses are supported, not all are address points and the process falls back to interpolated data. This is not unexpected.

 

What actions lead to the IE11 issue? Do you see it on load, on input, on send, on return?


webaccount
Thanks so much for the

Thanks so much for the response Brian.  I'm not very clear on your commentary regarding the geocoder.  Are you saying the lat/lng response of places-search.js for a specific address should be assumed as incorrect?  What seems odd is locations without trailing 0s don't seem to be having the problem, it is only locations that have trailing 0s.

 

IE11 issue occurs immediately on loading, error provided happens on page load and points to places-search.js.  Tested on multiple OS (Win 7 & 10) in both a physical computer and virtual machines.

 

Thanks again for the quick response and look forward to your thoughts.


MQBrianCoakley
The search result/geocode and

The search result/geocode and the reverse geocode result may not be the same. Reverse geocode is usually interpolated and will vary.

 

I'll look into the IE11 issue soon.


webaccount
You've mentioned this but I

You've mentioned this but I keep defering you back to my original comment.  The geo coordinates (lat/lng) returned by place-search is WRONG.  Other providers in the market do not have the same problem so this is not a reverse geocode result problem, it is that the search is wrong.


MQBrianCoakley
When geocoding the original

When geocoding the original address, the quality code returned is P1AAA which is from the address point geocode data set. The displayLatLng is over the parcel and the latLng is snapped to the road. The trailing zero is dropped from the display latitude. 

 

Reverse geocoding either of the provided lat/lng returns a result with quality code L1AAA which is from an interpolated data set. The reverse geocode result is the same with or without the trailing zero. This is not unexpected given that the result is interpolated.