Dlaczego mogę poprosić o izochronę dla pieszych lub rowerzystów na maksymalnie 2 godziny, a dla kierowców – tylko na 1 godzinę?
To ograniczenie wynika ze złożoności obliczeń. Pojazd pokonuje znacznie większą odległość niż pieszy lub rowerzysta w tym samym czasie, co oznacza, że podstawowa sieć dróg, którą należy przeanalizować, rozszerza się wykładniczo. Czas jazdy jest ograniczony do maksymalnie 1 godziny (3600 sekund), aby zapewnić, że interfejs API może zwrócić odpowiedź w szybkim, synchronicznym oknie czasu rzeczywistego. W przypadku chodzenia i jazdy na rowerze czas jest ograniczony do 2 godzin (7200 sekund).
Jak obliczyć izochronę „dojazdu do pracy” (podróż do miejsca docelowego) w porównaniu z izochroną „wyjazdu” (podróż z miejsca wyjazdu)?
Interfejs API w wersji 1 obsługuje obliczenia przychodzące i wychodzące za pomocą parametru travel_direction:
FROM(Wychodzące): oblicza obszar osiągalnyfrompunktu początkowego w określonym czasie. Jest to odpowiednie w przypadku takich zastosowań jak strefy dostaw lub zasięg usług.TO(Wewnętrzne): oblicza obszar, z którego można dotrzeć dotopunktu początkowego w określonym czasie. Jest to przydatne w przypadku aplikacji takich jak funkcje dojazdu do pracy czy określanie stref dojazdu wokół centralnego biura lub węzła transportu publicznego.
Czasami zwrócony wielokąt wygląda na blokowy lub ma poszarpane, 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żywaj bardzo precyzyjnej siatki o wysokiej rozdzielczości, ponieważ całkowity obszar jest mały, co daje szczegółową granicę.
- Dłuższe okresy: przejście na siatkę o większych komórkach i niższej rozdzielczości, aby efektywnie pokryć rozległy obszar geograficzny bez powodowania dużych opóźnień.
Jeśli potrzebujesz określonego, stałego poziomu szczegółowości niezależnie od czasu trwania, możesz ustawić opcjonalny parametr polygon_fidelity na HIGH, MEDIUM lub LOW.
Dlaczego w przypadku żądania izochrony dla współrzędnych w parku, jeziorze lub dużym kompleksie przemysłowym czasami zwracany jest 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 pochodzenia 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 m (ignoruje ścieżki przeznaczone tylko dla pieszych).BICYCLE: 180 metrów.WALK: 150 metrów.
Jeśli współrzędne punktu początkowego znajdują się dalej od prawidłowego segmentu drogi zgodnego z danym rodzajem transportu niż te progi, przyciąganie się nie powiedzie, a interfejs API zwróci NOT_FOUNDbłąd. Aby rozwiązać ten problem, upewnij się, że współrzędne są umieszczone w pobliżu publicznej ulicy lub ścieżki.
Dlaczego podczas proszenia o wyznaczanie tras z uwzględnieniem natężenia ruchu w przypadku marszu lub jazdy na rowerze pojawia się błąd?
Aktualne warunki drogowe (TRAFFIC_AWARE) są obsługiwane wyłącznie w przypadku trybu podróży DRIVE. Jeśli spróbujesz wysłać żądanie izochrony 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 jest wyświetlany w nieprawidłowym miejscu, jest zniekształcony lub nie renderuje się. Co jest tego przyczyną?
Jest to niemal zawsze 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]. Wiele pakietów SDK do mapowania i niestandardowych obiektów geometrycznych oczekuje jednak współrzędnych w kolejności [latitude, longitude].
Jeśli renderowanie mapy jest nieprawidłowe, sprawdź, jak pakiet SDK Mapy obsługuje GeoJSON:
- Interfejs 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ź i przekształcasz ją w obiekty
LatLng, musisz przejść w pętli przez współrzędne w ładunku GeoJSON i przekształcić wartości[lng, lat]w pary[lat, lng]przed renderowaniem.
Dlaczego w moim wielokącie izochronicznym są puste „dziury” i czy mogę zamiast tego uzyskać pełny kształt?
Otwory oznaczają obszary, do których nie można dotrzeć drogami w określonym czasie. Jest to powszechne w regionach z dużymi lasami, zbiornikami wodnymi, lotniskami lub prywatnymi nieruchomościami, 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 Twoja aplikacja wymaga solidnej granicy, np. do przeprowadzania sprawdzania, czy punkt znajduje się w wielokącie, możesz:
- Ustaw parametr
polygon_fidelitynaMEDIUMlubLOW, 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 w przypadku analizy przestrzennej na backendzie należy włączyć opcję enable_smoothing?
Nie. Parametr enable_smoothing służy wyłącznie do celów estetycznych.
Zaokrągla ostre rogi siatki obliczeniowej, aby kształt wyglądał naturalnie na mapie.
Wygładzanie nie jest zalecane w przypadku precyzyjnej analizy przestrzennej, ponieważ zmienia wierzchołki i nieznacznie przesuwa granice. W przypadku obliczeń na serwerze backendu, zapytań do bazy danych lub testów punktu w wielokącie ustaw wartość enable_smoothing na false, aby mieć pewność, że używasz obliczonej granicy o precyzji matematycznej.