Über unsMediaKontaktImpressum
Elena Bochkor & Dr. Veikko Krypczyk 19. Juli 2022

Komponentengestützte Softwareentwicklung für die Nutzung von Kartendiensten

Viele moderne Anwendungen sind auf die intensive Nutzung von Kartendiensten angewiesen. Wie gelange ich von A nach B? Was ist die kürzeste Route? Welchen Weg soll ich nehmen, um Staus zu umgehen? In welcher Region sind meine Kunden vertreten? Wie groß ist der Wirkungsradius des Vertriebsteams? Graphische Darstellungen mit Hilfe von Karten sind gefragt. Dabei gibt es unterschiedliche Kartendienste. Mit einer passenden Komponente bekommt man alle Anforderungen, Dienste und die technischen Hürden simultan in den Griff.

Geographische Daten werden für eine Vielzahl von Anwendungen benötigt und verarbeitet. Geoinformationssysteme (GIS) ermöglichen eine Erfassung, Speicherung und die Analyse von räumlichen Daten. Gegenüber herkömmlichen Informationssystemen sind GIS auf die Arbeit mit Geodaten spezialisiert. Mit Hilfe von Karten werden statische und sich dynamisch ändernde Sachverhalte auf der Basis von Daten abgebildet. Die Darstellungen geographischer Gegebenheiten lassen sich beispielsweise in die Kategorien: Orte, Wege und Regionen zuordnen. Beispiele aus den Bereichen sind:

  • Orte: Ein Unternehmen stellt die Standorte seiner Filialen in einer Karte dar und reichert die Abbildung mit aktuellen Verkaufszahlen an.
  • Wege: Ein Logistikunternehmen errechnet kostenminimale Wege zwischen einem zentralen Depot und den Auslieferungslagern. Die geplanten Routen variieren je nach Auftragslage, Verkehrssituation usw. Zur besseren Veranschaulichung werden die Routen in die Karte eingezeichnet und bei Änderungen ad hoc aktualisiert.
  • Regionen: Zur Optimierung des Vertriebs werden Regionen in Bezug auf einen Standort, zum Beispiel unter Berücksichtigung der Verkehrswege und der Bevölkerungsdichte, ermittelt und in einer Karte eingezeichnet. Auf diese Weise können "weiße Flecken" und Überschneidungen bei der Vertriebszuordnung weitgehend vermieden werden.

Die Komponenten eines GIS lassen sich typischerweise in drei Ebenen unterteilen (s. Abb. 1) [1]:

  • Dateneingabe: Hier werden alle Daten, welche für die Analyse notwendig sind, eingespeist. Das sind zum einen Daten über die Geographie (Karten, Geodaten, …), als auch die Daten über den zu analysierenden Sachverhalt, zum Beispiel die Verkaufszahlen.
  • Datenanalyse: Es erfolgt eine Analyse der Daten, zum Beispiel die Errechnung von Regionen, bestmöglichen Wege oder Abstände zwischen Standorten.
  • Datenausgabe: Die Ausgabe der Daten eines GIS kann in Form von Texten, Tabellen oder speziellen Kartendarstellungen erfolgen. Der Schwerpunkt solcher Systeme liegt auf der Präsentation in Form von Karten, da diese intuitiv verständlich sind und eine interaktive Bearbeitung – zum Beispiel ein Zoom in die Karte oder ein Verschieben des Fokus – leicht möglich ist.

Die nachfolgenden Ausführungen beschäftigen sich mit der Integration von Kartendarstellungen in Business-Applikationen. Die Anwender von Software sind in der Handhabung von Karten durch die intensive Nutzung von Diensten wie Google Maps, Bing Maps usw. vertraut. Zuvor erfolgt jedoch eine kompakte Darstellung zur Spezifik von Geodaten und deren Präsentation in Karten.

Geodaten und Präsentation

