Najczęstsze pytania dotyczące interfejsu Isochrones API

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

Obliczenia dojazdu do pracy i dojazdu z pracy są obsługiwane w interfejsie API w wersji 1 za pomocą parametru travel_direction:

  • FROM (dojazd z pracy): oblicza obszar, do którego można dotrzeć from punktu początkowego w określonym czasie. Nadaje się do przypadków użycia, takich jak strefy dostawy lub zasięg usług.

  • TO (dojazd do miasta): oblicza obszar, z którego można dotrzeć to do punktu początkowego w określonym czasie. Nadaje się do aplikacji takich jak funkcje dojazdu do pracy lub określanie stref dojazdu wokół centralnego biura lub węzła komunikacyjnego.

Czasami zwracany wielokąt wygląda na blokowy lub ma poszarpane, schodkowe krawędzie, zwłaszcza w przypadku dłuższych czasów trwania. Dlaczego zmienia się poziom szczegółowości?

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

  • Krótsze czasy trwania: używaj bardzo dokładnej siatki o wysokiej rozdzielczości, ponieważ całkowity obszar jest mały, co daje szczegółową granicę.
  • Dłuższe czasy trwania: przejdź na siatkę o niższej rozdzielczości, aby efektywnie pokryć duż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 czasami, gdy proszę o izochronę dla współrzędnych w parku, jeziorze lub dużym kompleksie przemysłowym, otrzymuję błąd „Nie znaleziono”?

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

Każdy tryb podróży ma określony maksymalny próg odległości przyciągania:

  • DRIVE: 200 metrów (ignoruje ścieżki tylko dla pieszych).
  • TWO_WHEELER: 200 metrów (ignoruje ścieżki tylko dla pieszych).
  • BICYCLE: 180 metrów.
  • WALK: 150 metrów.

Jeśli współrzędne początkowe znajdują się dalej od prawidłowego segmentu drogi zgodnego z trybem niż te progi, przyciąganie nie powiedzie się, a interfejs API zwróci błąd NOT_FOUND. Aby rozwiązać ten problem, upewnij się, że współrzędne znajdują się blisko ulicy lub ścieżki publicznej.

Dlaczego podczas żądania wyznaczania trasy z uwzględnieniem ruchu pieszego lub rowerowego otrzymuję błąd?

Warunki ruchu w czasie rzeczywistym (TRAFFIC_AWARE) są obsługiwane w trybach podróży DRIVE i TWO_WHEELER. Jeśli spróbujesz poprosić o izochronę dla trybu 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 jest wyświetlany w niewłaściwym miejscu, jest zniekształcony lub nie jest renderowany. 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 renderowanie mapy jest nieprawidłowe, sprawdź, jak pakiet SDK do mapowania 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 podejmować żadnych działań.
  • Obiekty niestandardowe lub inne pakiety SDK: jeśli ręcznie analizujesz odpowiedź na obiekty LatLng, musisz przejść przez współrzędne w ładunku GeoJSON i przed renderowaniem transponować wartości [lng, lat] na pary [lat, lng].

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

Dziury reprezentują obszary, na których nie ma dróg dostępnych w określonym czasie. Jest to powszechne w regionach z dużymi lasami, zbiornikami wodnymi, lotniskami lub nieruchomościami prywatnymi, po których nie mogą poruszać się pojazdy ani piesi.

Zewnętrzny interfejs API w wersji 1 nie udostępnia parametru umożliwiającego automatyczne usuwanie dziur. Jeśli aplikacja wymaga pełnej granicy, na przykład 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 (powłokę zewnętrzną), odrzucając wszystkie kolejne pierścienie wewnętrzne (dziury).

Czy w przypadku analizy przestrzennej po stronie serwera należy włączyć opcję enable_smoothing?

Nie. Parametr enable_smoothing jest przeznaczony wyłącznie do celów estetycznych. Zaokrągla ostre rogi siatki obliczeń, aby kształt wyglądał na mapie bardziej naturalnie.

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