Wegbeschreibungen über die Directions API (alte Version) abrufen

Entwickler im Europäischen Wirtschaftsraum (EWR)

Dieses Produkt hat den Legacy-Status. Ab Oktober 2026 kann die Directions API (Legacy) nicht mehr für neue Google Cloud-Projekte aktiviert werden. Bestehende Projekte werden weiterhin vollständig unterstützt. Wenn Sie neue Funktionen und eine bessere Leistung nutzen möchten, migrieren Sie zur Routes API.

Für Routenberechnungen, die in Echtzeit auf Nutzereingaben reagieren (z. B. in einem Element der Benutzeroberfläche), können Sie die Directions API (Legacy) oder, wenn Sie die Maps JavaScript API verwenden, den Directions Service verwenden. Für die serverseitige Verwendung können Sie den Java-, Python-, Go- und Node.js-Client für Google Maps-Dienste nutzen.

Mit der Directions API (Legacy) können Sie:

  • Routen für verschiedene Mobilitätsformen abrufen, z. B. öffentliche Verkehrsmittel, Auto, zu Fuß oder Fahrrad
  • Mehrteilige Wegbeschreibungen ausgeben, wenn eine Reihe von Wegpunkten angegeben wird.
  • Geben Sie Startpunkte, Ziele und Wegpunkte als Textstrings (z. B. „Chicago, IL“ oder „Darwin, NT, Australien“), als Orts-IDs oder als Breiten-/Längengradkoordinaten an.

Die API gibt bei der Routenberechnung die effizientesten Routen zurück. Die Route wird primär nach der Fahrzeit optimiert, es können aber auch andere Faktoren berücksichtigt werden, wie z. B. die Entfernung oder die Anzahl der Abzweige.

Hinweis

Um die Directions API (Legacy) nutzen zu können, benötigen Sie ein Projekt mit einem Rechnungskonto. Außerdem muss die Directions API (Legacy) aktiviert sein. Weitere Informationen finden Sie unter In der Cloud Console einrichten.

Directions API (Legacy)-Anfragen erstellen

Eine Anfrage an die Directions API (Legacy) hat folgendes Format:

https://maps.googleapis.com/maps/api/directions/outputFormat?parameters

Dabei kann outputFormat einen der folgenden Werte haben:

  • json (empfohlen) gibt die Ausgabe in JavaScript Object Notation (JSON) an.
  • xml gibt die Ausgabe als XML an.

Hinweis: URLs müssen ordnungsgemäß codiert sein, um gültig zu sein, und sind für alle Webdienste auf 16.384 Zeichen beschränkt. Beachten Sie dieses Limit beim Erstellen Ihrer URLs.

Wie in URLs üblich, werden alle Parameter mit dem Und-Zeichen (&) getrennt. Alle reservierten Zeichen (z. B. das Pluszeichen „+“) müssen URL-codiert sein. Im Folgenden finden Sie die Liste der Parameter und ihre möglichen Werte.

Erforderliche Parameter

Ziel

Die Orts-ID, die Adresse oder der Textwert für den Breiten-/Längengrad, für den Sie die Route berechnen möchten. Die Optionen für den Zielparameter sind dieselben wie für den Ursprungsparameter.

origin

