A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://www.asahi-net.or.jp/~ax2s-kmtn/internet/geo/REC-geolocation-API-20161108.html below:

ジオãƒã‚±ãƒ¼ã‚·ãƒ§ãƒ³API仕様 第2版

【注意】 このドキュメントは、W3CのGeolocation API Specification 2nd Edition W3C Recommendation 8 November 2016の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。

First Update: 2016年11月14日

要約

この仕様は、ホスティング・デバイスに関連付けられた地理的な位置情報へのスクリプトによるアクセスを提供するAPIを定義しています。

このドキュメントのステータス

現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストはhttps://www.w3.org/TR/のW3C技術報告インデックスにあります。

このドキュメントは、2013年のジオロケーションAPI勧告を編集したバージョンであり、すべての誤りを修正するという2013年の勧告に対して行われた変更が含まれています。このドキュメントの前の勧告との差分を記したバージョンも比較のために利用できます。正誤表にまだ記録されていない不確かなコンテキストに関する未解決の問題があることに注意してください。

このドキュメントは、ジオロケーション・ワーキンググループによって勧告として公開されました。このドキュメントに関してコメントを行いたい場合には、public-geolocation@w3.org(購読、アーカイブ。説明も参照してください)にお送りください。どのようなコメントでも歓迎します。

このドキュメントは、W3Cメンバー、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。これは確定済みドキュメントであり、参考資料として用いたり、別のドキュメントで引用することができます。勧告の作成におけるW3C の役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。

グループは勧告候補の終了基準を満たしたことを示す実装報告書を作成しました。少なくとも5つのユーザ・エージェントの実装があり、ジオロケーションAPI仕様のすべての機能が2つ以上のユーザ・エージェントで実装されました。また、ウェブサイト・テストに適合するウェブサイトが少なくとも2つありました。

このドキュメントは、2004年2月5日のW3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。

このドキュメントは、2015年9月1日のW3Cプロセス・ドキュメントによって管理されています。

目次
  1. 1 適合要件
  2. 2 はじめに
  3. 3 対象範囲
  4. 4 セキュリティおよびプライバシーに関する留意点
  5. 5 API記述
  6. 6 ユースケースと要件
  7. 謝辞
  8. 参考文献
1 適合要件

すべての項において明示的に非規範的と記しているとおり、この仕様のすべての図、例、注は、非規範的です。その他はすべて規範的です。

このドキュメントの規範的な部分の「しなければならない(MUST)」「してはならない(MUST NOT)」「必須である／要求される(REQUIRED)」「すべきである／する必要がある(SHOULD)」「すべきでない／する必要がない(SHOULD NOT)」「推奨される(RECOMMENDED)」「することができる／してもよい(MAY)」「選択できる／任意である(OPTIONAL)」というキーワードは、RFC2119で記述されているように解釈されるべきです。読みやすさのために、これらの用語をすべて大文字で表しているとは限りません。[RFC2119]

アルゴリズムの一部として命令文で表される要件(「先頭の空白文字を削除」や「エラーを返し、これらのステップを中止」など)は、アルゴリズムの導入に用いるキーワード(「しなければならない(MUST)」、「すべきである／する必要がある(SHOULD)」、「することができる／してもよい(MAY)」など)の意味で解釈すべきです。

アルゴリズムや特定のステップとして表現している適合要件は、最終的な結果が同等である限り、どのような方法で実装してもかまいません。(特に、この仕様で定義しているアルゴリズムは、分かりやすさを目指しており、効率の良さは目指していません。)

ユーザ・エージェントは、そのままでは制約のない入力に対し、例えば、サービスへの攻撃を防いだり、メモリの不足を監視したり、プラットフォーム固有の制限に対処したりするなど、実装固有の制限を課すことができます。

この仕様はWeb IDL仕様の用語を用いているため、この仕様で定義しているAPIをECMAScriptで実装する場合には、Web IDL仕様で定義されているECMAScript Bindingsと一致する形で実装しなければなりません。[WEBIDL]

2 はじめに

この項は非規範的です。

ジオロケーションAPIは、緯度と経度のような、実装を提供しているデバイスのみに関連付けられている位置情報に対する、ハイレベルなインターフェースを定義します。API自体は、基礎となる位置情報の情報源に依存しません。一般的な位置情報の情報源には、ユーザによる入力に加え、GPS(Global Positioning System)や、IPアドレス、RFID、WiFiやBluetooth MACアドレスなどのネットワーク信号から推測される位置情報、GSM/CDMAセルIDなどがあります。APIがデバイスの実際の位置を返す保証はありません。

