OpenStreetMapデータモデルは地理情報を表現するパワフルでありながらシンプルな方法です。データモデルを理解することで、あなたはOpenStreetMapの生データを対話処理できるようになり、あなたの目的により役立つ形式に加工することができます。生のOpenStreetMapデータをアプリケーション内で利用する形式に変換するために、あるいは既存のソフトウェアツールの機能に飽き足らない場合、必要なマップ用エディタの作成に興味をお持ちなら、データモデルを理解したいと思うでしょう。
伝統的なGISではマップデータは3つの異なるやり方で表現されます：ポイントは座標で定義される空間上の単一の位置であり、線分は道路や境界を表わす線形のフィーチャーであり、ポリゴンは閉じたエリアです。これらの地理的なフィーチャーを書き表すデータは通常、二次的なデータベース内の補足として添付されます。OpenStreetMapでは、これら3つの概念は、各フィーチャーを表現する方法としてのタグを付けて、ノード、ウェイ、そしてリレーションとして抽出されています。この章では、これらコアなOpenStreetMapの概念をより詳細に議論します。
これは高度なトピックで、OpenStreetMapのデータを深く探求すると決めた場合、おそらく従来に無い何か面白いものを実装したり、現在のツールを改善するのに手助けとなるでしょう。タスクがマップデータの制御を低レベルで必要とするなら、静的なデータセットで作業したり、OSMデータ編集のために使われるライブREST APIのようなOpenStreetMap APIを操作したりする手助けとなるでしょう。REST APIについての詳細は、次のWikiページを参照。 http://wiki.openstreetmap.org/wiki/API_v0.6.
タグは"キーと値"の文字列のペアで、オプションとしてOpenStreetMap内の個々の地理要素に付加されます。これらのタグは、付加先のフィーチャーを説明し、スペースも含め最大255文字までの任意の文字列のペアであり、唯一の制限はひとつの要素内ではキーはユニークでなければならない、ということです。フィーチャーに関連するタグが無い場合、データのレンダリングはたいていその地物を表示しません。
地球上のポイントはノードと呼ばれ、緯度経度及び適切な数のタグで表現されます。例えば、ノードはお店、バス停、ベンチ、郵便ポストなどを表現するのに使われます。タグの無いノードは他の要素のサブ要素です。
ノードの並びはウェイと呼ばれます。ウェイは、ツールやユーザが操作しずらいとても大きな構造に圧倒されないように、最大2000ノードまでです。歩道、道路、鉄道、電力線などのような線形のフィーチャーを表わすのに使われます。
エリアは特別なデータタイプを持っていない、シンプルな閉じたウェイの一種で、最初のノードが最後のノードと同じものになります。建物の外周、公園、土地利用などを表現するのに使われます。
リレーションはノード、ウェイあるいはリレーションの並んだ一覧です。リレーションの各メンバーはそのサブ要素についての情報の付加的な一部を提供するオプションのロールを持っています。これらのロールは、タグ値に似た255文字長までの文字列です。リレーションは道路や自転車のルート、方向転換制限、行政界を表現でき、再び付加されたタグのセットに依存します。
リレーションはカテゴリではなく、単に物事をグループ化するために使うべきではないということに注意してください。物事をグループ化するのであればタグを使ってください。このトピックについてより詳細な情報はhttp://wiki.osm.org/wiki/Relations/Relations_are_not_Categoriesを参照してください。
上記3種のOpenStreetMapデータセット内の任意の要素は、ユニークな数値のIDにより識別されます。これらの数値には個々のフィーチャーの参照を許可する以外の目的はなく、特別な意味はありません。リレーションやウェイはこれらの識別子を使ってそのサブ要素を参照します。２つのウェイが接続されるのは、識別される座標を持つ２つのノードというより、同じノード識別子を参照している場合だけです。エリアを表すクローズドウェイは同じノードIDを２回参照する必要があります。
OpenStreetMapデータファイルは伝統的に、シンプルなスキーマでノード、ウェイ、リレーションの概念を表現するXML形式で配布されます。圧縮なしだと、このXML形式はとてつもなく大きくなりえるため、通常はgzipやbz2のような効率的な圧縮アルゴリズムを使って配布されます。OSM XMLデータ形式を扱えるように設計されたツールの多くは、圧縮されたXMLを操作できます。
サイズとXMLパース速度の問題を解決するために、GoogleのProtocol Buffersプロジェクトを使った別の形式が作成され、できる限りのOSMデータをバイナリーファイルにパックすることができます。いくつかの言語向けに、このファイル形式の読み込みを手助けするライブラリがあります。
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.