GPS/GNSS Static Measurement: การกำหนดค่า Elevation Mask Angle (กำจัดจุดอ่อน)

บทความอ้างอิง:
>> GPS/GNSS Static Measurement: การกำหนดค่า Timing Interval (ท่านว่ามากหมอ ก็มากความ)

Photo Credited: http://arincdecoder.fr

>> เป็นเวลาเกือบ 2 ปี นับตั้งแต่บทความอ้างอิงข้างต้น ได้ถูกเผยแพร่ออกไป ซึ่งผู้เขียนมีความตั้งใจ ณ ช่วงเวลานั้นว่า จะออกบทความเรื่อง The Mask Angle ตามน้ำไปติดๆ แต่ก็ได้มีภารกิจงานสำรวจฯในประเทศเพื่อนบ้าน เข้ามาสอดแทรกโดยตลอด จนทำให้เกิดโรคเลื่อนระบาด (อีกแล้ว)...ต้องขออภัย มา ณ ที่นี้

ไปกันต่อ ต่อเนื่องจากบทความอ้างอิงข้างต้น ที่ว่าด้วยองค์ประกอบอื่นๆในการกำหนดค่าพารามิเตอร์ต่างๆให้กับ 'ตัวจานสัญญาณดาวเทียม' โดยในบทความนี้ ผู้เขียนจะขออนุญาติกล่าวถึงการกำหนดค่า Elevation Mask Angle ให้กับตัวจานรับสัญญาณฯ ซึ่งเป็นขั้นตอนที่ 'มีความสำคัญ' และส่งผลโดยตรงต่อความคลาดเคลื่อนที่จะเกิดขึ้น ในการสำรวจรังวัดดาวเทียม 

ภาพตัวอย่าง แสดงตำแหน่ง Scatter Plot

ปฐมบท:

ดาวเทียมในระบบ Navigation ดวงหนึ่งๆนั้น เมื่อได้โคจรผ่านแนวเส้นขอบฟ้า หรือโคจรเข้ามาในน่านฟ้าที่ตัวจานรับสัญญาณฯสามารถตรวจจับ Tracking/Locking ได้ โดยจานรับสัญญาณดาวเทียมที่ไม่ได้กำหนดค่ามุม Elevation Mask ใดๆ เมื่อได้ตรวจพบสัญญาณดาวเทียมดังกล่าวแล้ว กระบวนการ Synchronize/Locking สัญญาณฯจะเริ่มต้นขึ้นทันที เพื่อทำการบันทึกข้อมูลสัญญาณดาวเทียมลงในหน่วยความจำ (ตามค่า Timing Interval ที่ได้กำหนด) และการบันทึกข้อมูลสัญญาณฯจากดาวเทียมดังกล่าว จะมีความต่อเนื่อง (Tracking) ไปจนกว่า การ Synchronize สัญญาณฯจะขาดหายไป (จานรับสัญญาณฯตรวจไม่พบสัญญาณดาวเทียม) อันเนื่องมาจากแนวเส้นโคจรของดาวเทียมดวงนั้นๆ ได้โคจรออกนอกอาณาเขตน่านฟ้าไปแล้ว

ภาพตัวอย่าง ทิศทางการ Tracking/Locking รับสัญญาณดาวเทียม แต่ละดวง

การกำหนดตำแหน่งแห่งที่ ให้กับตัวจานรับสัญญาณฯ โดยตั้งอยู่ในพื้นที่เปิดโล่ง 100% ไร้การบดบังใดๆนั้น เป็นสิ่งที่กระทำได้ยาก (ยกเว้นการสำรวจฯดาวเทียมบนยอดเขาสูง หรือกลางทะเล) และเมื่อไม่สามารถที่จะหลีกเลี่ยงปัจจัยทางด้านการบดบัง, การสะท้อน และการอับสัญญาณ ตัวจานรับสัญญาณฯจึงได้มี 'ออปชั่นการกำหนดค่ามุมดิ่ง' (Elevation Mask) ในการรับสัญญาณดาวเทียม

>> การกำหนดค่า Elevation Mask ถือว่าเป็นเรื่องที่ไม่มีความซับซ้อนมากนัก ถ้าผู้ทำการสำรวจฯมีเข้าใจพื้นฐานในเรื่องของ 'มุม' โดยการกำหนดค่ามุมดังกล่าว เป็นวิธีการคัดสรร/แบ่งแยก การรับ-ไม่รับสัญญาณดาวเทียม (ทุกระบบ) ไปตามค่ามุมดิ่งที่กำหนด อาทิ การกำหนดค่า Elevation Mask = 23° หมายความว่า การรับสัญญาณดาวเทียม (ทุกระบบ) ที่อยู่ภายใต้ค่ามุมดิ่ง 0° - 23° จะไม่ถูกบันทึกลงในหน่วยความจำ (Cut Off) หรือในจานรับสัญญาณฯบางรุ่น/บางยี่ห้อ สามารถบันทึกข้อมูลดาวเทียมเก็บเอาไว้ทั้งหมด โดยต้องเข้าไปกำหนดค่า Elevation Mask อีกครั้ง ตอนทำการประมวลผลข้อมูลดาวเทียม ในซอฟแวร์

ภาพตัวอย่างแสดง การกำหนดค่า Elevation Mask

ขออนุญาติท้าวความ (ส่วนตัว):

ย้อนกลับไปในยุคอดีตเกือบๆ 20 ปีที่แล้ว ที่อุปกรณ์สำรวจรังวัดดาวเทียม 'ราคาเรือนล้าน' เพิ่งจะเข้ามาสู่สารขัณฑ์ประเทศ และผู้เขียนในฐานะที่ยังเป็นนักสำรวจฯฝึกหัด ณ ช่วงเวลานั้น เป็นผู้หนึ่งที่ได้เคยปฏิบัติตาม 'นายสั่ง' ในการกำหนดค่า Elevation Mask Angle ให้กับตัวจานรับสัญญาณฯ ในแบบที่ 'ไม่มีแบบแผนใดๆ' บางทีก็ใส่ค่ามุมต่ำๆ บางทีก็ใส่ค่ามุมสูงๆ นายสั่งว่าอย่างไร ก็เออออ ห่อหมก แบบไม่รู้สี่ รู้แปด ตามน้ำกันไปเรื่อย 

* ผู้เขียนได้เคยสอบถามว่า ทำไมถึงต้องเปลี่ยนค่าเหล่านี้กลับไป-กลับมา มุมแคบบ้าง มุมกว้างบ้าง ซึ่งได้รับคำตอบกลับมาว่า มีผู้ชำนาญงานทางด้านนี้บอกมาอีกที...(ผู้ชำนาญ อีกแล้ว?)...ครั้นจะไปค้นคว้าหา ข้อมูล How To? ใน Google นั้น ยิ่งไปกันใหญ่ ด้วยเหตุว่าในยุคสมัยนั้น ยังเป็นยุคที่มีระบบปฎิบัติการ Windows 98 เป็น 'สุดยอดเทคโนโลยีล้ำสมัย' โดยที่ยังไม่มีผู้ใดที่รู้จักคำว่า Google ว่า มันคืออิหยัง?