このAPIは、キャッシュされた位置情報のクエリを明示的に行う性能に加え、「単発」の位置情報リクエストと、位置情報の繰り返し更新の両方を可能にすることを目指しています。位置情報は、緯度と経度の座標で表されます。この仕様のジオロケーションAPIは、[AZALOC]、[GEARSLOC]、[LOCATIONAWARE]などの、業界における初期の取り組みを基礎としています。

次のコードは、基本的な位置情報の取得方法に関する説明を抜粋したものです。

「単発」の位置情報リクエストの例

    function showMap(position) {
      // (position.coords.latitude, position.coords.longitude)を中心
      // とする地図を表示する。
    }

    // 単発の位置情報をリクエストする。
    navigator.geolocation.getCurrentPosition(showMap);

位置情報の繰り返し更新のリクエストの例

    function scrollMap(position) {
      // (position.coords.latitude, position.coords.longitude)が中心
      // となるように、地図をスクロールする。
    }

    // 繰り返し更新をリクエストする。
    var watchId = navigator.geolocation.watchPosition(scrollMap);

    function buttonClickHandler() {
      // ユーザがボタンをクリックしたら、更新を中止する。
      navigator.geolocation.clearWatch(watchId);
    }

位置情報の繰り返し更新のリクエストとエラー対応の例

    function scrollMap(position) {
      // (position.coords.latitude, position.coords.longitude)が中心
      // となるように、地図をスクロールする。
    }

    function handleError(error) {
      // error.messageでdiv要素を更新する。
    }

    // 繰り返し更新をリクエストする。
    var watchId = navigator.geolocation.watchPosition(scrollMap, handleError);

    function buttonClickHandler() {
      // ユーザがボタンをクリックしたら、更新を中止する。
      navigator.geolocation.clearWatch(watchId);
    }

潜在的にキャッシュされている位置情報をリクエストする例

    // 位置情報をリクエストする。キャッシュ期間が10分以内の位置を受け
    // 入れる。ユーザ・エージェントが持っているキャッシュされた位置オ
    // ブジェクトが十分に新しくなければ、自動的に新しいオブジェクトを
    // 取得する。
    navigator.geolocation.getCurrentPosition(successCallback,
                                             errorCallback,
                                             {maximumAge:600000});

    function successCallback(position) {
      // 上記の「maximumAge」オプションの使用により、位置オブジェクト
      // は最大10分前までのものであることが保証される。
    }

    function errorCallback(error) {
      // error.messageでdiv要素を更新する。
    }

新しくキャッシュされた位置情報の返答をユーザ・エージェントに強制

    // 位置をリクエストする。キャッシュ期間が10分以内の、キャッシュされた
    // 位置のみを受け入れる。ユーザ・エージェントが持っているキャッシュさ
    // れた位置オブジェクトが十分に新しくなければ、直ちにエラー・コールバ
    // ックが呼び出されるでしょう。
    navigator.geolocation.getCurrentPosition(successCallback,
                                             errorCallback,
                                             {maximumAge:600000, timeout:0});

    function successCallback(position) {
      // 上記の「maximumAge」オプションの使用により、位置オブジェクトは最
      // 大10分前までのものであることが保証される。0ミリ秒の「タイムアウト」
      // を使用すれば、適切なキャッシュされた位置情報が利用できなければ、
      // ユーザ・エージェントは非同期にコードTIMEOUTでエラー・コールバック
      // を呼び出し、新しい位置情報の取得プロセスを開始しないでしょう。
    }

    function errorCallback(error) {
      switch(error.code) {
        case error.TIMEOUT:
          // 適切なキャッシュされた位置情報が存在しない場合の迅速なフォールバック。
          doFallback();
          // 新しい位置オブジェクトを取得する。
          navigator.geolocation.getCurrentPosition(successCallback, errorCallback);
          break;
        case ... // 他のエラーのケースを処理する。
      };
    }

    function doFallback() {
      // 十分に新しいキャッシュされた位置情報は利用できない。
      // デフォルトの位置情報に対するフォールバック。
    }