Für die Speicherung und die Arbeit mit geographischen Daten werden fachlich spezialisierte Datentypen und Darstellungen gewählt. Die Lage eines Punktes auf der Erdoberfläche wird mittels des Winkelmaßes, bezogen auf den Äquator (geographische Breite) und den Nullmeridian (geographische Länge) bestimmt. Ergänzt wird ggf. eine Höhenangabe (geographische Höhe). Die Kombination aus geographischer Breite (Latitude), geographische Länge (Longitude) und geographische Höhe (Altitude) bezeichnet man als geodätisches Datum. Die Festlegung eines Nullmeridians ist willkürlich. Der heute weltweit gebräuchliche Nullmeridian wurde während der Internationalen Meridiankonferenz 1884 in die Meridianebene der Londoner Sternwarte Greenwich gelegt und wird daher oft auch als Greenwich-Meridian bezeichnet.

Um beispielsweise Regionen auf einer Karte exakt zu beschreiben, werden geometrische Primitive verwendet. Häufig eingesetzt wird beispielsweise das Simple-Feature-Modell, welches auch als ISO-Norm (ISO 19125-1) standardisiert ist. Es handelt sich um Geo-Objekte, welche durch geradlinig miteinander verbundene Stützpunkte begrenzt werden, beispielsweise Polygone, Mehrfachlinien usw. Um geographische Repräsentationen in Datenbanken zu speichern wurde der SQL-Standard erweitert. Die Erweiterung SQL/MM (MM = Multimedia) erlaubt es, geometrische Objekte – angewendet für Geodaten-Repräsentationen – in einer Datenbank mit eigens dafür definierten Datentypen zu speichern.

Die Logik dieser geographischen Darstellungen, der Einsatz der speziellen Datentypen und die Speicherung in Geo-Datenbanken spielt für die Softwareentwicklung immer dann eine Rolle, wenn man Datenbestände aus größeren Datensammlungen – einer Geo-Datenbank – abruft. Bekannte Geo-Datenbanken sind beispielsweise Oracle Spatial, PostGIS (Erweiterung zu PostgreSQL) und SpatialLite. Jedoch können auch "herkömmliche" Datenbanksysteme – wie MS SQL Server und MySQL/ MariaDB – mit Geodaten umgehen. Auch NoSQL-Datenbanken, wie MongoDB, bieten die Speicherung von Geodaten und die räumliche Abfrage solcher Daten an.

Betrachtet man die Darstellung von Objekten, Routen und Regionen in Karten, dann wird häufig ein Ebenen-Konzept verwendet (Abb. 3).

Einer Ebene werden alle geographischen Objekte eines Themas zu geordnet. Ebene eins umfasst dann zum Beispiel die aktuellen Angaben zu den Niederschlagsmengen und Ebene zwei die Angaben zu den Temperaturen. Die Ebenen können unabhängig voneinander ein- und ausgeblendet werden.

Softwareentwicklung mit Kartendiensten

Auch jenseits von umfassenden GIS gibt es ein großes Potenzial, Daten aus den unterschiedlichsten Bereichen mit Hilfe von Karten zu visualisieren. Dabei kann der Entwickler auf unterschiedliche Kartendienste zurückgreifen. Dazu gehören beispielsweise Google Maps, Here Maps, Microsoft Bing Maps, OpenStreetMap usw. Dabei bieten die Dienste ähnliche Funktionen, zum Beispiel die Anzeige von Orten und Routen, die Visualisierung von Bereichen oder das Ein- und Ausblenden von weiteren Informationen. Zusatzdienste, zum Beispiel die aktuelle Verkehrssituation, kann über eine API bei einigen Diensten abgerufen werden. Meist muss man sich bei dem Dienst zur Nutzung anmelden und einen identifizierenden Key abrufen. Einige Services der Dienste stehen kostenfrei zur Verfügung, andere werden gegen Zahlung einer Lizenzgebühr angeboten. Für die Einbindung in das eigene Programm existiert dann im Idealfall ein spezielles Software Development Kit (SDK). Dieses kann vom Serviceanbieter, von einem Drittanbieter oder von der Community bereitgestellt werden. Die Nutzung eines SDK vereinfacht die Programmierung des Kartendienstes i. d. R. deutlich gegenüber der Verwendung eines generischen API. Möchte man Services von unterschiedlichen Diensten in einer oder mehreren Anwendungen nutzen, dann muss man sich mit den diversen Programmierschnittstellen und den zugehörigen Dokumentationen auseinandersetzen.

