JP2006155076A - 図形データ管理装置 - Google Patents

Abstract

【課題】図面データの排他制御に係る処理の負荷を低減させる。
【解決手段】交通ダイヤＤＢ１３は、複数の管理項目を用いて交通ダイヤデータを階層管理する。具体的には、施行日を用いて大分類し、施行日および線区を用いて中分類し、施行日、線区および種別を用いて小分類し、そして、施行日、線区、種別および列車番号を用いて交通ダイヤデータ毎に管理する。また、階層毎に排他フラグ管理ＴＬを排他フラグＤＢ１４に登録し、個々の交通ダイヤデータに対する排他フラグをいずれか１つの排他フラグ管理ＴＬで管理する。つまり、同じ図形に対する排他フラグを複数の排他管理テーブルに重複登録しない。排他制御部１２は、排他フラグが設定されている交通ダイヤデータの編集を、当該排他フラグが与えられた端末以外の端末から受付けないようにすることで、交通ダイヤデータの排他制御を行なう。
【選択図】図１

Description

本発明は、複数の端末によって編集されるデータの管理技術に関し、特に、交通ダイヤデータに好適なデータ管理技術に関する。

特許文献１には、複数の端末に表示させる図面データを複数のメッシュに分割して、メッシュ毎に排他フラグを管理し、排他フラグが設定されいるメッシュに対する編集を、当該排他フラグが与えられた端末以外の端末から受付けないようにすることで、複数の端末間における図面データの排他制御を行なう技術が開示されている。

ところで、列車の交通ダイヤデータは、線区を構成する各駅の時刻情報を含む。したがって、交通ダイヤデータは、縦軸を線区を構成する各駅とし、横軸を時刻とするグラフ、つまり、図面データとして表示できる。このため、特許文献１の技術は、交通ダイヤデータの編集を複数の端末から受付ける場合における交通ダイヤデータの排他制御に適用することもできる。

特開平５-２１６９４６号公報

しかし、特許文献１の技術を交通ダイヤデータの排他制御に適用した場合、次のような問題が生じる。すわわち、交通ダイヤデータは、通常、施行日を単位として管理される。ここで、列車本数の多い路線（例えば都市部を走行する路線）の場合、同じ施行日に、数百〜数千本の交通ダイヤデータが存在することもある。したがって、同じ施行日の交通ダイヤデータを１つの図面データとして複数の端末各々に表示し編集を受付けようとした場合、個々の交通ダイヤデータの排他制御を実現するためには、図面データを分割するメッシュを小さくして、１つのメッシュに１つの交通ダイヤデータのみが含まれるようにしなければならない。このため、メッシュ数が膨大となり、したがって、交通ダイヤデータの排他制御のために管理しなければならない排他フラグの数も膨大となり、排他制御のための処理の負荷が大きくなる。

本発明は上記事情に鑑みてなされたものであり、本発明の目的は、図面データの排他制御に係る処理の負荷を低減させることにある。

上記課題を解決するために、本発明では、図面データに含まれる個々の図形を複数の管理項目を用いて階層的に分類する。例えば、第１の管理項目を用いて図形を大分類し、第１および第２の管理項目を用いて図形を中分類し、第１乃至第３の管理項目を用いて図形を小分類し、そして、第１乃至第４の管理項目を用いて個々の図形を特定する。また、前記階層毎に排他フラグ管理テーブルを用意し、個々の図形に対する排他フラグをいずれかの排他フラグ管理テーブルで管理する。ここで、同じ図形に対する排他フラグが複数の排他管理テーブルに重複登録されないようにすることが好ましい。例えば、大分類の階層に対応する排他フラグ管理テーブルにおいて、ある大分類に対する排他フラグを登録する場合、当該大分類に属する中分類、小分類および個々の図形に対する排他フラグは設定しない。また、例えば、個々の図形の階層に対応する排他フラグ管理テーブルにおいて、ある図形に対する排他フラグを登録する場合、当該図形が属する小分類、中分類および大分類に対する排他フラグは設定しない。そして、排他フラグが設定されている図形あるいは排他フラグが設定されている分類に属する図形の編集を、当該排他フラグが与えられた端末以外の端末から受付けないようにすることで、図形編集を複数の端末から受付ける場合における図形の排他制御を行なう。

例えば、本発明の図形データ管理装置は、少なくとも１つの図形データ編集装置より図形データの更新要求を受付け、受付けた要求に従って自身が保持する当該図形データを更新する図形データ管理装置であって、複数の管理項目を用いて階層的に分類された図形データが複数記憶された図形データ記憶手段と、前記図形データ記憶手段に記憶された図形データを読み出して前記少なくとも１つの図形データ編集装置に送信する図形データ送信手段と、前記階層毎に設けられた、対応する階層において分類される図形データのグループに対する排他を獲得したユーザの情報が登録された排他フラグ記憶手段と、前記階層毎に設けられた排他フラグ記憶手段を参照して、前記更新要求の対象となる図形データの排他を制御する排他制御手段と、を有する。

前記排他制御手段は、前記更新要求の対象となる図形データを含むグループに対する排他を獲得したユーザの情報を、前記階層毎に設けられた排他フラグ記憶手段から検索し、検索したユーザの情報が前記更新要求の送信元の情報と一致する場合に、前記更新要求に従い前記図形データ記憶手段に記憶されている前記更新要求の対象となる図形データを更新し、検索したユーザの情報が前記更新要求の送信元の情報と一致しない場合、もしくは、ユーザの情報を検索できなかった場合に、前記更新要求に従った前記図形データ記憶手段の更新を拒否する。

なお、前記排他フラグ記憶手段は、当該排他フラグ記憶手段が対応する階層よりも上位の階層において分類される図形データのグループに対する排他を獲得したユーザの情報が、当該上位の階層に対応する排他フラグ記憶手段に登録されている場合に、当該グループに属する図形データに対する排他を獲得した当該ユーザの情報が重複して登録されていないようにしてもよい。

本発明によれば、排他フラグの数を低減することができ、これにより、図形の排他制御に係る処理の負荷を低減させることができる。

以下、本発明の実施の形態について説明する。

図１は本発明の一実施形態が適用された交通ダイヤデータ編集管理システムの概略図である。図示するように、本実施形態の交通ダイヤデータ編集管理システムは、交通ダイヤ管理サーバ１と、少なくとも１つの交通ダイヤ編集端末２とが、インターネットなどのネットワーク３を介して互いに接続されて構成されている。

交通ダイヤ管理サーバ１は、列車の交通ダイヤデータを保持する。また、交通ダイヤ編集端末２から交通ダイヤデータの編集を受付けて、自身が保持する交通ダイヤデータに編集内容を反映させる。この際、編集対象の交通ダイヤデータに対する排他を獲得した交通ダイヤ編集端末２以外の交通ダイヤ編集端末２から、当該編集対象の交通ダイヤデータに対する編集を受付けないようにすることで、交通ダイヤデータの排他制御を行なう。

図示するように、交通ダイヤ管理サーバ１は、ネットワーク３に接続するためのネットワークＩＦ部１１と、排他制御部１２と、交通ダイヤＤＢ（データベース）１３と、排他フラグ管理ＤＢ１４と、更新情報管理ＴＬ（テーブル）１５と、を有する。

交通ダイヤＤＢ１３には、列車の交通ダイヤデータが記憶されている。図２は交通ダイヤＤＢ１３の登録内容例を示す図である。図示するように、交通ダイヤＤＢ１３には、列車毎に交通ダイヤのレコード１３０が登録されている。レコード１３０は、列車にユニーク割り当てられた列車番号を登録するフィールド１３１と、施行日（列車の運行日）を登録するフィールド１３２と、列車が運行する路線の区間を示す線区を登録するフィールド１３３と、列車の運行目的（営業、回送等）を登録するフィールド１３４と、列車の交通ダイヤデータを登録するフィールド１３５と、を有する。

フィールド１３５に登録される列車の交通ダイヤデータは、線区を構成する各駅（始発駅から終着駅までの各駅）の情報と、各駅における出発及び/又は到着時刻とを有する。また、フィールド１３１〜１３４に登録されている各データは、列車の交通ダイヤデータを階層的に分類するための管理項目である。交通ダイヤデータは、フィールド１３２の施行日により大分類され、フィールド１３２、１３３の施行日、線区により中分類され、フィールド１３２、１３３、１３４の施行日、線区、種別により小分類され、そして、フィールド１３２、１３３、１３４、１３１の施行日、線区、種別、列車番号により個々の列車ダイヤデータが特定される。

排他フラグ管理ＤＢ１４には、複数の管理項目により階層管理される列車の交通ダイヤデータの階層毎に、交通ダイヤデータの排他制御を管理するための排他フラグ管理ＴＬが記憶されている。上述したように、交通ダイヤデータは、大分類、中分類、小分類、および、交通ダイヤデータ毎の４階層により階層管理されている。このため、排他フラグ管理ＴＬも、分類、中分類、小分類および交通ダイヤデータ毎の４階層のそれぞれの階層毎に設けられている。

図３は排他フラグ管理ＤＢ１４の登録内容例を示す図であり、図３（Ａ）は階層「大分類」に対応する排他フラグ管理ＴＬ１４１の登録内容例を、図３（Ｂ）は階層「中分類」に対応する排他フラグ管理ＴＬ１４２の登録内容例を、図３（Ｃ）は階層「小分類」に対応する排他フラグ管理ＴＬ１４３の登録内容例を、そして、図３（Ｄ）は階層「交通ダイヤデータ毎」に対応する排他フラグ管理ＴＬ１４４の登録内容例を示している。

排他フラグ管理ＴＬ１４１には、図３（Ａ）に示すように、施行日を単位とする排他フラグのレコード１４１０が登録される。レコード１４１０は、施行日を登録するフィールド１４１１と、当該施行日に運行する全ての列車の交通ダイヤデータに対する排他フラグを獲得しているユーザのユーザＩＤを登録するフィールド１４１５と、を有する。

排他フラグ管理ＴＬ１４２には、図３（Ｂ）に示すように、施行日および線区の組合せを単位とする排他フラグのレコード１４２０が登録される。レコード１４２０は、施行日を登録するフィールド１４２１と、線区を登録するフィールド１４２２と、当該施行日に当該線区を運行する全ての列車の交通ダイヤデータに対する排他フラグを獲得しているユーザのユーザＩＤを登録するフィールド１４２５と、を有する。

