地理マークアップ言語

地理マークアップ言語
ポイント、ポリライン、ポリゴンを含むベクター マップ。
ファイル名拡張子.gmlまたは.xml
インターネットメディアの種類
アプリケーション/gml+xml [1]
開発者オープン地理空間コンソーシアム
初回リリース2000 （2000年）
最新リリース
3.2.1 [2]
2007年8月27日; 18年前 （2007年8月27日）
フォーマットの種類地理情報システム
延長からXML
標準ISO 19136:2007

地理マークアップ言語（GML）は、Open Geospatial Consortium （OGC）によって定義された、地理的特徴を表現するためのXML文法です。GMLは、地理システムのモデリング言語としてだけでなく、インターネット上での地理情報トランザクションのためのオープンな交換フォーマットとしても機能します。GMLの有用性の鍵は、従来の「ベクター」オブジェクトや個別オブジェクトだけでなく、カバレッジ（GMLJP2も参照）やセンサーデータなど、あらゆる形式の地理情報を統合できることです。

GMLモデル

GMLには、アプリケーション固有のスキーマやアプリケーション言語を構築するために使用できる豊富なプリミティブが含まれています。これらのプリミティブには以下が含まれます。

  • 特徴
  • 幾何学
  • 座標参照系
  • トポロジー
  • 時間
  • ダイナミック機能
  • 対象範囲（地理的画像を含む）
  • 測定単位
  • 方向
  • 観察
  • マップ表示のスタイルルール

オリジナルのGMLモデルは、ワールド・ワイド・ウェブ・コンソーシアム（OGC ）のリソース記述フレームワーク（RDF）に基づいていました。その後、OGCは、既存の様々な地理データベースを接続するため、GMLの構造にXMLスキーマを導入しました。地理データベースのリレーショナル構造はXMLスキーマによって容易に定義できます。その結果、XMLスキーマベースのGMLは、子要素を親オブジェクトのプロパティとして扱う（RDFS）という概念や、リモートプロパティ参照の使用など、RDFの多くの機能を保持しています。

プロフィール

GMLプロファイルはGMLに対する論理的な制約であり、ドキュメント、XMLスキーマ、またはその両方で表現できます。これらのプロファイルは、GMLの導入を簡素化し、標準の迅速な導入を促進することを目的としています。GML仕様で定義されている以下のプロファイルは、公開または一般利用のために提案されています。

  • 完全な GML 文法を必要としない、ポイント ジオメトリ データを使用するアプリケーション用のポイントプロファイル。
  • たとえばWFSを使用したベクター フィーチャのリクエストとトランザクションをサポートするGMLシンプル フィーチャ プロファイル。
  • GMLJP2用の GML プロファイル(JPEG 2000 の GML)。
  • RSS用の GML プロファイル。

プロファイルはアプリケーションスキーマとは異なります。プロファイルはGML名前空間（Open GIS GML）の一部であり、GMLの限定されたサブセットを定義します。アプリケーションスキーマは、GMLを使用して定義されたXMLボキャブラリであり、アプリケーション定義のターゲット名前空間に存在します。アプリケーションスキーマは、特定のGMLプロファイルに基づいて構築することも、完全なGMLスキーマセットを使用することもできます。

プロファイルは、多くの場合、商用航空、海図作成、リソース活用などの特定のアプリケーション ドメインをサポートするために作成された GML 派生言語 (アプリケーション スキーマを参照) をサポートするために作成されます。

GML 仕様 (GML v3 以降) には、GML プロファイルの構築に使用できる1 組のXSLTスクリプト (通常は「サブセット ツール」と呼ばれます) が含まれています。

GMLシンプルフィーチャプロファイル

GMLシンプル フィーチャ プロファイルは、上記のポイント プロファイルよりも完全な GML プロファイルであり、次のような幅広いベクター フィーチャ オブジェクトをサポートします。

  1. 0D、1D、2D の線形ジオメトリ オブジェクト (すべて線形補間に基づく) と対応する集約ジオメトリ (gml:MultiPoint、gml:MultiCurve など) を許可する縮小ジオメトリ モデル。
  2. 1 レベルの深さのみを持つ簡略化されたフィーチャ モデル (一般的な GML モデルでは、フィーチャおよびフィーチャ プロパティの任意のネストは許可されません)。
  3. すべての非幾何学的プロパティは XML スキーマの単純型である必要があります。つまり、ネストされた要素を含めることはできません。
  4. メインの GML 仕様と同様のリモート プロパティ値参照 (xlink:href)。

