Apa tujuan PostGIS di PostgreSQL?

PostgreSQL sudah mendukung tipe data spasial, operator dan pengindeksan.

Apa yang PostGIS sediakan tepat yang membuatnya perlu ada sebagai ekstensi untuk PostgreSQL?

Mengapa kita semua tidak menggunakan fungsionalitas spasial PostgreSQL saja?

— Zeruno
sumber

PostGIS yang menyediakan tipe data spasial, operator, dan pengindeksan ...

— DPSSpatial

Tidak, dia berbicara tentang tipe geometri PostgreSQL asli.

— Evan Carroll

Jawaban singkatnya adalah PostGIS (sekarang) 10x berfungsi seperti tipe PgSQL. Jawaban panjang, yang mencakup pertanyaan "mengapa mengembangkan tipe baru, dan tidak hanya memperbaiki yang sudah ada" dibahas di bawah ini.

— Paul Ramsey

Hal yang sama terjadi dengan kerangka Java Spring. Java memiliki kekurangan / fitur yang hilang. Pegas memperbaiki banyak kekurangan Java dan menambahkan fitur yang bermanfaat. Java menyalin fitur + perbaikan Spring. Orang-orang kemudian bertanya mengapa Spring ada ...

— Neil McGuigan

Jawaban:

Jika Anda melukai kembali alam semesta hingga awal tahun 2001, dan tidak hanya membiarkan para penemu PostGIS melihat masa depan, tetapi juga membiarkan PSC PgSQL melihat masa depan, mungkin PostGIS akan menjadi serangkaian tambalan pada PgSQL. Tetapi paling tidak, jika kita memulai sebagai tambalan ke inti, hal pertama yang harus kita hadapi adalah:

area inti PgSQL tidak mendukung lubang, tetapi model GIS benar-benar menginginkan lubang, dapatkah kita mengubahnya?

Dan inti PgSQL akan mengatakan: "tidak, tentu saja tidak, area memiliki semantik yang sudah dipahami dengan baik dan kita tidak bisa membuat perubahan mundur yang tidak kompatibel seperti itu".

Sebagai pengembang non-inti, PostGIS mampu melumpuhkan rilis bulanan dan 6-bulanan selama beberapa tahun sementara inti PgSQL menurun seiring dengan rilis tahunan dan lebih lama. Kami juga dapat menambahkan fitur apa pun yang kami inginkan, kapan saja, karena kami memiliki hak komitmen dalam proyek kami, tetapi mendapatkan hak komitmen dalam PgSQL membutuhkan waktu yang sangat lama.

Pada saat PostGIS mendemonstrasikan nilai eksternal yang cukup sehingga inti PgSQL melihat ke atas dan berkata pada diri mereka sendiri "huh, yang akan menyenangkan untuk memiliki inti sebagai fitur tambahan", sudah ada begitu banyak kode dengan standar dan gaya yang berbeda dari PgSQL (belum lagi di bawah lisensi yang tidak kompatibel) bahwa gagasan penggabungan tidak benar-benar mungkin.

Alih-alih, PostGIS telah menjadi contoh kanonik dari Ekstensi Kompleks Sungguh Besar yang membantu PgSQL tetap modular dan dapat diperluas. "Bagaimana ini akan mempengaruhi sesuatu seperti PostGIS" adalah pertanyaan yang sering ditanyakan ketika core PgSQL mengevaluasi beberapa perubahan. Ini juga hal yang baik, mungkin tidak sebagus PostGIS yang menjadi bagian dari inti, tetapi cukup baik.

Ada alasan lain, seperti daftar panjang ketergantungan PgSQL inti akan benci untuk melihat, konsistensi kode umumnya lebih rendah dan kebersihan API yang mereka akan putus asa untuk meningkatkan, dan terus dan terus. Bahkan pada saat pembuahan, PostGIS terlalu besar untuk tidak bisa ditelan oleh PgSQL.

— Paul Ramsey
sumber