排他フラグ管理ＴＬ１４３には、図３（Ｃ）に示すように、施行日、線区および種別の組合せを単位とする排他フラグのレコード１４３０が登録される。レコード１４３０は、施行日を登録するフィールド１４３１と、線区を登録するフィールド１４３２と、種別を登録するフィールド１４３３と、当該施行日に当該線区を当該種別の目的で運行する全ての列車の交通ダイヤデータに対する排他フラグを獲得しているユーザのユーザＩＤを登録するフィールド１４３５と、を有する。

そして、排他フラグ管理ＴＬ１４４には、図３（Ｄ）に示すように、施行日、線区、種別および列車番号の組合せを単位とする排他フラグのレコード１４４０が登録される。レコード１４４０は、施行日を登録するフィールド１４４１と、線区を登録するフィールド１４４２と、種別を登録するフィールド１４４３と、列車番号を登録するフィールド１４４４と、当該施行日に当該線区を当該種別の目的で運行する当該列車番号を持つ列車の交通ダイヤデータに対する排他フラグを獲得しているユーザのユーザＩＤを登録するフィールド１４４５と、を有する。

更新情報管理ＴＬ１５には、交通ダイヤ編集端末２から受信した後述する更新情報登録要求が登録される。図４は更新情報管理ＴＬ１５の登録内容例を示す図である。図示するように、更新情報管理ＴＬ１５には、交通ダイヤ編集端末２から受信した後述する更新情報登録要求のレコード１５０が登録される。レコード１５０は、ユーザのユーザＩＤを登録するフィールド１５１と、更新情報登録要求を識別するための要求ＩＤを登録するフィールド１５２と、更新を要求する交通ダイヤデータを特定するための施行日、線区、種別および列車番号をそれぞれ登録するフィールド１５３〜１５６と、交通ダイヤデータの更新内容（編集データ）を登録するフィールド１５７と、該更新内容が交通ダイヤＤＢ１３に反映済みであるか否かを示す反映状況を登録するフィールド１５８と、を有する。

排他制御部１２は、排他フラグ登録部１２１と、ＤＢ更新部１２２と、ＤＢ転送部１２３と、を有する。排他フラグ登録部１２１は、ネットワークＩＦ部１１を介して交通ダイヤ編集端末２より受け取った後述する排他フラグ登録要求に従い排他フラグ管理ＤＢ１４を更新する。ＤＢ更新部１２２は、ネットワークＩＦ部１１を介して交通ダイヤ編集端末２から受け取った後述する更新情報登録要求を更新情報管理ＴＬ１５に登録する。また、更新情報管理ＴＬ１５に登録されている更新情報登録要求に従い交通ダイヤＤＢ１３を更新する。ＤＢ転送部１２３は、更新ダイヤＤＢ１３から交通ダイヤデータを読み出し、ネットワークＩＦ部１１を介して交通ダイヤ編集端末２に送信する。

交通ダイヤ編集端末２は、ユーザからの指示に従い交通ダイヤ管理サーバ１が保持する交通ダイヤデータを編集する。図示するように、交通ダイヤ編集端末２は、ネットワーク３に接続するためのネットワークＩＦ部２１と、交通ダイヤ編集部２２と、更新情報管理ＴＬ２３と、作業用記憶部２４と、排他フラグ管理ＴＬ２５と、情報を表示してユーザより操作や指示などを受付けるためのＧＵＩ（Graphical User Interface）部２６と、を有する。

更新情報管理ＴＬ２３には、交通ダイヤ編集部２２がＧＵＩ部２６を介してユーザより受付けた交通ダイヤデータの編集内容を特定するための情報である更新情報が登録される。図５は更新情報管理ＴＬ２３の登録内容例を示す図である。図示するように、更新情報管理ＴＬ２３には、交通ダイヤ編集部２２がＧＵＩ部２６を介してユーザより交通ダイヤデータの編集を受付ける毎にレコード２３０が登録される。レコード２３０は、更新情報登録要求の要求ＩＤを登録するフィールド２３１と、編集された交通ダイヤデータを特定するための施行日、線区、種別および列車番号をそれぞれ登録するフィールド２３２〜２３５と、交通ダイヤデータの変更内容（編集データ）を登録するフィールド２３６と、フィールド２３１〜２３６の情報を含む更新情報登録要求が送信済みであるか否かを示す送信状況を登録するフィールド２３７と、を有する。

作業用記憶部２４には、交通ダイヤ編集部２２がネットワークＩＦ部２１を介して交通ダイヤ管理サーバ１から取得した交通ダイヤデータが記憶される。

排他フラグ管理ＴＬ２５には、交通ダイヤ編集端末２のユーザが獲得した排他フラグが登録される。図６は排他フラグ管理ＴＬ２５の登録内容例を示す図である。図示するように、排他フラグ管理ＴＬ２５には、交通ダイヤ編集端末２のユーザが獲得した排他フラグ毎にレコード２５０が登録される。レコード２５０は、獲得した排他フラグが適用される交通ダイヤデータの施行日を登録するフィールド２５１と、当該交通ダイヤデータの線区を登録するフィールド２５２と、当該交通ダイヤデータの種別（運行目的）を登録するフィールド２５３と、当該交通ダイヤデータの列車番号を登録するフィールド２５４と、を有する。ここで、ある施行日に運行する全ての列車の交通ダイヤデータに対する排他フラグを獲得している場合、当該排他フラグのレコード２５０のフィールド２５１に当該施行日が登録され、その他のフィールド２５２〜２５４にヌルデータが登録される。また、ある施行日にある線区を運行する全ての列車の交通ダイヤデータに対する排他フラグを獲得している場合、当該排他フラグのレコード２５０のフィールド２５１、２５２に当該施行日および当該線区が登録され、その他のフィールド２５３、２５４にヌルデータが登録される。また、ある施行日にある線区をある種別の目的で運行する全ての列車の交通ダイヤデータに対する排他フラグを獲得している場合、当該排他フラグのレコード２５０のフィールド２５１〜２５３に、当該施行日、当該線区および当該種別が登録され、その他のフィールド２５４にヌルデータが登録される。そして、ある施行日にある線区をある種別の目的で運行するある列車番号を持つ列車の交通ダイヤデータに対する排他フラグを獲得している場合、当該排他フラグのレコード２５０のフィールド２５１〜２５４に、それぞれ、当該施行日、当該線区、当該種別および当該列車番号が登録される。

交通ダイヤ編集部２２は、排他フラグ登録要求部２２１と、更新情報登録要求部２２２と、編集受付部２２３と、交通ダイヤ読込部２２４と、を有する。

排他フラグ登録要求部２２１は、ＧＵＩ部２６を介してユーザより、排他フラグを獲得する交通ダイヤデータ（編集対象の交通ダイヤデータ）を特定する情報（交通ダイヤデータを管理するいずれかの階層の管理項目の情報）を受付けて排他フラグ登録要求を作成し、ネットワークＩＦ部２１を介して交通管理サーバ１に送信する。図７は排他フラグ登録要求を模式的に表した図である。図示するように、排他フラグ登録要求２２１０は、ユーザＩＤを登録するエリア２２１１、排他フラグを獲得する交通ダイヤデータの施行日を登録するエリア２２１２、排他フラグを獲得する交通ダイヤデータの線区を登録するエリア２２１３、排他フラグを獲得する交通ダイヤデータの種別（運行目的）を登録するエリア２２１４、および、排他フラグを獲得する交通ダイヤデータの列車番号を登録するエリア２２１５を有する。排他フラグ管理ＴＬ２５のレコード２５０と同様、エリア２２１３〜２２１５は、獲得しようとしている交通ダイヤデータの階層によってヌルデータとなる場合がある。また、排他フラグ登録要求部２２１は、交通ダイヤ管理サーバ１に送信した排他フラグ登録要求２２１０のレコード２５０を排他フラグ管理ＴＬ２５に登録する。

更新情報登録要求部２２２は、定期的もしくは更新情報管理ＴＬ２３に新たなレコード２５０が追加される毎に、更新情報管理ＴＬ２３に登録されているフィールド２３７の送信状況が「未」のレコード２３０に基づいて更新情報登録要求を作成し、これをネットワークＩＦ部２１を介して交通ダイヤ管理サーバ１に送信する。図８は更新情報登録要求を模式的に表した図である。図示するように、更新情報登録要求２２２０は、ユーザＩＤを登録するエリア２２２１、更新情報登録要求の要求ＩＤを登録するエリア２２２２、更新する交通ダイヤデータの施行日を登録するエリア２２２３、更新する交通ダイヤデータの線区を登録するエリア２２２４、更新する交通ダイヤデータの種別（運行目的）を登録するエリア２２２５、更新する交通ダイヤデータの列車番号を登録するエリア２２２６、および、交通ダイヤデータの更新内容を登録するエリア２２２７を有する。

編集受付部２２３は、作業用記憶部２４に記憶されている交通ダイヤデータをＧＵＩ部２６に表示し、ユーザから交通ダイヤデータの編集を受付ける。そして、受付けた編集内容を更新情報管理ＴＬ２３に登録する。この際、排他フラグ管理ＴＬ２５を参照し、排他フラグを獲得している交通ダイヤデータ以外の交通ダイヤデータをマスクしてＧＵＩ部２６に表示することで、排他フラグを獲得している交通ダイヤデータについてのみユーザから編集を受付けるようにする。

そして、交通ダイヤ読込部２２４は、ネットワークＩＦ部２１を介して交通ダイヤ管理サーバ１から交通ダイヤデータをダウンロードし、作業用記憶部２４に記憶する。