任意の利用可能なキャッシュされた位置情報の返答をユーザ・エージェントに強制

    // 位置をリクエストする。いかなるキャッシュ期間でも、キャッシュされた位置
    // のみを受け入れる。ユーザ・エージェントがキャッシュされた位置情報を全く持
    // っていなければ、直ちにエラー・コールバックが呼び出されるでしょう。
    navigator.geolocation.getCurrentPosition(successCallback,
                                             errorCallback,
                                             {maximumAge:Infinity, timeout:0});

    function successCallback(position) {
      // 「maximumAge」を無限に設定することにより、位置オブジェクトはキャッシュさ
      // れたものであることが保証される。0ミリセカンドの「タイムアウト」を使用する
      // と、キャッシュされた位置が全く利用できない場合、ユーザ・エージェントは、
      // 直ちにコードTIMEOUTでエラー・コールバックを呼び出し、新しい位置情報の取得
      // プロセスを開始しないでしょう。
      if (position.timestamp < freshness_threshold && 
          position.coords.accuracy < accuracy_threshold) {
        // 位置情報は比較的新しくて正確。
      } else {
        // 位置情報はかなり古くかつ／または不正確。
      }
    }

    function errorCallback(error) {
      switch(error.code) {
        case error.TIMEOUT:
          // キャッシュされた位置情報が全く存在しない場合の迅速なフォールバック。
          doFallback();
          // 新しい位置オブジェクトを取得する。
          navigator.geolocation.getCurrentPosition(successCallback, errorCallback);
          break;
        case ... // 他のエラーのケースを処理する。
      };
    }

    function doFallback() {
      // キャッシュされた位置情報は利用できない。
      // デフォルト位置情報に対するフォールバック。
    }
3 対象範囲

この項は非規範的です。

この仕様は、ホスティング・デバイスに関連付けられた地理的な位置情報を取得するためのスクリプトAPIの提供のみを範囲としています。地理的な位置情報は、世界測地系座標[WGS84]で提供されます。

この仕様の範囲には、いかなる種類のマークアップ言語の提供も含まれていません。

この仕様の範囲には、地理的な位置を識別するURIを構築するための新たなURIスキームの定義は含まれていません。

4 セキュリティおよびプライバシーに関する留意点

この仕様で定義しているAPIは、ホスティング・デバイスの地理的な位置を取得するために用いられます。ほとんどの場合、この情報はそのデバイスのユーザの位置も開示するため、ユーザのプライバシーが危険にさらされる可能性があります。この仕様に適合する実装は、ユーザのプライバシーを保護するメカニズムを提供しなければならず、このメカニズムは、ユーザが明確に許可しない限り、このAPIで位置情報が利用できるようにならないことを保証すべきです。

4.1 ジオロケーションAPIの実装者のためのプライバシーに関する留意点

ユーザ・エージェントは、ユーザが明確に許可していないウェブサイトに位置情報を送信してはなりません。下記で述べているように、事前にユーザとの信頼関係が構築できていない場合、ユーザ・エージェントは、ユーザ・インターフェースを通じて許可を得なければなりません。ユーザ・インターフェースには、ドキュメントのURI[URI]のホスト・コンポーネントが含まれていなければなりません。ユーザ・インターフェースで得られた許可が、現在のブラウジング・セッションの範囲を越えて(つまり、ブラウジング・コンテキスト[BROWSINGCONTEXT]が別のURLにナビゲートされる時間を超えて)保持されている場合、それを取消できなければならず、ユーザ・エージェントは許可が取消されればそれを尊重しなければなりません。

一部のユーザ・エージェントは、そのようなユーザ・インターフェースを必要としない信頼関係を事前に構築するでしょう。例えば、ウェブ・サイトが地理的な位置情報を特定するリクエストを行なう時にはウエブ・ブラウザはユーザ・インターフェースを表示するかもしれませんが、E911(訳注：米国の携帯電話における緊急通報)機能を実行するために位置情報を用いる場合は、VOIP電話はユーザ・インターフェースを表示しないかもしれません。

4.2 位置情報の受信者のためのプライバシーに関する留意点

受信者は、必要な場合にのみ位置情報をリクエストしなければなりません。受信者は、与えられたタスクのためにのみ位置情報を用いなくてはなりません。受信者は、ユーザから位置情報の保持を明確に許可されている場合を除き、そのタスクの完了時にその情報を廃棄しなければなりません。受信者は、この情報を不正なアクセスから保護するための措置を講じなければなりません。位置情報を保存する場合は、ユーザがこの情報を更新・削除できるようにすべきです。

位置情報の受信者は、ユーザが明確な許可なく位置情報を再送信してはなりません。再送信時には注意すべきであり、暗号化の利用が推奨されます。

受信者は、位置データを収集しているという事実、収集目的、データの保持期間、データの保護方法、データを共有する場合の共有方法、ユーザがデータにアクセス、更新、削除できる方法、データに関してユーザが有するその他の選択肢を明確かつ目立つように開示しなければなりません。この開示には、上記のガイドラインの例外に関する説明が含まれていなければなりません。

4.3 実装に関する補足的留意点

この項は非規範的です。

ジオロケーションAPIの実装者は、前項で挙げた要件に加え、ユーザのプライバシーに悪影響を及ぼしうる次の点についても考慮することが推奨されます。ユーザは、自分の位置をウェブサイトに開示する許可をユーザ・エージェントにうっかり与えてしまう場合があります。また、ユーザに関する限り、あるURLで提供されていたコンテンツが変更され、以前に与えられた位置に関する許可が適用されなくなる場合もあります。あるいは、単にユーザが考えを変えるかもしれません。

