วิธีการออกแบบและรังวัดโครงข่าย GNSS ฉบับคนเดินถนน (ตอนที่ 2)

นับเป็นตอนที่ 2 ที่ใช้เวลาต่อจากตอนที่ 1 นานที่สุด เอาละครับมาสายดีกว่าไม่มา ตอนที่ 2 นี้มาว่ากันด้วยข้อมูลสนามแบบมินิมอล (minimal) เกือบจะที่สุด ส่วนใหญ่ข้อมูลที่ผมมีอยู่ก่อนหน้านี้จะเป็นข้อมูลที่รังวัดหลายหมุดและหลายคาบ (session) ค่อนข้างจะซับซ้อน ผมเลยจะนำเสนอข้อมูลที่รังวัดจากหน้างานล่าสุดไม่นานนี้ มีจำนวน 5 หมุด/5 เครื่อง ถ้ายังไม่ได้อ่านตอนที่ 1 ถ้าสนใจก็ไปอ่านตามลิ๊งค์ด้านล่างครับ

วิธีการออกแบบและรังวัดโครงข่าย GNSS ฉบับคนเดินถนน (ตอนที่ 1)

รวมมิตรเครื่องรับสัญญาน GNSS ของ Trimble, Emlid และ CHCNav

เริ่มจากหมุดรังวัดจำนวน 5 หมุด ใช้เครื่องรับสัญญาน GNSS แบบรวมมิตรยี่ห้อ Trimble SPS855 จำนวน 1 เครื่อง ใช้เครื่อง Emlid RS2 จำนวน 1 เครื่อง และเครื่อง CHCNav i73+ จำนวน 3 เครื่อง รังวัดสองคาบ คาบละประมาณ 1 ชั่วโมง 30 นาที หมุดที่ทราบค่าพิกัดและระดับ (N,E,Z) จำนวน 2 หมุด หมุดที่ต้องการทราบค่าจำนวน 2 หมุด และอีกหมุดหนึ่งทราบค่าพิกัดและค่าระดับแล้วแต่นำเป็นหมุดตรวจสอบ ตำแหน่งที่ตั้งของหมุดดังรูปด้านล่าง

โปรแกรมประมวลผล GNSS Post Processing ด้วย TBC, LGO และ CGO

สำหรับโปรแกรม GNSS Post Processing ที่ผมใช้ทดสอบคือ Trimble Business Center (TBC) ขาใหญ่และขาเก่าแห่งวงการจับคู่ประกบกับขาเก่าอีกรายคือ Leica Geo Office (LGO) และมีน้องใหม่ CHC Geomatics Office (CGO) มาร่วมด้วย เนื่องจาก TBC และ CGO สองโปรแกรมนี้มี workflow ค่อนข้างคล้ายกัน ผมว่า CGO คงใช้ TBC เป็นต้นแบบในการพัฒนา แต่มีบางอย่างที่ CGO ทำได้ดีเช่น User Interface ที่สวยงามใช้ง่ายมากและ workflow ที่เป็นลำดับเรียงร้อยให้ใช้งานได้อย่างง่ายดาย ผมให้คะแนน Usability สูงมาก

ที่จริงผมพยายามจะใช้ Leica Infinity แบบ Trial หนึ่งเดือนแต่จนแล้วจนรอดไม่สามารถคำนวณ Network Adjustment ผ่านได้เตือนว่า “Observation not enough” ทั้งที่ข้อมูลที่ทดสอบเป็นชุดเดียวกันกับโปรแกรมอื่น พยายามแกะแล้วจนอ่อนอกอ่อนใจแล้วล้มเลิกไป จึงย้อนยุคไปใช้ LGO แทน

มาดู Time-based ของข้อมูลการรังวัด

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

คำนวณจำนวนเส้นฐานอิสระ

สำหรับการรังวัด GNSS แบบมีหมุด 5 หมุดและเครื่องรังวัด 5 เครื่อง (N = 5) ถ้ารังวัด 1 คาบ ความเป็นไปได้ของเส้นฐานแบบอิสระจำนวน = N -1 = 5 – 1 = 4 เส้น จากเส้นฐานทั้งหมดต่อคาบ = N*(N-1)/2 = 5*(5-1)/2 = 10 เส้น

