Mengapa sebagian besar paket GIS memerlukan nomor numerik?

11

Ini adalah pertanyaan sederhana namun mungkin kontroversial: mengapa sebagian besar (jika tidak semua) paket GIS mengharuskan lapisan yang ditentukan memiliki pengidentifikasi numerik yang tidak dapat dibatalkan ?

Mengapa ada kebutuhan untuk kunci pengganti seperti itu daripada yang alami?

Contoh:

  • ArcGIS memberlakukan OBJECTID (atau GlobalID)

  • QGIS tidak memuat layer ketika mereka tidak memiliki id numerik.

George Silva
sumber
8
Penjelasan yang mungkin: id numerik membutuhkan byte jauh lebih sedikit daripada id non-numerik. Ini semakin penting ketika Anda mulai menautkan tabel yang berbeda, yang semuanya menyimpan salinan id.
johanvdw
+1 Pertanyaan bagus, saya rasa NoSQL tidak membutuhkan kunci numerik.
Kirk Kuykendall
tinyurl.com/6xrtk2l
CaptDragon
@cap Itu sedikit sinis (dan Anda sudah memposting tautan itu).
whuber

Jawaban:

6

Karena mereka harus memiliki bidang indeks yang dioptimalkan. Untuk mengindeks bidang string berulang kali akan membutuhkan lebih banyak overhead dan pada akhirnya tidak seefisien.

ESRI sebenarnya mendukung di dunia SDE 'GLOBALID' yang merupakan bidang GUID, jadi ini adalah bidang 32char tetapi masih diindeks untuk meningkatkan kinerja.

Benar
sumber
3
Itu penjelasan yang bagus untuk keuntungan efisiensi dari id angka. Tapi saya pikir @George menyelidiki lebih dalam dari ini. Secara teknis, RDBMS tidak perlu pengidentifikasi mereka menjadi numerik, jadi mengapa harus GIS?
whuber
1
Masalahnya di sini bukan kinerja. Kunci unik yang tidak dapat dibatalkan dapat melakukannya. Tapi mengapa harus numerik? Setelah saya mendengar atau membaca bahwa itu harus numerik karena menggunakan kunci itu untuk mengontrol rendering ... apakah dalam Modeling Our World from ESRI?
George Silva
2
Karena GIS bukan RDBMS, meskipun dapat memanfaatkannya. GIS biasanya akan memiliki beberapa aturan dan asumsi, seperti asumsi bahwa kunci utama akan menjadi bilangan bulat yang diindeks atau GUID, demi kinerja dan pengkodean kewarasan.
blah238
1
ok, tapi mengapa menganggap angka? mengapa kita tidak bisa memilih kunci kita saat membuat layer?
George Silva
1
Saya membayangkan alasan utamanya adalah asumsi-asumsi itu membuat pekerjaan penulisan kode yang membuat paket GIS bekerja jauh lebih mudah.
blah238
4

Jika Anda mulai menambahkan catatan ke lapisan Anda bisa mengandalkan pengguna memasukkan kode alfanumerik unik untuk setiap fitur baru sebelum menulisnya ke disk ..

..atau Anda bisa menerapkan bidang bilangan bulat autoincrementing sederhana.

geografi
sumber
4

Seperti yang disarankan banyak orang, ini adalah masalah kenyamanan; tapi mungkin yang lebih dalam, itu adalah konvensi.

Sebagai seorang programmer, insting pertama saya adalah menggunakan kunci numerik untuk layer ID karena itulah yang selalu dilakukan. Memang, bahkan mungkin tidak terpikir oleh saya, pada tingkat sadar setidaknya, bahwa saya harus melakukannya dengan cara lain. Tentu saja, jika ada alasan teknis untuk tidak menggunakan bilangan bulat, katakan jika ada kemungkinan ada lebih banyak lapisan daripada yang dapat disimpan dalam 32-bit (proposisi yang sangat tidak mungkin!), Atau jika ada alasan bisnis untuk itu, maka alternatif akan dipertimbangkan.

Ada juga pertimbangan algoritmik dengan tombol angka. Menyortir, dan mencari daftar nilai yang diurutkan akhirnya bermuara pada perbandingan antara dua angka, bahkan jika itu adalah daftar string atau objek kompleks; mereka hanya diubah menjadi angka dengan fungsi hashing . Karena itu, pada komputer modern, mencari daftar katakanlah 100 atau bahkan 1000 item biasanya sama cepatnya dengan pendekatan brute-force seperti halnya dengan algoritma yang sangat dioptimalkan. Dalam kasus lapisan dalam GIS, saya tidak dapat melihat bahkan peta yang paling kompleks sekalipun memiliki lebih dari 1000, dan bahkan jika itu terjadi, perhitungan lain yang terkait akan mengambil urutan besarnya lebih lama daripada keuntungan kecil dari pengoptimalan mencari daftar pendek.

Kunci integer "masuk akal" untuk seorang programmer, dan seperti kata Brad, ada lebih banyak upaya dalam menggunakan kunci non-numerik. Mungkin bukan lebih banyak kode, tetapi lebih banyak upaya mental, dan kita adalah makhluk kebiasaan yang malas. Juga, kunci yang secara unik mengidentifikasi sesuatu seperti lapisan dalam GIS dianggap "tersembunyi" dari pengguna, untuk memastikan mereka tidak mengacaukannya dan memecah kode yang bergantung pada keunikannya (meskipun kata kunci UNIK DB DB). Karena jika Anda memberi pengguna cukup tali, cepat atau lambat seseorang akan menggantung diri dengannya. Dengan segala cara menegakkan keunikan pada bidang yang dapat diedit pengguna, tetapi sistem yang mendasarinya harus menganggap kuncinya unik dan tidak teramputasi.