ภายหลังการปฏิบัติตามนายสั่ง มาเนิ่นนานในช่วงระยะเวลาหนึ่ง ได้ทำให้ผู้เขียนเสาะแสวงหาคำตอบ ถึงหลักวิธีการที่ถูกต้อง ในการกำหนดค่ามุม Elevation Mask ให้กับตัวจานรับสัญญาณฯ...ซึ่งในยุคสมัยนั้น การเข้าถึงเทคโนโลยีทางด้านอินเตอร์เน็ตด้วยระบบปฏิบัติการ Windows Me เป็นสิ่งที่มีความยากลำบาก และล่าช้ามาก เมื่อต้องใช้โมเด็ม 56 Kpbs (แต่วิ่งจริงประมาณ 28Kpbs +เสียงสุดหลอน ติ้งต่องๆๆๆ แครกๆๆๆ ครากกๆๆๆ ติดบ้าง ไม่ติดบ้าง เอ๋ๆ เอ๋อๆ, ถ้าท่านผู้อ่านเคยผ่านประสบการณ์ตรงนี้ 'เราคือเพื่อนกัน') ในการเชื่อมสัญญาณอินเตอร์เน็ต และถึงแม้ว่าจะต่อเชื่อมอินเตอร์เน็ตได้ แต่ก็ไม่รู้ว่าจะค้นหาข้อมูลเรื่อง Elevation Mask Angle ได้จากที่ใด มัน 'ยังไม่มีข้อมูล' ในอินเตอร์เน็ต โดยเฉพาะในภาษาชาวเรา...และยิ่งไม่ต้องไปเสียเวลาค้นหาให้เมื่อยตุ้ม ก็ในเมื่อจำนวนผู้ครอบครองเครื่องมือรับสัญญาณดาวเทียมในสารขัณฑ์ประเทศชาวเรา ยังมีน้อยราย และมีผู้คนจำนวนไม่น้อย ณ ยุคสมัยนั้น ยังไม่รู้เลยว่า 'มันคืออะไร? ใช้ทำอะไร?'

'การถามซึ่งหน้า' ตามโอกาสที่เอื้ออำนวย ต่อชาวต่างชาติหลายท่านที่ทำงานสำรวจฯทางด้านนี้ เป็นวิธีที่ผู้เขียนได้เลือกใช้ และการถามเพื่อขอความรู้ในประเด็นเรื่อง Elevation Mask Angle ที่ว่านี้ ได้สร้างความ ?? ยิ่งขึ้นไปอีก เมื่อผู้ตอบ (ในยุคสมัยนั้น) ต่างพากันตอบไปคนละทิศ คนละทาง หรือออกแนวมากหมอ ก็มากความ ซึ่งผู้เขียนสรุปมาได้ 3 วิธีการ คือ;

1. แบบล๊อคค่ามุม Elevation Mask 'ตายตัว' (fixed) ตามที่ทางศูนย์ฯ/ตัวแทนจำหน่าย แนะนำ อาทิ สาย Topcon แนะนำให้ล๊อคไว้ที่ 15°, สาย Trimble แนะนำให้ล๊อคไว้ที่ 10°, สาย Ashtech แนะนำให้ล๊อคไว้ที่ 10°, สาย Leica แนะนำให้ล๊อคไว้ที่ 10°-15° หรือสายหยวนแนะนำให้ล๊อคไว้ 13° และอื่นๆ...ในประเด็นนี้ คือการกำหนดค่ามุม Elevation Mask เอาไว้แบบคงที่ตายตัว ตามที่สายผู้ผลิตฯต่างๆแนะนำให้ ใช้กับทุกๆสภาพภูมิประเทศ และทุกๆสภาพแวดล้อม
2. แบบล๊อคค่ามุม Elevation Mask ให้เป็น 0° ประมาณว่า อย่าไปแตะต้องมัน ให้ล๊อคค่ามุมฯ ไว้ที่ 0° ใช้กับทุกๆสภาพภูมิประเทศ และทุกๆสภาพแวดล้อม
3. แบบเปลี่ยนค่ามุมองศา เป็นค่าใดๆ ไปตามสภาพแวดล้อม อ้อมข้าง ณ ตำแหน่งที่ตั้งจานรับสัญญาณฯเป็นสำคัญ อาทิ เมื่อตำแหน่งตั้งจานรับสัญญาณฯ อยู่ในตำแหน่ง 'อับสัญญาณ' ซึ่งอาจจะถูกแวดล้อมอ้อมข้าง ไปด้วยต้นไม้ขนาดใหญ่, ตึกสูง, หุบเขา ฯลฯ ซึ่งบดบัง ต่อการรับสัญญาณฯ...ท่านว่าให้กำหนด ยกค่ามุม 'ให้สูงขึ้น' จนพ้นแนวบดบังต่างๆ หรือกำหนดค่ามุมให้กว้างๆ บานออก ในพื้นที่เปิดโล่ง

ภาพตัวอย่าง แสดงการกำหนดค่ามุม Elevation Mask ให้สูงขึ้นจนพ้น แนวบดบังต่างๆ

ในขณะที่ใช้การกำหนดค่ามุม Elevation Mask ให้ 'ต่ำลง' หรือกำหนดค่ามุมองศาให้เป็น 0° ในกรณีที่ตั้งจานรับสัญญาณฯ อยู่บนยอดเขา หรือกลางทะเล

ภาพตัวอย่าง แสดงการกำหนดค่ามุม Elevation Mask ให้เป็น 0°

>> จากที่ผู้เขียนได้กล่าวข้างต้นว่า มีวิธีการอยู่ 3 วิธีในการกำหนดค่ามุมดังกล่าว ซึ่งวิธีการที่ 3 (แบบเปลี่ยนค่ามุมองศา เป็นค่าใดๆ) เป็นวิธีที่ผู้เขียนได้นำมาใช้ 'พัฒนา ปรับเปลี่ยน และต่อยอด' จนถึงปัจจุบัน ซึ่งมีความ 'ยืดหยุ่น' ไปตามสถานการณ์ (หน้างานฯ) ในแต่ละพื้นที่ๆ มีความแตกต่างกันทางสภาพแวดล้อมอ้อมข้าง โดยในบทความนี้ ผู้เขียนจะมุ่งเน้นอธิบาย 'วิธีการกำหนดค่าฯ ในแบบที่เรียกว่าวิธีการยืดหยุ่น' ที่ว่านี้ เป็นสำคัญ

หลักแนวคิดพื้นฐานที่ผู้เขียน (ส่วนตัว) ใช้ในการกำหนดค่ามุม Elevation Mask 

1. 'พยายามกำหนดค่ามุมฯ ให้มีค่าต่ำมากที่สุด เท่าที่จะเป็นไปได้ โดยต้องมีค่าไม่ต่ำกว่า 7°' เพื่อที่ตัวจานรับสัญญาณฯจะสามารถรับสัญญาณดาวเทียมได้มากที่สุด (มีจำนวนดาวเทียมมาก) และยังส่งผลโดยตรงต่อค่า GDOP (Geometric Dilution Of Precision) ที่ลดต่ำลง เมื่อ 'ระยะห่าง' ระหว่างดาวเทียมบนแนวเส้นโคจรแต่ละดวง มีระยะห่างระหว่างกัน 'เพิ่มมากขึ้น' และนั่นหมายถึง การมีความแม่นยำทางตำแหน่ง และทางระดับ ที่เพิ่มมากขึ้น

* การกำหนดค่า Elevation Mask ให้ 'ต่ำลง' จาก 7° ลงจนถึง 0° ผู้เขียนพบว่า แม้จะได้รับข้อมูลดาวเทียมจากจำนวนดาวเทียมที่ตรวจพบมากขึ้นกว่าเดิม และค่าความคลาดเคลื่อนทางมุมเลขาคณิตของดาวเทียม GDOP แสดงค่าเป็นที่น่าพึงพอใจ แต่ข้อมูลจากการประมวลผลที่ได้รับนั้น มีค่าความคลาดเคลื่อนเพิ่มขึ้นอย่างมีนัยยะ (แต่ค่าความคลาดเคลื่อนไม่สูงเพิ่มขึ้นแบบน่าตกใจ ในกรณีที่ปรับกำหนดค่า Elevation Mask สูงขึ้น และการรับสัญญาณดาวเทียมได้น้อยลง (จำนวนที่น้อยลง)) ซึ่งความคลาดเคลื่อนที่เพิ่มขึ้นน่าจะเกิดจาก 'ระยะทาง ที่เพิ่มมากขึ้น' ระหว่างตัวจานรับสัญญาณฯและดาวเทียมที่ตรวจพบที่ค่ามุมต่ำๆ...และเมื่อผู้เขียนปรับค่ามุม Elevation Mask ให้เพิ่มสูงขึ้นเล็กน้อย ปรากฎว่าข้อมูลจากการประมวลผล แสดงค่าความคลาดเคลื่อนที่ลดลง

