แมปลิงก์และแนวคิดที่ตรงกันหรือไม่ [ปิด]

ฉันใช้ OpenStreetMap และเครือข่ายถนน vectorial และฉันต้องการใช้อัลกอริทึมตัวจับคู่แผนที่

ขณะนี้ฉันสามารถใช้ตำแหน่ง GPS แต่ละตำแหน่งเพื่อดึงส่วนถนนที่ใกล้ที่สุดและคำนวณการคาดการณ์ตำแหน่งนี้ไปยังส่วนนั้นได้เช่นเดียวกับในภาพนี้ (หมุดสีแดงคือตำแหน่ง GPS บริสุทธิ์ในสีน้ำเงินส่วนที่แมปและสีเขียว ตำแหน่งที่แมป):

อย่างไรก็ตามเนื่องจากการขาดความแม่นยำของ GPS บางครั้งตำแหน่งที่แมปจะกระโดดจากเซ็กเมนต์ไปยังอีกตำแหน่งหนึ่งและสามารถให้ตำแหน่งที่แมปไม่สอดคล้องกันเป็นบางครั้ง

อัลกอริทึมปัจจุบันของฉันเป็นพื้นฐานมาก: จากตำแหน่ง GPS ที่บริสุทธิ์ฉันได้ส่วนที่ใกล้ที่สุดและตัดสินใจว่าตำแหน่งที่แมปตรงกันอยู่ในตำแหน่งนี้ ฉันรู้ว่าสิ่งนี้สามารถปรับปรุงได้จริงๆ

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

ฉันต้องการลิงค์ใด ๆ และ / หรือซอฟต์แวร์โอเพนซอร์ซ

การฉายจุดบนบรรทัดขณะที่คุณกำลังทำอยู่นั้นเป็นไปได้ที่จะทำโดยตรงใน PostGIS เมื่อไม่นานมานี้ฉันเขียนเกี่ยวกับที่นี่

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

1. สร้างความหลากหลายของคะแนน
2. ลองวิธีแก้ปัญหาที่แนะนำในอัลกอริทึมสำหรับการจับคู่เซ็กเมนต์เพื่อจับคู่ทั้งบรรทัดแทนที่จะเป็นแบบจุดต่อจุด

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

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

สำหรับการอ่านเพิ่มเติมฉันขอแนะนำต่อไปนี้:

• การจับคู่แผนที่สำหรับวิถี GPS อัตราการสุ่มตัวอย่างต่ำ
• อัลกอริทึมการจับคู่แผนที่บางอย่างสำหรับผู้ช่วยนำทางส่วนบุคคล
• วิธีการจับคู่แผนที่ทั่วไปสามขั้นตอนในสภาพแวดล้อม GIS: มุมมองการศึกษาการเดินทาง / การขนส่ง

ตอบคำถามของฉันเอง!

1- . nice .pdf ฉันเพิ่งพบเกี่ยวกับเรื่องนี้:

http://safari.ce.sharif.edu/file/2011-06-06/259/2009_An%20off-line%20map-matching%20algorithm%20for%20incomplete%20map%20databases.pdf

ที่ยังเชื่อมโยงไปยังC ++ เปิดดำเนินงานแหล่งที่มาของแผนที่การจับคู่ที่อธิบายไว้ในเอกสาร: http://eden.dei.uc.pt/~camara/files/mgemma.zip
(อันนี้เป็นแผนที่แบบออฟไลน์จับคู่, ความเข้าใจของผมคือ มันคำนวณแผนที่จับคู่ตำแหน่งกับเส้นทาง WHOLE เป็นอินพุตและไม่สามารถทำได้ทันทีสำหรับแต่ละตำแหน่ง)

2- จากนั้นฉันเพิ่งอ่านอันนี้ในเชิงลึกและมันดีจริงๆในความคิดของฉัน: https://dspace.lboro.ac.uk/dspace-jspui/bitstream/2134/4860/1/velaga.pdf "การพัฒนา ขั้นสูงอัลกอริธึม MapMatching ทอพอโลยีที่อิงกับน้ำหนักสำหรับระบบขนส่งอัจฉริยะ "
อัลกอริธึมได้อธิบายไว้อย่างชัดเจนและมีการจัดทำค่าการปรับน้ำหนักไว้ในเอกสารด้วย

มีงานจำนวนมากในการจับคู่แผนที่ดูกระดาษนี้สำหรับการสำรวจสั้น ๆ ของงานล่าสุดค่อนข้างบาง (ก่อนปี 2007) เมื่อเร็ว ๆ นี้แนวทางที่ใช้โมเดลของมาร์คอฟที่ซ่อนอยู่ดูเหมือนจะทำงานได้ค่อนข้างดีภายใต้สถานการณ์ปกติ ตัวอย่างเช่นลองดูบทความนี้จากปี 2009 ความคิดและรูปแบบนั้นค่อนข้างง่ายและไม่ควรให้ปัญหามากเกินไปในการติดตั้งแม้ว่าคุณจะไม่คุ้นเคยกับ HMM (ในกรณีนี้อย่าตกใจมีมากมาย ของบทเรียนและการแนะนำออนไลน์)

