Apakah ada upaya untuk mengganti shapefile? [Tutup]

67

Baru-baru ini saya telah menghabiskan banyak waktu mengonversi nama bidang yang sangat bagus seperti "Persen warga berusia 25 tahun ke atas dengan gelar sarjana atau lebih tinggi" menjadi hal-hal seperti "edbchogtr" untuk memenuhi batas nama bidang 10 karakter DBF.

Di utas lain ( "Keanehan" dalam spesifikasi teknis Shapefile ), geospatialpython berkomentar bahwa "Terlepas dari kekurangan format, keanehan, dan keterbatasan format shapefile tetap ada di dalam dan sekitar bidang SIG. Setiap upaya lain untuk menggantikannya terlalu membengkak untuk penyimpanan vektor sederhana atau terlalu eksklusif. "

Kegiatan ini ditambah dengan komentar Pak Lawhead membuat saya bertanya-tanya:

  • apakah ada upaya eksplisit yang pernah dilakukan untuk mengganti shapefile sebagai penyimpanan data dan format pertukaran GIS di mana-mana?
  • Apakah ada pesaing?
  • Jika ada format yang bersaing, mengapa gagal?
  • Apakah Esri menolak untuk mendukung mereka, atau apakah ceritanya hanyalah salah satu dari kelambanan teknologi?
  • Jika belum ada upaya ... mengapa tidak?

Sepertinya kita bisa melakukan sedikit lebih baik untuk diri kita sendiri, baik sebagai pengembang dan pengguna GIS.

shapefile vector canisrufus
sumber
2
@Mapperz Selain Geodatabase API yang baru dirilis, saya tidak melihat alat apa pun untuk menulis geodatabase yang gratis. Saya tidak berpikir ini bisa dianggap sebagai pengganti kecuali di bagian dunia ESRI.
canisrufus
2
Anda dapat menulis dan membaca geodatabases (melalui API) menggunakan GDAL gdal.org/ogr/drv_filegdb.html menggunakan resources.arcgis.com/content/geodatabases/10.0/file-gdb-api
Mapperz
1
Ingin melihat API Python untuk membaca / menulis File Geodatabase (setidaknya Fitur Sederhana) tanpa lisensi ArcGIS - yang akan Terbuka.
PolyGeo
2
@ PolyGeo, Anda dan semua orang :)
Ragi Yaser Burhum
3
@celenius Dari gdal.org/ogr/drv_shapefile.html "Geometri: Format Shapefile secara eksplisit menggunakan offset 32bit sehingga tidak dapat melebihi 8GB (sebenarnya menggunakan offset 32bit ke kata 16bit). Karenanya, tidak disarankan menggunakan file ukuran lebih dari 4GB. Atribut: Format dbf tidak memiliki offset di dalamnya, sehingga dapat menjadi besar secara sewenang-wenang. " Jadi Anda dapat memiliki dbf yang cukup besar, tetapi Anda harus berhati-hati dengan shp Anda yang melebihi 4GB. Maka Anda bermain dengan api.
Ragi Yaser Burhum

Jawaban:

50

Ini adalah topik yang selalu muncul. Saya mungkin tidak memiliki jawaban yang benar, tetapi saya bisa memberikan pendapat pribadi saya .

Alasan mengapa mereka didukung, dapat dikaitkan dengan beberapa karakteristik tentang mereka, jadi izinkan saya menyebutkan beberapa.

  • Pertama, ada spec . Maksudku, aku berusia awal tiga puluhan dan benda ini ada sejak aku remaja. Jadi aman untuk mengatakan bahwa spesifikasi ini telah ada selama beberapa waktu. Tentu saja, ada beberapa format lain yang juga diterbitkan, tetapi perbedaannya adalah ...

  • Ini relatif sederhana! Itu dibangun di atas Format DBF , yang pada saat itu sudah ada dan didukung secara luas di beberapa platform / OS. Sudah ada parser yang bisa membaca setengah dari format ini (bagian DBF), sehingga memudahkan mendukung penambahan tambahan. Anda punya geometri? Tentu hanya membuat serial dan menulisnya. Kamu selesai. Bandingkan ini dengan liputan ! Cobalah untuk menjelaskan kepada seseorang secara sederhana apa yang dilakukan topologi bersih . Bukan hal sepele untuk menulis liputan yang bersih secara topologis.

  • Yang paling penting, saya pikir alasan # 1 untuk shapefile untuk tetap menjadi populer adalah karena mereka didukung baik dalam sistem Open Source maupun Proprietary . SIG apa yang Anda ketahui yang tidak mendukung shapefile?!? Belum pernah terjadi.

