Apakah ada nilai Dummy Z standar atau "paling sering digunakan"?


10

Membuat dan mengimpor data 2D dan 3D, saya berkali-kali menghadapi situasi di mana saya tidak memiliki nilai Z untuk set koordinat, bahwa nilai koordinat Z tampaknya di luar jangkauan (seperti -99, -9999, -inf atau serupa) ) atau bahwa saya perlu membuat koordinat Z dummy .

Saya tahu bahwa jawaban untuk pertanyaan saya adalah:

"Cukup gunakan nilai yang pasti di luar jangkauan dalam kasus Anda."

Tapi jawaban itu mengesampingkan saya bertanya-tanya apakah komunitas GIS memiliki nilai standar atau paling sering digunakan untuk koordinat Z dummy ?

Jawaban:


5

Semua balasan saat ini memberikan saran yang bagus. Aturan umum (dari komunitas komputasi ilmiah) yang berfungsi dengan baik dalam kasus di mana Anda tidak dapat menyimpan nulls benar atau NaN menggunakan nilai terkecil (paling negatif) yang akan dipegang oleh bidang (secara sah).

Contoh:

  • Bidang 7,2 desimal dapat menampung nilai sekecil -9999,99.

  • Raster integer dapat menampung angka sekecil -32768, tetapi sering (karena keengganan terhadap biner dan afinitas untuk basis 10) nilai -9999 digunakan sebagai gantinya.

  • Float dapat menampung angka pada urutan -10 ^ (38). Jika Anda tidak dapat menempatkan NaN di lapangan, temukan float terkecil yang sesuai (yang menyakitkan) atau gunakan sesuatu seperti -10 ^ (38) itu sendiri. Untuk ganda, -10 ^ (303) berfungsi dengan baik, tetapi begitu juga -10 ^ (38): cukup besar dan negatif untuk berfungsi sebagai penanda yang jelas dari nilai nol.

Aturan ini mudah diingat, konsisten, mudah diterapkan, mudah didokumentasikan dengan cara boilerplate (untuk metadata Anda), dan jarang mengarah pada kesalahan yang tidak disengaja (karena angka paling negatif biasanya sangat berbeda dari data sehingga penyalahgunaannya sebagai nilai aktual, alih-alih sebagai nol, ringkasan statistik korup dan perhitungan lainnya cukup untuk menaikkan tanda bahwa ada masalah).


5

Jika data Anda ada dalam database maka idealnya Anda akan menggunakan nilai NULL :

representasi "informasi yang hilang dan informasi yang tidak dapat diterapkan"

Namun ini dapat menyebabkan masalah dengan aplikasi dan kode klien, dan saya tidak percaya NULL didukung dalam DBF. Nilai apa yang seharusnya saya kira berbeda untuk konvensi organisasi yang berbeda. Nilai dummy apa pun yang Anda pilih, pastikan itu dicatat dalam metadata dataset.

Jika tidak ada poin untuk dataset memiliki nilai Z maka saya tidak melihat mengapa 0 tidak dapat digunakan, meskipun dalam kasus itu mungkin yang terbaik untuk menghapus kesadaran-Z dataset sepenuhnya untuk menghindari kebingungan.


2
+1 Sebagian besar produk ESRI, serta sebagian besar perangkat lunak lain, akan membaca nol di bidang dBase numerik sebagai nol. Itu mematikan, jadi biasanya penting untuk menggunakan pengkodean null eksplisit dalam file .dbf (yang mencakup shapefile).
whuber

4

Sebagian besar raster yang saya temui menggunakan -9999.0 untuk data floating point sebagai konvensi, dan GDAL akan menggunakan -dbl_inf saat Anda menulis kode untuk gambar yang tidak memiliki nilai nodata / dummy. 8-bit RGB biasanya akan menggunakan 0 0 0 atau 255 255 255, atau memiliki saluran alpha atau mask.

Cakupan GML 3 (yang saat ini tidak banyak dukungan, tetapi itu akan berubah ketika spesifikasi WCS 2 disahkan) memiliki beberapa nilai dummy yang direpresentasikan sebagai teks seperti "hilang" dan "ditahan".

Saya pengalaman saya standar apa pun cenderung spesifik domain atau khusus vendor. Jika Anda adalah penghasil data dan bukan konsumen, pilih angka dan tetap padanya dan pastikan konsumen Anda menyadarinya.


2

Saya akan menggunakan NaN karena operasi matematika akan menghasilkan NaN lain atau melempar pengecualian. Dengan begitu Anda dapat mendeteksi dengan jelas bahwa Anda mengacau karena Anda menggunakan nilai palsu


2
NaN akan baik-baik saja untuk perhitungan (dengan nilai floating point), tetapi Anda tidak dapat menyimpan NaN dalam banyak basis data atau format data GIS
geografi

2
+1 @geographika benar. Namun demikian, poin tentang menggunakan nilai yang akan mengacaukan perhitungan adalah sangat bagus.
whuber

untuk bilangan bulat, Anda dapat memiliki NaNs: numeric_limits <int> :: quiet_NaN ()
Ragi Yaser Burhum

Juga, rekomendasi saya adalah untuk penggunaan NaN karena berkaitan dengan nilai Z di dalam geometri. Jadi terlepas dari apakah nilainya ada dalam database atau tidak, IMHO itu harus diserialisasi dengan geometri - jadi seharusnya hanya berfungsi ...
Ragi Yaser Burhum
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.