Die Orts-ID, die Adresse oder der Textwert für den Breiten-/Längengrad, von dem aus Sie die Route berechnen möchten.

  • Orts-IDs muss das Präfix place_id: vorangestellt werden. Sie können Orts-IDs aus der Geocoding API und der Places API (einschließlich Place Autocomplete) abrufen. Ein Beispiel für die Verwendung von Orts-IDs aus dem „Place Autocomplete“-Dienst finden Sie hier. Weitere Informationen finden Sie in der Übersicht zur Orts-ID. 

    origin=place_id:ChIJ3S-JXmauEmsRUcIaWtf4MzE

  • Wenn Sie eine Adresse übergeben, wird der String vom Directions-Dienst geocodiert und in Breiten- und Längengradkoordinaten umgewandelt, um die Wegbeschreibung zu berechnen. Diese Koordinate kann sich von der von der Geocoding API zurückgegebenen Koordinate unterscheiden, z. B. ein Gebäudeeingang anstelle der Gebäudemitte. 

    origin=24+Sussex+Drive+Ottawa+ON

    Die Verwendung von Orts-IDs wird gegenüber Adressen oder Längen-/Breitengraden bevorzugt. Wenn Sie Koordinaten verwenden, wird der Punkt immer an der Straße ausgerichtet, die diesen Koordinaten am nächsten liegt. Das ist möglicherweise kein Zugangspunkt zum Grundstück oder sogar eine Straße, die nicht schnell oder sicher zum Ziel führt.

  • Wenn Sie Koordinaten übergeben, wird der Punkt an der nächstgelegenen Straße ausgerichtet. Wir empfehlen, eine Orts-ID zu übergeben. Wenn Sie Koordinaten übergeben, achten Sie darauf, dass zwischen den Werten für Breiten- und Längengrad kein Leerzeichen steht. 

    origin=41.43206,-81.38992

  • Plus Codes müssen als globaler oder zusammengesetzter Code formatiert sein. Formatieren Sie die Plus Codes wie hier gezeigt (Pluszeichen werden in der URL als %2B dargestellt, Leerzeichen als %20).

    • Global Code besteht aus einem vierstelligen Vorwahl-Code und einem mindestens sechsstelligen lokalen Code (849VCWC8+R9 wäre beispielsweise 849VCWC8%2BR9).
    • Compound Code ist ein mindestens sechsstelliger lokaler Code mit einem expliziten Ort (CWC8+R9 Mountain View, CA, USA wäre dann CWC8%2BR9%20Mountain%20View%20CA%20USA).
Hinweis: Verwenden Sie nach Möglichkeit Orts-IDs, um die Effizienz und Genauigkeit zu erhöhen. Diese IDs sind eindeutig, wie ein Breiten-/Längengrad-Wertepaar, und bieten Geocoding-Vorteile für das Routing, z. B. Zugangspunkte und Verkehrsvariablen. Im Gegensatz zu einer Adresse ist für IDs keine Suche oder Zwischenanfrage für Ortsdetails erforderlich. Daher ist die Leistung besser.

Optionale Parameter

Alternativen

Ist der Wert auf true gesetzt, kann der „Directions“-Dienst mehrere alternative Routen in der Antwort zurückgeben. Durch alternative Routen kann sich die Antwortzeit des Servers jedoch verlängern. Diese Option ist nur für Anfragen ohne Wegpunkte verfügbar. Weitere Informationen finden Sie im Leitfaden zu Wegpunkten.

arrival_time

Gibt die bevorzugte Ankunftszeit für Routen für öffentliche Verkehrsmittel in Sekunden seit Mitternacht, 1. Januar 1970 UTC, an. Sie können entweder departure_time oder arrival_time angeben, aber nicht beides. Beachten Sie, dass arrival_time als Ganzzahl angegeben werden muss.

avoid

Gibt an, dass die berechneten Routen die angegebenen Elemente vermeiden sollen. Dieser Parameter unterstützt die folgenden Argumente:

  • tolls gibt an, dass auf der berechneten Route Mautstraßen und ‑brücken vermieden werden sollen.
  • highways gibt an, dass auf der berechneten Route Autobahnen vermieden werden sollen.
  • ferries gibt an, dass auf der berechneten Route Fähren vermieden werden sollen.
  • indoor gibt an, dass für die berechnete Route Treppen in Innenräumen für Fußgänger und Routen für öffentliche Verkehrsmittel vermieden werden sollen.

Sie können eine Route anfordern, bei der eine beliebige Kombination aus Mautstraßen, Autobahnen und Fähren vermieden wird, indem Sie mehrere Einschränkungen an den Parameter „avoid“ übergeben. Beispiel: 

