はじめに - HERE Developer ポータル

このセクションでは、 HERE Developer ポータルで HERE GNSS サービスを使用してはじめにをすばやく実行する方法について説明します。

  1. HERE アカウントを取得
  2. アプリ を登録する
  3. API キー を入手
  4. リクエストを送信
  5. 次のステップ

このセクションでは、 HERE GNSS サービスの使用を迅速に開始するために必要な最小限の設定について説明します。

HERE GNSS サービスはナビゲーションエディションでのみ利用できます。 HERE GNSS サービスの使用を開始する前 に、当社に連絡して評価版資格情報を取得してください。

HERE アカウントの設定、アプリの登録、および認証の詳細について は、『 Identity & Access Management 開発者ガイド』を参照してください。

HERE アカウントを取得

If you are an individual developer who has signed up for one of the plans listed on our Developer plans page on here-tech.skawa.fun., you received a HERE account ID when you signed up. You can use your HERE account to log in to here-tech.skawa.fun. to create applications. Applications (uniquely identified by an app ID) enable development with HERE products and services.

アプリを登録する

アプリを登録するには、次の手順を実行します。

  1. Sign in to here-tech.skawa.fun.
  2. 名前をクリックし 、 [ プロジェクト] を選択して、一覧からプロジェクトを選択します。 プロジェクトの詳細と利用可能なアプリケーションの資格情報が表示されます。
  3. JavaScript または REST を選択し、 Generate アプリをクリックします。アプリケーションが作成されると、そのアプリ ID が表示されます。

API キー を入手

API キー を取得するには、次の手順を実行します。

  1. Sign in to here-tech.skawa.fun.
  2. 名前をクリックし 、 [ プロジェクト] を選択して、一覧からプロジェクトを選択します。 プロジェクトの詳細と利用可能なアプリケーションの資格情報が表示されます。
  3. API キー を作成をクリック して、アプリケーションに最大 2 つの API キーを生成します。 API キー が作成され、表示されます。

HERE GNSS サービスは、通常の HERE フリーミアムプランには含まれていません。

無料の試用版 / 価格で API キー をアクティブ化するには、こちらにお問い合わせください。

Contact us GNSS サービスを使用することを連絡先リクエストの記述時に選択して言及します。

リクエストを送信する

次のセクションでは、リクエスト情報の例を示します。

Protobuf リクエストを作成しています

HERE GNSS API では、すべてのリクエストで同じ URL が使用されます。

   wss://gnss.hereapi.com:443/websocket/v1?apiKey={YOUR_API_KEY}

URL に送信されるリクエストは、 Message少なくとも 1 requestssubscriptionsunsubscriptions つの、、またはのサブメッセージを含む gnss.proto で定義された Protobuf です。

応答は常に、 Messagedata 少なくとも 1 つのサブメッセージを含む Protobuf です。

Protobuf に慣れていない場合 は、 HERE を使用して役立つチュートリアルを参照できます。

例 : GNSS アシスタンスデータのシングルショットリクエスト

Protobuf メッセージの内容は JSON のような形式で表示 gnss.proto されますが、実際のメッセージを作成するには、から生成した Protobuf コードを使用する必要があります。

GPS および Galileo の星座に関する GNSS 支援データをワンショットで要求する場合、次 Message の情報が API に送信されます。

{
  "requests": [
    {
      "data_type": DATATYPE_LPP_AGNSS_GPS
    },
    {
      "data_type": DATATYPE_LPP_AGNSS_GAL
    }
  ]
}

返信の内容は次のとおりです。

{
  "data": [
    {
      "data_type": DATATYPE_LPP_AGNSS_GPS,
      "payload": UPER encoded LPP 17.4.0 element <LPP-Message>
      "metadata": {
        "creation_timestamp": 1615295745
      }
    },
    {
      "data_type": DATATYPE_LPP_AGNSS_GAL,
      "payload": UPER encoded LPP 17.4.0 element <LPP-Message>
      "metadata": {
        "creation_timestamp": 1615295745
      }
    }
  ]
}

または、 2 つの個別の Protobuf メッセージがあり Data 、それぞれに 1 つのサブメッセージが含まれている場合もあります。 いずれの場合も、各 data サブメッセージに は LPP 17.4.0 ASN.1 スキーマで説明されている形式のアシスタンスデータが含まれています。

例 : GNSS 補正データをサブスクライブします

GPS およびビドー教の星座の軌道および時計の修正をサブスクライブする場合は Message 、以下のものを API に送信する必要があります。