これらの状況を予測したり防止したりすることは本質的に困難です。緩和策や徹底的な防御策は実装の責任であり、この仕様では規定していません。しかし、実装者は、これらの手段を設計する際に、ユーザが位置情報の共有について意識できるようにし、許可の取り消しが可能なインターフェースに容易にアクセスできるようにすることをお勧めします。

5 API記述 5.1 Geolocationインターフェース

Geolocationオブジェクトは、ホスティング・デバイスに関連する位置情報をプログラムで決定するために、スクリプトで用います。位置情報は、ユーザ・エージェントの特定のアルゴリズムを適用し、Positionオブジェクトを作成し、それに基づいて、オブジェクトに適切なデータを入力することで得られます。

 partial interface Navigator {
   readonly attribute Geolocation geolocation;
 };
 [NoInterfaceObject]
 interface Geolocation { 
   void getCurrentPosition(PositionCallback successCallback,
                           optional PositionErrorCallback errorCallback,
                           optional PositionOptions options);

   long watchPosition(PositionCallback successCallback,
                      optional PositionErrorCallback errorCallback,
                      optional PositionOptions options);

   void clearWatch(long watchId);
 };

 callback PositionCallback = void (Position position);

 callback PositionErrorCallback = void (PositionError positionError);

getCurrentPosition()メソッドは、1つか、2つか、3つの引数をとります。これが呼び出されれば直ちに応答し、デバイスの現在の位置情報の取得を非同期に試みなければなりません。試みが成功すれば、successCallbackが新しいPositionオブジェクトで呼び出され(つまり、handleEventオペレーションがコールバック・オブジェクト上で呼び出され)、デバイスの現在の位置情報を反映しなければなりません。試みが失敗すれば、errorCallbackが新しいPositionErrorオブジェクトで呼び出され、失敗の理由を反映しなければなりません。

getCurrentPositionメソッドの実装は、次のステップを実行しなければなりません。

  1. キャッシュされたPositionオブジェクト(キャッシュ期間がmaximumAge変数の値より大きくない)が利用できる場合は、キャッシュされたPositionオブジェクトでsuccessCallbackをパラメータとして呼び出し、この一連のステップを終了します。
  2. timeout変数の値が0であれば、code属性がTIMEOUTに設定されている新しいPositionErrorオブジェクトでerrorCallback(存在していれば)を呼び出し、この一連のステップを終了します。
  3. 可能であれば、enableHighAccuracy変数の値を考慮に入れ、(例えば、プラットフォーム固有のAPIの呼び出しにより)位置情報取得オペレーションを開始します(詳細はenableHighAccuracyの定義を参照)。
  4. timeout変数の値で示されたミリ秒後に始動するタイマーを開始します。タイマーが始動する時に、ステップ中のこのインスタンスに関連する進行中の位置情報取得オペレーションを中止し、code属性がTIMEOUTに設定されている新しいPositionErrorオブジェクトでerrorCallback(存在していれば)を呼び出し、この一連のステップを終了します。
  5. タイムアウトになる前に、オペレーションが成功に終われば、保留中のタイマーを中止し、取得オペレーションの結果を反映した新しいPositionオブジェクトでsuccessCallbackを呼び出し、この一連のステップを終了します。
  6. タイムアウトになる前に、オペレーションが失敗すれば、保留中のタイマーを中止し、codeがPOSITION_UNAVAILABLEに設定されている新しいPositionErrorオブジェクトでerrorCallback(存在していれば)を呼び出します。

watchPosition()メソッドは、1つか、2つか、3つの引数をとります。これが呼び出されれば、監視オペレーションを一意に識別する長い値を直ちに返し、監視オペレーションを非同期に開始しなければなりません。このオペレーションは、デバイスの現在の位置情報の取得を最初に試みなければなりません。試みが成功すれば、successCallbackが新しいPositionオブジェクトで呼び出され(つまり、handleEventオペレーションがコールバック・オブジェクト上で呼び出され)、デバイスの現在の位置情報を反映しなければなりません。試みが失敗すれば、errorCallbackが新しいPositionErrorオブジェクトで呼び出され、失敗の理由を反映しなければなりません。その後、監視オペレーションは、デバイスの位置のモニタリングを継続し、この位置が変わるたびに適切なコールバックを呼び出さなければなりません。監視オペレーションは、clearWatchメソッドが対応する識別子で呼び出されるまで、継続しなければなりません。