上述した交通ダイヤ管理サーバ１および交通ダイヤ編集端末２は、例えば図９に示すような、ＣＰＵ９０１と、メモリ９０２と、ＨＤＤ等の外部記憶装置９０３と、ＣＤ-ＲＯＭやＤＶＤ-ＲＯＭやＩＣカードなどの記憶媒体からデータを読み取る読取装置９０４と、キーボードやマウスなどの入力装置９０６と、モニタやプリンタなどの出力装置９０７と、ネットワーク３に接続するための通信装置９０８と、これらの各装置を接続するバス９０９と、を備えた一般的なコンピュータシステムにおいて、ＣＰＵ９０１がメモリ９０２上にロードされたプログラムを実行することで実現できる。このプログラムは、読取装置９０４を介して記憶媒体から、あるいは、通信装置９０８を介してネットワーク３から、外部記憶装置９０３にダウンロードされ、それから、メモリ９０２上にロードされてＣＰＵ９０１により実行されるようにしてもよい。あるいは、外部記憶装置９０３を経由せずに、メモリ９０２上に直接ロードされ、ＣＰＵ９０１により実行されるようにしてもよい。なお、この場合において、各記憶部１３〜１５、２３〜２５にはメモリ９０２や外部記憶装置９０３や読取装置９０４に搭載された記憶媒体が利用される。また、ネットワークＩＦ部１１、２１には通信装置９０８が利用される。

次に、上記構成の交通ダイヤデータ編集管理システムの動作を説明する。

先ず、交通ダイヤ管理サーバ１の操作を説明する。図１０は交通ダイヤ管理サーバ１の動作フローを説明するための図である。

排他制御部１２は、ネットワークＩＦ部１１を介して交通ダイヤ編集端末２からアクセスされると（Ｓ１１でＹＥＳ）、当該交通ダイヤ編集端末２から要求を受信してその内容を解析する（Ｓ１２）。解析の結果、当該要求が所定の管理項目の指定値を含むダイヤデータＤＬ（ダウンロード）要求であるならば、ＤＢ転送部１２３が処理を行う。すわなち、ＤＢ転送部１２３は、交通ダイヤデータＤＬ要求に含まれている管理項目の指定値が当該管理項目のフィールド１３１〜１３４に登録されているレコード１３０を、交通ダイヤＤＢ１３から全て読み出す（Ｓ１３）。本実施形態では、所定の管理項目として施行日を用いている。しかし、所定の管理項目は、施行日および線区の組合せでもよいし、あるいは、施行日、線区および種別の組合せでもよい。次に、ＤＢ転送部１２３は、読み出した交通ダイヤデータのレコード１３０を、ネットワークＩＦ部１１を介してダイヤデータＤＬ要求の送信元に送信する（Ｓ１４）。

また、Ｓ１２での解析の結果、当該要求が排他フラグ登録要求であるならば、排他フラグ登録部１２１が後述する排他フラグ登録処理を行い（Ｓ１５）、当該要求が更新情報登録要求であるならば、ＤＢ更新部１２２が後述する更新情報登録処理を行う（Ｓ１６）。

図１１および図１２は排他フラグ登録処理（図１０のＳ１５）を説明するためのフロー図である。

まず、排他フラグ登録部１２１は、ネットワークＩＦ部１１を介して交通ダイヤ編集端末２から受信した排他フラグ登録要求２２１０（図７参照）のエリア２２１２に登録されている施行日を特定し、当該施行日がフィールド１４１１に登録されているレコード１４１０を階層「大分類」に対応する排他フラグ管理ＴＬ１４１（図４（Ａ）参照）から検索する（Ｓ１５０１）。

Ｓ１５０１において排他フラグ管理ＴＬ１４１から該当するレコードを検索できた場合（Ｓ１５０２でＹＥＳ）、特定した施行日に運行する全ての列車の交通ダイヤデータを対象とする排他フラグが既に設定されていることになる。この場合、排他フラグ登録部１２１は、排他フラグ登録要求２２１０の拒否メッセージをネットワークＩＦ部１１を介して、当該要求の送信元である交通ダイヤ編集端末２に送信するなどの所定のエラー処理を行う（Ｓ１５４１）。

一方、Ｓ１５０１において排他フラグ管理ＴＬ４１から該当するレコードを検索できなかった場合（Ｓ１５０２でＮＯ）は、特定した施行日に運行する全ての列車の交通ダイヤデータを対象とする排他フラグは未だ設定されていないことになる。この場合、排他フラグ登録要求２２１０の線区を登録するエリア２２１３がヌルか否かを調べる（Ｓ１５０３）。そして、ヌルでない場合（Ｓ１５０３でＮＯ）、排他フラグは階層「中分類」以下のいずれかの階層に対応する排他フラグ管理ＴＬ１４２〜１４４（図４（Ｂ）〜（Ｃ）参照）で管理されるべきである。この場合はＳ１５１１に進む。一方、ヌルの場合（Ｓ１５０３でＹＥＳ）、排他フラグは階層「大分類」に対応する排他フラグ管理ＴＬ１４１で管理されるべきである。そこで、階層「大分類」に対応する排他フラグ管理ＴＬ１４１にレコード１４１０を新たに追加し、該レコード１４１０のフィールド１４１１、１４１５に、排他フラグ登録要求２２１０のエリア２２１２、２２１１に登録されている施行日、ユーザＩＤを登録する（Ｓ１５０６）。その後、処理を終了する。

また、Ｓ１５１１において、排他フラグ登録部１２１は、排他フラグ登録要求２２１０のエリア２２１２、２２１３に登録されている施行日、線区を特定し、当該施行日、線区がフィールド１４２１、１４２２に登録されているレコード１４２０を階層「中分類」に対応する排他フラグ管理テーブル１４２から検索する。

Ｓ１５１１において排他フラグ管理テーブル１４２から該当するレコードを検索できた場合（Ｓ１５１２でＹＥＳ）、特定した施行日に特定した線区を運行する全ての列車の交通ダイヤデータを対象とする排他フラグが既に設定されていることになる。この場合、排他フラグ登録部１２１は、排他フラグ登録要求２２１０の拒否メッセージをネットワークＩＦ部１１を介して、当該要求の送信元である交通ダイヤ編集端末２に送信するなどの所定のエラー処理を行う（Ｓ１５４１）。

一方、Ｓ１５１１において排他フラグ管理ＴＬ１４２から該当するレコードを検索できなかった場合（Ｓ１５１２でＮＯ）は、特定した施行日に特定した線区を運行する全ての列車の交通ダイヤデータを対象とする排他フラグは未だ設定されていないことになる。この場合、排他フラグ登録要求２２１０の種別を登録するエリア２２１４がヌルか否かを調べる（Ｓ１５１３）。そして、ヌルでない場合（Ｓ１５１３でＮＯ）、排他フラグは階層「小分類」以下のいずれかの階層に対応する排他フラグ管理ＴＬ１４３、１４４で管理されるべきである。この場合はＳ１５２１に進む。一方、ヌルの場合（Ｓ１５１３でＹＥＳ）、排他フラグは階層「中分類」に対応する排他フラグ管理ＴＬ１４２で管理されるべきである。そこで、階層「中分類」に対応する排他フラグ管理ＴＬ１４２にレコード１４２０を新たに追加し、該レコード１４２０のフィールド１４２１、１４２２、１４２５に、排他フラグ登録要求２２１０のエリア２２１２、２２１３、２２１１に登録されている施行日、線区、ユーザＩＤを登録する（Ｓ１５１６）。その後、処理を終了する。

また、Ｓ１５２１において、排他フラグ登録部１２１は、排他フラグ登録要求２２１０のエリア２２１２、２２１３、２２１４に登録されている施行日、線区、種別を特定し、当該施行日、線区、種別がフィールド１４３１、１４３２、１４３３に登録されているレコード１４３０を、階層「小分類」に対応する排他フラグ管理ＴＬ１４３から検索する。

Ｓ１５２１において排他フラグ管理ＴＬ１４３から該当するレコードを検索できた場合（Ｓ１５２２でＹＥＳ）、特定した施行日に特定した線区を特定した種別のために運行する全ての列車の交通ダイヤデータを対象とする排他フラグが既に設定されていることになる。この場合、排他フラグ登録部１２１は、排他フラグ登録要求２２１０の拒否メッセージをネットワークＩＦ部１１を介して、当該要求の送信元である交通ダイヤ編集端末２に送信するなどの所定のエラー処理を行う（Ｓ１５４１）。

一方、Ｓ１５２１において排他フラグ管理ＴＬ１４３から該当するレコードを検索できなかった場合（Ｓ１５２２でＮＯ）は、特定した施行日に特定した線区を特定した種別のために運行する全ての列車の交通ダイヤデータを対象とする排他フラグは未だ設定されていないことになる。この場合、排他フラグ登録要求２２１０の列車番号を登録するエリア２２１５がヌルか否かを調べる（Ｓ１５２３）。そして、ヌルでない場合（Ｓ１５２３でＮＯ）、排他フラグは階層「交通ダイヤデータ毎」に対応する排他フラグ管理ＴＬ１４４で管理されるべきである。この場合はＳ１５３１に進む。一方、ヌルの場合（Ｓ１５２３でＹＥＳ）、排他フラグは階層「小分類」に対応する排他フラグ管理ＴＬ１４３で管理されるべきである。そこで、階層「小分類」に対応する排他フラグ管理ＴＬ１４３にレコード１４３０を新たに追加し、該レコード１４３０のフィールド１４３１、１４３２、１４３３、１４３５に、排他フラグ登録要求２２１０のエリア２２１２、２２１３、２２１４、２２１１に登録されている施行日、線区、種別、ユーザＩＤを登録する（Ｓ１５２６）。その後、処理を終了する。

また、Ｓ１５３１において、排他フラグ登録部１２１は、排他フラグ登録要求２２１０のエリア２２１２、２２１３、２２１４、２２１５に登録されている施行日、線区、種別、列車番号を特定し、当該施行日、線区、種別、列車番号がフィールド１４４１、１４４２、１４４３、１４４４に登録されているレコード１４４０を、階層「交通ダイヤデータ毎」に対応する排他フラグ管理ＴＬ１４４から検索する。

Ｓ１５３１において排他フラグ管理ＴＬ１４４から該当するレコードを検索できた場合（Ｓ１５３２でＹＥＳ）、特定した施行日に特定した線区を特定した種別のために運行する、特定した列車番号を持つ列車の交通ダイヤデータを対象とする排他フラグが既に設定されていることになる。この場合、排他フラグ登録部１２１は、排他フラグ登録要求２２１０の拒否メッセージをネットワークＩＦ部１１を介して、当該要求の送信元である交通ダイヤ編集端末２に送信するなどの所定のエラー処理を行う（Ｓ１５４１）。

