เมื่อไลบรารี PROJ. จะคำนวณ Geoid Separation (N) ผ่านจีออยด์โมเดลในคลาวด์

โครงการ PROJ. ถ้าใช้ในไพทอนจะเรียกว่า PyProj ผมนำมาใช้เป็นไลบรารีหลักใน Surveyor Pocket Tools ถ้าผู้อ่านเคยดาวน์โหลดไปใช้งานจะพบว่าโปรแกรมมีขนาดใหญ่มาก ที่ขนาดใหญ่เพราะว่าต้องขนไฟล์จีออยด์เช่น EGM96, EGM2008 และ TGM2017 ไปใช้งาน เมื่อติดตั้งเสร็จจะพบว่าขนาดโดยรวมมีขนาด 1.1 GB ผมไม่แฮปปี้ตั้งแต่แรกเพราะถ้าอินเทอร์เน็ตไม่ดีการดาวน์โหลดโปรแกรมก็ต้องใช้เวลามาก แถมยังเสียพื้นที่ฮาร์ดดิสค์ในการติดตั้งมากอีกต่างหาก

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

รูปแบบไฟล์จีออยด์โมเดลสำหรับคลาวด์

ก่อนหน้านี้โครงการ PROJ. จะมีกริดไฟล์ที่ช่วยในการแปลงค่าพิกัดทางราบ (horizontal shift) ในรูปแบบเรียกว่า NTv2 และแปลงค่าระดับในทางดิ่ง (vertical shift) ในรูปแบบ GTX ทั้งสองรูปแบบมีจุดอ่อนที่ในไฟล์ไม่ได้เก็บ Metadata มากนักและไม่ได้ปรับให้ใช้สำหรับงานคลาวด์ที่มีประสิทธิผล

ทางโครงการจึงมองหามาตรฐานใหม่มาแทนที่ ณ ตอนนี้ยังไม่ได้ตัดสินใจมีแนวโน้มที่จะใช้ GeoTiff และทางโครงการเอาไฟล์จีออยด์โมเดลไปไว้ในคลาวด์ที่เรียกว่า Content Delivery Networks (CDN) โดยในเบื้องต้นใช้บริการของ Amazon Public Datasets

ลิขสิทธ์ของไฟล์จีออยด์โมเดล

สำหรับลิขสิทธิ์ไฟล์จีออยด์โมเดลมีหลายรูปแบบ ซึ่งเจ้าของไฟล์ต่างๆเหล่านี้ของแต่ละประเทศต้องระบุลิขสิทธิ์ลงไปดังนี้

  • Public domain
  • X/MIT
  • BSD 2/3/4 clause
  • CC0
  • CC-BY (v3.0 or later)
  • CC-BY-SA (v3.0 or later)

ทางโครงการจึงสามารถนำไปเผยแพร่และนำไปโฮสต์ไว้ในคลาวด์ สำหรับให้สาธารณชนมาเรียกใช้ได้ภายหลัง

การลงทะเบียน EPSG

และสิ่งที่ขาดไม่ได้คือจีออยด์โมเดลแต่ละอย่างนัั้นจะมีการนำไปลงทะเบียน European Petroleum Survey Group (EPSG) ตัวอย่างเช่นจีออยด์ EGM96 ใช้หมายเลข 5171 (EPSG:5171) และ EGM2008 ใช้หมายเลข 1027 (EPSG:1027)

การกำหนดหมายเลข EPSG ให้แต่ละจีออยด์โมเดลนั้นเพื่อความสะดวกสำหรับไลบรารี PROJ. ในการเรียกใช้ เพราะหมายเลข ชื่อไฟล์ ชื่อจีออยด์โมเดล จะถูกเก็บใน database “proj.db” ของไลบรารี

ข้อดีและข้อด้อยของไฟล์รูปแบบ GeoTiff

