JP4795820B2 - 地図データ作成装置、地図データ作成方法、地図データチェックプログラム - Google Patents

Description

本発明は、地図データの整合性のチェックを行う上で好適な地図データ作成装置に関する。

現在、車両に搭載されるナビゲーション装置等に使用される地図データは、ベクタデータで表現されている。ベクタデータでは、地図上の街区、建物等の事物（以下、単に「オブジェクト」と称す）が、位置と長さと方向を持ったベクトルで表現され、さらに、夫々のオブジェクトには、属性情報が付加されている。

このような地図データは、各市町村から発行される都市計画図を基に作成される。具体的には、まず、都市計画図をスキャンすることにより、ビットマップデータなどの画素の集合体で示されたラスタデータが作成される。次に、ラスタデータをメッシュに区画し、メッシュごとに都市計画図上の建物や街区、幹線道路などのオブジェクトをトレースすることにより、オブジェクトをベクタデータで表現した地図データが作成される。

しかしながら、上述の都市計画図の中には、作成対象外となっているために未完成となっている部分、いわゆる白部が存在するものがある。そのため、地図データの隣接メッシュ間の整合性のチェックを行う際にエラーを検知した場合、白部が存在することによってエラーとなるのか、または、トレースのし忘れによってエラーとなるのか、の区別が付き難く、その都度、ラスタデータを確認する必要があった。

なお、下記の特許文献１では、ラスタデータからベクタデータに変換する際、変換対象としたいオブジェクトのみにフラグを立てることにより、当該オブジェクトのみをベクタデータに変換する方法が記載されている。

特開平６−２４３２１４号公報

本発明が解決しようとする課題には、上記のようなものが一例として挙げられる。本発明は、地図データの整合性のチェックを行う際に、効率的な整合性チェックを行うことの可能な地図データ作成装置を提供することを課題とする。

請求項１に記載の発明は、地図データ作成装置において、原稿地図をスキャンすることによりラスタデータを作成するラスタデータ作成手段と、オペレータにより操作され、前記ラスタデータをメッシュに区画すると共に、前記地図上のオブジェクト毎にベクタデータに変換して属性情報を付加するベクタデータ変換手段と、を備え、前記原稿地図は、地図情報が存在しない未完成の領域である白部を含み、前記ベクタデータ変換手段は、前記白部もベクタデータに変換し、未完成であることを示す属性情報を付加することを特徴とする。
請求項４に記載の発明は、コンピュータを備える装置により実行される地図データ作成方法であって、原稿地図をスキャンすることによりラスタデータを作成するラスタデータ作成工程と、前記ラスタデータをメッシュに区画すると共に、前記地図上のオブジェクト毎にベクタデータに変換して属性情報を付加するベクタデータ変換工程と、を備え、前記原稿地図は、地図情報が存在しない未完成の領域である白部を含み、前記ベクタデータ変換工程は、前記白部もベクタデータに変換し、未完成であることを示す属性情報を付加することを特徴とする。

本発明の１つの観点では、地図データ作成装置は、原稿地図をスキャンすることによりラスタデータを作成するラスタデータ作成手段と、オペレータにより操作され、前記ラスタデータをメッシュに区画すると共に、前記地図上のオブジェクト毎にベクタデータに変換して属性情報を付加するベクタデータ変換手段と、を備え、前記原稿地図は、地図情報が存在しない領域である白部を含み、前記ベクタデータ変換手段は、前記白部もベクタデータに変換し属性情報を付加する。

上記の地図データ作成装置は、ラスタデータ作成手段と、ベクタデータ変換手段と、を備える。前記ラスタデータ作成手段は、オペレータにより操作され、前記ラスタデータをメッシュに区画すると共に、前記地図上のオブジェクト毎にベクタデータに変換して属性情報を付加する。また、前記原稿地図は、地図情報が存在しない領域である白部を含み、前記ベクタデータ変換手段は、前記白部もベクタデータに変換し属性情報を付加する。ここでいうオブジェクトとは、建物、街区、幹線道路といった、地図上の構成要素である。地図上の白部とは、作成対象外となっているために未完成となっている、地図情報が存在しない領域のことである。地図上のオブジェクトや白部は、具体的には、オペレータによりトレースされることにより、ベクタデータに変換される。さらに、ベクタデータに変換されたオブジェクトや白部には、その形状や、地図データ上での表示の仕方といった属性情報が付加される。このように、地図上の白部にも、属性情報を付加することにより、地図データの隣接メッシュ間の整合性のチェックの際、白部が存在することによってエラーとなるのか、または、オブジェクトのトレースのし忘れによってエラーとなるのか、の区別が付きやすくなり、効率的に整合性チェックを行うことができる。

