Apa tantangan terbesar Anda sebagai pengembang GIS?

23

Apa tantangan terbesar Anda saat mengembangkan perangkat lunak SIG?

Apakah ini coding? Apakah ia memahami konsep kartografi / geografi / dll (seperti proyeksi)? Atau kesulitan lain?

George
sumber
Saya suka diskusi ini. Saya tahu ini adalah utas lama, tetapi informasinya EMAS. Saya bekerja untuk Esri sebagai Manajer Produk produk pengembang. Saya menjaga ArcGIS Runtime SDK (Java, Android, Qt) dan ArcObjects SDK untuk Java. Pertama-tama, saya bisa berempati dengan rasa sakit. Kedua, saya ingin mendengar apakah API Web dan API Runtime ArcGIS telah membantu mengurangi titik-titik rasa sakit dalam menggunakan Platform, atau hanya secara umum. Menangani banyak dan banyak data masih merupakan tantangan, saya kira, apakah ini semakin baik ... sekarang 5 tahun kemudian? Layanan, baik dari Online maupun Portal, semakin kuat. Apakah t
Halo Eric, selamat datang di GIS.SE. Selalu menyenangkan melihat karyawan perusahaan perangkat lunak berpartisipasi dalam komunitas. Kami sedikit kurang forum diskusi di sini dan T&J lebih spesifik. Anda mungkin ingin memeriksa tur . Kami memiliki obrolan untuk percakapan, meskipun itu tidak banyak digunakan. Anda mungkin juga melihat sistem penandaan kami. Dengan menggunakan itu Anda dapat mengasah pada aktivitas pertanyaan terbaru pada subjek tertentu, seperti API dan SDK yang Anda sebutkan.
Chris W
Demikian juga selamat datang di GIS SE Eric! Ketika Anda melihat-lihat situs lagi, saya harap Anda akan dengan cepat mendapatkan apa yang dimaksud dengan Stack Exchange, dan betapa berbedanya format Q&A yang difokuskan pada forum diskusi. Persis seperti yang saya harapkan, Forum Diskusi ArcGIS akan menjadi dalam perombakan terbaru mereka. Namun, tolong jangan menilai nilainya pada T&J awal ini yang, meskipun populer, bukan contoh yang bagus tentang bagaimana pengguna dapat datang ke sini mencari jawaban, dan dalam beberapa menit mengidentifikasi pertanyaan yang sama dan membaca jawabannya tanpa untuk mencerna diskusi bolak-balik.
PolyGeo

Jawaban:

22

Berbicara dari pengalaman saya sebagai pengembang yang masuk dalam adegan pengembangan ESRI / GIS hampir 5 tahun yang lalu:

  1. Tidak ada API tunggal untuk melakukan apa yang ingin Anda lakukan. Hanya kekacauan API yang kacau yang mungkin atau mungkin tidak berfungsi untuk tujuan Anda: ArcObjects, Python, REST, SOAP, ADF, ST_Geometry operator?
  2. Semua API terkait dengan perangkat lunak yang kikuk dan mahal yang tidak Anda inginkan sebagai inti dari aplikasi Anda.
  3. Peluang kecil untuk desain yang benar-benar kreatif. Struktur data geospasial berorientasi objek? Lupakan. Terlepas dari semua pembicaraan tentang "objek" dan "kelas fitur" Anda masih bekerja dengan tabel bodoh yang dimediasi oleh middleware berubah-ubah.
  4. Perangkat lunaknya bermasalah, pesan kesalahan menyesatkan, dan dokumentasi tidak lengkap. Pemecahan masalah hampir selalu coba-coba. Terbiasalah.
  5. Mengelola data geospasial menggunakan metode basis data relasional hampir tidak mungkin. Saya cukup banyak harus meninggalkan SQL / DDL karena mereka hanya membuat saya bermasalah dengan middleware (ya, saya sedang berbicara tentang ArcSDE). Sayang sekali membuang seluruh wajan. Cukup buka ArcCatalog, arahkan, klik.

Seperti yang Anda tahu, saya memiliki pandangan yang cukup negatif di kancah pengembangan ESRI. Bagi mereka yang datang dari latar belakang geografi, saya yakin kemungkinannya cukup menarik. Tetapi untuk orang seperti saya yang menyukai database relasional, pemrograman berorientasi objek, dan peluang terbuka lebar untuk solusi kreatif, pengembangan GIS dengan ESRI sangat menghambat dan tidak memuaskan. Ini memalukan karena kerumunan sekolah tua mengatakan kepada saya bahwa dulu lingkungan yang unggul, sebelum sejajar dengan Microsoft. Saya sangat berharap komunitas open source terus berinovasi.