App-Integration mittels Komponente

Deutlich einfacher lassen sich die Funktionen mit Hilfe einer fertigen Komponente in die eigene Software integrieren. Idealerweise entsteht dabei Flexibilität auf beiden Seiten. Die Komponente bündelt die Dienste und die API von diversen Services und ermöglicht auf diese Weise die flexible Nutzung. Je nach Bedarf können die Services von mehreren Diensten oder zwischen den Diensten gewechselt werden. Konkret kann es beispielsweise bedeuten, dass man den Kartendienst von Microsoft Bing Maps zu Google Maps oder OpenStreetMaps nur dadurch anpasst, dass ein Wert der betreffenden Eigenschaft geändert wird. In der Anzeige wird dann zum Rendern der Karte bzw. für die Anzeige von datengetriebenen Objekten der jeweils konfigurierte Kartendienst verwendet. Entwickler bekommen auf diese Weise eine einheitliche Programmierschnittstelle und müssen sich über die konkrete Nutzung des Services bzw. dessen API keine Gedanken machen. Diese Flexibilität macht die eigene App auch unabhängig von eventuellen Änderungen der Schnittstelle und den Funktionen eines Dienstes. Oft sind für die Umsetzung mehrere Dienste geeignet, um die individuellen Anforderungen zu erfüllen. Passt ein Dienst seine API bzw. die angebotenen Funktionen an, dann kann man temporär zu einem anderen Dienst wechseln. Das geht i. d. R. schneller, als alle möglichen Änderungen am Dienst auf Auswirkungen auf die eigene Anwendung zu prüfen. Idealerweise abstrahiert die Komponente auch für die Nutzung in diversen Entwicklungsansätzen, d. h. sie kann aus mehreren Programmierumgebungen und für unterschiedliche Applikationstypen verwendet werden. Auf diese Weise entsteht eine beidseitige Abstraktion, welche den Einsatz einer Komponente für die Nutzung von geodatenbasierten Kartendiensten sinnvoll erscheinen lässt.

Eine solche Karten-Komponente ist TMS FNC Maps[2]. Die Komponente bietet den Zugriff auf eine Vielzahl von Kartendiensten bzw. -services und gleichzeitig unterstützt sie unterschiedliche Entwicklungsansätze, Frameworks und damit diverse Typen von Anwendungen. Sie kann für das Erstellen von Desktop-Anwendungen, mobilen Apps und Web-Apps eingesetzt werden.

Damit bildet die Komponente TMSFNCMaps eine abstrakte Schicht über den genannten Diensten. Sie dient dazu, Informationen des gewählten Dienstes anzuzeigen und abzurufen. Für den Entwickler bedeutet es, wenn er zu einem anderen Dienst wechselt, der Quellcode dennoch zu 100 Prozent kompatibel bleibt und sich die Funktionen genau so verhalten wie beim ursprünglichen Dienst. Das kann jedoch nur dann gelten, wenn sich die APIs der Dienste nicht ändern. Ist dieses aber der Fall, dann kann man (vorübergehend) zu einem anderen Dienst wechseln und auf ein Update der Komponente warten.

Eine App mit Kartendienst