ดังนั้นเมื่อรังวัดสองคาบ จะมีเส้นฐานอิสระทั้งหมด = 2 * 4 = 8 เส้น จำนวนเส้นฐานทั้งหมด = 2 * 10 = 20 เส้น

กำหนดเส้นฐานอิสระคาบที่ 1

เมื่อผมทราบว่ามีจำนวนเส้นฐานอิสระต่อคาบ 4 เส้น ผมกำหนดไว้ในใจว่าเส้นควรจะต่อกันตามหลักที่ว่าต่อกันด้วยเส้นที่สั้นที่สุดก่อนผมเลือกได้ดังนี้ ตามเส้นสีแดงเข้ม โดยเริ่มจาก NO1J2529 -> MTP3-03 -> MTP3-11 -> Bm6 -> Bm7 ระวังการลากเส้นฐานอิสระ ต้องไม่ลากให้เป็นรูปปิดเด็ดขาด

กำหนดเส้นฐานอิสระคาบที่ 2

สำหรับเส้นฐานอิสระคาบที่ 2 จำนวน 4 เส้น ผมกำหนดว่าต้องไม่ให้ทับเส้นฐานอิสระคาบที่ 1 เพื่อให้เกิด Loop ที่เป็นรูปสามเหลี่ยมมากที่สุด ลากเส้นตามเส้นสีน้ำเงินเข้ม ไม่ลืมว่าต้องไม่ลากเป็นวงปิดโดยเด็ดขาด สังเกตว่าผมจะลากเส้นต่อเนื่องเป็นวิธีที่ง่ายที่สุด อย่าให้ซ้ำกับคาบที่ 1 เป็นดีที่สุด

Closure Loop

วงปิดเกิดจากเส้นฐานอิสระแต่ละคาบที่มาต่อกัน จำนวนสามเส้น (3 legs) ต้องไม่เป็นคาบเดียวกันเด็ดขาดทั้ง 3 เส้น จะนำมาคำนวณเพื่อตรวจสอบคุณภาพงานรังวัด (Quality control: QC) ถ้าขั้นตอนนี้ข้อมูลวงบรรจบปิด (Closure loop) ไม่ผ่านเกณฑ์ที่กำหนดไว้ด้วยกรณีใดก็ตามจะต้องมีการตรวจสอบข้อมูล บางครั้งเป็นที่ป้อนความสูงจานรับสัญญานไม่ถูกต้อง ถ้าตรวจสอบแล้วว่าป้อนถูกต้องสุดท้ายแล้วต้องรังวัดข้อมูลใหม่

สำหรับงานรังวัดขั้นต้นเมื่อนำเส้นฐานอิสระคาบที่ 1 และคาบที่ 2 มารวมกันจะได้วงปิดทั้งหมดจำนวน 4 วง ดังนี้

ถ้าสังเกตดีๆจะมีวงพิเศษเกิดขึ้นอีกวงหนึ่ง รวมทั้งหมดเป็น 5 วง ในการคำนวณถ้าข้อมูลหมุดบางตัวป้อนค่าความสูง (Height of instrument) ผิดพลาด จะทำให้การคำนวณวงปิดนั้นล้มเหลว จึงสามารถใช้ผลลัพธ์การคำนวณนี้มาตรวจสอบได้ในเบื้องต้น

ขั้นตอนการคำนวณ (Workflow)

ผมขอยกขั้นตอนการคำนวณจากคู่มือภาษาไทยของ CGO มาให้ดู เพราะสรุปขั้นตอนมาได้ง่ายและตรงกันกับที่ผมทำอยู่ หมายเหตุ Loop closure ผมเรียกว่าวงบรรจบปิด

การตั้งค่าสำหรับงานคำนวณ

