FAQs zur Isochrones API

Warum kann ich eine Isochrone für Fußgänger oder Radfahrer für bis zu 2 Stunden anfordern, für Autofahrer jedoch nur für 1 Stunde?

Diese Einschränkung basiert auf der Rechenkomplexität der Berechnungen. Ein Fahrzeug legt in derselben Zeit eine deutlich größere Strecke zurück als ein Fußgänger oder Radfahrer. Das zugrunde liegende Straßennetz, das analysiert werden muss, wird dadurch exponentiell größer. Die Fahrzeit ist auf maximal eine Stunde (3.600 Sekunden) begrenzt, damit die API innerhalb eines schnellen, synchronen Echtzeitfensters eine Antwort zurückgeben kann. Für Fußgänger und Radfahrer werden bis zu zwei Stunden (7.200 Sekunden) unterstützt.

Wie berechne ich eine Isochrone für den Arbeitsweg (zum Zielort) im Vergleich zu einer Isochrone für die Abreise (vom Startort)?

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

• FROM (Ausgehend): Berechnet die Fläche, die from dem Ausgangspunkt innerhalb des angegebenen Zeitlimits erreicht werden kann. 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 zum Ausgangspunkt gelangen können. Dies eignet sich für Anwendungen wie Pendelstrecken zur Arbeit oder zur Bestimmung von Einzugsgebieten um ein zentrales Büro oder einen Verkehrsknotenpunkt.

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, da die Gesamtfläche klein ist und sich daraus eine detaillierte Grenze ergibt.
• Längere Zeiträume: Übergang 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 Parameter polygon_fidelity auf HIGH, MEDIUM oder LOW festlegen, wenn Sie unabhängig von der Dauer ein bestimmtes, einheitliches Detaillierungsniveau benötigen.

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

Mit der Isochrones API werden Reisezeiten anhand von Straßen und Wegen berechnet. Die API muss den Punkt an das nächstgelegene kompatible Segment „anpassen“, bevor die Berechnung beginnt, wenn sich die angeforderten Koordinaten des Startpunkts nicht auf einer erkannten Straße befinden.

Für jedes Verkehrsmittel gilt ein bestimmter maximaler Threshold für das Andocken:

• DRIVE: 200 Meter (nur für Fußgänger bestimmte Wege werden ignoriert).
• BICYCLE: 180 Meter.
• WALK: 150 Meter.

Wenn die Koordinaten des Startpunkts weiter von einem gültigen, moduskompatiblen Straßenabschnitt entfernt sind als diese Grenzwerte, schlägt das Andocken 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, um das Problem zu beheben.

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?

Das liegt fast immer an einer falschen Reihenfolge der Koordinaten.

Gemäß dem GeoJSON-Standard (RFC 7946) gibt die Isochrones API Koordinaten in der Reihenfolge [longitude, latitude] zurück. Viele Mapping-SDKs, darunter die Google Maps JavaScript API und verschiedene mobile Kartenkomponenten, erwarten jedoch Koordinaten oder LatLng-Objekte in der Reihenfolge [latitude, longitude].

Wenn die Karte falsch gerendert wird, müssen Sie die Koordinaten in der GeoJSON-Nutzlast durchlaufen und die Werte transponieren, bevor Sie sie an Ihr Karten-SDK übergeben.

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

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

In der externen v1 API ist kein Parameter verfügbar, mit dem Löcher automatisch entfernt werden können. Wenn für Ihre Anwendung eine durchgehende Begrenzung erforderlich ist, z. B. um Point-in-Polygon-Containment-Prüfungen durchzuführen, haben Sie folgende Möglichkeiten:

• 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 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 rein für die visuelle Ästhetik gedacht. Die scharfen Ecken des zugrunde liegenden Berechnungsrasters werden abgerundet, damit die Form auf einer Karte natürlich aussieht.

Für eine genaue räumliche Analyse ist die Glättung nicht empfehlenswert, da sie die Eckpunkte verändert und die Grenzen leicht verschiebt. Für Backend-Berechnungen, Datenbankabfragen oder Point-in-Polygon-Tests sollte enable_smoothing auf false gesetzt sein, damit die mathematisch präzise berechnete Grenze verwendet wird.