เวลาต้องนำพิกัดจากไฟล์ภาพหรือข้อมูลเส้นทางไปแสดงบนแผนที่ เราอาจคิดว่างานหลักคืออ่านตัวเลขสองตัวแล้วส่งต่อ แต่พอเอาข้อมูลจากคนละเครื่องมือมารวมกัน หมุดกลับไปอยู่ผิดที่ ทั้งที่ตัวเลขดูครบและไม่มีข้อความผิดพลาดตอนแปลงไฟล์
ปัญหาแบบนี้เกิดได้จากลำดับของค่าและข้อตกลงที่ใช้ตีความ บางหน้าจอชอบแสดงละติจูดก่อนลองจิจูด ขณะที่รูปแบบข้อมูลบางชนิดกำหนดตรงข้าม การที่ทั้งคู่รับเป็นตัวเลขสองตัวจึงไม่ได้แปลว่าจะนำ array เดิมใส่แทนกันได้เลย
ก่อนแก้ด้วยการสลับค่าไปมา ควรเริ่มจากสัญญาของต้นทางกับปลายทางครับ เพื่อให้รู้ว่าค่าที่ส่งมีความหมายอะไรและกำลังแปลงจากรูปแบบใดไปหาอะไร
GeoJSON ตาม RFC7946 กำหนดตำแหน่งแบบลองจิจูดแล้วละติจูด โดยใช้พิกัดภูมิศาสตร์ WGS84 กับหน่วยองศาทศนิยม ส่วน geo URI ตาม RFC5870 ใช้ละติจูดก่อนลองจิจูด ทั้งสองจึงไม่ควรถูกอ่านด้วยกติกาของ array กลางที่ไม่ระบุชนิดข้อมูล
ตัวอย่างสมมติต่อไปนี้ใช้ค่าละติจูด13.7และลองจิจูด100.5 เพื่อแสดงวิธีเรียงเท่านั้น ไม่ใช่ตำแหน่งจากการติดตามบุคคลหรือภาพที่ถ่ายจริง
{
"type": "Point",
"coordinates": [100.5, 13.7]
}
ตำแหน่งเดียวกันเมื่อเขียนเป็น geo URI จะเรียงในรูปนี้
geo:13.7,100.5
หากมี API ของแผนที่อีกตัวอยู่ปลายทาง ก็ต้องตรวจเอกสารของ API นั้นต่อ ไม่ใช้ข้อเท็จจริงว่า GeoJSON เรียงแบบหนึ่งไปสรุปว่าทุก method ที่มีคำว่า coordinates จะเรียงเหมือนกันทั้งหมด
ภายในแอป การเก็บค่าเป็น field ที่ระบุ latitude กับ longitude ช่วยให้คนอ่านเห็นความหมายได้ชัดกว่าเลขลอยสองตัว จากนั้นค่อยแปลงเป็นรูปแบบที่ปลายทางต้องการตรงขอบเขตการส่งข้อมูล พร้อมมีจุดตรวจว่าลำดับถูกต้อง
วิธีนี้ยังต้องระวังขั้นรับข้อมูล เพราะชื่อ field ที่ชัดไม่ได้ทำให้ค่าที่ใส่มาถูกโดยอัตโนมัติ หากต้นทางใช้ x กับ y ต้องรู้ว่าหมายถึงแกนในระบบพิกัดใด ไม่จับ x เป็น longitude ทุกกรณีเพียงเพราะเจอบ่อยในงานแผนที่เว็บ
ชื่อระบบพิกัดก็ต้องอ่านคู่กับข้อกำหนดเรื่องแกนของรูปแบบและ library นั้นด้วย การเห็นคำว่า WGS84 หรือชื่อรหัสที่คุ้นเคยจึงยังไม่แทนการตรวจลำดับในสัญญา API และหากต้นทางเป็นพิกัดฉายที่ใช้หน่วยระยะทาง การสลับเลขอย่างเดียวก็ไม่ใช่การแปลงให้กลายเป็นองศา
การตรวจว่าละติจูดกับลองจิจูดอยู่ในช่วงที่รูปแบบรองรับช่วยจับข้อมูลผิดบางชนิดได้ เช่น ตัวอย่างข้างบนถ้าสลับ100.5มาเป็นละติจูดก็จะเกินช่วงของละติจูด แต่ในหลายพื้นที่ตัวเลขทั้งคู่ยังอาจอยู่ในช่วงที่รับได้แม้สลับกันแล้ว
จึงควรตรวจความสมเหตุสมผลตามขอบเขตของงานด้วย เช่น ชุดเส้นทางที่ตั้งใจอยู่ในพื้นที่หนึ่งกลับมีจุดกระโดดไปไกล แต่การตรวจเชิงบริบทควรใช้แจ้งความผิดปกติหรือปฏิเสธตามกติกาที่ตกลง ไม่ย้ายหมุดไปจุดที่คิดว่าน่าจะถูกโดยไม่มีหลักฐานจากต้นทาง
กรณีไม่มีพิกัดก็ต้องมีสถานะแยก ไม่เติมศูนย์ทั้งคู่เพื่อให้โครงข้อมูลครบ เพราะศูนย์เป็นค่าพิกัดที่มีความหมายได้จริงบนโลก การใช้ค่าที่ดูสะดวกแทนข้อมูลขาดจึงทำให้แผนที่อาจแสดงสถานที่ที่ไม่เคยได้รับการวัดมา
การแสดงตัวเลขละเอียดช่วยรักษาค่าที่มีในข้อมูล แต่จำนวนหลักไม่ได้บอกว่าตำแหน่งถูกวัดได้แน่นอนแค่ไหน RFC5870 ระบุชัดว่าไม่ให้ใช้จำนวนหลักของพิกัดเป็นตัวแทนระดับความไม่แน่นอน หากมีข้อมูล uncertainty ก็ควรเก็บตามความหมายและหน่วยที่ต้นทางให้มา
ใน geo URI มีพารามิเตอร์ u สำหรับความไม่แน่นอนเป็นเมตร และการไม่ระบุค่านี้ต่างจากการระบุศูนย์ ส่วนเมื่อแปลงไปอีกรูปแบบต้องตรวจว่ามีที่เก็บข้อมูลดังกล่าวอย่างไร ไม่ถือว่าค่าพิกัดสองตัวรักษาความหมายประกอบทุกอย่างไว้ครบแล้ว
การปัดทศนิยมเพื่อประหยัดพื้นที่ก็ต้องสัมพันธ์กับงาน ไม่ลดความละเอียดแบบถาวรตั้งแต่รับข้อมูลเพียงเพราะหน้าจอแสดงไม่กี่หลัก เราอาจแยกค่าที่เก็บไว้ใช้ประมวลผลออกจากค่าที่จัดรูปแบบให้คนอ่าน พร้อมบันทึกการแปลงเมื่อสร้างไฟล์สำหรับเผยแพร่
หากต้องเก็บข้อมูลประกอบใน properties ของ GeoJSON Feature ก็ควรกำหนดชื่อ field และความหมายไว้ในสัญญาของงาน ไม่ตั้งชื่อว่า accuracy แล้วคาดว่าทุกระบบจะรู้หน่วยหรือวิธีคำนวณตรงกัน การเก็บ field ได้ตามโครงสร้างไม่ได้ทำให้ความหมายเฉพาะงานกลายเป็นมาตรฐานกลางขึ้นมาเอง
ก่อนนำเข้าข้อมูลชุดใหญ่ ควรใช้ชุดทดลองที่ระบุชื่อ field ระบบพิกัดและตำแหน่งที่คาดไว้ ตรวจตั้งแต่ parser การบันทึก การส่ง API จนถึงจุดบนแผนที่ รวมถึงค่าติดลบ ค่าขาด และกรณีสลับแล้วยังอยู่ในช่วงที่รับได้
หากมีความสูงเป็นค่าที่สาม ต้องตรวจหน่วยและพื้นผิวอ้างอิงด้วย ไม่ถือว่าความสูงจากทุกอุปกรณ์มีความหมายเดียวกับค่าที่รูปแบบกำหนด การรักษาข้อมูลต้นทางกับขั้นแปลงให้ตามได้ช่วยให้ย้อนแก้โดยไม่ต้องเดาว่ารอบใดเป็นคนสลับหรือเปลี่ยนหน่วยไปแล้ว
บทนี้ไม่มีการวัดความแม่นของ GPS หรือเปิดตำแหน่งส่วนตัวมาเทียบ ภาพเป็นตัวอย่างสัญญาข้อมูลและวิธีรักษาความหมาย จึงยังไม่ยืนยันคุณภาพพิกัดของเส้นทางหรือชุดภาพใดโดยเฉพาะ
ตอนรับจากฟอร์มหรือไฟล์ข้อความ ควรตรวจรูปแบบตัวเลขก่อนสร้าง JSON ด้วย โดยแยกเครื่องหมายคั่นค่าออกจากเครื่องหมายทศนิยมตามต้นทาง ไม่แปลงข้อความที่อ่านไม่ผ่านเป็นศูนย์เพื่อให้ส่งต่อได้ และควรมีตัวอย่างทดสอบว่าค่าที่เขียนออกไปถูกอ่านกลับมาเป็นตำแหน่งเดิมตามสัญญา
พิกัดที่นำไปใช้ได้ต้องมีทั้งตัวเลข ลำดับ หน่วยและรูปแบบที่ตรงกัน เมื่อแยกการรับข้อมูลออกจากการสร้าง GeoJSON หรือ geo URI และตรวจความไม่แน่นอนแยกจากทศนิยม เราจะลดการปักหมุดผิดที่โดยยังรักษาบริบทต้นทางไว้ ส่วนความถูกต้องของตำแหน่งจริงต้องอาศัยหลักฐานการวัดและการตรวจตามงานนั้นเพิ่มเติม