Wichtige Konzepte

Wenn Sie eine Isochrone generieren möchten, müssen Sie der API einen Startpunkt, ein Verkehrsmittel (z. B. Auto, Zweirad, Fahrrad oder zu Fuß) und ein Zeitlimit übergeben. Sie können auch die Routeneinstellungen und das Erscheinungsbild des resultierenden Polygons anpassen.

Mobilitätsformen

Verwenden Sie den erforderlichen Parameter travelMode (travel_mode), um das Verkehrsmittel anzugeben:

• DRIVE: Berechnet die Erreichbarkeit für einen Pkw auf befahrbaren Straßen unter Berücksichtigung der zulässigen Höchstgeschwindigkeit, der Straßenhierarchie, der Abbiegestrafen und (optional) der aktuellen Verkehrslage.
• TWO_WHEELER: Berechnet die Erreichbarkeit für ein motorisiertes Zweirad (z. B. ein Motorrad oder einen Roller) anhand von modusspezifischen Regeln für den Straßenzugang und niedrigeren modellierten Geschwindigkeiten als DRIVE auf Schnellstraßen. Daher deckt eine Isochrone von TWO_WHEELER in der Regel einen Bereich ab, der größer als BICYCLE, aber kleiner als DRIVE entlang von Schnellstraßen ist.
• BICYCLE: Berechnet die Erreichbarkeit für Radfahrer auf Straßen, Radfahrstreifen und gemeinsam genutzten Wegen, die für Fahrräder zugänglich sind. Die Geschwindigkeit wird an den Straßentyp und die Steigung angepasst. Autobahnen und Schnellstraßen mit eingeschränktem Zugang werden ausgeschlossen.
• WALK: Berechnet die Erreichbarkeit für Fußgänger auf Gehwegen, Fußwegen, Pfaden und für Fußgänger zugänglichen Straßen, wobei die Gehgeschwindigkeit an die Steigung angepasst wird. Bei der Fußgängernavigation werden Einbahnstraßenbeschränkungen für Fahrzeuge ignoriert.

Hinweis: Fähren und Wasserüberquerungen
Die Isochrones API berücksichtigt nur Straßen, Brücken, Tunnel und Wege. Fährrouten und Wasserüberquerungen werden bei der Berechnung der Erreichbarkeit für alle Mobilitätsformen ausgeschlossen. Inseln oder Halbinseln, die nur mit einer Fähre erreichbar sind, werden in der generierten Isochrone nur angezeigt, wenn sich der Startpunkt selbst auf dieser Landmasse befindet.

Zeithorizont

Die primäre Einschränkung, die Sie für den Dienst angeben, ist die travelDuration (travel_duration). Damit wird der Zeithorizont für die Berechnung definiert.

• Mindest- und Höchstdauer: Die Dauer muss mindestens "1s" (1 Sekunde) betragen. Null ("0s"), negative Dauern und Dauern unter einer Sekunde (z. B. "0.5s") geben einen 400 INVALID_ARGUMENT-Fehler zurück. Die API unterstützt eine maximale Reisedauer von 3.600 Sekunden (1 Stunde) für die Modi DRIVE und TWO_WHEELER und 7.200 Sekunden (2 Stunden) für die Modi WALK und BICYCLE.
• Mindestgröße des Polygons: Da die API erreichte Straßensegmente in räumliche Rasterzellen umwandelt, wird bei sehr kurzen Dauern ein kleines Polygon zurückgegeben, das die Rasterzellen um den eingerasteten Startpunkt abdeckt.
• Leistung: Die Berechnungszeit hängt von der angeforderten Dauer und dem ausgewählten Mobilitätsmodus ab. Eine Isochrone für eine einstündige Autofahrt deckt ein deutlich größeres geografisches Gebiet und Straßennetz ab als eine Isochrone für einen einstündigen Fußweg. Das führt zu einer höheren Latenz bei der Anfrage für die Autofahrt.
• Formatierung: Da die API google.protobuf.Duration verwendet, muss die Dauer als String formatiert werden, der mit einem "s" endet (z. B. "3600s") und nicht mit einer Ganzzahl.

Ursprungspunkte und Einrasten an Straßen