上記の地図データ作成装置の一態様は、前記白部に付加される属性情報は、ベクタデータを表示するときの色の属性情報を含む。このようにすることで、オペレータは、オブジェクトがベクタデータに変換された後の地図データ上で、前記白部を一目瞭然に判別することが可能となる。

上記の地図データ作成装置の他の一態様は、隣接する前記メッシュ間の整合性を自動的にチェックする整合性チェック手段と、を備え、前記整合性チェック手段は、前記白部に付加される属性情報を取得することにより、白部となっている部分を判別する。このように、自動的にチェックする場合においても、前記白部に付加される属性情報を取得することにより、白部となっている部分を判別することができる。

本発明の他の観点では、地図データ作成方法は、原稿地図をスキャンすることによりラスタデータを作成するラスタデータ作成工程と、前記ラスタデータをメッシュに区画すると共に、前記地図上のオブジェクト毎にベクタデータに変換して属性情報を付加するベクタデータ変換工程と、を備え、前記原稿地図は、地図情報が存在しない領域である白部を含み、前記ベクタデータ変換工程は、前記白部もベクタデータに変換し属性情報を付加する。これによっても、地図データの隣接メッシュ間の整合性のチェックの際、効率的に整合性チェックを行うことができる。

本発明の更なる他の観点では、コンピュータにより実行され、メッシュ毎に区画された地図データの整合性をチェックするプログラムであって、前記地図データは、地図上のオブジェクト毎に作成され属性情報を有する複数のベクタデータを含み、前記ベクタデータは、地図情報が存在しない領域に対応する不完全部オブジェクトに対応するベクタデータを含み、相互に隣接するメッシュに存在するオブジェクトが、前記メッシュの境界において連続しているか否かを判定する手段、前記オブジェクトが連続していない場合に、前記オブジェクトの一方が不完全部オブジェクトであるか否かを判定する手段、前記オブジェクトが連続している場合又は前記オブジェクトの一方が不完全部オブジェクトである場合に地図データの整合性が正しいと判断する手段、として前記コンピュータを機能させる。これによっても、前記白部に付加される属性情報を取得することにより、白部となっている部分を判別することができる。

本発明の好適な実施例では、地図上のオブジェクト毎に用意され、対応するオブジェクトを示す属性情報を有するベクタデータを有する地図データは、地図情報が存在しない領域に対応する不完全部オブジェクトに対応するベクタデータを含み、前記ベクタデータは、地図情報が存在しないことを示す不完全部という属性が設定されてなる。

［地図データ作成装置］
以下、本発明の好適な実施例を図面に基づいて説明する。図１に、本発明の実施例に係る地図データ作成装置１００の全体構成を示す。

地図データ作成装置１００は、例えば、パーソナルコンピュータであり、システムバス２と、ＣＰＵ４と、メモリ６と、キーボード２２と、座標指示デバイス２４と、スキャナ２６と、ディスプレイ２８と、プリンタ３０と、データベース３２より構成される。ＣＰＵ４、メモリ６は、システムバス２に接続され、キーボード２２、マウス等の座標指示デバイス２４、スキャナ２６といった入力装置、ディスプレイ２８、プリンタ３０といった出力装置、及び、データベース３２は、図示しないインターフェースを介してシステムバス２に夫々接続される。

ＣＰＵ４は、地図データ作成装置１００全体を制御し、入出力デバイスの制御を行う。また、ＣＰＵ４は、メモリ６に記憶されているプログラムの処理フローに従って、原稿地図の読み取り、ラスタデータの作成、ラスタデータからベクタデータへの変換、地図データの出力を行う。これらの処理については、後に詳述する。従って、ＣＰＵ４は、本発明におけるラスタデータ作成手段、ベクタデータ変換手段として機能する。

オペレータは、スキャナ２６に原稿地図、例えば、市町村等により発行された都市計画図などの地図をセットする。スキャナ２６は、ＣＰＵ４により制御され、原稿地図を読み取って、２値化し、当該原稿地図に対応するラスタデータに変換する。ラスタデータは、原稿地図を画素（ピクセル）の集合体で表したデータ形式であり、一般的なビットマップデータ等で表された画像データと同様のデータ構造となる。