一方、Ｓ１５３１において排他フラグ管理ＴＬ１４４から該当するレコードを検索できなかった場合（Ｓ１５３２でＮＯ）は、特定した施行日に特定した線区を特定した種別のために運行する、特定した列車番号を持つ列車の交通ダイヤデータを対象とする排他フラグは未だ設定されていないことになる。この場合、排他フラグ管理ＴＬ１４４にレコード１４４０を新たに追加し、該レコード１４４０のフィールド１４４１、１４４２、１４４３、１４４４、１４４５に、排他フラグ登録要求２２１０のエリア２２１２、２２１３、２２１４、２２１５、２２１１に登録されている施行日、線区、種別、列車番号、ユーザＩＤを登録する（Ｓ１５３３）。その後、処理を終了する。

図１３および図１４は更新内容反映処理（図１０のＳ１６）を説明するためのフロー図である。

まず、ＤＢ更新部１２２は、ネットワークＩＦ部１１を介して交通ダイヤ編集端末２から受信した更新情報登録要求２２２０（図８参照）のエリア２２２３〜２２２６に登録されている施行日、線区、種別、列車番号を特定し、当該施行日、線区、種別、列車番号がフィールド１４４１〜１４４４に登録されているレコード１４４０を階層「交通データ毎」に対応する排他フラグ管理テーブル１４４から検索する（Ｓ１６０１）。

Ｓ１６０１において排他フラグ管理テーブル１４４から該当するレコード１４４０を検索できた場合（Ｓ１６０２でＹＥＳ）、特定した施行日に特定した線区を特定した種別のために運行する、特定した列車番号を持つ列車の交通ダイヤデータを対象とする排他フラグが既に設定されていることになる。この場合、ＤＢ更新部１２２は、検索したレコード１４４０のフィールド１４４５に登録されているユーザＩＤと、更新情報登録要求２２２０のエリア２２２１に登録されているユーザＩＤとが一致するか否かを調べる（Ｓ１６０３）。

Ｓ１６０１で検索したレコード１４４０のフィールド１４４５に登録されているユーザＩＤと、更新情報登録要求２２２０のエリア２２２１に登録されているユーザＩＤとが一致する場合（Ｓ１６０３でＹＥＳ）、更新情報登録要求２２２０を送信した交通ダイヤ編集端末２のユーザは、当該要求で更新を要求する交通ダイヤデータに対する排他フラグを獲得している。この場合、ＤＢ更新部１２２は、更新情報管理ＴＬ１５にレコード１５０を新たに追加し、更新情報登録要求２２２０のエリア２２２１〜２２２７に登録されている内容をこのレコード１５０のフィールド１５１〜１５７に登録する。また、このレコード１５０のフィールド１５８に反映状況「未」を登録する（Ｓ１６０４）。それから、ＤＢ更新部１２２は、反映状況「未」のフィールド１５８を持つレコード１５０を更新情報管理ＴＬ１５から抽出する。次に、抽出したレコード１５０のフィールド１５３〜１５６に登録されている施行日、線区、種別、列車番号が、フィールド１３２〜１３４、１３１に登録されているレコード１３０を交通ダイヤＤＢ１３から検索する。そして、検索したレコード１３０のフィールド１３５に登録されている交通ダイヤデータを、抽出したレコード１５０のフィールド１５７に登録されている変更内容に従って更新する。また、抽出したレコード１５０のフィールド１５８に登録されている反映状況を「未」から「済」に変更する（Ｓ１６０５）。

一方、Ｓ１６０１で検索したレコード１４４０のフィールド１４４５に登録されているユーザＩＤと、更新情報登録要求２２２０のエリア２２２１に登録されているユーザＩＤとが一致しない場合（Ｓ１６０３でＮＯ）、更新情報登録要求２２２０を送信した交通ダイヤ編集端末２のユーザは、当該要求で更新を要求する交通ダイヤデータに対する排他フラグを獲得していない。該排他フラグは別のユーザが獲得している。この場合、ＤＢ更新部１２２は、更新情報登録要求２２２０の拒否メッセージをネットワークＩＦ部１１を介して、当該要求の送信元である交通ダイヤ編集端末２に送信するなどの所定のエラー処理を行う（Ｓ１６４１）。

また、Ｓ１６０１において排他フラグ管理ＴＬ１４４から該当するレコード１４４０を検索できなかった場合（Ｓ１６０２でＮＯ）、特定した施行日に特定した線区を特定した種別のために運行する、特定した列車番号を持つ列車の交通ダイヤデータを対象とする排他フラグは設定されていないことになる。この場合、ＤＢ更新部１２２は、更新情報登録要求２２２０のエリア２２２３〜２２２５に登録されている施行日、線区、種別を特定し、当該施行日、線区、種別がフィールド１４３１〜１４３３に登録されているレコード１４３０を階層「小分類」に対応する排他フラグ管理ＴＬ１４３から検索する（Ｓ１６１１）。

Ｓ１６１１において排他フラグ管理ＴＬ１４３から該当するレコード１４３０を検索できた場合（Ｓ１６１２でＹＥＳ）、特定した施行日に特定した線区を特定した種別のために運行する全ての列車の交通ダイヤデータを対象とする排他フラグが既に設定されていることになる。この場合、ＤＢ更新部１２２は、検索したレコード１４３０のフィールド１４３５に登録されているユーザＩＤと、更新情報登録要求２２２０のエリア２２２１に登録されているユーザＩＤとが一致するか否かを調べる（Ｓ１６１３）。

Ｓ１６１１で検索したレコード１４３０のフィールド１４３５に登録されているユーザＩＤと、更新情報登録要求２２２０のエリア２２２１に登録されているユーザＩＤとが一致する場合（Ｓ１６１３でＹＥＳ）、更新情報登録要求２２２０を送信した交通ダイヤ編集端末２のユーザは、当該要求で更新を要求する交通ダイヤデータに対する排他フラグを獲得している。この場合、ＤＢ更新部１２２は、更新情報管理ＴＬ１５にレコード１５０を新たに追加し、更新情報登録要求２２２０のエリア２２２１〜２２２７に登録されている内容をこのレコード１５０のフィールド１５１〜１５７に登録する。また、このレコード１５０のフィールド１５８に反映状況「未」を登録する（Ｓ１６１４）。それから、ＤＢ更新部１２２は、反映状況「未」のフィールド１５８を持つレコード１５０を更新情報管理ＴＬ１５から抽出する。次に、抽出したレコード１５０のフィールド１５３〜１５６に登録されている施行日、線区、種別、列車番号が、フィールド１３２〜１３４、１３１に登録されているレコード１３０を交通ダイヤＤＢ１３から検索する。そして、検索したレコード１３０のフィールド１３５に登録されている交通ダイヤデータを、抽出したレコード１５０のフィールド１５７に登録されている変更内容に従って更新する。また、抽出したレコード１５０のフィールド１５８に登録されている反映状況を「未」から「済」に変更する（Ｓ１６０５）。

一方、Ｓ１６１１で検索したレコード１４３０のフィールド１４３５に登録されているユーザＩＤと、更新情報登録要求２２２０のエリア２２２１に登録されているユーザＩＤとが一致しない場合（Ｓ１６１３でＮＯ）、更新情報登録要求２２２０を送信した交通ダイヤ編集端末２のユーザは、当該要求で更新を要求する交通ダイヤデータに対する排他フラグを獲得していない。該排他フラグは別のユーザが獲得している。この場合、ＤＢ更新部１２２は、更新情報登録要求２２２０の拒否メッセージをネットワークＩＦ部１１を介して、当該要求の送信元である交通ダイヤ編集端末２に送信するなどの所定のエラー処理を行う（Ｓ１６４１）。

また、Ｓ１６１１において排他フラグ管理テーブル１４３から該当するレコード１４３０を検索できなかった場合（Ｓ１６１２でＮＯ）、特定した施行日に特定した線区で特定した種別のために運行される全ての列車の交通ダイヤデータを対象とする排他フラグは設定されていないことになる。この場合、ＤＢ更新部１２２は、更新情報登録要求２２２０のエリア２２２３、２２２４に登録されている施行日、線区を特定し、当該施行日、線区がフィールド１４２１、１４２２に登録されているレコード１４２０を階層「中分類」に対応する排他フラグ管理ＴＬ１４２から検索する（Ｓ１６２１）。

Ｓ１６２１において排他フラグ管理ＴＬ１４２から該当するレコード１４２０を検索できた場合（Ｓ１６２２でＹＥＳ）、特定した施行日に特定した線区で運行される全ての列車の交通ダイヤデータを対象とする排他フラグが既に設定されていることになる。この場合、ＤＢ更新部１２２は、検索したレコード１４２０のフィールド１４２５に登録されているユーザＩＤと、更新情報登録要求２２２０のエリア２２２１に登録されているユーザＩＤとが一致するか否かを調べる（Ｓ１６２３）。

Ｓ１６２１で検索したレコード１４２０のフィールド１４２５に登録されているユーザＩＤと、更新情報登録要求２２２０のエリア２２２１に登録されているユーザＩＤとが一致する場合（Ｓ１６２３でＹＥＳ）、更新情報登録要求２２２０を送信した交通ダイヤ編集端末２のユーザは、当該要求で更新を要求する交通ダイヤデータに対する排他フラグを獲得している。この場合、ＤＢ更新部１２２は、更新情報管理ＴＬ１５にレコード１５０を新たに追加し、更新情報登録要求２２２０のエリア２２２１〜２２２７に登録されている内容をこのレコード１５０のフィールド１５１〜１５７に登録する。また、このレコード１５０のフィールド１５８に反映状況「未」を登録する（Ｓ１６２４）。それから、ＤＢ更新部１２２は、反映状況「未」のフィールド１５８を持つレコード１５０を更新情報管理ＴＬ１５から抽出する。次に、抽出したレコード１５０のフィールド１５３〜１５６に登録されている施行日、線区、種別、列車番号が、フィールド１３２〜１３４、１３１に登録されているレコード１３０を交通ダイヤＤＢ１３から検索する。そして、検索したレコード１３０のフィールド１３５に登録されている交通ダイヤデータを、抽出したレコード１５０のフィールド１５７に登録されている変更内容に従って更新する。また、抽出したレコード１５０のフィールド１５８に登録されている反映状況を「未」から「済」に変更する（Ｓ１６２５）。

