Eric Lontong

Berdasarkan pertanyaan ataupun komentar yang ada di tulisan-tulisan sebelumnya, aku melihat belum banyak yang mengerti perangkat dasar baik istilah, penggunaan maupun dependensi (keterkaitan) dalam geodatabase server menggunakan PostGIS.

Definisi berikut diberikan mungkin tidak akan sama persis dengan yang ditemukan di wikipedia namun aku coba untuk mengkombinasikan dengan bahasa awam untuk lebih mempermudah pengertian saja. Apabila terdapat kesalahan ataupun dibutuhkan koreksi, tambahkan saja di komentar.

Yang pasti, urutan-urutan di bawah ini juga menunjukkan ketergantungan dari yang teratas dan kaitannya akan lebih diperjelas lagi di dalam deskripsinya.

PostgreSQL Server

PostgreSQL, atau yang sering disingkat menjadi pgsql dan pg* untuk yang berhubungan dengannya, merupakan sistem basis data open source yang sangat handal dan mampu menangani objek data yang sangat besar. Banyak yang mempercayai PostgreSQL saat ini menjadi sistem database yang paling baik dan efektif, tentu saja tidak terlepas dari harga yang gratis dan mampu bekerja sama baiknya di hampir seluruh sistem operasi saat ini, Linux, UNIX (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64), dan Windows. Bahkan berdasarkan kutipan di situs resminya, PostgreSQL mampu menampung objek data binari yang sangat besar seperti gambar atau foto, suara atau lagu, bahkan video.

Berikut adalah batasan yang mereka deskripsikan tergantung versi database server Anda:

Indahnya dunia opensource tentu saja tidak terlepas dari fleksibilitas dan dukungan pengembangan beberapa extension dari kemampuan dasar. Kompabilitas penuh terhadap standar bahasa SQL maupun bahasa pemrograman C menciptakan beberapa fungsi atau prosedur yang sangat menarik dan niche untuk beberapa kebutuhan. Salah satu bahasa yang digunakan adalah PL/SQL (atau PG/PLSQL pada kasus ini). Bahasa ini yang patut dicermati selanjutnya untuk kasus pembahasan tulisan ini.

PostGIS

Secara default, PostgreSQL merupakan Sistem Database Tekstual.
PostGIS lah yang berfungsi untuk menambahkan fungsi objek geometri (Geo-Object) pada PostgreSQL sebagai Sistem Database Spasial. PostGIS sepenuhnya patuh pada aturan OpenGIS/OGC untuk sintaks geometri pada SQL dan telah terverifikasi penuh terhadap profil tipe dan fungsi terkait. Dengan demikian, sintaks SQL ini akan Anda temukan sama dan dapat bekerja untuk ArcGIS SDE dan Oracle Spatial Database juga. Ya, sebagai informasi saja, ketiga vendor inilah yang aktif pada Open Geospatial Consortium (OGC) sebagai organisasi pembentuk standarisasi bagi dunia spasial.

PostGIS juga merupakan produk dari hasil proyek open source yang gratis dan dapat digunakan dalam kegiatan non-profit maupun komersial. Dengan dukungan penuh terhadap berbagai bentuk/format fitur geometri, point, line, polyline, polygon, multipolygon bahkan Feature Collections, dan format geodata (WKT,WKB,XML,dll), PostGIS menjadi salah satu kekuatan sistem geodatabase yang paling banyak digunakan saat ini selain ArcGIS SDE (format shp/dbf). PostGIS juga mendukung sistem multi projections (datum) dalam satu database.

Namun yang perlu diingat, selain sangat bergantung (tentu saja) pada PostgreSQL server, ekstensi PostGIS ini juga sangat bergantung pada kemampuan sistem operasi secara keseluruhan. Libproj, OGR dan GDAL merupakan beberapa contoh ketergantungan PostGIS untuk dapat bekerja dengan baik.

PostGIS menyimpan data vektor geo-objek ini dalam bentuk spatial binary (biasanya pada kolom the_geom, dapat dikustomisasi). Dan karena datanya yang bisa sangat besar, sangat disarankan untuk mengaktifkan juga ekstensi GiST (Generalized Search Tree). Ekstensi ini berfungsi untuk melakukan indexing pada rekod tabel dengan metode yang lebih kompleks untuk membantu proses lanjutan pada data geometri, update, searching, filtering, dan fungsi PostGIS yang lebih rumit.

