Urutan penulisan tupel lintang & bujur yang disukai dalam layanan GIS


144

Ketika berhadapan dengan kode sumber SIG Anda sering perlu menulis koordinat koordinat lintang dan bujur.

Misalnya dalam tautan Google Maps (123, 456):

http://maps.google.com/maps/ms?msid=214518704716144912556.00046d7689a99e95b721c&msa=0&ll=123,456&spn=0.007996,0.026865

Pesanan mana yang disukai (dan mengapa?)

  • Garis lintas garis bujur

  • bujur, lintang

Saya telah melihat keduanya digunakan dalam berbagai sistem dan saya berharap untuk menemukan beberapa bukti untuk tetap dengan yang lain.

Apakah ada praktik standar, dan jika demikian, apa itu / apa itu?


2
alih-alih memesan pilihan, Anda dapat memeriksa kompilasi kasus: macwright.org/lonlat
golimar

3
Ini latitude, longitudepesanan
onmyway133

1
Saya memberikan suara untuk menutup pertanyaan ini karena ini bukan tentang pemrograman tetapi tentang geografi. Ini juga pertanyaan berbasis opini.
TylerH

1
@MikkoOhtamaa Perbedaannya adalah bahwa pertanyaan Anda tidak menanyakan apa pesanan yang diperlukan untuk spesifikasi teknis tertentu (yang kemungkinan besar akan sama di luar topiknya dengan permintaan untuk informasi dokumentasi di luar lokasi), melainkan apa metode 'disukai' adalah [ secara umum ]. Perubahan apa yang disukai berdasarkan orang yang Anda tanya dan tujuan / konteks penggunaan. Seperti yang ditunjukkan oleh jawaban di sini, kedua pemesanan memiliki pengikut yang substansial. Selanjutnya, masalah hubungan pemrograman masih sepenuhnya belum teratasi.
TylerH

1
@MikkoOhtamaa Saya tidak punya masalah dengan pertanyaan GIS di Stack Overflow. Ini bukan pertanyaan GIS; itu adalah pertanyaan "bagaimana saya harus memesan lintang / bujur" ... bahkan tidak ada aplikasi GIS spesifik yang Anda minta. Pertanyaan ini masih berdasarkan pendapat (pertanyaan apa pun yang menanyakan "metode yang disukai" didasarkan pada pendapat), terlalu luas (konteks, skenario, atau aplikasi apa yang Anda tanyakan? Seperti jawaban yang ditunjukkan, berbeda berdasarkan kriteria tersebut), dan bukan tentang pemrograman (lintang dan bujur bukan istilah pemrograman tetapi istilah geografi).
TylerH

Jawaban:


210

EPSG: 4326 secara khusus menyatakan bahwa urutan koordinat harus lintang, bujur. Banyak paket perangkat lunak masih menggunakan bujur, pemesanan lintang. Situasi ini telah mendatangkan malapetaka pada tenggat waktu proyek dan kewarasan programmer.

Panduan terbaik yang dapat ditawarkan adalah sepenuhnya menyadari urutan sumbu yang diharapkan dari setiap komponen dalam tumpukan perangkat lunak Anda. PostGIS mengharapkan lng / lat. WFS 1.0 menggunakan lng / lat, tetapi WFS 1.3.0 menolak standar dan menggunakan lat / lng. GeoTools secara default adalah lat / lng tetapi dapat diganti dengan properti sistem.

Dokumen GeoTools tentang sejarah dan penjelasan masalah patut dibaca: http://docs.geotools.org/latest/userguide/library/referencing/order.html


6
Saya jarang melihat sebagai jawaban di SO.com yang menyatakan mengapa ini baik. Ketukan omong kosong dari jawaban "karena MongoDB menggunakannya".
Mikko Ohtamaa

1
Tautan Anda tidak setuju dengan Anda; Dalam database EPSG, 4326 memetakan ke CRS geografis dengan urutan sumbu (lintang, bujur). Namun, sebagian besar perangkat lunak di lapangan memahami EPSG: 4326 sebagai CRS geografis dengan urutan sumbu (bujur, lintang), karena spesifikasi OGC lama dirancang seperti itu.
Aaron McIver

7
Dua kalimat pertama dari jawaban saya: EPSG: 4326 secara khusus menyatakan bahwa urutan koordinat harus lintang, bujur. Banyak paket perangkat lunak masih menggunakan bujur, pemesanan lintang. Bukankah itu persis sama?
Shane

5
Jika ada orang lain yang memiliki masalah dengan Google Maps dan menyediakan file KML untuk itu, urutannya adalah Bujur / Lintang !! Tidak ada dokumentasi untuk file KML yang mengatakan ini !!
Turnerj

2
"Tidak ada dokumentasi untuk file KML yang mengatakan ini" tidak benar. developers.google.com/kml/documentation/kmlreference#point "Tupel tunggal yang terdiri dari nilai titik mengambang untuk bujur, lintang, dan ketinggian (dalam urutan itu)."
tmcw