MerseyViking
sumber
The OpenStreetMap adalah salah satu contoh dari sebuah proyek yang membutuhkan lebih dari 32-bit bilangan bulat. Mereka gunakan bigintuntuk kunci utama mereka.
Mike T
Untuk cara / simpul, ya. Tetapi pertanyaan aslinya adalah tentang lapisan dalam GIS.
MerseyViking
OpenStreetMap menyimpan lapisan GIS.
George Silva
OSM hanya menyimpan cara dan simpul yang memiliki tag kunci / nilai. Terserah sistem presentasi (misalnya OpenLayers) dan rendering backend (misalnya Mapnik, Osmarender) untuk menentukan gagasan lapisan berdasarkan tag-tag itu atau yang lainnya. Tapi Mike benar, ia menggunakan bigints untuk semua kunci primer tabelnya.
MerseyViking
+1 untuk menyebutkan tentang konvensi. Ini adalah konvensi karena sama dengan kinerja yang lebih baik.
CaptDragon
3

Pertanyaan ini telah membingungkan orang (seperti saya) yang mengembangkan sisi geodatabase.

Ini bukan batasan penyimpanan basis data, karena PostgreSQL dapat mendefinisikan tabel dengan tombol KUNCI UTAMA dari tipe data yang berbeda, namun, tabel ini tidak dapat dimuat ke dalam program seperti QGIS. Pada catatan historis terkait, PostgreSQL digunakan untuk membutuhkan kolom OID sebagai kunci internal, yang juga merupakan bilangan bulat 32-bit. Ini diperlukan hingga versi 7.2 .

Persyaratan ID integer 32-bit sebenarnya adalah batasan pemrograman. Jauh lebih mudah untuk memiliki indeks ke set catatan sebagai tipe data tetap (bilangan bulat 32-bit), dan lebih nyaman untuk ini juga menjadi KUNCI UTAMA untuk catatan itu. Lebih sulit untuk membuat program memungkinkan kunci primer komposit, dan untuk itu mengambil catatan unik berdasarkan beberapa dan / atau berbagai tipe data. Namun, seperti OID PostgreSQL, batasan ini dapat diatasi dengan waktu pengembangan. Untuk QGIS, bug [ 5 tahun ] yang sudah berusia 5 tahun mungkin teratasi suatu hari nanti (inilah beberapa diskusi terkini tentang topik tersebut).

Mike T
sumber
+1 Dikatakan dengan baik. Sebagai bukti lebih lanjut bahwa ini adalah batasan pemrograman, perhatikan bahwa ESRI tidak memerlukan (atau menggunakan) bidang pengenal internal apa pun di ArcView sebelum ArcGIS 8.x keluar. ArcView lama mampu semua operasi database yang melakukan ArcGIS (dan sebenarnya lebih cepat di banyak dari mereka).
whuber
2

Dalam ESRI, dan perangkat lunak GIS lainnya, biasanya memiliki folder atau set file yang dibuat pada kelas fitur atau dataset.
misal cakupan arcinfo, shapefile, file geodatabase.
"Kumpulan" file ini perlu "digabungkan" oleh perangkat lunak untuk memungkinkan banyak fungsi GIS.
Tabel attrubute, jaringan, kontrol topologi.
Itulah tujuan dari OID dan juga alasan untuk membuatnya tidak dapat dibatalkan, disembunyikan, dikendalikan oleh perangkat lunak.

Brad Nesom
sumber
Saya pikir operasi GIS mungkin ada hubungannya dengan ini, sungguh. intersect, serikat (spasial), perbedaan, dll. Adakah yang bisa mengkonfirmasi atau menyajikan ini lebih detail?
George Silva
Lihatlah bagaimana satu kelas fitur SDE sebenarnya disimpan dalam database seperti Oracle. Ada satu tabel untuk atribut, satu tabel untuk geometri, satu tabel untuk indeks spasial, satu atau lebih tabel untuk indeks atribut, dll. Jika ESRI harus mendukung setiap halaman kode / pengkodean karakter untuk string PKEY kita akan semua masih di ArcView 3.x.
blah238
@ George - seperti dicatat oleh blah238 Ada sangat sedikit aplikasi GIS yang menggunakan satu file tunggal untuk menyimpan kedua (semua) data. Yang dapat terdiri dari koordinat, ukuran, atribut, aturan, hubungan, dan lainnya tergantung pada paket. Ini lebih berkaitan dengan bisa melacak baris spasial mana yang berjalan dengan baris atribut mana, baris jaringan mana, dan seterusnya.
Brad Nesom
1
Maaf blah238, saya benar-benar tidak berpikir jumlah kode adalah penentu dalam masalah ini. Enconding tidak ada hubungannya dengan ini. Basis data akan melakukan "matematika" dan memutuskan apakah urutan karakter sama atau tidak, oleh karena itu, menegakkan PKEY. Itu bukan pada lapisan perangkat lunak. @Brad Nesom: itu juga masuk akal. Tetapi dalam Oracle dan PostGIS Anda dapat menyimpan semua atribut Anda pada satu tabel. Saya setuju bahwa shapefile memerlukan ObjectID yang ditakuti ... dan yang mungkin telah menetapkan standar?
George Silva
@ George Shapefiles tidak diperlukan atau, sebagai aturan umum, menggunakan ObjectID. Bidang OID itu diperkenalkan dengan ArcGIS 8. Oleh karena itu saya ragu bahwa shapefile ada hubungannya dengan pertanyaan.
whuber