L1: XML und KML

Als wir uns mit Google Earth beschäftigt haben, konnten wir nach getaner Arbeit die erstellten Ortsmarkierungen, Pfade, Flächenmarkierungen, etc. in einer Datei abspeichern (diese Datei hatte die Endung KMZ). Die Datei kann später nicht nur über Google Earth, sondern auch über andere Geo-Tools eingelesen werden.

Es stellen sich auf Anhieb zwei Fragen: Wie kann ein Objekt (etwa eine Fläche) für ein Programm lesbar abgespeichert werden? Wie kann dies geschehen, wenn die Datei von mehreren unabhängig produzierten Tools eingelesen werden können soll?

Auf beide Fagen gibt es mehrere Antworten. Das Programm muss verstehen können, welche Informationen in einer Datei kodiert sind. Nehmen wir an, dass in einer Datei eine in Google Earth gezeichnete Fläche abgespeichert werden soll. Diese bestehe aus drei Punkten, die auf der Erde durch ihre Länge und Breite und ihre Höhe (über dem Meeresspiegel) eindeutig festgelegt sind. Die ProgrammentwicklerInnen fordern nun, dass eine solche Fläche in der Datei durch

Fläche( (12, 114, 14), (12, 114, 15), (13, 115, 16) )

repräsentiert ist. Dies ist möglich und sinnvoll.

Allerdings muss ein zweites Programm dann das gleiche Format benutzen, auch wenn die EntwicklerInnen des zweiten Programms lieber folgende Darstellung verwenden würden:

Fläche = [  Punkt[12, 114, 14], Punkt[12, 114, 15], Punkt[13, 115, 16] ];

Die zweite Darstellung lässt die LeserInnen erahnen, dass eine hierarchische Struktur in den Daten vorliegt, d.h., dass Objekte verschiedenen Typs geschachtelt werden.

In beiden Fällen muss natürlich eine Vielzahl verschiedener Objekte in einer Datei zugelassen sein, etwa Punkte, Polygonzüge und deren Attribute wie Farben, Schattierung, etc.

Regelwerke

Beiden Beschreibungen ist gemein, dass sie implizit ein Regelwerk angeben, demgemäß eine gültige Datei aufgebaut ist. Ein solches Regelwerk könnte folgendermaßen lauten:

  • Eine Koordinate ist eine Kommazahl (mit dem Dezimalpunkt als Komma).
  • Ein Punkt muss so angegeben werden: 'Punkt' '(' Koordinate',' Koordinate',' Koordinate ')'';'
  • Ein Dreieck muss so angegeben werden: 'Dreieck' '(' Punkt',' Punkt',' Punkt ')'';'

Man sieht, dass zwischen Zahlen und Zeichenketten, die zwischen Anführungszeichen stehen, und Elementen der Sprache wie Fläche unterschieden wird. Eine gültige Datei, die sich also an dieses Regelwerk hält, sieht etwa so aus:

Punkt ( 3.5, 2.5, 4.5 ); Dreieck ( Punkt ( 2.5, 1.5, 1.5 ); Punkt ( 2.5, 1.5, 1.5 ); Punkt ( 2.5, 1.5, 1.5 ); );

XML

Die Beschreibung unseres Regelwerks hat einige Schwächen: Wie könnte man ein Polygon definieren? Beachte, dass ein Polygon beliebig viele Punkte aufweisen kann. Die Beschreibung des Regelwerks bietet keine Möglichkeit, "beliebig viele" Punkte zuzulassen. Man müsste als für Dreieck, Viereck, Fünfeck, Sechseck, ... jede Regel einzeln aufschreiben.

In den letzten 25 Jahren hat sich, maßgeblich durch die Verbreitungs- und Austauschmöglichkeiten des Internets, XML entwickelt und verbreitet. XML ist ist eine Beschreibung für Regelwerke, d.h., eine Sprache, in der sich Regelwerke beschreiben lassen. Man nennt dies auch eine Metasprache. 

XML sieht vor, dass gültige Dokumente aus sogenannten (fast beliebig benannten) Elementen bestehen, die ineinander geschachtelt sein können. Die Elemente können (fast beliebig benannte) Eigenschaften aufweisen, die wiederum mit Werten belegt werden können.

Schema