監視プロセスの実装は、次の一連のステップを実行しなければなりません。

  1. キャッシュされたPositionオブジェクト(キャッシュ期間がmaximumAge変数の値より大きくない)が利用できる場合は、キャッシュされたPositionオブジェクトでsuccessCallbackをパラメータとして呼び出します。
  2. デバイスの位置が変わったかもしれないことを示すシステム・イベントを受信する(例えば、WiFiかセルラー信号の変更を聞いたりポーリングしたりすることにより)ために登録します。
  3. 可能であれば、enableHighAccuracy変数の値を考慮に入れ、(例えば、プラットフォーム固有のAPIの呼び出しにより)位置情報取得オペレーションを開始します(詳細はenableHighAccuracyの定義を参照)。
  4. 次の取得ステップを実行します。
    1. タイマーがまだ実行されていない場合は、timeout変数の値で示されたミリ秒後に始動するタイマーを開始します。タイマーが始動する時に、code属性がTIMEOUTに設定されている新しいPositionErrorオブジェクトでerrorCallback(存在していれば)を呼び出し、ステップ6に飛びます。
    2. タイムアウトになる前に、位置情報取得オペレーションが成功し、新しい位置情報が作成された場合は、次の2つのステップを実行します。
      1. 保留中のタイマーを中止します。このアルゴリズムが取得ステップの最初に飛んで戻れば、タイマーを再開しなければならないことに注意してください。
      2. 新しい位置情報が前の位置情報と大きく異なる場合は、取得オペレーションの結果を反映した新しいPositionオブジェクトでsuccessCallbackを呼び出します。このステップは、コールバック・レート制限の対象でありえます(下記を参照)。
    3. ほかに、タイムアウトになる前に、位置情報取得オペレーションによりエラーが報告された場合は、codeがPOSITION_UNAVAILABLEに設定されている新しいPositionErrorオブジェクトでerrorCallback(存在していれば)を呼び出します。このステップは、コールバック・レート制限の対象でありえます(下記を参照)。
  5. システム・イベントが受信されるのを待ちます。そのようなイベントが受信されれば、上の取得ステップに飛びます。

監視プロセスのステップ5.2.2で、新しい位置情報が得られ、この位置情報が以前に報告された位置情報と大きく異なる場合にのみ、successCallbackが呼び出されます。何をもって重大な違いとするのかの定義は、実装に委ねられます。さらに、5.2.2と5.2.3のステップで、実装は、過度な量の資源を不注意に消費しないようにするためにコールバックの頻度に制限を課すことができます。

getCurrentPositionとwatchPositionのどちらの場合も、実装は、最初に位置情報を共有する許可をユーザから得ない限り、決してsuccessCallbackを呼び出してはなりません。さらに、その実装は、上記のgetCurrentPositionかwatchPositionのどちらかのステップを実行する前に、位置情報を共有する許可をユーザから必ず得るべきです。ユーザが許可を与えれば、上記のような適切なコールバックが呼び出されなければなりません。ユーザが許可を否定すれば、上記のステップで遭遇した他のエラーに関係なく、errorCallback(存在していれば)がcode PERMISSION_DENIEDで呼び出されなければなりません。ユーザの許可を得るために費やされる時間を、PositionOptionsパラメータのtimeout属性でカバーされる期間に含んではなりません。timeout属性は、位置情報取得オペレーションのみに適用しなければなりません。

clearWatch()メソッドは1つの引数をとります。これが呼び出されれば、与えられたwatchId引数の値を最初にチェックしなければなりません。この値が以前に開始したどの監視プロセスにも対応していなければ、メソッドはそれ以上のアクションを行わずに、直ちに返答しなければなりません。そうでない場合は、watchId引数で識別された監視プロセスは直ちに止められなければならず、それ以上のコールバックが呼び出されてはなりません。

5.2 PositionOptionsインターフェース

getCurrentPosition()とwatchPosition()のメソッドは、PositionOptionsオブジェクトをそれらの3番目の引数として受け入れます。

ECMAScriptでは、PositionOptionsオブジェクトは、enableHighAccuracy、timeoutおよびmaximumAgeという名のオプションのプロパティーとともに、正規の本来のオブジェクトを用いて表されます。

  dictionary PositionOptions {
    boolean enableHighAccuracy = false;
    [Clamp] unsigned long timeout = 0xFFFFFFFF;
    [Clamp] unsigned long maximumAge = 0;
  };

ECMAScriptでは、enableHighAccuracy、timeoutおよびmaximumAgeというプロパティーは、すべてオプションです。PositionOptionsオブジェクトを作成する場合、開発者はこれらのプロパティーをどれでも指定できます。

