Menampilkan koordinat dan input sebagai LatLon atau LonLat?

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?

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)

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 .

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.

Ini adalah masalah umum, berikut diskusi sebelumnya:

• Mengapa beberapa sistem koordinat mendefinisikan sumbu x sebagai arah utara dan beberapa sebagai arah timur?

Ada diskusi yang sangat lengkap di http://wiki.osgeo.org/wiki/Axis_Order_Confusion

@wwnick memberikan informasi di atas sebagai komentar terhadap pertanyaan rangkap

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.