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