Google マップ V3 JavaScript 標高サービスに問題があります。
Google グループの投稿 ( https://groups.google.com/forum/#!msg/google-maps-js-api-v3/Z6uh9HwZD_k/G1ur1SJN7fkJ ) によると、 getElevationAlongPath() を使用すると圧縮して送信されるようですGoogle サーバーへのパス全体を Ajax GET リクエストとして取得し、サーバー上でサブサンプリングします。これは、多数のパス セグメントがある場合、エンコードされた URL が URL の最大長を超え、リクエストが UNKNOWN_ERROR で失敗することを意味します。
これが URL の長さの問題であることを確認できる人はいますか?
パスに沿って独自のサブサンプリングを行い、標高データが必要なポイントだけを getElevationForLocations() リクエストとして送信してみました。これは改善されているようですが、まだ UNKNOWN_ERROR 応答が返されます。これらは予期せず発生します。場合によっては、400 ポイントのリクエストが正常に返されることがあります。他のリクエストは失敗し、300 ポイントしか渡されません。これはまだ URL の長さに問題があると思います (getElevationForLocations() も URL エンコードされたデータを Google に送信すると仮定します)。
ドキュメントには、「サービス クォータを超えない限り、配列内で任意の数の複数の座標を渡すことができる」と記載されています。そうではないようです。
長いパスから多数の標高データ ポイント (500?) を取得するための信頼できる方法について何か提案はありますか?
ありがとう、コリン
もう少し掘り下げた後、これが状況のようです。
昇格用の JavaScript API は、バックグラウンドで HTTP 昇格サービスを使用します。HTTP 昇格サービスのドキュメントによると、リクエストは 2048 文字に制限されています。ただし、HTTP サービスを直接使用している場合は、独自の URL を作成します。これは、送信前に長さを確認できることを意味します。JavaScript API を使用する場合、URL は作成されますが、API コードは送信前に URL の長さをチェックしません。
コール エンドポイントの URL と必要なパラメータは 78 文字で、残りの 1970 はエンコードされたポイントです。
ここがぐちゃぐちゃになります。エンコードされたポイントの文字数は、緯度と経度の値のサイズと精度によって異なります。通常、1 ポイントあたり 8 ～ 12 文字です。追加の複雑さは、パス エンコーディングで使用される文字の一部が URL エンコーディングを必要とする可能性があることです。ポイントごとに必要な文字数は、未知ではあるが潜在的にかなりの量 (URL エンコーディングが必要なパス文字ごとに 2 文字余分に) 増加します。 ）。
これらすべての複雑さは、理論的には呼び出しが 55 ポイントの非常に長い URL になる可能性があることを意味しますが、非常にありそうもないことです。安全な制限は、おそらく 150 ポイントです (ただし、これでも失敗することがあります)。ほとんどの場合、200 で機能します。250 が最大値に近いはずです。
実際には、少数のテストから: - 毎回 200 が機能しました - 300 は通常機能します - 400 は時々機能します
計算とテストの不一致は、JavaScript API が何らかの形式の圧縮を行っている可能性があること、または計算に問題があることを示唆していますか?