คำถามที่พบบ่อยเกี่ยวกับ Isochrones API

ฉันจะคำนวณ Isochrone ขาเข้าแบบ "เดินทางไปทำงาน" (เดินทางไปยังจุดหมาย) เทียบกับ Isochrone ขาออก (เดินทางจากต้นทาง) ได้อย่างไร

API เวอร์ชัน 1 รองรับการคำนวณทั้งขาเข้าและขาออกโดยใช้พารามิเตอร์ travelDirection (travel_direction) ดังนี้

• FROM (ขาออก): คำนวณพื้นที่ที่เข้าถึงได้fromจุดต้นทางภายในขีดจำกัดเวลาที่ระบุ ซึ่งเหมาะสำหรับกรณีการใช้งาน เช่น พื้นที่นำส่งหรือความครอบคลุมของบริการ

• TO (ขาเข้า): คำนวณพื้นที่ที่คุณสามารถเดินทางtoจุดต้นทางภายในขีดจำกัดเวลาที่ระบุ ซึ่งเหมาะสําหรับแอปพลิเคชันต่างๆ เช่น ฟีเจอร์การเดินทางไปทํางาน หรือการกําหนดเขตพื้นที่ให้บริการรอบสํานักงานกลางหรือศูนย์กลางการขนส่ง

หมายเหตุ: รูปหลายเหลี่ยม FROM และ TO สำหรับจุดเริ่มต้นและระยะเวลาเดียวกันอาจไม่สมมาตรกันในทุกโหมด สำหรับ DRIVE, TWO_WHEELER และ BICYCLE สาเหตุอาจรวมถึงถนนเดินรถทางเดียวและข้อจำกัดในการเลี้ยว สำหรับ DRIVE และ TWO_WHEELER ทางขึ้นทางด่วน ทางลงทางด่วน และการจราจรติดขัดตามทิศทางก็มีส่วนด้วยเช่นกัน สำหรับWALKและBICYCLE ความชันก็มีความสำคัญเช่นกัน เพราะการเดินทางขึ้นเนินจะช้ากว่าการลงเนิน

โหมดการเดินทางทั้ง 4 โหมด (DRIVE, TWO_WHEELER, BICYCLE และ WALK) แตกต่างกันอย่างไร

แต่ละโหมดจะใช้กฎการเข้าถึงเครือข่ายถนน ต้นทุนการเลี้ยว และโมเดลความเร็วของตัวเอง ดังนี้

• DRIVE: เดินทางผ่านถนนที่ขับรถได้โดยใช้ความเร็วที่กำหนดหรือความเร็วที่รถวิ่งได้ตามปกติ หรือความเร็วตามสภาพการจราจรแบบเรียลไทม์ (TRAFFIC_AWARE) สูงสุด 3,600 วินาที (60 นาที)
• TWO_WHEELER: เดินทางบนถนนที่รถจักรยานยนต์เข้าถึงได้โดยมีความเร็วที่จำลองต่ำกว่า DRIVE บนถนนความเร็วสูงและเส้นทาง TRAFFIC_AWARE ที่ไม่บังคับ สูงสุด 3,600 วินาที (60 นาที) ด้วยเหตุนี้ Isochrone TWO_WHEELER จึงมีขนาดใหญ่กว่า BICYCLE แต่เล็กกว่า DRIVE ตามทางหลวงความเร็วสูง
• BICYCLE: เดินทางผ่านถนนที่จักรยานเข้าถึงได้ เลนจักรยาน และเส้นทางที่มีความเร็วที่ปรับตามประเภทถนนและความลาดชัน (ไม่รวมมอเตอร์เวย์และทางด่วน) สูงสุด 7,200 วินาที (120 นาที)
• WALK: เดินผ่านทางเท้า ทางเดิน และถนนด้วยความเร็วในการเดินที่ปรับตามความลาดชัน (ไม่สนใจข้อจำกัดการเดินรถทางเดียว) สูงสุด 7,200 วินาที (120 นาที)

Isochrones API มีเรือข้ามฟากหรือการข้ามน้ำไหม

