Geography Markup Language (GML) is focused on the description of geographic content. It is not a presentation standard. GML entities (features) do not carry properties like line thickness or colour. GML relies on other languages and standards like KML, SVG for graphical presentation. GML was not developed to draw maps.
Galdos is one of the creators of GML, which is a specification of the Open Geospatial Consortium and a standard of the International Standards Organization (ISO). The current designations for these standards are:
- OGC – Version 3.2.1
- ISO TC/211 19136
GML was conceived and evolved for a variety of reasons, the most important being:
- To provide a language for expressing geographic entities – to create application specific geographic vocabularies.
- To enable the encoding of geographic information consistent with these vocabularies.
- To support geospatial queries and transactions across the Internet.
GML is feature centric. Features are entities – things that describe aspects of the real world from the perspective of a particular application community – whether circumscribed by geography or function or both. GML vocabularies are created by communities of interest. These vocabularies are called GML Application Schemas. If you look at such an Application Schema you will find real world objects like Buildings, Roads, Buoys, Navigation Aids, Airline Flight Paths, Vehicles and Railway Switches. Each such object is defined in the schema by listing its properties. For example, a Building might be described by:
Note that the Building (feature) has two properties, namely height and footprint. The height property in this case has an integer value (number of stories), while the footprint property has a Polygon (shape) for a value.
GML application schemas can be the basis of standards in themselves – such as S57GML, cityGML, geoRSS GML and AIXM, or they can be informal creations for only a very small community. Which is the case is up to the community.
GML application schemas should NOT be confused with GML profiles. A GML profile is a subset of GML, defined usually by the subset tool (part of the GML specification), consisting of selected element, attribute and type declarations and all dependent components from the GML core schemas (the schemas defined by the GML specification). Application schemas can be built on GML profiles. Some GML profiles are also specifications and this includes the GML Simple Features Profile, the Point Profile, the GML Profile for GMLJP2 and the GML Profile for GeoRSS.
GML was developed to support geographic requests and transactions and this usage predates the Web Feature Service (WFS) developed for this purpose. When you send a request for geographic data – e.g. “find all water wells within this county” – you need a means to express water well and county and the geometric extend of the county. In WFS you use GML for this purpose. When you wish to send a transaction such as “change the shape of the Holmes River to the following …” you need a way to express the river’s geometry and GML provides this mechanism in the WFS.
Much has been said about the apparent complexity of GML, most of which is based on the size of the specification. The reality is, however, somewhat different. The complexity and size of GML puts it only in the lower mid range according to a study of XML schema size and complexity conducted by Microsoft Research. In addition, it should be noted that the size of the GML specification is mostly due to the range of elements covered, rather than the complexity of the GML model. GML is complex like a phone book. It has lots of entries, because a wide range of primitive types (geometries, topology, reference systems, temporality, units of measure, dynamic behaviour) are required in modeling the world. On the other hand the model used in the GML encoding is quite simple – just an XML rendition of an extended Entity-Relationship diagram. GML application schemas are no more (or less) complex than you make them to be.
What is the GML Model?
How does GML encode geographic objects? As we noted in the strategic overview, GML describes real world entities (called features) by listing their properties and specifying the value type of those properties. It is in effect an XML encoding of an extended Entity-Relationship diagram that anyone working with databases will be familiar with. Consider the following simple example:
This would be encoded in GML something as follows:
Note that the remote reference (xlink:href) points to the associated object (River). Note that both attributes and associations are represented as GML feature properties.
The structure of GML encodings is defined by the Object-Property-Value model illustrated in the example above. This can be summarized simply as:
- The children of GML objects (e.g. features) are ALWAYS the properties of the object.
- The child (or children) of a property constitute the value of the property.
The structure of GML is thus:
where Value can be, in turn, another GML object.
Geometry in GML
GML is feature centric. This means we do not talk in GML about point or line features. Rather we say that a feature may have various characteristics some of which are geometric. A GML feature can have multiple such geometric characteristics. We can talk about the centerline of a road, or the edge of a road, or the extent of the road.
GML provides a rich set of geometric primitives from points to polygons to full 3D solids. You need only learn about the geometry elements you intend to use in your models. If you are only concerned with 2D mapping, then you will only need to look at the schema geometryBasic2D.xsd. If you want to build 3D city models or engineering structures, than you may need the entire geometry model.
Coordinates in GML
All GML geometries depend on the coordinates of control points as in the following simple examples:
The interpretation of the coordinate values (i.e. the numbers in the pos or posList elements) is determined by the value of srsName attribute. Note that it is specified by a URN. The URN (or URI) would typically designate the definition of the CRS. For example, the OGP (Oil and Gas Producer’s Association) provides an online registry of CRS at http://www.epsg-registry.org/ which can be used to resolve these URN’s. Note that it is NOT anticipated that software look up the URN each time the data is referenced. This reference is to provide an authoritative definition of the CRS that can be used by programmers. The service at http://www.epsg-registry.org/ is, however, a web service and can be accessed programmatically if desired.