JA:OSM XML

From OpenStreetMap Wiki
Jump to navigation Jump to search
OSM XML - Other languages

基本

XMLは人間が読めるデータ交換フォーマットを提供するための、いわゆるメタ フォーマットです。 XHTML、SVG、ODTなどさまざまなファイル フォーマットでは、このデータツリー構造を使ってそれぞれのデータを埋め込みます。

長所 短所
  • 明解な構造のため、人間が読める
  • 文字コード、 XML スキーマ定義、 DTD、 名前空間など、厳密な定義があるので処理環境に依存しない
  • 汎用的なXMLのためのパーサーが利用でき、それぞれの具体的なファイル フォーマット向けにカスタマイズできる
  • 圧縮率が良い
  • 伸長すると非常に大きなファイルになる
  • 処理する前にはおそらく伸長する必要がある(データの圧縮/伸長は HTTPのような転送プロトコルによって、その場で行われる可能性がある)
  • 解析に巨大な時間とメモリを消費する可能性があるが、それはXMLの機能をフル活用した場合である。しかし、基本的なXML(DTDや名前空間を使わないもの)は、XMLドキュメント全体をDOM処理しなければとても高速で効率的です(例えば、シンプルなSAXパーサーを利用する場合など)

OSM XMLファイル フォーマットについて

公式の.xsdスキーマはありません。XSDやDTDによりフォーマットを定義しようとする非公式の試みについて、詳しくは以下及びOSM XML/XSDとOSM XML/DTDのページを参照してください。

OSM界隈の主なツールは、当初APIのみで使われていた以下のXMLスキーマ定義に従うXMLフォーマットを使います。基本的にこれはデータ要素(ノード、ウェイ、リレーション)のリストです。

OSM XML ファイルの例

以下のものは完全なOSM XMLファイルを短縮した例です。すべての OSM XML ファイルにこれらの要素の種類が含まれているわけではありません。以下の備考を参照してください。 

<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="CGImap 0.0.2">
 <bounds minlat="54.0889580" minlon="12.2487570" maxlat="54.0913900" maxlon="12.2524800"/>
 <node id="298884269" lat="54.0901746" lon="12.2482632" user="SvenHRO" uid="46882" visible="true" version="1" changeset="676636" timestamp="2008-09-21T21:37:45Z"/>
 <node id="261728686" lat="54.0906309" lon="12.2441924" user="PikoWinter" uid="36744" visible="true" version="1" changeset="323878" timestamp="2008-05-03T13:39:23Z"/>
 <node id="1831881213" version="1" changeset="12370172" lat="54.0900666" lon="12.2539381" user="lafkor" uid="75625" visible="true" timestamp="2012-07-20T09:43:19Z">
  <tag k="name" v="Neu Broderstorf"/>
  <tag k="traffic_sign" v="city_limit"/>
 </node>
 ...
 <node id="298884272" lat="54.0901447" lon="12.2516513" user="SvenHRO" uid="46882" visible="true" version="1" changeset="676636" timestamp="2008-09-21T21:37:45Z"/>
 <way id="26659127" user="Masch" uid="55988" visible="true" version="5" changeset="4142606" timestamp="2010-03-16T11:47:08Z">
  <nd ref="292403538"/>
  <nd ref="298884289"/>
  ...
  <nd ref="261728686"/>
  <tag k="highway" v="unclassified"/>
  <tag k="name" v="Pastower Straße"/>
 </way>
 <relation id="56688" user="kmvar" uid="56190" visible="true" version="28" changeset="6947637" timestamp="2011-01-12T14:23:49Z">
  <member type="node" ref="294942404" role=""/>
  ...
  <member type="node" ref="364933006" role=""/>
  <member type="way" ref="4579143" role=""/>
  ...
  <member type="node" ref="249673494" role=""/>
  <tag k="name" v="Küstenbus Linie 123"/>
  <tag k="network" v="VVW"/>
  <tag k="operator" v="Regionalverkehr Küste"/>
  <tag k="ref" v="123"/>
  <tag k="route" v="bus"/>
  <tag k="type" v="route"/>
 </relation>
 ...
</osm>

オブジェクトのカテゴリの詳細は、データ要素を参照して下さい。
どのように現実の世界のものがモデル化されて分類されるかについては、JA:Map Featuresを参照して下さい。

