FAQs zur Isochrones API

Wie berechne ich eine Isochrone für den Arbeitsweg (Fahrt zu einem Ziel) im Vergleich zu einer Isochrone für die Heimfahrt (Fahrt von einem Startpunkt)?

In der v1 API werden sowohl Berechnungen für eingehende als auch für ausgehende Routen unterstützt. Verwenden Sie dazu den Parameter travelDirection (travel_direction):

• FROM (Ausgehend): Berechnet das Gebiet, das innerhalb des angegebenen Zeitlimits from dem Ausgangspunkt erreichbar ist. Dies eignet sich für Anwendungsfälle wie Lieferzonen oder Serviceabdeckung.

• TO (Eingehend): Berechnet das Gebiet, von dem aus Sie innerhalb des angegebenen Zeitlimits to den Ausgangspunkt erreichen können. Das eignet sich für Anwendungen wie Funktionen für den Arbeitsweg oder die Bestimmung von Einzugsgebieten um ein zentrales Büro oder einen Verkehrsknotenpunkt.

Hinweis: Die Polygone FROM und TO für denselben Startpunkt und dieselbe Dauer können in jedem Modus asymmetrisch sein. Bei DRIVE, TWO_WHEELER und BICYCLE sind die Ursachen Einbahnstraßen und Abbiegebeschränkungen. Bei DRIVE und TWO_WHEELER tragen auch Autobahnauffahrten, Autobahnabfahrten und richtungsabhängige Verkehrsüberlastung dazu bei. Bei WALK und BICYCLE spielt auch die Steigung eine Rolle, da die Fahrt bergauf langsamer ist als bergab.

Wie unterscheiden sich die vier Mobilitätsformen (DRIVE, TWO_WHEELER, BICYCLE und WALK)?

Für jeden Modus gelten eigene Zugriffsregeln für das Straßennetz, Abbiegekosten und Geschwindigkeitsmodelle:

• DRIVE: Durchquert befahrbare Straßen mit den angegebenen Geschwindigkeiten oder Geschwindigkeiten bei ungehindertem Verkehrsfluss oder mit Echtzeit-Verkehrsgeschwindigkeiten (TRAFFIC_AWARE) bis zu 3.600 Sekunden (60 Minuten).
• TWO_WHEELER: Fährt auf Straßen, die für motorisierte Zweiräder zugänglich sind, mit niedrigeren modellierten Geschwindigkeiten als DRIVE auf Schnellstraßen und optionaler TRAFFIC_AWARE-Routenplanung, bis zu 3.600 Sekunden (60 Minuten). Daher ist eine Isochrone von TWO_WHEELER größer als BICYCLE, aber kleiner als DRIVE entlang von Autobahnen.
• BICYCLE: Führt über für Fahrräder zugängliche Straßen, Radfahrstreifen und Wege, wobei die Geschwindigkeit an den Straßentyp und die Steigung angepasst wird (Autobahnen und Schnellstraßen ausgenommen). Die maximale Dauer beträgt 7.200 Sekunden (120 Minuten).
• WALK: Fußgängerwege, Pfade und Straßen werden mit einer an die Steigung angepassten Gehgeschwindigkeit (Einbahnstraßenbeschränkungen für Fahrzeuge werden ignoriert) bis zu 7.200 Sekunden (120 Minuten) zurückgelegt.

Berücksichtigt die Isochrones API Fähren oder Wasserüberquerungen?

Nein. Die Isochrones API berücksichtigt nur Straßen-, Brücken-, Tunnel- und Wegverbindungen. Fährrouten und Wasserüberquerungen sind für alle Reisemodi ausgeschlossen. Inseln oder Halbinseln, die nur mit einer Fähre erreichbar sind, werden nicht in eine Isochrone einbezogen, die vom Festland aus generiert wird.

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 sehr feines, hochauflösendes Raster, da die Gesamtfläche klein ist und so eine detaillierte Grenze entsteht.
• Längere Zeiträume: Wechsel zu einem gröberen Raster mit niedrigerer Auflösung, um das große geografische Gebiet effizient abzudecken, ohne dass es zu erheblichen Latenzen kommt.