このプロファイルは単純なエントリ ポイントを提供することを目的としているため、次のものはサポートされません。

  • 補償範囲
  • トポロジー
  • 観察
  • 値オブジェクト（リアルタイムセンサーデータ用）
  • ダイナミック機能

それにもかかわらず、それは現実世界のさまざまな問題をサポートしています。

サブセットツール

さらに、GML仕様では、ユーザーが指定したコンポーネントリストを含むGMLプロファイルを生成するためのサブセットツールが提供されています。このツールは3つのXSLTスクリプトで構成されています。これらのスクリプトは、開発者が手動で拡張したり、スキーマ制限によって拡張したりできるプロファイルを生成します。完全なGML仕様の制約として、プロファイルが生成できるアプリケーションスキーマは、それ自体が有効なGMLアプリケーションスキーマである必要があります。

サブセットツールは、他にも様々な目的でプロファイルを生成できます。結果のプロファイルスキーマに含める要素と属性をリストし、ツールを実行すると、ユーザーが指定した項目と、指定した項目が依存するすべての要素、属性、および型宣言のみを含む単一のプロファイルスキーマファイルが生成されます。この方法で作成されたプロファイルスキーマの中には、IHO S-57やJPEG 2000のGML など、他の仕様をサポートするものもあります。

アプリケーションスキーマ

アプリケーションの地理データをGMLで公開するために、コミュニティまたは組織は、対象となるアプリケーションドメイン（アプリケーションスキーマ）に固有のXMLスキーマを作成します。このスキーマは、コミュニティが関心を持つデータを持つオブジェクトタイプと、コミュニティアプリケーションが公開する必要があるオブジェクトタイプを記述します。例えば、観光アプリケーションでは、記念碑、名所、博物館、道路の出口、展望台などのオブジェクトタイプをアプリケーションスキーマに定義できます。これらのオブジェクトタイプは、GML標準で定義されているプリミティブオブジェクトタイプを参照します。

地理情報用の他のマークアップ言語の中にはスキーマ構造を用いるものもありますが、GMLは新しいスキーマ言語を作成するのではなく、既存のXMLスキーマモデルを基盤としています。アプリケーションスキーマは通常、ISO 19103（地理情報 - 概念スキーマ言語）[3]に準拠したUMLを用いて設計され、その後、 ISO 19136の附属書Eに定められた規則に従ってGMLアプリケーションが作成されます。

公開 GML アプリケーション スキーマのリスト

以下は、既知の公開 GML アプリケーション スキーマの一覧です。

  • AIXM航空情報交換モデル（http://aixm.aero – 商用航空関連スキーマを参照）
  • CAAML – カナダ雪崩協会マークアップ言語
  • CityGML – 仮想3D都市/地域モデルのための共通情報モデルとGMLアプリケーションスキーマ。[4]
  • カバレッジ– ISO 19123の抽象モデルに基づいて、空間的および時間的に変化する現象（センサー、画像、モデル、統計データなど）のデジタル表現のための相互運用可能な、エンコード中立な情報モデル
  • 気候科学モデリング言語（CSML）[5]
  • Darwin Core GMLアプリケーションスキーマ。生物多様性発生データを共有するためのGMLにおけるDarwin Coreスキーマの実装。
  • GeoSciML – IUGS地球科学情報委員会より
  • GPML – GPlatesマークアップ言語、プレートテクトニクスの情報モデルとアプリケーションスキーマ[6]
  • InfraGML - 2012年に開始されたGML実装[7]。LandXMLの更新が欠落していたことを反映している。
  • INSPIREアプリケーションスキーマ[8]
  • IWXXM – 航空気象 GML アプリケーション スキーマ
  • NcML/GML – NetCDF-GML [9]
  • 観測メタデータと結果のための観測と測定スキーマ
  • OSマスターマップGML [10]
  • 計測機器と処理チェーンを記述するためのSensorMLスキーマ
  • 土壌と地形データを記述するためのSoTerMLスキーマ
  • TigerGML – 米国国勢調査[11]
  • 水質データプロジェクトは、ニューサウスウェールズ州天然資源省から2008年7月21日にWayback Machineにアーカイブされました。
  • WXXM – 気象情報交換モデル
  • IndoorGML – 屋内空間情報用のオープン データ モデルと XML スキーマの OGC 標準。