enableHighAccuracy属性は、アプリケーションが最も良い結果を受け取りたいという示唆を与えます。その結果、応答時間が遅くなったり、電力消費量が増えたりする可能性があります。ユーザは、この性能を拒否することもできます。また、デバイスはフラグが指定されていなかったときよりも正確な結果を提供できない可能性もあります。この属性の本来の目的は、高精度なジオロケーションの確定を要求しないことを、実装に対してアプリケーションが通知できるようにすることです。したがって、実装では、大量の電力を消費するジオロケーション・プロバイダー(例えば、GPS)を用いないようにすることができます。これは特に、携帯電話のような電池式のデバイスで作動するアプリケーションに有用です。

timeout属性は、対応するsuccessCallbackが呼び出されるまでに、呼び出しからgetCurrentPosition()またはwatchPosition()への受け渡しに許されている最長時間(ミリ秒で)を示します。既定のタイムアウト時間が経過する前に、実装が新しいPositionをうまく取得できず、その間に他のエラーが生じていなければ、対応するerrorCallbackは、code属性がTIMEOUTに設定されているPositionErrorオブジェクトで呼び出されなければなりません。timeout属性がカバーする期間には、ユーザからの許可の取得に費やす時間が含まれないことに注意してください。timeout属性は、位置情報取得オペレーションのみに当てはまります。

getCurrentPosition()呼び出しの場合、errorCallbackは最大1回呼び出されるでしょう。watchPosition()の場合、errorCallbackは繰り返し呼び出されるかもしれません。最初のタイムアウトは、watchPosition()が呼び出された瞬間か、ユーザの許可(必要な場合に)が得られた瞬間に関係があります。次のタイムアウトは、ホスティング・デバイスの位置が変わったため、新しいPositionオブジェクトを取得しなければならないと実装が断定した瞬間に関係があります。

maximumAge属性は、アプリケーションが、ミリ秒で指定された時間よりも期間が大きくないキャッシュされた位置情報を喜んで受け入れることを示します。maximumAgeが0に設定されていれば、実装は新しい位置オブジェクトの取得を直ちに試みなければなりません。maximumAgeを無限(Infinity)に設定すると、実装はキャッシュ期間にかかわらず、キャッシュされた位置情報の返答を決定しなければなりません。指定されたmaximumAgeよりも期間が大きくない、キャッシュされた位置情報を実装が利用できない場合、新しい位置オブジェクトを取得しなければなりません。watchPosition()の場合、maximumAgeは、実装によって返された最初の位置オブジェクトを参照します。

5.3 Positionインターフェース

Positionインターフェースは、このAPIが返したジオロケーション情報のためのコンテナです。このバージョンの仕様では、型Coordinatesとtimestampの1つの属性が認められています。将来のAPIのバージョンでは、この位置(例えば、住所)に関する他の情報を提供する追加の属性が認められるかもしれません。

  [NoInterfaceObject]
  interface Position {
    readonly attribute Coordinates coords;
    readonly attribute DOMTimeStamp timestamp;
  };

coords属性には、高度と速度などの他のオプションの属性に加え、地理的な座標情報がそれらの関連する精度とともに含まれています。

timestamp属性は、Positionオブジェクトが得られた時間を表し、DOMTimeStamp[DOMTIMESTAMP]として表されます。

5.4 Coordinatesインターフェース 
  [NoInterfaceObject]
  interface Coordinates {
    readonly attribute double latitude;
    readonly attribute double longitude;
    readonly attribute double? altitude;
    readonly attribute double accuracy;
    readonly attribute double? altitudeAccuracy;
    readonly attribute double? heading;
    readonly attribute double? speed;
  };

このインターフェースで属性が用いる地理的な座標参照系は、世界測地系(2d)[WGS84]です。その他の参照系はサポートされていません。

latitudeとlongitudeの属性は、10進数の度数で指定される地理的な座標です。

altitude属性は、位置の高さを表し、[WGS84]楕円体からの高さをメートルで指定します。実装が高度の情報を提供できない場合、この属性の値はヌル(null)でなければなりません。accuracy属性は、緯度と経度の座標の精度のレベルを示します。これはメートルで指定し、すべての実装でサポートされなければなりません。accuracy属性の値は負でない実数でなければなりません。

accuracy属性はメートルで指定します。実装が高度情報を提供できない場合、この属性の値はヌルでなければなりません。そうでない場合には、altitudeAccuracy属性の値は負でない実数でなければなりません。

altitudeAccuracy属性はメートルで指定します。実装が高度情報を提供できない場合、この属性の値はヌルでなければなりません。そうでない場合には、altitudeAccuracy属性の値は負でない実数でなければなりません。

実装が返すaccuracyとaltitudeAccuracyの値は、95%の信頼レベルに相当すべきです。

heading属性は、ホスティング・デバイスの移動方向を示し、真北に対して時計回りに、0° ≤ 方向 < 360°の範囲で、度数で指定します。実装がheading情報を提供できない場合、この属性の値はヌルでなければなりません。ホスティング・デバイスが静止している場合(つまり、speed属性の値が0)、heading属性の値はNaNでなければなりません。

