Otomatisasi QGIS: 1 Tugas, 4 Metode, Diuji Waktunya di 2 Kota

Anda bisa mengotomatisasi alur kerja QGIS yang berulang dengan empat cara: Batch Processing untuk satu tool di banyak file, Graphical Modeler untuk rangkaian tool yang akan Anda jalankan ulang, skrip PyQGIS untuk loop dan kontrol yang presisi, atau AI agent di dalam QGIS saat Anda ingin hasilnya dari satu pesan dalam bahasa sehari-hari.

Tutorial yang saya baca mengajarkan salah satu dari empat cara itu secara terpisah dengan contoh sederhana, dan tidak ada yang menguji apa yang terjadi saat alur kerja dijalankan untuk kedua kalinya di kota baru. Pada 7 November 2026, saya mengambil satu tugas multi-langkah (luas area terbangun per distrik dari 180.602 bangunan OpenStreetMap di Bielefeld, Jerman), menjalankannya dengan keempat metode di QGIS 3.44.15, lalu menjalankan ulang keempatnya di Münster (135.577 bangunan, 6 distrik). Semua metode lolos di kedua kota, meski satu run Graphical Modeler awalnya selesai dengan status "OK" sambil menulis 1.058 poligon, bukan 10.

Apa itu otomatisasi QGIS?

Otomatisasi QGIS berarti menjalankan sebuah processing tool atau rangkaian tool pada beberapa layer tanpa mengklik setiap dialog secara manual. Di balik setiap metode ada framework QGIS Processing, mesin yang sama yang menjalankan Processing Toolbox. Karena tool-nya identik, baik dipanggil dari tabel batch, diagram Graphical Modeler, skrip Python, maupun tool command-line qgis_process, memilih metode otomatisasi sebenarnya berarti memilih cara merangkai tool-tool itu dan file apa yang ingin Anda simpan di disk untuk bulan depan.

Tugas dan data yang kami uji

Saya memilih pekerjaan yang sering muncul dalam perencanaan kota dan konsultansi: untuk setiap distrik kota, potong bangunan sesuai batas distrik, hitung jumlah footprint, jumlahkan luasnya dalam meter persegi, buat buffer 25 m di sekitar bangunan yang sudah dipotong dan gabungkan (dissolve) menjadi satu poligon area terbangun, lalu simpan satu GeoPackage yang rapi dengan satu baris per distrik.

Jika sebuah bangunan melintasi batas distrik, bangunan itu dipotong dan dihitung sekali di setiap distrik yang disentuhnya. Kedua kota memakai data OpenStreetMap dari ekstrak PBF BBBike (ODbL, kontributor OpenStreetMap), diproyeksikan ulang ke EPSG:25832 (ETRS89 / UTM zone 32N) untuk semua pengukuran.

• Kota 1, Bielefeld: 180.602 poligon bangunan di 10 distrik (admin_level=9), menghasilkan 115.002 potongan bangunan. Dua bangunan OSM mentah memiliki geometri tidak valid dan diperbaiki sekali dengan Fix geometries agar keempat metode mulai dari file bersih yang sama.
• Kota 2, Münster (run ulang): 135.577 poligon bangunan di 6 distrik, menghasilkan 116.382 potongan.

Sebelum menjalankan keempat metode, saya menulis referensi independen dengan pemanggilan geometri PyQGIS biasa (QgsSpatialIndex, geometry.intersection(), unaryUnion(), dan buffer(25, 5), tanpa memanggil algoritma Processing) dan menyimpan skrip pemeriksa. Sebuah metode dinyatakan lolos hanya jika menghasilkan satu GeoPackage dengan layer poligon built_up dalam EPSG:25832, jumlah bangunan per distrik yang tepat, luas footprint dalam selisih 0,5% dari referensi, hektar area terbangun dalam selisih 1%, dan tanpa edit manual sesudahnya.

Metode 1: Batch Processing

Setiap tool di Processing Toolbox memiliki tombol Run as Batch Process di pojok kiri bawah dialognya. Tombol ini mengubah dialog menjadi spreadsheet, dengan setiap baris berarti satu kali eksekusi tool tunggal itu.