Sie können den optionalen polygon_fidelity auf HIGH, MEDIUM oder LOW festlegen, wenn Sie unabhängig von der Dauer einen bestimmten, konsistenten Detaillierungsgrad benötigen.

Warum wird beim Anfordern einer Isochrone für eine Koordinate in einem Park, See oder großen Industriekomplex manchmal der Fehler „Nicht gefunden“ zurückgegeben?

Die Isochrones API berechnet die Reisedauer anhand von Straßen und Wegen. Die API muss den Punkt am nächstgelegenen kompatiblen Segment „einrasten“, bevor die Berechnung gestartet wird, wenn sich die angeforderten Startkoordinaten nicht auf einer erkannten Straße befinden.

Für jeden Mobilitätstyp gilt eine maximale Einrastentfernung von etwa 200 Metern oder weniger. WALK und BICYCLE verwenden kürzere Entfernungen als DRIVE und TWO_WHEELER. Bei DRIVE und TWO_WHEELER werden reine Fußgängerwege ignoriert.

Wenn die Entfernung zwischen der Ausgangskoordinate und einem gültigen, mit dem Modus kompatiblen Straßensegment größer ist als dieser Wert, schlägt das Einrasten fehl und die API gibt den Fehler NOT_FOUND zurück. Achten Sie darauf, dass sich die Koordinaten in der Nähe einer öffentlichen Straße oder eines öffentlichen Wegs befinden.

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

Die aktuelle Verkehrslage (TRAFFIC_AWARE) wird für die Mobilitätsformen 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 den Fehler 400 INVALID_ARGUMENT zurück.

Wenn ich die GeoJSON-Antwort auf meiner Karte rendere, wird die Form an der falschen Stelle angezeigt, ist verzerrt oder wird nicht gerendert. Woran liegt das?

Dies wird fast immer durch eine falsche Reihenfolge der Koordinaten verursacht.

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

Wenn Ihre Karte nicht richtig gerendert wird, prüfen Sie, wie Ihr Karten-SDK GeoJSON verarbeitet:

• Google Maps JavaScript API:Wenn Sie die Datenebene (map.data.addGeoJson()) verwenden, wird diese Reihenfolge nativ verarbeitet und Sie müssen nichts weiter tun.
• 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 transponieren.

Warum gibt es „Löcher“ in meinem Isochronen-Polygon und kann ich stattdessen eine durchgehende Form erhalten?

Löcher stellen Bereiche dar, in denen innerhalb des Zeitlimits keine Straßen erreichbar sind. Das ist in Regionen mit großen Wäldern, Gewässern, Flughäfen oder Privatgrundstücken üblich, die für Fahrzeuge oder Fußgänger nicht zugänglich sind.

Die externe v1 API stellt keinen Parameter zum automatischen Entfernen von Löchern bereit. Wenn Ihre Anwendung eine feste Grenze erfordert, z. B. um zu prüfen, ob ein Punkt innerhalb eines Polygons liegt, können Sie Folgendes tun:

• Legen Sie für den Parameter polygon_fidelity den Wert MEDIUM oder LOW fest, damit der Algorithmus diese internen Lücken verallgemeinert und zusammenführt.
• Verwenden Sie eine clientseitige GIS-Bibliothek (z. B. Turf.js), um das GeoJSON-Objekt 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 Analyse im Backend aktivieren?

Nein. Der Parameter enable_smoothing dient rein der Optik. Die scharfen Ecken des zugrunde liegenden Berechnungsrasters werden abgerundet, damit die Form auf einer Karte organisch aussieht.

Die Glättung wird für präzise räumliche Analysen nicht empfohlen, da sie die Eckpunkte ändert und die Grenzen leicht verschiebt. Für Backend-Berechnungen, Datenbankabfragen oder Point-in-Polygon-Tests sollten Sie enable_smoothing auf false setzen, damit die mathematisch genaue berechnete Grenze verwendet wird.