海拔服务UNKNOWN_ERROR [英] Elevation service UNKNOWN_ERROR
问题描述
我在使用谷歌地图V3 JavaScript提升服务时遇到了困难。 根据谷歌组织发帖（ https://groups.google.com/forum/#!msg/google-maps-js -api-v3 / Z6uh9HwZD_k / G1ur1SJN7fkJ ），看起来如果使用getElevationAlongPath（），它会压缩并将整个路径作为Ajax GET请求发送到Google服务器，并在服务器上对其进行二次抽样。这意味着如果您有大量的路径段，则编码的URL将超过最大URL长度，并且请求会因UNKNOWN_ERROR而失败。
任何人都可以确认这是一个URL我试过沿着路径做自己的二次采样，只发送我想要的高程数据作为getElevationForLocations（）请求的点。这似乎是一种改进，但我仍然收到一些UNKNOWN_ERROR响应。这些发生不可预知的。有时400点的请求会成功返回。其他请求将失败，只有300点通过。我猜这仍然是一个URL长度问题（假定getElevationForLocations（）也会将URL编码数据发送给Google）。
文档说只要不超过服务配额，数组中的任何数量的多个坐标。这似乎不是这种情况。
有没有人有任何建议可靠的方法来获得大量的高程数据点（500？）从长如果您有任何疑问，请联系我们，谢谢！b
$ b
感谢，
科林
升级的JavaScript API在幕后使用HTTP提升服务。 HTTP提升服务文档确实表示请求被限制为2048个字符。但是，如果您直接使用HTTP服务，则会构建自己的URL。这意味着您可以在发送前检查长度。如果您使用JavaScript API，则会为您构建网址，但API代码在发送前不会检查网址的长度。
呼叫终点URL和必要的参数占用编码点的1970年剩下的78个字符。
这是一个混乱的地方。编码点中字符的数量随lat和lng值的大小和精度而变化。一般来说，每点有8到12个字符。另外一个复杂的情况是，路径编码中使用的某些字符可能需要URL编码 - 这会进一步增加每个点需要的字符数量，但数量可能会很大（但需要URL编码的每个路径字符会增加2个字符）。
所有这些复杂情况都意味着它在理论上可能会导致过长的网址，结果只有55分 - 但是非常非常不可能。安全限制大概是150分（但这可能偶尔会失败）。 200应该在大部分时间工作。 250应该是最大限度的。
实际上，从少数测试：
- 200每次工作
- 300通常工作
- 400有时可行
计算和测试之间的差异表明JavaScript API可能会进行某种进一步的压缩形式，或者出现了问题在计算中？
您的怀疑是正确的，这是一个URL长度问题。如果您在提交请求时打开Chrome的开发人员工具，则会看到HTTP 414（请求URI太大）错误。该网址约为3000个字符，大约有1000个字符（2048是常见的最大网址长度）。
Google Maps API内部将所有这些点转换为看起来像编码多段线有助于压缩数据，但这显然不够用真正漫长的道路。当你知道你的要求包含N个以上的分数时（我试着用N来看看有什么作用），可能有必要将请求分成多个分段。
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?
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).
这篇关于海拔服务UNKNOWN_ERROR的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