一方、Ｓ１６２１で検索したレコード１４２０のフィールド１４２５に登録されているユーザＩＤと、更新情報登録要求２２２０のエリア２２２１に登録されているユーザＩＤとが一致しない場合（Ｓ１６２３でＮＯ）、更新情報登録要求２２２０を送信した交通ダイヤ編集端末２のユーザは、当該要求で更新を要求する交通ダイヤデータに対する排他フラグを獲得していない。該排他フラグは別のユーザが獲得している。この場合、ＤＢ更新部１２２は、更新情報登録要求２２２０の拒否メッセージをネットワークＩＦ部１１を介して、当該要求の送信元である交通ダイヤ編集端末２に送信するなどの所定のエラー処理を行う（Ｓ１６４１）。

また、Ｓ１６２１において排他フラグ管理ＴＬ１４２から該当するレコード１４２０を検索できなかった場合（Ｓ１６２２でＮＯ）、特定した施行日に特定した線区を運行する全ての列車の交通ダイヤデータを対象とする排他フラグは設定されていないことになる。この場合、ＤＢ更新部１２２は、更新情報登録要求２２２０のエリア２２２３に登録されている施行日を特定し、当該施行日がフィールド１４１１に登録されているレコード１４１０を、階層「大分類」に対応する排他フラグ管理ＴＬ１４１から検索する（Ｓ１６３１）。

Ｓ１６３１において排他フラグ管理ＴＬ１４１から該当するレコード１４１０を検索できた場合（Ｓ１６３２でＹＥＳ）、特定した施行日に運行する全ての列車の交通ダイヤデータを対象とする排他フラグが既に設定されていることになる。この場合、ＤＢ更新部１２２は、検索したレコード１４１０のフィールド１４１５に登録されているユーザＩＤと、更新情報登録要求２２２０のエリア２２２１に登録されているユーザＩＤとが一致するか否かを調べる（Ｓ１６３３）。

Ｓ１６３１で検索したレコード１４１０のフィールド１４１５に登録されているユーザＩＤと、更新情報登録要求２２２０のエリア２２２１に登録されているユーザＩＤとが一致する場合（Ｓ１６３３でＹＥＳ）、更新情報登録要求２２２０を送信した交通ダイヤ編集端末２のユーザは、当該要求で更新を要求する交通ダイヤデータに対する排他フラグを獲得している。この場合、ＤＢ更新部１２２は、更新情報管理ＴＬ１５にレコード１５０を新たに追加し、更新情報登録要求２２２０のエリア２２２１〜２２２７に登録されている内容をこのレコード１５０のフィールド１５１〜１５７に登録する。また、このレコード１５０のフィールド１５８に反映状況「未」を登録する（Ｓ１６３４）。それから、ＤＢ更新部１２２は、反映状況「未」のフィールド１５８を持つレコード１５０を更新情報管理ＴＬ１５から抽出する。次に、抽出したレコード１５０のフィールド１５３〜１５６に登録されている施行日、線区、種別、列車番号が、フィールド１３２〜１３４、１３１に登録されているレコード１３０を交通ダイヤＤＢ１３から検索する。そして、検索したレコード１３０のフィールド１３５に登録されている交通ダイヤデータを、抽出したレコード１５０のフィールド１５７に登録されている変更内容に従って更新する。また、抽出したレコード１５０のフィールド１５８に登録されている反映状況を「未」から「済」に変更する（Ｓ１６２５）。

一方、Ｓ１６３１で検索したレコード１４１０のフィールド１４１５に登録されているユーザＩＤと、更新情報登録要求２２２０のエリア２２２１に登録されているユーザＩＤとが一致しない場合（Ｓ１６３３でＮＯ）、更新情報登録要求２２２０を送信した交通ダイヤ編集端末２のユーザは、当該要求で更新を要求する交通ダイヤデータに対する排他フラグを獲得していない。該排他フラグは別のユーザが獲得している。この場合、ＤＢ更新部１２２は、更新情報登録要求２２２０の拒否メッセージをネットワークＩＦ部１１を介して、当該要求の送信元である交通ダイヤ編集端末２に送信するなどの所定のエラー処理を行う（Ｓ１６４１）。

次に、交通ダイヤ編集端末２の操作を説明する。図１５は交通ダイヤ編集端末２の動作フローを説明するための図である。

まず、排他フラグ登録要求部２２１は、ＧＵＩ部２６を介してユーザより排他フラグの登録指示を受付けると（Ｓ２０１でＹＥＳ）、図１６に示すような管理項目受付画面をＧＵＩ部２６に表示し、排他フラグを獲得する交通ダイヤデータを特定するための管理項目およびその情報の入力を受付ける。図１６において、符号２６０１は、獲得しようとしている排他フラグが適用される交通ダイヤデータの階層を選択するための選択欄であり、ユーザはプルダウンメニューに示された階層（図３に示す階層「大分類」、「中分類」、「小分類」および「交通ダイヤデータ毎」）の中から所望の階層を選択できる。符号２６０２〜２６０５は、選択欄２６０１で選択された階層で交通ダイヤデータに対する排他フラグを設定するための管理項目の情報を入力、選択するための入力・選択欄である。符号２６０２は管理項目「施行日」の入力欄、符号２６０３はプルダウンメニューの中から所望の管理項目「線区」を選択するための選択欄、符号２６０４はプルダウンメニューの中から所望の管理項目「種別」を選択するための選択欄、そして、符号２６０５は管理項目「列車番号」の入力欄である。選択欄２６０１で階層「大分類」が選択されている場合、入力・選択欄２６０３〜２６０５が例えばグレー表示され、情報を入力、選択できない。入力欄２６０２にのみ施行日を入力することができる。選択欄２６０１で階層「中分類」が選択されている場合、入力・選択欄２６０４、２６０５が例えばグレー表示され、情報を入力、選択できない。入力欄２６０２、選択欄２６０３に施行日、線区を入力、選択することができる。選択欄２６０１で階層「小分類」が選択されている場合、入力・選択欄２６０５が例えばグレー表示され、情報を入力、選択できない。入力欄２６０２〜２６０４に施行日、線区、種別を入力、選択することができる。そして、選択欄２６０１で階層「交通ダイヤデータ毎」が選択されている場合に、全ての入力・選択欄２６０２〜２６０５に情報を入力、選択できる。なお、選択欄２６０１、２６０３、２６０４にプルダウンメニュー表示する情報はメモリ等に予め記憶されているものとする。まや、符号２６０６は、入力・選択欄２６０１〜２６０５に入力、選択された情報を確定する確定ボタン、そして、符号２６０７は、入力・選択欄２６０１〜２６０５に入力、選択された情報をキャンセルする取消しボタンである。

さて、排他フラグ登録要求部２２１は、ＧＵＩ部２６を介してユーザより管理項目およびその情報の入力を受付けると、排他フラグ管理ＴＬ２５にレコード２５０を新たに追加し、このレコード２５０に、受付けた管理項目の情報を登録する。また、受付けた管理項目の情報と、予め登録されているユーザＩＤとを含む排他フラグ登録要求２２１０を生成し、これをネットワークＩＦ部２１を介して交通ダイヤ管理サーバ１に送信する（Ｓ２０３）。なお、排他フラグ登録要求拒否メッセージ等のエラー通知を所定期間内に交通ダイヤ管理サーバ１から受領したならば（Ｓ２０４でＹＥＳ）、Ｓ２０３で排他フラグ管理ＴＬ２５に追加したレコード２５０を削除する（Ｓ２０５）。

また、交通ダイヤ読込部２２４は、ＧＵＩ部２６を介してユーザより交通ダイヤデータのＤＬ指示を受付けると（Ｓ２３０でＹＥＳ）、ＤＬ範囲指定受付画面をＧＵＩ部２６に表示し、ダウンロードする交通ダイヤデータの範囲の指定を受付ける（Ｓ２３１）。本実施形態では、施行日の指定を受付けるようにしている。

さて、交通ダイヤ読込部２２４は、ＧＵＩ部２６を介してユーザよりＤＬ範囲の指定を受付けると、指定されたＤＬ範囲と、予め登録されているユーザＩＤとを含む交通ダイヤデータＤＬ要求を生成し、これをネットワークＩＦ部２１を介して交通ダイヤ管理サーバ１に送信する（Ｓ２２２）。そして、交通ダイヤ管理サーバ１から交通ダイヤデータを受信し、作業用記憶部２４に記憶する（Ｓ２２３）。これを受けて、編集受付部２２３は、作業用記憶部２４に記憶された交通ダイヤデータをグラフ表示する（Ｓ２２４）。

図１７は交通ダイヤデータの表示画面の一例である。この例では、縦軸２６１１を線区を構成する各駅とし、横軸２６１２を時刻として、指定された施行日（2004/11/16、2004/11/27）に運行される全ての交通ダイヤデータがグラフ表示されている。グラフに付されたアルファベット（符号２６１５）は列車番号である。グラフの線種は、種別を表している。ここでは実線が種別「営業」を、そして、一点鎖線が種別「貨物」を表している。ユーザは、ＧＵＩ部２６を介して、交通ダイヤデータ表示画面上にグラフ表示されている交通ダイヤデータの一部２６をカーソル（不図示）で選択し、ドラッグ等の操作を行うことにより、該操作内容を編集受付部２２３が受付けて、後述する交通ダイヤデータの編集を行う。符号２６１３が該操作内容の確定ボタン、符号２６１４はその取消ボタンである。なお、ＧＵＩ部２６を用いた交通ダイヤデータの編集受付には、既存のグラフィックソフトの技術を利用することができる。

また、交通ダイヤ読込部２２４は、例えば所定時間経過といった、作業用記憶部２４に記憶されている交通ダイヤデータの更新タイミングになった場合（Ｓ２２０、Ｓ２２１で共にＹＥＳ）、作業用記憶部２４に記憶されている交通ダイヤデータのＤＬ範囲（施行日）と、予め登録されているユーザＩＤとを含む交通ダイヤデータＤＬ要求を生成し、これをネットワークＩＦ部２１を介して交通ダイヤ管理サーバ１に送信する（Ｓ２２２）。そして、交通ダイヤ管理サーバ１から交通ダイヤデータを受信し、作業用記憶部２４の記憶内容を更新する（Ｓ２２３）。これを受けて、編集受付部２２３は、作業用記憶部２４内の更新された交通ダイヤデータをグラフ表示する（Ｓ２２４）。