Untuk tugas kami, batch processing menangani Clip per distrik dan Buffer per distrik dengan rapi, karena kedua langkah itu mengulang algoritma yang persis sama di 10 distrik. Namun, ia tidak bisa menyelesaikan seluruh alur kerja sekaligus, karena Batch Processing hanya menjalankan satu tool dalam satu waktu dan meninggalkan 10 layer output terpisah yang masih harus Anda gabung dan sambungkan kembali.

Dari 9 run (8 algoritma berbeda), total waktu eksekusi tool di Bielefeld adalah 62,0 detik, dan setiap jumlah per distrik cocok dengan referensi. Di Münster, waktu tool turun menjadi 39,8 detik untuk 6 distrik, tetapi saya harus menyusun ulang tabel batch 6 baris dan menjalankan ulang kesembilan langkah secara manual. Jika alur kerja Anda berupa rangkaian tool yang berbeda, bukan satu tool yang diulang di 50 file, Batch Processing bukan bentuk yang tepat.

Metode 2: Graphical Modeler

Graphical Modeler (Processing > Graphical Modeler) memungkinkan Anda merangkai beberapa Processing tool menjadi satu diagram dan menyimpannya sebagai file .model3. Setelah dibuat, model itu muncul di Processing Toolbox seperti tool bawaan lainnya.

Anda mungkin mengira perlu loop atas distrik di dalam Modeler, tetapi ternyata tidak. Dengan menjalankan Intersection antara bangunan dan distrik terlebih dahulu, setiap potongan bangunan mewarisi atribut name distriknya, sehingga Aggregate dan Dissolve yang dikelompokkan menurut name menghasilkan satu baris per distrik dalam sekali jalan. (Anda juga bisa memakai spatial join jika tidak perlu memotong bangunan tepat di garis batas distrik.)

Menjalankan model dari dialognya di Bielefeld memakan waktu 62,7 detik dan lolos semua pemeriksaan. Lebih baik lagi, file .model3 yang persis sama berjalan dari terminal macOS tanpa membuka jendela QGIS melalui qgis_process dalam 44,5 detik.

Manfaat sebenarnya terlihat saat run ulang di Münster. Saya membuka dialog model yang sama, memilih muenster_buildings dan muenster_districts di dua drop-down, lalu mengklik Run. Selesai dalam 67,2 detik tanpa satu pun perubahan pada model.

Metode 3: Skrip PyQGIS di Python Console

Jika Anda terbiasa dengan Python, skrip di Plugins > Python Console > Show Editor memberi Anda loop for sungguhan, input sebagai variabel di bagian atas file, dan tanpa langkah penggabungan.

Berikut skrip 38 baris (built_up_by_district.py) yang saya jalankan di QGIS 3.44.15, dengan path file dipersingkat:

# Built-up area by district. Run in the QGIS Python console (Plugins > Python Console > Show Editor > Run).
# Change the first five lines for a new city.
BUILDINGS = "data/bielefeld_buildings.gpkg"
DISTRICTS = "data/bielefeld_districts.gpkg"
NAME_FIELD = "name"
BUFFER_M = 25
OUT = "out/script/built_up_script.gpkg"

import processing
from qgis.core import (QgsVectorLayer, QgsCoordinateReferenceSystem, QgsFeature, QgsField, QgsFields, QgsGeometry)
from qgis.PyQt.QtCore import QVariant

crs = QgsCoordinateReferenceSystem("EPSG:25832")   # metric, Germany
def run(alg, **p):
    return processing.run(alg, p)["OUTPUT"]

buildings = run("native:reprojectlayer", INPUT=BUILDINGS, TARGET_CRS=crs, OUTPUT="memory:")
districts = run("native:reprojectlayer", INPUT=DISTRICTS, TARGET_CRS=crs, OUTPUT="memory:")

result = QgsVectorLayer("MultiPolygon?crs=EPSG:25832", "built_up", "memory")
result.dataProvider().addAttributes([QgsField("district", QVariant.String), QgsField("building_count", QVariant.Int),
                                     QgsField("building_area_m2", QVariant.Double), QgsField("built_up_ha", QVariant.Double)])
result.updateFields()