Dieser Abschnitt zeigt die Arbeit mit der Komponente TMSFNCMaps für Kartendienste. Das folgende Beispiel verwendet die genannte Komponente in einer Windows-Desktop-Anwendung. Als Entwicklungsumgebung wird Delphi eingesetzt. Die Komponente kann jedoch auch gleichermaßen in den anderen Programmierumgebungen und App-Typen verwendet werden. Beispielsweise zur Anzeige von Karten in Web-Applikationen oder mobilen Apps. Beispielhaft wird eine geographische Region mit einem bestimmten Radius in die Karte eingezeichnet. Die Komponente reduziert den Programmieraufwand auf die folgenden Arbeitsschritte:

  1. Hinzufügen der Maps-Komponente zur Applikation: Da es sich um ein visuelles Steuerelement handelt, zieht man diese aus der Komponentenpalette auf das Formular und passt Größe, Ausrichtung und Layout während der Designzeit der Anwendung an.
  2. Konfiguration der Basiseigenschaften der Karte: Hierzu gehört die Auswahl des Dienstes, z. B. Bing Maps, Google Maps usw. Für die meisten Dienste muss dazu ein Schlüssel (API Key) hinterlegt werden. Ausnahme ist der Service von OpenStreetMap (Open Layers). Ebenso ist der initiale Start-Zoom für die Karte zu definieren.
  1. Festlegung von statischen Kartenelementen: Während der Designzeit der Applikation können bestimmte statische Eigenschaften festgelegt werden. Dazu zählen beispielsweise Marker oder die Definition einer Region mit ihrer graphischen Entsprechung.

Abb. 5 zeigt das Hinzufügen der Komponente zum Formular in der Entwicklungsumgebung und die Anpassung der Eigenschaften.

Alle Eigenschaften der Karte und Elemente können dynamisch zur Laufzeit angepasst werden. Das Vorgehen gestaltet sich intuitiv, wie der folgende Quellcodeausschnitt (Object Pascal) zeigt:

procedure TForm1.AddCircleToMap;
var
  c: 	TTMSFNCMapsCircle;
  pos: TTMSFNCMapsCoordinateRec;
begin
  pos.Longitude:= 11.08;
  pos.Latitude:= 49.45;

  TMSFNCMaps1.BeginUpdate;
  
  TMSFNCMaps1.SetCenterCoordinate(pos);
  c := TMSFNCMaps1.AddCircle(pos, 2000);
  c.FillColor := gcOrange;
  c.FillOpacity := 0.5;
  c.StrokeColor := gcGreen;
  c.StrokeWidth := 4;

  TMSFNCMaps1.EndUpdate;
end;

Es werden zwei Objekte definiert. Eine Geo-Position, charakterisiert über die Koordinaten. In diesem Fall ist es ein Standort in der Gegend um Nürnberg mit der Position Longitude = 11.08 und Latitude = 49.45. Die Karte wird auf diese Position zentriert. Ebenso wird eine Region definiert. In diesem Fall ein Kreis mit einem Radius von 2.000 Metern. Farben werden zur visuellen Hervorhebung festgelegt. Die Änderungen in der Darstellung der Karte werden dynamisch während der Laufzeit der Anwendung vorgenommen.

Nach dem Start der Anwendung und einem Klick auf den Button wird die Karte zentriert und die Region um den gewählten Standort bei Nürnberg eingezeichnet. Im ersten Fall wird als Dienst OpenStreetMaps verwendet. Ändert man den Dienst über die Eigenschaft Service auf Bing Maps und erfasst zusätzlich einen API-Key, welchen man über Microsoft auf der Seite des Dienstes erhält, dann wird in der Anwendung die Karte mittels Bing Maps gerendert. Weitere Anpassungen sind nicht notwendig. Den Einsatz der anderen API bemerkt der Entwickler nicht, der Quellcode muss nicht angepasst werden. Man erkennt leichte Unterschiede in der Darstellung, d. h. der initialen Zoomgröße bei gleicher Vorgabe und minimale farbliche Differenzen (s. Abb. 6).

Komponente abstrahiert typische Funktionen