ไม่ Isochrones API จะข้ามการเชื่อมต่อถนน สะพาน อุโมงค์ และทางเดินเท่านั้น ระบบจะยกเว้นเส้นทางเรือข้ามฟากและการข้ามน้ำในทุกโหมดการเดินทาง เกาะหรือคาบสมุทรที่เชื่อมต่อด้วยเรือข้ามฟากเท่านั้นจะไม่รวมอยู่ใน Isochrone ที่สร้างจากแผ่นดินใหญ่

บางครั้งรูปหลายเหลี่ยมที่แสดงผลอาจดูเป็นบล็อกหรือมีขอบหยักเป็นขั้นบันได โดยเฉพาะอย่างยิ่งเมื่อใช้ระยะเวลานานขึ้น เหตุใดระดับรายละเอียดจึงเปลี่ยนแปลง

Isochrones API จะปรับความละเอียดของตารางกริดการคำนวณเชิงพื้นที่แบบไดนามิกตาม travel_duration และ travel_mode ที่ขอ

• ระยะเวลาสั้น: ใช้ตารางกริดที่มีความละเอียดสูงและได้รับการปรับแต่งอย่างละเอียดเนื่องจากพื้นที่ทั้งหมดมีขนาดเล็ก ส่งผลให้ได้ขอบเขตที่ละเอียด
• ระยะเวลานานขึ้น: เปลี่ยนไปใช้ตารางกริดที่มีความละเอียดต่ำและหยาบขึ้นเพื่อให้ครอบคลุมพื้นที่ทางภูมิศาสตร์ที่กว้างใหญ่ได้อย่างมีประสิทธิภาพโดยไม่ทำให้เกิดเวลาในการตอบสนองที่รุนแรง

คุณสามารถตั้งค่า polygon_fidelity ที่ไม่บังคับเป็น HIGH, MEDIUM หรือ LOW ได้หากต้องการรายละเอียดที่เฉพาะเจาะจงและสอดคล้องกันไม่ว่าจะใช้ระยะเวลาเท่าใดก็ตาม

เหตุใดการขอ Isochrone สำหรับพิกัดภายในสวนสาธารณะ ทะเลสาบ หรือนิคมอุตสาหกรรมขนาดใหญ่จึงแสดงข้อผิดพลาด "ไม่พบ" ในบางครั้ง

Isochrones API จะคำนวณระยะเวลาเดินทางโดยใช้ถนนและเส้นทางเดินเท้า API ต้อง "สแนป" จุดไปยังส่วนที่เข้ากันได้ที่ใกล้ที่สุดก่อนเริ่มการคำนวณ หากพิกัดต้นทางที่ขอไม่ได้อยู่บนถนนที่ระบบรู้จัก

โหมดการเดินทางแต่ละโหมดมีระยะทางสูงสุดในการสแนปประมาณ 200 เมตรหรือน้อยกว่า WALK และ BICYCLE ใช้ระยะทางสั้นกว่า DRIVE และ TWO_WHEELER ส่วน DRIVE และ TWO_WHEELER จะไม่สนใจเส้นทางสำหรับคนเดินเท้าเท่านั้น

หากพิกัดต้นทางอยู่ห่างจากส่วนถนนที่ถูกต้องและเข้ากันได้กับโหมดมากกว่าระยะทางนี้ การสแนปจะล้มเหลว และ API จะแสดงข้อผิดพลาด NOT_FOUND หากต้องการแก้ไขปัญหานี้ โปรดตรวจสอบว่าพิกัดของคุณอยู่ใกล้กับถนนหรือทางเดินสาธารณะ

ทำไมฉันจึงได้รับข้อผิดพลาดเมื่อขอการกำหนดเส้นทางที่อิงตามสภาพการจราจรสำหรับการเดินหรือปั่นจักรยาน

ระบบรองรับสภาพการจราจรแบบเรียลไทม์ (TRAFFIC_AWARE) สำหรับโหมดการเดินทางDRIVEและTWO_WHEELER หากคุณพยายามขอ Isochrone สำหรับ WALK หรือ BICYCLE โดยตั้งค่า routingPreference เป็น TRAFFIC_AWARE API จะแสดงข้อผิดพลาด 400 INVALID_ARGUMENT