次に、オペレータは、ラスタデータに変換された地図を格子状に規定された複数のメッシュに区画する。都市計画図は、先にも述べたように、市町村等によって独自に作成されるので、複数の都市計画図間で重複する領域が存在する。従って、メッシュに区画して、夫々のメッシュ毎に必要な地図情報のみを夫々の都市計画図より抽出し、組み合わせる必要が生じる。この１つ１つのメッシュの内部には、識別番号が付加される。このようにすることで、ラスタデータからベクタデータへ変換した後、メッシュを統合して１つの地図データとすることが可能となる。

メッシュに区画されたラスタデータは、メッシュごとにベクタデータに変換される。ベクタデータは、線や面といった位置と長さと方向のベクトルで規定されるデータ形式である。具体的には、オペレータが、ラスタデータに変換された地図上の街区、建物等の事物（以下、このような事物を「オブジェクト」と称す）をトレースして、又は、パターン認識プログラムを用いることにより、オブジェクトをベクタデータに変換する。このようにしてベクタデータに変換されたオブジェクトの位置と長さと方向の情報は、データベース３２に記憶される。さらに、ベクタデータでは、このように規定された線、面に対し、属性情報を付加することができる。

図２（ａ）は、１つのメッシュにおけるラスタデータで表現された地図データを示しており、図２（ｂ）は、図２（ａ）のオブジェクトをベクタデータに変換した後の地図データを示している。オペレータは、地図上の街区、建物等といったオブジェクトをトレースする際、夫々のオブジェクトの位置と長さと方向のベクトルで規定するとともに、夫々のオブジェクトの属性を決定する。

図２（ａ）、（ｂ）には、建物５１、街区５２、幹線道路５３、街路５４、不完全部５５が、オブジェクトの例として示されている。図２（ａ）、（ｂ）上において、建物５１として示されている部分には、ビルなどの建物が存在することを示している。街区５２として示されている部分は、地域や地区を示している。幹線道路５３として示されている部分は、ある一定以上の道幅を有する主要な幹線道路を示している。街路５４として示されている部分は、上記の幹線道路として示される以外の比較的小さな道路を示している。不完全部５５は、元々の原稿地図上で作成対象外となっているため、地図情報が存在しない領域、いわゆる白部を示している。

図３（ａ）〜（ｄ）は、建物５１、街区５２、幹線道路５３、不完全部５５の属性データを表にして示している。図３の表には、属性の種類として、「主題」、「空間」、「表示」の各属性が示されている。

「主題」の属性は、夫々のオブジェクトの種類を示し、例えば、建物、街区、幹線道路などというように示される。

「空間」の属性は、夫々のオブジェクトの形状を示している。夫々の表の下には、夫々のオブジェクトの形状が示されている。このオブジェクトの形状は、位置と長さと方向、即ち、黒点で示す位置と、それらを結ぶ線分によって規定されている。このオブジェクトの形状を基に、「空間」の属性が、例えば、ポイント（点）、ライン（線）、ポリゴン（多角形）というように規定される。ポイントは、点、即ち、一点で示される位置のみで表すことのできるオブジェクトの属性である。例えば、病院や学校の地図記号等がこれに当たる。ラインは、線で示すことのできるオブジェクトの属性である。例えば、道路や川がこれに当たる。ポリゴンは、多角形で示すことのできるオブジェクトの属性である。例えば、建物や街区がこれに当たる。

「表示」の属性は、オブジェクトをベクタデータに変換した後の地図データをオペレータが見たときに、オブジェクトがどのように見えるかを示している。オペレータは、夫々のオブジェクトの種類毎に「表示」の属性を決めておく。例えば、本実施例では、建物を黄色、街区を茶色、幹線道路を緑色、不完全部を赤色で示すこととする。このようにすることで、オペレータは、オブジェクトをベクタデータに変換した後の地図データを見たときに、表示される色によって、どこに何の種類のオブジェクトがあるのかを一目瞭然に判断することができる。

図３（ａ）の建物５１の表を見てみる。このオブジェクトの種類は、建物なので、「主題」の属性は、「建物」となる。図２（ａ）、（ｂ）から分かるように、建物５１は、建物５１の表の下に示すような形状、即ち、多角形（ポリゴン）となることが分かる。従って、「空間」の属性は、「ポリゴン」となる。「表示」の属性は、オブジェクトの種類が建物なので「黄色」とされる。このようにすることで、建物５１は、オブジェクトをベクタデータに変換した後の地図データ上では、黄色で表示される。

