Google- und MS-Webkartendienste mit Zugang per Schlüssel
Posted: 05 Sep 2016 18:44
Vor etwa 10 Jahren habe ich TransDEM um Online-Zugriffe erweitert, zuerst für WMS, Web Mapping Services, danach für Kachelkarten, beides bekannte Industrie- bzw. de-facto-Standards. Das Kachelkarten-Verfahren hat über die Jahre zusätzlich an Popularität gewonnen, vielleicht auch, weil es von Open Street Map verbreitet wird. Ursprünglich allerdings war es die Schnittstelle kostenloser Kartendienste von Google, Microsoft und einigen anderen kommerziellen Anbietern.
Vielleicht erinnert sich noch jemand von den alten Hasen: Judith Montgomery „Arista“ brachte das Kachelkartenthema ursprünglich bei TSSF auf; die Technik war zuvor bereits von der Flugsimulatorgemeinde entdeckt worden.
Die Web-Service-Schnittstelle für Kachelkarten selbst ist recht simpel, aber die Konstruktion der zugehörigen Abfrage-URL ist es weniger. Die URL fragt nach nach einer bestimmten Kachel anhand deren Adresse, wobei diese Adresse dann implizit auch die Georeferenzierung enthält. Als Antwort erhält man eine Bitmap, 256 x 256 Pixel groß, exakt eine Kachel. Das Ganze ist als Quadtree aufgebaut, mit einer Standard-Mercatorprojektion dahinter. Um von einem geographischen Ort zu einer Kacheladresse zu gelangen, ist schon ein wenig Hintergrundwissen erforderlich. Google und Microsoft bieten Javascript-Bibliotheken, um im Hauptanwendungsfall Webseite den Ersteller zu entlasten.
Im Laufe der Zeit wurden leistungsfähigere Server verfügbar und Google und Microsoft boten neuere Schnittstellen an, die es für die Client-Anwendungen einfacher machten. Intern wurde weiterhin die Kachelkartenstruktur benutzt, aber nach außen erwartet die neuere Schnittstelle jetzt die direkte Angabe geographischer Koordinaten, und auch die resultierende Bitmap darf flexiblere Abmessungen haben. Die URL-Komposition erinnert jetzt stärker an WMS.
Es gibt einen Haken. Diese neueren Schnittstellen erlauben keinen anonymen Zugang mehr. Sie erfordern zusätzlich einen Schlüssel.
Basisschlüssel werden von Google und Microsoft „kostenlos“ angeboten, aber wie wir alle wissen, there ain't no such thing as a free lunch. Wir zahlen mit unseren Daten, oder, wie es jemand neulich ausdrückte: Als Nutzer eines solchen kostenloses Produktes wird man selbst zum Produkt.
Von daher war ich immer sehr zurückhaltend, wenn die Frage zur Implementierung nicht-anonymer Schnittstellen in TransDEM aufkam.
In den letzten Monaten allerdings gab es nun verschiedene Anzeichen, die vermuten lassen, zumindest Google könne in absehbarer Zeit die klassische anonyme Kachelkartenschnittstelle abschalten.
Aus den Rückmeldungen, die ich zu TransDEM bekomme, weiß ich, dass viele Nutzer mit Google Earth beginnen. Nicht jedermann ist im Kartenlesen geübt, besonders wenn es um die topographischen Details geht. Luftbilder scheinen selbsterklärend, und für viele Ecken kann man sie fast beliebig vergrößern. Die Funktionen für Google Earth in TransDEM sind einfach zu nutzen, und Vorbereitung ist fast keine erforderlich. Aber wenn die Zahl der zu verarbeitenden Bilder ansteigt, wird der ganze Prozess doch etwas mühsam, und man wünscht sich stärker automatisierte Alternativen. Mit Kachelkarten existiert dafür bereits die Lösung. Eine andere Schnittstelle zu praktisch denselben Daten. TransDEM besorgt das Laden der Bilder, deren Georeferenzierung und die Konvertierung zu UTM. Und, wenn man entlang eines Pfades arbeitet, erledigt TransDEM dies sogar für ganze Bilderserien.
Diese Funktionalität für Luftbilder würden wir verlieren, wenn Google und Microsoft ihren klassischen Kachelkartenzugang abschalteten.
Aus diesem Grund habe ich mich entschlossen, nun doch Schnittstellen zu den neueren Diensten zu bauen, für die ein Schlüssel erforderlich ist. Der technische Ablauf wird weitgehend unter der Haube erfolgen. Der neue Zugang soll mit in den Kachelkarten-Client aufgenommen werden. Im Idealfall wird man als Anwender keinen Unterschied sehen, ob die Bilder als klassische Kacheln oder über den schlüssel-basierten Server abgerufen werden.
TransDEM selbst wird keinen solchen Schlüssel vorinstallieren. Es wird einzig und allein Sache des Anwenders sein, sich seinen Schlüssel über die Registrierungskanäle von Google oder Microsoft zu besorgen. Auch mit Schlüssel bleibt der Zugang zu deren Diensten beschränkt. Kostenlose Schlüssel verfügen über ein kleineres Kontingent als bezahlte Schlüssel, sollten aber für unsere Zwecke ausreichen. TransDEM wird einen Dialog anbieten, um den Schlüssel in den TransDEM-Einstellungen zu speichern, separat von den sonstigen Parametern der Kachelkarten.
Wer mit Rail Simulator/Railworks und der dortigen Google-Maps-Unterstützung gearbeitet hat, wird dem Schlüsselmechansmus möglicherweise bereits begegnet sein.
Derzeit kann ich noch nicht abschätzen, wie lange die Implementierung der Schnittstelle zu diesen neueren Diensten dauern wird. Ich habe gerade mal mit den Grundlagen begonnen. Ich bleibe dran und werde berichten, wenn es neue Erkenntnisse gibt.
Vielleicht erinnert sich noch jemand von den alten Hasen: Judith Montgomery „Arista“ brachte das Kachelkartenthema ursprünglich bei TSSF auf; die Technik war zuvor bereits von der Flugsimulatorgemeinde entdeckt worden.
Die Web-Service-Schnittstelle für Kachelkarten selbst ist recht simpel, aber die Konstruktion der zugehörigen Abfrage-URL ist es weniger. Die URL fragt nach nach einer bestimmten Kachel anhand deren Adresse, wobei diese Adresse dann implizit auch die Georeferenzierung enthält. Als Antwort erhält man eine Bitmap, 256 x 256 Pixel groß, exakt eine Kachel. Das Ganze ist als Quadtree aufgebaut, mit einer Standard-Mercatorprojektion dahinter. Um von einem geographischen Ort zu einer Kacheladresse zu gelangen, ist schon ein wenig Hintergrundwissen erforderlich. Google und Microsoft bieten Javascript-Bibliotheken, um im Hauptanwendungsfall Webseite den Ersteller zu entlasten.
Im Laufe der Zeit wurden leistungsfähigere Server verfügbar und Google und Microsoft boten neuere Schnittstellen an, die es für die Client-Anwendungen einfacher machten. Intern wurde weiterhin die Kachelkartenstruktur benutzt, aber nach außen erwartet die neuere Schnittstelle jetzt die direkte Angabe geographischer Koordinaten, und auch die resultierende Bitmap darf flexiblere Abmessungen haben. Die URL-Komposition erinnert jetzt stärker an WMS.
Es gibt einen Haken. Diese neueren Schnittstellen erlauben keinen anonymen Zugang mehr. Sie erfordern zusätzlich einen Schlüssel.
Basisschlüssel werden von Google und Microsoft „kostenlos“ angeboten, aber wie wir alle wissen, there ain't no such thing as a free lunch. Wir zahlen mit unseren Daten, oder, wie es jemand neulich ausdrückte: Als Nutzer eines solchen kostenloses Produktes wird man selbst zum Produkt.
Von daher war ich immer sehr zurückhaltend, wenn die Frage zur Implementierung nicht-anonymer Schnittstellen in TransDEM aufkam.
In den letzten Monaten allerdings gab es nun verschiedene Anzeichen, die vermuten lassen, zumindest Google könne in absehbarer Zeit die klassische anonyme Kachelkartenschnittstelle abschalten.
Aus den Rückmeldungen, die ich zu TransDEM bekomme, weiß ich, dass viele Nutzer mit Google Earth beginnen. Nicht jedermann ist im Kartenlesen geübt, besonders wenn es um die topographischen Details geht. Luftbilder scheinen selbsterklärend, und für viele Ecken kann man sie fast beliebig vergrößern. Die Funktionen für Google Earth in TransDEM sind einfach zu nutzen, und Vorbereitung ist fast keine erforderlich. Aber wenn die Zahl der zu verarbeitenden Bilder ansteigt, wird der ganze Prozess doch etwas mühsam, und man wünscht sich stärker automatisierte Alternativen. Mit Kachelkarten existiert dafür bereits die Lösung. Eine andere Schnittstelle zu praktisch denselben Daten. TransDEM besorgt das Laden der Bilder, deren Georeferenzierung und die Konvertierung zu UTM. Und, wenn man entlang eines Pfades arbeitet, erledigt TransDEM dies sogar für ganze Bilderserien.
Diese Funktionalität für Luftbilder würden wir verlieren, wenn Google und Microsoft ihren klassischen Kachelkartenzugang abschalteten.
Aus diesem Grund habe ich mich entschlossen, nun doch Schnittstellen zu den neueren Diensten zu bauen, für die ein Schlüssel erforderlich ist. Der technische Ablauf wird weitgehend unter der Haube erfolgen. Der neue Zugang soll mit in den Kachelkarten-Client aufgenommen werden. Im Idealfall wird man als Anwender keinen Unterschied sehen, ob die Bilder als klassische Kacheln oder über den schlüssel-basierten Server abgerufen werden.
TransDEM selbst wird keinen solchen Schlüssel vorinstallieren. Es wird einzig und allein Sache des Anwenders sein, sich seinen Schlüssel über die Registrierungskanäle von Google oder Microsoft zu besorgen. Auch mit Schlüssel bleibt der Zugang zu deren Diensten beschränkt. Kostenlose Schlüssel verfügen über ein kleineres Kontingent als bezahlte Schlüssel, sollten aber für unsere Zwecke ausreichen. TransDEM wird einen Dialog anbieten, um den Schlüssel in den TransDEM-Einstellungen zu speichern, separat von den sonstigen Parametern der Kachelkarten.
Wer mit Rail Simulator/Railworks und der dortigen Google-Maps-Unterstützung gearbeitet hat, wird dem Schlüsselmechansmus möglicherweise bereits begegnet sein.
Derzeit kann ich noch nicht abschätzen, wie lange die Implementierung der Schnittstelle zu diesen neueren Diensten dauern wird. Ich habe gerade mal mit den Grundlagen begonnen. Ich bleibe dran und werde berichten, wenn es neue Erkenntnisse gibt.