nw1
sumber
4
Saya seorang ahli statistik, dan saya memiliki keluhan yang sangat mirip tentang produk ESRI. Teori saya yang terlalu optimis adalah bahwa, karena komputer mungkin diterapkan pada statistik sebelum GIS, perangkat lunak GIS adalah sekitar sepuluh tahun di belakang perangkat lunak statistik (dalam fase SAS / SPSS) dan bahwa program open-source atau stack yang benar-benar luar biasa ada di ambang pecah. Mungkin sudah - sudah bertahun-tahun sejak saya berkesempatan bermain dengan program non-ESRI.
Matt Parker
2
Saya hanya akan berpura-pura mengguncang tinju saya di Redlands bersama kalian semua, dan menyampaikan anekdot ilustrasi: Hampir semua panggilan API ke API raster Spatial Analyst (pada saat itu) akan gagal dengan COM generik "Kesalahan Tidak Ditentukan" "Jika ada yang salah. Putus asa untuk memecahkan masalah, saya akhirnya menghubungkan strace ke ArcGIS.exe dan, terkubur dalam panggilan sistem, menemukan (drumroll) bahwa pesan kesalahan era 1980-an yang membantu dan rinci sedang ditulis ke jendela yang setara dengan / dev / null.
Dan S.
13

Sejumlah besar data. Mampu menemukan cara yang tepat untuk mengekstraksi data dalam jumlah besar menggunakan teknologi web telah menjadi tantangan. Kami dapat memiliki banyak data, dan kinerja buruk, atau memiliki lebih sedikit data yang ditampilkan, tetapi berpotensi menyampaikan informasi yang salah.

Hugo Estrada
sumber
10

Saya bukan pengembang GIS; namun, saya seorang pemodel GIS:

Tantangan:

  • Pengumpulan data, agregasi, disagregasi, penggabungan, dan pemisahan: Saya mendapatkan data dari berbagai sumber untuk berbagai proyek; masalah terbesar biasanya adalah mendapatkan semua data untuk bidang / wilayah geografis yang sama. Saya biasanya harus menggunakan beberapa teknik yang disebutkan di atas pada setiap set data, untuk memiliki sampel yang koheren untuk proyek tersebut. Ini meningkatkan kemungkinan kesalahan dan melemahkan ketepatan kami.

  • Saya bukan pengembang; Saya ulangi saya bukan pengembang: Ketika Anda orang-orang yang baik berbicara tentang SOAP, SHAMPOO, REST, Indeks GIS-T, dll. Ini sangat berarti bagi Anda. Bagi saya kebanyakan itu adalah jargon. Saya biasanya memiliki kurva belajar yang besar atau pendakian yang curam untuk menyelesaikan beberapa hal sederhana.

  • Kesenjangan antara FOSS dan Perangkat Lunak Kepemilikan: Saya suka QGIS dan postgis hingga mati; secara harfiah saya memilikinya diinstal pada setiap mesin; namun, ketika saya ingin melakukan analisis berbasis transportasi, saya harus menggunakan TransCAD atau EMME2 / 3. Setiap biaya sekitar $ 15.000 dengan semua lonceng dan peluit. Dalam semua keadilan, semua masalah ini dapat diselesaikan jika ada paket networkx untuk file shp.

  • Berbagai masalah disiplin: Saya berpengalaman dalam teknik pemodelan transportasi; Namun payah pada pemodelan demografis, dan sejauh yang saya tahu, saya harus menggunakan alat R canggih untuk menyelesaikan data saya. Jadi Masalah GIS adalah bahwa GIS adalah bidang multidisiplin yang sulit untuk bertahan hidup sendiri.

  • Kurangnya alat dan perangkat lunak yang mapan untuk beralih dari penggunaan lahan citra ke penggunaan lahan vektor: Saya memperkirakan masa depan di mana sebuah alat akan menganalisis citra satelit GEOEYE dan membandingkan penggunaan lahan di dalamnya dengan database vektor (seperti yang dibangun)

  • Terkadang lebih cepat melakukan hal-hal di Excel / "program spreadsheet favorit Anda ada di sini: Kadang-kadang saya ingin melakukan analisis transit, jauh lebih cepat untuk mengambil data yang dimasukkan ke excel, mengerjakan rumus, lalu membuang data kembali menjadi postgis sebagai file csv dan meregenerasi peta. Perbedaan seperti itu terutama di dunia OpenSource harus ditangani dengan lebih baik.