図３（ｂ）の街区５２の表を見てみる。このオブジェクトの種類は、街区なので、「主題」の属性は、「街区」となる。図２（ａ）、（ｂ）から分かるように、街区５２も、街区５２の表の下に示すような形状、即ち、多角形（ポリゴン）となることが分かる。従って、「空間」の属性は、「ポリゴン」となる。「表示」の属性は、オブジェクトの種類が街区なので「茶色」とされる。このようにすることで、街区５２は、オブジェクトをベクタデータに変換した後の地図データ上では、茶色で表示される。

図３（ｃ）の幹線道路５３の表を見てみる。このオブジェクトの種類は、幹線道路なので、「主題」の属性は、「幹線道路」となる。図２（ａ）、（ｂ）から分かるように、幹線道路５３は、道を示しているので、基本的には、２本の線を並べたもので示すことができる。従って幹線道路５３の表の下に示すような形状、即ち、線（ライン）となることが分かる。従って、「空間」の属性は、「ライン」となる。「表示」の属性は、オブジェクトの種類が幹線道路なので「緑色」とされる。このようにすることで、幹線道路５３は、オブジェクトをベクタデータに変換した後の地図データ上では、緑色で表示される。

図３（ｄ）の不完全部５５の表を見てみる。このオブジェクトの種類は、不完全部なので、「主題」の属性は、「不完全部」となる。図２（ａ）、（ｂ）から分かるように、不完全部５５は、不完全部５５の表の下に示すような形状、即ち、多角形（ポリゴン）となることが分かる。従って、「空間」の属性は、「ポリゴン」となる。「表示」の属性は、オブジェクトの種類が不完全部なので「赤色」とされる。このようにすることで、不完全部５５は、オブジェクトをベクタデータに変換した後の地図データ上では、赤色で表示される。

ここで、オブジェクトをベクタデータに変換した後の地図データ上において、上述した建物、街区、幹線道路、不完全部などのオブジェクトの存在しない位置を「街路」と規定する。つまり、街路５４のような「街路」は、上述したオブジェクトのように、属性を持たない。街路は、幹線道路よりも小さな道路を示すが、その数は膨大であり、夫々に属性を持たせると、オブジェクトをベクタデータに変換した後の地図データのデータ量が膨大なものとなってしまう。そこで、本実施例では、オブジェクトの存在しない位置を「街路」と規定し、オブジェクトをベクタデータに変換した後の地図データ上では、街路は白色などの背景色で表示される。なお、このような「街路」にも属性情報を持たせることとしても良いのはいうまでもない。

従来の、オブジェクトをベクタデータに変換された後の地図データでは、不完全部についても属性を規定していなかったので、当該地図データ上において、例えば、背景色の白色となっている部分が、街路なのか、不完全部なのかを判別することが難しかった。この場合、オペレータは、ラスタデータを逐一確認することにより、オブジェクトをベクタデータに変換した後の地図データ上における白色となっている部分が、街路なのか、不完全部なのかを判別していた。本実施例に係る、オブジェクトをベクタデータに変換した後の地図データでは、不完全部についても、ポリゴンとして空間の属性が規定され、さらに、赤色などの表示の属性も規定されるので、オペレータは、当該地図データを見たときに、街路と不完全部を明確に区別することができる。また、このように、不完全部の属性を規定することにより、隣接するメッシュ間の整合性のチェックを、プログラムなどにより機械的に行う際にも、不完全部を判別することが可能となる。

［地図データ作成処理］
次に、本実施例における地図データ作成処理について述べる。図４に、本実施例に係る地図データ作成処理のフローチャートを示す。この地図データ作成処理のフローチャートは、オペレータによる処理を示したものである。

まず、オペレータは、スキャナ２６に原稿地図を読み取らせることにより、ラスタデータを作成し（ステップＳ１１）、ラスタデータに変換された地図を格子状に規定された複数のメッシュに区画する（ステップＳ１２）。

オペレータは、上述した方法を用いて、ラスタデータをベクタデータに変換する（ステップＳ１３）。このとき、不完全部を含む各オブジェクトの属性が規定される。ベクタデータに変換された不完全部を含む各オブジェクトの位置や長さの情報、属性情報は、データベース３２に記憶される。

次に、オペレータは、データチェック処理を行う（ステップＳ１４）。このデータチェック処理について詳しく述べる。図５は、ステップＳ１４のデータチェック処理のフローチャートを示す。

