Najczęstsze pytania dotyczące interfejsu Isochrones API

Jak obliczyć izochronę dojazdu do pracy (podróż do miejsca docelowego) w porównaniu z izochroną wyjazdu (podróż z miejsca wyjazdu)?

W interfejsie API w wersji 1 obsługiwane są obliczenia zarówno dla ruchu przychodzącego, jak i wychodzącego, przy użyciu parametru travelDirection (travel_direction):

  • FROM (ruch wychodzący): oblicza obszar, do którego można dotrzeć from punktu początkowego w określonym czasie. Jest to przydatne w przypadku stref dostawy lokalnej lub obszarów świadczenia usług.

  • TO (przyjazd): oblicza obszar, z którego można dojechać to punktu początkowego w określonym czasie. Jest to przydatne w przypadku aplikacji takich jak funkcje dojazdu do pracy lub określanie stref zasięgu wokół centrali lub węzła transportu publicznego.

Czym różnią się 4 tryby podróży (DRIVE, TWO_WHEELER, BICYCLE i WALK)?

Każdy tryb korzysta z własnych reguł dostępu do sieci dróg, kosztów skrętu i modelu prędkości:

  • DRIVE: przejeżdża drogami przejezdnymi z opublikowaną lub swobodną prędkością albo z prędkością ruchu na żywo (TRAFFIC_AWARE) przez maksymalnie 3600 sekund (60 minut).
  • TWO_WHEELER: obejmuje drogi dostępne dla zmotoryzowanych pojazdów dwukołowych z niższymi modelowanymi prędkościami niż DRIVE na drogach szybkiego ruchu i opcjonalnym wyznaczaniem tras TRAFFIC_AWARE, do 3600 sekund (60 minut). W rezultacie izochrona TWO_WHEELER jest większa niż BICYCLE, ale mniejsza niż DRIVE wzdłuż autostrad.
  • BICYCLE: obejmuje ulice, ścieżki rowerowe i drogi dostępne dla rowerów, z prędkością dostosowaną do typu drogi i nachylenia (z wyłączeniem autostrad i dróg ekspresowych), do 7200 sekund (120 minut).
  • WALK: obejmuje chodniki, ścieżki i ulice z prędkością chodzenia dostosowaną do nachylenia (ignoruje ograniczenia dotyczące pojazdów jednokierunkowych), do 7200 sekund (120 minut).

Czy interfejs Isochrones API uwzględnia promy lub przeprawy wodne?

Nie. Interfejs Isochrones API przechodzi tylko przez drogi, mosty, tunele i ścieżki. Trasy promowe i przeprawy wodne są wykluczone we wszystkich trybach podróży. Wyspy lub półwyspy połączone tylko promem nie będą uwzględniane w izochronie wygenerowanej z lądu.

Czasami zwrócony wielokąt wygląda jak blok lub ma postrzępione, schodkowe krawędzie, zwłaszcza w przypadku dłuższych okresów. Dlaczego poziom szczegółowości się zmienia?

Interfejs Isochrones API dynamicznie dostosowuje rozdzielczość siatki obliczeń przestrzennych na podstawie żądanych wartości travel_duration i travel_mode:

  • Krótsze okresy: użyj bardzo precyzyjnej siatki o wysokiej rozdzielczości, ponieważ całkowity obszar jest mały, co pozwala uzyskać szczegółowe granice.
  • Dłuższe okresy: przejście na siatkę o mniejszej rozdzielczości, aby skutecznie objąć rozległy obszar geograficzny bez powodowania poważnych opóźnień.

Jeśli potrzebujesz określonego, spójnego poziomu szczegółowości niezależnie od czasu trwania, możesz ustawić opcjonalny parametr polygon_fidelity na HIGH, MEDIUM lub LOW.

Dlaczego żądanie izochrony dla współrzędnych w parku, jeziorze lub dużym kompleksie przemysłowym czasami zwraca błąd „Nie znaleziono”?

Interfejs Isochrones API oblicza czas podróży, korzystając z dróg i ścieżek. Jeśli żądane współrzędne miejsca początkowego nie znajdują się na rozpoznanej drodze, przed rozpoczęciem obliczeń interfejs API musi „przyciągnąć” punkt do najbliższego zgodnego segmentu.