Bagaimanapun saya mungkin tidak menjawab Anda dengan benar; Saya hanya berharap saya fasih dalam hal pemrograman GIS sehingga saya dapat unggul dalam pemodelan GIS

dassouki
sumber
Networkx untuk shp sudah ada FYI misalnya networkx.github.io/documentation/latest/reference/… Untuk vektor + raster, lihat PostGIS raster extension trac.osgeo.org/postgis/wiki/WKTRaster
ThomasG77
Masalah terbesar +1 adalah sumber data yang dapat diandalkan. Banyak negara bagian akan mempekerjakan mahasiswa magang untuk pekerjaan musim panas untuk berkeliling mengumpulkan koordinat untuk jalan dan barang-barang, dan biasanya tidak kesalahan diperiksa atau diaudit sama sekali (bahkan tidak sampel itu), dan hasilnya sekarang Anda memiliki New Jersey DOT yang mengatakan bahwa jalan 500 kaki lebih pendek dari Google dan OSM mengatakan itu. Sialan.
nothingisnecessary
8

Hal yang paling penting, dan biasanya yang paling sulit dalam pengalaman saya, adalah:

  1. dapatkan data yang tepat untuk pekerjaan itu
  2. Dapatkan untuk ditampilkan dalam proyeksi yang tepat (dan semua lapisan setuju). Terutama ketika mereka berasal dari sumber yang berbeda
  3. mendesain aplikasi yang dapat digunakan. Mudah dan menggoda untuk menaruh banyak lonceng dan peluit yang hanya akan membingungkan pengguna

Saya pikir poin 1 akan lebih mudah di negara maju, tapi itu bukan pengalaman saya.

Vinko Vrsalovic
sumber
6

Bagi saya, tantangan terbesar adalah memutuskan alat mana yang akan digunakan untuk proyek tertentu. Sumber terbuka atau kepemilikan? Python atau .NET? Berbasis web atau desktop? Saya menjawab pertanyaan-pertanyaan ini secara berbeda untuk proyek yang berbeda, dan saya yakin orang akan menanyakan semuanya di situs ini. Banyak yang turun ke preferensi pribadi dan mencoba untuk ilahi apa ESRI dan Microsoft akan mendukung di masa depan.

jswise
sumber
Ini harus menjadi hal terbesar bagi saya.
Nathan W
2
Ini kurang penting bagi saya. Sementara itu demi kepentingan terbaik pengembang untuk berinvestasi di masa depan mereka sendiri, dan untuk menghindari "pekerjaan sia-sia", saya merasa bahwa tujuan membenarkan cara, dan teknologi apa pun yang melakukan pekerjaan adalah pilihan terbaik. Memiliki gagasan yang jelas tentang apa yang perlu Anda sampaikan lebih penting daripada bagaimana Anda sampai di sana.
mwalker
5

Masalah saya adalah tentang kuda dan air. Dalam banyak kasus kami mengembangkan dan atau menghadirkan solusi yang benar-benar baik untuk klien kami, tetapi tidak peduli seberapa elegan solusinya, sama sekali tidak berguna jika tidak ada yang mau meluangkan waktu untuk menggunakannya. Dalam beberapa kasus, kami dapat mengatasi hal ini dengan membuat pengguna pekerjaan kami berbasis (survei untuk masalah, berbicara tentang solusi sebelum pengembangan) tetapi beberapa kasus ini masih belum cukup.

wilsongis
sumber
3

Saya pikir tantangan terberat adalah membuat manajemen memahami GIS dan beberapa pengguna juga tidak mengerti. Persepsi adalah bahwa SIG adalah tentang membuat peta; bahwa peta adalah satu-satunya hasil dari upaya GIS. Saya tidak bisa memberi tahu Anda betapa frustrasinya saya menemukan ini - tingkat ketidaktahuan di luar sana sangat besar, dan itu dipegang oleh para pembuat keputusan utama.

Namun pada akhirnya - kami menjadi beberapa ahli dan pemrogram SIG perintis - pada akhirnya akan menjadi manajemen dan akhirnya kami dapat menyelesaikan beberapa proyek SIG yang layak!