{
  "subscriptions": [
    {
      "data_type": DATATYPE_LPP_CLOCK_AND_ORBIT_GPS
    },
    {
      "data_type": DATATYPE_LPP_CLOCK_AND_ORBIT_BEI
    }
  ]
}

応答として、 data サブメッセージに LPP-Message's 子要素 gnss-SSR-ClockCorrections-r15 およびの修正データが含まれている Protobuf メッセージの受信を開始 gnss-SSR-OrbitCorrections-r15します。 次の例は、 1 つの Protobuf メッセージで送信された両方の星座の更新を示しています ( 他のサブスクリプションに関連する他の要素も存在する可能性があります ) 。

{
  "data": [
    {
      "data_type": DATATYPE_LPP_CLOCK_AND_ORBIT_BEI,
      "payload": UPER encoded LPP 17.4.0 element <LPP-Message>
      "metadata": {
        "creation_timestamp": 1615295835
      }
    },
    {
      "data_type": DATATYPE_LPP_CLOCK_AND_ORBIT_GPS,
      "payload": UPER encoded LPP 17.4.0 element <LPP-Message>
      "metadata": {
        "creation_timestamp": 1615295835
      }
    }
  ]
}

または、 2 つの個別の Protobuf メッセージがあり 、このサブスクリプションに関連する 1 つのDataサブメッセージがそれぞれに含まれている可能性があります(他のdataサブメッセージの場合もあります)。 データ型からサブスクライブを解除するか、または WebSocket 接続を閉じるまで、修正データが送られます。

例 : 電離層補正データにサブスクライブします

GPS などの特定の星座の電離層補正にサブスクライブする場合は、まず必要な修正のグリッド ID を決定する必要があります。 HERE では、 GPS コンステレーションを使用して電離圏のデータにサブスクライブする一般的なプロセスについて説明しています。 電離層補正の形式および必要なグリッド ID の決定方法の詳細について は、「電離圏補正の詳細」を参照してください。

まず、次 Message の情報が API に送信されます。

{
  "requests": [
    {
      "data_type": DATATYPE_LPP_IONO_GPS
    }
  ]
}

戻される応答は、 複数 のDataサブメッセージを含む Protobuf Messageで 、各サブエレメントGNSS-SSR-CorrectionPointsに 1 つのLPP-Messageグリッドが記述されています。

{
  "data": [
    {
      "data_type": DATATYPE_LPP_IONO_GPS,
      "payload": UPER encoded LPP 17.4.0 element <LPP-Message>
      "metadata": {
        "creation_timestamp": 1615295745
      }
    },
  ...
    {
      "data_type": DATATYPE_LPP_IONO_GPS,
      "payload": UPER encoded LPP 17.4.0 element <LPP-Message>
      "metadata": {
        "creation_timestamp": 1615295745
      }
    }
  ]
}

このデータから、ご利用の場所に必要なグリッド ID を判断し、電離層データのサブスクリプションを作成できます。 たとえば、グリッド ID 10 および 11 の場合 Message 、次の情報を API に送信する必要があります。

