xml

XML-Ecke

Struktur in den Content!

Google vereinfacht Geocoding-Service

Rund zehn Monate nach der Einführung von Version 3 (V3) der Google Maps API hat Google auch seinen Geocoding-Service vereinfacht, der Postadressen oder Ortsangaben in Geodaten umwandelt. Auch hier ist jetzt kein besonderer Key für die Nutzung des Dienstes mehr erforderlich. Es genügt die Anforderung beim Webservice nach dem Schema:

http://maps.google.com/maps/api/geocode/output?parameters

Der Platzhalter “output” wird ersetzt durch Angaben zum gewünschten Ausgabeformat, wobei XML oder das schlanke JSON zur Verfügung stehen. Statt “parameters” wird die gewünschte Adresse angegeben, also zum Beispiel:

http://maps.google.com/maps/api/geocode/xml?address=Weifert-Janz-Straße+1+Mainz&sensor=false

Der erforderliche Parameter “sensor” gibt an, ob die Anfrage von einem Gerät mit der Erfassung von Geodaten kommt oder nicht. Optional kann mit dem Parameter “region” die geografische Region eingegrenzt werden, was etwa bei Orten sinnvoll ist, die es in mehreren Ländern gibt. Ohne diese Differenzierung zeigt der Geocoder zum Beispiel bei der Abfrage von Toledo den im US-Staat Ohio gelegenen Ort an. Erst die Präzisierung mit “region=es” sucht nach der spanischen Stadt. Für die Bezeichnung der Region werden die Länder-Codes der Top-Level-Domains (ccTLD) verwendet, also etwa “de” für Deutschland. Das Ergebnis der Abfrage im JSON-Format führt alle bekannten Informationen auf, darunter auch die Geodaten der geografischen Länge und Breite:

{
  "status": "OK",
  "results": [ {
    "types": [ "street_address" ],
    "formatted_address": "Weifert-Janz-Straße 1, 55122 Mainz, Deutschland",
    "address_components": [ {
      "long_name": "1",
      "short_name": "1",
      "types": [ "street_number" ]
    }, {
      "long_name": "Weifert-Janz-Straße",
      "short_name": "Weifert-Janz-Straße",
      "types": [ "route" ]
    }, {
      "long_name": "Mainz",
      "short_name": "Mainz",
      "types": [ "locality", "political" ]
    }, {
      "long_name": "Mainz",
      "short_name": "MZ",
      "types": [ "administrative_area_level_2", "political" ]
    }, {
      "long_name": "Rheinland-Pfalz",
      "short_name": "RP",
      "types": [ "administrative_area_level_1", "political" ]
    }, {
      "long_name": "Deutschland",
      "short_name": "DE",
      "types": [ "country", "political" ]
    }, {
      "long_name": "55122",
      "short_name": "55122",
      "types": [ "postal_code" ]
    } ],
    "geometry": {
      "location": {
        "lat": 50.0042904,
        "lng": 8.2410587
      },
      "location_type": "RANGE_INTERPOLATED",
      "viewport": {
        "southwest": {
          "lat": 50.0011490,
          "lng": 8.2379114
        },
        "northeast": {
          "lat": 50.0074443,
          "lng": 8.2442067
        }
      },
      "bounds": {
        "southwest": {
          "lat": 50.0042904,
          "lng": 8.2410587
        },
        "northeast": {
          "lat": 50.0043029,
          "lng": 8.2410594
        }
      }
    }
  } ]
}

Die JSON-Elemente lassen sich nun mit wenigen Codezeilen als Javascript-Variablen definieren und für Kartendarstellungen verwenden – zum Beispiel:

?View Code JAVASCRIPT
var latitude = myJSONResult.results.location.lat;
var longitude = myJSONResults.location.lng;

Dabei verlangt Google in seinen Nutzungsbestimmungen, dass nur Karten auf der Grundlage seiner eigenen APIs für Google Maps oder Google Earth verwendet werden dürfen. Neben der Auflösung von Adressen wird auch das Reverse Geocoding unterstützt, also die Umwandlung von Geodaten mit den Angaben der geografischen Breiten- und Längengrade in Adressen. Für das oben gezeigte Beispiel funktioniert dies etwa auf diese Weise:

http://maps.google.com/maps/api/geocode/json?latlng=50.0042904,8.2410587&sensor=false

XMLSpy von Altova spricht auch JSON

Mit jeder Version lernt das Altova-Paket für die XML-Plattform neu hinzu. Nachdem vor einem Jahr die Unterstützung für die Business Reporting Language (XBRL) im Zentrum stand, spricht der XMLSpy 2010 jetzt auch JSON, das Datenformat JavaScript Object Notation. “Es gibt zahllose Anwendungen, bei denen XML sinnvoller ist, und es gibt zahllose andere Anwendungen, bei denen [...]

weiterlesen »

Debatte über Zukunft von XML

In einigen Blogs in den USA wird gerade eine Diskussion über den künftigen Stellenwert von XML geführt. Auslöser war ein Beitrag von Jack Vaughan mit der Frage “What’s the future of XML?”. Er stellt darin das Datenaustauschformat JSON (JavaScript Object Notation) als Reaktion auf die zunehmende Komplexität von XML dar und erklärt: “Es ist vorstellbar, dass die [...]

weiterlesen »


Hat XML eine Zukunft im Web?

So lautet die Frage beim Eröffnungspanel der vom 3. bis 5. Dezember in Boston. In dem Panel soll es unter anderem um die zunehmende Popularität von JSON (JavaScript Object Notation) gehen, einer Technik, die in Verbindung mit Ajax als Alternative zu XML für Webanwendungen eingesetzt werden kann. Am Diskussionstisch sitzt auch Michael Day, Gründer der [...]

weiterlesen »


Copyright © 2010 by: XML-Ecke - Lizenz: Creative Commons BY-NC-SA.