สำหรับคู่มือของ CGO นั้นมีรุ่นภาษาไทยและภาษาอังกฤษให้เลือกอ่าน โดยเฉพาะคู่มือภาษาไทยทำได้ดี อ่านเข้าใจง่าย ส่วนคู่มือของ LGO ที่เป็นทางการไม่มีเนื่องจากโปรแกรมนั้นเก่าแล้ว แต่ยังพอหาดาวน์โหลดได้ในบางเว็บไซต์

การตั้งค่า (settings) สำหรับการคำนวณนั้น สำหรับ TBC ผมยกให้คู่มือ TBC ที่จัดทำโดยกรมทางหลวงของออสเตรเลียถือว่าดีที่สุด ชัดเจนที่สุด ดีกว่าคู่มือที่ Trimble ทำมาเองเป็นไหนๆ

ในการรังวัดครั้งพบว่าข้อมูลจากดาวเทียม Glonass ได้ข้อมูลที่ไม่ดี เลยตัดทิ้งไม่นำมาคำนวณ ใช้ดาวเทียม GPS และ Beidou มาเป็นหลัก การตั้งค่าใน TBC รวมศูนย์อยู่ในที่เดียวคือ Project Settings

การตั้งค่าใน LGO จะมีสองจุดคือเมื่ออยู่ในแท็บ “GPS-Proc” และ “Adjustment”

การตั้งค่าใน CGO จะแยกไปตามรายการคำนวณ ทำให้การค้นหาเพื่อตั้งค่าทำได้ง่ายกว่ามาก โดยการตั้งค่าชุดที่ 1 จะเป็นตั้งค่าเกี่ยวกับการนำไฟล์เข้า การตั้งค่าชุดที่ 2 จะเป็นการคำนวณเส้นฐาน และการตั้งค่าชุดที่ 3 เป็นการตั้งค่าสำหรับการคำนวณปรับแก้โครงข่าย GNSS

การตั้งระบบพิกัด (Coordinates System)

เนื่องจากบ้านเราใช้พื้นหลักฐาน WGS84 เป็นหลักและใช้ Projection ที่เป็น UTM ซึ่งแบ่งได้เป็นโซน 47 และโซน 48 และปัจจุบันได้ใช้ยีออยด์โมเดล TGM2017 อย่างแพร่หลาย

ข้อกำหนดของจานรับสัญญาน GNSS

ในการประมวลผล GNSS Post Processing ในทางดิ่งแล้ว โปรแกรมต้องการความสูงจากหัวหมุดไปที่ Antenna Phase Center (APC) ปัญหาคือ APC เราไม่สามารถวัดไปตรงๆได้ การวัดทางอ้อมได้แก่วัดไปที่ Bottom of Antenna Mount (BAM) ได้จุดที่จานรับสัญญานต่อกับโพล หรือวัดไปที่ด้านข้างของจานแบบเฉียงๆที่ Trimble เรียกว่า Center of Bumper ล้วนแล้วแต่เป็นปัญหาสำหรับโปรแกรมทั้งนั้น ที่จะต้องคำนวณความสูงดิ่งจริงจากหัวหมุดไปหา APC โดยที่ต้องมีข้อมูลที่เป็นข้อกำหนดมาตรฐาน

โดยข้อกำหนดนี้ได้มาจากหน่วยงาน National Geodetic Survey (NGS) ของอเมริกาได้ทำการสอบเทียบจานรับสัญญานแต่ละยี่ห้อให้มารวมอยู่ในรูปแบบข้อมูลที่เป็นมาตรฐาน เรียกว่า ANTEX (Antenna eXchage Format) จัดเก็บในแอสกี้ไฟล์นามสกุล *.atx และจะมีรูปแบบคลาสสิคอีกรูปแบบที่เรียกว่า ANTINFO (legacy NGS format) จัดเก็บในแอสกี้ไฟล์สำหรับโปรแกรมแกรมรุ่นเก่าเช่น Leica Geo Office (LGO)

Antenna Manager

