FAQs zur Isochrones API

Wie berechne ich eine eingehende Isochrone für den Arbeitsweg (Reise zu einem Zielort) im Vergleich zu einer ausgehenden Isochronen (Reise von einem Ausgangspunkt)?

Sowohl eingehende als auch ausgehende Berechnungen werden in der v1 API mit dem Parameter travel_direction unterstützt:

• FROM (Ausgehend): Berechnet den Bereich, der from Ausgangspunkt innerhalb des angegebenen Zeitlimits erreichbar ist. Dies ist für Anwendungsfälle wie Lieferzonen oder Serviceabdeckung geeignet.

• TO (Eingehend): Berechnet den Bereich, von dem aus Sie innerhalb des angegebenen Zeitlimits to dem Ausgangspunkt reisen können. Dies ist für Anwendungen wie Funktionen für den Arbeitsweg oder die Bestimmung von Einzugsgebieten um ein zentrales Büro oder einen Verkehrsknotenpunkt geeignet.

Manchmal sieht das zurückgegebene Polygon blockartig aus oder hat gezackte, stufenförmige Kanten, insbesondere bei längeren Zeiträumen. Warum ändert sich der Detaillierungsgrad?

Die Isochrones API passt die Auflösung des räumlichen Berechnungsrasters dynamisch an die angeforderte travel_duration und travel_mode an:

• Kürzere Zeiträume: Verwenden Sie ein hochauflösendes Raster mit hoher Auflösung, da die Gesamtfläche klein ist, was zu einer detaillierten Grenze führt.
• Längere Zeiträume: Wechseln Sie zu einem gröberen Raster mit niedrigerer Auflösung, um das große geografische Gebiet effizient abzudecken, ohne zu einer erheblichen Latenz zu führen.

Sie können die optionale polygon_fidelity auf HIGH, MEDIUM oder LOW setzen, wenn Sie unabhängig von der Dauer einen bestimmten, einheitlichen Detaillierungsgrad benötigen.

Warum wird manchmal ein „Nicht gefunden“-Fehler zurückgegeben, wenn eine Isochrone für eine Koordinate in einem Park, See oder großen Industriekomplex angefordert wird?

Die Isochrones API berechnet die Reisezeiten anhand von Straßen und Wegen. Die API muss den Punkt an das nächste kompatible Segment „anpassen“, bevor die Berechnung gestartet wird, wenn sich die angeforderten Ausgangskoordinaten nicht auf einer erkannten Straße befinden.

Für jeden Reisemodus gibt es einen bestimmten maximalen Schwellenwert für die Anpassungsentfernung:

• DRIVE: 200 Meter (Fußwege werden ignoriert).
• TWO_WHEELER: 200 Meter (Fußwege werden ignoriert).
• BICYCLE: 180 Meter.
• WALK: 150 Meter.

Wenn Ihre Ausgangskoordinate weiter von einem gültigen, moduskompatiblen Straßensegment entfernt ist als diese Schwellenwerte, schlägt die Anpassung fehl und die API gibt einen NOT_FOUND-Fehler zurück. Achten Sie darauf, dass sich Ihre Koordinaten in der Nähe einer öffentlichen Straße oder eines öffentlichen Wegs befinden, um dieses Problem zu beheben.

Warum erhalte ich einen Fehler, wenn ich eine verkehrsabhängige Routenplanung für Fußgänger oder Radfahrer anfordere?

Verkehrslage in Echtzeit (TRAFFIC_AWARE) wird für die Reisemodi DRIVE und TWO_WHEELER unterstützt. Wenn Sie versuchen, eine Isochrone für WALK oder BICYCLE anzufordern, wobei routingPreference auf TRAFFIC_AWARE gesetzt ist, gibt die API einen 400 INVALID_ARGUMENT-Fehler zurück.

Wenn ich die GeoJSON-Antwort auf meiner Karte rendere, wird die Form an der falschen Stelle angezeigt, ist verzerrt oder kann nicht gerendert werden. Was ist die Ursache dafür?

Dies wird fast immer durch eine falsche Koordinatenreihenfolge verursacht.

Gemäß dem GeoJSON-Standard (RFC 7946) gibt die Isochrones API Koordinaten in der Reihenfolge [longitude, latitude] zurück. Viele Mapping-SDKs und benutzerdefinierte Geometrieobjekte erwarten jedoch Koordinaten in der Reihenfolge [latitude, longitude].

Wenn die Kartendarstellung falsch ist, prüfen Sie, wie Ihr Karten-SDK GeoJSON verarbeitet:

• Google Maps JavaScript API:Wenn Sie den Data Layer (map.data.addGeoJson()) verwenden, wird diese Reihenfolge nativ verarbeitet und es sind keine Maßnahmen erforderlich.
• Benutzerdefinierte Objekte oder andere SDKs:Wenn Sie die Antwort manuell in LatLng-Objekte parsen, müssen Sie die Koordinaten in der GeoJSON-Nutzlast durchlaufen und die [lng, lat]-Werte vor dem Rendern in [lat, lng]-Paare umwandeln.

Warum gibt es in meinem Isochronenpolygon hohle „Löcher“ und kann ich stattdessen eine durchgehende Form erhalten?

Löcher stellen Bereiche ohne erreichbare Straßen innerhalb des Zeitlimits dar. Dies ist in Regionen mit großen Wäldern, Gewässern, Flughäfen oder Privatgrundstücken üblich, in denen Fahrzeuge oder Fußgänger nicht unterwegs sein können.

Die externe v1 API bietet keinen Parameter, um Löcher automatisch zu entfernen. Wenn Ihre Anwendung eine durchgehende Grenze erfordert, z. B. um Containment-Prüfungen für Punkte in Polygonen durchzuführen, haben Sie folgende Möglichkeiten:

• Setzen Sie den Parameter polygon_fidelity auf MEDIUM oder LOW, damit der Algorithmus diese internen Lücken verallgemeinert und zusammenführt.
• Verwenden Sie eine clientseitige GIS-Bibliothek wie Turf.js, um das GeoJSON zu parsen und nur den ersten Koordinatenring (die äußere Hülle) zu extrahieren. Alle nachfolgenden inneren Ringe (die Löcher) werden verworfen.

Sollte ich die Option enable_smoothing für die räumliche Backend-Analyse aktivieren?

Nein. Der Parameter enable_smoothing ist ausschließlich für die visuelle Ästhetik gedacht. Er rundet die scharfen Ecken des zugrunde liegenden Berechnungsrasters ab, damit die Form auf einer Karte organischer aussieht.

Die Glättung wird für präzise räumliche Analysen nicht empfohlen, da sie die Eckpunkte verändert und die Grenzen leicht verschiebt. Setzen Sie für Backend-Berechnungen, Datenbankabfragen oder Punkt-in-Polygon-Tests enable_smoothing auf false, um sicherzustellen, dass Sie die mathematisch präzise berechnete Grenze verwenden.