GMLとKML

Google によって普及したKMLは、GML を補完するものです。GML は、さまざまなアプリケーション オブジェクトとそのプロパティ (橋、道路、ブイ、車両など) を記述することで、あらゆるアプリケーションの地理コンテンツをエンコードする言語であるのに対し、KML は、Google Earthに合わせて地理情報を視覚化するための言語です。KML は GML コンテンツのレンダリングに使用でき、プレゼンテーションの目的で KML を使用して GML コンテンツを「スタイル設定」できます。KML は、まず第一に 3D 描写トランスポートであり、データ交換トランスポートではありません。この目的の大きな違いの結果として、KML を使用して描写用に GML コンテンツをエンコードすると、結果として得られる KML の構造とアイデンティティが大幅に失われ、回復できなくなります。GML の構造の 90% 以上 (メタデータ、座標参照システム、水平および垂直基準系、円、楕円、円弧の幾何学的整合性など) は、損失または非標準のエンコードなしで KML に変換することはできません。同様に、KMLは描写トランスポートとして設計されているため、KMLコンテンツをGMLでエンコードすると、領域、詳細レベルルール、表示およびアニメーション情報、スタイル情報、マルチスケール表現といったKMLの描写構造が大幅に失われます。複数の詳細レベルでプレースマークを描写できる機能は、KMLとGMLの違いです。なぜなら、描写機能はGMLの範囲外だからです。[12]

GMLジオメトリ

GMLは、地理オブジェクトのGMLジオメトリ（幾何学的特性）を「ベクター」モデルに従ってGMLドキュメント内の要素としてエンコードします。これらのオブジェクトのジオメトリは、例えば道路、河川、橋梁などを記述します。

GML 1.0 および GML 2.0 の主な GML ジオメトリ オブジェクト タイプは次のとおりです。

  • ポイント
  • ラインストリング
  • ポリゴン

GML 3.0 以降には、ほとんどの衛星データを含むリモート センサーや画像から収集された「カバレッジ」情報、つまり「ラスター」モデルを記述するための構造も含まれています。

特徴

GMLは、ジオメトリオブジェクトとは異なるフィーチャを定義します。フィーチャとは、建物、河川、人物など、物理的な実体を表すアプリケーションオブジェクトです。フィーチャは幾何学的な側面を持つ場合と持たない場合があります。ジオメトリオブジェクトは、物理的な実体ではなく、位置や領域を定義するため、フィーチャとは異なります。

GMLでは、フィーチャは、フィーチャの幾何学的な側面や特性を記述する様々なジオメトリプロパティ（例：ポイントプロパティやエクステントプロパティ）を持つことができます。GMLでは、共有ジオメトリプロパティへのリモートプロパティ参照を使用することで、フィーチャ間でジオメトリプロパティを共有する機能も提供されています。リモートプロパティは、RDFから借用されたGMLの一般的な機能です。GMLジオメトリプロパティのxlink:href属性は、そのプロパティの値がリンクで参照されているリソースであることを意味します。

例えば、特定のGMLアプリケーションスキーマにおけるBuildingフィーチャの位置は、プリミティブGMLジオメトリオブジェクト型Pointによって指定される場合があります。ただし、Building は、その位置を定義するPointとは別のエンティティです。さらに、フィーチャは、範囲や位置など、複数のジオメトリプロパティを持つ場合もあれば、全く持たない場合もあります。

座標

GMLにおける座標は、ジオメトリオブジェクトの座標を表します。座標は、以下のGML要素のいずれかで指定できます。

 <gml:座標> <gml:pos> <gml:posList>

GMLには座標を表現する複数の方法があります。例えば、<gml:coordinates>要素は次のように使用できます。

 <gml:Point gml:id= "p21" srsName= "http://www.opengis.net/def/crs/EPSG/0/4326" > <gml:座標> 45.67、88.56 </gml:座標> < / gml:Point>

上記のように表現すると、要素の内容が単一の文字列である ため、個々の座標 (例: 88.56 ) はXML ドキュメント オブジェクト モデルを通じて個別にアクセスできません。<gml:coordinates>