* การรับสัญญาณดาวเทียมจำนวนมาก หลายดวง และสัญญาณฯมีคุณภาพดี จะสามารถช่วยลดเวลาในการทำการสำรวจฯ ให้สั้นลง

2. ค่ามุมที่กำหนดนั้น ควรที่จะมีค่ามุมองศาที่สูง 'ข้ามพ้น' แนวบดบังอ้อมข้าง อาทิ กลุ่มต้นไม้ขนาดใหญ่ ตึกรามบ้านช่อง ฯลฯ 'ในระยะไกล' ในประเด็นนี้ การเลือกตำแหน่งตั้งอุปกรณ์รับสัญญาณดาวเทียม ผู้ทำการสำรวจฯ ควรที่จะเลือกพื้นที่ๆ มีความเปิดโล่งมากที่สุด เท่าที่จะเป็นไปได้

* การปรับค่ามุมองศา ให้เงยขึ้นพ้นแนวบดบังต่างๆนั้น จะทำให้เกิดพื้นที่ในการรับสัญญาณฯ มีขนาดที่แคบลง โดยที่ค่า DOPs ต่างๆ จะเพิ่มสูงขึ้นอย่างมีนัยยะ และส่งผลโดยตรงต่อข้อมูลการสำรวจฯ ซึ่งจะมีค่าความคลาดเคลื่อนเพิ่มสูงขึ้น...ฉะนั้น ผู้ทำการสำรวจฯ จึงต้องทำการตรวจสอบค่า RMS ของ HDOP และค่า VDOP ที่ตัว Controller ภายหลังการปรับค่ามุม Elevation Mask ว่าอยู่ในเกณฑ์ยอมรับได้หรือไม่ หรืออาจจะ ใช้ซอฟแวร์/ Application ในการ 'วางแผนและตรวจสอบ' หาค่ามุม Elevation Mask ที่เหมาะสมสำหรับพื้นที่ฯ ก่อนทำการสำรวจฯ

ภาพตัวอย่าง แสดงการกำหนดค่ามุมองศา ให้ยกสูงพ้นจากแนวบดบังสัญญาณฯ

* การปรับค่ามุมองศา ให้ต่ำลงกว่าความสูงของแนวบดบัง จะทำให้เกิดสภาวะการณ์ Cycle slip หรือสภาวะที่การรับสัญญาณดาวเทียมขาดๆ-หายๆ เป็นช่วง อันเนื่องมาจากการบดบังต่างๆ 

ผู้เขียน ได้ทำการทดลอง (ส่วนตัว) เพื่อทดสอบ 'สมมุติฐาน' จากทั้ง 3 วิธีการข้างต้น มาอย่างต่อเนื่อง นับตั้งแต่ปี พ.ศ. 2556 ในหลากหลายสถานการณ์+พื้นที่การสำรวจฯหน้างานจริง ซึ่งมักจะมีอุปสรรคจากการ บดบังสัญญาณดาวเทียมอยู่เสมอๆโดยกำหนดค่า Elevation Mask ให้เป็น 0° เพื่อตรวจสอบค่า DOPs ต่างๆ จะแสดงความเหมือน/แตกต่าง จากการกำหนดค่า Elevation Mask ให้เป็น 10°, 15°, 25° หรือ 30° อย่างไร เหล่านี้เป็นต้น

ตัวอย่าง ตารางแสดงผลการทดสอบเปรียบเทียบ การกำหนดค่า Elevation Mask Angle

จากภาพตัวอย่างการทดลองข้างต้น ให้พิจารณาที่ค่า HDOP และค่า VDOP  เป็นสำคัญ โดยจะเห็นว่าค่า DOPs ต่างๆ มีค่าต่ำสุดที่ ค่ามุม Elevation Mask Angle = 0° และมีค่า DOPs เพิ่มขึ้นตามลำดับ เมื่อค่ามุมองศามีค่าสูงขึ้น (พื้นที่รับสัญญาณฯแคบลง) โดยพิจารณาที่ตำแหน่งค่ามุม 15° ถึง 30° จะพบว่าค่า DOPs มีความลาดชันเพิ่มมากขึ้นอย่างมีนัยยะสำคัญ และนั่นหมายถึง ความคลาดเคลื่อนของข้อมูลดาวเทียม ที่เพิ่มมากขึ้น...ค่า Elevation Mask Angle 'สูงสุด' ที่ผู้เขียน (ส่วนตัว) นิยมกำหนดนั้น ไม่เกิน 15°

วิธีการตรวจสอบค่า Elevation Mask Angle ที่เหมาะสมในการสำรวจฯ (แบบออนไลน์)

>>  เป็นวิธีการที่ผู้เขียน (ส่วนตัว) นำมาประยุกต์ใช้ในการ 'วางแผน' การสำรวจรังวัดดาวเทียม สำหรับงาน Control Survey ที่ 'ต้องการความละเอียดสูง' โดยการใช้ Application (Android) หรือเว็บไซต์ติดตามการโคจรของระบบดาวเทียม (ทุกระบบ) แบบออนไลน์ ที่ชื่อว่า GNSS View >> https://app.qzss.go.jp/GNSSView/gnssview.html?t เพื่อตรวจสอบแนวโน้ม ความคลาดเคลื่อนมาก-น้อย ที่จะเกิดขึ้นใน 'ช่วงเวลาการทำการรังวัด' โดยอาศัยการตรวจสอบค่า HDOP และ VDOP 

ตัวอย่าง การตรวจสอบค่า Elevation Mask Angle ณ ตำแหน่ง Lat: 14° 37", Lon: 101° 9"

จะเป็นการดีสักเพียงใด ถ้า 'มีความถูกต้อง' จากการสำรวจฯดาวเทียมที่ 'เพิ่มมากขึ้นกว่าเดิม'

GNSS Solutions...กับความเข้าใจที่คลาดเคลื่อน (ลงทุนฆ่าควาย แต่เสียดายพริก)

>> ผู้เขียนขออนุญาติ หยิบยกเอาประเด็นคำถามที่น่าเคลือบแคลงสงสัยผ่านทางหลังไมค์ ถึงเรื่องวิธีการใช้งานตัวโปรแกรมฯ CGO Office ในการประมวลผลข้อมูลดาวเทียมที่ได้จากจานรับสัญญาณฯ ยี่ห้อ CHC รุ่น i80...ซึ่งผู้เขียนได้สอบถาม ไล่เลียงไปถึงว่าตอนที่ซื้อหาเครื่องมือสำรวจฯยี่ห้อดังกล่าว ทางตัวแทนจำหน่าย/ศูนย์ฯ เขาไม่สอนวิธีการใช้งานตัวโปรแกรม CGO Office หรืออย่างไร?

