Festlegen, wie und ob Trafficdaten einbezogen werden sollen

Die von Ihnen ausgewählten Traffic-Einstellungen sorgen für ein Gleichgewicht zwischen der Genauigkeit der Routendetails und der Anfrageleistung. Wenn Sie eine Anfrage stellen, möchten Sie abwägen, ob es besser ist, möglichst genaue oder möglichst schnelle Ergebnisse zurückzugeben. Die Routes API bietet Optionen, mit denen Sie die Qualität der Antwortdaten im Vergleich zur Latenz der Antwort steuern können.

Ebene der Verkehrsdaten festlegen

Die Routes API bietet RoutingPreference (REST) und RoutingPreference (gRPC), mit denen Sie Routingeinstellungen für die Berechnung von Routen angeben können. Diese Präferenzen unterscheiden sich insofern, als dass dabei die Verkehrslage bei der Routenberechnung berücksichtigt wird. Jede Routingeinstellung erzeugt Ergebnisse, die sich in Bezug auf die Routenqualität, die geschätzte voraussichtliche Ankunftszeit und die Antwortlatenz bis zu einem gewissen Grad unterscheiden.

Die Verkehrslage beschreibt die Geschwindigkeit des Verkehrsflusses. Beispiel:

• Wenn es keine Staus gibt, wird die Verkehrslage als normal betrachtet und der Verkehr fließt mit normaler ungehinderter Geschwindigkeit.
• Kurz vor der Stoßzeit nimmt die Verkehrsdichte zu, was dazu führt, dass sich der Verkehr verlangsamt und die Verkehrslage gering bis mäßig ist.
• Im Bumper-zu-Bumper-Verkehr bricht die Geschwindigkeit zum Stillstand, was zu starken Verkehrsverhältnissen führt.

Traffic nicht erkannt

Wenn Sie die Routingeinstellung TRAFFIC_UNAWARE festlegen, werden Routen ohne Berücksichtigung der aktuellen Verkehrslage berechnet. Diese Routingeinstellung bietet die niedrigste Antwortlatenz. Antworten werden am schnellsten zurückgegeben.

TRAFFIC_UNAWARE ist die Standardeinstellung.

.

In der Antwort:

• Die voraussichtliche Ankunftszeit ist im Antwortattribut duration enthalten.

• Die Antwortattribute duration und staticDuration enthalten denselben Wert.

Verwenden Sie diese Routingeinstellung, wenn Antworten am schnellsten zurückgegeben werden sollen und ungefähre Routingdetails ausreichend sind.

Traffic-Erkennung

Wenn Sie die Routingeinstellung TRAFFIC_AWARE festlegen, werden Routen unter Berücksichtigung der aktuellen Verkehrslage berechnet. Dadurch spiegeln die Routen- und Routendetails reale Bedingungen genauer wider. Da diese Erhöhung der Datenqualität auf Kosten der Antwortlatenz führt, werden Leistungsoptimierungen angewendet, um die Latenz erheblich zu verringern.

In der Antwort:

• Die ETA unter Berücksichtigung des Echtzeit-Traffics ist im Antwortattribut duration enthalten.

• Das Antwortattribut staticDuration enthält die Reisedauer auf der Route ohne Berücksichtigung der Verkehrslage.

Verwenden Sie diese Routingeinstellung, wenn Sie genauere Routingdetails als TRAFFIC_UNAWARE benötigen und es Ihnen nichts ausmacht, wenn Antworten mit einer moderaten Erhöhung der Latenz zurückgegeben werden.

Traffic-Erkennung optimal

Wenn Sie die Routingeinstellung TRAFFIC_AWARE_OPTIMAL festlegen, werden die Routen unter Berücksichtigung der aktuellen Verkehrslage berechnet. Es werden jedoch keine Leistungsoptimierungen angewendet. In diesem Modus führt der Server eine umfassendere Suche im Straßennetz durch, um die optimale Route zu finden.

Die Routingeinstellung TRAFFIC_AWARE_OPTIMAL entspricht dem Modus, der von maps.google.com und der mobilen Google Maps App verwendet wird.

Wenn diese Option mit Compute Route Matrix verwendet wird, darf die Anzahl der Elemente in einer Anfrage (Anzahl der Startorte × Anzahl der Ziele) 100 nicht überschreiten. Weitere Informationen zu Limits in Compute Route Matrix finden Sie unter Routenmatrix berechnen.

