ฟีเจอร์แผนที่ของ OpenStreetMap ที่สร้างด้วยคอมพิวเตอร์วิทัศน์

• Mozilla.ai เปิดตัว OpenStreetMap AI Helper Blueprint ที่เชื่อมโยงข้อมูล OpenStreetMap กับภาพถ่ายดาวเทียม เพื่อค้นหาอ็อบเจกต์บนแผนที่ ให้มนุษย์ตรวจสอบ แล้วนำกลับไปมีส่วนร่วมกับแผนที่อีกครั้ง
• วิธีนี้แยก การตรวจจับอ็อบเจกต์ด้วย YOLOv11 และ การแบ่งส่วนภาพด้วย SAM2 ออกจากกัน แทนการใช้ LLM/VLM โดยให้แต่ละส่วนรับผิดชอบการระบุตำแหน่งและการสร้างขอบเขตโพลิกอน
• ตัวอย่างการทำแผนที่สระว่ายน้ำแสดงกระบวนการสร้างข้อมูลฝึกจากแท็ก leisure=swimming_pool และไทล์ของ Mapbox แล้วอัปโหลดผลลัพธ์ขึ้น Hugging Face Hub
• ระหว่างการอนุมาน ระบบจะรวมไทล์รอบจุดสนใจ แล้วเปรียบเทียบกับอ็อบเจกต์ที่มีอยู่ใน OpenStreetMap เพื่อ ตัดผู้สมัครที่ซ้ำออก และให้มนุษย์ตรวจเฉพาะผู้สมัครใหม่
• งานแบบทำมือทั้งหมดทำได้ราว 2–3 สระว่ายน้ำต่อนาที แต่ Blueprint นี้ประมวลผลได้ถึง 10–15 แห่งแม้ UX ยังไม่ถูกปรับแต่ง จึงเร็วขึ้นประมาณ 5 เท่า

---

เหตุผลที่ใช้ข้อมูล OpenStreetMap สำหรับการทำแผนที่ด้วย AI

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

เลือกโมเดลคอมพิวเตอร์วิทัศน์ขนาดเบาแทน LLM

• Map Features จำนวนมากของ OpenStreetMap แสดงเป็นพื้นที่รูปโพลิกอน
• การที่มนุษย์ค้นหาและวาดโพลิกอนเองใช้เวลามาก แต่หากมีข้อมูลเพียงพอ ก็สามารถฝึก โมเดลคอมพิวเตอร์วิทัศน์ ให้เหมาะกับงานนี้ได้
• Blueprint ใช้โมเดลสมัยใหม่ที่ไม่ใช่ LLM โดยแบ่งเป็นสองขั้นตอน
  • การตรวจจับอ็อบเจกต์: YOLOv11 ของ Ultralytics ค้นหาตำแหน่งของฟีเจอร์แผนที่ที่เกี่ยวข้องในภาพ
  • การแบ่งส่วนภาพ: SAM2 ของ Meta ปรับรูปร่างที่แน่นอนของอ็อบเจกต์ที่ตรวจพบให้เป็นเส้นขอบ
• YOLOv11 และ SAM2 มีขนาดเบา รวดเร็ว และเหมาะกับการรันในเครื่อง
  • น้ำหนักรวมของทั้งสองโมเดลมีขนาด ต่ำกว่า 250MB
  • SmolVLM ที่ถูกกล่าวถึงเพื่อเปรียบเทียบมีขนาด 4.5GB

กระบวนการ 3 ขั้นของ Blueprint