มาดูของ CGO จะมีทูลส์เรียกว่า Antenna Manager ให้สามารถ import ไฟล์ atx ได้ง่ายดาย แต่ต้องนำเข้าแต่ละยี่ห้อโมเดล (ผมพยายามนำเข้าไฟล์ ngs20.atx ที่ผมดาวน์โหลดมาทั้งก้อน ปรากฎว่าเตือนให้เขียนทับรุ่นที่มีอยู่ในแล้ว คลิกโอเคจนเมื่อยสุดท้าย error ไม่ผ่าน) น่าเสียดายสำหรับ TBC ไม่ปรากฎว่ามีทูลส์นี้ ส่วนการนำเข้า LGO ต้องการรูปแบบ Antenna info

ในการใช้เครื่องรับสัญญานแต่ละยี่ห้อ จะมีทูลส์หรือเครื่องมือในการเขียน Rinex ( Receiver Independent Exchange Format) ส่งผ่านข้อมูลดิบตั้งต้น เช่นความสูงที่วัด วิธีการที่วัด ไปยังโปรแกรมประมวลผล ดังนั้นโปรแกรมประมวลผลจะต้องมีข้อกำหนดของจานรับสัญญานมาทอนจากความสูงที่วัดในสนามมาเป็นความสูงเทียบกับ APC

การแปลงข้อมูล Rinex

ข้อมูล rinex ในปัจจุบันขณะที่เขียนบทความอยู่เป็นรุ่น 4.0.1 (กค. 2023) เนื่องจากมีโปรแกรมรุ่นเก่าๆเช่น LGO ที่ต้องการไฟล์รุ่น 3.0.2 ผมจึงหลีกเลี่ยงไม่แปลงไปรุ่นสูงๆมาก สำหรับข้อมูลรังวัดของ Trimble SPS855 ก็สามารถแปลงได้โดยใช้ทูลส์ที่ติดมากับ TBC

สำหรับเครื่องรับสัญญาน Emlid นั้นภายในใช้ chipset ของ Ublox ดังนั้นเวลารังวัดจะได้ไฟล์แบบ raw (*.ubx) การแปลงไฟล์ raw เป็นไฟล์ rinex จะใช้ทูลส์ RTKLib ที่เป็น opensource สังเกตว่าผมต้องช่วยป้อนค่าหลายอย่างเช่นชนิดจานรับสัญญานและความสูง เมื่อทำการ Convert เพื่อแปลงจะได้ไฟล์รังวัดนามสกุล *.obs ผมใช้ windows explorer เปลี่ยนนามสกลเป็น *.23o (ขณะเขียนบทความคือปี 2023 จึงเลือกใช้คำว่า 23 นำหน้าตัวโอ) เพื่อให้โปรแกรมเช่น CGO ได้มองเห็นไฟล์ รวมถึงโปรแกรมแกรมเก่าๆด้วยเช่น LGO

สำหรับข้อมูลของเครื่องรับสัญญาน i73+ CHCNav นั้นค่าที่ได้มาจากเครื่องได้เป็น raw + rinex อยู่แล้วค่อนข้างสะดวก

นำเข้าข้อมูล Rinex

หลังจากได้ข้อมูล rinex มาแล้ว นำข้อมูล rinex มาจัดกลุ่มเป็นโฟลเดอร์ตามคาบการรังวัดเพื่อให้สะดวกต่อการนำมาใช้งานและแยกแยะได้ง่าย

การนำไฟล์ rinex เข้าแต่ละโปรแกรมค่อนข้างคล้ายๆกัน

ตรวจสอบเส้นฐาน

เมื่อนำเข้าไฟล์ rinex โปรแกรมจะสร้างเส้นฐานให้อัตโนมัติ ตามที่ผมกล่าวไว้ข้างต้นถ้ารังวัดคาบที่ 1 และคาบที่ 2 มีข้อมูลเหลื่อมกัน เช่นใน CGO ผมตั้งเวลาที่น้อยที่สุด 1800 วินาที (30 นาที) ถ้าน้อยกว่านี้จะไม่สร้างเส้นฐานให้ จำนวนเส้นฐานอิสระทั้งหมด 20 เส้น ทำให้ดูง่าย สบายตา

