CyberLibrarian

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

First Update: 2013年10月28日


W3C

ジオロケーションAPI仕様

W3C勧告 2013年10月24日

本バージョン:
http://www.w3.org/TR/2013/REC-geolocation-API-20131024/
最新公開バージョン:
http://www.w3.org/TR/geolocation-API/
最新編集者草案:
http://dev.w3.org/geo/api/spec-source.html
旧バージョン:
http://www.w3.org/TR/2012/PR-geolocation-API-20120510/
編集者:
Andrei Popescu, Google, Inc

このドキュメントに対する正誤表を参照してください。いくつかの規範的な修正が含まれているかもしれません。

翻訳版も参照してください。


要約

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

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

この項は、このドキュメントの公開時のステイタスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、http://www.w3.org/TR/のW3C技術報告インデックスにあります。

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

この勧告の公表に際し、W3Cは、このジオロケーションAPIの勧告で規定している機能は、HTML5やWeb IDLの仕様が勧告へと移行しても、その変更による影響を受けないだろうと考えています。

このドキュメントは、2012年5月10日の勧告案に対して行われたマイナーな変更を組込んでいます。

ドキュメントに関するコメントは、ワーキンググループの公開メーリング・リストpublic-geolocation@w3.org購読アーカイブ)にお送りください。W3Cメーリング・リストおよびアーカイブ利用ガイドラインを参照してください。

勧告案段階に入るための基準は、(1)ジオロケーションAPIの各機能を実装し、ユーザ・エージェント・テストに合格した最低限2つの独立した相互運用可能なユーザ・エージェント、および(2)ウェブサイト・テストに合格した最低限2つのウェブサイトを持つことでした。ワーキンググループは、勧告候補の期間に、既知の実装に関する情報を含んでいる実装報告書を作成しました。ワーキンググループは、少なくとも5つのユーザ・エージェントの実装があり、ジオロケーションAPI仕様のすべての機能が、2つ以上のユーザ・エージェントで実装されていることを確認しました。また、ウェブサイト・テストに適合するウェブサイトが少なくとも2つありました。結果の詳細については、実装報告書を参照してください。

このドキュメントは、W3C勧告手順に沿って進めるために、W3Cプロセスのために用意された手順に従い、W3C Geolocation Working Groupによって作成されました。

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

目次

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 ... // treat the other error cases.
      };
    }

    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 ... // treat the other error cases.
      };
    }

    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オブジェクトを作成し、それに基づいて、オブジェクトに適切なデータを入力することで得られます。

Navigatorインターフェースを実装しているオブジェクト(例えば、window.navigatorオブジェクト)は、NavigatorGeolocationインターフェース[NAVIGATOR]も実装しなければなりません。そうすれば、NavigatorGeolocationのインスタンスは、Navigatorのインスタンスでバインディング固有のキャスト・メソッドを用いて取得できるでしょう。

 [NoInterfaceObject]
 interface NavigatorGeolocation {
   readonly attribute Geolocation geolocation;
 };

 Navigator implements NavigatorGeolocation;
  


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

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

監視プロセスの実装は、次の一連のステップを実行すべきです。

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

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

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

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

5.2 PositionOptionsインターフェース

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

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

  [NoInterfaceObject]
  interface PositionOptions {
    attribute boolean enableHighAccuracy;
    attribute long timeout;
    attribute long maximumAge;
  };

  

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

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

getCurrentPositionまたはwatchPositionに対し、PositionOptionsパラメーターが省略された場合、enableHighAccuracy属性に用いられるデフォルト値は偽(false)です。enableHighAccuracyプロパティーが省略された場合、ECMAScriptでは同じデフォルト値が用いられます。

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

getCurrentPositionまたはwatchPositionに対し、PositionOptionsパラメーターが省略された場合、timeout属性に用いられるデフォルト値は無限(Infinity)です。負の値が提供された場合、timeoutの値は0であると考えられます。timeoutプロパティーが省略された場合、ECMAScriptでは同じデフォルト値が用いられます。

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

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

getCurrentPositionまたはwatchPositionに対し、PositionOptionsパラメーターが省略された場合、maximumAge属性に用いられたデフォルト値は0です。負の値が提供された場合、maximumAge値は0であると考えられます。maximumAgeプロパティーが省略された場合、ECMAScriptでは同じデフォルト値が用いられます。

5.3 Positionインターフェース

Positionインターフェースは、このAPIが返したジオロケーション情報のためのコンテナです。このバージョンの仕様では、型Coordinatestimestampの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]です。その他の基準系はサポートされていません。

latitudelongitudeの属性は、10進の緯経度で指定する地理座標です。

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

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

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

heading属性は、ホスティング・デバイスの移動方向を示し、真北に対して右回りに0° ≤ heading < 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を使用できます。ユーザの位置が変われば、ウィジェットは、それに応じて内容を適応させることができます。

6.1.7 ソーシャル・ネットワーキング・アプリケーションにおける位置をタグ付けしたステータスの更新

ソーシャル・ネットワーク・アプリケーションでは、ユーザが位置情報を用いてステータスの更新を自動的にタグ付けできます。これは、ジェオロケーション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]
(非規範的) 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, David Hyatt, Editors. World Wide Web Consortium. See http://www.w3.org/TR/2013/CR-html5-20130806/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, David Hyatt, Editors. World Wide Web Consortium. See http://www.w3.org/TR/2013/CR-html5-20130806/webappapis.html#navigator
[DOMTIMESTAMP]
The DOMTimeStamp Type, Arnaud Le Hors, Philippe Le Hegaret, Gavin Nicol, Lauren Wood, Mike Champion, Steve Byrne, Editors. World Wide Web Consortium, 7 April 2004. See http://www.w3.org/TR/DOM-Level-3-Core/core.html#Core-DOMTimeStamp
[GEARSLOC]
(非規範的) Gears Geolocation API. See http://code.google.com/apis/gears/api_geolocation.html [historical]
[LOCATIONAWARE]
(非規範的) LocationAware.org. See http://locationaware.org/ [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
[RFC3066]
Tags for the Identification of Languages, Harald Tveit Alvestrand. Internet Engineering Task Force, January 2001. See http://www.ietf.org/rfc/rfc3066.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