for d in districts.getFeatures():
    one = run("native:extractbyexpression", INPUT=districts, EXPRESSION=f"$id = {d.id()}", OUTPUT="memory:")
    clipped = run("native:clip", INPUT=buildings, OVERLAY=one, OUTPUT="memory:")
    area = sum(f.geometry().area() for f in clipped.getFeatures())
    built_up = run("native:buffer", INPUT=clipped, DISTANCE=BUFFER_M, SEGMENTS=5, DISSOLVE=True, OUTPUT="memory:")
    geom = next(built_up.getFeatures()).geometry()
    f = QgsFeature(result.fields())
    f.setGeometry(geom)
    f.setAttributes([d[NAME_FIELD], clipped.featureCount(), area, geom.area() / 10000])
    result.dataProvider().addFeature(f)
    print(d[NAME_FIELD], clipped.featureCount(), round(area), round(geom.area() / 10000, 1))

processing.run("native:savefeatures", {"INPUT": result, "OUTPUT": OUT, "LAYER_NAME": "built_up"})
print("saved", OUT)

Skrip ini menyimpan setiap layer perantara di memori dan melakukan loop atas distrik, dan sejauh ini menjadi metode tercepat (kami tidak memprofilkan penyebabnya). Skrip menyelesaikan Bielefeld dalam 8,1 detik dan cocok dengan referensi independen hingga 0.00% di setiap distrik.

Untuk menjalankannya ulang di Münster, saya mengubah tiga baris di bagian atas (BUILDINGS, DISTRICTS, dan OUT) lalu mengklik tombol play hijau Run Script. Selesai dalam 7,4 detik. Jika Anda ingin mempelajari cara kerja processing.run secara detail, lihat panduan PyQGIS kami.

Perbandingan keempat metode di kedua kota

Berikut hasil pengukuran kami untuk keempat metode pada 7 November 2026:

Semua metode cocok dengan jumlah bangunan dan luas footprint bangunan (building_area_m2) referensi hingga 0.00%. Selisih +0.08% pada built_up_ha untuk Batch Processing dan Graphical Modeler berasal dari $area di Refactor fields yang mengukur pada ellipsoid proyek, sedangkan skrip dan referensi memakai geometry().area() planar dalam EPSG:25832.

Apa yang rusak di sepanjang jalan (termasuk jawaban salah yang diam-diam)

Tutorial jarang menunjukkan run yang gagal, jadi saya mencatat setiap error sepanjang hari. Kegagalan yang paling menakutkan bukan crash atau banner error merah: melainkan run Graphical Modeler yang melaporkan sukses tetapi memberi output yang salah.

Saat pertama kali menjalankan model secara headless sebelum membatasi field di node Intersection, log mencetak:

Model processed OK. Executed 8 algorithm(s) total in 84.548 s.

Tanpa error, tanpa peringatan. Saat saya memeriksa GeoPackage output, built_up berisi 1.058 poligon, bukan 10.

Penyebabnya: bangunan OpenStreetMap punya kolom name sendiri (nama toko, sekolah, atau gereja), dan layer distrik juga punya kolom name. Saat Intersection menggabungkan semua field dari kedua layer, name milik bangunan tetap name, sedangkan name milik distrik diam-diam diganti menjadi name_2. Di langkah berikutnya, Aggregate dan Dissolve mengelompokkan menurut name, sehingga yang dikelompokkan adalah nama bangunan, bukan distrik! Membatasi Input fields to keep pada Intersection ke osm_id mencegah bentrokan itu dan mengembalikan output ke 10 distrik.

Tiga hal lain juga rusak dan perlu Anda ketahui sebelum mengotomatisasi data sendiri:

• Geometri OSM yang tidak valid menghentikan Processing secara default. Dua dari 180.602 bangunan Bielefeld memiliki ring yang memotong dirinya sendiri. Dengan pengaturan default QGIS, Clip langsung berhenti dengan Feature (18818404) from 'b' has invalid geometry. Jalankan Fix geometries sebagai langkah pertama setiap kali input Anda berasal dari OpenStreetMap mentah.
• savefeatures di PyQGIS tidak cocok dengan connection string GDAL. Pada run skrip pertama saya (10,0 detik), memberikan ogr:dbname='...' table="built_up" ke native:savefeatures memunculkan OGR driver for '' not found. Berikan path .gpkg biasa di OUTPUT dan atur LAYER_NAME: "built_up" sebagai parameter terpisah.
• Memuat banyak layer perantara membuat sesi kami crash. QGIS crash (SIGSEGV) tiga kali saat output Processing dimuat ke layer tree dengan Load layers on completion dicentang. Menghapus centangnya untuk baris batch perantara menghentikan crash tersebut.

Metode 4: Meminta AI agent di dalam QGIS