avoid=tolls|highways|ferries.

departure_time

Gibt die bevorzugte Abfahrtszeit an. Sie können die Zeit als Ganzzahl in Sekunden seit Mitternacht, 1. Januar 1970 UTC, angeben. Wenn ein departure_time nach dem 31.12.9999, 23:59:59.999999999Z angegeben wird, setzt die API den departure_time auf den 31.12.9999, 23:59:59.999999999Z zurück. Alternativ können Sie den Wert „now“ angeben, wodurch die Abfahrtszeit auf die aktuelle Zeit (auf die Sekunde genau) festgelegt wird. Die Abreisezeit kann in zwei Fällen angegeben werden:

  • Für Anfragen mit öffentlichen Verkehrsmitteln als Mobilitätsform: Sie können optional departure_time oder arrival_time angeben. Wenn keine der beiden Zeiten angegeben ist, wird für departure_time standardmäßig die aktuelle Uhrzeit verwendet (d. h. die Abfahrtszeit entspricht der aktuellen Uhrzeit).
  • Für Anfragen mit Kraftfahrzeugen als Mobilitätsform: Sie können departure_time angeben, um eine Route und eine Fahrtdauer (Antwortfeld: duration_in_traffic) zu erhalten, die die Verkehrslage berücksichtigen. Für departure_time muss die aktuelle Zeit oder eine Zeit in der Zukunft angegeben werden. Der Wert darf nicht in der Vergangenheit liegen.
Hinweis: Wenn keine Startzeit angegeben ist, beruhen die Auswahl der Route und die Reisezeit auf dem Straßennetz und der durchschnittlichen zeitunabhängigen Verkehrslage. Die Ergebnisse für eine bestimmte Anfrage können sich im Laufe der Zeit aufgrund von Änderungen im Straßennetz, Aktualisierungen der durchschnittlichen Verkehrslage und der Dezentralisierung des Diensts ändern. Außerdem können die Ergebnisse zwischen praktisch gleichwertigen Routen jederzeit und beliebig oft variieren.
Hinweis: Distanzmatrix-Anfragen, bei denen departure_time angegeben ist, wenn mode=driving, sind auf maximal 100 Elemente pro Anfrage beschränkt. Die Anzahl der Elemente ergibt sich aus der Anzahl der Startorte multipliziert mit der Anzahl der Zielorte.

Sprache

Die Sprache, in der die Ergebnisse zurückgegeben werden sollen. Dies gilt nur für die geocodierten Adressen in start_address und end_address, den lokalisierten Text in den Feldern distance und duration (in Abschnitten und Schritten) und die Beschreibung der Manöver in html_instructions, nicht aber für die Namen und Adressen in html_instructions, die in der jeweiligen Landessprache und -schrift formatiert sind.

  • Hier finden Sie eine Liste der unterstützten Sprachen. Die unterstützten Sprachen werden regelmäßig von Google aktualisiert, sodass diese Liste unter Umständen nicht vollständig ist.
  • Wenn language nicht angegeben ist, versucht die API, die im Header Accept-Language angegebene bevorzugte Sprache zu verwenden.
  • Die API versucht, eine Adresse anzugeben, die sowohl für den Nutzer als auch für Einheimische lesbar ist. Dazu werden Adressen in der Landessprache zurückgegeben, die bei Bedarf in eine für den Nutzer lesbare Schrift transliteriert werden, wobei die bevorzugte Sprache berücksichtigt wird. Alle anderen Adressen werden in der bevorzugten Sprache zurückgegeben. Adresskomponenten werden alle in derselben Sprache zurückgegeben, die von der ersten Komponente ausgewählt wird.
  • Wenn ein Name in der bevorzugten Sprache nicht verfügbar ist, verwendet die API die nächstgelegene Übereinstimmung.
  • Die bevorzugte Sprache hat einen geringen Einfluss auf die von der API zurückgegebenen Ergebnisse und die Reihenfolge, in der sie zurückgegeben werden. Der Geocoder interpretiert Abkürzungen je nach Sprache unterschiedlich, z. B. Abkürzungen für Straßentypen oder Synonyme, die in einer Sprache gültig sind, in einer anderen jedoch nicht. Beispiel: utca und tér sind Synonyme für „Straße“ auf Ungarisch.