また、編集受付部２４は、ＧＵＩ部２６に表示されている交通ダイヤデータ表示画面（図１７参照）を介して、交通ダイヤデータの編集操作を受付けると（Ｓ２１１でＹＥＳ）、編集操作を受付けた対象の交通ダイヤデータを対象とする排他フラグのレコード２５０が排他フラグ管理ＴＬ２５に登録されているか否かを調べる（Ｓ２１２）。具体的には、編集操作を受付けた対象の交通ダイヤデータと同じ施行日がフィールド２５１に登録されており、且つ、線区、種別および列車番号のフィールド２５２、２５３、２５４がヌルのレコード２５０、該交通ダイヤデータと同じ施行日、線区がフィールド２５１、２５２に登録されており、且つ、種別および列車番号のフィールド２５３、２５４がヌルのレコード２５０、編集操作を受付けた対象の交通ダイヤデータと同じ施行日、線区、種別がフィールド２５１、２５２、２５３に登録されており、且つ、列車番号のフィールド２５２、２５３、２５４がヌルのレコード２５０、および、編集操作を受付けた対象の交通ダイヤデータと同じ施行日、線区、種別、列車番号がフィールド２５１〜２５４に登録されているレコード２５０の、いずれかのレコードが登録されている否を調べる。

いずれのレコードも登録されていない場合（Ｓ２１２でＮＯ）、編集受付部２４は、該編集操作を交通ダイヤデータ表示画面に反映させない。つまり、作業用記憶部２４に記憶されている該編集操作を受付けた交通ダイヤデータに、当該編集操作による変更内容を反映させない。また、編集受付部２４は、編集操作を受付けた交通ダイヤデータを示すグラフの色を変えるなどして、編集操作が拒否されたことをユーザに知らせる（Ｓ２１８）。

一方、編集操作を受付けた対象の交通ダイヤデータを対象とする排他フラグのレコード２５０が排他フラグ管理ＴＬ２５に登録されている場合（Ｓ２１２でＹＥＳ）、編集受付部２４は、例えば該編集操作による変更内容を仮受付し、例えば図１８に示すように、作業用記憶部２４に記憶されている交通ダイヤデータを表すグラフに、仮受付した変更内容を色や線種を変えて重ね合わせて表示するなどして、ユーザが該編集内容を識別できるように交通ダイヤデータ表示画面を変更する（Ｓ２１３）。なお、図１８では、符号２６２１が付された交通ダイヤデータ、つまり、施行日「2004/11/26」、線区「α区」、種別「営業」、列車番号「Ｃ」により特定される交通ダイヤデータが編集操作された交通ダイヤデータであり、符号２６２２に示すように、該編集操作による変更内容が元の交通ダイヤデータ２６２１と表示形態（例えば色、線種）を変えて共に表示されている。このようにすることで、ユーザは自身が行った編集操作を確認できる。

さて、編集受付部２２３は、該編集操作による変更内容（時刻が変更された各駅の駅名および当該駅での変更後の時刻）と、該編集操作により編集された交通ダイヤデータの施行日、線区、種別および列車番号とを更新情報要求部２２２に通知する。これを受けて、更新情報要求部２２２は、更新情報管理ＴＬ２３に新たなレコード２３０を追加する。そして、このレコードのフィールド２３２〜２３６に、編集受付部２２３から追加した施行日、線区、種別、列車番号および変更内容を登録する。また、フィールド２３１にはユニークな要求ＩＤを生成して登録する。さらに、更新情報要求部２２２は、フィールド２３７に送信状況「未」を登録する。それから、更新情報要求部２２２は、予め登録されているユーザＩＤと、このレコード２３０のフィールド２３１〜２３６の登録内容とを含む更新情報登録要求２２２０を生成し、ネットワークＩＦ部２１を介して交通ダイヤ管理サーバ１に送信する（Ｓ２１４）。

次に、更新情報要求部２２２は、更新情報登録拒否メッセージ等のエラー通知を所定期間内に交通ダイヤ管理サーバ１から受領しなかった場合、あるいは、更新情報登録許可メッセージ等の正常応答を所定期間内に交通ダイヤ管理サーバ１から受領した場合（Ｓ２１５でＮＯ）、作業用記憶部２４の更新指示を編集受付部２２３に通知する。これを受けて、編集受付部２４は、仮受付した編集操作による変更内容を、作業用記憶部２４に記憶されている交通データに反映させて更新すると共に、作業用記憶部２４内の更新された交通ダイヤデータをグラフ表示する（Ｓ２１６）。それから、編集受付部２４は、ユーザが更新された部分を識別できるようにするために、図１９に示すように、編集操作により変更された交通ダイヤデータ２６２２を、例えば所定時間の間、色や線種を変えて表示する。

一方、更新情報要求部２２２は、更新情報登録拒否メッセージ等のエラー通知を所定期間内に交通ダイヤ管理サーバ１から受領した場合（Ｓ２１５でＹＥＳ）、その旨を編集受付部２２３に通知する。この場合、編集受付部２２３は、仮受付した編集操作による変更内容を作業用記憶部２４に記憶されている交通データに反映させるない。また、該編集操作による変更内容の交通ダイヤデータ表示画面へ表示を中止する。また、編集受付部２４は、ユーザが編集拒否された部分を識別できるようするために、図２０に示すように、編集操作が拒否された交通ダイヤデータ２６２１を、例えば所定時間の間、色や線種を変えて表示する。

次に、本実施形態の交通ダイヤデータ編集管理システム全体の動作例を説明する。

図２１は交通ダイヤ管理サーバ１および交通ダイヤ編集端末２間の情報のやり取りを説明するための図である。

交通ダイヤ編集端末２は、ＧＵＩ部２６を介してユーザより排他フラグの登録指示を受付けると、図１５のＳ２０２、Ｓ２０３を実行する。これにより、排他フラグ登録部１２１は、ユーザから排他フラグを獲得する交通ダイヤデータを特定するための管理項目およびその情報を受付け（Ｓ４０１）、受付けた情報を基に排他フラグ登録要求２２１０を生成し、これをネットワークＩＦ部２１を介して交通ダイヤ管理サーバ１に送信する（Ｓ４０２）。

交通ダイヤ管理サーバ１において、排他フラグ登録部１２１は、ネットワークＩＦ部１１を介して交通ダイヤ編集端末２より排他フラグ登録要求２２１０を受信すると、図１０のＳ１５（図１１および図１２に示すフロー）を実行する。これにより、排他フラグ登録要求２２１０が排他の獲得を要求する交通ダイヤデータについて、他のユーザによって既に排他を獲得されていない場合は、排他フラグ登録要求２２１０を排他フラグ管理ＤＢ１４に登録する（Ｓ４１１）。

また、交通ダイヤ編集端末２は、ＧＵＩ部２６を介してユーザより交通ダイヤデータのＤＬ指示を受付けると、図１５のＳ２３１、Ｓ２２２を実行する。これにより、交通ダイヤ読込部２２４は、ユーザから交通ダイヤデータのＤＬ範囲（施行日）を受付け（Ｓ４０３）、受付けた情報を基に交通ダイヤデータＤＬ要求を生成し、これをネットワークＩＦ部２１を介して交通ダイヤ管理サーバ１に送信する（Ｓ４０４）。

交通ダイヤ管理サーバ１において、ＤＢ転送部１２３は、ネットワークＩＦ部１１を介して交通ダイヤ編集端末２より交通ダイヤデータＤＬ要求を受信すると、図１０のＳ１３Ｓ１４を実行する。これにより、交通ダイヤデータＤＬ要求にて指定されているＤＬ範囲の交通ダイヤデータを交通ダイヤＤＢ１３から読み出して、ネットワークＩＦ部１１を介して交通ダイヤ編集端末２に送信する（Ｓ４１２）。

交通ダイヤ編集端末２は、ネットワークＩＦ部２１を介して交通ダイヤ管理サーバ１より交通ダイヤデータを受信すると、図１５のＳ２２３、Ｓ２２４を実行する。これにより、交通ダイヤ読込部２２４は、受信した交通ダイヤデータを作業用記憶部２４に記憶する。また、編集受付部２２３が、作業用記憶部２４に記憶された交通ダイヤデータをＧＵＩ部２６にグラフ表示する（Ｓ４０５）。

また、交通ダイヤ編集端末２は、ＧＵＩ部２６を介してユーザより、ＧＵＩ部２６に表示中の交通ダイヤデータの編集操作を受付けると、図１５のＳ２１２〜Ｓ２１４を実行する。これにより、編集受付部２２３は、排他フラグ管理ＴＬ２５を参照し、交通ダイヤ編集端末２のユーザが編集操作された交通ダイヤデータに対する排他を獲得しているならば、編集操作による変更内容を仮受付する。また、更新情報登録要求部２２２は、該変更内容を基に更新情報登録要求２２２０を生成し、これをネットワークＩＦ部２１を介して交通ダイヤ管理サーバ１に送信する（Ｓ４０７）。そして、所定時間内にエラー通知等がない場合、編集受付部２２３は、作業記憶部２４の交通ダイヤデータを更新し、更新後の交通ダイヤデータを表示する（Ｓ４０８）。

交通ダイヤ管理サーバ１において、ＤＢ更新部１２２は、ネットワークＩＦ部１１を介して交通ダイヤ編集端末２より更新情報登録要求２２２０を受信すると、図１０のＳ１６（図１３および図１４に示すフロー）を実行する。これにより、更新情報登録要求２２２０が更新を要求する交通ダイヤデータについて、当該要求の送信元のユーザが当該交通ダイヤデータに対する排他を獲得しているならば、当該要求に含まれている変更内容を交通ダイヤＤＢ１３に反映させる（Ｓ４１３）。

以上、本発明の一実施形態について説明した。