GML 3.0 では、XML DOM を介して GML 座標にアクセスできるようにするために、 要素<gml:pos>と<gml:posList>要素が導入されました。(GML バージョン 1 および 2 にも<gml:coord>要素はありましたが、欠陥として扱われているため使用されていません。)要素<gml:pos>の代わりに 要素を使用すると<gml:coordinates>、同じ点を次のように表現できます。

 <gml:Point gml:id= "p21" srsName= "http://www.opengis.net/def/crs/EPSG/0/4326" > <gml:pos srsDimension= "2" > 4​​5.67 88.56 </gml:pos> </gml:Point>

ジオメトリ オブジェクトの座標は、<gml:LineString>次の要素で表すことができます<gml:coordinates>。

 <gml:LineString gml:id= "p21" srsName= "http://www.opengis.net/def/crs/EPSG/0/4326" > <gml:coordinates> 45.67, 88.56 55.56,89.44 </gml:coordinates> </gml:LineString >

この<gml:posList>要素は、線形ジオメトリに必要な座標タプルのリストを表すために使用されます。

 <gml:LineString gml:id= "p21" srsName= "http://www.opengis.net/def/crs/EPSG/0/4326" > <gml:posList srsDimension= "2" > 4​​5.67 88.56 55.56 89.44 </gml:posList> </gml:LineString >

GML データ サーバー ( WFS ) および GML 1 または GML 2 (つまり<gml:coordinates>要素のみ) のみをサポートする変換ツールの場合、 に代わるものはありません<gml:coordinates>。ただし、GML 3 以降のドキュメントの場合は、 より<gml:pos>も および<gml:posList>が推奨されます<gml:coordinates>。

座標参照系

座標参照システム(CRS) は、GML ドキュメント内の各ジオメトリ要素のジオメトリを決定します。

KMLやGeoRSSとは異なり、GMLでは座標系が指定されていない場合、デフォルトでその座標系が使用されることはありません。代わりに、CRSを使用して必要な座標系を明示的に指定する必要があります。このようなCRSに基づいて座標が解釈される要素には、以下のものがあります。

  • <gml:coordinates>
  • <gml:pos>
  • <gml:posList>

ジオメトリ オブジェクトにアタッチされた srsName属性は、次の例に示すように、オブジェクトの CRS を指定します。

 <gml:Point gml:id= "p1" srsName= "#srs36" > <gml:座標> 100,200 </gml:座標> </gml:Point>

srsName属性の値は、 Uniform Resource Identifier（URI）です。これは、ジオメトリ内の座標を解釈するために使用されるCRSの定義を参照します。CRS定義は、ドキュメント（フラットファイルなど）またはオンラインWebサービス内に存在する場合があります。EPSGコードの値は、石油ガス生産者協会（Oil and Gas Producers Association）が運営するEPSG測地パラメータデータセットレジストリ（[1] Archived 2020-08-09 at the Wayback Machine ）を使用して解決できます。

srsName URIは、共通のCRS定義を参照するためのUniform Resource Name (URN) としても使用できます。OGCは、いくつかの共通CRSをエンコードするためのURN構造と特定のURNセットを開発しました。URNリゾルバは、これらのURNをGML CRS定義に解決します。

例

Polygons、Points、およびLineStringオブジェクトは、GML 1.0 および 2.0 では次のようにエンコードされます。

 <gml:ポリゴン> <gml:outerBoundaryIs> <gml:LinearRing> <gml:座標> 0,0 100,0 100,100 0,100 0,0 </gml:座標> </gml:LinearRing> </gml:outerBoundaryIs> </gml:Polygon> <gml:Point> <gml:座標> 100,200 </gml:座標> </gml:Point> <gml:LineString> <gml:座標> 100,200 150,300 </gml:座標> </gml:LineString>

LineStringオブジェクトは、 LinearRingオブジェクトと同様に、指定された点間の線形補間を前提としています。また、Polygonの座標は閉じている必要があります。

ジオメトリを使用したフィーチャ

次のGMLの例は、フィーチャとジオメトリオブジェクトの違いを示しています。Buildingフィーチャには複数のジオメトリオブジェクトがあり、そのうちの1つ（識別子p21のPoint）をSurveyMonumentフィーチャと共有しています。

 <abc:Building gml:id= "シアーズタワー" > <abc:height> 52 </abc:height> <abc:position xlink:type= "Simple" xlink:href= "#p21" /> </abc:Building> <abc:SurveyMonument gml:id= "g234" > <abc:position> <gml:Point gml:id= "p21" > <gml:posList> 100,200 </gml:posList> </gml:Point> </abc:position> </abc:SurveyMonument>