คุยกันไป คุยกันมา เลยจับประเด็นได้ว่า ตอนที่ซื้อเครื่องมือสำรวจฯดาวเทียมในยี่ห้อ/รุ่น ดังกล่าวมาใช้งานนั้น 'ไม่ได้' ซื้อตัวโปรแกรมฯ CHC CGO Office ติดมาด้วย (ราคา ณ ยามนั้น 'หลายหมื่นบาท') ด้วยเหตุว่ามีตัวโปรแกรมฯ GNSS Solutions (version 3.x) ของเดิมอยู่แล้ว ซึ่งใช้สำหรับประมวลผลข้อมูลดาวเทียม ที่ได้จากจานรับสัญญาณฯ ยี่ห้อ Ashtech รุ่น ProMark 3 และรุ่น ProMark 500 ที่ ณ ปัจจุบัน จานรับสัญญาณเหล่านี้ ยังใช้งานได้ดีอยู่

Ashtech ProMark 500 (งานแท้ คุณภาพมาเต็ม)

โดยเมื่อนำข้อมูลดาวเทียม (*.HCN) ที่ได้จากจานรับสัญญาณฯ CHC-i80 มาแปลง (Covert) เป็นไฟล์ RINEX (*.??O) เพื่อนำเข้าสู่ตัวโปรแกรมฯ GNSS Solutions...ผลลัพธ์ที่ได้จากการประมวลผลฯนั้นมีค่า 'ใกล้เคียง' (แตกต่างในระดับ มม. อย่างไม่มีนัยยะ) กับค่าการประมวลผลที่ได้จากจานรับสัญญาณฯ Ashtech ProMark 3/ProMark 500 โดยเทียบผลลัพธ์ผลการคำนวณ กับหมุดฯคู่/เส้น Baseline ที่ทราบค่าฯมีอยู่เดิม ซึ่งมีระยะห่างประมาณ 100 ม...จึงสรุปได้ว่า ตัวโปรแกรมฯ GNSS Solutions สามารถใช้ประมวลผลข้อมูลดาวเทียม ที่ได้จากจานรับสัญญาณฯ CHC-i80 ได้?

จากเรื่องราวข้างต้น ได้กระตุ้นให้ผู้เขียนต้อง Release บทความ 'ปรับความเข้าใจ' ในประเด็นที่ว่านี้กันสักครั้ง และไม่เฉพาะชนนายช่างฯชาวเราเท่านั้น (ชนกลุ่มน้อยบางส่วน) ที่ยังคงไว้ซึ่ง 'สายอนุรักษ์นิยม' ในตัวโปรแกรมฯ GNSS Solutions แต่ยังรวมไปถึงชนนายช่างฯใน สปป.ลาว ที่ผู้เขียนรู้จัก/บาง บ.สำรวจฯ ที่ยังคงใช้จานรับสัญญาณฯ Ashtech Z-Max และ ProMark 500 ร่วมกับจานรับสัญญาณฯ CHC/ComNav ฯลฯ แต่กลับยังคงไว้ซึ่งวิถีแห่ง GNSS Solutions ??

จริงๆแล้ว กระบวนการข้างต้น ในการใช้ตัวโปรแกรมฯ GNSS Solutions ประมวลผลข้อมูลดาวเทียมที่ได้จากจานรับสัญญาณฯ ในยี่ห้อ/รุ่นต่างๆ ณ ยุคปัจจุบันนั้น 'สามารถทำได้'...แต่..."มันมีอะไรที่มากกว่านั้น" 

>> ขออนุญาติ 'จั่วหัว' ไว้แค่บรรทัดนี้ก่อน <<

SPECTRA Precision Software

>> ในยุคสมัยราวๆปี พ.ศ. 2541 ซึ่งเป็นยุคสมัยที่อุปกรณ์สำรวจฯดาวเทียมความละเอียดสูง ยังมีราคาเรือนล้าน แพงลิบลิ่ว เข้าถึงยาก และสามารถรองรับสัญญาณดาวเทียมในระบบ GPS (L1/L2) เท่านั้น โดยไม่นับรวมดาวเทียมในกลุ่มไม้ประดับ อย่าง SBAS ...การเข้าถึงยาก โดยเฉพาะทางด้าน 'ราคา' ที่ไม่ค่อยจะเป็นมิตรเท่าใดนัก...ทำให้งานสำรวจฯประเภท Control Survey ในยุคสมัยนั้น ที่มีพื้นที่สำรวจขนาดกว้างใหญ่ ระยะทางสำรวจฯยาวไกล จึงยังต้องอาศัย 'งานสำรวจฯวงรอบ' ในการกำหนดตำแหน่งหมุดฯควบคุมต่างๆ ซึ่งเป็นงานสำรวจรังวัดด้วยกล้องฯ ที่ต้องใช้ระยะเวลาในการสำรวจฯยาวนาน และได้นำมาซึ่งต้นทุนในการสำรวจฯที่สูงขึ้น

ราวๆขวบปีให้หลัง การมาถึงของอุปกรณ์สำรวจฯรังวัดดาวเทียมในกลุ่ม 'เอื้ออาทร' ที่ทำให้ชนนายช่างฯชาวเรา (บางส่วน และรวมถึงตัวผู้เขียน) ได้มีโอกาส 'เข้าถึง' เข้าไปศึกษาเรียนรู้ในเทคโนโลยีการสำรวจรังวัดดาวเทียมดังกล่าว และหนึ่งในอุปกรณ์สำรวจฯรังวัดดาวเทียมเหล่านั้น คือการมาถึงของอุปกรณ์รับสัญญาณดาวเทียมในยี่ห้อ Ashtech (+Magellan/Thales) รุ่น ProMark 1, ProMark 2 และ ProMark 3 ที่ทำให้ชนนายช่างฯชาวเรา สามารถคบหาดูใจได้ในระดับหนึ่ง (ราคาค่าตัว ยังแรงพอสมควร)
* ในยุคสมัยดังกล่าว ถือว่าเป็น 'ยุคเปลี่ยนผ่าน' ในวงการสำรวจรังวัดอย่างแท้จริง ที่แต่เดิมนั้นงานสำรวจฯ Control Survey จะถูกอ้างอิงจากค่า 'มุม และระยะทาง' จากการส่องกล้องฯเป็นสำคัญ และเมื่ออุปกรณ์สำรวจฯรังวัดดาวเทียม ได้เข้ามามีบทบาทในการระบุตำแหน่ง (ความละเอียดสูง) บนพื้นผิวโลก ได้ช่วยให้งานสำรวจฯ Control Survey ในพื้นที่สำรวจฯที่มีขนาดใหญ่ มีความถูกต้อง แม่นยำมากยิ่งขึ้น อีกทั้งใช้เวลาในการทำการสำรวจฯที่สั้นลง

ProMark 2 และ ProMark 3 (ความละเอียดในระดับ 'เซนติเมตร')

Photo Credited: Researhgate และ Archive.amerisurv.com

และการมาถึงของอุปกรณ์สำรวจฯรังวัดดาวเทียมยี่ห้อ Ashtech นี้เอง ที่ทำให้ชนนายช่างฯ (สาย Ashtech) ต้องได้เข้าไปศึกษาเรียนรู้กับตัวโปรแกรมประมวลผลข้อมูลดาวเทียมที่ชื่อว่า Ashtech Solution (รุ่นบุกเบิก) และได้ถูกพัฒนาเปลี่ยนมาเป็น GNSS Solutions ในระยะ 2-3 ปีต่อมา จากค่าย Spectra

หน้าตาโปรแกรมฯ GNSS Solutions

Photo Credited: Javad GNSS