28

Pesanan yang disukai adalah dengan konvensi latitude, longitude. Ini mungkin distandarisasi oleh Organisasi Maritim Internasional seperti yang dilaporkan di sini . Google juga menggunakan pesanan ini di Maps dan Earth-nya . Saya ingat urutan ini dengan memikirkan urutan alfabet latitude, longitude.


12
Kecuali dalam file KML. Di sana koordinat disimpan sebagai lng, lat, alt; mungkin karena itu dapat diterjemahkan ke x, y, z
Wouter van Nifterick

23

Urutan yang benar adalah bujur, lintang, di hampir semua aplikasi GIS profesional, seperti dalam matematika konvensional (yaitu, f(x ,y, z)). Standar GeoJSON cukup khas dan ringkas:

The order of elements must follow x, y, z order
(easting, northing, altitude for coordinates in a 
projected coordinate reference system, or longitude,
latitude, altitude for coordinates in a geographic
coordinate reference system).

Hal yang sama berlaku untuk standar Open Geospatial Consortium primer (WKT dan WKB, dan ekstensi seperti EWKB). Demikian juga Google dapat menampilkan pesanan dalam Lat / Lon untuk membuatnya lebih akrab bagi pengguna yang tumbuh dengan kebiasaan itu (yaitu dari standar navigasi seperti IMO, daripada yang komputasi.) Tetapi standar KML itu sendiri seperti hampir semua sistem GIS lainnya:

The KML encoding of every kml:Location and coordinate
tuple uses geodetic longitude, geodetic latitude, and
altitude (in that order).

Aturan praktis yang baik: jika Anda tahu apa tuple adalah dan pemrograman, Anda harus menggunakan lon, lat. Aku bahkan akan mengatakan ini berlaku jika pengguna akhir Anda (mengatakan pilot atau kapten kapal) akan lebih memilih untuk melihat output dalam lat, lon. Anda dapat mengganti urutan di UI Anda jika perlu, tetapi sebagian besar data Anda (shapefile, geojson, dll.) Akan berada dalam urutan Cartesian normal.


4
Saya melihat beberapa ketidaksepakatan di sini: SAYA DUA pilihan untuk memilih - terlalu banyak!
Mikko Ohtamaa

6
Pembaca harus mencatat bahwa ISO 6709 secara eksplisit menyatakan Anda harus selalu menggunakan format [lat, lon] di UI apa pun dan tidak - sebagaimana mungkin disimpulkan - hanya masalah preferensi pribadi.
Iain Collins

9

