인바운드 '출근' 등시선 (목적지로 이동)과 아웃바운드 등시선 (출발지에서 이동)을 계산하려면 어떻게 해야 하나요?
v1 API에서는 travelDirection (travel_direction) 매개변수를 사용하여 인바운드 및 아웃바운드 계산을 모두 지원합니다.
FROM(출발): 지정된 시간 제한 내에 출발지에서from도달할 수 있는 영역을 계산합니다. 이는 배송 구역 또는 서비스 범위와 같은 사용 사례에 적합합니다.TO(인바운드): 지정된 시간 제한 내에 출발지to로 이동할 수 있는 영역을 계산합니다. 이는 출퇴근 기능이나 중앙 사무실 또는 대중교통 허브 주변의 집수 구역을 결정하는 것과 같은 애플리케이션에 적합합니다.
네 가지 이동 수단 (DRIVE, TWO_WHEELER, BICYCLE, WALK)은 어떻게 다른가요?
각 모드는 자체 도로망 액세스 규칙, 회전 비용, 속도 모델을 사용합니다.
DRIVE: 게시된 속도, 자유 흐름 속도 또는 실시간 교통정보 속도 (TRAFFIC_AWARE)를 사용하여 주행 가능한 도로를 최대 3,600초 (60분) 동안 이동합니다.TWO_WHEELER: 고속도로에서DRIVE보다 모델링된 속도가 느리고 선택적TRAFFIC_AWARE라우팅을 사용하여 이륜차로 접근할 수 있는 도로를 최대 3,600초 (60분) 동안 이동합니다. 따라서 고속도로를 따라TWO_WHEELER등시선은BICYCLE보다 크지만DRIVE보다 작습니다.BICYCLE: 자전거로 접근 가능한 도로, 자전거 전용도로, 도로 유형 및 경사에 맞게 속도가 조정된 경로 (고속도로 제외)를 최대 7,200초 (120분) 동안 이동합니다.WALK: 경사에 맞게 조정된 보행 속도로 보행자 인도, 산책로, 거리를 이동합니다 (일방통행 차량 제한 무시). 최대 7,200초 (120분)입니다.
Isochrones API에 페리 또는 수상 횡단이 포함되나요?
아니요. Isochrones API는 도로, 다리, 터널, 경로 연결만 순회합니다. 페리 경로 및 수상 대중교통 교차로는 모든 이동 수단에서 제외됩니다. 페리로만 연결된 섬이나 반도는 본토에서 생성된 등시선에 포함되지 않습니다.
반환된 다각형이 블록 모양이거나 가장자리가 들쭉날쭉하고 계단식으로 표시되는 경우가 있습니다. 특히 시간이 길어질수록 이러한 현상이 두드러집니다. 세부정보 수준이 변경되는 이유는 무엇인가요?
Isochrones API는 요청된 travel_duration 및 travel_mode에 따라 공간 계산 그리드의 해상도를 동적으로 조정합니다.
- 짧은 기간: 총 영역이 작기 때문에 고도로 정제된 고해상도 그리드를 사용하여 경계가 세부적으로 표시됩니다.
- 더 긴 기간: 심각한 지연 시간을 유발하지 않고 광대한 지리적 영역을 효율적으로 처리하기 위해 더 거칠고 해상도가 낮은 그리드로 전환합니다.
기간에 관계없이 일관된 특정 수준의 세부정보가 필요한 경우 선택사항인 polygon_fidelity를 HIGH, MEDIUM 또는 LOW로 설정할 수 있습니다.
공원, 호수 또는 대규모 산업 단지 내부의 좌표에 대해 등시선을 요청하면 '찾을 수 없음' 오류가 반환되는 경우가 있는 이유는 무엇인가요?
Isochrones API는 도로와 경로를 사용하여 이동 시간을 계산합니다. 요청된 출발지 좌표가 인식된 도로에 있지 않은 경우 API는 계산을 시작하기 전에 가장 가까운 호환 세그먼트에 지점을 '스냅'해야 합니다.
각 이동 수단의 최대 스냅 거리는 약 200미터 이하입니다.
WALK 및 BICYCLE는 DRIVE 및 TWO_WHEELER보다 짧은 거리를 사용하며 DRIVE 및 TWO_WHEELER는 보행자 전용 경로를 무시합니다.
출발지 좌표가 모드와 호환되는 유효한 도로 세그먼트에서 이 거리보다 멀리 떨어져 있으면 스냅이 실패하고 API에서 NOT_FOUND 오류를 반환합니다. 이 문제를 해결하려면 좌표가 공공 도로나 경로에 가깝게 배치되어 있는지 확인하세요.
도보 또는 자전거의 교통정보를 반영한 경로를 요청할 때 오류가 발생하는 이유는 무엇인가요?
실시간 교통 상황 (TRAFFIC_AWARE)은 DRIVE 및 TWO_WHEELER 이동 수단에 지원됩니다. routingPreference가 TRAFFIC_AWARE로 설정된 WALK 또는 BICYCLE의 등시선을 요청하려고 하면 API에서 400 INVALID_ARGUMENT 오류를 반환합니다.
내 지도에서 GeoJSON 응답을 렌더링할 때 도형이 잘못된 위치에 표시되거나 왜곡되거나 렌더링되지 않습니다. 원인은 무엇인가요?
이는 거의 항상 좌표 순서 불일치로 인해 발생합니다.
GeoJSON 표준 (RFC 7946)에 따라 Isochrones API는 [longitude, latitude] 순서로 좌표를 반환합니다. 그러나 많은 매핑 SDK와 맞춤 도형 객체는 [latitude, longitude] 순서의 좌표를 예상합니다.
지도 렌더링이 잘못된 경우 지도 SDK가 GeoJSON을 처리하는 방식을 확인하세요.
- Google Maps JavaScript API: 데이터 영역(
map.data.addGeoJson())을 사용하는 경우 이 순서는 기본적으로 처리되므로 별도의 조치가 필요하지 않습니다. - 커스텀 객체 또는 기타 SDK: 응답을
LatLng객체로 수동 파싱하는 경우 렌더링하기 전에 GeoJSON 페이로드의 좌표를 반복하고[lng, lat]값을[lat, lng]쌍으로 변환해야 합니다.
등시선 다각형 내부에 빈 '구멍'이 있는 이유는 무엇이며, 대신 채워진 도형을 사용할 수 있나요?
구멍은 시간 제한 내에 도달할 수 있는 도로가 없는 영역을 나타냅니다. 이는 차량이나 보행자가 이동할 수 없는 대규모 숲, 수역, 공항 또는 사유지가 있는 지역에서 흔히 발생합니다.
외부 v1 API는 구멍을 자동으로 삭제하는 매개변수를 노출하지 않습니다. 애플리케이션에 실선 경계가 필요한 경우(예: 다각형 내 점 포함 여부 확인) 다음을 수행할 수 있습니다.
polygon_fidelity매개변수를MEDIUM또는LOW로 설정하여 알고리즘이 이러한 내부 격차를 일반화하고 병합하도록 합니다.- 클라이언트 측 GIS 라이브러리 (예: Turf.js)를 사용하여 GeoJSON을 파싱하고 첫 번째 좌표 링 (외부 셸)만 추출하고 후속 내부 링 (구멍)은 삭제합니다.
백엔드 공간 분석에 enable_smoothing 옵션을 사용 설정해야 하나요?
아니요. enable_smoothing 매개변수는 순전히 시각적 미학을 위해 설계되었습니다.
기본 계산 그리드의 날카로운 모서리를 둥글게 처리하여 지도에서 도형이 자연스럽게 보이도록 합니다.
꼭짓점을 변경하고 경계를 약간 이동하므로 정확한 공간 분석에는 평활화를 사용하지 않는 것이 좋습니다. 백엔드 계산, 데이터베이스 쿼리 또는 다각형 내 점 테스트의 경우 enable_smoothing을 false로 설정하여 수학적으로 정확하게 계산된 경계를 사용하도록 합니다.