Menampilkan koordinat dan input sebagai LatLon atau LonLat?


72

Saya mencoba memahami apakah ini masalah bagi orang lain atau setiap input / output harus diberi label sehingga pengguna tidak bingung dan langsung menggunakannya?

Saya pikir hampir semua orang mengucapkannya sebagai "LatLon".

Siapa yang memulai?

Apakah itu karena urutan abjad dibandingkan dengan "LonLat"?

Memetakan Lat dan Lon ke pesawat Cartesian Lon adalah "x" dan Lat adalah "y" jadi karena kita mengatakan "(x, y)" harus dikatakan sebagai "LonLat". Dan sekarang untuk menampilkan informasi.

Haruskah bilah status pada aplikasi pemetaan menampilkan La, Lo atau Lo, Lat?

Haruskah itu hanya dilabeli sebagai satu cara dan membiarkan pengguna menanganinya?

Dan sama dengan input, apa cara yang benar untuk memesan bidang?

Format KML adalah Lon, Lat, Altitude. Sementara aplikasi lain adalah Lat, Lon dan harus sangat waspada ketika mengkonversi format.

Apakah ada standar?


1
Baiklah secara pribadi, saya mengatakan Lat / Lon tapi saya selalu memasukkan X / Y. Ketika saya bekerja dengan data dan menerimanya dari klien atau menghapusnya dari situs web, mungkin sekitar 90% dari waktu saya mendapatkan X / Y.
Tac194

1
ahh ini pasti membawa kembali kenangan ... blogs.msdn.com/b/isaac/archive/2007/12/27/…
Kirk Kuykendall

1
Konversi ini ke Wiki karena tidak memiliki jawaban yang benar, tetapi mudah-mudahan menghasilkan beberapa diskusi yang bermanfaat.
scw


Jawaban:


38

Anda harus melihat pada standar ISO 6709. Inilah entri wikipedia: ISO 6709

Item utamanya adalah urutan harus selalu garis bujur lintang.

Latitude datang sebelum garis bujur

[sunting sekarang saya memiliki salinan 6709: 2008]

Untuk pertukaran data, gunakan DD, tetapi untuk kompatibilitas mundur, sexagesimal valid.

Ada bagian yang disebut "Koordinat lintang dan bujur tidak unik" lengkap dengan gambar.

Ada kata-kata yang sangat kuat tentang urutan koordinat untuk tampilan (bukan pertukaran). Dikatakan bahwa para navigator secara tradisional menggunakan urutan garis bujur dan mengubah urutannya dapat membahayakan keselamatan. Gunakan sexagesimal, simbol arah daripada +/-, dll. Nilai Z mengikuti garis bujur. Nilai kisi / planar harus menggunakan urutan yang ditentukan dalam definisi CRS.

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

(Hah! Saya mulai menulis sampel dan secara otomatis menulis nilai bujur terlebih dahulu)


7
Itu tidak berarti bahwa standar adalah yang terbaik. Murid-murid saya bingung dengan campuran lat / long ... lalu Anda memperkenalkan easting dan northing ... lalu x / y. Saya lebih suka bahwa satu tongkat dengan representasi matematika dari koordinat, apakah bola atau planar, x / y, timur / utara, panjang / lat ... mungkin sebuah gerakan bisa terjadi

Melita - Anda mengetahui bahwa ISO 6709 ADALAH standar. Tetapi revisi ISO 6709: 2008 "... juga menentukan representasi lokasi titik horizontal menggunakan tipe koordinat selain lintang dan bujur." Bisakah Anda memperluas aspek-aspek standar untuk orang-orang.
V Stuart Foote

1
@ Sitart, sayangnya saya tidak memiliki akses ke revisi 2008, dan tidak suka membayar € 122 untuk hak istimewa! Seseorang di sini mungkin memilikinya; Saya akan melihat apakah saya dapat menemukan salinannya. Masih ada masalah hak cipta tentang seberapa banyak saya dapat memposting.
mkennedy

@Dan, oh, saya setuju sepenuhnya, tetapi gerakan telah terjadi, dan akhirnya direvisi ke garis lintang saat ini, LALU bujur. Pada x, y: sayangnya, tidak semua orang menyamakan x = timur, y = utara! Esri memiliki beberapa permintaan perangkat tambahan untuk mendukung penggantian label untuk sumbu, urutan pertukaran, dll.
mkennedy

2
@ Sitart, saya mengedit jawaban saya untuk memasukkan beberapa informasi dari standar.
mkennedy

14

Mewakili posisi di bola dunia tidak hanya membutuhkan dua, tetapi tiga nilai, yang di bumi umumnya diwakili oleh (lintang, bujur, ketinggian). Komputer umumnya bekerja di ruang Cartesian, seperti halnya peta kertas kami, yang lebih mudah dipahami sebagai (x, y) koordinat, karenanya konflik.

Urutan mengikuti beberapa konvensi historis untuk koordinat bola, yang memetakan ke koordinat geografis sebagai berikut:

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

Urutan umum (r, θ, φ) ( standar ISO di komunitas fisika, meskipun tidak diselesaikan di tempat lain ) menyederhanakan ke (θ, φ) ketika Anda menganggap kami sedang mengerjakan unit sphere, dan karenanya (lintang, garis bujur).

