Dlaczego mogę poprosić o izochronę dla pieszych lub rowerzystów na maksymalnie 2 godziny, ale dla kierowców jest ona ograniczona do 1 godziny?
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óra musi zostać przeanalizowana, rozszerza się wykładniczo. Jazda jest ograniczona do maksymalnie 1 godziny (3600 sekund), aby interfejs API mógł zwrócić odpowiedź w szybkim, synchronicznym oknie czasu rzeczywistego, natomiast chodzenie i jazda na rowerze są obsługiwane przez maksymalnie 2 godziny (7200 sekund).
Jak obliczyć izochronę „dojazdu do pracy” (podróż do miejsca docelowego) w porównaniu z izochroną wychodzącą (podróż z miejsca początkowego)?
Obliczenia przychodzące i wychodzące są obsługiwane w interfejsie API w wersji 1 za pomocą parametru travel_direction:
FROM(wychodząca): oblicza obszar, do którego można dotrzećfrompunktu początkowego w określonym limicie czasu. Nadaje się do przypadków użycia, takich jak strefy dostawy lub zasięg usług.TO(do miasta): oblicza obszar, z którego można dotrzećtodo punktu początkowego w określonym limicie czasu. 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. 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: 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: przejdź na siatkę o niższej rozdzielczości, aby efektywnie pokryć rozległy obszar geograficzny bez powodowania poważnych 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 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, zanim rozpocznie obliczenia.
Każdy tryb podróży ma określony maksymalny próg przyciągania:
DRIVE: 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 się nie powiedzie, 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.
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 map, w tym
Google Maps JavaScript API i różne komponenty map mobilnych, oczekuje
współrzędnych lub obiektów LatLng w kolejności [latitude, longitude].
Jeśli renderowanie mapy jest nieprawidłowe, musisz przejść przez współrzędne w ładunku GeoJSON i transponować wartości, zanim przekażesz je do pakietu SDK mapy.
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 limicie czasu. 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_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 (dziury).
Czy w przypadku analizy przestrzennej po stronie serwera warto 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 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.