ตัวโปรแกรมฯ GNSS Solutions เป็นโปรแกรมประมวลผลข้อมูลดาวเทียม ที่ผู้เขียนได้เคยใช้งานอยู่หลายปีพอสมควร และต้องขออนุญาติกล่าวว่าเป็นโปรแกรมฯที่อยู่ในชั้น 'ดีเยี่ยม' (ให้ 9 เต็ม 10 ไม่หัก) เมื่อต้องทำการประมวลข้อมูลดาวเทียมในระบบ GPS และ GLONASS (ทั้ง L1/L2) เมื่อให้เวลาในการรับสัญญาณดาวเทียมที่มากพอ จะได้ค่ามุมและระยะทางของเส้น Baseline ที่แน่น ไม่งอแง เมื่อสอบเทียบกับกล้องฯ Total Station อีกทั้งยังเป็นโปรแกรมที่ใช้งานค่อนข้างง่าย ไม่ซับซ้อน สามารถรองรับไฟล์ RINEX จากจานรับสัญญาณฯจากยี่ห้ออื่นๆ นำเข้ามาประมวลผลร่วมกันได้
* ท่านใดสนใจ สามารถดาวน์โหลดไปทำการทดสอบกันได้ ในแบบ Trial version (30 วัน) ลองดูว่า 'ทำไมมันดีกว่าชาวบ้านเขา' ดาวน์โหลด >> Click!

>> ด้วยความที่การใช้งานตัวโปรแกรมฯ GNSS Solutions นั้นมีความสะดวก รวดเร็ว มีความถูกต้องแม่นยำสูง...อาจจะเป็นสาเหตุหนึ่งที่ทำให้ผู้ใช้งาน 'บางท่าน' ติดอกติดใจ (ผู้เขียนทราบมาว่า มีบางท่านถึงขนาด 'ยึดติด' ไม่ปล่อยวาง) ไม่ยอมที่จะเมียงมองไปยังโปรแกรมประมวลผลข้อมูลดาวเทียม อื่นๆ และนั่นคือประเด็นสำคัญที่ทำให้เกิด 'การมองข้าม' สิ่งสำคัญบางอย่าง? หรืออาจจะคิดไปว่ามันคือโปรแกรมฯที่ชื่อ GNSS ก็ต้องมีความสามารถประมวลผลข้อมูลดาวเทียมในระบบ  GNSS ได้ทั้งหมด ?

โปรแกรมฯ GNSS Solutions เวอร์ชั่นล่าสุด เท่าที่ผู้เขียนได้รับทราบคือ version 3.80.8 ซึ่งเป็นช่วงปลายยุคสมัยของระบบ GNSS รุ่นบุกเบิกที่มี GPS+GLONASS อยู่เพียง 2 ระบบหลัก และพร้อมๆกับการมาถึงของระบบดาวเทียม Multi-GNSS ที่ความสามารถของตัวจานรับสัญญาณฯ ได้ถูกพัฒนาให้รองรับสัญญาณดาวเทียมในระบบหลักอีก 2 ระบบ นั่นคือระบบ Galileo และ Beidou (Compass)

Photo Credited: NASA

ในยุคปัจจุบันที่ตัวจานรับสัญญาณฯในระบบ Multi-GNSS กำลังได้รับความนิยมอยู่ ณ ขณะนี้ ที่ใครๆ ต่างมีไว้ใช้งาน เข้าถึงได้ตามกำลังทรัพย์บนหน้าตัก ทั้งสายหยวน สายยุ่น สายยุโรป สายอเมริกา หรือแม้แต่ 'สายลูกทุ่ง' (ซื้อบอร์ดรับสัญญาณฯ OEM มาพัฒนากันต่อ และแปะยี่ห้อของตนเข้าไป) 

บอร์ด OEM ยี่ห้อ TERSUS รุ่น BX10C  

(คุณภาพมาเต็ม ทุกดอก)

Photo Credited: TERSUS

ซึ่งตัวจานรับสัญญาณฯเหล่านี้ ล้วนต่างมาพร้อมกับโปรแกรมประมวลผลฯประจำค่ายของตน ที่ต้องใช้ในการประมวลผลข้อมูลดาวเทียมจาก 4 ระบบหลัก (+ในอนาคตอันใกล้ ระบบดาวเทียม QZSS 'สายยุ่น' กำลังทยอยเข้ามา อยู่ ณ ปัจจุบัน หรือแม้แต่ระบบดาวเทียม 'สายโอปป้า' และ 'สายอาบัง')

>> เรื่องที่ผู้เขียนได้ จั่วหัว เอาไว้ข้างต้น 'เราจะไปกันต่อ' นับจากบรรทัดนี้ <<

การนำข้อมูลดาวเทียมจากจานรับสัญญาณฯในระบบ Multi-GNSS ไปแปลง (Covert) เป็นไฟล์ RINEX เพื่อนำเข้าสู่ตัวโปรแกรม GNSS Solutions เพื่อทำการประมวลผลนั้น สามารถ 'ทำได้'...แต่มันทำได้ ในบริบทที่ว่า ต้องยอมรับเงื่อนไขที่จะต้อง 'ถูกระงับการใช้งาน' ข้อมูลดาวเทียมในระบบ Galileo และ Beidou ด้วยเหตุว่าตัวโปรแกรม GNSS Solutions นั้น สามารถรองรับข้อมูลดาวเทียมได้เพียง 2 ระบบหลักเท่านั้น นั่นคือระบบ GPS และ GLONASS (เกินกว่านี้ ตัวโปรแกรมฯไม่รู้จัก)

ออปชั่นการเลือกข้อมูลระบบดาวเทียมที่ใช้ในการประมวลผล ของตัวโปรแกรม GNSS Solutions

นั่นหมายความว่า...สู้อุตส่าห์ 'ทุบหมูออมสิน' ลงทุนซื้อหาจานรับสัญญาณดาวเทียมระบบ Multi-GNSS ราคาหลายอัฐ โดยมีความคาดหวังเอาไว้ว่า ข้อมูลการสำรวจฯดาวเทียมที่ได้รับจากทั้ง 4 ระบบหลักนั้น จะช่วยให้ข้อมูลการสำรวจฯมีความถูกต้อง แม่นยำ มากกว่าข้อมูลที่ได้รับจากระบบดาวเทียมเพียง 2 ระบบเดิม...แต่กลับกลายเป็นว่า มา 'ตกม้าตาย' เมื่อเลือกใช้โปรแกรมฯ GNSS Solutions ทำการประมวลผลข้อมูล

แล้วจะซื้อตัวจานรับสัญญาณดาวเทียมระบบ Multi-GNSS ราคาแพง มาเพื่ออิหยัง? ในเมื่อนำมาประมวลผลด้วยโปรแกรม GNSS Solutions แล้ว ให้ผลลัพธิ์การคำนวณ ความถูกต้อง เหมือนกับจานรับสัญญาณฯในระบบ GNSS รุ่นบุกเบิกเพียง 2 ระบบหลัก...ท่านสาธุชน โปรดนำไปคิดกันต่อ

ยัง...ยังไม่จบเพียงเท่านี้

ไม่เพียงแต่ปัญหาในเรื่องที่ตัวโปรแกรม GNSS Solutions ไม่รองรับข้อมูลดาวเทียมในระบบ Galileo และ Beidou เท่านั้น...แต่ยังมีปัญหาต่อไปอีก นั่นคือปัญหาในการกำหนดค่า Parameter ให้กับจานรับสัญญาณประเภท Multi-GNSS อาทิ จานรับสัญญาณฯ CHC รุ่น i80 ซึ่งตัวโปรแกรมฯ GNSS Solutions ไม่มีฐานข้อมูล 'คุณลักษณะ' ของตัวจานรับสัญญาณฯ (Antenna) ฉะนั้นเหล่าสาวก GNSS Solutions จึงจำเป็นที่จะต้องขวนขวาย หาข้อมูล ค่า Config. ต่างๆของตัวจานรับสัญญาณฯ เพื่อนำมา 'เติมลงในช่องว่าง' ให้ถูกต้อง ดังต่อไปนี้...ซึ่งผู้เขียนได้ลองทดสอบดูแล้ว ผลปรากฎว่า 'เหลว' 