Karena GIS diimplementasikan dalam lingkungan yang menggunakan koordinat kartesius digunakan di seluruh sistem, kita dibiarkan dengan sedikit konflik . Saya pikir masalah utamanya adalah memperjelas apa yang Anda gunakan, dan menaatinya.

Saya pribadi lebih suka unit Cartesian karena kesamaan mereka di tempat lain, dan sementara koneksi akademik untuk koordinat bola tidak boleh dilupakan, itu bukan pilihan pragmatis ketika menerapkan sistem baru. Formulir (x, y) digunakan secara internal di sebagian besar format file spasial seperti WKT, Shapefile, GeoJSON dan sejenisnya - tetapi jika Anda menyajikan data kepada audiens awam, maka apa yang benar tergantung pada apa yang paling mudah untuk mereka pahami .


2
(1) Ada adalah, bagaimanapun, sebuah konvensi untuk orientasi sistem koordinat . Menurut konvensi ini, misalnya, (x, y) positif sedangkan (y, x) negatif. Di lingkup, (lat, lon) adalah negatif sedangkan (lon, lat) adalah positif (mengambil garis bujur barat dan lintang selatan menjadi angka negatif, yang tampaknya universal). Oleh karena itu, jika Anda ingin menggunakan orientasi yang konsisten untuk sistem koordinat, Anda akan menggunakan (arah timur, utara) pada peta Anda dan (lon, lat) pada bola.
whuber

4

Dua jawaban sebelumnya sudah mencakup sejarah, inilah dua sen saya tentang standar:

Untuk tujuan pertukaran data, urutan koordinat ditentukan oleh pilihan CRS , seperti yang dipromosikan oleh OGC dalam Catatan Panduan Kebijakan Pesanan Axis mereka .

Jika Anda perhatikan dengan cermat, EPSS CRS mana pun menentukan urutan sumbu, yang harus dihormati dalam muatan apa pun yang ditandai untuk menggunakan CRS. Sebagai contoh, apa pun yang menerbitkan data dalam epsg: 4326 (WGS 84 2D geografis) harus memiliki koordinat yang dinyatakan sebagai (lat, lon). Anda dapat memeriksa sendiri registri EPSG (cari kode 4326 dan lihat di bawah Ellipsoidal CS / Axes).

Cara lain yang banyak digunakan untuk menentukan CRS adalah Proyeksi WKT (bagian 7; juga tersedia di sini ), yang juga menentukan pesanan. Sebagai contoh

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

Namun, parameter AXIS bersifat opsional, dan standarnya, sesuai dengan spesifikasi ini, adalah

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

ini membuat seluruh masalah cukup membingungkan, karena itu berarti bahwa banyak file .prj di luar sana merujuk pada epsg: 4326 ( misalnya yang ada di spatialreference.org ) yang tidak secara eksplisit menentukan urutan sumbu yang sama dengan EPSG, namun tetap merujuk pada Kode EPSG, bertentangan dengan catatan panduan OGC.


Saya tidak percaya bahwa spesifikasinya menentukan urutan penyimpanan. Mereka mendikte urutan pertukaran / tampilan. Agak seperti fisika kuantum. Anda tidak dapat (tidak perlu) tahu apa yang terjadi sampai Anda mengamati fenomena itu. Setuju dengan format wkt. Esri telah menambahkan dukungan untuk pesanan kapak ketika bekerja dengan server, tetapi tidak dalam perangkat lunak umum.
mkennedy

1
@kennedy, secara teknis Anda benar. Dalam shapefile, Anda dapat memiliki pesanan apa pun yang Anda suka. Tapi begitu Anda mengirim shapefile itu kepada seseorang dan menggambarkannya sebagai epsg: 4326, Anda harus memastikan bahwa urutannya adalah (lat, lon). Saya menghapus 'toko' dari jawaban untuk membuatnya lebih jelas bahwa standarnya adalah tentang menerbitkan data.
mkadunc


0

Ini menimbulkan masalah besar bagi saya selama bertahun-tahun pada AutoCAD 2D yang diperparah oleh kenyataan bahwa autocad membaca sudut berlawanan arah jarum jam dengan 0 derajat mulai dari posisi 90d. Untuk sementara saya suka percaya bahwa saya telah menyelesaikannya dengan mengubah UCS sehingga x menjadi utara dan timur. Selama saya terus menghasilkan rencana properti 2D, saya tidak pernah benar-benar menghadapi kesalahan saya: sumbu z menunjuk ke arah yang salah.

Tentu saja teks dimensi saya biasanya membaca dari kanan ke kiri, tetapi saya merasa itu adalah harga yang kecil untuk membayar sudut baca yang benar dan lebih pada intinya, menempatkan x dan y di tempat intuitif mereka (sesuai Northing / Easting, Lat./Lon (konvensi). Kemudian saya lulus ke Autocad Civil 3d dan mencoba melakukan trik lagi dan berhadapan muka dengan garis bawah: y adalah utara / lat dan x adalah Timur / panjang. Terima itu.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.