ข้อดีของไฟล์รูปแบบ GeoTiff ที่จะนำมาใช้เป็นจีออยด์โมเดลในคลาวด์ มีข้อดีคือ

  • รูปแบบ Tiff เป็นที่รู้จักกันดี ใช้กันอย่างแพร่หลาย ที่ใช้กันทั่วๆไปจะเป็นไฟล์เก็บรูปภาพ
  • รูปแบบ Tiff มี tag ที่สามารถใส่ได้อย่างไม่มีข้อจำกัด ในขณะที่รูปแบบภาพอื่นๆจะใส่ header ได้ในขนาดจำกัด เช่น ขนาดภาพ สี ในส่วนเฟรมเวิร์คของ tag ของ Tiff เรียกว่า Image File Directory (IFD)
  • การเข้ารหัสไฟล์ GeoTiff รูปภาพเพื่ออ้างอิงตำแหน่งค่าพิกัดโลกเป็นมาตรฐานของ OGC
  • สามารถจัดเก็บไฟล์ที่สามารถแยกเป็นหลายหน้า (Multi-Pages) ในลักษณะโครงสร้างปิรามิด
  • สามารถเข้าถึงผ่านเน็ตเวิร์คสามารถดึงไฟล์บางส่วนออกมาได้ในลักษณะตารางสี่เหลี่ยม
  • สามารถตัดเป็นตารางย่อยๆได้ (Tile)
  • บีบอัดได้เพื่อให้ไฟล์มีขนาดเล็กผ่านไลบรารี DEFLATE หรือ LZW
  • สามารถใส่ตัวเลขแสดง Bands (Channels) ได้
  • โหมดสี (RGB) สามารถจับเก็บในไฟล์เดียวกันหรือแยกกันได้ผ่านทางตัวแปร PlanarConfiguration ใน header ของไฟล์
  • ไลบรารี libtiff มีอยู่ในไฟล์ไบนารีของ PROJ. อยู่แล้ว
  • ความปลอดภัยของไฟล์ Tiff เนื่องจากได้ถูกพัฒนามาอย่างยาวนาน

ข้อด้อย

  • ขนาดสูงสุดไม่เกิน 4 GB เนื่องจากการกำหนด tag ในไฟล์จะอ้างอิงตำแหน่ง offset ใช้ตัวเลข 32 บิต ดังนั้นอ้างอิงได้สูงสุด 232 จึงไม่เกิน 4 GB (ปัจจุบันมีการกำหนด BigTiff ที่สามารถสร้างไฟล์ขนาดใหญ่กว่า 4 GB ได้)

ทดสอบแปลงไฟล์ TGM2017 รูปแบบ GTX เป็นรูปแบบ GeoTiff

ผมจะลองทดสอบการแปลงไฟล์ TGM2017.GTX ที่ผมได้จัดทำรูปแบบไฟล์นี้ไว้เพื่อใช้ใน Surveyor Pocket Tools เพื่อแปลงมาอยู่ในรูป GeoTiff โดยอาศัยโค้ดไพทอนที่อยู่ใน github แต่เครื่องคอมพิวเตอร์ต้องติดตั้งไลบรารี gdal ไว้ก่อน สำหรับใช้งานกับไพทอนแล้วติดตั้งผ่านไฟล์ wheel สะดวกที่สุด เพื่อจะได้ไลบรารีที่เป็นไฟล์ไบนารีมาด้วยดาวน์โหลดได้ตาม gdal-wheels นี้

โค้ดที่นำมาทดสอบคือไฟล์ vertoffset_grid_to_gtiff.py และจะมีการเรียกใช้ไฟล์ cloud_optimize_gtiff.py จากภายในด้วย ผมสร้างโฟลเดอร์ก๊อปปี้ไฟล์สคริปต์ไพทอนสองไฟล์นี้ และก๊อปปี้ไฟล์ tgm2017.gtx รันสคริปต์ด้วยคำสั่งต่อไปนี้ ผมใช้วินโดส์ ถ้าใช้ลีนุกซ์หรือแมคต้องเปลี่ยนเครื่องหมาย ^ เป็น \

python3 vertoffset_grid_to_gtiff.py ^
--type GEOGRAPHIC_TO_VERTICAL ^
--area-of-use "Thailand" ^
--source-crs EPSG:4326 ^
--target-crs EPSG:5773 ^
--copyright "URL https://civil.eng.cmu.ac.th/people/puttipol-dumrongchai" ^
tgm2017.gtx th_rtsd_tgm2017.tif

จะสังเกตุว่า –target-crs ของจีออยด์ TGM2017 ไม่ได้ลงทะเบียน EPSG ไว้ ผมจึงใส่ EPSG:5773 เข้าไปดื้อๆ

รันสคริปต์ไพทอน

จะแสดงผลลัพธ์การแปลงไฟล์ดังนี้