Dengan konvensi dalam 'kehidupan nyata', ketika memberikan posisi, garis lintang (yaitu Utara / Selatan) selalu diberikan 1, misalnya 20 ° N 56 ° W (walaupun, ini tidak mengikuti konvensi normal jika memikirkan standar Cartesian grid); sama halnya, semua koordinat di Wikipedia mengikuti konvensi ini (misalnya, lihat lokasi untuk Southampton: http://en.wikipedia.org/wiki/Southampton ). Untuk menyimpan kebingungan, terutama ketika unit tidak dimasukkan, saya selalu merekomendasikan bahwa garis lintang diberikan 1 dalam tupel.


9

Secara pribadi saya belum pernah melihat apa pun kecuali garis lintang diikuti oleh garis bujur.

Dan, ketika menggunakan + dan - alih-alih N dan S, selalu + adalah N dan - adalah S.

Saya telah mengamati variasi ketika menggunakan + dan - untuk E dan W. Secara umum + telah menjadi E dan - telah menjadi W. Namun, pada aplikasi yang lebih tua di mana mereka berurusan overhwlemingly dengan W bujur, saya telah melihat + menjadi W dan - menjadi E .

Semoga Anda tidak harus berurusan dengan aplikasi yang lama.


Mudah diamati ketika Anda bekerja dengan aplikasi di seluruh dunia.
Daniel Antunes Pinto

Cukup ketikkan pasangan koordinat bujur dan lintang ke dalam peta Google dan Anda akan melihatnya mengartikannya sebagai (panjang, lat), bukan sebaliknya. Itu adalah contoh dari sistem yang sangat banyak digunakan.
cazort

2
@cazort Untuk alasan apa pun, itu tidak terjadi di sini. Sebagai contoh, kampung halaman saya di Eugene, Oregon adalah sekitar N 44.1, W 123.1. Jika di maps.google.com saya masukkan 44.1 -123.1, ia menuju ke Eugene. Jika saya memasukkan -123.1 44, ia memberi tahu saya tidak dapat menemukannya. Menariknya, jika saya memasukkan 123.1 W 44 N, ia mencari tahu dan pergi ke Eugene, jadi ada beberapa fleksibilitas. Reference.com/technology/… juga menunjukkan bahwa lat / long adalah urutan yang diinginkan. Juga, untuk apa nilainya, Google Earth menggunakan lat / long.
Terry

5

Terlepas dari spesifikasi GeoJSON, yang orang lain telah sebutkan, ada kasus praktis lainnya di mana bujur, urutan latitide direkomendasikan, bahkan wajib - misalnya: pengindeksan geospasial dalam MongoDB . Jika Anda salah memesan di sana, kueri Anda akan mengembalikan hasil yang salah, seolah-olah dilakukan lagi dengan dataset yang dialihkan.


5

Jadi pesanan yang disukai tergantung pada preferensi pribadi!

Latitude datang lebih dulu; ekuinoks telah dikenal selama ribuan tahun, karena zaman "matahari melintasi khatulistiwa"; pada bulan Maret menyeberang dari S ke N dan September dari N ke S. Satu-satunya pertanyaan mungkin adalah apakah Ekuator seharusnya 0 atau 90 derajat. Dengan mengambil 0 derajat, sudut antara zenit surya vertikal dan tengah hari di titik balik adalah garis lintang suatu lokasi, di mana pun di planet ini. Garis lintang utama, atau garis tengah utama secara efektif mendefinisikan dirinya sendiri.

Garis bujur hanya bisa dengan persetujuan. Inggris memasang hadiah Bujur. Inggris membutuhkan kapal-kapalnya untuk mengetahui di mana mereka berada dan membutuhkan peta yang lebih baik. Harrison ( http://www.youtube.com/watch?v=T-g27KS0yiY ) menghasilkan kronometer laut yang akurat; mereka mengirim perjalanan pembuatan peta misalnya James Cook 1770's. Karena itu Inggris mengklaim Meridian Utama dengan menggunakan Greenwich sebagai 000deg untuk peta mereka. Setelah 100 tahun penggunaannya, Meridian Perdana diterima secara internasional, pada tahun 1884.

Di Christopher Columbus, waktu Latitude adalah satu-satunya nomor yang mereka miliki. Strateginya adalah untuk melintasi paralel sebelum belok kiri atau kanan ke tujuan; mengawasi awan atau burung. Mengukur kecepatan dalam knot setiap jam adalah hal biasa tetapi tidak memperhitungkan arus. Mungkin prestasi terbesar Columbus adalah pulang ke rumah dari Hindia Barat empat kali. Tanpa itu, tanah yang dia temukan tidak dapat ditambahkan ke peta.

Baca "Bujur" oleh Dava Sobel (ISBN: 9780007214228)


1
Saya pikir maksudnya secara terprogram dan dengan referensi teknis (tapi saya bisa saja salah). Namun, pelajaran sejarah itu menarik.
jww

1
Ini tidak terkait dengan pertanyaan, tetapi pasti menarik. Terima kasih :)
Mikko Ohtamaa

Tapi itu masuk akal, karena jika hanya koordinat peta yang akan digunakan, itu akan tanpa pertanyaan bahwa urutannya adalah bujur, lintang, seperti pada X, Y; kebingungan hanya ada karena ratusan tahun diutamakan mengatakan (dan mendengar) lintang, bujur di mana-mana.
Antti Haapala

5

ISO 6709 menstandarisasi daftar urutan sebagai lintang, bujur untuk alasan keamanan. Penjelasan Graham di atas juga terdengar benar bagi saya. Seseorang menyarankan jawaban ini tidak terkait dengan pertanyaan - itu memang benar, dan menjelaskan mengapa urutannya sering diberikan sebagai garis lintang, garis bujur.

Ini adalah bagaimana telah terdaftar untuk berapa lama navigator telah menggunakan sistem; mengubah yang sekarang akan membingungkan, dan seperti yang disarankan ISO, berpotensi berbahaya. Perangkat lunak GIS, seperti ArcMap, mendaftarkannya sebaliknya karena itu adalah konvensi umum untuk pasangan koordinat x, y. Latitude adalah y, bujur adalah x, jadi begitulah Arc mencantumkannya.


1

Bujur lalu Lintang (lon, lat).

Ketika diproyeksikan ke garis bujur Mercator menentukan arah x dan garis lintang mendefinisikan arah y. Kebanyakan pustaka geometri secara ketat menggunakan format ini (lon, lat) karena ini adalah cara paling intuitif untuk memikirkan koordinat geografis dalam bidang 2D.


3
Jadi, jika itu cara berpikir yang paling intuitif, mengapa blog Google Earth disebut Lat-Long Blog sementara mereka menggunakan lon-lat di KML?
theta

1
Pada dasarnya, navigator biasanya menggunakan penguraian lat-lon, jadi jika Anda mengacaukan pemesan itu, Anda mungkin mengacaukan navigasi Anda. Jadi google menggunakan tradisional untuk blog dan pemesanan bidang 2D untuk struktur data mereka. @kenkeny menjawab ini dengan jawaban terbaiknya untuk pertanyaan yang sama: gis.stackexchange.com/questions/6037/…
David
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.