内容

  • そのファイルにUTF-8文字エンコーディングを導入するためのXML宣言
  • osmエレメント。APIのバージョン(即ち使われている機能)と、このファイルを作成したジェネレータ(例えばエディタツールの一つ)を含む。
    • ノード ブロック。特にWGS84参照系での位置を含む。
      • 各ノードのタグ
    • ウェイ ブロック
      • 各ウェイごとに、そのノードへの参照
      • 各ウェイのタグ
    • リレーション ブロック
      • 各リレーションごとに、そのメンバーへの参照
      • 各リレーションのタグ

確かなこと、不確かなこと

このフォーマットを扱うツールを開発するとき、以下は確実であると前提できます:

  • ブロックが上記の順序で表れること
  • APIとJOSMのデータの範囲内であること

以下のことは確実とは限りません:

  • あるブロックが存在すること (例えばノードのみ、ウェイ無しなど)
  • ブロックがソートされていること
  • 要素のIDが非負であること (すべてのomsファイルにおいてではありません。負のIDはエディタが新規要素のために使います)
  • 要素がタグを持つこと (持たないことも多くあります。タグも無く孤立しているノードであることさえあるでしょう。)
  • visibleはfalseの場合のみ表れること、またPlanet.osm内には無いこと
  • idまたはuser nameがあること (必ずあるとは限りません。ごく初期の匿名の編集のため)
  • 変更セットがnum_changes属性を持つこと (不整合が起きるため履歴エクスポート ツールから削除されました)
  • バージョンが連続して並ぶこと (その必要はありません)

JOSMでは新規オブジェクトに対して、タイムスタンプ、バージョン、変更セットの代わりに'action'属性を使います。

いくつかの変種では他にも制約があるかも知れません。

ツール

Planet.osm、インポート、エクスポート, 変換を参照してください。

変種

現在いくつかの異なるファイル フォーマットが使われており、それぞれ微妙に異なる目的を持っています。

JOSMファイル フォーマット

主な記事：JOSM file format

JOSMの作者によりファイル フォーマットが設計されました。基本的にはサーバーから送られるデータの論理的な拡張です。追加されるのはデータの出所の表示と、取り出された外接矩形(可能なら)です。ダウンロードされたデータだけでなくユーザーによる変更内容も保存するフォーマットです。

長所 短所
  • プレースホルダーをサポートする
  • データのソースを表す
  • ストリームとして扱えず、適用する前に全体を読まなければならない

サポートしているのは:

osmChange

主な記事：OsmChange

OsmChangeはosmosisの作者により作られたファイル フォーマットで、編集内容を表すためのより一般的なフォーマットです。

長所 短所
  • ストリーム可能

適切に保存されていれば、順番に再生可能な変更の連続的なストリームとなります。osmosisでは--sort-changeオプションにより変更をストリーム可能な順序にすることができます。

  • データのソースを表さない

プレースホルダーは拡張として提案されていますが、広くサポートされていません。

サポートしているのは:

変更フォーマットの技術的な特性

変更セットのような変更を表現するファイル フォーマットの望まれることの一覧です。

プレースホルダー

プレースホルダーは、ファイル内で生成されるオブジェクトが、それに依存して作られる別のオブジェクトの中で利用できるようにする機能です。1つのファイルで、新たな2つのノードとそれをつなぐ線分を、それらの最終的なIDが分からなくても作成することができます。

プレースホルダーを持つオブジェクトは、バージョン番号や作成日時、ユーザーIDや対応する変更セットを持ちません。(それらのプロパティはサーバーによりセットされ、コンフリクトしたり同期に失敗したりした変更を検出して報告するために使われます)

プレースホルダーのIDは負の整数でなければならず、任意に割り当て可能ですが、そのスコープは、データが作成されるサーバーに送られる1つのデータ ファイルの中に限られます。データが正しく作成された後、サーバーは作成に成功したプレースホルダに対応する各オブジェクトに、正の値として割り当てられた最終的なIDを返します。(初期バージョン番号、作成日時、それらが作成された変更セットのIDも返されます) 従って、クライアントは最終的なIDに置き換えて、その後のリクエストで同じオブジェクトを参照するために使うことができます。

出所の表示

OSMファイルの中のIDは、サーバー間で共有されません。IDはクライアントでなくサーバーで割り当てられます。従って変更ファイルが、ファイル内で使われているIDのソースを示すことは有用です。

ストリーム可能

参照の完全性を損なうことなく、ファイルがストリームとして処理できるかどうか。

関連項目

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=JA:OSM_XML&oldid=1331899"