สำหรับ TBC โปรแกรมสร้างเส้นฐานมาให้ทั้งหมด 30 เส้น เนื่องจากผมหาที่ตั้งค่าให้ไม่ได้ (อาจจะมีแต่ผมหาไม่เจอ) ผลก็คือตรงที่ข้อมูลคาบที่ 1 และคาบที่ 2 ที่เหลื่อมกัน TBC สร้างมาให้ทั้งหมด

ในเคส LGO จะต่างออกไปไม่มีการสร้างเส้นฐานให้อัตโนมัติ หมายถึงว่าตอนนำไฟล์ rinex เข้าโปรแกรมจะไม่ได้สร้างให้ทันที ผู้ใช้ต้องมาเลือกสร้างเอง (Manual mode) หรือจะใช้วิธีที่โปรแกรมสร้างให้ (Automatic mode) ผมถนัดคำนวนเส้นฐานทีละคู่และจัดเก็บ (store) เพราะเราจะเลือกเส้นฐานอิสระที่กระบวนการเลือกเส้นฐานนี้ ต่างจาก TBC และ CGO ที่สามารถไปคลิกเลือก enable หรือ disable ได้ทีหลัง

การเลือกเส้นฐานอิสระและประมวลผล

มาถึงตอนสำคัญคือการเลือกเส้นฐานอิสระจากเส้นฐานทั้งหมด ตามที่ผมกล่าวไว้ตอนต้นบทความ ลองย้อนไปดูรูปที่ผมแสดงไว้ เราจะเลือกเส้นฐานอิสระจากคาบการรังวัดละ 4 เส้น รวมทั้งหมด 8 เส้น ใน CGO การเลือกไม่ยากคลิกขวาที่เส้นฐานแต่ละเส้น แล้วเลือก Enable หรือ Disable เส้นฐานที่ถูก disable สีจะเปลี่ยนเป็นสีเทาทีบ ทำให้ดูง่าย

จากนั้นทำการประมวลผลเส้นฐานอิสระทีเดียวทั้ง 8 เส้น ผลลัพธ์ที่ Solution type ต้องเป็น “L1 Fix” หรือ “L1/L2 Fix” ถือว่าผ่าน

ใน TBC วิธีการคล้ายๆกันคือเลือกคลิกขวาเส้นฐานอิสระแต่ละเส้น แล้วทำการคลิก Enable/Disable เช่นกันเส้นฐานที่ถูก disable จะเปลี่ยนเป็นสีเทาเข้ม

สำหรับ LGO นั้นต้องออกแรงกว่าเพราะไม่มีเส้นฐานแสดงให้เห็น (ไม่มีการสร้างให้ตอนนำเข้าไฟล์ rinex) สำหรับผมแล้วใช้การจับคู่ทีละคู่ เพื่อสร้างเส้นฐาน โดยการคลิกให้เส้นหนึ่งเป็นสีแดง (reference) และอีกเส้นเป็นสีเขียว (rover) สีนั้นสามารถสลับกันได้โดยไม่มีผลอะไร แต่ถ้าเลือกเป็นสีเขียวหรือสีแดงทั้งคู่ โปรแกรมจะไม่คำนวณให้ ที่ต้องระลึกไว้คือผมเลือกตามที่ผมวางแผนเลือกเส้นฐานไว้ในตอนต้นของบทความ

เมื่อเราคลิกที่ไอคอนรูปเกียร์ โปรแกรมจะประมวลผลเส้นฐานมาให้ จากนั้นดูที่ Ambiguity Statu (ตัวเลขปริศนา) ถ้าผ่านจะขึ้น “Yes” แล้วคลิกขวาเลือก “Store” เพื่อเก็บผลลัพธ์ไว้

ประมวลเส้นฐานอิสระ (Baseline Processing)

