เหตุใดฉันจึงขอไอโซโครนสำหรับการเดินหรือการปั่นจักรยานได้นานสูงสุด 2 ชั่วโมง แต่การขับรถจำกัดไว้ที่ 1 ชั่วโมง
ข้อจำกัดนี้อิงตามความซับซ้อนในการคำนวณ ยานพาหนะ เดินทางได้ไกลกว่าคนเดินเท้าหรือนักปั่นจักรยานอย่างมากในช่วงเวลาเดียวกัน ซึ่งหมายความว่าเครือข่ายถนนพื้นฐานที่ต้องวิเคราะห์จะขยายตัว แบบทวีคูณ การขับรถจำกัดเวลาสูงสุด 1 ชั่วโมง (3,600 วินาที) เพื่อให้แน่ใจว่า API สามารถส่งคืนการตอบกลับภายในหน้าต่างแบบเรียลไทม์ที่รวดเร็วและซิงโครนัส ขณะที่การเดินและการปั่นจักรยานรองรับได้นานสูงสุด 2 ชั่วโมง (7,200 วินาที)
ฉันจะคำนวณไอโซโครน "การเดินทางไปทำงาน" ขาเข้า (เดินทางไปยังจุดหมาย) เทียบกับไอโซโครนขาออก (เดินทางจากต้นทาง) ได้อย่างไร
API v1 รองรับการคำนวณทั้งขาเข้าและขาออกโดยใช้พารามิเตอร์
travel_direction ดังนี้
FROM(ขาออก): คำนวณพื้นที่ที่เข้าถึงได้fromจากจุดต้นทาง ภายในเวลาที่กำหนด ซึ่งเหมาะสำหรับกรณีการใช้งาน เช่น เขตนำส่งหรือพื้นที่ให้บริการTO(ขาเข้า): คำนวณพื้นที่ที่คุณเดินทางจากtoจุดเริ่มต้นได้ภายในเวลาที่กำหนด เหมาะสำหรับแอปพลิเคชัน อย่างฟีเจอร์การเดินทางไปทำงานหรือการกำหนดเขตพื้นที่บริการรอบๆ สำนักงานกลางหรือศูนย์กลางการขนส่ง
บางครั้งรูปหลายเหลี่ยมที่แสดงผลอาจดูเป็นบล็อกหรือมีขอบเป็นขั้นบันได โดยเฉพาะอย่างยิ่งในระยะเวลาที่นานขึ้น เหตุใดระดับรายละเอียดจึงเปลี่ยนแปลง
Isochrones API จะปรับความละเอียดของ
ตารางการคำนวณเชิงพื้นที่แบบไดนามิกตาม travel_duration และ
travel_mode ที่ขอ
- ระยะเวลาที่สั้นลง: ใช้กริดที่มีความละเอียดสูงและปรับแต่งมาอย่างดี เนื่องจาก พื้นที่ทั้งหมดมีขนาดเล็ก จึงทำให้ขอบเขตมีความละเอียด
- ระยะเวลานานขึ้น: เปลี่ยนไปใช้ตารางกริดที่มีความละเอียดต่ำกว่าเพื่อครอบคลุม พื้นที่ทางภูมิศาสตร์ที่กว้างใหญ่ได้อย่างมีประสิทธิภาพโดยไม่ทำให้เกิดเวลาในการตอบสนองที่รุนแรง
คุณตั้งค่า polygon_fidelity ที่ไม่บังคับเป็น HIGH, MEDIUM หรือ LOW ได้หากต้องการ
รายละเอียดระดับหนึ่งที่เฉพาะเจาะจงและสอดคล้องกันโดยไม่คำนึงถึงระยะเวลา
เหตุใดการขอไอโซครอนสำหรับพิกัดภายในสวนสาธารณะ ทะเลสาบ หรือนิคมอุตสาหกรรมขนาดใหญ่อาจแสดงข้อผิดพลาด "ไม่พบ" ในบางครั้ง
Isochrones API จะคำนวณเวลาในการเดินทางโดยใช้ถนนและทางเดิน API ต้อง "สแนป" จุดไปยังส่วนที่เข้ากันได้ที่ใกล้ที่สุดก่อนเริ่ม การคำนวณ หากพิกัดต้นทางที่คุณขอไม่ได้อยู่บนถนนที่รู้จัก
โหมดการเดินทางแต่ละโหมดมีเกณฑ์ระยะการสแนปสูงสุดที่เฉพาะเจาะจง ดังนี้
DRIVE: 200 เมตร (ไม่รวมเส้นทางสำหรับคนเดินเท้าเท่านั้น)BICYCLE: 180 เมตรWALK: 150 เมตร
หากพิกัดต้นทางอยู่ไกลจากส่วนของถนนที่ใช้ได้และเข้ากันได้กับโหมดมากกว่าเกณฑ์เหล่านี้ การปักหมุดจะล้มเหลว และ API จะแสดงNOT_FOUND
ข้อผิดพลาด ในการแก้ไขปัญหานี้ ให้ตรวจสอบว่าพิกัดอยู่ใกล้กับถนนหรือทางเท้าสาธารณะ
เมื่อแสดงผลการตอบกลับ GeoJSON บนแผนที่ รูปร่างจะแสดงในตำแหน่งที่ไม่ถูกต้อง บิดเบี้ยว หรือแสดงผลไม่สำเร็จ สาเหตุของปัญหานี้คืออะไร
ซึ่งมักเกิดจากการที่ลำดับพิกัดไม่ตรงกัน
ตามมาตรฐาน GeoJSON (RFC 7946) Isochrone API จะแสดงพิกัด
ตามลำดับ [longitude, latitude] อย่างไรก็ตาม SDK การแมปจำนวนมาก รวมถึง
Google Maps JavaScript API และคอมโพเนนต์แผนที่บนอุปกรณ์เคลื่อนที่ต่างๆ คาดหวัง
พิกัดหรือออบเจ็กต์ LatLng ตามลำดับ [latitude, longitude]
หากการแสดงผลแผนที่ไม่ถูกต้อง คุณต้องวนซ้ำพิกัดในเพย์โหลด GeoJSON และสลับค่าก่อนส่งไปยัง SDK แผนที่
เหตุใดจึงมี "รู" กลวงอยู่ภายในรูปหลายเหลี่ยมไอโซโครน และฉันจะรับรูปทรงทึบแทนได้ไหม
รูหมายถึงพื้นที่ที่ไม่มีถนนที่เข้าถึงได้ภายในเวลาที่กำหนด ซึ่งมักพบในภูมิภาคที่มีป่าไม้ขนาดใหญ่ แหล่งน้ำ สนามบิน หรือพื้นที่ส่วนบุคคล ที่ยานพาหนะหรือคนเดินเท้าไม่สามารถสัญจรได้
API ภายนอกเวอร์ชัน 1 ไม่ได้แสดงพารามิเตอร์เพื่อนำช่องว่างออกโดยอัตโนมัติ หากแอปพลิเคชันของคุณต้องการขอบเขตที่แน่นอน เช่น เพื่อทำการตรวจสอบการบรรจุจุดในรูปหลายเหลี่ยม คุณสามารถทำสิ่งต่อไปนี้ได้
- ตั้งค่าพารามิเตอร์
polygon_fidelityเป็นMEDIUMหรือLOWเพื่อกระตุ้นให้อัลกอริทึม สรุปและรวมช่องว่างภายในเหล่านี้ - ใช้ไลบรารี GIS ฝั่งไคลเอ็นต์ (เช่น Turf.js) เพื่อแยกวิเคราะห์ GeoJSON และ ดึงเฉพาะวงแหวนพิกัดแรก (เปลือกภายนอก) โดยทิ้งวงแหวนภายใน ที่ตามมา (รู)
ฉันควรเปิดใช้ตัวเลือก enable_smoothing สำหรับการวิเคราะห์เชิงพื้นที่แบ็กเอนด์ไหม
ไม่ได้ พารามิเตอร์ enable_smoothing ออกแบบมาเพื่อความสวยงามเท่านั้น
โดยจะปัดมุมแหลมของตารางการคำนวณพื้นฐานเพื่อให้
รูปร่างดูเป็นธรรมชาติบนแผนที่
ไม่แนะนําให้ใช้การปรับให้เรียบสําหรับการวิเคราะห์เชิงพื้นที่ที่แม่นยําเนื่องจากจะเปลี่ยน
จุดยอดและเลื่อนขอบเขตเล็กน้อย สำหรับการคำนวณแบ็กเอนด์ ฐานข้อมูล
การค้นหา หรือการทดสอบจุดในรูปหลายเหลี่ยม ให้ตั้งค่า enable_smoothing เป็น false เพื่อ
ให้แน่ใจว่าคุณใช้ขอบเขตที่คำนวณแล้วซึ่งแม่นยำทางคณิตศาสตร์