Modus

Für die Berechnung von Entfernungen und Wegbeschreibungen können Sie die zu verwendende Mobilitätsform angeben. Standardmäßig wird der Modus driving verwendet. Standardmäßig erfolgt die Routenberechnung mit dem Wert driving . Folgende Mobilitätsformen werden unterstützt:

  • Bei driving (Standardeinstellung) wird eine standardmäßige Wegbeschreibung oder Entfernung auf Grundlage des Straßennetzes angefordert.
  • Bei walking werden Fußgängerrouten oder Entfernungen auf Fußgängerwegen und Bürgersteigen (sofern vorhanden) angefordert.
  • Bei bicycling werden Fahrradrouten oder Entfernungen mit Radwegen und bevorzugten Straßen (sofern vorhanden) angefordert.
  • Bei transit werden Routen oder Entfernungen mit öffentlichen Verkehrsmitteln (sofern verfügbar) angefordert. Wenn Sie den Modus auf „Öffentliche Verkehrsmittel“ festlegen, können Sie optional entweder departure_time oder arrival_time angeben. Wenn keine der beiden Zeiten angegeben ist, wird für departure_time standardmäßig die aktuelle Uhrzeit verwendet (d. h. die Abfahrtszeit wird standardmäßig auf die aktuelle Uhrzeit festgelegt). Optional können Sie auch eine transit_mode und/oder eine transit_routing_preference angeben. Fahrten mit öffentlichen Verkehrsmitteln sind bis zu 7 Tage in der Vergangenheit oder bis zu 100 Tage in der Zukunft verfügbar, sofern die entsprechenden Informationen von Datenanbietern bereitgestellt werden. Fahrpläne für öffentliche Verkehrsmittel ändern sich häufig. Die verfügbaren Fahrten können sich im Laufe der Zeit ändern und es gibt keine Garantie, dass die Vorhersagen für weit in der Zukunft liegende Zeitpunkte konsistent sind.
Hinweis: Fußgänger- und Fahrradrouten enthalten unter Umständen keine ausgewiesenen Fußgänger- oder Fahrradwege. In diesen Fällen werden Warnungen im zurückgegebenen Ergebnis angezeigt, die Sie dem Nutzer anzeigen müssen.

Region

Der Regionscode, angegeben als zweistelliger Wert der Ländercode-Top-Level-Domain (ccTLD). Die meisten ccTLD-Codes entsprechen den ISO-3166-1-Codes. Es gibt jedoch einige Ausnahmen. So lautet beispielsweise die ccTLD des Vereinigten Königreichs „uk“ (.co.uk), der ISO-3166-1-Code dagegen „gb“ (technisch gesehen für die Entität „Vereinigtes Königreich Großbritannien und Nordirland“).

traffic_model

Gibt die Annahmen an, die bei der Berechnung der Reisezeit verwendet werden sollen. Diese Einstellung wirkt sich auf den Wert für die voraussichtliche Reisezeit aus, der in der Antwort im Feld „duration_in_traffic“ zurückgegeben und anhand bisheriger Durchschnittswerte berechnet wird. Der Parameter traffic_model darf nur für Wegbeschreibungen angegeben werden, wenn die Anfrage einen departure_time enthält. Verfügbare Werte für diesen Parameter sind:

  • best_guess (Standardwert) gibt an, dass die zurückgegebene „duration_in_traffic“ die beste Schätzung der Reisezeit sein sollte. Dazu werden Verlaufs- und Echtzeitdaten zur Verkehrslage herangezogen. Die aktuelle Verkehrslage wird umso stärker gewichtet, je näher die departure_time rückt.
  • pessimistic gibt an, dass die zurückgegebene duration_in_traffic an den meisten Tagen länger sein sollte als die tatsächliche Reisezeit. An Tagen mit besonders schlechter Verkehrslage kann dieser Wert jedoch überschritten werden.
  • optimistic gibt an, dass die zurückgegebene „duration_in_traffic“ an den meisten Tagen kürzer als die tatsächliche Reisezeit sein dürfte. An Tagen mit besonders guter Verkehrslage kann dieser Wert jedoch unterschritten werden.