Każdy środek transportu ma maksymalną odległość przyciągania wynoszącą około 200 metrów lub mniej. W przypadku opcji WALK i BICYCLE odległości są krótsze niż w przypadku opcji DRIVE i TWO_WHEELER, a opcje DRIVE i TWO_WHEELER ignorują ścieżki tylko dla pieszych.

Jeśli współrzędna punktu początkowego znajduje się dalej od prawidłowego, zgodnego z trybem segmentu drogi niż ta odległość, przyciąganie się nie powiedzie, a interfejs API zwróci błąd NOT_FOUND. Aby rozwiązać ten problem, upewnij się, że współrzędne są umieszczone blisko ulicy lub ścieżki publicznej.

Dlaczego podczas wysyłania żądania wyznaczania trasy z uwzględnieniem natężenia ruchu dla pieszych lub rowerzystów pojawia się błąd?

Aktualne warunki na drodze (TRAFFIC_AWARE) są obsługiwane w przypadku trybów podróży DRIVE i TWO_WHEELER. Jeśli spróbujesz poprosić o izochronę dla WALK lub BICYCLE z parametrem routingPreference ustawionym na TRAFFIC_AWARE, interfejs API zwróci błąd 400 INVALID_ARGUMENT.

Gdy renderuję odpowiedź GeoJSON na mapie, kształt wyświetla się w niewłaściwym miejscu, jest zniekształcony lub nie renderuje się. Co jest tego przyczyną?

Prawie zawsze jest to spowodowane niezgodnością kolejności współrzędnych.

Zgodnie ze standardem GeoJSON (RFC 7946) interfejs Isochrones API zwraca współrzędne w kolejności [longitude, latitude]. Jednak wiele pakietów SDK do mapowania i niestandardowych obiektów geometrycznych oczekuje współrzędnych w kolejności [latitude, longitude].

Jeśli mapa jest renderowana nieprawidłowo, sprawdź, jak pakiet SDK mapy obsługuje GeoJSON:

  • Google Maps JavaScript API: jeśli używasz warstwy danych (map.data.addGeoJson()), ta kolejność jest obsługiwana natywnie i nie musisz nic robić.
  • Obiekty niestandardowe lub inne pakiety SDK: jeśli ręcznie analizujesz odpowiedź na obiekty LatLng, musisz przed renderowaniem przejść w pętli przez współrzędne w ładunku GeoJSON i przekształcić wartości [lng, lat] w pary [lat, lng].

Dlaczego wewnątrz wielokąta izochrony znajdują się puste „dziury” i czy mogę zamiast tego uzyskać pełny kształt?

Otwory reprezentują obszary, do których nie można dotrzeć w określonym czasie. Często zdarza się to w regionach z dużymi lasami, zbiornikami wodnymi, lotniskami lub terenami prywatnymi, po których nie mogą poruszać się pojazdy ani piesi.

Zewnętrzny interfejs API w wersji 1 nie udostępnia parametru do automatycznego usuwania dziur. Jeśli aplikacja wymaga stałej granicy, np. do sprawdzania, czy punkt znajduje się w wielokącie, możesz:

  • Ustaw parametr polygon_fidelity na MEDIUM lub LOW, aby zachęcić algorytm do uogólniania i scalania tych wewnętrznych luk.
  • Użyj biblioteki GIS po stronie klienta (np. Turf.js), aby przeanalizować GeoJSON i wyodrębnić tylko pierwszy pierścień współrzędnych (zewnętrzną powłokę), odrzucając wszystkie kolejne pierścienie wewnętrzne (otwory).

Czy należy włączyć opcję enable_smoothing na potrzeby analizy przestrzennej backendu?

Nie. Parametr enable_smoothing służy wyłącznie do celów estetycznych. Zaokrągla ostre rogi siatki obliczeniowej, aby kształt wyglądał na mapie naturalnie.

Wygładzanie nie jest zalecane w przypadku precyzyjnej analizy przestrzennej, ponieważ zmienia wierzchołki i nieznacznie przesuwa granice. W przypadku obliczeń backendu, zapytań do bazy danych lub testów punktu w wielokącie ustaw enable_smoothing na false, aby mieć pewność, że używasz matematycznie precyzyjnie obliczonej granicy.