Bei Google MAPS GEO-Koordinaten mit C# abfragen

Für ein aktuelles Projekt benötige ich von Plätzen / Anschriften die GEO-Koordinaten. Da zur Visualisierung so wieso Google-Maps später eingesetzt werden soll, liegt natürlichdie Google-API nahe. Dafür habe ich heute ein C# Klasse entwickelt, mit der man einfach über einen HTTPRequest das Ergebnis in XML zurück geliefert bekommt. Die Klassen analysiert das Ergebnis von Google auf Fehler und parst die Werte für Latitude und Longitude.

Zunächst habe ich mir das Core-Modul von DotNetNuke "MAPS" angeschaut, das ebenfalls die Google-Maps nutzt. Es funktioniert recht gut - nur war ich von der vorgehensweise docht etwas erschrocken: Da wird das Ergebnis wirklich noch mit String-Funktionen (Find, Left, SubString) auseinandergenommen um an die Werte zukommen. Hallo? Wofür gibt es einen XML-Parser, der für solche Aufgaben entwickelt wurde und auch deutlich schneller ist, bei der Analyse von XML.
Das aber nur als Zwischenbemerkung an dieser Stelle ;-)

Bei der Entwicklung der Klasse hatte ich zunächst Probleme mit XPath die Werte auszulesen. Da ich ja diesmal gezielt ein paar Daten aus dem XML-File benötige und nicht wirklich Node für Node durchgehen muss (wollte), war XPath meine erste Wahl. Mache das aber nicht so häufig und hatte zuerst schwirigkeiten, weil die Abfrage SelectSingleNode immer einen null-Value zurück lieferte. Nach kurzer Zeit viel mir dann aber auf, das Google einen Namespace im XML-Dokument stehen hat - so wie es ja eigentlich auch sein soll. Diesen Namespace muss aber bei einer XPath-Abfrage auf jeden Fall vorher dem Parser bekannt geben. Dann funktioniert die Abfrage auch ohne Probleme. Das sieht dann in etwa so aus:

XmlNamespaceManager nsManager = new XmlNamespaceManager(xmlDoc.NameTable);
nsManager.AddNamespace("gm", "http://earth.google.com/kml/2.0");

///Es wird versucht den Statuscode zu ermitteln
XmlNode nodeStatus = xmlDoc.SelectSingleNode("gm:kml/gm:Response/gm:Status/gm:code", nsManager);

In der Abfrage hier wird der Status-Cide abgefragt, um zu überprüfen ob die Anfrage erfolgreich war. xmlDoc ist dabei mein XML-Parser ( System.Xml.XmlDocument).

Die fertige C# Klasse steht hier zum Download bereit:

C#-GoogleMaps-API-GEO-Koordinaten.zip (2,59 KB)

Kommentare (6) -

Jan Welker
17.05.2008 17:15:14 #

Hallo,

warum lässt du den XML Overhead nicht einfach komplett weg?
Siehe: dotnet-snippets.de/.../...api-abfragen-SID824.aspx

Viele Grüße
Jan

Daniel
19.05.2008 14:10:39 #

Hi,

ganz einfach: Weil ich XML deutlich besser finde als CSV und die Verbeitung auch deutlich angenehmer ist - normlerweise Smile

Gruß
Daniel

Kevin M Schreiner
20.05.2008 14:35:51 #

First, let me apologize for responding in English, my German isn't all that good. I colleague alerted me of the subject matter of the post. In any case - while it is correct that the Map Module is utilizing the String object over the XML Document in order to parse the KML content retrieved from Google, it is indeed not faster to use XML in this case. The loading, parsing and searching of the XML node via both the XML Navigator and the XML Document SelectSingleNode function is 6 times slower. This is if you are using both standard paths of:

gm:kml/gm:Response/gmTonglacemark/gmTongoint/gm:coordinates
or
descendant::gm:coordinates

The reason for the speed verification is the code was pulled from an internal service for geocoding large sets of data, and the functions have undergone some heavy functional analysis to determine which approach would be more appropriate. These tests were provided using the average expended ticks over a cycle of 100,000 repeated calls.

I will say, however, that the XML approach is FAR more intuitive to the end user, and I fully expect that I will adopt in the upcoming releases.

Kevin M Schreiner
20.05.2008 14:40:23 #

Ah, one other note - when you are geocoding the contents - Google throttles the result so pay attention to the status codes when the coordinates are not present:

200 - Success
400 - Bad Request (don't retry or you will get the same result)
500 - Server Error (retry, as this was unexpected)
601 - Missing Query String
602 - Missing Address
603 - Unavailable Address
610 - Bad Key
620 - Too many requests (this is the throttle result, you can retry and repeat until success)

Andreas
27.05.2008 14:44:07 #

Hallo, kann mir jemand vielleicht bitte sagen, wie ich beispielhaft den Methoden-Aufruf z.B. für München durchführe ?

Vielen Dank

mr nobody
31.07.2008 08:55:27 #

Moin wollte nur anmerken das da nen Google Api Key im Quellcode steht soweit ich weiß muss man den doch beantragen oder nicht (ich mein quasi ist der ja auf irgendwen registriert).

Kommentar schreiben