จงเติม 'ค่า' ลงในช่องว่างให้ถูกต้อง (แทนที่เลข 0)

* ผู้เขียนได้ทำการทดลองกำหนด (+ค้นหาใน Google) ค่าต่างๆลงไปในช่องว่างข้างต้น โดยใช้จานรับสัญญาณฯ CHC x91+S เป็นตัวอย่างในการทดสอบ และทำการประมวลผลด้วยโปรแกรมฯ GNSS Solutions ซึ่งผลปรากฎว่า ค่าพิกัด และค่าระดับของตัว Rover ซึ่งมีระยะห่างจากตัว Base Station ประมาณ 100 ม. ที่คำนวณได้นั้น ต่างกับค่า Known Point ที่ผู้เขียนมีอยู่เดิม เพียง 3-4 มม. ซึ่งไม่มีนัยยะใดๆ...แต่เมื่อผู้เขียนได้ทำการ เพิ่มระยะทางให้กับตำแหน่ง Rover ให้ห่างจากตัว Base Station เป็น 3.5 กม. ผลปรากฎว่า ทางด้านค่าพิกัด E/N นั้น ยังไม่มีความแตกต่างอย่างมีนัยยะ...แต่...ทางด้านค่าระดับ (Elevation) 'เกิดความแตกต่าง' ถึง 95 มม. (9.5 ซม.)

ความแตกต่างทางด้านค่าระดับเกือบๆ 10 ซม. ในระยะทางเพียง 3.5 กม. ข้างต้นนี้ 'มีนัยยะที่สำคัญ' ที่ผู้เขียนเชื่อว่า อาจจะเกิดจากการกำหนดค่า 'ความสูง หรือค่าองศา' ต่างๆ เพื่อคำนวณหาค่า Phase Center ที่แท้จริง? ให้กับตัวจานรับสัญญาณฯ...โดยผู้เขียนได้พยายามเปลี่ยนตัวแปรในการทดลอง อาทิ การใช้การกำหนดค่าจานฯ เปรียบเทียบกับการที่ไม่ต้องไปกำหนดค่าใดๆ (ปล่อยให้เป็น 0, ตัวโปรแกรมฯไม่รู้จัก) แต่ผลการคำนวณที่ได้รับนั้น ก็ยังคงมีความแตกต่าง คลาดเคลื่อนทางงานระดับ อย่างมีนัยยะ

ในทรรศนะของผู้เขียน: โปรแกรมฯ GNSS Solutions 'มีความเหมาะสม' ที่จะใช้ในการประมวลผลข้อมูลดาวเทียม ที่ได้จากจานรับสัญญาณฯ GNSS ที่รองรับข้อมูลดาวเทียมในระบบหลัก อย่าง GPS และ GLONASS 'เท่านั้น' ส่วนในกรณีที่ทางหน่วยงาน บริษัท ห้างร้านใดๆ ที่มีจานรับสัญญาณฯประเภท Multi-GNSS ผู้ใช้งานควรที่จะสรรหาตัวโปรแกรมฯของยี่ห้อนั้นๆ มาใช้ในการประมวลผลข้อมูล และในกรณีที่ต้องการประมวลผลข้อมูลดาวเทียมฯร่วมกับข้อมูลจากจานรับสัญญาณฯ GNSS รุ่นบุกเบิก ผู้ใช้งานควรที่จะนำเอาข้อมูลดาวเทียมจากจานรับสัญญาณฯ GNSS รุ่นบุกเบิกดังกล่าว มาทำการแปลงเป็นไฟล์ RINEX เพื่อนำเข้าสู่ตัวโปรแกรมฯที่สามารถรองรับข้อมูลดาวเทียมจากหลายระบบ แล้วทำการประมวลผลร่วมกัน ซึ่งจะได้ผลการคำนวณที่มีความถูกต้อง แม่นยำมากกว่า...ไหนๆก็เสียเงิน เสียทอง ลงทุนซื้อหาจานรับสัญญาณฯราคามิใช่น้อยๆ มาใช้งานกันแล้ว ก็ควรที่จะจัดหาตัวโปรแกรมประมวลผลฯที่มีความเหมาะสมมาใช้งานคู่กันด้วย ซึ่งมีคำโบราณท่านกล่าวไว้ว่า 'ฆ่าควาย อย่าเสียดายพริก'

Photo Credited: Blogdit

บทส่งท้าย...
>> สำหรับเหล่าสาวก ค่าย Spectra ที่ยังคงมีความเชื่อมั่น ถือมั่น ในโปรแกรมฯ GNSS Solutions รุ่นเดอะ ข้างต้นนั้น...ผู้เขียนขออนุญาติแจ้งให้ทราบว่า ทางค่าย Spectra ได้ออกโปรแกรมประมวลผลข้อมูลดาวเทียม ที่สามารถรองรับข้อมูลระบบดาวเทียมหลัก 'ทุกระบบ' ณ พ.ศ. นี้ ภายใต้ชื่อทางการค้าว่า (SPECTRA) Survey Office ซึ่ง ณ พ.ศ. นี้ ได้ถูกพัฒนาไปถึงเวอร์ชั่น 5.2 กันแล้ว

โปรแกรมฯ Survey Office (มีออปชั่นให้เลือกหลาย Module ตามประเภทการใช้งาน)

ผู้เขียนได้ทำการทดสอบ และใช้งานแล้ว ผลปรากฎว่า...'ชั้นเยี่ยม' แต่ผู้ใช้งานจะต้องทำความเข้าใจกับค่า Setting อยู่พอสมควร และเป็นโปรแกรมฯที่ผู้เขียนมองว่า มีความเหมาะสมในการ ใช้วิเคราะห์ข้อมูลดาวเทียมที่ไปทำการสำรวจรังวัดมา แบบลงลึกในรายละเอียด (ถึงรากหญ้า) โดยเฉพาะการมีชุดคำสั่งล้ำๆ อย่างการ Plot เส้น Baseline ลงในตัวโปรแกรม Google Earth แบบอัติโนมัติ

ภาพตัวอย่าง แนวเส้น Vector ถูก plot ลงในโปรแกรม Google Earth (มีโลโก้ Spectra ทางมุมซ้ายบน)

และการมีชุดคำสั่ง Session Editor ที่ช่วยให้ผู้ใช้งานสามารถเข้าไประงับ หรือยกเลิกการประมวลผลข้อมูลดาวเทียม 'ณ ช่วงเวลา' ที่เกิดสภาวะการณ์ Cycle Slip (ข้อมูลขาดๆหายๆ เป็นช่วงๆ ขาดความต่อเนื่อง) และยังสามารถสั่งให้ระงับ (Cancel) ดาวเทียม 'บางดวง' (หรือหลายๆดวง ในกรณีที่เกิดรวมหัวกันเอ๋ๆ เอ๋อๆ) ที่ให้ข้อมูลแบบ 'ขาดตกบกพร่อง' อันเนื่องมาจากปัจจัยต่างๆ อาทิ การรบกวนจากสภาพแวดล้อม การบดบัง การสะท้อนของสัญญาณ, Multipath ฯลฯ

ภาพตัวอย่าง การเกิดสภาวะการณ์ Cycle Slip

ภาพแสดง การติ๊กเลือก/ไม่เลือก ดาวเทียมที่ไม่ต้องการ

* ตัวโปรแกรมฯ (CHC) CGO v. 2.x มีชุดคำสั่งในการจัดการกับข้อมูล Cycle Slip คล้ายๆกันนี้