เมื่อฉันแสดงผลการตอบกลับ GeoJSON บนแผนที่ รูปร่างจะแสดงในตำแหน่งที่ไม่ถูกต้อง บิดเบี้ยว หรือแสดงผลไม่สำเร็จ สาเหตุของปัญหานี้คืออะไร

ซึ่งแทบทั้งหมดเกิดจากลำดับพิกัดที่ไม่ตรงกัน

Isochrones API จะแสดงผลพิกัดตามลำดับ [longitude, latitude] ตามมาตรฐาน GeoJSON (RFC 7946) อย่างไรก็ตาม SDK การทำแผนที่และออบเจ็กต์เรขาคณิตที่กำหนดเองจำนวนมากคาดหวังพิกัดตามลำดับ [latitude, longitude]

หากการแสดงผลแผนที่ไม่ถูกต้อง ให้ตรวจสอบวิธีที่ SDK ของแผนที่จัดการ GeoJSON ดังนี้

• Google Maps JavaScript API: หากคุณใช้ชั้นข้อมูล (map.data.addGeoJson()) ระบบจะจัดการลำดับนี้โดยอัตโนมัติและคุณไม่ต้องดำเนินการใดๆ
• ออบเจ็กต์ที่กำหนดเองหรือ SDK อื่นๆ: หากคุณแยกวิเคราะห์การตอบกลับเป็นออบเจ็กต์ LatLng ด้วยตนเอง คุณต้องวนซ้ำพิกัดในเพย์โหลด GeoJSON และเปลี่ยนค่า [lng, lat] เป็นคู่ [lat, lng] ก่อนแสดงผล

เหตุใดจึงมี "รู" กลวงอยู่ภายในรูปหลายเหลี่ยม Isochrone และฉันจะขอรูปทรงทึบแทนได้ไหม

หลุมแสดงถึงพื้นที่ที่ไม่มีถนนที่เข้าถึงได้ภายในเวลาที่กำหนด ซึ่งมักเกิดขึ้นในภูมิภาคที่มีป่าขนาดใหญ่ แหล่งน้ำ สนามบิน หรือสถานที่ส่วนบุคคลที่ยานพาหนะหรือคนเดินเท้าสัญจรไม่ได้

API เวอร์ชัน 1 ภายนอกไม่แสดงพารามิเตอร์เพื่อนำช่องว่างออกโดยอัตโนมัติ หากแอปพลิเคชันของคุณต้องใช้ขอบเขตที่แน่นอน เช่น เพื่อทำการตรวจสอบการรวมจุดในรูปหลายเหลี่ยม คุณสามารถทำดังนี้

• ตั้งค่าพารามิเตอร์ polygon_fidelity เป็น MEDIUM หรือ LOW เพื่อกระตุ้นให้อัลกอริทึมสรุปและผสานช่องว่างภายในเหล่านี้
• ใช้ไลบรารี GIS ฝั่งไคลเอ็นต์ (เช่น Turf.js) เพื่อแยกวิเคราะห์ GeoJSON และดึงเฉพาะวงแหวนพิกัดแรก (เปลือกนอก) โดยทิ้งวงแหวนภายในที่ตามมา (รู)

ฉันควรเปิดใช้ตัวเลือก enable_smoothing สำหรับการวิเคราะห์เชิงพื้นที่แบ็กเอนด์ไหม

ไม่ พารามิเตอร์ enable_smoothing ออกแบบมาเพื่อความสวยงามเท่านั้น โดยจะปัดเศษมุมแหลมของตารางกริดการคำนวณที่อยู่ด้านล่างเพื่อให้รูปร่างดูเป็นธรรมชาติบนแผนที่

เราไม่แนะนำให้ใช้การปรับให้เรียบสำหรับการวิเคราะห์เชิงพื้นที่ที่แม่นยำ เนื่องจากจะเปลี่ยนจุดยอดและเลื่อนขอบเขตเล็กน้อย สำหรับการคำนวณแบ็กเอนด์ การค้นหาฐานข้อมูล หรือการทดสอบจุดในรูปหลายเหลี่ยม ให้ตั้งค่า enable_smoothing เป็น false เพื่อให้แน่ใจว่าคุณใช้ขอบเขตที่คำนวณได้อย่างแม่นยำทางคณิตศาสตร์