Best Practices für die Isochrones API

Glättung und Genauigkeit

Mit den Parametern polygon_fidelity und 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 (polygon_fidelity): Auflösung. Steuert die Größe der zugrunde liegenden räumlichen Rasterzellen, die zur Berechnung des erreichbaren Bereichs verwendet werden.

    • LOW: Verwendet die größten Rasterzellen (mehrere hundert Meter breit). Am besten geeignet, um große Bereiche ohne Lücken abzudecken und die Anzahl der Eckpunkte zu minimieren. Das Ergebnis ist eine verallgemeinerte Form, die den erreichbaren Bereich entlang schmaler Straßenkorridore überschätzen kann.
    • MEDIUM: Ausgewogene Genauigkeit und Nutzlastgröße.
    • HIGH: Verwendet die kleinsten Rasterzellen (ca. 100–150 Meter breit). Führt zu einer engeren Anpassung an das Straßennetz mit mehr Eckpunkten, kann aber zu Löchern im Inneren führen, wenn das Straßennetz dünn besetzt ist.
    • Standard (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, damit dieselbe Auflösung verwendet wird.

    Die Zellgrößen sind ungefähre Angaben. Sehr große Isochronen werden möglicherweise weiter generalisiert, um die Antwortgröße überschaubar zu halten.

  • enableSmoothing (enable_smoothing): Die Ästhetik. Steuert, ob die abgestuften Kanten der durch die Genauigkeit definierten Rasterzellen abgerundet werden.
    • false (Rohdaten): Gibt die am Raster ausgerichtete Grenze zurück. Die Kanten erscheinen gezackt oder gestuft, was die Rasterzellen widerspiegelt. Am besten für analytische Genauigkeit, z. B. strenge Punkt-in-Polygon-Tests.
    • true (Glätten): Rundet die Ecken ab, wobei die Fläche der einzelnen Ringe ungefähr erhalten bleibt. Am besten für die visuelle Darstellung auf Karten geeignet. Da die Grenze nicht mehr den Rasterzellen folgt, sollten Sie sie nicht für strenge Punkt-in-Polygon-Tests verwenden.

Interaktion: Die Detailtreue legt die Baseline-Details fest, auf die der Glättungsalgorithmus angewendet wird.

  • Hohe Wiedergabetreue + Glättung: Erzeugt eine detaillierte, organisch wirkende Form, die sich eng an die Straßenenden anpasst.
  • Niedrige Genauigkeit + Glättung: Erzeugt eine breite, verallgemeinerte „Blob“-Form.

Nutzlastgröße und Rendering

Große Isochronen (insbesondere Anfragen mit langer Dauer und HIGH-Genauigkeit) können Zehntausende von Koordinaten enthalten und die unkomprimierte JSON-Antwort kann mehrere Hundert Kilobyte oder mehr groß sein.

  • Bandbreite: Beachten Sie, dass die JSON-Antwortgröße bei Anfragen mit maximaler Dauer und hoher Genauigkeit erheblich ist.
  • Rendering: Das Rendern extrem detaillierter Polygone wirkt sich auf die Clientleistung aus. Wenn Sie die Anzahl der Eckpunkte und die Nutzlastgröße reduzieren möchten, wählen Sie polygonFidelity: MEDIUM oder LOW aus oder vereinfachen Sie die Geometrie auf dem Client vor dem Rendern mit einem Algorithmus zur Linienvereinfachung wie Douglas-Peucker.

Latenz und Client-Zeitüberschreitungen

Die Antwortlatenz steigt mit der Größe des durchquerten Straßennetzes: Kurze Dauern und die Modi WALK und BICYCLE sind am schnellsten, während lange DRIVE- und TWO_WHEELER-Anfragen (insbesondere mit TRAFFIC_AWARE) am längsten dauern.

  • Empfohlenes Client-Zeitlimit: Konfigurieren Sie HTTP- oder gRPC-Client-Fristen auf mindestens 30 Sekunden, damit lange Anfragen nicht vorzeitig durch ein kurzes Client-Zeitlimit abgebrochen werden.

Fehlerbehandlung

Implementieren Sie eine Wiederholungslogik mit exponentiellem Backoff und Jitter für 429 RESOURCE_EXHAUSTED-Ratenbegrenzungsantworten und 5xx-Serverfehler. Wiederholen Sie die Clientfehler 400, 403 oder 404 nicht, ohne die Anfrage zu ändern:

  • INVALID_ARGUMENT (400): Prüfen Sie, ob travelDuration zwischen 1s und 3600s (DRIVE/TWO_WHEELER) oder 7200s (WALK/BICYCLE) liegt, location nicht weggelassen wurde und nicht (0, 0) ist (oder place eine gültige Orts-ID ist) und TRAFFIC_AWARE nur mit DRIVE oder TWO_WHEELER verwendet wird. Wenn latitude oder longitude weggelassen wird, wird der Wert als 0.0 behandelt. Wenn nur einer der beiden Werte weggelassen wird, führt das in der Regel nicht zu einem 400-Fehler, es sei denn, der andere Wert ist ebenfalls 0.0. Prüfen Sie beide Werte, wenn die Isochrone an der falschen Stelle angezeigt wird.
  • PERMISSION_DENIED (403): Prüfen Sie, ob Ihr API-Schlüssel oder OAuth-Token enthalten ist und ob die Isochrones API und die Abrechnung für Ihr Google Cloud-Projekt aktiviert sind.
  • NOT_FOUND (404): Der place konnte keinem Ort zugeordnet werden oder der Startpunkt konnte nicht an eine nahe gelegene Straße angeglichen werden, die für den Reisemodus geeignet ist (innerhalb von etwa 200 Metern oder weniger für WALK und BICYCLE).
  • RESOURCE_EXHAUSTED (429): Ihr Projekt hat das Kontingent für Anfragen pro Minute überschritten (Standard: 300 Abfragen pro Minute). Wiederholungsversuche mit exponentiellem Backoff