• ขั้นที่ 1: สร้างชุดข้อมูลตรวจจับอ็อบเจกต์จาก OpenStreetMap

  • ดึงข้อมูล OpenStreetMap มารวมกับภาพถ่ายดาวเทียม และแปลงเป็นรูปแบบที่เหมาะสำหรับการฝึก
  • มี Create Dataset Colab ที่รันได้โดยตรงให้ใช้งาน
  • การรวบรวมข้อมูล OpenStreetMap ใช้ API สองตัว
    • Nominatim API: ช่วยให้ผู้ใช้เลือกพื้นที่สนใจได้อย่างยืดหยุ่น
    • Overpass API: ดาวน์โหลดโพลิกอนที่ตรงกับ แท็ก เฉพาะภายในพื้นที่ที่เลือก
  • ในตัวอย่างสระว่ายน้ำ ใช้ Galicia สำหรับการฝึก และใช้ Viana do Castelo สำหรับการตรวจสอบความถูกต้อง
  • แท็กเป้าหมายคือ leisure=swimming_pool และตัดเป้าหมายที่มี location=indoor ร่วมอยู่ด้วยออก
  • หลังดาวน์โหลดโพลิกอน จะเลือก ระดับซูม และระบุไทล์ที่มีโพลิกอนอยู่ในระดับซูมนั้น
  • ดาวน์โหลดไทล์ผ่าน Static Tiles API ของ Mapbox
  • โพลิกอนที่เป็นพิกัดละติจูด·ลองจิจูดจะถูกแปลงเป็นกล่องขอบเขตในพิกัดพิกเซลอ้างอิงตามแต่ละไทล์ และบันทึกใน รูปแบบ Ultralytics YOLO
  • ชุดข้อมูลที่เสร็จแล้วจะถูกอัปโหลดไปยัง Hugging Face Hub โดยชุดข้อมูลตัวอย่างคือ mozilla-ai/osm-swimming-pools

• ขั้นที่ 2: ปรับจูนโมเดลตรวจจับอ็อบเจกต์

  • เมื่อรูปแบบชุดข้อมูลพร้อมแล้ว สามารถปรับจูน YOLOv11 หรือโมเดลอื่นที่ Ultralytics รองรับได้
  • มี Finetune Model Colab ที่รันได้โดยตรงให้ใช้งาน
  • ไฮเปอร์พารามิเตอร์ที่ใช้ได้ดูได้จาก เอกสารการตั้งค่าการฝึก ของ Ultralytics
  • โมเดลที่ฝึกแล้วก็จะถูกอัปโหลดไปยัง Hugging Face Hub
  • โมเดลตัวอย่างคือ mozilla-ai/swimming-pool-detector

• ขั้นที่ 3: มีส่วนร่วมกับ OpenStreetMap

  • รันการอนุมานกับไทล์หลายรายการโดยใช้โมเดลตรวจจับอ็อบเจกต์ที่ปรับจูนแล้ว
  • มี Run Inference Colab ที่รันได้โดยตรงให้ใช้งาน
  • สามารถลองใช้ตัวตรวจจับสระว่ายน้ำตัวอย่างได้ที่ HuggingFace Demo
  • กระบวนการอนุมานต้องมี ปฏิสัมพันธ์จากมนุษย์ อยู่บางส่วน
    • ขั้นแรก เลือกจุดสนใจบนแผนที่
    • คำนวณกล่องขอบเขตรอบจุดที่เลือกตามอาร์กิวเมนต์ margin
    • ดาวน์โหลดอ็อบเจกต์สนใจที่มีอยู่แล้วจาก OpenStreetMap
    • ดาวน์โหลดไทล์ทั้งหมดจาก Mapbox แล้วรวมกันเป็นภาพแบบสแต็ก
    • ภาพสแต็กจะถูกแบ่งกลับเป็นไทล์ที่ซ้อนทับกัน
  • ในแต่ละไทล์จะรันโมเดลตรวจจับอ็อบเจกต์ YOLOv11
  • เมื่อตรวจพบอ็อบเจกต์สนใจอย่างสระว่ายน้ำ ระบบจะส่งกล่องขอบเขตไปยัง SAM2 เพื่อให้ได้มาสก์การแบ่งส่วนภาพ
  • โพลิกอนที่คาดการณ์ได้จะถูกเปรียบเทียบกับโพลิกอนที่มีอยู่เดิมซึ่งดาวน์โหลดจาก OpenStreetMap เพื่อ หลีกเลี่ยงการอัปโหลดซ้ำ
  • ผู้สมัครที่ระบุว่าเป็นอ็อบเจกต์ใหม่จะแสดงทีละรายการ และผู้ใช้จะตรวจสอบ·กรองด้วยตนเอง
  • อ็อบเจกต์ที่ผู้ใช้เลือกเก็บไว้จะถูกอัปโหลดไปยัง OpenStreetMap ในรูปของ changeset เดียว

