"列車、電車又はバスを乗降する駅のつながりを表すとともに別路線の近傍駅へ徒歩移動できる駅については徒歩による駅間所要時間が関連付けられている運行ネットワークデータを保持する運行ネットワークデータ保持手段、及び、地図情報を駅周辺毎に取得可能な地図情報保持手段にアクセスするアクセス手段と、出発駅、目的駅およびユーザが徒歩移動を許容できる時間を表す徒歩許容時間を含む探索条件を受け付ける受付手段と、前記アクセス手段を通じて前記運行ネットワーク情報保持手段にアクセスし、前記受付手段で受け付けた探索条件に基づいて、前記運行ネットワークデータにおける出発駅から目的駅へ向かう経路候補を動的に探索し、その際、前記出発駅と前記目的駅との間に、前記近傍駅まで徒歩で移動できる途中駅が存在し、かつ、当該途中駅に関連付けられている前記駅間所要時間が前記徒歩許容時間以下の場合は、当該途中駅と当該近傍駅とを結ぶ徒歩区間を含めた経路候補の探索を可能とする経路探索手段と、経路探索により特定された経路候補に前記徒歩区間が含まれる場合は、前記地図情報保持手段にアクセスして当該途中駅周辺の地図情報を取得し、取得した地図情報に前記徒歩区間を明示して出力する地図情報編集手段と、を備えて成る、経路探索システム。前記近傍駅へ徒歩移動できる駅と当該駅を起点とした前記駅間所要時間とを含む徒歩区間を登録する徒歩区間登録手段をさらに備えており、前記経路探索手段は、この徒歩区間登録手段で登録された徒歩区間を前記運行ネットワークデータ保持手段で保持されている運行ネットワークデータに含めて経路探索を行う、請求項1記載の経路探索システム。前記登録手段は、前記登録された徒歩区間の信頼性を定量的に表す信頼性フラグを当該徒歩区間と関連付けて更新自在に記録するとともに、最新の信頼性フラグが所定の定量値を示すかどうかを判定し、所定の定量値を示すときに当該徒歩区間を前記運行ネットワークデータの一部として前記運行ネットワーク保持手段に保持させる、請求項1又は2記載の経路探索システム。列車、電車又はバスを乗降する駅のつながりを表すとともに別路線の近傍駅へ徒歩移動できる駅については徒歩による駅間所要時間が関連付けられている運行ネットワークデータ、及び、駅周辺毎に取得可能な地図情報にアクセスするアクセス手段とを備えた装置で実行する経路探索方法であって、出発駅、目的駅およびユーザが徒歩移動を許容できる時間を表す徒歩許容時間を含む探索条件の受付を契機に、前記運行ネットワークデータにアクセスし、受け付けた探索条件に基づいて、前記運行ネットワークデータにおける出発駅から目的駅へ向かう経路候補を動的に探索するとともに、前記出発駅と前記目的駅との間に、前記近傍駅まで徒歩で移動できる途中駅が存在し、かつ、当該途中駅に関連付けられている前記駅間所要時間が前記徒歩許容時間以下の場合は、当該途中駅と当該近傍駅とを結ぶ徒歩区間を含めた経路候補の探索を可能とし、経路探索により特定された経路候補に前記途中駅から前記近傍駅への徒歩区間が含まれる場合は、前記地図情報にアクセスして当該途中駅周辺の地図情報を取得し、取得した地図情報に前記徒歩区間を明示して出力する、経路探索方法。ユーザ端末と公衆回線網を介して接続されたサーバを、前記ユーザ端末からの経路探索の依頼に応じて経路探索を行う経路探索システムとして動作させるためのコンピュータプログラムであって、前記サーバを、列車、電車又はバスを乗降する駅のつながりを表すとともに別路線の近傍駅へ徒歩移動できる駅については徒歩による駅間所要時間が関連付けられている運行ネットワークデータを保持する運行ネットワークデータ保持手段、及び、地図情報を駅周辺毎に取得可能な地図情報保持手段にアクセスするアクセス手段;出発駅、目的駅およびユーザが徒歩移動を許容できる時間を表す徒歩許容時間を含む探索条件を受け付ける受付手段;前記アクセス手段を通じて前記運行ネットワーク情報保持手段にアクセスし、前記受付手段で受け付けた探索条件に基づいて、前記運行ネットワークデータにおける出発駅から目的駅へ向かう経路候補を動的に探索し、その際、前記出発駅と前記目的駅との間に、前記近傍駅まで徒歩で移動できる途中駅が存在し、かつ、当該途中駅に関連付けられている前記駅間所要時間が前記徒歩許容時間以下の場合は、当該途中駅と当該近傍駅とを結ぶ徒歩区間を含めた経路候補の探索を可能とする経路探索手段;経路探索により特定された経路候補に前記徒歩区間が含まれる場合は、前記地図情報保持手段にアクセスして当該途中駅周辺の地図情報を取得し、取得した地図情報に前記徒歩区間を明示して出力する地図情報編集手段;として機能させるコンピュータプログラム。特許文献1に記載された経路情報提示装置に代表される従来の経路探索システムは、徒歩区間をなるべく短くなるように探索を行うものである。しかし、最近は、健康志向の観点から徒歩を優先する傾向がみられ、乗り換えるために長い時間を要するとされている駅間でも、敢えて徒歩で駅間移動するユーザが増えている。また、公共交通網上では乗換駅として案内されていない駅であっても、多くのユーザで混雑する乗換駅での乗り換えを回避したり、あるいは、時間帯によっては他の駅へ徒歩で移動して別路線の駅へ乗り換えた方が結果的に早く目的駅に到着できる場合がある。また、不測の事故等により不通区間が発生した場合も、駅間徒歩による乗り換えが可能な近傍駅への案内情報があれば、ユーザに大きな混乱を生じさせることがなくなることが期待される。他方、初めて歩く場合や駅間距離が長い場合には、近傍駅への道順に困ることが想定されるが、駅間地図とその地図上に徒歩経路を表示することによって、徒歩移動が容易となり、歩くことのモチベーションが高まることが期待される。本発明は、このような背景から、徒歩による乗り換え情報を充実させることより、より実用的な経路探索を実現できる経路探索の技術を提供することを課題とする。上記課題を解決するため、本発明は、経路探索システム、経路探索方法及びコンピュータプログラムを提供する。本発明が提供する経路探索システムは、列車、電車又はバスを乗降する駅のつながりを表すとともに別路線の近傍駅へ徒歩移動できる駅については徒歩による駅間所要時間が関連付けられている運行ネットワークデータを保持する運行ネットワークデータ保持手段、及び、地図情報を駅周辺毎に取得可能な地図情報保持手段にアクセスするアクセス手段と、出発駅、目的駅およびユーザが徒歩移動を許容できる時間を表す徒歩許容時間を含む探索条件を受け付ける受付手段と、前記アクセス手段を通じて前記運行ネットワーク情報保持手段にアクセスし、前記受付手段で受け付けた探索条件に基づいて、前記運行ネットワークデータにおける出発駅から目的駅へ向かう経路候補を動的に探索し、その際、前記出発駅と前記目的駅との間に、前記近傍駅まで徒歩で移動できる途中駅が存在し、かつ、当該途中駅に関連付けられている前記駅間所要時間が前記徒歩許容時間以下の場合は、当該途中駅と当該近傍駅とを結ぶ徒歩区間を含めた経路候補の探索を可能とする経路探索手段と、経路探索により特定された経路候補に前記徒歩区間が含まれる場合は、前記地図情報保持手段にアクセスして当該途中駅周辺の地図情報を取得し、取得した地図情報に前記徒歩区間を明示して出力する地図情報編集手段と、を備えて成る。ある実施の態様では、経路探索システムは、前記近傍駅へ徒歩移動できる駅と当該駅を起点とした前記駅間所要時間とを含む徒歩区間を登録する徒歩区間登録手段をさらに備えており、前記経路探索手段は、この徒歩区間登録手段で登録された徒歩区間を前記運行ネットワークデータ保持手段で保持されている運行ネットワークデータに含めて経路探索を行う。この登録手段は、また、前記登録された徒歩区間の信頼性を定量的に表す信頼性フラグを当該徒歩区間と関連付けて更新自在に記録するとともに、最新の信頼性フラグが所定の定量値を示すかどうかを判定し、所定の定量値を示すときに当該徒歩区間を前記運行ネットワークデータの一部として前記運行ネットワーク保持手段に保持させることも行う。信頼性フラグを記録するのは、徒歩区間の登録だけでは全体の経路探索精度に影響を与えることが考えられるため、その信頼性を客観的に確認、検証できるようにするためである。本発明が提供する経路探索方法は、列車、電車又はバスを乗降する駅のつながりを表すとともに別路線の近傍駅へ徒歩移動できる駅については徒歩による駅間所要時間が関連付けられている運行ネットワークデータ、及び、駅周辺毎に取得可能な地図情報にアクセスするアクセス手段とを備えた装置で実行する経路探索方法であって、出発駅、目的駅およびユーザが徒歩移動を許容できる時間を表す徒歩許容時間を含む探索条件の受付を契機に、前記運行ネットワークデータにアクセスし、受け付けた探索条件に基づいて、前記運行ネットワークデータにおける出発駅から目的駅へ向かう経路候補を動的に探索するとともに、前記出発駅と前記目的駅との間に、前記近傍駅まで徒歩で移動できる途中駅が存在し、かつ、当該途中駅に関連付けられている前記駅間所要時間が前記徒歩許容時間以下の場合は、当該途中駅と当該近傍駅とを結ぶ徒歩区間を含めた経路候補の探索を可能とし、経路探索により特定された経路候補に前記途中駅から前記近傍駅への徒歩区間が含まれる場合は、前記地図情報にアクセスして当該途中駅周辺の地図情報を取得し、取得した地図情報に前記徒歩区間を明示して出力する経路探索方法である。本発明が提供するコンピュータプログラムは、ユーザ端末と公衆回線網を介して接続されたサーバを、前記ユーザ端末からの経路探索の依頼に応じて経路探索を行う経路探索システムとして動作させるためのコンピュータプログラムであって、前記サーバを、列車、電車又はバスを乗降する駅のつながりを表すとともに別路線の近傍駅へ徒歩移動できる駅については徒歩による駅間所要時間が関連付けられている運行ネットワークデータを保持する運行ネットワークデータ保持手段、及び、地図情報を駅周辺毎に取得可能な地図情報保持手段にアクセスするアクセス手段;出発駅、目的駅およびユーザが徒歩移動を許容できる時間を表す徒歩許容時間を含む探索条件を受け付ける受付手段;前記アクセス手段を通じて前記運行ネットワーク情報保持手段にアクセスし、前記受付手段で受け付けた探索条件に基づいて、前記運行ネットワークデータにおける出発駅から目的駅へ向かう経路候補を動的に探索し、その際、前記出発駅と前記目的駅との間に、前記近傍駅まで徒歩で移動できる途中駅が存在し、かつ、当該途中駅に関連付けられている前記駅間所要時間が前記徒歩許容時間以下の場合は、当該途中駅と当該近傍駅とを結ぶ徒歩区間を含めた経路候補の探索を可能とする経路探索手段;経路探索により特定された経路候補に前記徒歩区間が含まれる場合は、前記地図情報保持手段にアクセスして当該途中駅周辺の地図情報を取得し、取得した地図情報に前記徒歩区間を明示して出力する地図情報編集手段;として機能させるコンピュータプログラムである。本発明によれば、ある駅から路線の異なる近傍駅までの徒歩区間を、出発駅と目的駅との間に存在する区間の一つとして、運行データネットワークデータに含めて経路候補の探索ができるので、徒歩区間を併用することで利用の多様性を増す路線網の実情と、たとえ駅間距離が長くても歩きたい歩いてもよいユーザの意図に即した経路探索を行うことができる。また、適宜、徒歩区間を運行ネットワークデータの一部として組み込むことができるので、経路探索の結果をユーザの意図を反映したものにチューニングすることができる。以下、本発明を、携帯端末向けの経路探索サービスを可能にするネットワーク型の経路探索システムに適用した場合の実施の形態例を説明する。図1は、この実施形態の経路探索システムの全体構成図であり、特徴的な部分のみを掲示してある。この経路探索システム1は、インターネット等の公衆通信網Nに接続される経路探索サーバ10と、ユーザ端末50との間で双方向の通信を行う1又は複数の情報端末サービスサーバ20図示の例では1つとを含んで構成される。ユーザ端末50は、データ通信及びデータ処理機能を有する携帯端末、及び、パーソナルコンピュータPCなどである。この携帯情報端末は、メールサーバ60を介して公衆通信網Nに接続されるものも含む。[経路探索サーバ]経路探索サーバ10は、サーバ本体と本発明のコンピュータプログラムとの協働により実現される。すなわち、サーバ本体が、本発明のコンピュータプログラムを読み込んで実行することにより、そのサーバ本体を、データ通信用インターフェース100、経路探索ツール110、地図情報登録ツール120として機能させ、経路探索のための情報処理を実行可能にする。データ通信用インターフェース100は、データ通信及びデータ処理機能を有するユーザ端末50との双方向通信を可能にするとともに、これらの情報端末が閲覧可能な階層ページ画面を提供する。この階層ページ画面では、経路探索のWebサービスを行なうためのもので、経路探索条件の精緻な指定をシステム側とユーザとの間でインタラクティブに行なうことにより、ユーザが満足する経路探索を行なう環境を提供する。経路探索の結果情報の表示も、このページ画面で行なうことができる。経路探索ツール110は、経路探索エンジン111のほか、外部記憶装置図示せずに構築された運行情報DBDBはデータベースの略、以下同じ112および徒歩区間DB113を有し、さらに、徒歩区間を事後的に徒歩区間DB113に登録するための徒歩区間登録部114の機能を有している。運行情報DB112には、駅、列車、電車、バスの路線網及び駅の繋がり、各駅の緯度経度、時刻表等の運行情報が格納されている。なお、別路線の近傍駅まで徒歩で移動可能な駅については、徒歩区間の情報2つの駅名、駅間所要時間等が関連付けられて格納されている。また、徒歩区間DB113には、ユーザが事後的に登録した上記徒歩区間の情報が格納される。運行情報DB112および徒歩区間DB113に保持されたこれらの情報が、経路探索において経路候補を特定する際に参照される運行ネットワークデータとなる。なお、運行情報DB112および徒歩区間DB113の情報は、データテーブル形式で格納される。これについては、後述する。経路探索エンジン111は、出発駅と目的駅とを含む探索条件を受け付けたときに、上記運行ネットワークデータをもとに、出発駅から目的駅に向かう経路候補を動的に探索する。その際、徒歩区間の情報も考慮する。動的に探索とは、出発駅を起点として経路の運行コストが最も小さくなる次の区間、すなわち次の駅や停留所以下の説明では、停留所も駅に含まれるものとするの探索を、例えば水面に石を投げたときの波紋のように連鎖的に繰り返すことにより探索することをいい、探索途中で現実的でない経路となることが判明した場合は、その経路についての次の駅以降の探索を止める。このような手法は、出発駅から目的駅までの経路を特定した後に当該経路上の最適な運行コストの経路を探索する手法とは異なるものである。経路探索エンジン111は、探索条件の中に、徒歩で別路線の近傍駅まで移動しても良いとする時間、すなわち徒歩許容時間が指定されているときは、出発駅と目的駅との間の駅、すなわち途中駅に関連付けられている駅間所要時間と徒歩許容時間とを比較する。そして、駅間所要時間が徒歩許容時間より短い場合は、当該途中駅を起点とし、近傍駅を終点とする徒歩区間を含めた経路候補の探索を行う。経路候補の探索時に考慮する運行コストは、通常は時間を対象とする。すなわち、次の区間駅間、徒歩区間が最短時間となる経路候補を探索していく。但し、時間以外にも、距離、運賃、あるいは、これらの組み合わせを運行コストとしても良い。経路探索エンジン111は、また、運行コストをもとに探索した複数の経路の各々について、当該経路の総運行コスト、例えば総所要時間を算出し、算出された総所要時間の小さい順に、複数の経路をソートすることもできる。さらに、経路探索結果の中に徒歩区間が含まれる場合には、当該徒歩区間の起点となる駅および終点となる駅の情報を情報端末サービスサーバ20後述する地図情報編集部211に送る。徒歩区間登録部114は、ユーザ又は経路探索サーバ10の管理者などにより入力された、徒歩区間の情報を徒歩区間DB113に登録する。但し、登録される徒歩区間のうち駅間所要時間はあくまでもユーザ等の主観に基づいた情報であることから、駅間所要時間の信頼性を定量値で表す更新自在の信頼性フラグを当該徒歩区間と関連付けて記録する。信頼性フラグは、例えば未検証情報を表す0とし、登録を行ったユーザのみが利用可能な情報とする。管理者等による所定の検証が済んだ後であれば、信頼性が高まったとみなされ、信頼性フラグは1つまり検証済みを表す情報に更新される。徒歩区間登録部114は、信頼性フラグを適宜更新するとともに最新の信頼性フラグを監視し、1のときは当該徒歩区間を運行ネットワークデータの一部として運行情報DB112に、適宜保持させる。あるいは、運行情報DB112に運行ネットワークデータの一部として組み込まずに徒歩区間DB113にそのまま記録しておき、複数のユーザが経路探索時に利用可能な情報として、記録情報を開放させることもできる。なお、出発駅と目的駅との間に存在する途中駅に、徒歩区間の情報が関連付けられていない場合に、ユーザから受け付けた徒歩許容時間内にある徒歩移動による乗換駅の情報を新たに作成する徒歩区間情報作成機能を付加し、これにより作成された徒歩区間の情報を徒歩区間DB114に登録するようにしても良い。つまり、利用者による登録によらず、運行情報DB112に記録されている途中駅及びその近傍駅の緯度経度情報をもとに、経路探索サーバ10が独自に徒歩区間を作成しても良い。地図情報登録ツール120は、地図情報DB121と地図情報登録部122とを含んで構成される。地図情報登録部122は、駅毎に、当該駅周辺の道路名、建物名、交差点名等の地理情報を図化した地図情報や歩行ルートを形成するための情報を地図情報DB121に登録するとともに、既に格納されている地図情報の修正、削除などを行う。地図情報については、自らそれを作成して保持するほか、公衆通信網インターネットN上で提供されている地図情報サービスのリンク先情報を保持することもできる。このように構成される経路探索サーバ10の経路探索ツール110による一般的な経路探索処理、すなわち出発駅と目的駅との間の経路探索の概要を説明する。比較のため、徒歩区間を考慮する従来の経路探索の概要を図2、本実施形態の経路探索ツール110による経路探索の概要を図3に示す。従来の経路探索では、図2に示すように、出発駅から目的駅に至る途中の途中駅から別路線の近傍駅他の途中駅への徒歩による移動所要時間が5分の第1徒歩区間は存在するが、9分の第2徒歩区間は存在しない場合、第2徒歩区間は次の区間の探索候補の対象にならない。つまり、実際には第2徒歩区間を含む経路の総運行コストが最小となる場合であっても、最適な経路としては、太実線で結ばれている第1徒歩区間を含む経路が特定される。これに対して、本実施形態の経路探索では、従来は存在しなかった上記第2徒歩区間を徒歩区間DB113に登録可能とするとともに、徒歩許容時間を含む探索条件で動的に経路候補を探索するので、例えば徒歩許容時間を例えば10分と指定することで、図3に示すように、上記第2徒歩区間登録済の場合を含む経路が特定され得る。その結果、実情に即した最適な経路探索が可能となる。なお、総運行コストの大小に関わらず、例えば10分は歩いても良い、あるいは積極的に歩きたいユーザが徒歩許容時間を10分と指定することで、上記第2徒歩区間を含む経路を意図的に特定することもできる。このような特徴的な経路探索を実現し、且つ、従来の経路探索をも可能にするために、運行情報DB112および徒歩区間DB113に格納されるデータテーブルについて、以下説明する。図4は、運行情報DB112に格納される、近傍駅まで徒歩可能な乗換駅に関するデータテーブルの一例を示した図である。このテーブルを運行情報テーブルと称する。運行情報テーブル200には、例えば路線毎の駅の情報緯度経度情報を含むのほか、既に運行ネットワークデータの一部として組み込まれている徒歩区間の情報、すなわち2つの駅、駅間所要時間、登録日が記録される。上記徒歩区間の情報は、具体的には、2つの駅の一方の駅の情報である第1駅コード及びこれに対応する第1駅名、他方の駅の情報である第2駅コード及びこれに対応する第2駅名のそれぞれが関連付けて記録されており、これにより、徒歩移動による乗換が可能な駅であることを経路探索ツール110が特定できるようになっている。第1駅コードで特定される駅と、第2駅コードで特定される駅との間は、双方から徒歩移動が可能であるため、どちらかの一方が途中駅であれば、他の一方が別経路の近傍駅となる関係である。駅間所要時間には、駅間を徒歩で移動したときの所要時間が記録される。登録日には、上記情報の登録日が記録される。図5は、徒歩区間DB113に格納される、事後的に登録される徒歩区間に関するデータテーブルの一例を示した図である。このテーブルを徒歩区間特定テーブルと称する。徒歩区間特定テーブル201には、徒歩区間登録部114により登録された徒歩区間の起点となる駅および終点となる駅の情報、駅間所要時間、登録日、信頼性フラグ、ユーザIDが記録される。徒歩区間特定テーブル201は、基本的には運行情報テーブル200とほぼ同様の構成であり、異なるのは、上述の信頼性フラグとユーザIDが付加されている点である。ユーザIDには、徒歩移動による乗換駅の情報を登録したユーザのIDIdentificationが記録される。徒歩区間特定テーブル201には、従来の経路探索では探索対象にならない徒歩区間、例えば徒歩移動したとすれば20分ないし30分かかるような徒歩区間も登録することができる。これにより、総運行コストに関係なく、徒歩移動によって乗り換え可能な駅別路線の近傍駅を含むの有無を判別することができるとともに、この徒歩区間を探索対象に含めることができる。このように構成することで、ユーザは、改めて乗換駅の情報を収集したり、一から情報を入力して登録する手間を省くことができる。地図情報DB121に格納される地図情報の一部もまた、データテーブル形式で格納される。図6は、徒歩区間を明示する際に用いられる地図情報を特定するためのデータテーブルの一例を示した図である。このテーブルを地図情報特定テーブルと称する。地図情報特定テーブルは、経路探索ツール110による経路探索結果の中に、徒歩区間が含まれている場合に参照される。地図情報特定テーブル202には、駅コードおよびこれに対応する駅名が記録され、位置には、運行情報DB112から転記された途中駅の緯度情報と経度情報とが記録される。なお、運行情報DB112を併用する場合は位置を省略しても良い。これらの情報により徒歩区間の2つの駅の周辺の地図情報を特定できるようになっている。登録日には、上記情報の登録日が記録される。駅周辺の地図情報の範囲地理上の領域は、緯度情報と経度情報とから特定される地点を中心に半径2kmの円で囲まれる範囲であったり、当該駅から乗り換え可能な別路線の近傍駅が所定の数を含む範囲であったりする。地図情報特定テーブル202により、徒歩区間となる2つの駅の位置がそれぞれ緯度情報と経度情報とで特定されるため、例えば各駅周辺の地図情報を拡大又は縮小してユーザ端末50のディスプレイに両駅を結ぶ経路を表示できるように編集することも可能となる。また、徒歩区間となる2つの駅間の歩行ルートを生成するための情報線図またはテキスト等の作成用情報を、駅コードの組み合わせと関連付けておくこともできる。これにより、地図情報の編集にかかる時間を短縮することができる。[情報端末サービスサーバ]次に、情報端末サービスサーバ20について説明する。情報端末サービスサーバ20は、携帯端末50その他の情報端末からの経路探索の依頼に対応したり、地図情報の編集を行ったりするものであり、情報端末用インターフェース200、サービス制御部210、探索条件入力部220の機能を有している。情報端末用インターフェース200は、データ通信用インターフェース100と同じ機能であるが、ユーザ端末50と後述するサービス制御部210や探索条件入力部220との双方向通信を可能にする点で、データ通信用インターフェース100とは区別される。サービス制御部210は、情報端末サービスサーバ全体における各種動作を制御する。例えば、ユーザ端末50から経路探索の依頼、つまり探索条件を受け付けたことを情報端末用インターフェース200が検知したときに、後述する探索条件入力部220を制御して探索条件を経路探索ツール110に入力させる。サービス制御部210は、経路探索ツール110から経路探索結果徒歩区間を含むおよび対応する地図情報を特定するための情報を経路探索ツール110より受け取る。受け取ったこれらの情報に徒歩区間が含まれ、かつ、歩行ルートの表示が必要な場合には、地図情報編集部211で、徒歩区間の歩行ルートを地図情報に明示するとともに、ユーザ端末50のディスプレイで表示可能なサイズの電子情報に編集する。そして、携帯端末用インターフェース220を制御することにより、編集した電子情報を経路探索依頼の送信元であるユーザ端末50に返信し、表示させる。ユーザ端末50のディスプレイに表示される経路探索結果の一例を図7に示す。図7の例では、探索条件のうち、徒歩許容時間を10分と指定し、出発駅である飯田橋から目的駅である北千住駅までの間の経路探索結果の例である探索結果画面300が示されている。経路探索結果には、7分の徒歩区間を含む経路が特定されているため、探索結果画面300には、上野御徒町駅と湯島駅との間が徒歩区間として表示されている。この徒歩区間の下部領域には、選択ボタンとして機能する歩行ルート表示301が表示される。ユーザにより歩行ルート表示301がクリック操作されると、地図情報編集部211で編集された当該徒歩区間の地図情報および歩行ルートが別画面で表示される。図8は、上記徒歩区間の歩行ルートの表示画面である。図示の例では、上野御徒町駅から湯島駅までの間の歩行ルートが駅周辺の地図情報として駅間所要時間と共に表示されている。このような経路は、上記徒歩区間が予め登録されていない限り、特定されることはない。徒歩区間DB113に当該徒歩区間が登録され、10分の徒歩許容時間がユーザによって指定されることで初めて探索対象となり、特定可能となる。また、地図情報DB121に歩行ルートを明示するための情報を含む地図情報が登録され、上記徒歩区間の2つの駅周辺の地図情報が読み出されて初めて上記表示が可能となる。図9は、他の徒歩区間の地図情報および歩行ルートの表示画面例である。図9の例では、新板橋駅から下板橋駅までの間を徒歩区間とする所要移動時間8分の歩行ルートが各駅周辺の地図情報と共に表示されている。この表示画面例のように、それぞれの駅と歩行ルートおよび路線名図9では都営三田線とがユーザ端末50のディスプレイの表示領域内に表示されるように編集させることもできる。歩行ルートの表示に関しては、経路探索結果に含まれる徒歩区間が複数存在する場合であれば、それぞれの徒歩区間に対応させた歩行ルート表示301を探索結果内容300内に表示させることで、特定の歩行ルートのみを任意に選択し表示できるように構成することもできる。なお、ユーザの操作により、地図情報を任意に拡大縮小表示させたり、経路探索結果と歩行ルートとを同一画面上に表示させる機能を付加するようにしても良い。この機能自体は公知の技術を用いることで、容易に実現することができる。探索条件入力部220は、ユーザ端末50からの探索条件を受け付けるためのもので、ルールテーブル221を有している。ルールテーブル221には、受け付けた探索条件の整合性を検証するためのルールが記録されている。例えば、受け付けた駅の名称が複数の地域に存在した場合の確認を促すルールや、受け付けた徒歩許容時間が入力ミスであろうと判断するためのルール例えば、30分を超えた値が入力されていれば、確認のためのアラートを表示するである。[運用形態]次に、本実施形態の経路探索システム1の運用形態例を説明する。ここでは、ユーザが、ユーザ端末50を通じていくつかの徒歩区間を経路探索サーバ10に登録するとともに、当該ユーザ端末50から出発駅、目的駅および徒歩許容時間を探索条件として指定し、これにより、経路探索ツール110が、出発駅から目的駅までの経路候補のうち、総所要時間が短い経路を探索する場合の例を説明する。ユーザは、ユーザ端末50から経路探索サーバ10にアクセスし、徒歩区間登録部114を通じて、自己が認識している徒歩区間、例えば上記の湯島駅-上野御徒町駅、あるいは、新板橋駅-下板橋駅のような徒歩区間を、駅間所要時間と共に入力する。入力に際しては、路線又は駅名候補のウインドウを表示させ、ユーザがいずれかを選ぶようにして入力操作の簡素化を図ることができる。2つの駅の位置緯度情報および経度情報については、運行情報DB112から自動転記されるようにする。登録日は自動作成され、ユーザIDについては、例えばユーザ端末50の識別情報が転記される。徒歩区間登録部114は、入力された徒歩区間に0の信頼性フラグを付加し、新規の場合には図5に示した内容の徒歩区間特定テーブル201を作成し、他方、既に存在する場合は、追記して徒歩区間DB113へ登録する。これにより、当該徒歩区間を、運行ネットワークデータと共に、経路探索の対象区間の一つとして参照することができる。経路探索ツール110による経路探索は、図10の手順で実行される。すなわち、ユーザ端末50から、出発駅、目的駅および徒歩許容時間を含む探索条件を受け付けるとステップS101:Yes、経路探索ツール110は、運行情報DB112に格納されている運行ネットワークデータおよび徒歩区間DB113に格納されている徒歩区間の情報にアクセスし、受け付けた探索条件に基づいて、出発駅から目的駅へ向かう経路候補の動的な探索を開始するステップS102。探索過程では、出発駅と目的駅との間に、近傍駅まで徒歩で移動できる駅、すなわち途中駅ないし乗換駅が存在するかどうかを判定しステップS103、存在しないときは通常の駅間探索を行うステップS103:No、S104。途中駅ないし乗換駅が存在するときは当該駅に関連付けられている駅間所要時間と探索条件に含まれる徒歩許容時間とを比較するステップS103:Yes、S105。駅間所要時間が徒歩許容時間以下の場合は当該途中駅と当該近傍駅とを結ぶ徒歩区間を、駅間探索と同様、探索対象区間の一つに含めるステップS106。目的駅に到達したかどうかを判定しステップS107、到着しない場合はステップS103の処理に戻りステップS107:No、他方、到着した場合は、動的な探索を終了して、ユーザ端末50のディスプレイに、例えば図7のような探索結果画面300に経路探索結果を出力するステップS108:Yes、S109。ユーザ端末50の歩行ルート表示301がクリック操作されたことを検知したときの手順は図11のようになる。すなわち、経路探索ツール110は、経路探索結果の出力後、上記クリック操作されたかどうかを監視しておりステップS201、クリック操作されたことを検知したときは、徒歩区間DB113および地図情報DB121にアクセスして当該徒歩区間の2つの駅、各駅周辺の地図情報および歩行ルートの形成に必要な情報を取得し、取得した情報を地図情報編集部211に伝達するステップS201:Yes、S202。地図情報編集部211は、当該徒歩区間の2つの駅周辺の地図情報に歩行ルートが適切なサイズで明示されるように編集しステップS203、編集された地図情報を、既存のものと別画面の情報として、ユーザ端末50に向けて出力するステップS204。これにより、ユーザ端末50のディスプレイに、例えば図8又は図9のような当該徒歩区間の地図情報および歩行ルートが、探索結果画面300と別画面で表示される。なお、地図情報編集部211は、地図情報を編集する際に、徒歩区間の起点である途中駅から終点である別路線の近傍駅までを結ぶ歩行ルートを太線又は目立つ着色を施して強調表示できるようにすることが好ましい。このように、本実施形態の経路探索システム1では、徒歩区間DB113に登録した徒歩区間を、出発駅と目的駅との間の途中駅からの次の区間の一つとして、運行データネットワークデータに組み込むことができるので、途中駅で歩いた方が結果的に目的駅へ早く到着する場合があるという実情と、歩きたい歩いてもよいユーザの意図とを反映した経路探索を行うことができる。徒歩区間DB113には、多くのユーザの路線利用の経験に基づく徒歩区間の情報が格納されるので、路線網の実情に即した経路探索が可能となり、システム利用によるユーザの満足度を高めることができる。この徒歩区間DB113に登録された徒歩区間のうち、利用頻度が高い徒歩区間や実際に検証された徒歩区間の信頼性フラグを登録時の0から1へ更新することにより、適宜、この徒歩区間を経路探索の際に利用できるので、運行ネットワークデータが整備され、最適経路候補の特定精度が向上される。本実施形態は以上の通りであるが、本発明は、上記の実施形態例に限らず、以下のような種々の変形実施が可能である。1本実施形態では、探索条件に徒歩許容時間を含む場合の例を説明したが、徒歩許容時間の指定が無くとも、従来の経路探索における徒歩区間の歩行ルートをディスプレイに表示しても良い。2本実施形態では、ユーザが入力する探索条件として徒歩許容時間、出発駅及び目的駅の場合を例に挙げたが、出発予定時刻、到着予定時刻、利用時間帯等の時刻情報、あるいは徒歩区間が特定できる場合はその起点となる途中駅を探索条件に含めても良い。探索結果をより正確にする上では、好ましい態様となり得る。3徒歩区間を含む最適経路候補が特定された場合の出発駅から目的駅までの全体の所要時間を算出する際には、途中駅の降車ホームから徒歩区間の開始地点までの所要時間と、徒歩区間の終了地点から別路線の近傍駅の乗車ホームまでの所要時間とを加えて算出することもできる。これにより、より正確な所要時間が算出することができる。また、予め徒歩移動所要時間にこれらの時間を加えておいても良い。4本実施形態は、運行情報DB112と徒歩区間DB113、地図情報DB121それぞれを独立して存在するものとして説明したが、これらを統合した1つ又は複数のDBに置き換えても良い。5また、本実施形態は、経路探索サーバ10に運行情報DB112、徒歩区間DB113、地図情報DB121のそれぞれを備えているが、本例に限ることなく経路探索サーバ10からのアクセスが可能な構成であればいかなる形態のものであっても良い。例えば、地図情報DB113だけがインターネット上の外部サーバに存在したり、例えば商用DBとのリンクによって地図情報の表示機能を実現しても良い。つまり、図11の処理ステップS202,S203において、徒歩区間となる2つの駅の駅コードと緯度経度を商用DBに伝達し、その商用DBから2つの駅間がちょうど1つの画面に収まるサイズの地図情報と当該地図上の徒歩ルートとを取得し、取得したこれらの情報を経路探索サーバ10の地図情報編集部211で編集するようにしても良い。6さらに、情報端末サービスサーバ20が有する各種機能を経路探索サーバ10側で備えるようにしても良い。7信頼性フラグは0と1の2つだけでなく、例えば0~5のように数字が大きくなるほど信頼性が高まるように多段階に定量化し、5に更新された時点で、運行ネットワークデータの一部として組み込む運行情報DB112への組込又は徒歩区間DB113の開放ようにしても良い。"