(57)【特許請求の範囲】
【請求項１】
列車、電車又はバスを乗降する駅のつながりを表すとともに別路線の近傍駅へ徒歩移動できる駅については徒歩による駅間所要時間が関連付けられている運行ネットワークデータを保持する運行ネットワークデータ保持手段、及び、地図情報を駅周辺毎に取得可能な地図情報保持手段にアクセスするアクセス手段と、
出発駅と目的駅との間に存在する途中駅から前記近傍駅までの徒歩区間を総運行コストの大小に関わらずに含めた経路候補を探索するためにユーザにより指定され、前記出発駅、前記目的駅、及び、当該ユーザが歩きたい時間を表す徒歩許容時間を含む探索条件を受け付ける受付手段と、
前記アクセス手段を通じて前記運行ネットワークデータ保持手段にアクセスし、前記受付手段で受け付けた探索条件に基づいて、前記運行ネットワークデータにおける前記出発駅から前記目的駅へ向かう経路候補を動的に探索し、その際、前記途中駅が存在し、かつ、当該途中駅に関連付けられている前記駅間所要時間が前記徒歩許容時間以下の場合は、当該途中駅と当該近傍駅とを結ぶ徒歩区間を含めた経路候補の探索を可能にする経路探索手段と、
経路探索手段により前記経路候補が特定され、かつ、特定された経路候補に前記徒歩区間が含まれる場合は、前記アクセス手段を通じて前記地図情報保持手段にアクセスして当該途中駅周辺の地図情報を取得し、取得した地図情報に前記徒歩区間を明示して出力する地図情報編集手段と、
を備えて成る、経路探索システム。
【請求項２】
前記近傍駅へ徒歩移動できる駅と当該駅を起点とした前記駅間所要時間とを含む徒歩区間を登録する徒歩区間登録手段をさらに備えており、
前記経路探索手段は、この徒歩区間登録手段で登録された徒歩区間を前記運行ネットワークデータ保持手段で保持されている運行ネットワークデータに含めて経路探索を行う、
請求項１記載の経路探索システム。
【請求項３】
前記徒歩区間登録手段は、前記登録された徒歩区間の信頼性を定量的に表す信頼性フラグを当該徒歩区間と関連付けて更新自在に記録するとともに、最新の信頼性フラグが所定の定量値を示すかどうかを判定し、所定の定量値を示すときに当該徒歩区間を前記運行ネットワークデータの一部として前記運行ネットワークデータ保持手段に保持させる、
請求項２記載の経路探索システム。
【請求項４】
列車、電車又はバスを乗降する駅のつながりを表すとともに別路線の近傍駅へ徒歩移動できる駅については徒歩による駅間所要時間が関連付けられている運行ネットワークデータ、及び、駅周辺毎に取得可能な地図情報にアクセスするアクセス手段を備えた装置が実行する経路探索方法であって、
前記アクセス手段が、
出発駅と目的駅との間に存在する途中駅から前記近傍駅までの徒歩区間を総運行コストの大小に関わらずに含めた経路候補を探索するためにユーザにより指定され、前記出発駅、前記目的駅、及び、当該ユーザが歩きたい時間を表す徒歩許容時間を含む探索条件を受け付け、
受け付けた前記探索条件に基づいて、前記運行ネットワークデータにおける出発駅から目的駅へ向かう経路候補を動的に探索し、その際、前記途中駅が存在し、かつ、当該途中駅に関連付けられている前記駅間所要時間が前記徒歩許容時間以下の場合は、当該途中駅と当該近傍駅とを結ぶ徒歩区間を含めた経路候補の探索を可能とし、
前記徒歩区間を含む経路候補が特定された場合は、前記地図情報にアクセスして当該途中駅周辺の地図情報を取得し、取得した地図情報に前記徒歩区間を明示して出力する処理を実行することを特徴とする、
経路探索方法。
【請求項５】
ユーザ端末と公衆回線網を介して接続されたサーバを、前記ユーザ端末からの経路探索の依頼に応じて経路探索を行う経路探索システムとして動作させるためのコンピュータプログラムであって、
前記サーバを、
列車、電車又はバスを乗降する駅のつながりを表すとともに別路線の近傍駅へ徒歩移動できる駅については徒歩による駅間所要時間が関連付けられている運行ネットワークデータを保持する運行ネットワークデータ保持手段、及び、地図情報を駅周辺毎に取得可能な地図情報保持手段にアクセスするアクセス手段；
出発駅と目的駅との間に存在する途中駅から前記近傍駅までの徒歩区間を総運行コストの大小に関わらずに含めた経路候補を探索するためにユーザにより指定され、前記出発駅、前記目的駅、及び、当該ユーザが歩きたい時間を表す徒歩許容時間を含む探索条件を受け付ける受付手段；
前記アクセス手段を通じて前記運行ネットワークデータ保持手段にアクセスし、前記受付手段で受け付けた探索条件に基づいて、前記運行ネットワークデータにおける前記出発駅から前記目的駅へ向かう経路候補を動的に探索し、その際、前記途中駅が存在し、かつ、当該途中駅に関連付けられている前記駅間所要時間が前記徒歩許容時間以下の場合は、当該途中駅と当該近傍駅とを結ぶ徒歩区間を含めた経路候補の探索を可能とする経路探索手段；
経路探索手段により前記経路候補が特定され、かつ、特定された経路候補に前記徒歩区間が含まれる場合は、前記アクセス手段を通じて前記地図情報保持手段にアクセスして当該途中駅周辺の地図情報を取得し、取得した地図情報に前記徒歩区間を明示して出力する地図情報編集手段；
として機能させるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、駅間を歩いて移動したいユーザのニーズに応えつつ、出発駅から目的駅（到着予定駅）に至る経路を効率的に探索する経路探索の技術に関する。
【背景技術】
【０００２】
電車等の公共交通網における最適な運行経路をユーザに提供する経路探索システムとして、本出願人によって開発された運行経路探索ソフトウェア「駅すぱあと」（登録商標、非特許文献１参照）を搭載したパーソナルコンピュータ（PC）はじめ、多くの同種製品（ソフトウェア／システム）が存在する。これらの経路探索システムについては、探索精度や公共交通網を利用する者の利便性等を向上するため、幾多の改良・改善が試みられてきた。改良・改善された経路探索技術の一つとして、駅間徒歩移動を考慮して出発駅から目的駅を結ぶ候補経路を探索する手法がある。
例えば、JR・日比谷線「秋葉原」駅−都営線「岩本町駅」、JR「御茶ノ水」駅−千代田線「新御茶ノ水」駅、JR線「板橋」駅−都営三田線新「新板橋」駅のように、違う路線の近傍駅まで徒歩で移動することで、出発駅から目的駅へ、より短い時間で移動できる場合がある。逆に、駅間徒歩移動を考慮しないと、大幅な迂回経路が探索結果として回答されてしまう場合がある。
【０００３】
そのため、従来の経路探索システムのうちのいくつかは、徒歩区間の情報、例えば別路線であるが徒歩で移動できる時間、すなわち駅間所要時間で移動できる近傍駅が存在する駅について、駅間所要時間を関連付けておき、経路探索時に、当該駅、近傍駅並びに駅間所要時間の組み合わせで表現される徒歩区間を経路探索の回答に反映させるようにしているものがある。
【０００４】
例えば特許文献１には、駅間を徒歩で移動することができる経路（徒歩経路の一例）が存在する場合に、必要に応じて当該経路を含めて探索を行う経路情報提示装置が示されている（特許文献１段落0046等）。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】「駅すぱあと」風雲録  柏崎ほか  日経ＢＰ社  ２００６年３月２０日発行
【特許文献】
【０００６】
【特許文献１】特開２０１０−１２６０２８号
【発明の概要】
【発明が解決しようとする課題】
【０００７】
特許文献１に記載された経路情報提示装置に代表される従来の経路探索システムは、徒歩区間をなるべく短くなるように探索を行うものである。
しかし、最近は、健康志向の観点から徒歩を優先する傾向がみられ、乗り換えるために長い時間を要する（とされている）駅間でも、敢えて徒歩で駅間移動するユーザが増えている。また、公共交通網上では乗換駅として案内されていない駅であっても、多くのユーザで混雑する乗換駅での乗り換えを回避したり、あるいは、時間帯によっては他の駅へ徒歩で移動して別路線の駅へ乗り換えた方が結果的に早く目的駅に到着できる場合がある。
また、不測の事故等により不通区間が発生した場合も、駅間徒歩による乗り換えが可能な近傍駅への案内情報があれば、ユーザに大きな混乱を生じさせることがなくなることが期待される。
他方、初めて歩く場合や駅間距離が長い場合には、近傍駅への道順に困ることが想定されるが、駅間地図とその地図上に徒歩経路を表示することによって、徒歩移動が容易となり、歩くことのモチベーションが高まることが期待される。
【０００８】
本発明は、このような背景から、徒歩による乗り換え情報を充実させることより、より実用的な経路探索を実現できる経路探索の技術を提供することを課題とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するため、本発明は、経路探索システム、経路探索方法及びコンピュータプログラムを提供する。
本発明が提供する経路探索システムは、列車、電車又はバスを乗降する駅のつながりを表すとともに別路線の近傍駅へ徒歩移動できる駅については徒歩による駅間所要時間が関連付けられている運行ネットワークデータを保持する運行ネットワークデータ保持手段、及び、地図情報を駅周辺毎に取得可能な地図情報保持手段にアクセスするアクセス手段と、
出発駅と目的駅との間に存在する途中駅から前記近傍駅までの徒歩区間を総運行コストの大小に関わらずに含めた経路候補を探索するためにユーザにより指定され、前記出発駅、前記目的駅、及び、当該ユーザが歩きたい時間を表す徒歩許容時間を含む探索条件を受け付ける受付手段と、前記アクセス手段を通じて前記運行ネットワークデータ保持手段にアクセスし、前記受付手段で受け付けた探索条件に基づいて、前記運行ネットワークデータにおける前記出発駅から前記目的駅へ向かう経路候補を動的に探索し、その際、前記途中駅が存在し、かつ、当該途中駅に関連付けられている前記駅間所要時間が前記徒歩許容時間以下の場合は、当該途中駅と当該近傍駅とを結ぶ徒歩区間を含めた経路候補の探索を可能にする経路探索手段と、経路探索手段により前記経路候補が特定され、かつ、特定された経路候補に前記徒歩区間が含まれる場合は、前記アクセス手段を通じて前記地図情報保持手段にアクセスして当該途中駅周辺の地図情報を取得し、取得した地図情報に前記徒歩区間を明示して出力する地図情報編集手段と、を備えて成る。
【００１０】
ある実施の態様では、経路探索システムは、前記近傍駅へ徒歩移動できる駅と当該駅を起点とした前記駅間所要時間とを含む徒歩区間を登録する徒歩区間登録手段をさらに備えており、前記経路探索手段は、この徒歩区間登録手段で登録された徒歩区間を前記運行ネットワークデータ保持手段で保持されている運行ネットワークデータに含めて経路探索を行う。この徒歩区間登録手段は、また、前記登録された徒歩区間の信頼性を定量的に表す信頼性フラグを当該徒歩区間と関連付けて更新自在に記録するとともに、最新の信頼性フラグが所定の定量値を示すかどうかを判定し、所定の定量値を示すときに当該徒歩区間を前記運行ネットワークデータの一部として前記運行ネットワークデータ保持手段に保持させることも行う。信頼性フラグを記録するのは、徒歩区間の登録だけでは全体の経路探索精度に影響を与えることが考えられるため、その信頼性を客観的に確認、検証できるようにするためである。
【００１１】
本発明が提供する経路探索方法は、列車、電車又はバスを乗降する駅のつながりを表すとともに別路線の近傍駅へ徒歩移動できる駅については徒歩による駅間所要時間が関連付けられている運行ネットワークデータ、及び、駅周辺毎に取得可能な地図情報にアクセスするアクセス手段を備えた装置が実行する経路探索方法であって、前記アクセス手段が、出発駅と目的駅との間に存在する途中駅から前記近傍駅までの徒歩区間を総運行コストの大小に関わらずに含めた経路候補を探索するためにユーザにより指定され、前記出発駅、前記目的駅、及び、当該ユーザが歩きたい時間を表す徒歩許容時間を含む探索条件を受け付け、受け付けた前記探索条件に基づいて、前記運行ネットワークデータにおける出発駅から目的駅へ向かう経路候補を動的に探索し、その際、前記途中駅が存在し、かつ、当該途中駅に関連付けられている前記駅間所要時間が前記徒歩許容時間以下の場合は、当該途中駅と当該近傍駅とを結ぶ徒歩区間を含めた経路候補の探索を可能とし、前記徒歩区間を含む経路候補が特定された場合は、前記地図情報にアクセスして当該途中駅周辺の地図情報を取得し、取得した地図情報に前記徒歩区間を明示して出力する処理を実行することを特徴とする。
【００１２】
本発明が提供するコンピュータプログラムは、ユーザ端末と公衆回線網を介して接続されたサーバを、前記ユーザ端末からの経路探索の依頼に応じて経路探索を行う経路探索システムとして動作させるためのコンピュータプログラムであって、前記サーバを、列車、電車又はバスを乗降する駅のつながりを表すとともに別路線の近傍駅へ徒歩移動できる駅については徒歩による駅間所要時間が関連付けられている運行ネットワークデータを保持する運行ネットワークデータ保持手段、及び、地図情報を駅周辺毎に取得可能な地図情報保持手段にアクセスするアクセス手段；出発駅と目的駅との間に存在する途中駅から前記近傍駅までの徒歩区間を総運行コストの大小に関わらずに含めた経路候補を探索するためにユーザにより指定され、前記出発駅、前記目的駅、及び、当該ユーザが歩きたい時間を表す徒歩許容時間を含む探索条件を受け付ける受付手段；前記アクセス手段を通じて前記運行ネットワークデータ保持手段にアクセスし、前記受付手段で受け付けた探索条件に基づいて、前記運行ネットワークデータにおける前記出発駅から前記目的駅へ向かう経路候補を動的に探索し、その際、前記途中駅が存在し、かつ、当該途中駅に関連付けられている前記駅間所要時間が前記徒歩許容時間以下の場合は、当該途中駅と当該近傍駅とを結ぶ徒歩区間を含めた経路候補の探索を可能とする経路探索手段；経路探索手段により前記経路候補が特定され、かつ、特定された経路候補に前記徒歩区間が含まれる場合は、前記アクセス手段を通じて前記地図情報保持手段にアクセスして当該途中駅周辺の地図情報を取得し、取得した地図情報に前記徒歩区間を明示して出力する地図情報編集手段；として機能させるコンピュータプログラムである。
【発明の効果】
【００１３】
本発明によれば、ある駅から路線の異なる近傍駅までの徒歩区間を、出発駅と目的駅との間に存在する区間の一つとして、運行データネットワークデータに含めて経路候補の探索ができるので、徒歩区間を併用することで利用の多様性を増す路線網の実情と、たとえ駅間距離が長くても歩きたい（歩いてもよい）ユーザの意図に即した経路探索を行うことができる。
また、適宜、徒歩区間を運行ネットワークデータの一部として組み込むことができるので、経路探索の結果をユーザの意図を反映したものにチューニングすることができる。
【図面の簡単な説明】
【００１４】
【図１】本実施形態の経路探索システムの全体構成図である。
【図２】従来の経路探索処理の概要を示す図である。
【図３】本実施形態の経路探索ツールによる経路探索処理の概要を示す図である。
【図４】運行情報ＤＢの内容例を示す図である。
【図５】徒歩区間ＤＢの内容例を示す図である。
【図６】地図情報ＤＢの内容例を示す図である。
【図７】本実施形態の経路探索結果の表示例を示す図である。
【図８】地図情報に歩行区間を明示した例図である。
【図９】地図情報に歩行区間を明示した他の例図である。
【図１０】経路探索ツールの処理手順例を示す図である。
【図１１】地図情報編集部の処理手順例を示す図である。
【発明を実施するための形態】
【００１５】
以下、本発明を、携帯端末向けの経路探索サービスを可能にするネットワーク型の経路探索システムに適用した場合の実施の形態例を説明する。
図１は、この実施形態の経路探索システムの全体構成図であり、特徴的な部分のみを掲示してある。
【００１６】
この経路探索システム１は、インターネット等の公衆通信網Ｎに接続される経路探索サーバ１０と、ユーザ端末５０との間で双方向の通信を行う１又は複数の情報端末サービスサーバ２０（図示の例では１つ）とを含んで構成される。
【００１７】
ユーザ端末５０は、データ通信及びデータ処理機能を有する携帯端末、及び、パーソナルコンピュータ（ＰＣ）などである。この携帯情報端末は、メールサーバ６０を介して公衆通信網Ｎに接続されるものも含む。
【００１８】
［経路探索サーバ］
経路探索サーバ１０は、サーバ本体と本発明のコンピュータプログラムとの協働により実現される。すなわち、サーバ本体が、本発明のコンピュータプログラムを読み込んで実行することにより、そのサーバ本体を、データ通信用インターフェース１００、経路探索ツール１１０、地図情報登録ツール１２０として機能させ、経路探索のための情報処理を実行可能にする。
【００１９】
データ通信用インターフェース１００は、データ通信及びデータ処理機能を有するユーザ端末５０との双方向通信を可能にするとともに、これらの情報端末が閲覧可能な階層ページ画面を提供する。この階層ページ画面では、経路探索のＷｅｂサービスを行なうためのもので、経路探索条件の精緻な指定をシステム側とユーザとの間でインタラクティブに行なうことにより、ユーザが満足する経路探索を行なう環境を提供する。
経路探索の結果情報の表示も、このページ画面で行なうことができる。
【００２０】
経路探索ツール１１０は、経路探索エンジン１１１のほか、外部記憶装置（図示せず）に構築された運行情報ＤＢ（ＤＢはデータベースの略、以下同じ）１１２および徒歩区間ＤＢ１１３を有し、さらに、徒歩区間を事後的に徒歩区間ＤＢ１１３に登録するための徒歩区間登録部１１４の機能を有している。
【００２１】
運行情報ＤＢ１１２には、駅、列車、電車、バスの路線網及び駅の繋がり、各駅の緯度・経度、時刻表等の運行情報が格納されている。なお、別路線の近傍駅まで徒歩で移動可能な駅については、徒歩区間の情報（２つの駅名、駅間所要時間等）が関連付けられて格納されている。また、徒歩区間ＤＢ１１３には、ユーザが事後的に登録した上記徒歩区間の情報が格納される。運行情報ＤＢ１１２および徒歩区間ＤＢ１１３に保持されたこれらの情報が、経路探索において経路候補を特定する際に参照される運行ネットワークデータとなる。
なお、運行情報ＤＢ１１２および徒歩区間ＤＢ１１３の情報は、データテーブル形式で格納される。これについては、後述する。
【００２２】
経路探索エンジン１１１は、出発駅と目的駅とを含む探索条件を受け付けたときに、上記運行ネットワークデータをもとに、出発駅から目的駅に向かう経路候補を動的に探索する。その際、徒歩区間の情報も考慮する。「動的に探索」とは、出発駅を起点として経路の運行コストが最も小さくなる次の区間、すなわち次の駅や停留所（以下の説明では、停留所も駅に含まれるものとする）の探索を、例えば水面に石を投げたときの波紋のように連鎖的に繰り返すことにより探索することをいい、探索途中で現実的でない経路となることが判明した場合は、その経路についての次の駅以降の探索を止める。このような手法は、出発駅から目的駅までの経路を特定した後に当該経路上の最適な運行コストの経路を探索する手法とは異なるものである。
経路探索エンジン１１１は、探索条件の中に、徒歩で別路線の近傍駅まで移動しても良いとする時間、すなわち徒歩許容時間が指定されているときは、出発駅と目的駅との間の駅、すなわち途中駅に関連付けられている駅間所要時間と徒歩許容時間とを比較する。そして、駅間所要時間が徒歩許容時間より短い場合は、当該途中駅を起点とし、近傍駅を終点とする徒歩区間を含めた経路候補の探索を行う。
【００２３】
経路候補の探索時に考慮する運行コストは、通常は時間を対象とする。すなわち、次の区間（駅間、徒歩区間）が最短時間となる経路候補を探索していく。但し、時間以外にも、距離、運賃、あるいは、これらの組み合わせを運行コストとしても良い。
【００２４】
経路探索エンジン１１１は、また、運行コストをもとに探索した複数の経路の各々について、当該経路の総運行コスト、例えば総所要時間を算出し、算出された総所要時間の小さい順に、複数の経路をソートすることもできる。さらに、経路探索結果の中に徒歩区間が含まれる場合には、当該徒歩区間の起点となる駅および終点となる駅の情報を情報端末サービスサーバ２０（後述する地図情報編集部２１１）に送る。
【００２５】
徒歩区間登録部１１４は、ユーザ又は経路探索サーバ１０の管理者などにより入力された、徒歩区間の情報を徒歩区間ＤＢ１１３に登録する。但し、登録される徒歩区間のうち駅間所要時間はあくまでもユーザ等の主観に基づいた情報であることから、駅間所要時間の信頼性を定量値で表す更新自在の信頼性フラグを当該徒歩区間と関連付けて記録する。
信頼性フラグは、例えば未検証情報を表す「０」とし、登録を行ったユーザのみが利用可能な情報とする。管理者等による所定の検証が済んだ後であれば、信頼性が高まったとみなされ、信頼性フラグは「１」つまり検証済みを表す情報に更新される。
【００２６】
徒歩区間登録部１１４は、信頼性フラグを適宜更新するとともに最新の信頼性フラグを監視し、「１」のときは当該徒歩区間を運行ネットワークデータの一部として運行情報ＤＢ１１２に、適宜保持させる。あるいは、運行情報ＤＢ１１２に運行ネットワークデータの一部として組み込まずに徒歩区間ＤＢ１１３にそのまま記録しておき、複数のユーザが経路探索時に利用可能な情報として、記録情報を開放させることもできる。
【００２７】
なお、出発駅と目的駅との間に存在する途中駅に、徒歩区間の情報が関連付けられていない場合に、ユーザから受け付けた徒歩許容時間内にある徒歩移動による乗換駅の情報を新たに作成する徒歩区間情報作成機能を付加し、これにより作成された徒歩区間の情報を徒歩区間ＤＢ１１４に登録するようにしても良い。つまり、利用者による登録によらず、運行情報ＤＢ１１２に記録されている途中駅及びその近傍駅の緯度・経度情報をもとに、経路探索サーバ１０が独自に徒歩区間を作成しても良い。
【００２８】
地図情報登録ツール１２０は、地図情報ＤＢ１２１と地図情報登録部１２２とを含んで構成される。地図情報登録部１２２は、駅毎に、当該駅周辺の道路名、建物名、交差点名等の地理情報を図化した地図情報や歩行ルートを形成するための情報を地図情報ＤＢ１２１に登録するとともに、既に格納されている地図情報の修正、削除などを行う。地図情報については、自らそれを作成して保持するほか、公衆通信網（インターネット）Ｎ上で提供されている地図情報サービスのリンク先情報を保持することもできる。
【００２９】
このように構成される経路探索サーバ１０の経路探索ツール１１０による一般的な経路探索処理、すなわち出発駅と目的駅との間の経路探索の概要を説明する。比較のため、徒歩区間を考慮する従来の経路探索の概要を図２、本実施形態の経路探索ツール１１０による経路探索の概要を図３に示す。
【００３０】
従来の経路探索では、図２に示すように、出発駅から目的駅に至る途中の途中駅から別路線の近傍駅（他の途中駅）への徒歩による移動所要時間が５分の第１徒歩区間は存在するが、９分の第２徒歩区間は存在しない場合、第２徒歩区間は次の区間の探索候補の対象にならない。つまり、実際には第２徒歩区間を含む経路の総運行コストが最小となる場合であっても、最適な経路としては、太実線で結ばれている第１徒歩区間を含む経路が特定される。
【００３１】
これに対して、本実施形態の経路探索では、従来は存在しなかった上記第２徒歩区間を徒歩区間ＤＢ１１３に登録可能とするとともに、徒歩許容時間を含む探索条件で動的に経路候補を探索するので、例えば徒歩許容時間を例えば１０分と指定することで、図３に示すように、上記第２徒歩区間（登録済の場合）を含む経路が特定され得る。その結果、実情に即した最適な経路探索が可能となる。
なお、総運行コストの大小に関わらず、例えば１０分は歩いても良い、あるいは積極的に歩きたいユーザが徒歩許容時間を１０分と指定することで、上記第２徒歩区間を含む経路を意図的に特定することもできる。
このような特徴的な経路探索を実現し、且つ、従来の経路探索をも可能にするために、運行情報ＤＢ１１２および徒歩区間ＤＢ１１３に格納されるデータテーブルについて、以下説明する。
【００３２】
図４は、運行情報ＤＢ１１２に格納される、近傍駅まで徒歩可能な乗換駅に関するデータテーブルの一例を示した図である。このテーブルを「運行情報テーブル」と称する。運行情報テーブル２００には、例えば路線毎の駅の情報（緯度・経度情報を含む）のほか、既に運行ネットワークデータの一部として組み込まれている徒歩区間の情報、すなわち２つの駅、駅間所要時間、登録日が記録される。
【００３３】
上記徒歩区間の情報は、具体的には、２つの駅の一方の駅の情報である「第１駅コード」及びこれに対応する「第１駅名」、他方の駅の情報である「第２駅コード」及びこれに対応する「第２駅名」のそれぞれが関連付けて記録されており、これにより、徒歩移動による乗換が可能な駅であることを経路探索ツール１１０が特定できるようになっている。
「第１駅コード」で特定される駅と、「第２駅コード」で特定される駅との間は、双方から徒歩移動が可能であるため、どちらかの一方が途中駅であれば、他の一方が別経路の近傍駅となる関係である。「駅間所要時間」には、駅間を徒歩で移動したときの所要時間が記録される。「登録日」には、上記情報の登録日が記録される。
【００３４】
図５は、徒歩区間ＤＢ１１３に格納される、事後的に登録される徒歩区間に関するデータテーブルの一例を示した図である。このテーブルを「徒歩区間特定テーブル」と称する。徒歩区間特定テーブル２０１には、徒歩区間登録部１１４により登録された徒歩区間の起点となる駅および終点となる駅の情報、駅間所要時間、登録日、信頼性フラグ、ユーザＩＤが記録される。
徒歩区間特定テーブル２０１は、基本的には運行情報テーブル２００とほぼ同様の構成であり、異なるのは、上述の「信頼性フラグ」と「ユーザＩＤ」が付加されている点である。「ユーザＩＤ」には、徒歩移動による乗換駅の情報を登録したユーザのＩＤ（Identification）が記録される。
【００３５】
徒歩区間特定テーブル２０１には、従来の経路探索では探索対象にならない徒歩区間、例えば徒歩移動したとすれば２０分ないし３０分かかるような徒歩区間も登録することができる。これにより、総運行コストに関係なく、徒歩移動によって乗り換え可能な駅（別路線の近傍駅を含む）の有無を判別することができるとともに、この徒歩区間を探索対象に含めることができる。このように構成することで、ユーザは、改めて乗換駅の情報を収集したり、一から情報を入力して登録する手間を省くことができる。
【００３６】
地図情報ＤＢ１２１に格納される地図情報の一部もまた、データテーブル形式で格納される。
図６は、徒歩区間を明示する際に用いられる地図情報を特定するためのデータテーブルの一例を示した図である。このテーブルを「地図情報特定テーブル」と称する。地図情報特定テーブルは、経路探索ツール１１０による経路探索結果の中に、徒歩区間が含まれている場合に参照される。
地図情報特定テーブル２０２には、「駅コード」およびこれに対応する「駅名」が記録され、「位置」には、運行情報ＤＢ１１２から転記された途中駅の緯度情報と経度情報とが記録される。なお、運行情報ＤＢ１１２を併用する場合は「位置」を省略しても良い。これらの情報により徒歩区間の２つの駅の周辺の地図情報を特定できるようになっている。「登録日」には、上記情報の登録日が記録される。
駅周辺の地図情報の範囲（地理上の領域）は、緯度情報と経度情報とから特定される地点を中心に半径２ｋｍの円で囲まれる範囲であったり、当該駅から乗り換え可能な別路線の近傍駅が所定の数を含む範囲であったりする。
【００３７】
地図情報特定テーブル２０２により、徒歩区間となる２つの駅の位置がそれぞれ緯度情報と経度情報とで特定されるため、例えば各駅周辺の地図情報を拡大又は縮小してユーザ端末５０のディスプレイに両駅を結ぶ経路を表示できるように編集することも可能となる。また、徒歩区間となる２つの駅間の歩行ルートを生成するための情報（線図またはテキスト等の作成用情報）を、駅コードの組み合わせと関連付けておくこともできる。これにより、地図情報の編集にかかる時間を短縮することができる。
【００３８】
［情報端末サービスサーバ］
次に、情報端末サービスサーバ２０について説明する。情報端末サービスサーバ２０は、携帯端末５０その他の情報端末からの経路探索の依頼に対応したり、地図情報の編集を行ったりするものであり、情報端末用インターフェース２００、サービス制御部２１０、探索条件入力部２２０の機能を有している。
【００３９】
情報端末用インターフェース２００は、データ通信用インターフェース１００と同じ機能であるが、ユーザ端末５０と後述するサービス制御部２１０や探索条件入力部２２０との双方向通信を可能にする点で、データ通信用インターフェース１００とは区別される。
【００４０】
サービス制御部２１０は、情報端末サービスサーバ全体における各種動作を制御する。例えば、ユーザ端末５０から経路探索の依頼、つまり探索条件を受け付けたことを情報端末用インターフェース２００が検知したときに、後述する探索条件入力部２２０を制御して探索条件を経路探索ツール１１０に入力させる。
サービス制御部２１０は、経路探索ツール１１０から経路探索結果（徒歩区間を含む）および対応する地図情報を特定するための情報を経路探索ツール１１０より受け取る。受け取ったこれらの情報に徒歩区間が含まれ、かつ、歩行ルートの表示が必要な場合には、地図情報編集部２１１で、徒歩区間の歩行ルートを地図情報に明示するとともに、ユーザ端末５０のディスプレイで表示可能なサイズの電子情報に編集する。そして、携帯端末用インターフェース２２０を制御することにより、編集した電子情報を経路探索依頼の送信元であるユーザ端末５０に返信し、表示させる。
【００４１】
ユーザ端末５０のディスプレイに表示される経路探索結果の一例を図７に示す。
図７の例では、探索条件のうち、徒歩許容時間を１０分と指定し、出発駅である飯田橋から目的駅である北千住駅までの間の経路探索結果の例である探索結果画面３００が示されている。経路探索結果には、７分の徒歩区間を含む経路が特定されているため、探索結果画面３００には、上野御徒町（駅）と湯島（駅）との間が徒歩区間として表示されている。この徒歩区間の下部領域には、選択ボタンとして機能する歩行ルート表示３０１が表示される。ユーザにより歩行ルート表示３０１がクリック操作されると、地図情報編集部２１１で編集された当該徒歩区間の地図情報および歩行ルートが別画面で表示される。
【００４２】
図８は、上記徒歩区間の歩行ルートの表示画面である。図示の例では、上野御徒町（駅）から湯島（駅）までの間の歩行ルートが駅周辺の地図情報として駅間所要時間と共に表示されている。このような経路は、上記徒歩区間が予め登録されていない限り、特定されることはない。徒歩区間ＤＢ１１３に当該徒歩区間が登録され、１０分の徒歩許容時間がユーザによって指定されることで初めて探索対象となり、特定可能となる。また、地図情報ＤＢ１２１に歩行ルートを明示するための情報を含む地図情報が登録され、上記徒歩区間の２つの駅周辺の地図情報が読み出されて初めて上記表示が可能となる。
【００４３】
図９は、他の徒歩区間の地図情報および歩行ルートの表示画面例である。図９の例では、新板橋（駅）から下板橋（駅）までの間を徒歩区間とする所要移動時間８分の歩行ルートが各駅周辺の地図情報と共に表示されている。この表示画面例のように、それぞれの駅と歩行ルートおよび路線名（図９では都営三田線）とがユーザ端末５０のディスプレイの表示領域内に表示されるように編集させることもできる。
歩行ルートの表示に関しては、経路探索結果に含まれる徒歩区間が複数存在する場合であれば、それぞれの徒歩区間に対応させた歩行ルート表示３０１を探索結果内容３００内に表示させることで、特定の歩行ルートのみを任意に選択し表示できるように構成することもできる。
なお、ユーザの操作により、地図情報を任意に拡大・縮小表示させたり、経路探索結果と歩行ルートとを同一画面上に表示させる機能を付加するようにしても良い。この機能自体は公知の技術を用いることで、容易に実現することができる。
【００４４】
探索条件入力部２２０は、ユーザ端末５０からの探索条件を受け付けるためのもので、ルールテーブル２２１を有している。ルールテーブル２２１には、受け付けた探索条件の整合性を検証するためのルールが記録されている。例えば、受け付けた駅の名称が複数の地域に存在した場合の確認を促すルールや、受け付けた徒歩許容時間が入力ミスであろうと判断するためのルール（例えば、３０分を超えた値が入力されていれば、確認のためのアラートを表示する）である。
【００４５】
［運用形態］
次に、本実施形態の経路探索システム１の運用形態例を説明する。ここでは、ユーザが、ユーザ端末５０を通じていくつかの徒歩区間を経路探索サーバ１０に登録するとともに、当該ユーザ端末５０から出発駅、目的駅および徒歩許容時間を探索条件として指定し、これにより、経路探索ツール１１０が、出発駅から目的駅までの経路候補のうち、総所要時間が短い経路を探索する場合の例を説明する。
【００４６】
ユーザは、ユーザ端末５０から経路探索サーバ１０にアクセスし、徒歩区間登録部１１４を通じて、自己が認識している徒歩区間、例えば上記の湯島（駅）−上野御徒町（駅）、あるいは、新板橋（駅）−下板橋（駅）のような徒歩区間を、駅間所要時間と共に入力する。入力に際しては、路線又は駅名候補のウインドウを表示させ、ユーザがいずれかを選ぶようにして入力操作の簡素化を図ることができる。２つの駅の位置（緯度情報および経度情報）については、運行情報ＤＢ１１２から自動転記されるようにする。登録日は自動作成され、ユーザＩＤについては、例えばユーザ端末５０の識別情報が転記される。
徒歩区間登録部１１４は、入力された徒歩区間に「０」の信頼性フラグを付加し、新規の場合には図５に示した内容の徒歩区間特定テーブル２０１を作成し、他方、既に存在する場合は、追記して徒歩区間ＤＢ１１３へ登録する。これにより、当該徒歩区間を、運行ネットワークデータと共に、経路探索の対象区間の一つとして参照することができる。
【００４７】
経路探索ツール１１０による経路探索は、図１０の手順で実行される。すなわち、ユーザ端末５０から、出発駅、目的駅および徒歩許容時間を含む探索条件を受け付けると（ステップＳ１０１：Yes）、経路探索ツール１１０は、運行情報ＤＢ１１２に格納されている運行ネットワークデータおよび徒歩区間ＤＢ１１３に格納されている徒歩区間の情報にアクセスし、受け付けた探索条件に基づいて、出発駅から目的駅へ向かう経路候補の動的な探索を開始する（ステップＳ１０２）。
【００４８】
探索過程では、出発駅と目的駅との間に、近傍駅まで徒歩で移動できる駅、すなわち途中駅ないし乗換駅が存在するかどうかを判定し（ステップＳ１０３）、存在しないときは通常の駅間探索を行う（ステップＳ１０３：Ｎｏ、Ｓ１０４）。
途中駅ないし乗換駅が存在するときは当該駅に関連付けられている駅間所要時間と探索条件に含まれる徒歩許容時間とを比較する（ステップＳ１０３：Yes、Ｓ１０５）。駅間所要時間が徒歩許容時間以下の場合は当該途中駅と当該近傍駅とを結ぶ徒歩区間を、駅間探索と同様、探索対象区間の一つに含める（ステップＳ１０６）。目的駅に到達したかどうかを判定し（ステップＳ１０７）、到着しない場合はステップＳ１０３の処理に戻り（ステップＳ１０７：Ｎｏ）、他方、到着した場合は、動的な探索を終了して、ユーザ端末５０のディスプレイに、例えば図７のような探索結果画面３００に経路探索結果を出力する（ステップＳ１０８：Ｙｅｓ、Ｓ１０９）。
【００４９】
ユーザ端末５０の歩行ルート表示３０１がクリック操作されたことを検知したときの手順は図１１のようになる。
すなわち、経路探索ツール１１０は、経路探索結果の出力後、上記クリック操作されたかどうかを監視しており（ステップＳ２０１）、クリック操作されたことを検知したときは、徒歩区間ＤＢ１１３および地図情報ＤＢ１２１にアクセスして当該徒歩区間の２つの駅、各駅周辺の地図情報および歩行ルートの形成に必要な情報を取得し、取得した情報を地図情報編集部２１１に伝達する（ステップＳ２０１：Ｙｅｓ、Ｓ２０２）。
地図情報編集部２１１は、当該徒歩区間の２つの駅周辺の地図情報に歩行ルートが適切なサイズで明示されるように編集し（ステップＳ２０３）、編集された地図情報を、既存のものと別画面の情報として、ユーザ端末５０に向けて出力する（ステップＳ２０４）。
これにより、ユーザ端末５０のディスプレイに、例えば図８又は図９のような当該徒歩区間の地図情報および歩行ルートが、探索結果画面３００と別画面で表示される。
【００５０】
なお、地図情報編集部２１１は、地図情報を編集する際に、徒歩区間の起点である途中駅から終点である別路線の近傍駅までを結ぶ歩行ルートを太線又は目立つ着色を施して強調表示できるようにすることが好ましい。
【００５１】
このように、本実施形態の経路探索システム１では、徒歩区間ＤＢ１１３に登録した徒歩区間を、出発駅と目的駅との間の途中駅からの次の区間の一つとして、運行データネットワークデータに組み込むことができるので、途中駅で歩いた方が結果的に目的駅へ早く到着する場合があるという実情と、歩きたい（歩いてもよい）ユーザの意図とを反映した経路探索を行うことができる。
【００５２】
徒歩区間ＤＢ１１３には、多くのユーザの路線利用の経験に基づく徒歩区間の情報が格納されるので、路線網の実情に即した経路探索が可能となり、システム利用によるユーザの満足度を高めることができる。
この徒歩区間ＤＢ１１３に登録された徒歩区間のうち、利用頻度が高い徒歩区間や実際に検証された徒歩区間の信頼性フラグを登録時の「０」から「１」へ更新することにより、適宜、この徒歩区間を経路探索の際に利用できるので、運行ネットワークデータが整備され、最適経路候補の特定精度が向上される。
【００５３】
本実施形態は以上の通りであるが、本発明は、上記の実施形態例に限らず、以下のような種々の変形実施が可能である。
（１）本実施形態では、探索条件に徒歩許容時間を含む場合の例を説明したが、徒歩許容時間の指定が無くとも、従来の経路探索における徒歩区間の歩行ルートをディスプレイに表示しても良い。
（２）本実施形態では、ユーザが入力する探索条件として徒歩許容時間、出発駅及び目的駅の場合を例に挙げたが、出発予定時刻、到着予定時刻、利用時間帯等の時刻情報、あるいは徒歩区間が特定できる場合はその起点となる途中駅を探索条件に含めても良い。探索結果をより正確にする上では、好ましい態様となり得る。
（３）徒歩区間を含む最適経路候補が特定された場合の出発駅から目的駅までの全体の所要時間を算出する際には、途中駅の降車ホームから徒歩区間の開始地点までの所要時間と、徒歩区間の終了地点から別路線の近傍駅の乗車ホームまでの所要時間とを加えて算出することもできる。これにより、より正確な所要時間が算出することができる。また、予め徒歩移動所要時間にこれらの時間を加えておいても良い。
（４）本実施形態は、運行情報ＤＢ１１２と徒歩区間ＤＢ１１３、地図情報ＤＢ１２１それぞれを独立して存在するものとして説明したが、これらを統合した１つ又は複数のＤＢに置き換えても良い。
（５）また、本実施形態は、経路探索サーバ１０に運行情報ＤＢ１１２、徒歩区間ＤＢ１１３、地図情報ＤＢ１２１のそれぞれを備えているが、本例に限ることなく経路探索サーバ１０からのアクセスが可能な構成であればいかなる形態のものであっても良い。例えば、地図情報ＤＢ１１３だけがインターネット上の外部サーバに存在したり、例えば商用ＤＢとのリンクによって地図情報の表示機能を実現しても良い。つまり、図１１の処理（ステップＳ２０２，Ｓ２０３）において、徒歩区間となる２つの駅の駅コードと緯度・経度を商用ＤＢに伝達し、その商用ＤＢから２つの駅間がちょうど1つの画面に収まるサイズの地図情報と当該地図上の徒歩ルートとを取得し、取得したこれらの情報を経路探索サーバ１０の地図情報編集部２１１で編集するようにしても良い。
（６）さらに、情報端末サービスサーバ２０が有する各種機能を経路探索サーバ１０側で備えるようにしても良い。
（７）信頼性フラグは「０」と「１」の２つだけでなく、例えば「０」〜「５」のように数字が大きくなるほど信頼性が高まるように多段階に定量化し、「５」に更新された時点で、運行ネットワークデータの一部として組み込む（運行情報ＤＢ１１２への組込又は徒歩区間ＤＢ１１３の開放）ようにしても良い。
【符号の説明】
【００５４】
１０・・・経路探索サーバ、２０・・・情報端末サービスサーバ、５０・・・ユーザ端末、６０・・・メールサーバ、１００・・・データ通信用インターフェース、１１０・・・経路探索ツール、１１１・・・経路探索エンジン、１１２・・・運行情報ＤＢ、１１３・・・徒歩区間ＤＢ、１１４・・・徒歩区間作成部、１１５・・・徒歩区間登録部、１２０・・・地図情報登録ツール、１２１・・・地図情報ＤＢ、１２２・・・登録部、２００・・・情報端末用インターフェース、２１０・・・サービス制御部、２１１・・・地図情報編集部、２２０・・・探索条件入力部、２２１・・・ルールテーブル、３００・・・探索結果画面、Ｎ・・・公衆通信網。
【図１】
0005823217.tif 000002
【図２】
0005823217.tif 000003
【図３】
0005823217.tif 000004
【図４】
0005823217.tif 000005
【図５】
0005823217.tif 000006
【図６】
0005823217.tif 000007
【図７】
0005823217.tif 000008
【図１０】
0005823217.tif 000009
【図１１】
0005823217.tif 000010
【図８】
0005823217.tif 000011
【図９】
0005823217.tif 000012