本実施形態によれば、交通ダイヤデータを複数の階層で管理すると共に、各階層毎に排他フラグ管理ＴＬ１４１〜１４４を用意し、ある交通ダイヤデータに対する排他フラグをいずれかの排他フラグ管理ＴＬで管理している。例えば、ある施行日に運行する全ての列車の交通ダイヤデータに対する排他フラグが階層「大分類」の排他フラグ管理ＴＬ１４１に登録された場合、それ以降、階層「大分類」以下の各排他フラグ管理ＴＬ１４１〜１４４に、当該施行日に運行する交通ダイヤデータに対する排他フラグが登録されることはない。また、ある施行日に線区を運行する全ての列車の交通ダイヤデータに対する排他フラグが階層「中分類」の排他フラグ管理ＴＬ１４２に登録された場合、それ以降、階層「中分類」以下の各排他フラグ管理ＴＬ１４２〜１４４には、当該施行日に当該線区を運行する交通ダイヤデータに対する排他フラグが登録されることはない。また、ある施行日に線区をある種別の目的で運行する全ての列車の交通ダイヤデータに対する排他フラグが階層「小分類」の排他フラグ管理ＴＬ１４３に登録された場合、それ以降、階層「小分類」以下の各排他フラグ管理ＴＬ１４３、１４４には、当該施行日に当該線区を当該種別の目的で運行する交通ダイヤデータに対する排他フラグが登録されることはない。このようにすることで、図面データをメッシュ分割して、各メッシュ毎に排他フラグを管理する特許文献１の技術に比べ、排他フラグの数を低減することができ、これにより、交通ダイヤデータの排他制御に係る処理の負荷を低減させることができる。

また、本実施形態では、図１１および図１２に示すように、排他フラグ登録部１２１による排他フラグ管理ＤＢ１４への排他フラグ登録処理を次の要領で行っている。先ず、排他フラグ登録要求２２１０と同じ施行日を持つレコード１４１０が階層「大分類」の排他フラグ管理ＴＬ１４１に登録されているか否かを調べ、登録されている場合は該要求２２１０を拒否する。次に、同じ施行日を持つレコード１４１０が登録されていない場合であって、排他フラグ登録要求２２１０に線区が含まれている場合は、当該要求２２１０と同じ施行日および線区を持つレコード１４２０が階層「中分類」の排他フラグ管理ＴＬ１４２に登録されているか否かを調べ、登録されている場合は該要求２２１０を拒否する。さらに、同じ施行日および線区を持つレコード１４２０が登録されていない場合であって、排他フラグ登録要求２２１０に種別が含まれている場合は、当該要求２２１０と同じ施行日、線区および種別を持つレコード１４３０が階層「小分類」の排他フラグ管理ＴＬ１４２に登録されているか否かを調べ、登録されている場合は該要求２２１０を拒否する。さらにまた、同じ施行日、線区および種別を持つレコード１４３０が登録されていない場合であって、排他フラグ登録要求２２１０に列車番号が含まれている場合は、当該要求２２１０と同じ施行日、線区、種別および列車番号を持つレコード１４４０が階層「交通ダイヤデータ毎」の排他フラグ管理ＴＬ１４４に登録されているか否かを調べ、登録されている場合は該要求２２１０を拒否する。このように、排他フラグ登録要求の可否判断を上位階層の排他フラグ管理ＴＬから下位階層の排他フラグ管理ＴＬへ向けて行うことで、該判断処理を迅速に行うことができる。

また、本実施形態では、図１３および図１４に示すように、ＤＢ更新部１２２による交通ダイヤＤＢ１３への更新情報反映処理を次の要領で行っている。先ず、更新情報登録要求２２２０と同じ施行日、線区、線種および列車番号を持つレコード１４４０が階層「交通ダイヤデータ毎」の排他フラグ管理ＴＬ１４４に登録されているか否かを調べ、登録されている場合は該要求２２２０を拒否する。次に、同じ施行日、線区、線種および列車番号を持つレコード１４４０が登録されていない場合は、該要求２２２０と同じ施行日、線区および線種を持つレコード１４３０が階層「小分類」の排他フラグ管理ＴＬ１４３に登録されているか否かを調べ、登録されている場合は該要求２２１０を拒否する。さらに、同じ施行日、線区および線種を持つレコード１４３０が登録されていない場合は、該要求２２２０と同じ施行日および線区を持つレコード１４２０が階層「中分類」の排他フラグ管理ＴＬ１４２に登録されているか否かを調べ、登録されている場合は該要求２２１０を拒否する。さらにまた、同じ施行日および線区を持つレコード１４２０が登録されていない場合は、該要求２２２０と同じ施行日を持つレコード１４１０が階層「大分類」の排他フラグ管理ＴＬ１４１に登録されているか否かを調べ、登録されている場合は該要求２２１０を拒否する。このように、更新情報登録要求の可否判断を下位階層の排他フラグ管理ＴＬから上位階層の排他フラグ管理ＴＬへ向けて行うことで、該判断処理を迅速に行うことができる。

なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。

例えば、上記の実施形態では、施行日、線区、種別および列車番号を用いて、大分類、中分類、小分類および交通ダイヤデータ毎の４つの階層で交通管理データを管理する場合を例にとり説明した。しかし、本発明はこれに限定されない。本発明は第１の管理項目をを用いて交通ダイヤデータを第１の階層で管理し、第１および第２の管理項目を用いて交通ダイヤデータを第２の階層で管理し、第１、第２および第３の管理項目を用いて交通ダイヤデータを第３の階層で管理するといったように、複数の管理項目を用いて交通ダイヤデータを複数の階層で管理するものに広く適用できる。

なお、複数の管理項目の組み合わせを１つのデータとして取り扱うようにしてもよい。例えば、図３（Ｂ）において、施行日および線区を繋ぎ合わせたデータを１つのフィールドに登録し、図３（Ｃ）において、施行日、線区および種別を繋ぎ合わせたデータを１つのフィールドに登録し、そして、図３（Ｄ）において、施行日、線区、種別および列車番号を繋ぎ合わせたデータを１つのフィールドに登録してもよい。

また、上記の実施形態では、交通ダイヤデータの編集における排他制御を例にとり説明した。しかし、本発明はこれに限定されない。交通ダイヤデータ以外の図形データであっても、複数の管理項目を用いて階層管理できるものであれば、本発明を適用できる。

図１は本発明の一実施形態が適用された交通ダイヤデータ編集管理システムの概略図である。 図２は交通ダイヤＤＢ１３の登録内容例を示す図である。 図３は排他フラグ管理ＤＢ１４に登録内容例を示す図であり、図３（Ａ）は階層「大分類」に対応する排他フラグ管理ＴＬ１４１の登録内容例を、図３（Ｂ）は階層「中分類」に対応する排他フラグ管理ＴＬ１４２の登録内容例を、図３（Ｃ）は階層「小分類」に対応する排他フラグ管理ＴＬ１４３の登録内容例を、そして、図３（Ｄ）は階層「個別の交通ダイヤデータ」に対応する排他フラグ管理ＴＬ１４４の登録内容例を示す図である。 図４は更新情報管理ＴＬ１５の登録内容例を示す図である。 図５は更新情報管理ＴＬ２３の登録内容例を示す図である。 図６は排他フラグ管理ＴＬ２５の登録内容例を示す図である。 図７は排他フラグ登録要求を模式的に表した図である。 図８は更新情報登録要求を模式的に表した図である。 図９は交通ダイヤ管理サーバ１および交通ダイヤ編集端末２のハードウエア構成例を示す図である。 図１０は交通ダイヤ管理サーバ１の動作フローを説明するための図である。 図１１は排他フラグ登録処理（図１０のＳ１５）を説明するためのフロー図である。 図１２は排他フラグ登録処理（図１０のＳ１５）を説明するためのフロー図である。 図１３は更新内容反映処理（図１０のＳ１６）を説明するためのフロー図である。 図１４は更新内容反映処理（図１０のＳ１６）を説明するためのフロー図である。 図１５は交通ダイヤ編集端末２の動作フローを説明するための図である。 図１６は管理項目受付画面の一例を示す図である。 図１７は交通ダイヤデータの表示画面の一例である。 図１８は交通ダイヤデータの編集内容識別表示画面の一例を示す図である。 図１９は交通ダイヤデータの更新部分識別表示画面の一例を示す図である。 図２０は交通ダイヤデータの更新拒否識別表示画面の一例を示す図である。 図２１は交通ダイヤ管理サーバ１および交通ダイヤ編集端末２間の情報のやり取りを説明するための図である。

符号の説明

１…交通ダイヤ管理サーバ、２…交通ダイヤ編集端末、３…ネットワーク、１１…ネットワークＩＦ部、１２…排他制御部、１３…交通ダイヤＤＢ、１４…排他フラグ管理ＤＢ、１５…更新情報管理ＴＬ、２１…ネットワークＩＦ部、２２…交通ダイヤ編集部、２３…更新情報管理ＴＬ、２４…作業用記憶部、２５…排他フラグ管理ＴＬ、２６…ＧＵＩ部、１２１…排他フラグ登録部、１２２…ＤＢ更新部、１２３…ＤＢ転送部、２２１…排他フラグ登録要求部、２２２…更新情報登録要求部、２２３…編集受付部、２２４…交通ダイヤ読込部

Claims (10)

1. 少なくとも１つの図形データ編集装置より図形データの更新要求を受付け、受付けた要求に従って自身が保持する当該図形データを更新する図形データ管理装置であって、
   複数の管理項目を用いて階層的に分類された図形データが複数記憶された図形データ記憶手段と、
   前記図形データ記憶手段に記憶された図形データを読み出して前記少なくとも１つの図図形データ編集装置に送信する図形データ送信手段と、
   前記階層毎に設けられた、対応する階層において分類される図形データのグループに対する排他を獲得したユーザの情報が登録された排他フラグ記憶手段と、
   前記階層毎に設けられた排他フラグ記憶手段を参照して、前記更新要求の対象となる図形データの排他を制御する排他制御手段と、を有し、
   前記排他制御手段は、
   前記更新要求の対象となる図形データを含むグループに対する排他を獲得したユーザの情報を、前記階層毎に設けられた排他フラグ記憶手段から検索し、検索したユーザの情報が前記更新要求の送信元の情報と一致する場合に、前記更新要求に従い前記図形データ記憶手段に記憶されている前記更新要求の対象となる図形データを更新し、検索したユーザの情報が前記更新要求の送信元の情報と一致しない場合、もしくは、ユーザの情報を検索できなかった場合に、前記更新要求に従った前記図形データ記憶手段の更新を拒否すること
   を特徴とする図形データ管理装置。