ภาพแสดง การสั่ง 'ระงับ' ข้อมูลดาวเทียมในช่วงขาดๆ หายๆ ไม่ต่อเนื่อง

ภาพแสดงการ 'ติ๊กไม่เลือก' (ยกเลิก) ดาวเทียมหมายเลข G16 ในระบบ GPS

(ข้อมูลขาดๆ หายๆ อันเนื่องมาจากปัจจัยแวดล้อมต่างๆ)

ข้อกังขา...ที่อดสงสัยเสียมิได้

>> ผู้เขียน ได้เคยเป็นผู้ใช้งานตัวโปรแกรมฯ GNSS Solutions อยู่นานหลายปี จึงสามารถจดจำรูปร่าง ลักษณะหน้าตา (Interface) ของตัวโปรแกรมฯได้เป็นอย่างดี โดยเฉพาะในแถบ Panel ทางด้านซ้าย ของตัวโปรแกรมฯ ที่แสดงลำดับขั้นตอน ในการประมวลผลข้อมูลดาวเทียม

ภาพแสดงแถบ Panel ทางซ้าย ที่แสดงลำดับการประมวลผลฯ ในโปรแกรมฯ GNSS Solutions

แต่...เมื่อได้มาพบเจอตัวโปรแกรมประมวลผลข้อมูลดาวเทียม จากค่ายอื่นๆ ที่แสดงรูปร่างหน้าตา และลำดับการประมวลผลข้อมูลฯ ของตัวโปรแกรมฯ 'คล้ายๆกัน' กับตัวโปรแกรมฯ GNSS Solutions ข้างต้น จึงทำให้ผู้เขียนอดคิดไม่ได้ว่า เป็นไปได้หรือไม่? ที่ทางค่าย SPECTRA 'อาจจะ' เป็นผู้พัฒนาตัวโปรแกรมประมวลผลข้อมูลดาวเทียม ให้กับทางค่ายต่างๆเหล่านี้ (ชื่อตัวโปรแกรมฯ พ้องเสียง กันเสียด้วย)

TGO (Trimble Geomatics Office)

Photo Credited: Docburan

LGO (Leica Geo Office)

>> เป็นโปรแกรมประมวลผลฯ ที่ผู้เขียน (ส่วนตัว) ให้คะแนน 7 เต็ม 10 ไม่หัก โดยเปรียบเทียบกับโปรแกรมฯจากค่ายอื่นๆ ใน Class เดียวกัน...ทาง Leica น่าจะพัฒนาให้ดีกว่านี้

LGO มีชุดคำสั่ง ระงับการประมวลผลข้อมูลดาวเทียม ณ ช่วงเวลาต่างๆ เช่นเดียวกัน...แต่ผู้เขียนได้ทำการทดสอบแล้ว (Version 8.x) ผลปรากฎว่า 'ยังไม่โดน'

ภาพแสดง ตำแหน่งการยกเลิก/ระงับ การประมวลผลฯบางช่วงเวลา

จากระบบดาวเทียม Beidou หมายเลข C09

ในยุคปัจจุบัน Leica ได้ออกตัวโปรแกรมประมวลผลข้อมูลดาวเทียมรุ่นใหม่ ในชื่อทางการค้าว่า Leica Infinity ซึ่งผู้เขียนได้ทำการทดสอบใช้งานแล้ว (ส่วนตัว) มองว่ายัง 'ไม่ถึงเครื่อง' โดยเฉพาะในชุดคำสั่งที่เกี่ยวข้องการยกเลิก/ระงับ การประมวลผลฯบางช่วงเวลา

โปรแกรมฯ Leica Infinity (คำสั่งการวิเคราะห็ข้อมูลดาวเทียม)

CGO (CHC Geomatics Office) version 1.x

โปรแกรม CGO Office v.1.x ไม่รองรับข้อมูลดาวเทียมระบบ Galileo

HGO (Hi-Target Geomatics Office)

TGO (Tersus Geomatics Office)

>> เวอร์ชั่นที่ผู้เขียนใช้ในการทดสอบ คือ v.1.1 (Update ปี 2017) ซึ่งผู้เขียน (ส่วนตัว) เห็นว่าหน้าตา Interface ต่างๆ ในเวอร์ชั่นนี้ มีความละม้ายคล้ายคลึงกับตัวโปรแกรม CGO v.1.x ข้างต้น และที่สำคัญ ในเวอร์ชั่นนี้ ทั้ง CGO และ TGO ยังไม่รองรับข้อมูลดาวเทียมจากระบบ Galileo หรือระบบใหม่ๆ ในยุคปัจจุบัน (CGO v.1.x กระโดดไป v2.x แล้ว)

Photo Credited: tersusgnss

GGO (G Geomatics Office) ค่าย GINTEC

* ท่านใดมีความสนใจที่จะเรียนรู้การใช้งานโปรแกรมฯทางด้านล่างเหล่านี้ ในส่วนของการประมวลผลข้อมูลดาวเทียม ติดต่อหลังไมค์ได้ครับ ยินดีถ่ายทอดความรู้ให้โดยไม่มีค่าใช้จ่ายใดๆทั้งสิ้น 

1. SPECTRA Survey Office
2. Trimble Business Center 
3. Topcon Magnet Office
4. Leica Infinity
5. CGO Geomatics Office v.1.x และ v.2.x
6. Tersus Geomatics v.1.x
7. Stonex Cube Manger v.4.x

แผนที่เส้นทางภายในถ้ำหลวง ขุนน้ำนางนอน ในระบบ 3 มิติ (Tham Luang Physical 3D Scanning Cave Database)

บทความอ้างอิง: งานสำรวจฯข้อมูลสภาพทางกายภาพของถ้ำ (Physical of Cave Surveying Database)

>> หลังจากปรากฏการณ์ 'การกู้ภัยระดับโลก' ที่ถ้ำหลวงฯ ผ่านพ้นไปแล้ว ผู้เขียนได้พยายามเฝ้าสดับรับฟัง ติดตามความเคลื่อนไหว สอบถามข่าวคราวจากเหล่ามิตรสหายในสายงานกรมอุทยานฯ และในวงการสำรวจฯชาวเรา ถึงความคืบหน้าในการดำเนินการสำรวจฯ และจัดทำ 'แผนที่ถ้ำหลวง' ในแบบ Full Scale ตามมาตรฐานงานสำรวจฯ ซึ่งเป็นสิ่งจำเป็น 'ที่จำเป็นต้องมี' นับจากนี้ต่อไป...ด้วยเหตุว่าในช่วงของวิกฤตการณ์ถ้ำหลวงฯที่กำลังเกิดขึ้นนั้น 'ตัวแผนที่ภายในถ้ำฯ' ที่ถูกสำรวจฯเอาไว้แบบคร่าวๆ (จากวิธีการสำรวจฯที่ผู้เขียนได้อธิบายไว้ในบทความอ้างอิง ข้างต้น) ไม่สามารถใช้อธิบายความสัมพันธ์ของลักษณะทางภูมิศาสตร์ รวมไปถึงความสูง-ต่ำทางค่าระดับภายในถ้ำได้อย่างถูกต้องแม่นยำ ตามมาตรฐานงานสำรวจฯแผนที่

แผนที่ถ้ำหลวงฯ ที่ถูกใช้อ้างอิงในการดำเนินการกู้ภัยฯ

Credited: www.khaosodenglish.com

