3

I'm having difficulty with the Google maps V3 JavaScript elevation service.

According a google groups posting ( https://groups.google.com/forum/#!msg/google-maps-js-api-v3/Z6uh9HwZD_k/G1ur1SJN7fkJ ), it appears that if you use getElevationAlongPath() it compresses and sends the entire path to the Google server as an Ajax GET request and subsamples it on their server. This means that if you have a large number of path segments the encoded URL exceeds the maximum URL length and the request fails with UNKNOWN_ERROR.

Can anyone confirm that this is a URL length issue?

I've tried doing my own subsampling along the path and sending just the points I want elevation data for as a getElevationForLocations() request. This does seem to be an improvement, but I'm still getting some UNKNOWN_ERROR responses. These occur unpredictably. Sometimes a request with 400 points returns successfully. Other requests will fail with only 300 points passed. I'm guessing that this still a problem with URL length (presuming getElevationForLocations() also sends URL-encoded data to Google).

The documentation says that "you may pass any number of multiple coordinates within an array, as long as you don't exceed the service quotas." This doesn't seem to be the case.

Does anyone have any suggestions for a reliable way to get a large number of elevation data points (500?) from a long path?

Thanks, Colin

After a bit more digging, this seems to be the situation.

The JavaScript API for elevation uses the HTTP elevation service behind the scenes. The HTTP elevation service docs do say that requests are limited to 2048 characters. However, if you're using the HTTP service directly, you build you're own URLs. This means you can check the length before sending. If you use the JavaScript API, the URL is built for you, but the API code doesn't check the URL length before sending.

The call end-point URL and the necessary parameters take up 78 characters leaving 1970 for the encoded points.

This is where it gets messy. The number of characters in an encoded point varies with the size and precision of the lat and lng values. Generally, somewhere between 8 and 12 characters per point. An added complication is that some of the characters used in the path encoding may need URL-encoding - further increasing the number of characters needed per point by an unknown, but potentially significant amount (2 extra characters for each path character in need of URL encoding).

All of these complications mean that its theoretically possible for a call to result too long a URL with just 55 points - very, very unlikely though. A safe limit is probably 150 points (but this may still fail occasionally). 200 should work most of the time. 250 should be about the maximum.

In reality, from a small number of tests: - 200 worked every time - 300 usually works - 400 sometimes works

The discrepancy between the calculation and the tests suggests that the JavaScript API may be doing some further form of compression or I've got something wrong in calcs?

casperOne
  • 73,706
  • 19
  • 184
  • 253
ColinK
  • 31
  • 2
  • Do you have a link to an example that reproduces this? – bamnet Jul 10 '12 at 22:48
  • To replicate go to http://gb.mapometer.com/cycling/route_2113760.html then click on the 'show altitude' button (bottom left of the map). There's a long pause then the UNKNOWN_ERROR. I've traced this through with a debugger and the data being sent seems fine. – ColinK Jul 11 '12 at 17:30
  • Thanks for this question @ColinK, I'm facing the same issue as you, I'm in need of sending multiple locations for the elevation requests but the URI becomes too big for the protocol to accept and handle it. Seems like I'll have to do these requests multiple times. If you have any word of advice, 4 years down the road, please let me know :) – RainierMallol Jun 17 '16 at 03:59

1 Answers1

2

Your suspicions are correct, this is a URL length issue. If you have Chrome's Developer Tools open when you submit the request you'll see an HTTP 414 (Request-URI Too Large) error. The URL is around 3000 characters which is about 1000 too many (2048 is a common max url length).

Internally the Google Maps API converts all those points to what looks like an encoded polyline which helps compress that data down, but it's clearly not enough for this really long path. It might be worth splitting the request up into multiple segments when you know your going to be including more than N points (I'd experiment around with N to see what works).

bamnet
  • 2,525
  • 17
  • 21
  • Thanks for the extra info - helpful. If they use a compression similar to that for encoded polylines it would require 10 bytes per point. The limit should therefore be around 200 points (right ballpark). It should also, however, be a fixed number (for a given browser). I haven't found this to be the case. As I said above sometimes 400 points works and sometimes 300 fails. – ColinK Jul 11 '12 at 20:23
  • The fact that the data is URL-encoded means that the service is fundamentally incapable of delivering what the docs describe. Its a very odd design choice to use a GET request when so much data might be sent. Why not POST? – ColinK Jul 11 '12 at 20:28