แสดงพิกัดและอินพุตเป็น LatLon หรือ LonLat หรือไม่

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

ฉันคิดว่าเกือบทุกคนออกเสียงว่า "LatLon"

ใครเป็นคนเริ่ม?

เป็นเพราะเรียงตามตัวอักษรเมื่อเทียบกับ "LonLat"?

การทำแผนที่ Lat และ Lon กับระนาบ Cartesian Lon คือ "x" และ Lat คือ "y" ดังนั้นเมื่อเราพูดว่า "(x, y)" มันควรจะเรียกว่าเป็น "LonLat" และตอนนี้เพื่อแสดงข้อมูล

แถบสถานะบนแอปพลิเคชันแผนที่ควรแสดง La, Lo หรือ Lo, Lat หรือไม่

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

เช่นเดียวกับอินพุตสิ่งที่ถูกต้องในการสั่งซื้อเขตข้อมูลคืออะไร?

รูปแบบของ KML คือ Lon, Lat, Altitude ในขณะที่แอพอื่น ๆ เป็น Lat, Lon และต้องระมัดระวังเป็นอย่างมากเกี่ยวกับการแปลงรูปแบบ

มีมาตรฐานหรือไม่?

คุณควรดูที่มาตรฐาน ISO 6709 นี่คือรายการ wikipedia: ISO 6709

รายการหลักคือคำสั่งนั้นควรเป็นละติจูดลองจิจูด

ละติจูดมาก่อนลองจิจูด

[แก้ไขทันทีที่ฉันมีสำเนา 6709: 2008]

สำหรับการแลกเปลี่ยนข้อมูลใช้ DD แต่สำหรับความเข้ากันได้แบบย้อนหลัง sexagesimal จะใช้ได้

มีส่วนที่เรียกว่า "ละติจูดและลองจิจูดไม่แตกต่างกัน" สมบูรณ์พร้อมรูปภาพ

มีถ้อยคำที่แข็งแกร่งมากเกี่ยวกับลำดับการประสานงานสำหรับการแสดงผล (ไม่ใช่การแลกเปลี่ยน) มันบอกว่าผู้นำได้ใช้คำสั่งละติจูดลองจิจูดและการเปลี่ยนแปลงคำสั่งสามารถดั้งเดิมความปลอดภัย ใช้สัญลักษณ์ทางเพศสัมพันธ์มากกว่า +/- ฯลฯ ค่า Z เป็นไปตามลองจิจูด ค่ากริด / ระนาบควรใช้ลำดับที่ระบุในคำจำกัดความของ CRS

34 ° 05'09.76 "N 117 ° 02'01.23" W 829.1m

(หือ! ฉันเริ่มเขียนตัวอย่างและเขียนค่าลองจิจูดโดยอัตโนมัติก่อน)

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

การจัดลำดับตามแบบแผนทางประวัติศาสตร์บางประการสำหรับพิกัดทรงกลมซึ่งแผนที่ลงบนพิกัดทางภูมิศาสตร์ดังนี้:

geographic spherical   symbol
---------- ---------   ------
longitude  azimuth       φ
latitude   inclination   θ 
elevation  radius        r