สำหรับ TBC และ CGO เดินในแนวทางเดียวกัน เมื่อทำการ disable baseline ที่เป็นเส้นฐานไม่อิสระไว้แล้ว ที่เหลือสามารถทำการคำนวณได้ทั้งหมดทีเดียว ซึ่งผมถือว่าสะดวกกว่ามาก เพราะเราสามารถสั่งโปรแกรมคำนวณเมื่อไหร่ก็ได้ เช่นในกรณีเปลี่ยนค่า config ใหม่ ต่างกันนิดตรงที่ TBC คำนวณเสร็จเราต้องสั่ง “Save” ผลการคำนวณ ส่วน CGO เมื่อสั่งคำนวณแล้วจะเก็บค่าอัตโนมัติ ใน TBC ต้องดูที่ Solution Type ต้องเป็น “Fixed” ถือว่าคำนวณตัวเลขปริศนาผ่าน

การคำนวณวงบรรจบปิด Loop Closure

ต่อไปการคำนวณ Loop Closure ถือว่าเป็นด่านทดสอบ QC (Quality control) ที่จะต้องผ่านด้วย criteria ที่กำหนดไว้ เมื่อผ่านแล้วถึงจะทำการคำนวณ Network Adjustment เพื่อหาค่าพิกัดและค่าระดับในลำดับถัดไป สำหรับวงบรรจบปิดจะสนใจเฉพาะวงที่ประกอบด้วยขาเส้นฐาน 3 ด้านเท่านั้น (3 legs) สำหรับตัวอย่างนี้เอาข้อมูลการรังวัดไปใช้ในงานก่อสร้าง ดังนั้นเกณฑ์ที่เลือกจึงกำหนดให้ error ไม่เกิน 10 ppm หรือคิดเป็นอัตราส่วน 1: 100000 ดังตารางด้านล่างนี้

การคำนวณวงบรรจบปิดและผลลัพธ์ใน TBC

การคำนวณใน TBC เลือกที่ไอคอน “Loop closure” ได้ไม่ยาก แต่การตั้งเกณฑ์นั้นดูจะลึกลับหน่อย ผมเอาขั้นตอนมาดูให้ดังรูปด้านล่าง

ผลลัพธ์กระชับสั้นมาก ผลสรุปคือค่าดีสุดและค่าที่แย่ที่สุด รายละเอียดแต่ละวงให้ตั้ง “Passed loop section” เป็น “Show” ผลก็คือผ่านการคำนวณทั้ง 5 วง โดยมีค่าดีที่สุดอยู่ที่ 2.259 ppm และค่าที่แย่ที่สุดอยู่ที่ 7.526 และค่าทั้งหมดน้อยกว่า 10 ppm ถือว่างานผ่านเกณฑ์ของ FGCC 1989

การคำนวณวงบรรจบปิดและผลลัพธ์ใน CGO

สำหรับการคำนวณวงบรรจบปิดใน CGO ทำได้ง่าย การแสดงผลแบบสรุปย่อ สำหรับรูปแบบที่มีรายละเอียดแต่ละวงนั้นสามารถนำออกได้เป็นไฟล์ pdf

เนื่องจากในการแกสดงผล CGO จะคำนวณทุกวงปิดที่เป็นไปได้ ดังนั้นจะต้องเลือกวงปิด (Loop type) แบบ “Asyn Loop” ซึ่งผมเข้าใจว่าน่าจะเป็นวงบรรจปิดที่ได้จากเส้นฐานอิสระต่างคาบกัน และเลือก Qualified เป็น “Confomity” หมายถึงว่าค่าผ่านเกณฑ์ที่เราตั้งไว้ไม่เกิน 10 ppm

จะเห็นค่า error ดีที่สุดอยู่ที่ 0.67 ppm ค่าแย่ที่สุดอยู่ที่ 5.43 ppm ไม่เกินเกณฑ์ 10 ppm ที่กำหนดไว้ถือว่าผ่าน

การคำนวณวงบรรจบปิดและผลลัพธ์ใน LGO

