地理マークアップ言語

地理マークアップ言語

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

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

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

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

元の GML モデルは、World Wide Web Consortiumのリソース記述フレームワーク(RDF) に基づいていました。その後、OGC は、リレーショナル構造 XML スキーマをより簡単に定義できるさまざまな既存の地理データベースを接続するために、GML の構造にXML スキーマを導入しました。その結果、XML スキーマ ベースの GML には、子要素を親オブジェクトのプロパティとして扱うという考え方 (RDFS) や、リモート プロパティ参照の使用など、RDF の多くの機能が保持されています。

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

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

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

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

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

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 アプリケーション スキーマの一覧です。

• 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]
• 水質データ プロジェクトは、ニューサウスウェールズ州天然資源省のWayback Machineに 2008-07-21 にアーカイブされています。
• WXXM – 気象情報交換モデル
• IndoorGML – 屋内空間情報用のオープン データ モデルと XML スキーマの OGC 標準。

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

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:ポイント>  
     
 

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

GML 座標を XML DOM を通じてアクセス可能にするために、GML 3.0 では 要素<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:ポイント>  
      
 

ジオメトリ オブジェクトの座標は、次の要素<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 1 または GML 2 のみ (つまり、要素のみ)をサポートするGML データ サーバー ( WFS ) および変換ツールの場合、 に代わるものはありません。ただし、GML 3 以降のドキュメントの場合、 よりも およびが適しています。 <gml:coordinates><gml:coordinates><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コードの値は、石油ガス生産者協会が運営するEPSG測地パラメータデータセットレジストリ[1]を使用して解決できます。2020-08-09に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:ポリゴン> <gml:ポイント> <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>' オブジェクトです。残りの地理情報は、写真コレクション スキーマによって定義されます。

ロン・レイクは、ラジオ放送用の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の使用に焦点を当てていた。 Galdos は、1999 年 9 月の最初の OGC Web マップ テスト ベッドで、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プロファイル（2つはDTDベース、1つはRDFベース）が含まれ、そのうちの1つは静的スキーマアプローチを使用していました。これは、2000年5月にOGCで勧告文書として承認されました。^[14]

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 の基礎として確立されました。

これらのイベントが展開する一方で、日本では、河野茂氏の指揮のもと、日本データベース推進センターの支援のもと、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の交差点という重要な新しい展開が起こりました。

GML/G-XML 合意によって導入された新しいオブジェクトのほとんど、およびOGC プロセス内で Galdos によって導入された一部のオブジェクト(特にカバレッジ) には基本的なコーディングが存在していましたが、これらのエンコーディングのほとんどは、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 ) は、国際的な自主的な合意に基づく標準化団体であり、そのメンバーは地理マークアップ言語標準を維持しています。OGC は、ISO TC 211標準化団体と連携して、OGC と ISO の標準化作業の一貫性を維持しています。GML は、2007 年に国際標準 (ISO 19136:2007) として採用されました。

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

ISO 19136地理情報 - 地理マークアップ言語は、地理情報 (ISO 191xx) の標準規格であるISOファミリの標準です。これは、 Open Geospatial Consortium の定義と地理マークアップ言語 (GML) を ISO-191xx 標準規格と 統合して生まれました。

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

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

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

• ISO 19136:2007 - 地理情報 - 地理マークアップ言語 (GML)
• GML仕様