Der Standardwert best_guess liefert für die meisten Anwendungsfälle die nützlichsten Vorhersagen. Es ist möglich, dass die Vorhersage der Reisedauer für best_guess kürzer als optimistic oder länger als pessimistic ist, da das Vorhersagemodell für best_guess Echtzeit-Verkehrsinformationen einbezieht.

transit_mode

Gibt ein oder mehrere bevorzugte Verkehrsmittel an. Dieser Parameter darf nur für Routen mit öffentlichen Verkehrsmitteln angegeben werden. Der Parameter unterstützt die folgenden Argumente:

  • bus gibt an, dass für die berechnete Route Busse bevorzugt werden sollen.
  • subway gibt an, dass für die berechnete Route U-Bahnen bevorzugt werden sollen.
  • train gibt an, dass für die berechnete Route Züge bevorzugt werden sollen.
  • tram gibt an, dass für die berechnete Route Straßen- und Stadtbahnen bevorzugt werden sollen.
  • rail gibt an, dass für die berechnete Route Züge, Straßenbahnen, Stadtbahnen und U-Bahnen bevorzugt werden sollen. Dies entspricht transit_mode=train|tram|subway.

transit_routing_preference

Gibt Einstellungen für Routen mit öffentlichen Verkehrsmitteln an. Mit diesem Parameter können Sie die zurückgegebenen Optionen beeinflussen, anstatt die standardmäßige beste Route der API zu verwenden. Dieser Parameter darf nur für Routen für öffentliche Verkehrsmittel angegeben werden. Dieser Parameter unterstützt die folgenden Argumente:

  • less_walking gibt an, dass die berechnete Route möglichst wenige Gehstrecken enthalten soll.
  • fewer_transfers gibt an, dass die berechnete Route möglichst wenige Umstiege beinhalten soll.

Einheiten

Gibt das Einheitensystem an, das bei der Anzeige von Ergebnissen verwendet werden soll.

Routenergebnisse enthalten Text in Entfernungsfeldern, der dem Nutzer angezeigt werden kann, um die Entfernung eines bestimmten „Schritts“ der Route anzugeben. Standardmäßig wird für diesen Text das Einheitensystem des Ausgangslands bzw. der Ausgangsregion verwendet.

Bei einer Route von „Chicago, IL“ nach „Toronto, ONT“ werden die Ergebnisse also in Meilen angezeigt, für die Rückfahrt aber in Kilometern. Sie können das Einheitensystem überschreiben, indem Sie in der Anfrage explizit ein anderes System festlegen. Folgende Werte sind zulässig:

  • metric gibt an, dass das metrische System verwendet werden soll. Textentfernungen werden in Kilometern und Metern zurückgegeben.
  • imperial gibt an, dass das imperiale (englische) System verwendet werden soll. Entfernungen im Textformat werden in Meilen und Fuß zurückgegeben.
Hinweis: Die Einstellung für das Einheitensystem wirkt sich nur auf den Text aus, der in Entfernungsfeldern angezeigt wird. Die Entfernungsfelder enthalten auch Werte, die immer in Metern angegeben werden.

Wegpunkte

Achtung: Anfragen mit mehr als 10 Wegpunkten (zwischen 11 und 25) oder Wegpunktoptimierung werden zu einem höheren Preis abgerechnet. Weitere Informationen zur Abrechnung für Google Maps Platform-Produkte