การตั้งค่าเกณฑ์วงบรรจบปิดสำหรับ LGO ดูเหมือนจะไม่ชัดเจนเหมือนกับ TBC และ CGO ผมเลยไม่ได้ตั้งค่าอะไร หลังจากเราทำการเลือกเส้นฐานอิสระและประมวลผลเส้นฐานแต่ละเส้นจนครบ สามารถตรวจสอบรูปร่างของโครงข่ายได้ที่หน้าจอ การคำนวณวงบรรจบปิดสามารถทำได้ในแท็ป “Adjustment” ด้านล่าง เลือกคำนวณตามที่ผมแคปรูปไว้ด้านล่าง หมายเหตุพอคลิกคำนวณ “Loop closure” เสร็จโปรแกรมไม่ได้แสดงอะไรให้เห็นว่าเสร็จแล้ว จากนั้นก็คลิก Result > Loop เพื่อดูผลลัพธ์

สำหรับ LGO ไม่มีสรุปผลลัพธ์ให้ว่าผ่านกี่วง ไม่ผ่านกี่วง บังคับต้องดูรายละเอียดแต่ละวงกันเลยทีเดียว และที่สำคัญคือ LGO มองเห็นวงบรรจบปิดแค่ 4 วงเท่านั้น

ค่า error ผมใส่เครื่องหมายสี่เหลี่ยมสีแดง ค่าดีที่สุด 0.7 ppm ค่าที่แย่ที่สุด 8.6 ppm ไม่เกินเกณฑ์ 10 ppm ที่กำหนดไว้ถือว่าผ่าน

การประมวลผลปรับแก้โครงข่ายเน็ตเวิร์ค (Network Adjustment)

หลังจากกระบวนการ QC ผ่าน คืองานคำนวณวงบรรจบปิดได้ผลตามเกณฑ์แล้ว สุดท้ายจะมาคำนวณหาค่าพิกัดและระดับของหมุดที่ต้องการทราบค่า โดยเราจะใช้ป้อนค่าพิกัดและระดับให้กับหมุดที่ทราบค่าพิกัดแล้วเข้าไป เรียกในทางเทคนิคว่าตรึงพิกัดหรือ “Fix” เพื่อให้โปรแกรมได้ทำการคำนวณปรับแก้โครงข่ายและได้ผลลัพธ์เป็นค่าพิกัดและระดับของหมุดที่ต้องการทราบค่าออกมา การ Fix ค่าจะแยกออกเป็น 3 รูปแบบคือ Fix แบบ 3D (N,E,Z) ต้องใส่ค่าพิกัดและค่าระดับ และแบบ 2D (N, E) คือใส่ค่าพิกัดอย่างเดียว หรือแบบ 1D (Z) คือใส่เฉพาะค่าระดับ

นำเข้าไฟล์หมุดควบคุม (Control points)

หมุดควบคุมสามารถทำเป็นไฟล์ csv เอาไว้ หรือกรณีมี 2-3 หมุดสามารถคีย์เข้าไปได้ ตอนนี้ผมมีหมุดควบคุม 3 หมุด แต่จะใช้จริงๆแค่ 2 หมุด โดยหมุดอีกตัวจะปล่อยให้ลอย เพื่อตรวจสอบค่า error

ผมจะใช้หมุด NO1J2529 และหมุด MTP30-03 สำหรับ fix ค่าแบบ 3D ส่วนหมุด MTP3-11 ปล่อยให้ลอย เมื่อคำนวณค่าพิกัดและระดับมาได้แล้วจะนำมาเปรียบเทียบกับค่านี้

การคำนวณปรับแก้โครงข่ายด้วย TBC

การนำเข้าไฟล์หมุดควบคุมใน TBC ทำได้ง่ายๆด้วยการคลิกที่ “import” แล้วเลือกไฟล์ จากนั้นทำการคำนวณปรับแก้ด้วยไอคอน “Adjust Network” แล้วทำการคลิกเลือกค่าพิกัดที่จะ fix เป็น 3D แล้วคำนวณต่อด้วยการคลิกไอคอน “Adjust”

กรณีคำนวณรอบแรกไม่ผ่านจะต้องมาคลิกที่ “Weighting” แล้วมาคลิก “Adjust” อีกครั้ง ถ้าผ่านรอบแรกก็เหมือนข้อมูลชุดนี้