ซึ่ง 'ความขาดแคลน' ดังกล่าวได้ส่งผลกระทบ หรือเป็นอุปสรรคในการดำเนินงาน การวางแผนบริหาร-จัดการสำหรับภารกิจช่วยเหลือกู้ภัยที่เกี่ยวข้องอื่นๆ ณ ช่วงเวลานั้น อาทิ การเจาะผนังถ้ำเพื่อระบายน้ำ-สูบน้ำ ต้องเจาะไปที่ตำแหน่งใด มีการตั้ง 'ค่ามุมองศา' ของหัวเจาะขึ้น-ลงเท่าไหร่ อย่างไร และรวมไปถึงระยะทางในการขุดเจาะ ซึ่งแปรผันโดยตรงกับระยะเวลา (สำคัญ) ที่ต้องใช้ในการขุดเจาะ ฯลฯ

ฉะนั้นชาวเราจึงเห็นความพยายามของสื่อ หรือหน่วยงานต่างๆ ฯลฯ ในการสรรหา และจัดทำแผนที่ Graphic ในหลากหลายเวอร์ชั่น มาช่วยอธิบายลักษณะภูมิสัณฐานต่างๆภายในถ้ำฯ ซึ่งแม้ว่าจะขาดแคลนความถูกต้องในเชิงภูมิศาสตร์ แต่ ณ เวลาที่วิกฤติเช่นนั้น ต้องถือว่า 'ดีกว่าไม่มีอะไรเลย'

ตัวอย่างแผนที่กราฟฟิค แสดงเส้นทางและระดับความสูงต่ำ (คร่าวๆ) ภายในถ้ำหลวงฯ

Credited: www.learningstudio.info

Credited: www.asiaone.com

Credited: Newish

ภายหลังจากที่ระดับน้ำภายในถ้ำฯได้ลดระดับลงจนแห้ง และกลับคืนเข้าสู่ภาวะปรกติ ภารกิจการเก็บกู้อุปกรณ์ที่ถูกใช้ในการกู้ภัยได้เริ่มขึ้น และสิ้นสุดลงไป...พร้อมๆกับความ 'เงียบหาย' ไร้การพูดถึงจากเจ้าภาพ? สำหรับประเด็นเรื่องการสำรวจฯและจัดทำแผนที่ถ้ำหลวงฯ...จบแล้ว ก็จบกันไป

ภาพถ่ายการเก็บกู้อุปกรณ์ต่างๆภายในถ้ำฯภายหลังระดับน้ำลดลงจนแห้งเป็นปรกติ

Credited: www.thethaiger.com

เสียงลือ เสียงเล่าอ้างในวงการสำรวจฯชาวเขา และชาวเรา ใน Social Media ได้มีการกล่าวถึง 'ทุนในการสำรวจฯถ้ำหลวง' จากต่างชาติ โดยอ้างถึงการทำการสำรวจฯและจัดทำแผนที่ตัวถ้ำฯให้โดยไม่คิดค่าใช้จ่าย (ฟรี?)...เสียงล่ำลือเหล่านั้น ถูกแพร่สะพัดไปในชั่วระยะเวลาสั้นๆ และก็เงียบหายไปกับสายลม และแสงแดด...

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

ในช่วงต้นปีที่ผ่านมา...'ความอึมครึม' ดังกล่าว(ส่วนหนึ่ง) ได้ถูกเปิดเผยขึ้น ถึงสิ่งที่ผู้เขียน (เสียงเล็กๆ) ได้พยายามเขียนกระตุ้นเตือนสู่สาธารณะชนถึงการถอดบทเรียน 'จากความขาดแคลน' แผนที่ถ้ำฯ (มาตรฐานงานสำรวจฯ) ผ่านทาง Blog และในโลกออนไลน์ นับตั้งแต่ช่วงเกิดวิกฤตการณ์ฯ นั่นคือ การสำรวจฯและจัดทำแผนที่ถ้ำหลวง แบบมาตรฐาน...ซึ่งมันได้เกิดขึ้น และสัมฤทธิ์ผลลงแล้ว โดยชุดข้อมูลตัวถ้ำฯดังกล่าว จะได้กลายมาเป็น Map Database หรือแผนที่แม่บทที่สำคัญ เพื่อใช้ในการอ้างอิงทางด้านภูมิศาสตร์ (ที่มีความละเอียดถูกต้อง แม่นยำสูง) ของตัวถ้ำฯ ต่อไปในอนาคต...

ข้อมูล Point Cloud (ส่วนหนึ่ง) แสดงลักษณะสัณฐานทางภูมิศาสตร์ของถ้ำหลวงฯ ในระบบ 3 มิติ

Credited: National Geographic (ทีมสำรวจฯ)

and This Link!

ภาพถ่าย ทีมงาน Scanning ณ ตำแหน่งที่สูงที่สุด (ทางระดับ) ที่ค้นพบทีมหมูป่า

Credited: www.forbes.com (คลิกที่ภาพ เพื่อขยาย)

จากภาพถ่ายข้างต้น แสดงเครื่องมือ 'ตาเทพ' 3D Terrestrial Scanner ที่ถูกนำมาใช้

ยี่ห้อ RIEGL ซีรี่ VZ-400/VZ-1000 

Credited: RIEGL

>> มีประเด็นที่น่าสนใจ จากการที่ทีมงานฯ National Geographic ได้เลือกใช้อุปกรณ์สำรวจฯ RIEGL ซีรี่ VZ-400/VZ-1000 ข้างต้น ซึ่งผู้เขียนได้เคยกล่าวไว้ในบทความอ้างอิง ในประเด็นเรื่อง 'น้ำหนัก' ของตัวอุปกรณ์สำรวจฯ ซึ่งนั่นหมายถึงอุปสรรค และความยากลำบากในการเคลื่อนย้ายนำพาตัวอุปกรณ์  ภายในพื้นที่ๆมีลักษณะการเข้าถึงที่ยากลำบาก และมีขนาดพื้นที่ๆจำกัด

Credited: www.wsj.com

อีกทั้งการเลือกใช้อุปกรณ์สำรวจฯที่ต้องติดตั้งอยู่บน 3 ขา (Tripod) ซึ่งนั่นหมายถึง การเพิ่มน้ำหนักสัมภาระในการเคลื่อนย้าย และการเลือกใช้อุปกรณ์สำรวจฯดังกล่าว ในการทำการสำรวจฯ จะทำให้เกิดตำแหน่ง Blind Spot ที่จุดตั้งอุปกรณ์ในทุกๆตำแหน่ง ซึ่งในประเด็นนี้...มิใช่สาระสำคัญอะไรนักในสายงานสำรวจฯแผนที่ถ้ำ

ภาพแสดง ตำแหน่งจุด Blind Spot ทุกๆตำแหน่งจุดตั้งอุปกรณ์

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

ณ วันนี้ ตัวแผนที่ ที่แสดงลักษณะทางภูมิศาสตร์ของพื้นที่ภายนอกตัวถ้ำฯ ที่ได้จากกระบวนการสำรวจฯจากทางอากาศ มีความถูกต้องแม่นยำสูง และเมื่อนำมาบูรณาการ ผนวกเข้ากับตัวแผนที่ๆแสดงเส้นทางภายในถ้ำฯ ความละเอียดสูง...คำถามที่ว่า 'เจาะแล้วจะเจอหรือไม่?' จะถูกตอบกลับไปได้อย่าง ชิวๆ

Credited: ArcGIS

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

จะเป็นการดีสักเพียงใด ถ้าทุกๆถ้ำที่สำคัญในสารขัณธ์ประเทศชาวเรา 

มีข้อมูลถ้ำในระบบ 3 มิติ เฉกเช่นที่เกิดขึ้นที่ ณ ถ้ำหลวง ขุนน้ำนางนอน

Special Thanks

เมื่อยามนั้นมาถึง...ตัวตน ชนชาวเราจะเป็นเช่นนั้น เสมอ

Credited: TODAYonline