3 คะแนน โดย GN⁺ 2025-03-24 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Mozilla.ai เชื่อว่าปัญญาประดิษฐ์ (AI) มอบโอกาสมากมายในการเสริมความแข็งแกร่งให้ชุมชนผ่านการทำงานร่วมกันแบบเปิด
  • โอกาสเหล่านี้จำเป็นต้องได้รับการออกแบบอย่างรอบคอบ และความกังวลเกี่ยวกับการใช้ AI มากเกินไปก็กำลังเพิ่มขึ้น
  • ภายใต้บริบทนี้ จึงได้พัฒนาและเปิดตัว OpenStreetMap AI Helper Blueprint
  • ทำไมต้องเป็น OpenStreetMap?
    • ข้อมูลเป็นองค์ประกอบสำคัญของแอปพลิเคชัน AI และ OpenStreetMap มีชุมชนที่กระตือรือร้นซึ่งดูแลฐานข้อมูลแผนที่แบบเปิดที่สมบูรณ์ที่สุดแห่งหนึ่ง
    • OpenStreetMap ให้ข้อมูลหลากหลาย เช่น ถนน สถานีรถไฟ และอื่น ๆ และเมื่อผสานกับภาพถ่ายดาวเทียมก็เปิดโอกาสไม่สิ้นสุดในการฝึกโมเดล AI หลากหลายแบบ
    • เป้าหมายคือใช้ AI เพื่อเร่งขั้นตอนที่ทำได้ช้าในการทำแผนที่ ขณะเดียวกันก็ยังคงการตรวจสอบโดยมนุษย์ไว้ในส่วนสำคัญ
  • ทำไมต้องเป็นคอมพิวเตอร์วิทัศน์?
    • ฟีเจอร์บนแผนที่จำนวนมากแสดงในรูปแบบหลายเหลี่ยม และการค้นหาและวาดสิ่งเหล่านี้ใช้เวลามาก
    • โมเดลคอมพิวเตอร์วิทัศน์สามารถทำงานเหล่านี้ได้อย่างง่ายดายเมื่อมีข้อมูลเพียงพอ
    • ใช้โมเดล YOLOv11 และ SAM2 สำหรับงานตรวจจับวัตถุและการแบ่งส่วน โดยโมเดลเหล่านี้มีขนาดเบา รวดเร็ว และเหมาะกับการใช้งานบนเครื่อง
  • OpenStreetMap AI Helper Blueprint
    • ขั้นที่ 1: สร้างชุดข้อมูลสำหรับการตรวจจับวัตถุจาก OpenStreetMap
      • นำข้อมูล OpenStreetMap มารวมกับภาพถ่ายดาวเทียมและแปลงให้อยู่ในรูปแบบที่เหมาะสำหรับการฝึก
      • ใช้ Nominatim API และ Overpass API เพื่อดาวน์โหลดข้อมูลของพื้นที่ที่สนใจ และบันทึกในรูปแบบ Ultralytics YOLO
    • ขั้นที่ 2: ปรับจูนโมเดลตรวจจับวัตถุแบบละเอียด
      • ปรับจูนโมเดล YOLOv11 แบบละเอียด และอัปโหลดไปยัง Hugging Face Hub
    • ขั้นที่ 3: มีส่วนร่วมกับ OpenStreetMap
      • ใช้โมเดลที่ปรับจูนแล้วรันการอนุมานบนหลายไทล์ จากนั้นตรวจสอบวัตถุใหม่ด้วยตนเองก่อนอัปโหลดไปยัง OpenStreetMap
  • ข้อคิดส่งท้าย
    • OpenStreetMap เป็นตัวอย่างที่ทรงพลังของการทำงานร่วมกันแบบเปิดเพื่อสร้างแผนที่โลกที่ขับเคลื่อนโดยชุมชน
    • OpenStreetMap AI Helper Blueprint แสดงให้เห็นว่า AI สามารถยกระดับการมีส่วนร่วมของมนุษย์ได้ และตอกย้ำคุณค่าของข้อมูลคุณภาพสูง
    • เมื่อใช้ Blueprint นี้ สามารถทำแผนที่สระว่ายน้ำได้มากกว่างานแบบแมนนวลประมาณ 5 เท่าในเวลาเท่ากัน
    • ขอแนะนำให้ลองทดลองฝึกโมเดลสำหรับฟีเจอร์แผนที่ประเภทอื่น ๆ และสามารถมีส่วนร่วมกับโครงการหรือขยายต่อยอดได้