Juga ... PostGIS adalah C ++. Ini akan menjadi showstopper untuk penggabungan PostgreSQL. Apakah itu seharusnya atau tidak . Ketergantungan juga akan menghentikannya sepenuhnya - GDAL? Ha! Saya bahkan tidak bisa mendapatkan inti untuk setuju bergantung pada Perl> 5.8.0. Kecepatan pengembangan lambat walaupun Anda memiliki hak komitmen; komuter tidak hanya mendapatkan gratis untuk semua barang dorong di pohon, mereka harus melalui tinjauan kode, dan mendapatkan perubahan besar dalam waktu berbulan-bulan atau bertahun-tahun. Ada manfaat kualitas kode tetapi tentu tidak bergerak cepat.

— Craig Ringer

Ini adalah masalah khusus yang inti Pg terus menciptakan kembali hal-hal untuk menghindari tergantung pada lebih banyak perpustakaan eksternal. Karena itu berarti $ ancient_unix_42 dengan $ odd_vendor_compiler di $ dead_architecture harus mendukungnya, semua anggota buildfarm perlu memperbarui, dll. Itu salah satu masalah dengan menjadi dewasa dan stabil kurasa.

— Craig Ringer

@CraigRinger Mengapa menurut Anda PostGIS adalah C ++? Itu adalah penghinaan :-)

— Nicklas Avén

Itu ... bukan? Aku bisa bersumpah. Tapi tentu saja itu tidak terlihat seperti itu. Salahku. Saya sebenarnya suka (sedang dan terkendali) penggunaan C ++.

— Craig Ringer

Untuk jangka waktu tertentu PostGIS memiliki beberapa potong C ++ untuk membuat pengikatan pada GEOS. Begitu GEOS menambahkan API C-nya sendiri, potongan-potongan itu dihapus dan PostGIS menjadi "murni" C.

— Paul Ramsey

Itu tidak benar, PostgreSQL tidak mendukung tipe data spasial. Ini mendukung tipe geometris. Ini sangat baik untuk beberapa hal, tetapi mereka benar-benar terpisah dari sistem koordinat dunia nyata. Jenis asli

tidak memiliki ID Sistem Referensi Spasial / SRSID.
tidak pernah dapat diproyeksikan kembali.
bahkan pada spheroid, mereka menyediakan fungsionalitas yang sangat terbatas.
Mereka tidak standar.
Mereka tidak memberikan indeks GIST.

Memperbarui

Sedangkan untuk pertanyaan indeks, ada di FAQ

Mengapa indeks PostgreSQL R-Tree tidak didukung?

Versi awal PostGIS menggunakan indeks PostgreSQL R-Tree. Namun, PostgreSQL R-Trees telah sepenuhnya dibuang sejak versi 0.6, dan pengindeksan spasial disediakan dengan skema R-Tree-over-GiST.

Pengujian kami telah menunjukkan kecepatan pencarian untuk R-Tree dan GiST asli agar sebanding. Native PostgreSQL R-Tree memiliki dua batasan yang membuatnya tidak diinginkan untuk digunakan dengan fitur GIS (perhatikan bahwa keterbatasan ini disebabkan oleh implementasi R-Tree asli PostgreSQL saat ini, bukan konsep R-Tree secara umum):

Indeks R-Tree di PostgreSQL tidak dapat menangani fitur yang berukuran lebih dari 8K. Indeks GiST dapat, menggunakan trik "lossy" untuk mengganti kotak pembatas untuk fitur itu sendiri.

Indeks R-Tree di PostgreSQL tidak "null safe", jadi membangun indeks pada kolom geometri yang berisi geometri nol akan gagal. [Indeks GiST tidak aman]

— Evan Carroll
sumber

Bisakah Anda memperluas poin terakhir Anda - yang tentang indeks GiST? PostgreSQL menyediakan R-Tree dan sekarang menyediakan ini melalui indeks GiST jadi saya bingung tentang hal itu.

— Zeruno

diperbarui dengan teks langsung dari faq.

— Evan Carroll

Inti API adalah hal PostgreSQL disediakan oleh akses / gist.h . Anda dapat melihatnya digunakan di PostGIS

