ArcSDE - gunakan tipe geometri asli untuk migrasi selanjutnya dari SDE?

Latar Belakang: Kami memiliki aplikasi web pelaporan non-spasial dengan backend SQL Server. Kami ingin menambahkan komponen spasial ke aplikasi ini: sajikan beberapa peta dasar, sajikan poin dan poligon untuk tampilan dan pengeditan, buat laporan untuk poligon yang dipilih.

Untuk itu, rencananya adalah menggunakan ArcSDE dengan SQL Server, dan menggunakan ArcServer untuk menyajikan lapisan dasar dan geometri vektor. (sesuatu seperti WMS / WFS-T)

Masalah: Kami mungkin, pada titik tertentu, memutuskan untuk pindah dari perangkat lunak berpemilik yang mahal, dan menggunakan alternatif FOSS (misalnya GeoServer, atau TinyOWS jika / ketika mendukung SQL Server). Jika memungkinkan, saya ingin menghindari membangun aplikasi dengan teknologi ESRI yang tidak dapat dibatalkan.

Pemahaman saya tentang SDE adalah bahwa ia dapat menggunakan format spasial spesifik ESRI, atau format spasial yang asli dari sistem basis data yang diinstal. (Saya kira ada beberapa penalti kinerja untuk menggunakan format asli.)

Pertanyaan saya: Jika kita mengatur SDE pada basis data server SQL ini menggunakan format spasial SQL Server asli, apakah kita dapat mengatur katakanlah, GeoServer, untuk dijalankan terhadap tabel yang dikelola SDE? Apa yang diperlukan untuk mencabut SDE dan menggunakan sesuatu yang lain? (Juga, sebuah pertanyaan meta: apakah ini pertanyaan yang wajar untuk ditanyakan? Apakah ada sesuatu yang penting yang saya lewatkan?)

Jawaban parsial: Saya bukan pengguna Geoserver, tapi saya telah membangun aplikasi web non-Esri berbasis spasial (ASP.NET) menggunakan geometri asli yang disimpan dalam SDE featureclass aktual (SQL Server 2008). Selama tidak diversi (atau diversi dan Anda menerima jeda apa pun yang ada agar editan Anda dipindahkan ke pangkalan), seharusnya tidak ada masalah. Aplikasi saya didorong secara spasial, tidak berisi peta, tetapi fungsi spasial di mana banyak digunakan dalam pernyataan SELECT dan prosedur tersimpan.

Saya telah menemukan bahwa ArcGIS dapat bermasalah dengan implementasi ST_GEOMETRY asli dan / atau Esri dan sering kali akan menghasilkan penunjuk jari vendor. Lihat pertanyaan ini: Bagaimana cara memperbolehkan lebih banyak simpul polyline untuk ST_GEOMETRY di Oracle / SDE? (versi singkat: Oracle: "Begitulah adanya. Esri perlu menghadapinya." Esri: "Itu bug - tunggu sampai Oracle memperbaikinya.")

Ini bukan alasan untuk tidak menggunakan geometri asli, tetapi sesuatu yang harus diperhatikan jika Anda adalah orang pertama yang menemukan bug (saya juga menyarankan memiliki versi SDE_BINARY dari kumpulan data Anda dalam tes / dev env sehingga Anda dapat mengonfirmasi atau aturan perilaku aneh di kedua tipe data penyimpanan).

Anda menyebutkan pengeditan pada rencana tata ruang db ini. Di situlah Anda tidak memberikan data yang cukup untuk jawaban yang lengkap.
Jika ada kekhasan esri (tipe data) tentang tabel yang diedit maka Anda berencana untuk beberapa lautan kasar.
Akan cukup tantangan untuk mengatur tabel spasial (pihak ke-3), bekerja di sekitar izin pengguna, izin pemirsa, kunci, tidak ada versi yang didukung, mengedit data yang bukan versi di arcgis, ... Ada banyak jembatan, rintangan lainnya , dan bahkan jurang untuk berakhir.
Jadi semakin sederhana model semakin sedikit masalah untuk pencapaian.
Itu dikatakan jawaban singkatnya adalah ya.
Salah satu masalah dengan jalan ini adalah bahwa begitu keputusan untuk melakukan perjalanan jalan dibuat.
Ada banyak kendaraan untuk menyusuri jalan.
Membuat keputusan untuk kendaraan yang tepat sering dilakukan melalui berbulan-bulan jika tidak bertahun-tahun bermain kotak pasir.

EDIT
Jika Anda mengedit poligon dan Anda tidak menggunakan beberapa teknik dan alat yang cukup canggih, Anda ingin ada aturan topolgy untuk membantu kontrol kualitas (mungkin tumpukan perangkat lunak lain seperti radius). Jika Anda memecah sebuah poligon, Anda ingin keduanya mendapatkan atribut yang sama, atau tidak, ketika sebuah vertex dipindahkan adalah untuk snap ke yang lain, jika tidak ada sepotong. seterusnya dan seterusnya. jika Anda tidak menggunakan esri Anda sendirian (atau db spasial) untuk menerapkan beberapa fungsi dasar gis. Anda hanya perlu tahu apa yang Anda inginkan dan bagaimana melakukannya (atau itu bisa dilakukan).

Kami menyimpan data sde di SQL Server 2008 tipe geometri asli dan saya tidak akan melakukannya dengan cara lain. Ini memungkinkan fleksibilitas maksimum dengan kueri spasial dalam database. Geoserver baru saja melakukan perbaikan signifikan pada dukungan untuk tipe data SQL server tetapi kami belum menggunakannya sehingga saya tidak dapat memberikan banyak masukan dalam hal itu. Satu hal yang perlu diperhatikan adalah bahwa membangun database sde dengan instalasi postingan standar membangun struktur tabel untuk sde. Akan lebih bijaksana untuk melihat ke dalam struktur itu. Jika saya menghapus sde yang mendukung solusi Foss, saya tidak ingin semua tabel sistem sde yang tidak dibutuhkan. Oleh karena itu saya akan membangun kembali DB yang bersih dan memindahkan tabel ke lingkungan yang baru. Ini akan menjadi kesempatan untuk mencoba postgis sebagai pengganti SQL server karena geoserver memiliki sejarah pengembangan dengan postgis. Saya tidak akan

Semoga itu bisa membantu!