ประสิทธิภาพและนัยเชิงปฏิบัติ

• OpenStreetMap AI Helper Blueprint แสดงให้เห็นว่า AI สามารถเสริมพลังการมีส่วนร่วมกับแผนที่ของมนุษย์ พร้อมยังคงให้ การตรวจสอบโดยมนุษย์ เป็นศูนย์กลางได้
• ในกระบวนการทำมือทั้งหมด สามารถทำแผนที่สระว่ายน้ำได้ 2–3 แห่งต่อนาที
• เมื่อใช้ Blueprint แม้ UX ยังไม่ถูกปรับแต่ง ก็สามารถทำแผนที่สระว่ายน้ำได้ 10–15 แห่งในเวลาเท่ากัน หรือมากขึ้นประมาณ 5 เท่า
• หากมีข้อมูล OpenStreetMap คุณภาพสูง ก็สามารถฝึกโมเดลอย่าง YOLOv11 ให้ทำการตรวจจับอ็อบเจกต์ได้
• ไม่จำเป็นต้องนำ LLM มาใช้กับทุกปัญหา และสำหรับการตรวจจับฟีเจอร์แผนที่กับการสร้างโพลิกอน การผสานโมเดลคอมพิวเตอร์วิทัศน์ขนาดเบา อาจเป็นทางเลือกที่ตรงจุดกว่า
• หากต้องการฝึกโมเดลสำหรับฟีเจอร์แผนที่อื่นหรือมีส่วนร่วมกับรีโพซิทอรี สามารถใช้ OpenStreetMap AI Helper Blueprint ได้
• Blueprint อื่นที่เผยแพร่แล้วดูได้ที่ Blueprints Hub

[depth221]

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

[GN⁺]

ความคิดเห็นจาก Hacker News

• ในมุมของ OpenStreetMap Foundation ไม่ควรเพิ่ม สิ่งภูมิศาสตร์ที่ AI ตรวจพบ เข้าไปในฐานข้อมูลโดยตรง
  อัลกอริทึมมีปัญหา false positive และมีปัญหาแมปวัตถุที่เป็นเส้นตรงหรือสี่เหลี่ยมผืนผ้าออกมาเป็นรูปทรงสั่น ๆ เหมือนในภาพหน้าจอรองสุดท้าย
  มันมีคุณค่ามากในฐานะเครื่องมือช่วยค้นหาสิ่งที่ขาดหายไป แต่การยืนยันว่าวัตถุที่ตรวจพบถูกวาดอย่างถูกต้องหรือไม่ ยังจำเป็นต้องมี การแทรกแซงจากมนุษย์ อยู่ดี
  อ้างอิง: https://wiki.openstreetmap.org/wiki/Import/Guidelines และ https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_...

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

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

  • กำลังทำโปรเจกต์อย่าง การนำเข้าข้อมูลเวลาเปิดทำการ ของ alltheplaces อยู่
    https://community.openstreetmap.org/t/what-you-think-about-i...
    https://www.openstreetmap.org/user/Mateusz%20Konieczny%20-%2...
    https://codeberg.org/matkoniecz/list_how_openstreetmap_can_b...
  • alltheplaces ใช้แม้กระทั่ง ทรัพยากรที่มีการระบุลิขสิทธิ์ชัดเจนและถูกป้องกันด้วย API key อย่างหละหลวมจนน่ากังวล
    ในสภาพปัจจุบัน มันอาจให้แรงบันดาลใจได้ แต่ยังไม่เข้ากันกับ OpenStreetMap
  • โซลาร์อาจเป็นเรื่องยุ่งยาก
    ยังไม่ชัดว่าจะ แยกแผงโซลาร์เซลล์ ออกจากแผงรับความร้อนจากแสงอาทิตย์อย่างไร
    ภายนอกดูแทบเหมือนกัน แต่หน้าที่ต่างกันมาก

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

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

• เคยทำงานในด้านนี้เมื่อหลายปีก่อน และมี โมเดล ชุดข้อมูล และเครื่องมือ เดิมอยู่มากมายมหาศาล
  https://github.com/satellite-image-deep-learning

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