Eine Komponente abstrahiert dabei unter einer generischem API diverse Funktionen aus dem Bereich Geo-Datenverarbeitung und Kartendienste. Neben der primären Anzeige von Orten, Routen und Regionen bietet die o. g. Komponente weitere Funktionen durch Nutzung von Services der Kartendienste. Dazu zählen zum Beispiel:

  • Abrufen von Wegbeschreibungen, Routeninformationen und Schritt-für-Schritt-Anweisungen für die Navigation vom Start zum Ziel.
  • Abrufen der Höhenposition für einen bestimmten geographischen Standort.
  • Abrufen von Mautkosteninformationen für eine Route vom Start zum Ziel.
  • Abrufen von Zeitzoneninformationen für eine bestimmte geographische Region.

Diese Funktionen werden häufig benötigt und damit wird die Implementierung erheblich vereinfacht. Zur Routenfunktion erfolgt nachfolgend eine Demonstration zur Verwendung in der eigenen Applikation. Für die Bestimmung von Routen zwischen Standorten gibt es die Komponente TMSFNCRouteCalculator. Dabei handelt es sich um eine nicht-visuelle Komponente, welche mit der vorgestellten Komponente TMSFNCMaps zusammenarbeitet. Für die Bestimmung der Route muss man ebenfalls einen Dienst wie Bing Maps oder Google Maps auswählen und ggf. auch hier einen API-Key hinterlegen. Beide Komponenten werden zur Entwurfszeit der App miteinander über die Eigenschaften verbunden (Abb. 7).

Startet man dann die App, kann man interaktiv Start- und Zielpunkt auf der Karte auswählen, die Route wird berechnet und angezeigt (Abb. 8).

Diverse Optionen zur Berechnung der Route (Straße, öffentliche Verkehrswege) oder die Art und Gestaltung der Marker können nach Wunsch konfiguriert werden. Neben dem interaktiven Vorgehen kann man alle Optionen zur Konfiguration und Berechnungen für die gewünschte Routen auch aus dem Quellcode heraus vornehmen. Die Daten dafür können dann zum Beispiel aus einer Datenbank stammen. Auch dieses Beispiel demonstriert, wie einfach mit Hilfe von Komponenten typische Aufgaben einer geodaten- bzw. kartenbasierten Anwendung umgesetzt werden können.

Fazit und Ausblick

Die Nutzung von Kartendiensten spielt eine zunehmende Rolle in betrieblichen Anwendungen. Für den Entwickler ist die Situation in mehrfacher Hinsicht komplex. Zum einem muss man zunächst die theoretischen Hintergründe und die Begriffe bei der Arbeit mit Geodaten erlernen. Danach gilt es, den passenden Dienst auszuwählen und mit dessen API vertraut zu werden. Die Arbeit mit unterschiedlichen Anforderungen und Diensten kann man erheblich vereinfachen, wenn man eine die Technik abstrahierende Komponente verwendet. Diese vereinheitlicht die Programmierschnittstellen diverser APIs und kann in unterschiedlichen Programmierumgebungen genutzt werden. Das Ergebnis ist eine maximale Flexibilität, eine einfachere Entwicklung und ein direktes Konzentrieren auf die Anforderungen der zu entwickelnden Software.

Quellen
  1. Spektrum – Lexikon der Geographie: GIS
  2. TMS FNC Maps

Weitere Informationen:

 

Autor:innen

Elena Bochkor

Elena Bochkor ist studierte Wirtschaftsinformatikerin. Sie setzt sich u.a. mit Fragen der digitalen Transformation, des Mobile Computings und weiteren Zukunftsthemen auseinander.
>> Weiterlesen

Dr. Veikko Krypczyk

Dr. Veikko Krypczyk arbeitet u. a. als Softwareentwickler, Fachautor und Dozent. Über die Firma LARInet gibt er darüber hinaus sein Wissen in Schulungen zu aktuellen Fragestellungen der IT weiter.
>> Weiterlesen
Das könnte Sie auch interessieren
Kommentare (0)

Neuen Kommentar schreiben