Hal sulit lainnya sebagai programmer GIS - Anda harus memahami begitu banyak teknologi yang berbeda, Java, .Net, basis data, perangkat lunak ESRI atau vendor lain yaitu MapInfo, jaringan, keamanan, teknologi web, dll. Kadang-kadang pekerjaan itu hampir mustahil!

Vidar
sumber
2

Berurusan dengan orang-orang dari latar belakang survei yang tidak memahami teknik pengembangan dan metodologi perangkat lunak profesional, tetapi karena mereka belajar sendiri cara membuat kode avenue / VB, berpikir itulah yang ada di sana.

BlinkyBill
sumber
2

# 3 dari jawaban Vinko :

mendesain aplikasi yang dapat digunakan. Mudah dan menggoda untuk menaruh banyak lonceng dan peluit yang hanya akan membingungkan pengguna.

Saya akan memilih seluruh jawaban tetapi untuk fakta bahwa kegunaan hanya item ketiga dalam daftar dan saya tidak berpikir dua yang pertama adalah yang menantang.

Kegunaan adalah tempat sebagian besar masalah saya dan di mana saya menghabiskan sebagian besar waktu desain / pengembangan, mencari tahu bagaimana merancang antarmuka pengguna yang cerdas dan efektif, tetapi tetap intuitif agar pengguna tidak bingung karenanya, misalnya:

  • Cara menyetel styling (dan memilih layer) dari peta interaktif untuk menunjukkan informasi yang relevan dan menghindari kekacauan yang sering muncul dengan menampilkan terlalu banyak data (misalnya dengan menggunakan agregasi otomatis fitur titik); Saya tahu inilah yang coba dipecahkan oleh kartografi selama bertahun-tahun, tetapi masalahnya hanya bertambah buruk dengan peta digital / interaktif

  • Cara melakukan pemosisian otomatis tampilan peta berdasarkan kueri / pemilihan fitur pengguna

  • Menyoroti fitur 'terpilih' - apakah Anda menunjukkan sorotan secara singkat, telah menyorotnya setiap kali fitur dipilih, apakah Anda tidak menyorot ketika tabel pilihan (atau daftar) kehilangan fokus ... Bagaimana menyorot kedua kueri semua hasil dari tabel dan baris yang dipilih dalam tabel itu (tanpa memiliki terlalu banyak tombol sakelar)

  • Menampilkan informasi tambahan dalam daftar lapisan atau fitur, mis. Visibilitas / gaya terapan / tipe geometri, status / kelas fitur ... Ini menjadi semakin rumit jika seseorang memiliki tipe fitur berbeda yang ditampilkan dalam daftar yang sama (saya rasa itu sebabnya Google dan Bing Maps menggunakan pemfilteran hasil pencarian yang cukup berat)

  • Pengeditan yang efisien: gertakan, penutupan poligon, tambahkan / pindahkan / hapus titik, tanpa memiliki banyak tombol bilah alat.

  • Bagaimana cara mendesain (dan mengimplementasikan) antarmuka permintaan pengguna yang frendly untuk kueri geometri, dan bahkan lebih menantang, antarmuka untuk kueri termasuk atribut dan geometri; tanpa membuat tipe pengguna dalam sesuatu yang menyerupai SQL.

  • Cara mendesain sesuatu seperti clipboard untuk fitur / geometri agar tidak harus terus menerus 'mengambil' fitur dari peta untuk digunakan dalam kueri, pengeditan ...