speed属性は、ホスティング・デバイスの現在の速度の水平成分の大きさを示し、メートル毎秒で指定します。実装が速度情報を提供できない場合、この属性の値はヌルでなければなりません。そうでない場合には、速度属性の値は負でない実数でなければなりません。

5.5 PositionErrorインターフェース 
  [NoInterfaceObject]
  interface PositionError {
    const unsigned short PERMISSION_DENIED = 1;
    const unsigned short POSITION_UNAVAILABLE = 2;
    const unsigned short TIMEOUT = 3;
    readonly attribute unsigned short code;
    readonly attribute DOMString message;
  };

code属性は、次のリストから適切なコードを返さなければなりません。

PERMISSION_DENIED (数値1)
ドキュメントにはジェオロケーションAPIの使用許可がないため、位置情報取得プロセスは失敗した。
POSITION_UNAVAILABLE (数値2)
デバイスの位置を決定できなかった。例えば、位置情報取得プロセスで用いた1つ以上の位置情報プロバイダーが、プロセスの完全な失敗を引き起こした内部エラーを報告した。
TIMEOUT (数値3)
実装が新しいPositionオブジェクトの取得に成功する前に、timeoutプロパティーで指定された時間が経過した。

message属性は、遭遇したエラーの詳細を説明したエラー・メッセージを返さなければなりません。この属性は、主としてデバッグを目的としており、開発者はアプリケーションのユーザ・インターフェースでそれを直接使用すべきではありません。

6 ユースケースと要件 6.1 ユースケース 6.1.1 ユーザの周辺にある注目すべき場所の発見

外国の都市を訪れた人は、観光名所のデータベースを検索・閲覧できるウェブ・アプリケーションにアクセスできます。ウェブ・アプリケーションは、ジェオロケーションAPIを用いてユーザのおおよその位置情報にアクセスできるため、ユーザの位置に近い順に検索結果を並べることができます。

6.1.2 位置情報を用いたコンテンツのアノテーション

友人のグループがスコットランドの高地をハイキングしています。彼らの一部は、旅行中に短いメモを書き、様々な場所で写真を撮り、彼らの携帯端末内でオフラインで動作するウェブ・アプリケーションを用いて、それらを保存します。彼らが新しいコンテンツを追加するたびに、そのアプリケーションは、ジェオロケーションAPI(今度は、内蔵のGPSデバイスを用いる)からの位置データを用いて自動的にタグ付けを行います。彼らが町や村に到着し、ネットワークの範囲内にまた入るたびに、そのアプリケーションは、人気のあるブログ・サイトに彼らのメモと写真を自動的にアップロードしますが、これは、マッピング・サービスへのリンクを構築するためにジェオロケーション・データを用います。グループの旅行をたどるユーザは、これらのリンクをクリックして、メモが書かれ、写真が撮られた地域の衛星写真を見ることができます。別の例は、あるユーザが自身の毎日の経験を記録したコンテンツ(例えば、画像、ビデオ、音声)を作成する生活ブログです。このコンテンツは、時間、地理的位置、記録時のユーザの感情までも含んだ情報で自動的にアノテーションを付与できます。

6.1.3 地図上のユーザの位置の表示

ユーザは市内の知らない地域にいます。彼女は自身の位置を確認したいと思い、ジェオロケーションAPIを用いて、市内の地図上で彼女の正確な位置を示してくれるウェブ・ベースのマッピング・アプリケーションを利用するために携帯端末を用います。その後、彼女は、現在位置から希望する目的地への運転方向を提供してくれるようにウェブ・アプリケーションに依頼します。

6.1.4 進路変更ごとのルート・ナビゲーション

マッピング・アプリケーションは、進路変更のたびに詳細な指示を行うことにより、ユーザがルートに沿って移動することを補助できます。そのアプリケーションは、登録によってこれを行い、ユーザの位置情報の更新を繰り返し受け取るためにジェオロケーションAPIを用います。これらの更新は、実装しているユーザ・エージェントが、ユーザの位置が変わったと判断するとすぐに伝えられ、それによって、アプリケーションは、ユーザが行う必要がありえる方向転換を予測できるようになります。

6.1.5 注目すべき場所がユーザの周辺にある場合の通知

観光ガイドのウェブ・アプリケーションは、ユーザの位置をモニターし、注目すべき場所が周辺にあれば、視覚または音声により通知を行うためにジェオロケーションAPIを使用できます。ユーザが、あるタスクに関連した目標物の近くにいれば、オンライン・タスク管理システムはリマインダーを発動できます。

6.1.6 最新ローカル情報