เมื่อคำนวณผ่านแล้วสามารถไปดูรายงานได้ ซึ่งหัวรายงานจะแจ้งสถานะการปรับแก้สำหรับของ TBC ผ่านการทดสอบด้วย Chi-squares test ที่ระดับความมั่นใจ 95% จากนั้น TBC จะเปรียบเทียบค่าหมุดควบคุมที่ไม่ได้ใช้ fix คือหมุด “MTP3-11” ซึ่งค่า error ออกมาที่ระดับมม. ซึ่งน่าพอใจ

สุดท้ายเป็นค่าพิกัดและระดับของหมุด BM6 และ BM7 ที่ต้องการ

การคำนวณปรับแก้โครงข่ายด้วย CGO

การนำเข้าไฟล์หมุดควบคุมของ CGO ก็ง่ายเช่นเดียวกัน แต่มีประเด็นตรงที่จุดเอาเข้ามาแล้วต้องเลือกเป็น NE, NEH หรือ NEh ถ้าเลือกเป็น None จะต้องไปใส่ค่าพิกัด Lat/Lon ให้ ซึ่งผมไม่ต้องการ วิธีที่ดีที่สุดของผมคือ remove หมุด “MTP3-11” ออก

จัดการตั้งหมุด MTP3-03 และหมุด NO1J2529 ให้เป็น 3D คือ NEh (h หมายถึงค่าระดับที่เป็น Orthometric height) จากนั้นทำการคำนวณปรับแก้โครงข่าย

ผมเลือกการปรับแก้แบบ “Manual 3D” และเลือกระบบค่าพิกัดแบบ Target Coordinate System ความหมายก็คือระบบพิกัดที่เราใช้อยู่ในปัจจุบัน “UTM Zone 47N WGS84” ที่ตั้งไว้แล้วตั้งแต่ต้น ดูผลลัพธ์แล้วจะเห็นค่าทางสถิติว่าการทดสอบแบบ Chi Square Test ผ่าน

ต่อไปเป็นผลลัพธ์ค่าพิกัดและระดับของหมุด BM6 และ BM7 ที่ได้จากการคำนวณปรับแก้โครงข่าย

จากรูปด้านบนผมลงค่าพิกัดของหมุด MTP3-11 ด้วยตัวหนังสือสีแดง เพื่อเปรียบเทียบค่าพิกัดโดยที่มีค่า error ΔN = 0.001 m และ ΔE = 0.001 m

การคำนวณปรับแก้โครงข่ายด้วย LGO

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

เนื่องจากนำเข้าหมุด MTP3-11 ด้วย วิธีการปลดจากหมุดควบคุมคือไปปลดสถานะจาก control เป็น Navigated ส่วนหมุด NO1J2529 และหมุด MTP3-03 ยังคงสถานะเป็น control

เมื่อหมุดควบคุมพร้อม ต่อไปทำการคำนวณปรับแก้โครงข่าย และเปิดเข้าไปดูรายงาน

ในรายงานของ LGO แสดงรายละเอียดผลการทดสอบ W-test และ F-test ซึ่งบอกตรงๆผมก็ไม่คุ้นเคยมากนัก ก็ขอผ่านไม่นำเสนอ มาดูค่าพิกัดและค่าระดับของหมุด BM6 และ BM7 ดังนี้

จากรูปด้านบนผมลงค่าพิกัดของหมุด MTP3-11 ด้วยตัวหนังสือสีแดง เพื่อเปรียบเทียบค่าพิกัดโดยที่มีค่า error ΔN = 0.001 m และ ΔE = 0.001 m

เปรียบเทียบผลลัพธ์ค่าพิกัดและค่าระดับ

มาดูผลลัพธ์ค่าพิกัดและค่าระดับที่ได้จากการคำนวณปรับแก้โครงข่ายด้วย TBC, LGO และ CGO

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

สำหรับการคำนวณของแต่ละโปรแกรม TBC, LGO และ CGO จะมีรายละเอียดปลีกย่อยต่างๆมากมาย เกินกว่าที่บทความผมจะเสนอให้ละเอียดทุกแง่ทุกมุมได้ จึงนำเสนอในเบื้องต้นให้พอเห็นในภาพรวม โปรดติดตามบทความตอนหน้าครับ