Kommen wir zurück zu unserem GIS-Beispiel, bei dem im KMZ-Format Daten abgelegt werden. Beachte, dass das KMZ-Format lediglich aussagt, dass hier eine ZIP-komprimierte KML-Datei vorliegt. KML steht für Keyhole Markup Language, welche ein Regelwerk für KML-Dateien darstellt. Dieses Regelwerk heißt Schema und man findet es auf der OpenGIS-Webseite http://schemas.opengis.net/kml/2.2.0/ogckml22.xsd.

Wir greifen einen Teil des Schemas heraus:

<element name="Placemark" type="kml:PlacemarkType" substitutionGroup="kml:AbstractFeatureGroup"/>
<complexType name="PlacemarkType" final="#all">
<complexContent>
<extension base="kml:AbstractFeatureType">
<sequence>
<element ref="kml:AbstractGeometryGroup" minOccurs="0"/>
<element ref="kml:PlacemarkSimpleExtensionGroup" minOccurs="0" maxOccurs="unbounded"/>
<element ref="kml:PlacemarkObjectExtensionGroup" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>

Anhand des Ausschnitts lassen sich wesentliche Strukturen erkennen, die durch XML vorgegeben sind. Damit ein Text gültiges XML ist, muss er Elemente enthalten, die mit spitzen Klammern "geöffnet" und später wieder "geschlossen" werden - diese heißen Tags: Er besteht aus einem öffnenden <Tag ...> und einem schließenden </Tag>; sind in einem Tag keine weiteren Tags enthalten, kann der Tag auch durch <Tag /> geöffnet und gleich wieder geschlossene werden.

Wie angedeutet werden in einem Schema mehrere Elemente (hier z.B.: Placemark) definiert. Die Elemente haben Attribute, die nacheinander durch Attributname="Attributwert" in dem Tag angeführt werden.

Wir weisen noch einmal auf den Unterschied zwischen der Metasprache XML und einer konkreten Sprache KML hin: XML ist das Regelwerk, um eine beliebige Sprache, etwa KML, zu beschreiben. KML ist das Regelwerk, um gültige Geo-Daten zu beschreiben. Welche Tags in einem Schema vorkommen dürfen, wird durch XML festgelegt: Beispielsweise dürfen element, complexType, complexContent, sequence vorkommen. Welche Tags in einem KML-Dokument vorkommen dürfen, wird durch KML festgelegt, etwa Placemark.

Im obigen Ausschnitt hat ein Element die Attribute Name und Typ. Es wird ein Element namens Placemark definiert, welches vom Typ kml:PlacemarkType ist. Der Typ kml:PlacemarkType wird dann ab der zweiten Zeile spezifiziert. Durch den Tag sequence wird gefordert, dass innerhalb des Elements eine Folge von geschachtelten Elementen steht. Das Attribut minOccurs bzw. maxOccurs bei einem Element gibt an, wie oft dieses Element mindestens bzw. höchstens in dieser Folge erlaubt ist. Die erlaubten Elemente können vom Typ kml:AbstractGeometryGroup sein. Was für Elemente sind das nun konkret? 

Sehen wir weiter im Schema. Dort heißt es

<element name="Point" type="kml:PointType" substitutionGroup="kml:AbstractGeometryGroup"/>

sodass also der Point ein Element vom Typ kml:AbstractGeometryGroup ist. Wie genau ein Point auszusehen hat, wird ähnlich wie beim Placemark-Element durch den Typ beschrieben.

Betrachten wir ein fertiges KML-Dokument (aus https://de.wikipedia.org/wiki/Keyhole_Markup_Language):

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document>
  <Placemark>
    <name>Zürich</name>
    <description>Zürich</description>
    <Point>
      <coordinates>8.55,47.3666667,0</coordinates>
    </Point>
  </Placemark>
</Document>
</kml>

Die erste Zeile besagt, dass es sich um Dokument handelt, das der XML-Struktur gehorcht. Google Earth oder ein anderes Geo-Tool weiß nun, wie es mit der Datei umzugehen hat. In der zweiten Zeile steht, nach welchem Schema vorgegangen wird (welches Regelwerk auf die Datei also anzuwenden ist). In der dritten Zeile wird das Dokument geöffnet, welches aus mehreren Elementen bestehen kann. In diesem Dokument ist ein einziges Element enthalten, nämlich ein Placemark. Dieses besteht aus einem Punkt, der mit dem Namen Zürich bezeichnet und durch Koordinaten gegeben ist.

Zuletzt geändert: Sonntag, 30. Juli 2017, 15:58