EQUATOR GNSS / BY TECHNOGISเยอรมนี · อินโดนีเซีย
พิกัดและความสูง

ลำดับแกนพิกัดในข้อมูล GNSS: การป้องกันข้อผิดพลาดที่เป็นไปได้

สร้างอนุสัญญาพิกัดละติจูด-ละติจูด ละติจูด-ลองจิจูด และพิกัดตะวันออก-เหนือ-พิกัด อย่างชัดเจนในทุกขอบเขตการนำเข้า การเปลี่ยนแปลง และการแลกเปลี่ยน

ลำดับแกนพิกัดในข้อมูล GNSS: การป้องกันข้อผิดพลาดที่เป็นไปได้

รักษาลำดับแกนเป็นส่วนหนึ่งของข้อมูลอ้างอิง

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

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

เรียนรู้เพิ่มเติม พิกัด UTM: โซน ซีกโลก และข้อผิดพลาดส่งออกที่พบบ่อย

อ่านเอกสารต้นฉบับก่อนเดา

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

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

เรียนรู้เพิ่มเติม การตรวจสอบการนำเข้าพิกัด CSV จากการสำรวจ GNSS

แยกแยะแกน CRS ออกจากลำดับข้อมูล API

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

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

เรียนรู้เพิ่มเติม การจัดทำเอกสารพิกัดยุคในข้อมูลการสำรวจที่ดิน GNSS

เคารพกฎการแลกเปลี่ยนเฉพาะรูปแบบ

RFC 7946 ตำแหน่ง Geojson ใช้ลองจิจูดและละติจูด WGS84 เป็นองศาทศนิยม กฎดังกล่าวมีผลบังคับใช้แม้ว่าการสำรวจที่ดินต้นทางหรือการแสดงซอฟต์แวร์จะใช้ละติจูดก่อน ต้องเปลี่ยนพิกัดที่คาดการณ์ไว้ก่อนการส่งออกที่เป็นไปตามมาตรฐาน การแลกเปลี่ยนค่าเพียงอย่างเดียวไม่ได้แปลงพิกัดตะวันออกและพิกัดทางเหนือเป็นพิกัดทางภูมิศาสตร์

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

เรียนรู้เพิ่มเติม เวิร์กโฟลว์ QGIS สำหรับการตรวจสอบข้อมูลการสำรวจที่ดินของ GNSS

เครื่องรับ GNSS ติดตั้งบนขาตั้งสำรวจ
เครื่องรับ GNSS ติดตั้งบนขาตั้งสำรวจ · Rowan Johnson / USGS / Public Domain

การนำเข้าทดสอบด้วยจุดอ้างอิงที่ทราบ

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

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

เรียนรู้เพิ่มเติม พิกัด UTM: โซน ซีกโลก และข้อผิดพลาดส่งออกที่พบบ่อย

แยกขนาดแนวตั้งและเวลาออกจากกัน

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

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

เรียนรู้เพิ่มเติม การตรวจสอบการนำเข้าพิกัด CSV จากการสำรวจ GNSS

แก้ไขความไม่ตรงกันอย่างสม่ำเสมอ

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

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

เรียนรู้เพิ่มเติม การจัดทำเอกสารพิกัดยุคในข้อมูลการสำรวจที่ดิน GNSS

ส่งพิกัดด้วยอนุสัญญาที่ชัดเจน

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

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

เรียนรู้เพิ่มเติม เวิร์กโฟลว์ QGIS สำหรับการตรวจสอบข้อมูลการสำรวจที่ดินของ GNSS

ตรวจสอบแหล่งที่มาของ Latitude-First สำหรับแผนที่เว็บ

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

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

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

เรียนรู้เพิ่มเติม พิกัด UTM: โซน ซีกโลก และข้อผิดพลาดส่งออกที่พบบ่อย

รายการตรวจสอบเชิงปฏิบัติ

รายการตรวจสอบเชิงปฏิบัติ

  1. ลำดับแกนเอกสารทุกขอบเขตอินเทอร์เฟซ
  2. ทดสอบจุดที่ทราบและตรวจสอบค่าที่เก็บไว้และแสดง
  3. ใช้องศาละติจูด-ละติจูด geojson หลังจากการเปลี่ยนแปลงที่เหมาะสม
EQUATOR GNSS

วางแผนชุดอุปกรณ์ GNSS

เปรียบเทียบข้อมูลจำเพาะเครื่องรับ EQ10 และ EQ20 แล้วหารือเรื่องการตั้งค่าและการสนับสนุนที่โครงการของคุณต้องการ

เปรียบเทียบเครื่องรับ GNSS

เอกสารอ้างอิง

  1. PROJ Documentation — Geodetic Transformation
  2. PROJ Documentation — Axis Swap
  3. IETF — RFC 7946: The GeoJSON Format