จะได้ผลลัพธ์คือไฟล์ th_rtsd_tgm2017.tif ขนาด 1.9 MB ทดสอบเปิดไฟล์ด้วย QGIS แล้วซ้อนด้วยแผนที่ขอบเขตประเทศไทย

ไฟล์จีออยด์โมเดล TGM2017 ในรูปแบบ GeoTiff แสดงผลบน QGIS

สำรวจแท็กของไฟล์ Tiff ด้วย Hex Editor

ไฟล์ของ Tiff จะมีหัวไฟล์ (header) อยู่สี่ไบต์ โดยที่สองไบต์แรก ไบต์ 0-1 จะระบุว่าเป็นการเข้ารหัสไฟล์แบบ little endian หรือ big endian เราจะมาอ่านตรงนี้ก่อน ถ้าอ่านได้ 0x4949 (อักขระคือ “II”) จะเป็น little endian ก็ใช้อยู่ในเครื่องคอมพิวเตอร์ตระกูล x86 ทั่วๆไป ถ้าอ่านได้ 0x4D4D (อักขระคือ “MM”) จะเป็น big endian

ความต่างของ big endian และ little endian จะอยู่ที่การเก็บลำดับของไบต์ สำหรับ little endian จะเก็บไบต์ต่ำก่อนแล้วค่อยเก็บไบต์สูงในลำดับถัดไป ตัวอย่างเช่น 0x124B เก็บ 4B -> 12 แต่ big endian จะตรงข้ามเก็บไบต์สูงก่อนแล้วค่อยจัดเก็บไบต์ต่ำ ตัวอย่างเช่น 0x124B เก็บ 12 -> 4B

ผมใช้โปรแกรมฟรี Hxd เปิดไฟล์ th_rtsd_tgm2017.tif ตรวจดูไบต์ที่ 0-1 จะเห็นเลขฐาน 16 0x4949 แสดงว่าไฟล์ถูกจัดเก็บแบบ little endian ดูไบต์ที่ 2-3 อ่านได้ 0x002A คือเลข 42 ในฐานสิบซึ่งตรงกับข้อกำหนดต้องอ่านได้เท่ากับ 42 เท่านั้น

อ่านไบต์ที่ 4-5 จะได้เลข 0x0056 ตัวนี้สำคัญมากเรียกว่า IFD ตามที่ผมกล่าวมาแล้วคือเป็นตัวชี้ไปเริ่มตำแหน่งแท็ก เมื่อไปที่ตำแหน่งที่ 0x0056 อ่านไบต์มาสองไบต์จะได้ตัวเลข 0x0014 หรือเท่ากับ 20 ในตัวเลขฐานสิบ จำนวน 20 นี้คือจำนวนแท็ก ที่ถูกกำหนดในไฟล์นี้

อ่าน header ไฟล์ th_rtsd_tgm2017.tif ด้วย HxD

ต่อไปจะเริ่มแท็กของไฟล์ tiff เริ่มจากอ่านหมายเลขแท็กโค้ด 0x0100 (256) ซึ่งหมายเลขนี้กำหนดว่าเป็นความกว้างภาพ (ImageWidth) ถัดไปสองไบต์เป็นชนิดข้อมูลอ่านได้ 0x0003 เป็นชนิดข้อมูลแบบ SHORT อ่านต่อ 4 ไบต์คือค่า (value) ได้ 0x00000001 (1) คือจำนวน (count) ซึ่งหมายความว่าค่าที่จะอ่านต่อไปจะมีจำนวนเพียง 1 เท่านั้น อ่านค่า (value) ต่อ 4 ไบต์คือ 0x0000030C (780) เท่ากับความกว้างภาพ 780 พิกเซลในเลขฐานสิบ

ต่อไปอ่านแท็กโค้ด 0x0101 (257) คือความสูงภาพ (ImageLength) ชนิดข้อมูลและจำนวนเหมือนกับแท็กโค้ดก่อนหน้านี้ อ่านค่า (value)ได้ 0x000004B5 (1200) ได้ความสูงภาพ 1200 พิกเซล

ต่อไปจะดูแท็ก ImageDescription แท็กโค้ดที่ 0x10E (270) ชนิดข้อมูล 02 เป็นแอสกี้ ขนาดหรือจำนวน 105 ตัวอักษร อ่านค่าหรือ offset ได้ 0x0000014C (332) ดูตำแหน่งที่ offset จะเห็นอักขระคือ “WGS 84 (EPSG:4326) to EGM96 height (EPSG:5773). Converted from tgm2017.gtx (last modified at 2020/05/12)” ตามที่ผมแจ้งไว้เบื้องต้นเนื่องจาก TGM2017 ไม่ได้ลงทะเบียน EPSG ไว้ ผมหลอกๆด้วย EPSG:5773