— Evan Carroll

Walaupun PostGIS memang memiliki implementasi rtree-on-gist sendiri, namun sangat mirip dengan yang digunakan oleh PgSQL untuk dukungan intinya terhadap objek grafis dengan alasan sederhana yang awalnya kami salin.

— Paul Ramsey

@Zeruno, Tidak, memodifikasi splitter rtree di PgSQL tidak akan mengubah perilaku PostGIS, karena kita punya kita sendiri, di gserialized_gist_picksplit_2d (). Anda tidak akan tidak jauh berbeda dari yang PgSQL, jika sama sekali.

— Paul Ramsey

PostGIS adalah extender database spasial untuk database relasional- postgreSQL . Ia menambahkan dukungan untuk objek geografis yang memungkinkan kueri lokasi dijalankan di SQL.
SELECT superhero.name
FROM city, superhero
WHERE ST_Contains(city.geom, superhero.geom)
AND city.name = 'Gotham';
Selain kesadaran lokasi dasar, PostGIS menawarkan banyak fitur yang jarang ditemukan di database spasial lain yang bersaing seperti Oracle Locator / Spatial dan SQL Server. Lihat Daftar Fitur PostGIS untuk lebih jelasnya.

Daftar Fitur PostGIS memperluas kemampuan itu juga:

PostGIS menambahkan tipe tambahan (geometri, geografi, raster, dan lainnya) ke database PostgreSQL . Ini juga menambahkan fungsi, operator, dan peningkatan indeks yang berlaku untuk tipe spasial ini. Fungsi tambahan ini, operator, binding indeks dan tipe menambah kekuatan inti DBMS PostgreSQL, menjadikannya sistem manajemen basis data spasial yang cepat, banyak fitur, dan kuat.

Daftar Fitur

Seri PostGIS 2+ menyediakan:

Fungsi pemrosesan dan analitik untuk data vektor dan raster untuk penyambungan, dicing, morphing, reklasifikasi, dan pengumpulan / penyatuan dengan kekuatan aljabar peta raster SQL untuk pemrosesan raster berbutir halus

Proyeksi ulang spasial Fungsi callable SQL untuk data vektor dan raster Dukungan untuk mengimpor / mengekspor data vektor shapefile ESRI melalui baris perintah dan alat yang dikemas GUI dan dukungan untuk lebih banyak format melalui alat Sumber Terbuka pihak ketiga lainnya

Baris perintah terpaket untuk mengimpor data raster dari banyak format standar: GeoTiff, NetCDF, PNG, JPG

Rendering dan mengimpor fungsi dukungan data vektor untuk format teks standar seperti KML, GML, GeoJSON, GeoHash dan WKT menggunakan SQL Rendering data raster dalam berbagai format standar GeoTIFF, PNG, JPG, NetCDF, untuk beberapa nama menggunakan SQL

Fungsi raster / vektor SQL callable yang mulus untuk ekstrusi nilai piksel berdasarkan wilayah geometris, menjalankan statistik berdasarkan wilayah, memotong raster berdasarkan geometri, dan vektorisasi raster, dukungan objek 3D, indeks spasial, dan fungsi. Dukungan topologi jaringan Packer Loader / Geocoder / Reverse Geocoder / memanfaatkan data US Census Tiger

Selanjutnya untuk poin / bagian yang disebutkan sudah ada di posting ini. Saya akan menambahkan sebagaimana disebutkan di situs web PostGIS Bagaimana cara kerjanya

Karena PostGIS ada di C, ia dapat menggunakan pustaka lain di C dan C ++, dan ia melakukannya dengan bebas. PostGIS tergantung pada:

GEOS untuk banyak algoritma pemrosesan geometri

Proyeksi.4 untuk fungsi proyeksi ulang koordinat

GDAL untuk pemrosesan raster dan dukungan format

LibXML2 untuk parsing XML

JSON-C untuk penguraian JSON

SFCGAL untuk dukungan 3D yang diperluas dan algoritma geoproses tambahan

— Whyzar
sumber