Sebagai gantinya, kami mendengar File GeoDatabases dan Spatialite . Kedua format, sangat unggul dalam hal fungsionalitas, fleksibilitas, kecepatan, dll. Bila dibandingkan dengan Shapefile. Dengan cara mereka sendiri, mereka memiliki hal-hal tertentu yang membuat mereka lebih baik daripada satu sama lain di daerah yang berbeda, tetapi perbandingan spasial dan FileGDB tentu saja di luar cakupan pertanyaan ini.

Apakah saya pikir salah satu format ini akan menggantikan Shapefile? Tidak dalam inkarnasi mereka saat ini .

Mengapa?

Bukan karena argumen teknologi (saya memang mengatakan mereka lebih unggul dalam aspek itu), tetapi karena sesuatu yang lain: lisensi.

Jadi apa masalah mereka?

FileGDB :

FileGDB menyediakan interoperabilitas melalui API FileGDB baru. Namun demikian, API ini disediakan dalam format bineroleh ESRI. Ini bukan spesifikasi. Setelah bekerja di tim GeoDatabase di masa lalu, saya dapat memberitahu Anda, bertentangan dengan semua teori konspirasi yang memakai topi timah, ini sama sekali tidak berbahaya. Itu karena internal GeoDatabase berubah pada setiap rilis. Menerbitkan spesifikasi lengkap pada dasarnya akan memberikan semua rincian tentang bagaimana segala sesuatu seharusnya dipertahankan dan kemudian dengan hati-hati mendokumentasikan perubahan pada format dengan setiap rilis tahunan. Itu tidak masuk akal. Jadi FileGDB API, meskipun bukan spec, itu abstrak semua perubahan kecil itu. Dan sekarang bisa digunakan lintas platform! Pikiran Anda, ini adalah langkah besar ke depan! Mengingat sifat konservatif ESRI, ini jelas merupakan reaksi ke arah yang benar.

Namun, dukungan biner saja tidak membuat siapa pun di dunia Open Source terlalu senang. Bagaimana Anda kemudian memanfaatkan porting beberapa kode untuk mengatakan rasa Linux lain jika ESRI tidak mendukungnya. Kamu tidak bisa Inilah yang membuat Open Source kuat, dan sekarang, Anda tidak dapat memanfaatkan ini. Jika ESRI memutuskan untuk berhenti mendukung Debian, itu dia. Kamu selesai. Dan tidak ada yang bisa Anda lakukan untuk mengubahnya.

Spasial :

Spatialite mengagumkan karena mendapat semua fungsi gratis dari SQLite . SQLite digunakan di mana-mana. Itu ada di Ponsel Android Anda, di iPhone / iPad Anda, di Firefox, di Google Chrome, di beberapa perangkat tertanam komersial - dapat berlangsung selamanya. Untuk benar-benar membuatnya menjadi Geoformat (dan tidak hanya melakukan operasi kotak terikat bodoh), itu perlu memanfaatkan perpustakaan geometri yang sama yang digunakan PostGIS: GEOS . Sedihnya, GEOS didasarkan pada pustaka geometri lain yang bahkan lebih keren yang dikenal sebagai JTS . Semua algoritma di JTS sangat kuat, jadi apa masalahnya?

Yah, JTS dilisensikan sebagai Open Source LGPL , dan LGPL adalah lisensi viral . JTS adalah LGPL, berarti GEOS adalah LGPL, berarti spatialite yang dihubungkan secara statis dengan GEOS adalah LGPL. Ini menyebalkan. Mengapa? Tanpa menjelaskan lisensi open source terlalu banyak, saya dapat memberitahu Anda bahwa, misalnya, saya tidak dapat menggunakan spatialite pada, katakanlah, aplikasi iPhone karena itu akan membuat seluruh aplikasi saya secara otomatis open source (iOS hanya memungkinkan tautan statis). Semua jenis lisensi GPL (sewajarnya) membuat takut ESRI, sehingga mereka tidak akan menyentuhnya dengan tiang 10 kaki. Oleh karena itu, ArcGIS, sistem GIS paling populer di dunia tidak (dan mungkin tidak akan pernah) mendukung spasial secara asli. Ini secara otomatis membunuhnya sebagai format yang layak.