Kami membuat AI Agent, jadi bagian ini membahas plugin kami sendiri. Plugin ini menempatkan panel chat di dalam QGIS, memeriksa layer dan field yang sudah ada di proyek Anda, memanggil sendiri Processing tool QGIS dan PyQGIS, lalu memeriksa output sebelum menjawab.

Untuk pekerjaan sekali jalan atau proyek dua kota, membuat Graphical Model 8 node atau men-debug skrip 38 baris sering kali butuh persiapan lebih besar daripada tugasnya sendiri. Saya membuka proyek berisi layer buildings dan districts Bielefeld, mengatur panel ke effort Medium dan izin Balanced, lalu mengirim satu pesan:

The project has two layers: "buildings" (OSM buildings of Bielefeld, Germany) and "districts" (its 10 city districts, the district name is in the field "name"). For each district: clip the buildings to the district, count the buildings, sum their footprint area in square meters, and build a 25 m buffer around the clipped buildings, dissolved into one built-up polygon, with its area in hectares. Measure in a metric CRS (EPSG:25832). Write one GeoPackage at [output folder]/built_up_agent.gpkg with a single polygon layer named built_up, one feature per district, fields district, building_count, building_area_m2, built_up_ha, in EPSG:25832. Then show me the result table.

(Path output dipersingkat di kedua prompt. Catatan transparansi: pada percobaan pertama, QGIS crash 9 detik setelah saya mengklik Send karena segfault slot Qt sebelum ada jawaban. Saya membuka ulang proyek, mengirim prompt yang persis sama sekali lagi, dan tidak mengirim ulang setelah itu.)

Dalam 110 detik, agent menjalankan 27 pemanggilan tool (12 run_processing, 7 get_algorithm_help, 4 execute_code, 2 get_layer_info, 1 export_layer, 1 get_features), pulih sendiri dari satu error Processing internal tanpa menampilkan kartu izin, menulis GeoPackage, dan mencetak tabel 10 distrik di chat. Tanpa diminta, agent juga mencatat dalam jawabannya: "Buffer 25 m bisa melewati batas distrik dan saling tumpang tindih."

Lalu saya menyeret muenster_buildings dan muenster_districts ke dalam proyek dan mengetik pesan lanjutan 46 kata di chat yang sama:

Now do the same for Münster. I added two layers: "muenster_buildings" and "muenster_districts" (6 districts, the name is in the field "name"). Same fields and same 25 m buffer, in a new GeoPackage at [output folder]/built_up_agent_muenster.gpkg with the layer named built_up. Then show me the result table.

Dengan uji pertama masih ada di chat yang sama, agent menyelesaikan Münster dalam 60 detik menggunakan 15 pemanggilan tool (11 run_processing, 1 export_layer, 1 get_features, 1 zoom_to_layer, 1 execute_code) tanpa error.

Setiap jumlah bangunan dan luas footprint cocok dengan referensi hingga 0.00% di kedua kota.

Di mana batasnya? Pertama, nilai built_up_ha dari agent berada 0.07% hingga 0.21% di atas referensi planar (misalnya, Brackwede tercatat 1,390.51 ha vs 1,388.31 ha di referensi; kami tidak mengukur langkah internal mana yang menyebabkan selisih kecil itu). Kedua, GeoPackage yang diekspor menyisakan kolom tambahan _export_fid. Ketiga, dan paling penting untuk otomatisasi: agent merencanakan langkahnya dari awal di setiap pesan (27 pemanggilan tool di Bielefeld, 15 di Münster) dan berjalan di dalam sesi QGIS yang terbuka, sehingga tidak meninggalkan file .model3 atau .py yang bisa Anda jadwalkan tanpa pengawasan dengan cron.

Metode otomatisasi QGIS mana yang sebaiknya Anda pilih?

Daripada menganggap satu tool sebagai pemenang, sesuaikan metode dengan seberapa sering Anda akan mengulang pekerjaan itu:

• Anda menjalankan satu tool yang persis sama di 10 hingga 100 file: gunakan Batch Processing. Fitur ini sudah ada di setiap dialog Processing, gratis, dan tidak butuh kode sama sekali. Berhentilah memakainya begitu alur kerja Anda merangkai tiga atau empat tool berbeda.
• Anda atau tim akan menjalankan rangkaian multi-langkah setiap bulan, atau sesuai jadwal di server: buat di Graphical Modeler. Anda mendapat satu file .model3 yang bisa dibagikan ke rekan yang tidak menulis Python, dan bisa dijalankan secara headless dari shell script atau scheduled task via qgis_process.
• Anda butuh loop khusus, kontrol planar yang presisi, atau kecepatan eksekusi tercepat: tulis skrip PyQGIS. Skrip 38 baris kami berjalan 8 hingga 9 kali lebih cepat daripada Modeler di kedua kota.
• Anda punya tugas kompleks yang dijalankan sekali, dua kali, atau untuk beberapa variasi proyek hari ini: gunakan AI agent di dalam QGIS seperti AI Agent (atau lihat ikhtisar yang lebih luas di hub QGIS AI kami). Anda tidak perlu mencari nama tool yang tepat dan bisa menjalankan ulang di kota kedua dengan satu kalimat. Paket Free memberi 5 tugas per bulan dengan effort Low; pengujian ini berjalan dengan effort Medium, yang tersedia di Pro (49 EUR / bulan belum termasuk PPN, 300 tugas).

Cara kami mengukurnya. Semua pengujian berjalan pada 7 November 2026 di satu Mac Apple Silicon (macOS 27.0.1, arm64) dalam sesi QGIS 3.44.15-Solothurn yang terisolasi (Python 3.12.11) dengan AI Agent 1.9.4 (effort Medium, mode Balanced). Beban mesin bervariasi sepanjang hari, jadi bandingkan waktu-waktu ini sebagai orde besaran, bukan sebagai benchmark CPU. Kami mengukur waktu eksekusi wall-clock mesin dan jumlah langkah, bukan menit kerja manusia yang dibutuhkan analis GIS untuk merangkai model atau menulis skrip dari nol. Semua input, file .model3, skrip .py, pemeriksa referensi, dan log JSON mentah tersimpan di arsip eksperimen kami.

Pertanyaan yang sering diajukan

Bagaimana cara mengotomatisasi alur kerja yang berulang di QGIS?

Anda punya empat pilihan utama, tergantung seberapa sering pekerjaan itu berulang. Untuk satu tool di banyak file, klik Run as Batch Process di dalam dialog tool tersebut. Untuk rangkaian multi-langkah yang akan rutin dijalankan ulang, rangkai tool-tool itu di Processing > Graphical Modeler dan simpan file .model3. Untuk loop dan performa tercepat, tulis skrip Python menggunakan processing.run() di Python Console QGIS. Untuk analisis sekali atau beberapa kali saja saat Anda tidak ingin merangkai node atau menulis kode, jelaskan alur kerjanya dengan kata-kata biasa di plugin agent seperti AI Agent.

Sebaiknya pakai Graphical Modeler QGIS atau Python (PyQGIS)?

Gunakan Graphical Modeler saat alur kerja Anda berupa rangkaian lurus algoritma Processing dan Anda ingin file .model3 visual yang bisa dibuka anggota tim non-programmer, atau yang bisa dijalankan dari command line dengan qgis_process. Gunakan PyQGIS saat Anda perlu loop atas feature, menyimpan layer perantara di memori (skrip berjalan 8,1 detik vs 62,7 detik untuk model dalam uji Bielefeld kami), menangani error di kode, atau mengontrol skema output secara eksplisit.

Bisakah Graphical Model QGIS diekspor menjadi skrip Python?

Bisa. Graphical Modeler dapat mengekspor model sebagai skrip Processing Python (Export as Script Algorithm), yang kemudian bisa Anda edit untuk menambahkan loop, variabel, atau logika khusus. Kami tidak menguji ekspor ini dalam perbandingan ini.

Bisakah QGIS menjalankan alur kerja otomatis sesuai jadwal tanpa membuka aplikasinya?

Bisa. QGIS dilengkapi utilitas command-line bernama qgis_process. Anda bisa memberinya algoritma bawaan apa pun atau file .model3 yang tersimpan (misalnya, qgis_process run model3 --BUILDINGS=... --DISTRICTS=... --built_up=...) dari bash script, Windows Task Scheduler, atau job cron tanpa membuka antarmuka grafis QGIS. Dalam uji Bielefeld kami, model berjalan headless melalui qgis_process dalam 44,5 detik.

Coba AI Agent gratis

Baca selanjutnyaApa itu PyQGIS? Otomatisasi QGIS dengan atau tanpa kode