• Google คงไม่อนุญาต แต่ Mapbox ดูเหมือนจะอนุญาตหากเป็นวัตถุประสงค์ที่ไม่ใช่เชิงพาณิชย์หรือเพื่อใช้กับ OSM
  อย่างไรก็ตาม ทำได้เฉพาะเมื่อใช้ ข้อมูลดาวเทียม ไม่ใช่ข้อมูลเวกเตอร์ของ Mapbox
  ในข้อกำหนดระบุว่าลูกค้าห้ามติดตาม หรือสร้าง/ดึงเนื้อหา ข้อมูล หรือสารสนเทศจากสิ่งที่ให้บริการ แต่มีข้อยกเว้นว่า สามารถใช้ Mapbox Maps ที่ประกอบด้วยภาพดาวเทียมเท่านั้น ติดตามด้วย Studio หรือซอฟต์แวร์ของบุคคลที่สาม เพื่อสร้างชุดข้อมูลเวกเตอร์อนุพันธ์ได้ โดยมีวัตถุประสงค์ต้องเป็นแบบไม่ใช่เชิงพาณิชย์หรือเพื่อ OpenStreetMap
  นับว่า Mapbox ทำได้ค่อนข้างดีทีเดียว

  • Bing ก็อนุญาตให้ผู้ทำแผนที่ OpenStreetMap ใช้ภาพถ่ายทางอากาศเพื่อการ trace เช่นกัน
    https://wiki.openstreetmap.org/wiki/Bing_Maps#Aerial_imagery

• เมื่อไม่กี่เดือนก่อนเคยทำงานที่คล้ายกัน
  แม้จะเป็นสำหรับข้อมูลภูมิศาสตร์ที่ขนาดเล็กกว่า https://github.com/uav4geo/GeoDeep

  • เป็นงานที่ยอดเยี่ยม และอยากคุยเรื่องไอเดียการทำงานร่วมกัน

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

  • ใน OSM เกณฑ์ที่ใช้ trace เองก็มักเป็น ภาพดาวเทียม อยู่แล้ว
    คุณภาพการ trace นั้นบางครั้งแกว่งมาก และเคยต้องแก้แนวชายฝั่งที่เพี้ยนอย่างประหลาดจนถนนไปอยู่เหนือทะเลอยู่หลายครั้ง
    ถ้าเครื่องมือนี้มีความสม่ำเสมอในระดับหนึ่ง ก็อาจดีกว่าผู้มีส่วนร่วม OSM โดยเฉลี่ยก็ได้
    อย่างไรก็ตาม น่าจะเริ่มจากการแยกส่วนบ้าน ถนน และแหล่งน้ำ แล้วเปรียบเทียบกับข้อมูลปัจจุบันเพื่อหาความไม่สอดคล้องและไฮไลต์เป็นจุดที่ควรแก้ไข

• Mozilla ช่วยโฟกัสกับการทำเบราว์เซอร์ดี ๆ ไม่ได้หรือ?

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

  • โปรเจกต์นี้ไม่ได้มีการ fine-tune SAM2
    ข้อมูลการแยกส่วนของ OSM มีคุณภาพไม่พอที่จะฝึกโมเดล segmentation ได้อย่างเหมาะสม
    ที่นี่ใช้โมเดล YOLO สำหรับทำนาย bounding box
    bounding box ของ OSM เพียงพอสำหรับวัตถุประสงค์นี้ และส่ง bounding box แต่ละอันเป็น prompt ให้ SAM2 แยกส่วนภายใน
    เคยลองวิธีส่งจุดกึ่งกลางของกล่องเป็น prompt ให้ SAM ด้วย แต่ผลลัพธ์แย่กว่า

• ได้ออกรุ่นใหม่โดยนำฟีดแบ็กหลายอย่างมาปรับใช้ และแทนที่โค้ดทั้งหมดที่อัปโหลดไปยัง OSM โดยตรงด้วยการ ส่งออกในรูปแบบ OsmChange
  หวังว่านี่จะเป็นอีกก้าวหนึ่งในทิศทางที่ถูกต้อง และจะอภิปรายต่อในเธรดเฉพาะบนฟอรัม OSM