Gibt ein Array von Zwischenorten an, die auf der Route zwischen Start- und Zielpunkt als Durchfahrts- oder Zwischenstopporte berücksichtigt werden sollen. Werden Wegpunkte angegeben, wird die Route so geändert, dass sie über die entsprechenden Orte führt. Die API unterstützt Wegpunkte für die Mobilitätsformen Autofahren, Gehen und Fahrradfahren, nicht jedoch für öffentliche Verkehrsmittel. Sie können einen oder mehrere Orte angeben, die durch das Pipe-Zeichen (| oder %7C) getrennt sind. Die Angabe kann in Form einer Orts-ID, einer Adresse oder von Breiten-/Längengradkoordinaten erfolgen. Standardmäßig berechnet der Directions-Dienst die Route über die Wegpunkte in der angegebenen Reihenfolge. Die Reihenfolge für das Parsen des Wegpunktwerts ist Orts-ID, Breiten-/Längengradkoordinaten und dann Adresse.

  • Wenn Sie eine Orts-ID übergeben, müssen Sie ihr das Präfix place_id: voranstellen. Sie können Orts-IDs aus der Geocoding API und der Places API (einschließlich Place Autocomplete) abrufen. Ein Beispiel für die Verwendung von Orts-IDs aus dem „Place Autocomplete“-Dienst finden Sie hier. Weitere Informationen finden Sie in der Übersicht zur Orts-ID.
    Verwenden Sie nach Möglichkeit Orts-IDs, um die Effizienz und Genauigkeit zu erhöhen. Diese IDs sind eindeutig, wie ein Paar aus Breiten- und Längengrad, und bieten Geocoding-Vorteile für das Routing, z. B. Zugangspunkte und Verkehrsvariablen. Im Gegensatz zu einer Adresse ist für IDs keine Suche oder Zwischenanfrage für Ortsdetails erforderlich. Daher ist die Leistung besser.
  • Wenn Sie Breiten-/Längengradkoordinaten übergeben, werden die Werte direkt an den Frontend-Server gesendet, um Routen ohne Geocoding zu berechnen. Die Punkte werden an Straßen ausgerichtet und bieten möglicherweise nicht die Genauigkeit, die Ihre App benötigt. Verwenden Sie Koordinaten, wenn Sie sicher sind, dass die Werte genau die Punkte angeben, die Ihre Anwendung für die Routenplanung benötigt, ohne dass mögliche Zugangspunkte oder zusätzliche Geocoding-Details berücksichtigt werden müssen. Achten Sie darauf, dass die Werte für Breiten- und Längengrad durch ein Komma (%2C) und nicht durch ein Leerzeichen (%20) getrennt sind.
  • Wenn Sie eine Adresse übergeben, wird der String vom Directions-Dienst geocodiert und in Breiten- und Längengradkoordinaten umgewandelt, um die Wegbeschreibung zu berechnen. Wenn der Adresswert mehrdeutig ist, kann der Wert eine Suche auslösen, um ihn von ähnlichen Adressen zu unterscheiden. Beispielsweise könnte „1st Street“ ein vollständiger Wert oder ein Teilwert für „1st Street NE“ oder „1st St SE“ sein. Dieses Ergebnis kann sich von dem der Geocoding API unterscheiden. Mit Orts-IDs können Sie mögliche Fehlinterpretationen vermeiden.
  • Alternativ können Sie eine codierte Gruppe von Punkten mit dem Algorithmus für codierte Polylinien angeben. Ein codierter Satz ist für eine große Anzahl von Wegpunkten nützlich, da die URL dadurch erheblich kürzer ist. Für alle Webdienste gilt ein URL-Limit von 16.384 Zeichen.
    • Codierten Polylinien muss enc: vorangestellt werden, gefolgt von einem Doppelpunkt (:). Beispiel: waypoints=enc:gfo}EtohhU:.
    • Sie können auch mehrere codierte Polylinien angeben, die durch das Pipe-Zeichen (|) getrennt sind. Beispiel: waypoints=via:enc:wc~oAwquwMdlTxiKtqLyiK:|enc:c~vnAamswMvlTor@tjGi}L:| via:enc:udymA{~bxM:

Routen mit Zwischenstopps und Wegpunkten beeinflussen

Für jeden Wegpunkt in der Anfrage wird der Routenantwort ein Eintrag im legs-Array hinzugefügt, der Details zu Zwischenstopps auf diesem Abschnitt der Route enthält.

Wenn Sie die Route mithilfe von Wegpunkten beeinflussen möchten, ohne einen Zwischenstopp hinzuzufügen, fügen Sie dem Wegpunkt das Präfix via: hinzu. Wegpunkte mit dem Präfix via: werden nicht dem Array legs hinzugefügt, aber die Route führt über den Wegpunkt.

Mit der folgenden URL wird die vorherige Anfrage so geändert, dass die Route ohne Zwischenstopp durch Lexington führt: 

https://maps.googleapis.com/maps/api/directions/json?
origin=Boston,MA&destination=Concord,MA
&waypoints=Charlestown,MA|via:Lexington,MA

Das Präfix via: ist am effektivsten, wenn Routen erstellt werden, nachdem der Nutzer die Wegpunkte auf der Karte gezogen hat. So kann der Nutzer sehen, wie die endgültige Route in Echtzeit aussehen könnte. Außerdem wird so sichergestellt, dass Wegpunkte an Orten platziert werden, die für die Directions API zugänglich sind.

Achtung: Wenn Sie das Präfix via: verwenden, um Aufenthalte zu vermeiden, wird der Wegpunkt sehr genau interpretiert. Wenn die Directions API keine Routen berechnen kann, die durch diesen Punkt führen, kann das zu erheblichen Umwegen auf der Route oder zu ZERO_RESULTS im Antwortstatuscode führen.

Wegpunkte optimieren

Standardmäßig berechnet der „Directions“-Dienst die Route über die Wegpunkte in der angegebenen Reihenfolge. Optional können Sie optimize:true als erstes Argument im Parameter „waypoints“ übergeben, damit der „Directions“-Dienst die Wegpunkte in eine effizientere Reihenfolge bringen kann, um die Route zu optimieren. Diese Optimierung ist eine Umsetzung des Rundreiseproblems. Die Route wird primär nach der Fahrzeit optimiert, es können aber auch andere Faktoren berücksichtigt werden, wie z. B. die Entfernung oder die Anzahl der Abzweige. Damit der „Directions“-Dienst die Route optimieren kann, müssen alle Wegpunkte als Aufenthalte definiert sein.

Wenn Sie den „Directions“-Dienst anweisen, die Reihenfolge der Wegpunkte zu optimieren, wird die Reihenfolge im Feld waypoint_order im Routenobjekt zurückgegeben. Das Feld waypoint_order gibt nullbasierte Werte zurück.

Im folgenden Beispiel wird eine Fahrt von Adelaide, South Australia, zu den wichtigsten Weinregionen von South Australia mithilfe der Routenoptimierung berechnet. 

https://maps.googleapis.com/maps/api/directions/json?
origin=Adelaide,SA&destination=Adelaide,SA
&waypoints=optimize:true|Barossa+Valley,SA|Clare,SA|Connawarra,SA|McLaren+Vale,SA

Bei der Prüfung der berechneten Route wird angezeigt, dass die Berechnung Wegpunkte in der folgenden Reihenfolge verwendet: 

"waypoint_order": [ 3, 2, 0, 1 ]
Achtung: Anfragen mit Wegpunktoptimierung werden zu einem höheren Preis abgerechnet. Weitere Informationen zur Abrechnung von Google Maps Platform-Produkten

Nächste Schritte

Beispiele für Wegbeschreibungen

Directions-Antworten