GML File Documentation

Summary

A .gml file is a Geography Markup Language file: an XML format from the Open Geospatial Consortium for exchanging geographic (GIS) data such as points, lines, polygons, their coordinate reference system, and attributes. Standardised in 2000 and published as ISO 19136, its MIME type is application/gml+xml. Open it as a map in the free QGIS or read the raw XML in any text editor; handle large datasets with QGIS or the GDAL/OGR tools.

Technical details

FeatureValue
Full nameGeography Markup Language
File extension.gml
MIME typeapplication/gml+xml
DeveloperOpen Geospatial Consortium (OGC)
Introduced2000 (OGC); GML 3.2.1 = ISO 19136:2007
Standard / specOGC GML; ISO 19136
Open standardYes
Format typeXML-based geographic/GIS data (plain text)
Container / base formatXML 1.0
BinaryNo
Character encodingUTF-8 (declared in the XML prolog)
Typical start<?xml ?> then a namespace xmlns:gml="http://www.opengis.net/gml"
Geometry typesPoint, LineString, Polygon, plus Multi* aggregates and surfaces
Coordinate ref systemsYes — via srsName (e.g. EPSG:4326)
ValidationXML Schema (XSD); application schemas define feature types
Application profilesCityGML, AIXM, INSPIRE, GeoSciML
Used in web servicesWeb Feature Service (WFS) payloads
Free toolsQGIS, GDAL/OGR (ogr2ogr)
Related extensions.xml, .gpkg, .shp, .kml, .geojson, .osm
Common conversionsGML → Shapefile, GeoJSON, KML
Specification URLogc.org/standards/gml
Structure at a glance

GML is plain-text XML, so it has no binary magic number. A file opens with the XML prolog <?xml version="1.0" encoding="UTF-8"?> and a root element that declares the GML namespace, xmlns:gml="http://www.opengis.net/gml" (or /gml/3.2), alongside the dataset’s own application-schema namespace. Inside are feature members whose geometry is a <gml:Point>, <gml:LineString> or <gml:Polygon> carrying a <gml:posList> of coordinates and an srsName naming the coordinate reference system, e.g. srsName="urn:ogc:def:crs:EPSG::4326".

What is a GML file?

A .gml file is a Geography Markup Language document: an XML grammar for modelling, storing, and transporting geographic information. The Open Geospatial Consortium published GML in 2000, and the mature version (GML 3.2.1) is also an international standard, ISO 19136. Its purpose is vendor-neutral interchange of GIS data: instead of a proprietary binary, a feature’s geometry and attributes are written as tagged text that any conforming system can read. National mapping agencies, cadastral and land-registry systems, and the EU’s INSPIRE spatial-data directive all publish data as GML, so people most often meet a .gml when they download official map data and need to view or reuse it.

Because it is XML, a GML file is human-readable but verbose: geometry that a binary format packs into a few bytes becomes many lines of tagged coordinates. That trade-off (readability and interoperability, paid for in size) shapes everything about working with GML, from why you open large files in QGIS rather than Notepad to why the usual next step is converting to a more compact format. This article covers the parts a GML file is actually built from: features and their schema, the geometry primitives, the coordinate reference system and its axis-order trap, and the WFS services that emit GML.

Features, feature members and the application schema

The core concept in GML is the feature: a real-world thing (a building, a road segment, a parcel of land) with a geometry and a set of non-spatial properties. A GML dataset is typically a FeatureCollection containing many featureMember elements, each wrapping one feature.

<wfs:FeatureCollection xmlns:gml="http://www.opengis.net/gml/3.2"
                       xmlns:app="http://example.org/cadastre">
  <wfs:member>
    <app:Parcel gml:id="p.1042">
      <app:parcelId>1042</app:parcelId>
      <app:area uom="m2">523.8</app:area>
      <app:geometry>
        <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">...</gml:Polygon>
      </app:geometry>
    </app:Parcel>
  </wfs:member>
</wfs:FeatureCollection>