ユーザが現在いる地域の天気やニュースを表示するウィジェットなどのウェブ・アプリケーションは、位置情報更新の登録手続きを行うためにジェオロケーションAPIを使用できます。ユーザの位置が変われば、ウィジェットは、それに応じて内容を適応させることができます。

ソーシャル・ネットワーク・アプリケーションでは、ユーザが位置情報を用いてステータスの更新を自動的にタグ付けできます。これは、ジェオロケーションAPIでユーザの位置をモニターすることで行います。個々のユーザは、他のユーザと共有する位置情報の粒度(例えば、都市レベルか近隣レベルか)をコントロールできます。ユーザは、彼の友人のネットワークを追跡し、彼らの現在の位置に関するリアルタイムな更新情報を入手することもできます。

6.2 要件 6.2.1 ジェオロケーションAPIは、緯度と経度の対の座標で位置データを提供しなければなりません。 6.2.2 ジェオロケーションAPIは、取得された位置データの正確さに関する情報を提供しなければなりません。 6.2.3 ジェオロケーションAPIは、「単発」の位置更新をサポートしなければなりません。 6.2.4 ジェオロケーションAPIは、ホスティング・デバイスの位置が変わった時に、アプリケーションが更新を受信するために登録できるようにしなければなりません。 6.2.5 ジェオロケーションAPIは、アプリケーションが、指定された値よりもキャッシュ期間が大きくない、キャッシュされた位置をリクエストできるようにしなければなりません。 6.2.6 ジェオロケーションAPIは、位置決定情報を取得している間に発生した可能性があるエラーに関する更新をアプリケーションが受け取る方法を提供しなければなりません。 6.2.7 ジェオロケーションAPIは、アプリケーションが望ましい位置情報の精度レベルを指定できるようにしなければなりません。 6.2.8 ジェオロケーションAPIは、基礎となる位置情報の情報源にとらわれてはなりません。 謝辞

Alec Berntson、Alissa Cooper、Steve Block、Greg Bolsinga、Lars Erik Bolstad、Aaron Boodman、Dave Burke、Chris Butler、Max Froumentin、Shyam Habarakada、Marcin Hanclik、Ian Hickson、Brad Lassey、Angel Machin、Cameron McCormack、Daniel Park、Stuart Parmenter、Olli Pettay、Chris Prince、Arun Ranganathan、Aza Raskin、Carl Reed、Thomas Roessler、Dirk Segers、Allan Thomson、Martin Thomson、Doug Turner、Erik Wilde、Matt Womer、Mohamed Zergaoui

参考文献
[AZALOC]
(Non-normative) Geolocation in Firefox and Beyond, Aza Raskin. See http://azarask.in/blog/post/geolocation-in-firefox-and-beyond
[BROWSINGCONTEXT]
The browsing context in HTML5, Ian Hickson, Robin Berjon, Steve Faulkner, Travis Leithead, Erika Doyle Navara, Edward O'Connor, Silvia Pfeiffer, Editors. World Wide Web Consortium. See http://www.w3.org/TR/2014/REC-html5-20141028/browsers.html#windows
[URI]
Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter, Editors. Internet Engineering Task Force. See http://www.ietf.org/rfc/rfc2396.txt
[NAVIGATOR]
Navigator interface in HTML5, Ian Hickson, Robin Berjon, Steve Faulkner, Travis Leithead, Erika Doyle Navara, Edward O'Connor, Silvia Pfeiffer, Editors. World Wide Web Consortium. See http://www.w3.org/TR/2014/REC-html5-20141028/webappapis.html#navigator
[DOMTIMESTAMP]
The DOMTimeStamp Type, Cameron McCormack, Editor. World Wide Web Consortium, 19 April 2012. See http://www.w3.org/TR/2012/CR-WebIDL-20120419/#common-DOMTimeStamp
[GEARSLOC]
(Non-normative) Gears Geolocation API. See http://code.google.com/apis/gears/api_geolocation.html [historical]
[LOCATIONAWARE]
(Non-normative) LocationAware.org. See http://cdn.oreillystatic.com/en/assets/1/event/4/LocationAware_%20Standardizing%20a%20Geolocation%20API%20in%20the%20Browser%20Presentation.pdf [historical]
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels, Scott Bradner. Internet Engineering Task Force, March 1997. See http://www.ietf.org/rfc/rfc2119.txt
[WEBIDL]
web IDL, Cameron McCormack, Editor. World Wide Web Consortium, 19 April 2012. See http://www.w3.org/TR/2012/CR-WebIDL-20120419/
[WGS84]
National Imagery and Mapping Agency Technical Report 8350.2, Third Edition. National Imagery and Mapping Agency, 3 January 2000. See http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf

↑

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3