In der Antwort:

• Die ETA unter Berücksichtigung des Echtzeit-Traffics ist im Antwortattribut duration enthalten.

• Das Antwortattribut staticDuration enthält die Reisedauer auf der Route ohne Berücksichtigung der Verkehrslage.

Diese Routingeinstellung bietet die höchste Antwortlatenz (d. h. Antworten mit der längsten Verzögerung). Verwenden Sie diese Routingeinstellung, wenn Sie Ergebnisse von höchster Qualität erhalten möchten, unabhängig davon, wie lange die Antworten dauern.

Auswirkungen der Festlegung der Abfahrtszeit

Mit dem Attribut departureTime können Sie optional die Abfahrtszeit einer Fahrt festlegen. Wenn Sie das Attribut departureTime nicht festlegen, wird standardmäßig der Zeitpunkt verwendet, zu dem Sie die Anfrage stellen.

• Für TRAFFIC_UNAWARE kann departureTime nicht festgelegt werden, da die Wahl der Route und der Reisezeit auf dem Straßennetz und der durchschnittlichen zeitunabhängigen Verkehrslage basiert.

• Für TRAFFIC_AWARE und TRAFFIC_AWARE_OPTIMAL, die die Bedingungen für Live-Traffic berücksichtigen, wird der Live-Traffic umso wichtiger, je näher der departureTime ist. Je weiter Sie eine in der Zukunft liegende Abfahrtszeit angeben, desto mehr wird die bisherige Verkehrslage berücksichtigt.

Beispiel für die Einstellung der Routingeinstellung

Der folgende JSON-Code zeigt, wie die Routingeinstellung im Entitätstext einer Anfragenachricht festgelegt wird.

{
  "origin":{
    "location":{
      "latLng":{
        "latitude":37.419734,
        "longitude":-122.0827784
      }
    }
  },
  "destination":{
    "location":{
      "latLng":{
        "latitude":37.417670,
        "longitude":-122.079595
      }
    }
  },
  "travelMode":"DRIVE",
  "routingPreference":"TRAFFIC_AWARE_OPTIMAL"
}

Qualität von Polylinien konfigurieren

Mit der Routes API können Sie Informationen zur Verkehrslage mithilfe einer verkehrsabhängigen Polylinie anfordern. Weitere Informationen finden Sie unter Polylinien anfordern.

Die Qualität einer Polylinie kann wie folgt beschrieben werden:

• Die Anzahl der Punkte, aus denen die Polylinie besteht

  Je mehr Punkte vorhanden sind, desto gleichmäßiger ist die Polylinie (insbesondere bei Kurven).

• Die Gleitkommagenauigkeit der Punkte

  Punkte werden als Breiten- und Längengradwerte angegeben, die im Gleitkommaformat mit einfacher Genauigkeit dargestellt werden. Dies funktioniert gut bei kleinen Werten, die genau dargestellt werden können. Die Genauigkeit nimmt jedoch bei steigenden Werten aufgrund von Rundungsfehlern ab.

Die Methode computeRoutes (REST) und die Methode ComputeRoutes (gRPC) unterstützen die Anfrageoption polylineQuality zur Steuerung der Qualität von Polylinien.

Beispiel für das Festlegen der Qualität von Polylinien

polylineQuality gibt die Qualität der Polylinie als HIGH_QUALITY oder OVERVIEW (Standard) an. Mit OVERVIEW besteht die Polylinie aus einer kleinen Anzahl von Punkten und hat eine geringere Anfragelatenz als HIGH_QUALITY.

Hier ein Beispiel für den Anfragetext:

{
  "origin":{
    "location":{
      "latLng":{
        "latitude": 37.419734,
        "longitude": -122.0827784
      }
    }
  },
  "destination":{
    "location":{
      "latLng":{
        "latitude": 37.417670,
        "longitude": -122.079595
      }
    }
  },
  "travelMode": "DRIVE",
  "routingPreference": "TRAFFIC_AWARE",
  "polylineQuality": "HIGH_QUALITY",
  "polylineEncoding": "ENCODED_POLYLINE", 
  "departureTime": "2023-10-15T15:01:23.045123456Z",
  ...
}