どのフィーチャオブジェクトも複数のジオメトリ オブジェクトプロパティ を持つことができるため、参照はSurveyMonumentではなく共有Pointに対して行われます。

ポイントプロファイル

GMLポイントプロファイルには、単一のGMLジオメトリ、つまりオブジェクト型が含まれます。任意のXMLスキーマは、ポイントプロファイルをインポートし、サブジェクトインスタンスを参照することで<gml:Point>使用できます。<gml:Point>

 <PhotoCollection xmlns= "http://www.myphotos.org" xmlns:gml= "http://www.opengis.net/gml" xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "http://www.myphotos.org  MyGoodPhotos.xsd" > <items> <Item> <name> Lynn Valley </name> <description>吊り橋から見た滝のショット</description> <where> North Vancouver </where> <position> < gml :Point srsDimension= "2" srsName= "http://www.opengis.net/def/crs/EPSG/0/4326" > < gml:pos> 49.40 -123.26 </gml:pos> </gml:Point> </position> </Item> </items> </写真コレクション>

ポイントプロファイルを使用する場合、ジオメトリオブジェクトは '<gml:Point>' オブジェクトのみとなります。残りの地理情報は写真コレクションスキーマによって定義されます。

歴史

初期作業 – OGC勧告文書まで

ロン・レイクは、ラジオ放送用のXMLエンコーディングの研究に続いて、1998年秋にGMLの研究を始めた。レイクは、1999年2月にジョージア州アトランタで開催されたOGC会議で、xGMLというタイトルで彼の初期のアイデアを発表した。これは、GeoDOMのアイデアと、XSLに基づいた地理スタイリング言語（GSL）の概念を紹介した。NTTデータの中井明文も、同じ会議で、NTTデータで部分的に進行中の、位置情報サービスを対象としたG-XMLと呼ばれるXMLエンコーディングの研究を発表した。[13] 1999年4月、ガルドスは、CubeWerx、 Oracle Corporation、MapInfo Corporation、NTTデータ、三菱電機、Compusultを下請けとして 、XBedチームを結成した。Xbedは、地理空間でのXMLの使用に焦点を合わせた。これが、ガルドス、米国国勢調査局、NTTデータからの入力によるSFXML（Simple Features XML）の作成につながった。 Galdos Systemsは、1999年9月に開催された最初のOGC Web Map Test Bedにおいて、Oracleベースの「GML」データサーバー（WFSの前身）からデータを取得する初期のマップスタイルエンジンを実演しました。1999年10月、Galdos SystemsはSFXMLの草案文書をRequest for Comment（意見募集）に書き直し、言語名称をGML（Geography Markup Language）に変更しました。この文書では、1) オブジェクト-プロパティ-値ルール、2) リモートプロパティ（rdf:resource経由）、3) 静的スキーマセットではなくアプリケーションスキーマを使用するという決定など、GMLの基礎となるいくつかの重要なアイデアが紹介されました。また、この文書では、言語をそれまで使用されていたDTDではなく、リソース記述フレームワーク（RDF）に基づくものと提案されました。 RDFの利用を含むこれらの問題は、1999年から2000年にかけてOGCコミュニティ内で激しい議論を交わし、最終的なGML勧告文書には3つのGMLプロファイル（DTDベースが2つ、RDFベースが1つ）が含まれ、そのうち1つのDTDは静的スキーマアプローチを採用していました。これは2000年5月にOGCで勧告文書として承認されました。[14]

XML スキーマ バージョン 2 への移行。