Perasaan saya adalah bahwa SIG adalah bidang yang sangat menantang dalam aspek kegunaan, karena:

  • Lokasi adalah konteks universal dan biasanya paling alami untuk informasi apa pun, sehingga selalu ada terlalu banyak informasi yang tersedia untuk ditampilkan

  • Memiliki informasi yang ditampilkan pada peta, seseorang mudah tergoda untuk meremehkan pentingnya bagian-bagian non-GIS dari antarmuka pengguna

  • Industri ini secara tradisional mengabaikan aspek kegunaan dari perangkat lunak GIS, dan mereka lolos karena pemetaan digital dipandang sebagai perdagangan teknis dengan kurva belajar yang lambat dan ada konsep yang jauh lebih sulit untuk dipelajari daripada cara menggunakan antarmuka. Ini berarti bahwa siapa pun yang mencoba merancang antarmuka GIS untuk non-pakar harus menemukan prinsip mereka sendiri yang akan membingungkan (contoh yang bagus adalah Google 'Petaku' atau Bing Maps '' Tempatku ')

mkadunc
sumber
2

Salah satu tantangan terbesar untuk pengembangan GIS berbasis web adalah bagaimana data dikirimkan dan seberapa banyak efisiensi yang bisa saya dapatkan dari penyampaian data dengan cara tertentu. Rintangan terbesar adalah sangat sulit untuk menulis kode untuk sesuatu yang mengharuskan manusia untuk men-tweak. Sangat jarang Anda melihat teknik generalisasi untuk data vektor yang digunakan pada skala besar. Sering kali Anda harus mengubah rentang skala untuk menghidupkan dan mematikan lapisan.

CrazyEnigma
sumber
1

Pertanyaan ini muncul di pencarian google saya untuk tantangan di GIS, dan saya merasa ingin berkontribusi di sini.

Tautan lain yang menurut saya relevan adalah tulisan ini .

Merangkum apa yang dikatakan di sana dan pandangan saya sendiri, saya pikir tantangan terbesar (tanpa urutan tertentu):

  • Antarmuka Pengguna: Dengan sejumlah opsi antarmuka pengguna, sangat menantang bagi pengembang untuk mengoptimalkan penawaran agar sesuai dengan semua perangkat. Berbasis sentuhan vs desktop vs dpt dipakai. Ide DE seperti yang disampaikan oleh Gore, yang menampilkan headset yang dapat dikenakan dengan layar, sarung tangan dengan kontrol arah dan pengenalan suara adalah masa depan yang mewah.
  • Standardisasi: Dengan standar untuk penyimpanan dan pengambilan data, kita bisa memiliki geo-database yang bersandar di cloud dan memungkinkan informasi yang diambil dalam perjalanan sehingga penelusuran dan penggunaan GIS dapat dibuat lancar.
  • Penggunaan Data: Pembuat keputusan selalu terdesak waktu. Jika alat membantu mereka, itu harus dilakukan dengan cara yang halus, mudah dan cepat. GIS tampaknya tidak disampaikan di bagian depan ini dan itu adalah salah satu alasan mengapa itu masih bukan kata kunci.
  • Data: Data bervariasi, tersebar dan berisik. Bahkan untuk organisasi dengan insentif yang jelas pada GIS real-time, agregasi data masih menjadi rintangan besar untuk membayangkan entri.
  • Upaya Terkoordinasi: GIS bersifat multi-disiplin. Setiap anak tahu itu. Manajemen dibuat sadar akan hal itu di slide pertama. Meskipun multi-disiplin seperti itu, proyek multi-departemen jarang terjadi.
Chintan Pathak
sumber
0

Ketika datang ke coding, saya merasa saya membuang terlalu banyak waktu untuk solusi. Untuk proyeksi, saya butuh beberapa bulan untuk memahami proses dan matematika karena menurut saya sedikit materi yang diterbitkan bermanfaat tentang masalah ini. Dokumen-dokumen EPSG dan OGC tentang masalah itu memang membantu saya mendapatkan kepalaku setelah beberapa kali membaca, meskipun mereka kadang-kadang tampak sebagai salinan satu sama lain. Masalah terbesar yang saya miliki sebagai pengembang independen adalah bahwa saya tidak dapat membantu tetapi tersandung orang yang membutuhkan pekerjaan khusus untuk pengembangan aplikasi web medis, industri, atau bahkan sederhana, bahkan sekarang. Dengan industri GIS, tampaknya hampir mustahil untuk menemukan cara untuk masuk ke pasar.

Pesolek
sumber
0

Saya seorang pemula yang lengkap di teknologi GIS, mencari tahu semuanya sambil jalan. Dan karena dana saya terbatas, saya mencoba menghindari menggunakan produk ESRI dan melakukan semuanya dengan alat open source.

Karena itu, hal tersulit bagi saya sejauh ini semuanya terkait dengan pengumpulan data. Ada banyak artikel tentang memanipulasi dan menampilkan data, dan banyak alat untuk membuat hidup Anda lebih mudah. Tapi saya masih berjalan dalam kegelapan ketika datang untuk mengumpulkan data.

Saya tidak tahu apa yang dilakukan para profesional untuk menemukan dan mengumpulkan data. Sesuatu memberi tahu saya bahwa ada cara yang lebih mudah untuk mendapatkan data daripada data.gov dan google.

Eric Palakovich Carr
sumber
Sebagian besar kami harus membelinya dari Vendor, yang melakukan survei lapangan aktual dan konversi dari sumber lain. Di dunia ketiga, mendapatkan data secara terbuka dari Pemerintah adalah PITA
Devdatta Tengshe
-1

Anda mungkin tidak beruntung dipaksa bekerja dengan analis GIS yang telah dikonversi menjadi pengembang perangkat lunak.

Sangat mudah untuk mengharapkan pengembang perangkat lunak yang kompeten untuk mengambil konsep GIS, dan membiarkan mereka pergi melalui API dan umumnya mencari tahu tanpa banyak bantuan. Hal yang sama tidak berlaku untuk mengambil analis GIS dan mengharapkan mereka untuk mengambil pengembangan perangkat lunak.

Hasilnya memalukan , paling-paling. Jika Anda memiliki pengalaman bekerja dengan pengembang yang buruk , bayangkan kode itu lebih buruk daripada apa pun yang dikembangkan oleh programmer terburuk.

Ada beberapa perusahaan tempat Anda bekerja yang tidak mendapatkannya.

emptyset
sumber
2
@emptyset: Saya seorang ahli geografi yang menjadi pengembang. Saya tidak berpikir hasil saya "memalukan" di terbaik. Saya memiliki lebih banyak ketrampilan pengembangan daripada kolega lain yang memiliki latar belakang TI - meningkatkan pemahaman yang lebih baik dan PENGGUNAAN konsep OOP, konsep dan aturan basis data, dll. Tentu saja, saya tidak setuju dengan jawaban Anda: P
George Silva
1
@ George: Dan saya tidak mengatakan Anda mengatakan sebaliknya, hanya menunjukkan bahwa untuk menjadi pengembang yang hebat Anda harus tahu seberapa banyak yang Anda payah. Setidaknya saya coba.
Vinko Vrsalovic
2
+1 Pada banyak kesempatan, saya diminta untuk "memperbaiki bug" di Big Ball of Mud en.wikipedia.org/wiki/Big_ball_of_mud yang ditulis oleh satu atau beberapa analis. Beberapa kode terburuk ditulis oleh beberapa analis terpandai. Seringkali yang cerdas gagal menghargai keindahan kesederhanaan. Seringkali kesalahan terjadi pada manajemen - analis mungkin menyadari nilai refactoring, tetapi tidak dapat membenarkan menghabiskan waktu mengubah kode yang tidak rusak.
Kirk Kuykendall
3
Untuk akibat wajarnya, Anda mungkin kurang beruntung untuk bekerja dengan pengembang perangkat lunak yang dipaksa bekerja sebagai profesional GIS. Saya sangat waspada terhadap siapa pun, dari bidang apa pun, hanya mencari tahu semuanya saat mereka menggunakan SIG. Saya seorang analis yang mengeksplorasi pengembangan, dan saya sepenuhnya berharap - dan ingin - orang-orang waspada terhadap kode saya. Pengembang mana pun yang merasa baik-baik saja di GIS, mungkin tidak. :-)
matt wilkie
3
-1 - pernyataan sangat menyapu yang terbukti salah dan agak ofensif. Seperti yang ditunjukkan oleh Matt W di atas, Anda biasanya lebih baik meminta orang GIS untuk melakukan pengkodean daripada sebaliknya karena ada begitu banyak sumber daya untuk membantu Anda mempelajari pengkodean dan menerapkan praktik terbaik daripada yang ada di GIS
dmbrubac
-1

dunia GIS sedang diperluas ke pengguna umum kecuali tahun-tahun awal di mana GIS hanya diperlakukan oleh insinyur, arsitek atau komunitas ilmiah. Dalam hal aplikasi GIS dilakukan untuk pengguna umum, tantangannya adalah mencampurkan teknologi di mana GIS diperlakukan lebih sebagai teknologi (dalam hal ini pengembang dengan sedikit pemahaman tentang teknologi GIS sudah cukup). Namun dalam hal aplikasi dilakukan untuk komunitas khusus tantangannya lebih kompleks karena bergabung dengan teknologi diperlukan untuk mencari algoritma yang ada untuk memenuhi permintaan, jika tidak lebih buruk kita harus mengembangkan algoritma ini. Dalam hal ini perpaduan antara insinyur dan pengembang adalah pekerja yang sesuai.

Rodolfo Moreno
sumber