2. 請求項１に記載の図形データ管理装置であって、
   前記排他フラグ記憶手段は、
   当該排他フラグ記憶手段が対応する階層よりも上位の階層において分類される図形データのグループに対する排他を獲得したユーザの情報が、当該上位の階層に対応する排他フラグ記憶手段に登録された場合に、当該グループに属する図形データに対する排他を獲得した当該ユーザの情報が重複して新たに登録されないこと
   を特徴とする図形データ管理装置。
3. 請求項１又は２に記載の図形データ管理装置であって、
   前記更新要求を登録する更新要求記憶手段をさらに有し、
   前記排他制御手段は、
   前記階層毎に設けられた排他フラグ記憶手段から検索した、前記更新要求の対象となる図形データを含むグループに対する排他を獲得したユーザの情報が、前記更新要求の送信元の情報と一致する場合に、前記更新要求を前記更新要求記憶手段に記憶すると共に、前記更新要求記憶手段に記憶されている前記更新要求に従い前記図形データ記憶手段を更新すること
   を特徴とする図形データ管理装置。
4. 請求項１乃至３のいずれか一項に記載の図形データ管理装置であって、
   前記排他制御手段は、
   前記更新要求の対象となる図形データを含むグループに対する排他を獲得したユーザの情報を前記排他フラグ記憶手段から検索する処理を、最下位層に対応する排他フラグ記憶手段から順番に、当該ユーザ情報が検出されるまで実行すること
   を特徴とする図形データ管理装置。
5. 請求項１乃至４のいずれか一項に記載の図形データ管理装置であって、
   前記少なくとも１つの図形データ編集装置より、前記複数の管理項目のうちの少なくとも１つの管理項目の指定値を含む排他フラグ登録要求を受付けて、前記少なくとも１つの管理項目により管理される階層に対応する前記排他フラグ記憶手段に、前記排他フラグ登録要求の送信元ユーザの情報を、前記少なくとも１つの管理項目の指定値に対応付けて登録する排他フラグ登録手段をさらに有し、
   前記排他フラグ登録手段は、
   前記少なくとも１つの管理項目により管理される階層および当該階層より上位の階層に対応する各排他フラグ記憶手段に対して、最上位層に対応する排他フラグ記憶手段から順番に、前記排他フラグ登録要求に含まれている、当該排他フラグ記憶手段が対応する階層で用いる管理項目の指定値に対応付けられて、ユーザの情報が登録されているか否かを調べ、登録されている場合は、前記少なくとも１つの管理項目により管理される階層に対応する前記排他フラグ記憶手段に、前記排他フラグ登録要求の送信元ユーザの情報を登録しないこと
   を特徴とする図形データ管理装置。
6. 請求項１乃至５のいずれか一項に記載の図形データ管理装置であって、
   前記図形データは、列車の交通ダイヤデータであり、
   前記図形データ記憶手段には、施行日、線区、種別（運行目的）および列車番号を用いて階層的に分類された列車の交通ダイヤデータが記憶されており、
   前記階層毎に設けられた排他フラグ記憶手段は、
   施行日と、当該施行日に運行する全ての列車の交通ダイヤデータに対する排他を獲得したユーザの情報との対応関係が記憶された階層「大分類」の排他フラグ記憶手段と、
   施行日および線区と、当該施行日に当該線区を運行する全ての列車の交通ダイヤデータに対する排他を獲得したユーザの情報との対応関係が記憶された階層「中分類」の排他フラグ記憶手段と、
   施行日、線区および種別と、当該施行日に当該線区を当該種別のために運行する全ての列車の交通ダイヤデータに対する排他を獲得したユーザの情報との対応関係が記憶された階層「小分類」の排他フラグ記憶手段と、
   施行日、線区、種別および列車番号と、当該施行日に当該線区を当該種別のために運行する、当該列車番号を持つ列車の交通ダイヤデータに対する排他を獲得したユーザの情報との対応関係が記憶された階層「交通ダイヤデータ毎」の排他フラグ記憶手段とを有し、
   前記排他制御手段は、
   前記更新要求の対象となる交通ダイヤデータの施行日、線区、種別および列車番号に対応付けられたユーザの情報を前記階層「交通ダイヤデータ毎」の排他フラグ記憶手段から検索し、前記階層「交通ダイヤデータ毎」の排他フラグ記憶手段から検索できなかった場合に、前記更新要求の対象となる交通ダイヤデータの施行日、線区および種別に対応付けられたユーザの情報を前記階層「小分類」の排他フラグ記憶手段から検索し、前記階層「小分類」の排他フラグ記憶手段から検索できなかった場合に、前記更新要求の対象となる交通ダイヤデータの施行日および線区に対応付けられたユーザの情報を前記階層「中分類」の排他フラグ記憶手段から検索し、前記階層「中分類」の排他フラグ記憶手段から検索できなかった場合に、前記更新要求の対象となる交通ダイヤデータの施行日に対応付けられたユーザの情報を前記階層「大分類」の排他フラグ記憶手段から検索すること
   を特徴とする図形データ管理装置。
7. 請求項５に記載の図形データ管理装置であって、
   前記図形データは、列車の交通ダイヤデータであり、
   前記図形データ記憶手段には、施行日、線区、種別（運行目的）および列車番号を用いて階層的に分類された列車の交通ダイヤデータが記憶されており、
   前記階層毎に設けられた排他フラグ記憶手段は、
   施行日と、当該施行日に運行する全ての列車の交通ダイヤデータに対する排他を獲得したユーザの情報との対応関係が記憶された階層「大分類」の排他フラグ記憶手段と、
   施行日および線区と、当該施行日に当該線区を運行する全ての列車の交通ダイヤデータに対する排他を獲得したユーザの情報との対応関係が記憶された階層「中分類」の排他フラグ記憶手段と、
   施行日、線区および種別と、当該施行日に当該線区を当該種別のために運行する全ての列車の交通ダイヤデータに対する排他を獲得したユーザの情報との対応関係が記憶された階層「小分類」の排他フラグ記憶手段と、
   施行日、線区、種別および列車番号と、当該施行日に当該線区を当該種別のために運行する、当該列車番号を持つ列車の交通ダイヤデータに対する排他を獲得したユーザの情報との対応関係が記憶された階層「交通ダイヤデータ毎」の排他フラグ記憶手段とを有し、
   前記排他フラグ登録要求は、
   施行日の指定値と、施行日および線区の指定値と、施行日、線区および種別の指定値と、施行日、線区、種別および列車番号の指定値とのいずれかを含んでおり、
   前記排他フラグ登録手段は、
   前記排他フラグ登録要求に施行日の指定値が含まれている場合、前記階層「大分類」の排他フラグ記憶手段に、当該施行日の指定値に対応付けられてユーザの情報が登録されているか否かを調べ、前記排他フラグ登録要求に施行日および線区の指定値が含まれている場合、前記階層「中分類」の排他フラグ記憶手段に、当該施行日および線区の指定値に対応付けられてユーザの情報が登録されているか否かを調べ、前記排他フラグ登録要求に施行日、線区および種別の指定値が含まれている場合、前記階層「小分類」の排他フラグ記憶手段に、当該施行日、線区および種別の指定値に対応付けられてユーザの情報が登録されているか否かを調べ、そして、前記排他フラグ登録要求に施行日、線区、種別および列車番号の指定値が含まれている場合、前記階層「交通ダイヤデータ毎」の排他フラグ記憶手段に、当該施行日、線区、種別および列車番号の指定値に対応付けられてユーザの情報が登録されているか否かを調べ、登録されている場合は、前記排他フラグ登録要求の送信元ユーザの情報を、前記排他フラグ登録要求に含まれている全ての管理項目の組合せに対応する階層の排他フラグ記憶手段に登録しないこと
   を特徴とする図形データ管理装置。
8. 請求項１乃至７のいずれか一項に記載の図形データ管理装置が保持する図形データを編集する図形データ編集装置であって、
   前記図形データ管理装置より受信した図形データを記憶する作業用記憶手段と、
   前記作業用記憶手段に記憶されている図形データを読み出して表示装置に表示すると共に、入力装置を介して前記表示装置に表示された図形データの編集を受付け、当該受付けた編集内容に従って図形データの更新要求を生成し前記図形データ管理装置に送信する図形データ編集手段と、を有し、
   前記図形データ編集手段は、
   前記図形データ管理装置によって前記更新要求が拒否されなかった場合に、前記受付た編集内容に従い前記作業用記憶手段に記憶されている図形データを更新すること
   を特徴とする図形データ編集装置。
9. 請求項８に記載の図形データ編集装置であって、
   前記図形データ編集手段は、
   編集を受付けた図形データの編集前の状態と編集後の状態とが識別できるように前記表示装置に表示すること
   を特徴とする図形データ編集装置。
10. 図形データ管理装置が、少なくとも１つの図形データ編集装置より図形データの更新要求を受付け、受付けた要求に従って自身が保持する当該図形データを更新する図形データ管理方法であって、
    前記図形データ管理装置は、複数の管理項目を用いて階層的に分類された図形データが複数記憶された図形データ記憶手段と、前記階層毎に設けられた、対応する階層において分類される図形データのグループに対する排他を獲得したユーザの情報が登録された排他フラグ記憶手段と、を有し、
    前記図形データ管理方法は、
    前記更新要求の対象となる図形データを含むグループに対する排他を獲得したユーザの情報を、前記階層毎に設けられた排他フラグ記憶手段から検索するステップと、
    検索したユーザの情報が前記更新要求の送信元の情報と一致するか否かを調べるステップと、
    一致する場合に、前記更新要求に従い前記図形データ記憶手段に記憶されている前記更新要求の対象となる図形データを更新し、検索したユーザの情報が前記更新要求の送信元の情報と一致しない場合、もしくは、ユーザの情報を検索できなかった場合に、前記更新要求に従った前記図形データ記憶手段の更新を拒否する排他制御ステップと、を有すること
    を特徴とする図形データ管理方法。

Images