2 ความคิดเห็น

 
depth221 2025-03-24

ลองค้นดูแล้ว เห็นว่า Map Feature โดยทั่วไปมักแปลว่าองค์ประกอบแผนที่

 
GN⁺ 2025-03-24
ความคิดเห็นจาก Hacker News
  • ขอทักทายจาก OpenStreetMap Foundation ไม่ควรเพิ่มฟีเจอร์ที่ AI ตรวจจับได้เข้าไปในฐานข้อมูลโดยตรง

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

    • มีหลายความเห็นที่คัดค้านแนวคิดที่ว่า OSM จะเติบโตได้ด้วยงานทำมือ
    • ตลอด 10 ปีได้ทำการแก้ไขไป 60,000 ครั้ง แต่ด้วยแรงขับของอาสาสมัครมนุษย์เพียงอย่างเดียว ไม่สามารถแก้ปัญหาการทำแผนที่ในสเกลระดับโลกได้
    • จำเป็นต้องมีเฟรมเวิร์กที่ขยายได้สำหรับใส่หมายเหตุเรื่องคุณภาพของข้อมูล แหล่งที่มา วิธีรายงานบั๊ก และแนวทางสำหรับผู้ใช้ข้อมูล
    • ตัวอย่างเช่น เมื่ออยาก query ว่า "ธุรกิจประเภท X ที่มนุษย์ทำแผนที่ไว้ในช่วง 1 ปีที่ผ่านมา" ก็พอทำได้ในระดับหนึ่งด้วย "วันที่ตรวจสอบ"
    • แต่ก็ยังไม่รู้ได้ว่าคุณสมบัติต่าง ๆ ถูกต้องแค่ไหน หรือผู้ทำแผนที่ตรวจแค่ชื่อ/ตำแหน่งเท่านั้นหรือไม่
    • อาจจะดีกว่าหากเก็บเวลาทำการของทุกสถานที่เพื่อดูแลข้อมูลแบบอัตโนมัติทุกเดือน
    • ถ้าในฐานะผู้ใช้ข้อมูลสามารถกรองเฉพาะแหล่งข้อมูลบางแห่งที่เชื่อถือได้ ก็อาจจะดีกว่า
    • แม้จะมีข้อจำกัดอย่าง POI ที่อนุมานโดย AI ก็ยังสามารถใช้ข้อมูลได้
  • หลังจากได้เจอกับการทำแผนที่อัตโนมัติโดยตรง ก็กลายเป็นคนระแวดระวังมาก

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

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

    • ไม่ควรส่งข้อมูลที่ AI จินตนาการขึ้นมาเข้าไปเป็น contribution
  • Google ไม่อนุญาตเรื่องนี้ แต่ Mapbox อนุญาตหากใช้เพื่อวัตถุประสงค์ที่ไม่ใช่เชิงพาณิชย์ หรือใช้กับ OSM

    • สามารถใช้ภาพถ่ายดาวเทียมของ Mapbox เพื่อสร้างชุดข้อมูลเวกเตอร์แบบอนุพันธ์ได้
  • อยากให้ Mozilla โฟกัสกับการสร้างเบราว์เซอร์ที่ดี

  • เคยทำงานคล้ายกันเมื่อไม่กี่เดือนก่อน (ข้อมูลภูมิศาสตร์ขนาดเล็ก)

    • สามารถดูข้อมูลที่เกี่ยวข้องได้บน GitHub
  • อยากเห็นรายละเอียดเกี่ยวกับวิธี fine-tune SAM/2 เพื่อตรวจจับสระว่ายน้ำหรือแผงโซลาร์

    • มีประโยชน์ต่อโครงการด้านความยืดหยุ่นของชุมชน แต่ตามเรื่องการ fine-tune SAM2 ไม่ทัน
    • โมเดล Yolov8 หาและแบ่งส่วนแผงโซลาร์ได้ดี แต่ขอบแย่มากจนต้องทำงานเพิ่มอีกเยอะ
    • ผลลัพธ์ที่ฝึกด้วย SAM2 ดูดีกว่ามาก
    • จะไม่เพิ่มเข้า OSM เพราะปัญหาเรื่องความแม่นยำ แต่สามารถนำไปใช้ที่อื่นได้
  • แต่ก่อนเราเรียกสิ่งนี้ว่า 'head-up digitizing'