Sie haben zwei Möglichkeiten, den Startpunkt für die Isochrone anzugeben:

• Koordinaten (location): Ein Paar aus Breiten- und Längengrad. Geben Sie sowohl latitude (in [-90, 90]) als auch longitude (in [-180, 180]) an. Wenn Sie einen der beiden Werte weglassen, wird er von der API als 0.0 behandelt, wodurch der Punkt auf dem Äquator oder dem Nullmeridian platziert wird. Wenn Sie beide weglassen ({}) oder (0, 0) senden, gibt die API den Fehler 400 INVALID_ARGUMENT zurück.
• Orts-IDs (place): Eine eindeutige Kennung für einen bestimmten Ort auf Google Maps. Wenn Sie eine Orts-ID angeben, löst der Dienst den Ort in seine Schwerpunktkoordinate auf und fängt diesen Punkt an der nächstgelegenen Straße. Verwenden Sie das Format für Ressourcennamen, das mit places/ beginnt (z. B. places/ChIJIQBpAG2ahYAR_6128GcTUEo). Eine einfache Orts-ID ohne das Präfix places/ wird ebenfalls akzeptiert. Weitere Informationen zu Orts-IDs finden Sie unter Orts-IDs.

Unabhängig von der Eingabemethode berechnet die API die Reisedauer nicht vom genauen physischen Punkt, wenn dieser nicht auf einer Straße liegt, z. B. in einem Park oder Gebäude. Um diese Situation zu bewältigen, verwendet der Dienst das Einrasten auf Straßen. Das Einrasten auf Straßen hat die folgenden Funktionen:

• Intelligentes Einrasten: Der Dienst versucht, den Startpunkt am nächstgelegenen befahrbaren Straßensegment einrasten zu lassen.
• Modusbewusstsein: Die Einrastlogik berücksichtigt Ihren travel_mode. Wenn Sie DRIVE oder TWO_WHEELER anfordern, ignoriert die API reine Fußgängerwege und sucht nach der nächstgelegenen befahrbaren Straße. Wenn Sie WALK anfordern, priorisiert die API Fußgängerwege und Bürgersteige.
• Fehlerfälle: Wenn die API innerhalb der maximalen Einrastentfernung Ihres Ausgangspunkts (ca. 200 Meter oder weniger für WALK und BICYCLE) kein geeignetes Straßensegment findet, gibt sie den Fehler 404 NOT_FOUND zurück. Bei großen geografischen Elementen wie Parks, Campussen oder Aussichtspunkten kann der Schwerpunkt der Orts-ID weiter als die Fangentfernung von der nächsten Straße entfernt sein, die für den Reisemodus verwendet werden kann. Geben Sie in solchen Fällen stattdessen die expliziten location-Koordinaten einer Straßeneinfahrt an.

Fahrtrichtung (stadteinwärts oder stadtauswärts)

Mit dem Parameter travelDirection (travel_direction) können Sie sowohl die eingehende als auch die ausgehende Erreichbarkeit berechnen:

• FROM (Ausgehend): Berechnet das Gebiet, das vom Startpunkt aus innerhalb des angegebenen Zeitlimits erreichbar ist. Dies eignet sich für Anwendungsfälle wie Lieferzonen oder Serviceabdeckung.
• TO (Inbound): Berechnet das Gebiet, von dem aus Sie innerhalb des angegebenen Zeitlimits zum Ausgangspunkt gelangen können. Dies eignet sich für die Bestimmung von Einzugsgebieten, z. B. von wo aus Mitarbeiter zu einem zentralen Büro pendeln können.

Hinweis: FROM- und TO-Isochronen für denselben Startpunkt können sich in Form und Fläche in jedem Modus unterscheiden. Für DRIVE, TWO_WHEELER und BICYCLE werden Einbahnstraßen und Abbiegebeschränkungen berücksichtigt. Bei DRIVE und TWO_WHEELER tragen auch Autobahnauffahrten und Staus in eine Richtung dazu bei. Bei WALK und BICYCLE spielt auch die Steigung eine Rolle, da die Fahrt bergauf langsamer ist als bergab. Daher sind WALK-Polygone nur auf flachem Gelände nahezu identisch.