PostGIS terus dikembangkan dan saat ini telah mendukung beberapa fungsi/prosedur berdasarkan PG/PLSQL untuk memproses kebutuhan-kebutuhan standar GIS seperti buffering, crossing, penghitungan luas area, panjang baris, dsb. Silakan baca manual PostGIS untuk lebih lengkap fungsi yang telah didukung sesuai dengan versi yang Anda miliki. Ke depan mereka juga merencanakan untuk dukungan 3D topografi, struktural sistem komplek, yang akan sangat menarik untuk ditunggu. Dan jangan lupa, bila ada rejeki dan mempunyai proyek menggunakan PostGIS ini, dukung pengembangan mereka dengan memberikan donasi seiklasnya ya

pgRouting

pgRouting merupakan proyek (lagi-lagi) open source dari PostLBS untuk menambahkan fungsi routing (penghitungan jarak terpendek dari data polyline) pada PostGIS berdasarkan bahasa prosedural PG/PLSQL. Menggunakan metoda yang sama kita lihat pada perangkat lunak berbayar seperti Arc* dan MapInfo, PostLBS memperkuat pgRouting ini dengan metoda Dijkstra, A* (A-star), Shooting Star, TSP (Travelling Sales Person) dan DDC (Driving Distance Calculation) untuk membedakan jalur yang dapat ditempuh oleh kendaraan ataupun jalan kaki, sama seperti opsi yang terdapat pada routing Google Maps/Earth.

Terlepas dari validasi data yang baik atau tidak, pgRouting mampu memberikan hasil kalkulasi yang cukup akurat. Sayangnya, untuk beberapa geodata yang ada di Indonesia, proses digitasi data tidak dilakukan dengan validasi yang cukup baik. Secara harafiah, data vektor merupakan data yang memiliki besaran dan arah tertentu. Namun untuk beberapa data di Indonesia, vektorisasi ini tidak melalui proses Quality Control yang cukup baik sehingga tidak memiliki arah yang sesuai dengan data aslinya. Misalnya begini, jalan A  memiliki cabang menuju B dan C sedangkan BC terhubung oleh arah B menuju C. Sedangkan ketersediaan data setelah digitasi menghasilkan A ke B, A ke C, dan C ke B. Ilustrasinya:

Untuk hasil routing menggunakan pgDijkstra dapat dilihat di tulisan sebelumnya, yang sangat bergantung pada kualitas data ini. Ini jelas akan mempengaruhi untuk dunia yang sebenarnya dengan routing untuk dua arah akan sangat sulit dilakukan dan dipertanggungjawabkan keakuratannya.

Catatan tambahan lainnya, berdasarkan hasil pengalaman, tipe PostGIS tampaknya tidak terlalu bersahabat untuk yang ingin melakukan clean update pada data geometri. Misalnya pada saat development Anda menggunakan PostGIS versi 1.2.1 sedangkan production server menggunakan versi 1.2.5, tidak dapat melakukan backup sebagai SQL dari 1.2.1 dan memasukkan secara langsung ke server v1.2.5. Data tidak akan valid.
Tidak mengetahui secara detail bagaimana perkembangan saat ini, namun untuk beberapa pekerjaan, aku selalu melakukan konversi shapefile ke sql untuk data yang sama dan proses update untuk data tekstual atribut lainnya. Ini sangat penting untuk dilakukan karena setiap kali kita melakukan konversi dari format yang satu ke format lainnya, kualitas data akan berkurang.

pgAdmin

Tidak terlalu bergantung pada versi database server, pgAdmin, apapun dan siapapun yang membuatnya, sama sekali tidak ada hubungannya dengan kemampuan PostgreSQL dan PostGIS itu sendiri. Ini lebih sebagai tools pembantu untuk mempermudah penggunaan saja. Tanpa tools ini, aplikasi ataupun sistem dapat bekerja dengan baik. Namun terkait dengan kemampuan spasial geodatabase server, sangat bijak untuk memilih perangkat pembantu yang cukup powerful.

Bagian ini aku serahkan kepada masing-masing pihak saja. Sehari-hari, aku sendiri lebih banyak berkecimpung dengan phpPgAdmin untuk berbasis web (biasanya di server) dan pgAdmin III sebagai tool bawaan installer postgresql di Windows . Sebenarnya ada tambahan plugin di phpPgAdmin untuk pgsql yang sudah diperkuat oleh PostGIS dan terdapat mapserver dengan nama proyek phpPgGIS (silakan dicari sendiri di sourceforge.net) namun sayangnya tidak dikembangkan sesuai dengan perkembangan ketiganya (PostGIS, MapServer, phpPgAdmin).
Untuk tool lainnya seperti PostgreSQL Maestro ataupun Navicat, tidak terlalu mendalam untuk mengopreknya.

Bagaimana, sudah mengerti atau masih ada pertanyaan?