OGCで勧告書が可決される以前から、GaldosはGMLのXMLスキーマ版の開発に着手しており、リモート参照用のrdf:resourceスキームをxlink:hrefの使用に置き換え、フィーチャコレクションのような複雑な構造の拡張を扱うための特定のパターン（例：Barbarians at the Gate）を開発していました。XMLスキーマ設計作業の多くは、GaldosのRichard Martell氏によって行われました。Martell氏はドキュメント編集者として、基本的なGMLモデルをXMLスキーマに変換する主な責任者でした。この時期の他の重要な貢献は、Simon Cox氏（CSIRO Australia）、Paul Daisey氏（米国国勢調査局）、David Burggraf氏（Galdos）、Adrian Cuthbert氏（Laser-Scan）から寄せられました。米国陸軍工兵隊（特にJeff Harrison氏）はGMLの開発を強く支持しました。米国陸軍工兵隊は「USLパイロット」プロジェクトを後援しました。このプロジェクトは、GML仕様におけるリンクとスタイルの概念の有用性を探る上で非常に役立ち、Monie (Ionic) と Xia Li (Galdos) による重要な作業が行われました。XMLスキーマ仕様の草案はGaldosによって提出され、2000年12月に一般公開が承認されました。これは2001年2月に勧告文書となり、同年5月に採択仕様となりました。このバージョン（V2.0）では、バージョン1から「プロファイル」が削除され、Galdosの最初の提案で概説された主要原則がGMLの基礎として確立されました。

GMLとG-XML（日本）

これらの出来事が展開する一方で、日本では河野茂氏の指導の下、日本データベース推進センターの支援のもと、G-XMLの開発が並行して進められていました。G-XMLとGMLにはいくつかの重要な点で違いがありました。LBSアプリケーションをターゲットとしたG-XMLは、多くの具体的な地理オブジェクト（Mover、POIなど）を採用していましたが、GMLはごく限られた具体的なオブジェクトセットを提供し、アプリケーションスキーマを用いることでより複雑なオブジェクトを構築していました。当時、G-XMLはまだDTDを用いて記述されていましたが、GMLは既にXMLスキーマに移行していました。一方で、G-XMLでは、時間性、識別子による空間参照、履歴を持つオブジェクト、トポロジベースのスタイリングといった、当時のGML語彙集にはなかった多くの基本的な構成要素を必要としていました。一方、GMLは、限られたプリミティブセット（ジオメトリ、フィーチャ）と、ユーザ定義のオブジェクト（フィーチャ）型を構築するためのレシピを提供していました。

2001 年 1 月に東京で開催された一連の会議には、Ron Lake (Galdos)、Richard Martell (Galdos)、OGC スタッフ (Kurt Buehler、David Schell)、Shige Kawano (DPC)、Akifumi Nakai (NTT Data)、および Shimada (Hitachi CRL) が参加し、DPC と OGC の間で MOU が締結されました。この MOU により、OGC は G-XML をサポートするために必要な基本要素を GML に注入し、G-XML を GML アプリケーション スキーマとして記述できるように努めることになりました。この結果、観測、動的フィーチャ、時間オブジェクト、デフォルト スタイル、トポロジ、およびビューポイントを含む多くの新しいタイプが GML のコア オブジェクト リストに追加されました。作業の多くは、NTT データとの契約に基づいて Galdos によって実施されました。これにより GML 3 の基礎が築かれましたが、この期間に OGC とISO/TC 211の交わりという重要な新しい展開が起こりました。

ISOに向けて – GML 3.0はGMLの範囲を拡大します

GML/G-XML 合意によって導入された新しいオブジェクトのほとんど、および Galdos によってOGC プロセス内で導入された一部のオブジェクト (特にカバレッジ) には基本的なコーディングが存在していましたが、これらのエンコーディングのほとんどは ISO TC/211 によって開発された抽象仕様に準拠していないことがすぐに明らかになりました。この仕様は、すべての OGC 仕様の基礎になりつつありました。たとえば、GML ジオメトリは、以前の部分的にしか文書化されていないジオメトリ モデル (シンプル フィーチャ ジオメトリ) に基づいていましたが、TC/211 で説明されているより広範で複雑なジオメトリをサポートするには不十分でした。この期間中に GML 開発の管理も変更され、より多くの個人の参加が得られました。この期間中の重要な貢献は、Milan Trninic (Galdos) (デフォルト スタイル、CRS)、Ron Lake (Galdos) (観測)、Richard Martell (Galdos) (動的フィーチャ) によって行われました。