Two namespaces are at work. The gml: namespace (http://www.opengis.net/gml/3.2) provides the geometry and standard building blocks. The other, here app:, is the dataset’s own application schema: an XSD that defines what a Parcel is, which properties it must have, and their data types. This is the key to GML’s flexibility and its difficulty. GML does not define “parcel” or “building”; each community defines its own feature types in an application schema, and profiles like CityGML (3D city models), AIXM (aeronautical data), and INSPIRE’s themes are exactly such schemas. A generic reader can extract the geometry, but understanding the attributes fully requires the matching schema.

Geometry primitives and coordinate lists

GML expresses geometry with a set of primitives that map onto the familiar GIS types. The basic three are gml:Point, gml:LineString, and gml:Polygon, with aggregate forms gml:MultiPoint, gml:MultiCurve, and gml:MultiSurface for collections. Coordinates are carried as whitespace-separated numbers, either one position in a gml:pos or a whole run in a gml:posList.

<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
  <gml:exterior>
    <gml:LinearRing>
      <gml:posList>52.20 0.11  52.20 0.13  52.21 0.13  52.21 0.11  52.20 0.11</gml:posList>
    </gml:LinearRing>
  </gml:exterior>
</gml:Polygon>

A polygon is a boundary made of one gml:exterior ring plus zero or more gml:interior rings (holes). Each ring is a gml:LinearRing that must close, meaning its first and last positions are identical, as in the example above. The gml:posList flattens all the coordinate pairs into a single list; a reader splits them into positions using the dimensionality of the coordinate reference system. GML 3 also supports true curved segments (arcs, circles) that a format like GeoJSON cannot represent, which is one reason a faithful GML-to-GeoJSON conversion sometimes has to approximate curves as many short straight segments.

The coordinate reference system and the axis-order trap

Coordinates are meaningless without knowing which coordinate reference system (CRS) they are expressed in, and GML attaches that with the srsName attribute on a geometry (or on an enclosing envelope). The value is usually an EPSG code: EPSG:4326 is WGS 84 latitude/longitude, EPSG:3857 is the Web Mercator used by web tile maps, and national grids have their own codes. A reader uses the CRS both to place the data on the earth and to reproject it into whatever the target map uses.

The most infamous pitfall in GML is axis order. When the CRS is written in the modern URN form, srsName="urn:ogc:def:crs:EPSG::4326", the standard mandates the axis order defined by the CRS authority, and for EPSG:4326 that authority order is latitude then longitude, not the longitude-then-latitude order most developers assume from x/y and from GeoJSON. The older short form srsName="EPSG:4326" was widely treated as longitude/latitude. The result is that the same numbers can plot in the wrong hemisphere depending on which srsName form was used and how the reader interprets it, a real interoperability bug that GDAL exposes through the GML_INVERT_AXIS_ORDER_IF_LAT_LONG option. When a GML dataset appears to load “flipped” in QGIS, this is almost always why.

GML as the payload of a Web Feature Service

A large share of GML never exists as a file you downloaded deliberately; it arrives as the response body of a Web Feature Service (WFS). WFS is an OGC web protocol for querying vector features over HTTP, and its default response format is GML. A GetFeature request returns exactly the FeatureCollection structure shown above, which the client then draws or stores. This is why the GML you meet is often auto-generated by a server such as GeoServer or MapServer rather than hand-written, and why its application schema is discoverable through the service’s DescribeFeatureType operation. Understanding that GML is the on-the-wire format of WFS explains its verbosity: it was designed to be self-describing and schema-validated across organisational boundaries, not to be compact.

Reading, validating and reprojecting with GDAL/OGR and QGIS

The practical toolchain for GML is GDAL/OGR underneath and QGIS on top. The ogr2ogr command reads GML through GDAL’s GML driver and writes almost any vector format: ogr2ogr -f GeoJSON out.geojson in.gml for a web map, -f "ESRI Shapefile" out.shp in.gml for the classic Shapefile (which splits into .shp/.shx/.dbf and truncates field names to 10 characters), or -f KML out.kml in.gml to view in Google Earth. Reprojection happens in the same step with -t_srs EPSG:3857. Because GML is XML, it can also be schema-validated against its XSD, which catches structural errors before a GIS ever loads it. For very large files this XML nature is the main cost: a plain text editor chokes on a multi-gigabyte GML that GDAL streams feature by feature without holding the whole document in memory.

Other formats that use the .gml extension

The .gml extension is reused by unrelated formats. The most common collision is GameMaker Language, the scripting language of the GameMaker game engine; a .gml from GameMaker is plain source code, not XML, and opens in the GameMaker IDE or any code editor. A much older, now largely historical use is the Graphlet graph-drawing tool’s Graphscript. The quick test is the first line: a Geography Markup Language file starts with <?xml and declares the OGC GML namespace, whereas a GameMaker script is ordinary program text with no XML prolog.

Frequently asked questions

Why does my GML data appear in the wrong place after loading?

Almost always an axis-order mismatch. With the URN CRS form urn:ogc:def:crs:EPSG::4326 the standard requires latitude-then-longitude order, while many tools and the short EPSG:4326 form assume longitude-then-latitude. If coordinates plot flipped or in the wrong hemisphere, force the correct order (for example GDAL’s GML_INVERT_AXIS_ORDER_IF_LAT_LONG).

Why do I need the application schema to fully read a GML file?

GML defines the geometry vocabulary but not the feature types. A dataset’s own XSD application schema (CityGML, INSPIRE, or a custom one) defines what each feature is and which properties it carries. A generic reader can still pull out the geometry, but validating attributes and their data types requires that schema.

References