Dan dengan demikian kita kembali ke shapefile jelek yang didukung di mana-mana.

Perbarui :

Rupanya jawaban saya cukup kontroversial sehingga seseorang memutuskan bahwa boleh saja mengedit dan mengubah seluruh arti jawaban saya dengan bebas untuk mengemukakan pandangan mereka. Tolong jangan lakukan itu. Jika Anda tidak setuju dengan saya, itu baik-baik saja, cukup kirimkan pendapat Anda dalam jawaban yang berbeda dan biarkan komunitas memutuskan. Saya memutar kembali suntingan ke jawaban saya untuk menunjukkan makna aslinya. Saya menambahkan pembaruan ini jika Anda membaca jawaban yang diedit yang mengklaim bahwa sqlite adalah format yang layak.

Ragi Yaser Burhum
sumber
Masalah dengan SQLite / Spatialite adalah bahwa itu bukan format, itu adalah mesin basis data relasional dengan perpustakaan spasial di atasnya. Sementara itu melakukan apa yang dilakukannya dengan sangat baik, itu memaksa data untuk disimpan dalam cara relasional, yang tidak selalu merupakan cara yang paling cocok. Selain itu, kompleksitas format file SQLite ( sqlite.org/fileformat2.html ) membuatnya sulit untuk mengakses data tanpa mesin SQLite dan karenanya tidak cocok untuk menjadi format file yang terbuka & mudah diakses untuk pertukaran data. Itu tidak benar-benar dirancang untuk itu.
Igor Brejc
8
Sebenarnya, LGPL bukan lisensi viral - itu dirancang khusus untuk menghindari hal ini. Selain itu, Spatialite dilisensikan di bawah lisensi tri MPL ( sumber ), yang berarti di antara hal-hal lain Anda dapat memilih Lisensi Publik Mozilla sebagai lisensi yang paling sesuai dan beroperasi di bawah ketentuan (copyleft yang sangat lemah). Bacaan saya setidaknya adalah bahwa ESRI tidak punya alasan untuk tidak mendukung Spatialite karena lisensi - apakah mereka akan (mengingat itu bersaing di ruang yang hampir sama dengan FileGDB) adalah cerita lain ...
om_henners
3
@Ragi, Anda mencampur menggunakan perpustakaan dan porting . Tentu saja pengangkutan harus LGPL, karena ini pada dasarnya adalah karya turunan. Tetapi jika Anda menautkannya secara dinamis, itu tidak dianggap sebagai karya turunan, itu adalah "karya yang menggunakan perpustakaan" dan Anda bisa mempertahankan lisensi Anda ( en.wikipedia.org/wiki/GNU_Lesser_General_Public_License ). Jadi mengatakan "LGPL adalah viral" tanpa penjelasan tambahan tidak akurat.
Igor Brejc
2
Tetapi sekali lagi, ini adalah poin yang dapat diperdebatkan, karena Spatialite dilisensikan di bawah skema berlisensi pohon ( groups.google.com/forum/?fromgroups#!topic/spatialite-users/… ), sehingga Anda dapat memilih lisensi yang sesuai dengan yang paling Anda - MPL memungkinkan penautan statis.
Igor Brejc
2
@ bugmenot123 Baiklah, perbaiki jika mau, tapi jangan menuduh saya menyebarkan FUD tentang OS karena itu menghina. Saya telah menulis kode OS selama lebih dari satu dekade (tidak akan terkejut bahwa Anda telah menggunakan sebagian milik saya sebenarnya) dan itu bukan kata-kata kasar yang marah. Itu benar - dan masih demikian. Menautkan secara dinamis di iOS LGPL ( kerangka kerja , tepatnya, diizinkan di iOS 8). Ini tidak pernah menjadi masalah teknis, tetapi masalah hukum. Distribusi di Appstore memerlukan penandatanganan kode - dan sayangnya untuk semua pecinta OS seperti saya - LGPL adalah lisensi kabur untuk ini. Tidak ada preseden di pengadilan.
Ragi Yaser Burhum
18

Bagian SHP + SHX itu sendiri tidak begitu buruk. Masalah sebenarnya terletak pada bagian DBF. Itu bisa dilakukan dengan format baru, yang mendukung unicode dan segala jenis tipe bidang modern. Masalahnya semakin baik didukung oleh semua perangkat lunak di luar sana.

Uffe Kousgaard
sumber
6
+1 Meningkatkan pada bagian DBF sama sekali tidak sulit, baik: itu benar-benar turun untuk meyakinkan pengembang perangkat lunak untuk menyetujui sesuatu.
Whuber
1
Apakah sudah ada upaya?
canisrufus
5
Saya sering mempertimbangkan amandemen Shapefile yang hanya menggantikan file CSF UTF-8 untuk DBF. Akan mudah untuk mendukung dan memerlukan perubahan minimum untuk paket perangkat lunak yang ada.
scw
1
@canis Fox Software membuat upaya kecil (eksklusif) di akhir tahun 80-an. Setelah MS membelinya (c. 1990), itu saja. Komunitas menciptakan standar DBF 3 dan itu cukup membekukan semua pengembangan. MS merilis Access; FoxPro mati; dunia bergerak.
whuber
1
Sebaliknya, @Uffe, file CSV dapat diakses secara acak: Anda hanya perlu indeks, seperti halnya file DBF untuk pencarian yang efisien. Masalah terbesar yang saya lihat adalah bahwa perubahan kecil yang terjadi secara alami pada file CSV, seperti mengutip string atau konversi CR / LF, akan mengacaukan semua byte byte. The panjang tetap rekor struktur file DBF, meskipun kurang efisien dalam penyimpanan, tidak memiliki masalah itu.
whuber
7

Setidaknya spatialite memiliki niat, lihat misalnya presentasi ini http://www.sourcepole.ch/assets/2010/9/10/foss4g2010_spatialite.pdf

Di sisi lain, saya percaya bahwa alasan utama gagal adalah shp didukung oleh banyak aplikasi dan hanya memiliki sedikit kekurangan.

Orang lain juga berbagi pendapat ini:

Ini bukan karena proyek SpatiaLite belum memberikan alat untuk kami implementasikan, itu karena komunitas tidak peduli. SHP bekerja untuk mereka dan tidak ada alasan untuk berubah.

http://www.spatiallyadjusted.com/2010/09/16/spatialite-is-not-the-shapefile-of-the-future/

Lebih banyak pemikiran tentang file Esri, geodatabase, spatialite, dan autodesk sdf di sini: http://www.spatialdbadvisor.com/blog/121/the-shapefile-manifesto

johanvdw
sumber
Sebesar yang saya kira spatiaLite adalah, ~ 3 megabita overhead dalam fungsi, sistem referensi, dll. Yang membuatnya menjadi format pertukaran all-around yang bagus.
Scro
Sebenarnya, lisensi untuk spasial kurang dari ideal - tidak ada hubungannya dengan alat.
Ragi Yaser Burhum
@ Scro, 3 megabyte terlalu besar? Jelas tidak terlalu besar untuk desktop. Anda harus mempertimbangkan perangkat seluler. Juga, apakah ada API Spasial lain, dengan fungsionalitas yang setara, dalam ukuran lebih kecil dari Spatialite?
klewis
@ KLewis - itu tidak terlalu besar, itu hanya sangat tidak efisien ketika Anda menganggap ada banyak dataset kecil (pikirkan <200kb) di luar sana. Itu banyak overhead, terutama mengingat kenyataan bahwa, setelah diterima, Anda biasanya akan meninggalkan setiap dataset dalam file 3MB itu, atau menggulungnya ke database yang sudah ada. Untuk lebih jelasnya, saya <3 spatiaLite - tetapi kita berbicara tentang transmisi data, di mana semacam flat file / xml / wkb akan jauh lebih efisien.
Scro
6

Esri telah mempromosikan File Geodatabases selama beberapa tahun sekarang sebagai pengganti shapefile.

Baru-baru ini mereka telah menyediakan API yang menyembunyikan keanehan.

Kirk Kuykendall
sumber
Saya belum banyak bekerja dengan geodatabases. Wikipedia mengatakan itu adalah standar "tertutup", mis. Spesifikasi geodatabase belum dipublikasikan. Tampaknya sulit untuk mendapatkan adopsi yang sangat luas tanpa menerbitkan format internal. Sementara saya terlalu muda untuk mengetahui sejarah, saya kira bahwa sebagian shapefile begitu populer karena bagian publik dari spesifikasi. API memang terlihat seperti langkah yang baik.
canisrufus
1
@dapatkah Anda benar. Pada saat itu tidak ada yang akan mengadopsi shapefile kecuali bahwa ESRI secara khusus mempromosikan mereka sebagai format pertukaran data GIS terbuka. Bahkan dengan perangkat lunak terbatas yang tersedia pada saat itu, dengan rilis ESRI dari spesifikasi .shp / .shx yang jelas (dan komitmen untuk berpegang teguh pada itu), itu menjadi masalah hanya beberapa jam kerja untuk menulis kode untuk membaca dan tulis shapefile: tidak perlu rekayasa balik.
whuber
Selama API adalah gumpalan biner kotak hitam, FGDB tidak akan melihat adopsi yang sama dengan SHP. Bahkan jika Esri meyakinkan semua pelanggan mereka untuk beralih ke FGDB dari SHP, API tidak benar-benar kompatibel dengan open source.
dericke
3

Dialek XML, seperti GML, jelas tidak dioptimalkan untuk mengoperasikan kumpulan data besar, tetapi, dapat digunakan sebagai format pertukaran antar perangkat lunak atau antar platform.

Saya tidak percaya ada masalah dengan lisensi (lihat posting Ragi Yaser Burhum tentang karakteristik virus Spatialite) dan cukup mudah untuk mengadaptasi parser yang ada jika diperlukan.

Stéphane Henriod
sumber
1
Saya pikir itu tidak disebutkan hanya karena alasan Anda mengemukakan, bahwa itu tidak dioptimalkan untuk kumpulan data besar. XML membengkak. Format yang disebutkan di sini adalah biner, tempat GML menyimpan poin sebagai string. Ukurannya bisa lebih dari urutan besarnya berbeda.
canisrufus
3
Canisrufus benar. Ada beberapa masalah dengan GML. Infoset dapat dinavigasi menggunakan XPath, tetapi siapa pun yang telah mencoba menerapkan pengindeksan spasial di atas XML akan memberi tahu Anda betapa irasionalnya hal ini dan seberapa buruk peta itu ke database relasional tradisional. Tanpa masuk ke banyak detail, jika sesuatu yang mendasar seperti pengindeksan dan pencarian menjadi tidak mudah, formatnya membengkak, dan pada dasarnya mengharuskan Anda untuk memiliki seluruh dataset dalam memori untuk melakukan apa pun dengan itu, maka ini bukan pilihan yang baik.
Ragi Yaser Burhum
4
xml membengkak saat disimpan sebagai teks biasa. Ada pustaka xml biner xml yang tersedia secara bebas (baik gratis maupun gratis) yang dapat berfungsi sebagai pengganti pengganti bagi pembaca xml, memberi orang kebebasan untuk memanfaatkan keterbacaan manusia xml dan efisiensi kinerja serta penyimpanan biner yang tersedia . Satu-satunya alasan yang dapat saya pikirkan untuk itu tidak pernah diangkat secara besar-besaran adalah seperti yang johandvw amati di atas : tidak ada yang peduli, .shp telah "cukup baik" sebagaimana adanya.
matt wilkie
1

Hanya untuk datang pada ini dari perspektif yang berbeda, saya tidak yakin penggunaan "Persen warga usia 25 dan lebih dengan gelar sarjana atau lebih tinggi" adalah nama bidang yang sangat baik. Meskipun memadukan spasi dan apostrof dapat ditangani, jika Anda menulis kode atau kueri, kemungkinan besar bug akan muncul.

Menurut pendapat saya, masa depan distribusi data spasial harus fokus pada web dan layanan web, dan spesifikasi WFS (yang menggunakan GML) terbuka dan dibuat. GeoJSON lebih kecil, dan bisa lebih mudah digunakan dalam JavaScript. Namun dengan kompresi ukurannya sebanding.

Saya juga ingin memberikan suara untuk Personal Geodatabases ESRI . Ini mungkin format Microsoft yang sering difitnah, tetapi mendukung ODBC, kueri SQL, tampilan, dan memungkinkan non-pengembang untuk membuat formulir entri data yang mudah, dan menyertakan setidaknya beberapa tingkat pemeriksaan integritas data (tipe data, panjang, nilai unik) .

geografi
sumber
Itu poin yang valid. Apa yang baik tentang mereka adalah bahwa dengan pengetahuan bahasa Inggris, orang dapat mengetahui apa arti bidang tersebut.
canisrufus
Itu benar-benar peran dari dataset metadata. Shapefile dapat menggunakan file XML dengan nama yang sama untuk menyimpan ini.
geografi