2002年6月12日、ロン・レイク氏はGML作成における功績が認められ、OGCからガーデルズ賞を受賞しました。[15]受賞理由には、「特に、この賞は地理マークアップ言語（GML）の作成における偉大な業績と、国家間の差異の調和を促進し、世界レベルでGMLの意義ある標準化を推進するための、他に類を見ない繊細さと効果的な取り組みを表彰するものです」と書かれています。その後、サイモン・コックス氏（CSIRO）[16]とクレメンス・ポルテレ氏（Interactive Instruments）[17]もGMLへの貢献によりガーデルズ賞を受賞しました。

標準

Open Geospatial Consortium（OGC）は、国際的な自主的なコンセンサス標準化団体であり、そのメンバーは地理マークアップ言語（GML）標準の維持管理を行っています。OGCは、 ISO TC 211標準化団体と連携し、OGCとISOの標準化活動間の整合性を維持しています。GMLは2007年に国際標準（ISO 19136:2007）として採択されました。

GML は、米国の国家情報交換モデル(NIEM)バージョン 2.1 にも含めることができます(説明が必要)。

ISO 19136

ISO 19136地理情報 - 地理マークアップ言語は、地理情報標準規格群（ISO 191xx）に属する規格です。これは、Open Geospatial Consortium の定義と地理マークアップ言語 (GML) を ISO-191xx 標準規格に統合することで実現しました。

GMLの以前のバージョンは、GMLバージョン3.1.1ではISO準拠ではありませんでした（GML 1、GML 2）。ISO準拠とは、GMLがISO 19107の実装でもあることを意味します。

地理マークアップ言語（GML）は、ISO 19118に準拠したXMLエンコーディングであり、 ISO 19100シリーズで使用される概念モデリングフレームワークに従ってモデル化された地理情報の転送および保存を目的としています。地理情報には、地理地物の空間的特性と非空間的特性の両方が含まれます。この仕様は、以下の事項を実現するXMLスキーマ構文、メカニズム、および規則を定義します。

  • 地理空間アプリケーションのスキーマとオブジェクトの定義のためのオープンでベンダー中立なフレームワークを提供します。
  • GML フレームワークの記述機能の適切なサブセットをサポートするプロファイルを許可します。
  • 専門分野および情報コミュニティ向けの地理空間アプリケーション スキーマの記述をサポートします。
  • リンクされた地理アプリケーション スキーマとデータセットの作成と保守を有効にします。
  • アプリケーション スキーマとデータ セットの保存と転送をサポートします。
  • 組織が地理的アプリケーション スキーマとそれが記述する情報を共有する能力を高めます。

参照

参考文献

  1. ^ Open Geospatial Consortium Inc. (2010-02-08)、技術委員会のポリシーと手順: GML の MIME メディアタイプ(PDF)
  2. ^ 「OpenGIS Geography Markup Language (GML) Encoding Standard」. 2011年3月25日閲覧。
  3. ^ 「ISO 19103:2015」。
  4. ^ “CityGMLホームページ”. 2013年2月1日時点のオリジナルよりアーカイブ。2018年6月18日閲覧。
  5. ^ 「気候科学モデリング言語 - CSML」。2015年6月13日時点のオリジナルよりアーカイブ。2018年6月18日閲覧。
  6. ^ 「GPlates 地質情報モデル: リソースページ」。
  7. ^ 「ニュース」.
  8. ^ 「/schemas のインデックス」。inspire.ec.europa.eu。
  9. ^ “NetCDF in XML”. 2010年3月23日時点のオリジナルよりアーカイブ。2007年4月10日閲覧。
  10. ^ 「OS MasterMap – GML（地理マークアップ言語）の説明」。2013年5月5日時点のオリジナルよりアーカイブ。2011年10月12日閲覧。
  11. ^ 「位置情報技術の革新とコラボレーションの本拠地 | OGC」。
  12. ^ 「KMLリファレンス | Keyhole Markup Language」。Google Developers。
  13. ^ “G-XML”. 2009年12月17日時点のオリジナルよりアーカイブ。
  14. ^ 「JPEG 2000 地理画像用 GML (GMLJP2) エンコーディング仕様」。
  15. ^ 「ロン・レイクの受賞状」.
  16. ^ 「サイモン・コックスの受賞状」.
  17. ^ 「クレメンス・ポルテレの受賞理由」.
  • ISO 19136:2007 - 地理情報 - 地理マークアップ言語 (GML)
  • GML仕様
「https://en.wikipedia.org/w/index.php?title=Geography_Markup_Language&oldid=1294208745」より取得