การจัดเรียงแบบทั่วไปของ (r, θ, φ) ( มาตรฐาน ISOในชุมชนฟิสิกส์แม้ว่าจะไม่ได้ตัดสินที่อื่น ) จะลดความซับซ้อนลง ((, φ) เมื่อคุณคิดว่าเรากำลังทำงานกับหน่วยทรงกลมและด้วยเหตุนี้ (ละติจูด, ลองจิจูด).

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

ฉันชอบหน่วยคาร์ทีเซียนเป็นการส่วนตัวเพราะเป็นเรื่องธรรมดาที่อื่นและในขณะที่การลืมความสัมพันธ์เชิงวิชาการกับพิกัดทรงกลมนั้นไม่ได้เป็นสิ่งที่ถูกต้อง รูปแบบ (x, y) ถูกใช้ภายในในรูปแบบไฟล์เชิงพื้นที่ส่วนใหญ่เช่น WKT, Shapefiles, GeoJSON และสิ่งที่คล้ายกัน - แต่ถ้าคุณนำเสนอข้อมูลต่อผู้ชมทั่วไปแล้วสิ่งที่ถูกต้องขึ้นอยู่กับสิ่งที่ง่ายที่สุดสำหรับพวกเขาที่จะเข้าใจ .

คำตอบสองข้อก่อนหน้านี้ครอบคลุมประวัติแล้วนี่เป็นเพียงสองเซ็นต์ของฉันเกี่ยวกับมาตรฐาน:

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

หากคุณมองอย่างใกล้ชิด CRG EPSG ใด ๆ ระบุลำดับของแกนซึ่งควรได้รับการเคารพในน้ำหนักบรรทุกที่ทำเครื่องหมายไว้ว่าจะใช้ CRS ตัวอย่างเช่นทุกสิ่งที่เผยแพร่ข้อมูลใน epsg: 4326 (WGS 84 2D ทางภูมิศาสตร์) ควรมีพิกัดที่แสดงเป็น (lat, lon) คุณสามารถตรวจสอบรีจิสทรี EPSG ได้ด้วยตัวเอง (ค้นหารหัส 4326 และดูที่ Ellipsoidal CS / Axes)

อีกวิธีที่ใช้กันอย่างแพร่หลายในการระบุ CRS คือProjection WKT (ส่วนที่ 7; มีให้ที่นี่ด้วย ) ซึ่งกำหนดลำดับ ตัวอย่างเช่น

...
AXIS["Lat",NORTH],
AXIS["Lon",EAST],
...

อย่างไรก็ตามพารามิเตอร์AXISเป็นทางเลือกและค่าเริ่มต้นตามข้อกำหนดนี้คือ

AXIS["Lon",EAST],AXIS["Lat",NORTH].

สิ่งนี้ทำให้ปัญหาค่อนข้างสับสนเนื่องจากหมายความว่ามีไฟล์. prj จำนวนมากอ้างอิง epsg: 4326 ( เช่นหนึ่งใน spatialreference.org ) ซึ่งไม่ได้ระบุลำดับแกนเดียวกันกับ EPSG อย่างชัดเจน แต่อย่างไรก็ตามยังอ้างอิงถึง รหัส EPSG ขัดแย้งกับคำแนะนำ OGC

นี่เป็นปัญหาที่พบบ่อยนี่คืออีกการสนทนาก่อนหน้านี้:

• ทำไมบางระบบพิกัดกำหนดแกน x เป็นทิศเหนือและบางส่วนเป็นตะวันออก

มีการพูดคุยอย่างละเอียดถี่ถ้วนที่http://wiki.osgeo.org/wiki/Axis_Order_Confusion

@wwnick ให้ข้อมูลข้างต้นเป็นความคิดเห็นสำหรับคำถามที่ซ้ำกัน

นี่เป็นปัญหาใหญ่สำหรับฉันในปีของ AutoCAD 2D ประกอบกับความจริงที่ว่า AutoCAD อ่านมุมทวนเข็มนาฬิกาด้วย 0 องศาเริ่มต้นที่ตำแหน่ง 90d ในขณะที่ฉันชอบที่จะเชื่อว่าฉันได้แก้ไขมันโดยการเปลี่ยน UCS เช่นนั้น x กลายเป็นทิศเหนือและทิศตะวันออก y ตราบใดที่ฉันยังคงสร้างแผนอสังหาริมทรัพย์แบบ 2 มิติฉันก็ไม่เคยเจอกับข้อผิดพลาดจริง ๆ : แกน z ชี้ไปในทางที่ผิด

แน่นอนว่าขนาดข้อความของฉันมักจะอ่านจากขวาไปซ้าย แต่ฉันรู้สึกว่ามันเป็นราคาขนาดเล็กที่ต้องจ่ายสำหรับการอ่านมุมที่ถูกต้องและมากขึ้นถึงจุดวาง x และ y ในสถานที่ที่ใช้งานง่ายของพวกเขา (ตาม Northing / Easting, Lat./Lon อนุสัญญา) จากนั้นฉันจบการศึกษาไปที่ Autocad Civil 3d และพยายามที่จะเล่นกลอีกครั้งและเผชิญหน้ากับบรรทัดล่าง: y คือ north / lat และ x คือทิศตะวันออก / ยาว ยอมรับว่า