データチェック処理において、まず、オペレータは、目視により、ベクタデータをチェックする。具体的には、オブジェクトをベクタデータに変換した後の地図データ上の隣接するメッシュ間における各オブジェクトの整合が取れているかどうか、をチェックする（ステップＳ２１）。

図６（ａ）〜（ｃ）に、互いに隣接する２つのメッシュＭ１、Ｍ２間における各オブジェクトの模式図の一例を示す。図６（ａ）〜（ｃ）では、線分Ｌ１、Ｌ２を境界として、メッシュＭ１、Ｍ２が隣接しているとする。ここでは、一例として、幹線道路５３のオブジェクトの整合が取れているかどうか、をチェックする。図６（ａ）に示すように、幹線道路５３が、メッシュＭ１、Ｍ２に跨って存在するとする。このとき、オペレータは、メッシュＭ１における幹線道路５３とメッシュＭ２における幹線道路５３が、メッシュＭ１とメッシュＭ２の境界において連続しているか、つまり、図６（ａ）で言うと、メッシュＭ１における幹線道路５３のメッシュＭ２との境界の座標Ｐ１、Ｐ２と、メッシュＭ２における幹線道路５３のメッシュＭ１との境界の座標Ｐ３、Ｐ４とが、夫々一致するか否か、をチェックする。

オペレータは、メッシュＭ１における幹線道路５３のメッシュＭ２との境界の座標と、メッシュＭ２における幹線道路５３のメッシュＭ１との境界の座標が一致しており、幹線道路５３のオブジェクトの整合が取れていると判断した場合には、エラーなしとみなす（ステップＳ２２：Ｎｏ）。

ここで、もし、オペレータが、幹線道路５３のオブジェクトの整合がとれていないと判断した場合には（ステップＳ２２：Ｙｅｓ）、幹線道路５３のオブジェクトが不完全部５５のオブジェクトと接しているか否かを判定する。例えば、図６（ｂ）の破線６３で示すように、本来、幹線道路５３のオブジェクトが、メッシュＭ２に存在するにもかかわらず、オペレータがトレースし忘れたのか、もしくは、図６（ｃ）に示すように、元々の原稿地図上で作成対象外となっているために、メッシュＭ２上では、不完全部５５となっているのかを判定する（ステップＳ２３）。不完全部５５は、本実施例では、オブジェクトをベクタデータに変換した後の地図データ上では、赤で表示されるとしているので、オペレータは、目視により容易に判定することができる。

図６（ｂ）に示すように、不完全部５５と接するのでなければ（ステップＳ２３：Ｎｏ）、隣接メッシュ、ここでは、メッシュＭ２を修正する（ステップＳ２４）。例えば、図６（ｂ）に示したように、トレースのし忘れといった場合には、オペレータは、メッシュＭ２における幹線道路５３のトレースを行う。一方、不完全部５５と接するのであれば、そのまま、次のステップに進む（ステップＳ２３：Ｙｅｓ）。なぜならば、不完全部５５は、元々、原稿地図上において、データの存在しない場所だからである。

上述したメッシュ間の整合性のチェックは、オペレータの目視による他、プログラムによって自動的に行うとすることもできる。本実施例に係るデータチェック処理では、オペレータの目視による整合性のチェックの後、更に、プログラムによる整合性チェックを行うこととしている。

オペレータは、ステップＳ２１〜ステップＳ２４の処理を終えた後、例えば、地図データ作成装置１００において、メモリ６に予め保持されている整合性チェック用のプログラムを起動する。当該プログラムの指令により、ＣＰＵ４は、ステップＳ２５〜ステップＳ２８の処理を行う。従って、ＣＰＵ４は、本発明の整合性チェック手段としても機能する。ステップＳ２５〜ステップＳ２８についても、図６（ａ）〜（ｃ）を例として用いて説明する。

まず、メッシュＭ１、Ｍ２の夫々において、幹線道路５３のオブジェクトは、位置と長さをデータとして有している。そこで、ＣＰＵ４は、メッシュＭ１における幹線道路５３のメッシュＭ２との境界の座標Ｐ１、Ｐ２と、メッシュＭ２における幹線道路５３のメッシュＭ１との境界の座標Ｐ３、Ｐ４を取得し、夫々一致するか否か、をチェックする（ステップＳ２５）。

ＣＰＵ４は、メッシュＭ１における幹線道路５３のメッシュＭ２との境界の座標と、メッシュＭ２における幹線道路５３のメッシュＭ１との境界の座標が一致しており、幹線道路５３のオブジェクトの整合が取れていると判断した場合には、エラーなしとみなし、データチェック処理を終了する（ステップＳ２６：Ｎｏ）。