Verkehrsbewusstsein

Mit dem Parameter routingPreference (routing_preference) können Sie steuern, wie sich Verkehrsdaten auf das generierte Polygon auswirken:

• TRAFFIC_UNAWARE (Standard): Verwendet Geschwindigkeitsbegrenzungen bei ungehindertem Verkehrsfluss und die Straßenhierarchie, um das Isochronenpolygon zu generieren. Dadurch entsteht eine deterministische Form, die nicht je nach Tageszeit schwankt. Dieser Parameter eignet sich ideal für allgemeine Analysen oder die Planung von Baseline-Szenarien.
• TRAFFIC_AWARE: Berechnet Isochronen anhand der aktuellen Verkehrslage zum Zeitpunkt der Verarbeitung der Anfrage. Benutzerdefinierte zukünftige oder historische Abfahrts- oder Ankunftszeitstempel können in Version 1 nicht konfiguriert werden. Dadurch schrumpft der erreichbare Bereich bei hohem Verkehrsaufkommen und vergrößert sich bei geringem Verkehrsaufkommen. Bei ungehindertem Verkehrsfluss oder geringem Verkehrsaufkommen können TRAFFIC_AWARE und TRAFFIC_UNAWARE nahezu identische Polygone zurückgeben. Hinweis: Die Berücksichtigung der aktuellen Verkehrslage wird nur unterstützt, wenn travelMode auf DRIVE oder TWO_WHEELER festgelegt ist.

Hinweis: Für verkehrsabhängige Isochronen müssen Echtzeit-Straßengeschwindigkeiten abgerufen werden. Sie haben eine höhere Latenz als verkehrsunabhängige Isochronen.

Glättung und Genauigkeit

Mit den Parametern polygonFidelity (polygon_fidelity) und enableSmoothing (enable_smoothing) können Sie das Aussehen und die Genauigkeit der Ausgabepolygone anpassen. Diese Optionen sind zwar unabhängig voneinander, bestimmen aber zusammen die endgültige Form.

• polygonFidelity: Steuert die Auflösung der räumlichen Rasterzellen, die zur Annäherung an die erreichbare Grenze verwendet wird:

  • LOW: Verwendet die größten Rasterzellen (mehrere hundert Meter breit). Am besten geeignet, um große Bereiche mit weniger Eckpunkten und ohne interne Lücken abzudecken. Das Ergebnis ist eine verallgemeinerte Form, die den erreichbaren Bereich entlang schmaler Straßenkorridore überschätzen kann.
  • MEDIUM: Ausgewogene Genauigkeit und Anzahl der Eckpunkte.
  • HIGH: Verwendet die kleinsten Rasterzellen (ca. 100–150 Meter breit). Führt zu einer engeren Anpassung an das erreichte Straßennetz, kann aber zu Löchern im Inneren führen, wenn das Straßennetz dünn besiedelt ist.
  • POLYGON_FIDELITY_UNSPECIFIED: Wenn keine Angabe gemacht wird, wählt der Dienst die Auflösung automatisch anhand des Mobilitätsmodus und der Dauer aus. Dabei werden für kurze Dauern und für WALK feinere Zellen und für lange Dauern gröbere Zellen verwendet. Wenn Sie Isochronen für verschiedene Dauern oder Mobilitätsformen vergleichen möchten, legen Sie polygonFidelity explizit fest.

    

    Hohe, mittlere und niedrige Polygon-Genauigkeit

• enableSmoothing: Steuert, ob die gestuften Kanten der durch die Genauigkeit definierten Rasterzellen abgerundet werden.

  • false (Rohdaten): Standardeinstellung. Gibt die am Raster ausgerichtete Grenze zurück. Kanten werden entlang der Rasterzellen abgestuft dargestellt. Am besten für analytische Genauigkeit, z. B. strenge Punkt-in-Polygon-Tests.
  • true (geglättet): Scharfe Ecken werden für die visuelle Kartendarstellung abgerundet, wobei die Fläche jedes Rings ungefähr erhalten bleibt. Die Grenze folgt nicht mehr den Rasterzellen.

    

    Isochrone mit und ohne Glättung