{
  "subscriptions": [
    {
      "data_type": DATATYPE_LPP_IONO_GPS,
      "params": {
        PARAMS_IONO_CORRECTIONS_GRID_IDS: "10,11"
      }
    }
}

このリクエストに対する最初の応答は、グリッドデータまたは修正データの新しい定義がある場合に発生します。 以下の例には、グリッド定義と補正データの両方が含まれています ( 他のサブスクリプションに関連する可能性のある他の要素の中にもあります ) 。 各 LPP-Message 要素には、子要素 GNSS-SSR-CorrectionPoints ( グリッド定義 ) 、子要素 GNSS-SSR-STEC-Correction 、および GNSS-SSR-GriddedCorrection ( 実際の補正 ) が含まれています。

{
  "data": [
    {
      "data_type": DATATYPE_LPP_IONO_GPS,
      "payload": UPER encoded LPP 17.4.0 element <LPP-Message>, definition for grid 10
      "metadata": {
        "creation_timestamp": 1615295835
      }
    },
    ...
    {
      "data_type": DATATYPE_LPP_IONO_GPS,
      "payload": UPER encoded LPP 17.4.0 element <LPP-Message>, corrections for grid 10
      "metadata": {
        "creation_timestamp": 1615295835
      }
    },
    {
      "data_type": DATATYPE_LPP_IONO_GPS,
      "payload": UPER encoded LPP 17.4.0 element <LPP-Message>, definition for grid 11
      "metadata": {
        "creation_timestamp": 1615295840
      }
    },
    ...
    {
      "data_type": DATATYPE_LPP_IONO_GPS,
      "payload": UPER encoded LPP 17.4.0 element <LPP-Message>, corrections for grid 11
      "metadata": {
        "creation_timestamp": 1615295840
      }
    }
  ]
}

その後、サブスクライブされているグリッド定義および修正データの更新が発生すると、クライアントに送信されます。 データ型からサブスクリプションを解除するか、または WebSocket 接続を閉じるまで、電離層補正データが送られます。

例 : 予測された GNSS 支援データを要求します

GPS コンステレーションの予測 GNSS 支援データのセットを 1 つ要求する場合は Message 、次のものを API に送信する必要があります。

{
  "requests": [
    {
      "data_type": DATATYPE_LPP_NAV_MODEL_PREDICTIONS_GPS
    }
  ]
}

応答として、 Data サブメッセージに今後 14 日間の GPS コンステレーションの予測アシスタンスデータが含まれている Protobuf Messageを受け取ります。

{
  "data": [
    {
      "data_type": DATATYPE_LPP_NAV_MODEL_PREDICTIONS_GPS,
      "payload": UPER encoded LPP 17.4.0 element <LPP-Message>.
      "metadata": {
        "creation_timestamp": 1615295835
      }
    },
    ...
    {
      "data_type": DATATYPE_LPP_NAV_MODEL_PREDICTIONS_GPS,
      "payload": UPER encoded LPP 17.4.0 element <LPP-Message>.
      "metadata": {
        "creation_timestamp": 1615295835
      }
    }
  ]
}

LPP-Message 各要素は、すべての有効な GPS 衛星について、一定の期間予測されたナビゲーションモデルを提供します。 子要素 gnss-ReferenceTime は、ナビゲーションモデルが計算された時間を示し、gnss-NavigationModel実際のナビゲーションモデルを定義します。

ナビゲーションモデル間の間隔は 2 時間で、 GPS の予測は 14 日間提供 されます。したがって、メッセージには合計で別個の14 * 12 = 168Data要素が含まれています。

予測された GNSS 支援または GNSS 支援のみにサブスクライブしている場合 Message's 、 GNSS 支援データサービスは、まれに新しい Protobuf を送信します。 アシスタンスデータの変更が遅いためです。

新しい予測が 15 分ごとに 1 回送信され、 30 ~ 60 分ごとに新しい支援が 1 回送信されます ( コンステレーションによって異なります ) 。

この場合、プロキシ、ファイアウォール、およびロードバランサの背後であっても、接続を維持するために、 WebSocket の ping メッセージが 50 秒あたり約 1 回送信されます。

クライアントは WebSocket の pong メッセージを返信する必要があります。そうしないと、接続が閉じられます。 実際には、すべての WebSocket ライブラリが、 pong メッセージのサポートが WebSocket プロトコルの必須機能であるため、 pong メッセージを自動的に送信します。

例 : GNSS 修正のサブスクリプションを解除します

前の例でサブスクライブした GNSS 修正の受信を停止するには Message 、 API に次のメッセージを送信します。

{
  "unsubscriptions": [
    {
      "data_type": 0
    }
  ]
}

を使用 data_type0 すると、この接続で行われたすべてのサブスクリプションがキャンセルされます。

警告

HERE GNSS API URL への WebSocket 接続が閉じると、すべてのサブスクリプションが自動的に閉じられます。

API への WebSocket 接続を開くたびに受信するすべてのデータにサブスクライブする必要があります。

データ接続の問題などにより、接続が切断された後で HERE GNSS API に再接続する場合は、指数バックオフを使用します。

アシスタンスデータを使用します

Message GNSS 支援データサービスから支援データまたは修正データを含む応答を受信した後 payload 、アップエンコードされた LPP 17.4.0 形式のデータをデコードする必要があります。

Message.Data.data_type 次の場合 :

  • DATATYPE_LPP_*では、アップエンコードされた LPP 17.4.0 形式のデータが使用さ れています。 LPP 17.4.0 ASN.1 スキーマを参照してください。
  • DATATYPE_IONEXでは、データはテキストベースの ionex 1.1 形式になっています。
  • DATATYPE_BSXでは、データはテキストベースの BSX 形式になっています。
  • それ以外の場合、データは BER エンコード LPP 16 形式になります。 LPP ASN.1 スキーマ を参照してください

次のステップ

  • A-GNSS データのサポートをリクエスト / サブスクライブする方法については 、「 GNSS 支援データ」を参照してください。
  • HD GNSS データの修正を要求 / サブスクライブする方法については、「 HD GNSS 補正データ」を参照してください。

」に一致する結果は 件です

    」に一致する結果はありません