วิธีการนี้เรียกว่า "การรวมเวกเตอร์" มีหน้า Wiki เฉพาะ ( http://wiki.openstreetmap.org/wiki/Conflation ) ซึ่งให้ภาพรวมทั่วไปและรายการซอฟต์แวร์ (Open Source) เพื่อแสดงภาพรวมของเวคเตอร์ถนนเช่น "JOSM conflation plugin", "การรวม Potlatch 2 เครื่องมือ "," RoadMatcher "(สำหรับ OpenJUMP) และอื่น ๆ

สำหรับอัลกอริทึมการจับคู่แผนที่มันขึ้นอยู่กับว่าคุณต้องการการประมวลผลแบบเรียลไทม์หรือออฟไลน์ ในกรณีต่อมา algos ที่ล้ำสมัยสามารถประมวลผลได้ ~ 1,000 คะแนนต่อวินาที ข้อกำหนดหน่วยความจำขึ้นอยู่กับการครอบคลุมของหลักสูตร เราพยายามบีบเครือข่ายถนน OSM ของโลกออกมาให้ได้ประมาณ 16 Gb เพื่อจุดประสงค์นั้น

นอกจากนี้คุณต้องแยกความแตกต่างของการจับคู่แผนที่จากการอนุมานเส้นทาง : กระบวนการเหล่านี้แยกกันสองกระบวนการขึ้นอยู่กับว่าคุณมีข้อมูลความถี่สูงหรือต่ำ เมื่อคุณมีคะแนนค่อนข้างน้อย (เช่น 1 ข้อมูลทุก ๆ กิโลเมตรในบริบทเมือง) มันเป็นการอนุมานเส้นทางเนื่องจากมักจะมีข้อสันนิษฐานบางอย่างที่ต้องคาดเดาว่าอุปกรณ์จะเดินทางไปที่ใด การอนุมานพา ธ มักจะยากกว่า แต่มีปัญหาน้อยลงกับอุปกรณ์ที่ทันสมัย ​​/ ราคาการเก็บข้อมูล

คุณสามารถตรวจสอบโปรไฟล์ของฉันสำหรับ API ที่ใช้การจับคู่แผนที่โดยตรงบน OSM: ใช้การจับคู่โทโพโลยีและทำงานได้ดีกับข้อมูลรถลอย

Strava Slideอธิบายว่าข้อมูลแทร็กสะสมบนเครือข่ายถนนสามารถทำตัวเหมือน "หุบเขา" ได้อย่างไรและเส้นทางที่นำเสนอจะ "ล้มเหลว" ได้อย่างไรเหมือนเป็นสายประคำ

หลังจากทดสอบกรอบการทำงานที่กล่าวถึงก่อนหน้านี้ฉันพบBarefootและสามารถแนะนำได้จริงๆ มันใช้โมเดลมาร์คอฟที่ซ่อนอยู่เป็นวิธีการจับคู่แผนที่น่าจะเป็น (รายละเอียดในกระดาษของพวกเขา"วางรถบนแผนที่" ) และดำเนินการใน Java มันเป็นโอเพนซอร์ซและพัฒนาโดยแผนก CarIT ของ BMW

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

โครงการโอเพ่นซอร์สของฉันที่เรียกว่า graphhopper ไม่ใช่สิ่งที่ใช้งานได้กับ iOS ( อัปเดต : ตอนนี้ใช้ได้กับ iOS ด้วย) และไม่มีแอพ Android ที่ใช้งานได้อย่างสมบูรณ์สำหรับสิ่งที่คุณต้องการ แต่คุณสามารถใช้เวอร์ชันเซิร์ฟเวอร์เพื่อสร้างแอป iOS หรือใช้การสาธิต Android ออฟไลน์เป็นการเริ่มต้น ฉันปล่อยอัลกอริธึมการจับคู่แผนที่ที่นี่เพียงแค่คร่าวๆ แต่ทำงานได้ดีอย่างน่าประหลาดใจ

ลองและรับข้อมูลการทดสอบที่ดี ใช้ GPS การติดตามความแม่นยำที่สูงกว่าเพิ่มเติมนอกเหนือจากจุดการบันทึกบนอุปกรณ์เป้าหมายของคุณ สิ่งนี้จะระบุข้อผิดพลาดใน GPS และในข้อมูล OSM พื้นฐาน การรู้เกณฑ์ที่สมเหตุสมผลจะทำให้การออกแบบอัลกอริทึมง่ายขึ้น

หากคุณสามารถรับข้อมูลถนนสำหรับภูมิภาคของคุณคุณอาจสนใจการสแนปแบบกลุ่มอัตโนมัติด้วย FOSS

ขึ้นอยู่กับว่าคุณต้องการพล็อตข้อมูลแบบเรียลไทม์หรือคุณวางแผนที่จะทำ postprocessing ที่พีซีของคุณหลังจากนั้น GRASS อาจช่วยได้

ฉันพบ APIที่อาจทำงานได้โดยไม่ต้องผ่านความพยายามในการพัฒนาโซลูชันของตัวเองในทันที

พวกเขาใช้ข้อมูล OSM เพื่อทำการจับคู่แผนที่ พวกเขายังมีหน้าตัวอย่างที่อนุญาตให้อัปโหลดไฟล์ GPX เพื่อดูว่ามันใช้งานได้ดีเพียงใดสำหรับคุณ

คุณไม่จำเป็นต้องปรับปรุงคุณภาพข้อมูลของคุณอย่างแน่นอน การใช้อัลกอริธึมทอพอโลยีกับเครือข่ายถนนในหน่วยความจำจะปรับปรุงการจับคู่ของคุณอย่างมาก ตรวจสอบการอ้างอิง: http://trb.metapress.com/content/p31485vw72645686