แท็กของ GeoTiff

สำหรับแท็กที่เราดูไปแล้วข้างต้นเรียกว่า baseline tag สำหรับไฟล์ tiff ทั่วๆไป ต่อไปจะดูแท็กของ GeoTiff เป็นบางส่วน เริ่มต้นที่แท็กโค้ด 0x830E (33550) เป็นแท็ก ModelPixelScaleTag ซึ่งจะเป็นมาตราส่วนของขนาดพิกเซลในหน่วยของโมเดล ในที่นี้จะเป็นองศา (degree) ซึ่งจะประกอบไปด้วยมาตราส่วนแกน X แกน Y และแกน Z สามารถเขียนได้ดังนี้ ModelPixelScaleTag = (ScaleX, ScaleY, ScaleZ)

แท็กโค้ด 0x830E (33550) ชนิดข้อมูล 0x000C (12) เป็นข้อมูลชนิด double จำนวนข้อมูล 3 ตัว ตำแหน่ง offset 0x00000205 (517) ตามไปดูที่ตำแหน่ง 517 ตามลูกศรชี้ อ่านค่ามาได้ 0.01666666, 0.01666666, 0.0 ซึ่งตัวเลขนี้ก็คือความละเอียดเชิงพื้นที่ 1 ลิปดานั่นเอง

ต่อไปจะดูแท็กโค้ด 0x8482 (33922) เป็นแท็ก ModelTiepointTag หรือบางครั้งเรียกว่า GeoreferenceTag จะเป็นชุดตัวเลขสำหรับกำหนดการแปลงค่าพิกัด (transformation) จากจุดภาพพิกเซลเป็นค่าพิกัดโลก จุดที่กำหนดมีจำนวน N = 6*K, โดยที่ K = จำนวนจุด

ต่อไปอ่านแท็กโค้ด 0x8482 (33922) ชนิดข้อมูลเป็น 12 คือ double ขนาด 8 ไบต์ อ่านจำนวนได้ 6 แสดงว่ามีจุดเดียว อ่านค่าออฟเซ็ทได้ 541 ตามไปดูที่ตำแหน่ง 541 การเก็บข้อมูล ModelTiepointTag จะเก็บเรียงกันไป ในลักษณะ

ModelTiepointTag = (…,I,J,K, X,Y,Z…), โดยที่ (I,J,K) คือจุดพิกัดของพิกเซลและจุด (X,Y,Z) คือค่าพิกัดโลก อ่านค่ามาทีละ 8 ไบต์ จะได้ค่า I,J,K,X,Y,Z เรียงกันดังนี้ 0, 0, 0, 95, 22.9833333333, 0 แสดงว่าจุดภาพที่พิกัด 0, 0, 0 เมื่อแปลงค่าพิกัดโลกเป็นลองจิจูด 95 องศา ละติจูด 22.983333333 องศา ดูแผนผังด้านล่างจะเห็นว่าจุด 0, 0, 0 คือจุดบนซ้ายสุด

แผนผังขนาดของ TGM2017

ไฟล์รูปแบบ GeoTiff ไม่ใช่เรื่องใหม่ ผมเขียนบทความนี้เพื่อให้เห็นการแปลงไฟล์จากรูปแบบ NOAA GTX เป็น GeoTiff โดยใช้เครื่องมือโปรแกรมจาก github มาช่วย จากนั้นพาไปดูรูปแบบไฟล์ GeoTiff แบบลึกๆโดยใช้เครื่องมือ Hex Editor ตอนนี้ทางโครงการ PROJ. ยังไมได้ปล่อย API สำหรับเรียกใช้ผ่านคลาวด์ ซึ่งผมคิดว่าคงไม่นานจากนี้ โปรดติตตามบทความตอนต่อไปครับ

2 thoughts on “เมื่อไลบรารี PROJ. จะคำนวณ Geoid Separation (N) ผ่านจีออยด์โมเดลในคลาวด์”

  1. ตำนานยังคงเผ็นตำนานครับ สุดจริงๆ

Leave a Reply

Your email address will not be published.