ＣＰＵ４は、幹線道路５３のオブジェクトの整合がとれていないと判断した場合には（ステップＳ２６：Ｙｅｓ）、幹線道路５３のオブジェクトが不完全部５５のオブジェクトと接しているか否かを判定する（ステップＳ２７）。本実施例では、不完全部５５のオブジェクトは、その属性情報を「不完全部」として規定しているので、ＣＰＵ４は、例えば、幹線道路５３と隣接するオブジェクトの「主題」の属性を取得することにより、不完全部か否かを判定することができる。

ＣＰＵ４は、幹線道路５３のオブジェクトが不完全部５５のオブジェクトと接するのでないと判断した場合には（ステップＳ２７：Ｎｏ）、そのことをディスプレイ２８上に表示するなどして、オペレータに知らせる。オペレータは、表示を確認した後、隣接メッシュ、ここでは、メッシュＭ２を修正する（ステップＳ２８）。一方、ＣＰＵ４は、不完全部５５と接すると判断した場合には、そのまま、データチェック処理を終了する（ステップＳ２７：Ｙｅｓ）。

以上に述べたデータチェック処理を行った後、図４のフローチャートに戻り、ステップＳ１５に進む。ステップＳ１５では、出荷用の地図データとして、データベース３２に記憶されている各メッシュの地図データを統合して出力する。なお、このとき、一般的には、不完全部は、エンドユーザに対し表示されない。つまり、不完全部となる部分の属性は、取り除かれ、不完全部は、背景色で表示される。

以上に説明したように、本実施例では、地図データ作成装置は、原稿地図をスキャンすることによりラスタデータを作成するラスタデータ作成手段と、オペレータにより操作され、前記ラスタデータをメッシュに区画すると共に、前記地図上のオブジェクト毎にベクタデータに変換して属性情報を付加するベクタデータ変換手段と、を備え、前記原稿地図は、地図情報が存在しない領域である白部を含み、前記ベクタデータ変換手段は、前記白部もベクタデータに変換し属性情報を付加する。このように、地図上の白部にも、属性情報を付加することにより、地図データの隣接メッシュ間の整合性のチェックの際、白部が存在することによってエラーとなるのか、または、オブジェクトのトレースのし忘れによってエラーとなるのか、の区別が付きやすくなり、効率的に整合性チェックを行うことができる。

本実施例に係る地図データ作成装置の全体構成を示すブロック図である。 ラスタデータ及びベクタデータで表現された地図データを示す図である。 各オブジェクトの属性を示す図表である。 本実施例に係る地図データ作成処理のフローチャートである。 本実施例に係るデータチェック処理のフローチャートである。 隣接するメッシュの地図データを示す図である。

符号の説明

２・・・システムバス
４・・・ＣＰＵ
６・・・メモリ
２６・・・スキャナ

Claims (4)

1. 原稿地図をスキャンすることによりラスタデータを作成するラスタデータ作成手段と、
   オペレータにより操作され、前記ラスタデータをメッシュに区画すると共に、前記地図上のオブジェクト毎にベクタデータに変換して属性情報を付加するベクタデータ変換手段と、を備え、
   前記原稿地図は、地図情報が存在しない未完成の領域である白部を含み、
   前記ベクタデータ変換手段は、前記白部もベクタデータに変換し、未完成であることを示す属性情報を付加することを特徴とする地図データ作成装置。
2. 前記白部に付加される属性情報は、ベクタデータを表示するときの色の属性情報を含むことを特徴とする請求項１に記載の地図データ作成装置。
3. 隣接する前記メッシュ間の整合性を自動的にチェックする整合性チェック手段を備え、
   前記整合性チェック手段は、前記白部に付加される属性情報を取得することにより、白部となっている部分を判別することを特徴とする請求項１又は２に記載の地図データ作成装置。
4. コンピュータを備える装置により実行される地図データ作成方法であって、
   原稿地図をスキャンすることによりラスタデータを作成するラスタデータ作成工程と、
   前記ラスタデータをメッシュに区画すると共に、前記地図上のオブジェクト毎にベクタデータに変換して属性情報を付加するベクタデータ変換工程と、を備え、
   前記原稿地図は、地図情報が存在しない未完成の領域である白部を含み、
   前記ベクタデータ変換工程は、前記白部もベクタデータに変換し、未完成であることを示す属性情報を付加することを特徴とする地図データ作成方法。

Images