ARCGIS PRO'DA GEODATABASE TASARIMI VE VERİ MODELLEMEK

İBB'nin altyapı CBS biriminde çalışan bir mühendisin masasında üç farklı kaynaktan gelen su şebekesi verisi vardır: ilçelerden gelen shapefile'lar, mahalle ölçümünden çıkmış AutoCAD paftaları ve abone takip sisteminden çekilmiş Excel tabloları. Hattın çapı bir dosyada "DN200", diğerinde "200 mm", üçüncüsünde sadece "200" yazar. Veri birleşmeden önce hangisinin standart olduğu kararı verilmeden tek bir analiz sorgusu bile güvenilir cevap vermez. Geodatabase tam bu noktada devreye girer — verinin nereye, hangi tipe, hangi sınırlar içinde gireceğini önceden tanımlar.

Bu yazıda file geodatabase ile enterprise geodatabase arasındaki tercih nedenini, feature class ve feature dataset hiyerarşisini, domain ve subtype'la veri girişini disipline etmeyi, relationship class ile tablo ilişkisi kurmayı, topoloji kurallarıyla geometrik tutarlılığı zorlamayı ve attribute rules ile Arcade ifadeleriyle iş kuralı yazmayı ele alacağız. Kurumsal CBS altyapısı kuran ekipler için sıralama ve karar mantığı önemlidir.

File mi Enterprise Geodatabase mi Seçilmeli?

Yeni bir projeye başlamadan önce verilmesi gereken ilk karar veritabanı tipidir. Esri belgelerinde üç ana seçenek tanımlanır ve tercih kullanıcı sayısı ile düzenleme şekline göre yapılır.

• File geodatabase (.gdb): Klasör biçiminde diskte durur. Tek kullanıcı düzenlemesi için tasarlanmıştır; aynı feature class üzerinde eş zamanlı çoklu düzenleme yapılamaz. Farklı feature dataset veya feature class üzerinde aynı anda çalışılabilir. 1 TB'ye kadar ölçeklenebilir, kurulum gerektirmez.
• Mobile geodatabase (.geodatabase): SQLite tabanlı tek dosya. ArcGIS Field Maps veya QuickCapture ile sahada veri toplayan ekipler için uygundur; ofise dönüşte ana geodatabase'e sync edilir.
• Enterprise geodatabase: Oracle, Microsoft SQL Server, PostgreSQL, IBM Db2 veya Informix üzerinde çalışır. Çok kullanıcılı düzenleme, versiyonlama (versioning), arşiv ve denetim kaydı sunar. ArcGIS 10.3'ten önce ArcSDE adıyla anılırdı; SDE command line araçları o sürümle deprecated edildi ama veritabanı katmanının teknik adı hâlâ kullanımda.

Versiyonlama (versioning) enterprise geodatabase'in en ayırt edici özelliğidir. Her düzenleme delta tablolarına yazılır; aynı parsel üzerinde üç farklı operatör çalışırken kimseye kilit gelmez, çakışmalar reconcile ve post aşamasında çözülür. Tapu ve Kadastro Genel Müdürlüğü gibi yüzlerce kullanıcının aynı veriyi düzenlediği yapılarda enterprise zorunludur; tek mühendisin saha rölövesini sayısallaştırdığı bir mimari proje için file geodatabase yeterlidir.

Karar tablosu pratikte şöyle özetlenir:

Feature Class ve Feature Dataset Hiyerarşisi

Feature class, aynı geometri tipini (nokta, çizgi, poligon, anotasyon) ve aynı öznitelik şemasını paylaşan coğrafi nesnelerin tablosudur. Her satır bir nesne, her sütun bir özniteliktir; ObjectID alanı tekil tanımlayıcı, Shape alanı geometriyi tutar. Çizgi feature class'lar uzunluğu, poligon feature class'lar çevre ve alanı otomatik hesaplar.

Geodatabase varsayılan x,y çözünürlüğü 0.0001 metre, x,y toleransı 0.001 metredir (çözünürlüğün 10 katı). Tolerans, koordinat çakışmalarını otomatik kümeleyen değerdir — kadastro işlerinde bu değer düşük tutulur, hidroloji modelinde gevşek bırakılabilir. Yanlış tolerans, parsel köşelerinin "kapanmadı" gibi görünmesine neden olur.

Feature dataset, aynı koordinat sistemini paylaşan birden fazla feature class'ı gruplayan kaptır. Tek başına dataset olmadan da feature class'lar geodatabase kökünde yaşayabilir ancak şu yapılar dataset zorunluluğu getirir:

• Topoloji (geometrik bütünlük kuralları)
• Network dataset (ulaşım/altyapı ağ analizi)
• Utility network (içme suyu, elektrik, telekom altyapısı)
• Trace network (basit izleme ağı)
• Parcel fabric (kadastral parsel yapısı)
• Terrain dataset (LIDAR/yüzey modeli)

Karayolları Genel Müdürlüğü'nün ulusal yol envanteri gibi bir projede feature dataset `Karayolu_Agi` adıyla açılır; içinde `Otoyollar`, `Devlet_Yollari`, `Il_Yollari`, `Kavsaklar` feature class'ları bulunur. Hepsi aynı projeksiyonda (ITRF96/TUREF-TM30) çalışır ve üzerlerine network dataset kurularak en kısa yol, etki alanı, servis bölgesi analizleri yapılır.

Domain ile Veri Girişi Nasıl Disipline Edilir?

Domain, bir alanın hangi değerleri kabul edeceğini önceden tanımlayan kuraldır. İki tipi vardır:

• Coded value domain: Liste tipi — örneğin Yol_Sinifi alanı sadece Otoyol, Devlet_Yolu, Il_Yolu, Koy_Yolu değerlerini alır. Kullanıcı arayüzde dropdown'dan seçer; "Otoyol", "OTOYOL", "otoyol" gibi yazım çeşitlemesi imkânsızlaşır.
• Range domain: Sayısal aralık — örneğin Cap_mm alanı sadece 50-2000 mm arası değer kabul eder. İçme suyu hattı projesinde 5000 mm'lik yanlış giriş veritabanına ulaşmaz.

İBB CBS uygulamalarında bir yol envanter projesinde `Kaplama_Tipi` alanına bağlanan coded value domain yaklaşık 6-8 değer içerir: asfalt beton, sathi kaplama, parke taş, beton, stabilize, toprak. Veri girişi yıllar geçtikçe farklı operatörler tarafından yapıldığında bile alan tek bir terminolojide kalır; raporlamada GROUP BY sorguları temiz çalışır.

Domain geodatabase seviyesinde tanımlanır, sonra istenen feature class'ın istenen alanına atanır. Aynı `MalzemeDomain` hem `İçmeSuyuHatti` hem `KanalizasyonHatti` feature class'ında kullanılabilir — tek yerde tutulduğu için liste güncellendiğinde her iki katmana yansır.

Subtype Ne Zaman Gerekli?

Subtype, bir feature class içinde birden fazla alt türü tek bir alanın değerine göre ayırır. Esri belgelerinde "tek bir alanın değerlerine göre veriyi gruplamak ve her gruba farklı bağlanma, ilişki ya da topoloji kuralı atamak" şeklinde tanımlanır.

Pratik örnek: `İçmeSuyuHatti` adlı tek bir çizgi feature class içinde üç farklı hat tipi vardır — iletim, dağıtım, abone bağlantısı. Üçü için ayrı feature class yapmak yerine Hat_Tipi alanı üzerinde subtype tanımlanır:

• Subtype 1 — İletim: Cap_mm domaini 300-2000, varsayılan malzeme "Çelik", basınç sınıfı PN16-PN25
• Subtype 2 — Dağıtım: Cap_mm domaini 100-300, varsayılan malzeme "HDPE", basınç sınıfı PN10
• Subtype 3 — Abone: Cap_mm domaini 20-50, varsayılan malzeme "PEX", basınç sınıfı PN10

Aynı alana farklı subtype için farklı domain atanır. Operatör yeni bir dağıtım hattı çizdiğinde Cap_mm dropdown'unda 100-300 arası değerler çıkar; iletim hattı çizdiğinde 300-2000 arası. Subtype + domain ikilisi veri girişi sırasında kullanıcıya yol gösterir, sonradan veri temizliği iş yükünü minimuma indirir.

Subtype her zaman zorunlu değildir. Geometri ve davranış tamamen farklı katmanlar (örneğin "Yangın_Musluğu" ile "Yol") ayrı feature class'larda durur. Subtype ortak şema paylaşan ama davranışı az farklı olan nesneler içindir.

Relationship Class ile Tablo İlişkileri

İlişkisel veritabanı mantığı geodatabase'te relationship class ile kurulur. İki tablo arasında 1-1, 1-N veya N-N bağ tanımlanır.

Tapu ve Kadastro mekansal veri yönetiminde klasik örnek: `Parseller` (poligon feature class) ile `Maliyet_Listesi` (öznitelik tablosu, geometrisiz) arasında Parsel_No alanı üzerinden 1-N relationship class kurulur. Bir parselin birden fazla maliki olabilir; tablo değişse parsel kaydı bozulmaz. Harita üzerinde bir parsele tıklandığında pop-up panelinde ilişkili tüm malikler otomatik listelenir.

Relationship class tipleri:

1. Simple relationship: İki taraf bağımsız yaşar. Parsel silinse maliyet kaydı kalabilir.
2. Composite relationship: Origin (kaynak) silinirse destination (hedef) de silinir. Bina silindiğinde bağımsız bölümleri de silinmelidir; composite uygundur.
3. Attributed relationship: İlişki üzerinde kendi öznitelikleri vardır (örneğin maliyetin başlama tarihi, hisse oranı).

Relationship class kurulduğunda Pro arayüzünde feature class'ın özellikleri altında "Related Data" sekmesi açılır; seçilen nesnenin ilişkili kayıtları tek tıkla görüntülenir, düzenleme aynı pencere içinden yapılır.

Topoloji Kurallarıyla Hangi Hatalar Önlenir?

Topoloji, feature class'lar arasında geometrik olarak hangi durumların geçerli, hangilerinin hata sayılacağını tanımlar. Geodatabase topology dataset içine kurulur, içine alınan feature class'lara kurallar atanır.

Sık kullanılan kurallar:

• Must Not Overlap: Parseller birbirinin üzerine binemez — kadastro temeli.
• Must Not Have Gaps: İlçe sınırları arasında boşluk kalamaz — il sınırı tüm ilçeleri kapsamalı.
• Must Be Covered By: Bina poligonları parsel poligonu içinde kalmalı — kaçak yapı tespiti için doğal raporlama.
• Must Not Intersect: Aynı yol katmanında çizgiler kesişmez — kavşak ayrı feature class'ta tutulur.
• Endpoint Must Be Covered By: İçme suyu hattının her uç noktası bir vanaya/eke temas etmeli.
• Must Be Single Part: Bir parsel tek parçalı olmalı — bölünmüş parsel ayrı kayıt.

Topoloji validate edildiğinde hataları (error) Topoloji Errors paneline düşürür. Operatör her hatayı incelemek için "Inspect" aracını kullanır, gerçekten hata mı yoksa kabul edilebilir istisna mı kararına göre "Mark as Exception" işaretler. KGM altyapı GIS verisinde köprü ile yol katmanı kesişimi gibi durumlar exception olarak işaretlenir; gerçek hata değildir ama topoloji kuralı kesişimi yakalar.

Attribute Rules ve Arcade ile İş Kuralı

Attribute rules domain ve subtype'ı tamamlayan üçüncü katmandır; daha karmaşık iş kuralları için ArcGIS Arcade ifade dili ile yazılır. Üç tipi vardır:

1. Calculation rule: Düzenleme sırasında bir alanı otomatik hesaplar. Bir parsel poligonu çizildiğinde Alan_m2 alanı kendiliğinden geometrinin alanı kadar dolar; Tescil_Tarihi alanına bugünün tarihi yazılır.
2. Constraint rule: Geçersiz bir girişi engeller. Örneğin bir binanın inşaat tarihi parsel tescil tarihinden önce olamaz; constraint rule bunu redder ve hata mesajı verir.
3. Validation rule: Mevcut veriyi denetler — yeni girişte değil, sonradan toplu çalıştırılır. Hata bulan satırlar işaretlenir.

Calculation ve constraint kuralları immediate (düzenleme anında); batch calculation ve validation kuralları deferred (zamanlanmış toplu çalıştırma). Attribute rules için tüm feature class'ta GlobalID alanının açık olması zorunludur; batch ve validation için ek olarak editor tracking devrede olmalı.

Arcade ifadesi okunabilir, JavaScript benzeri sözdizimiyle yazılır. Bir validation rule örneği — bina yüksekliğinin imar planındaki maks. yükseklikten büyük olamayacağını denetler:

// Validation rule: Bina yüksekliği imar limitini aşamaz
var parsel = FeatureSetByRelationshipName($feature, "Bina_Parsel_iliski");
var imar_max = First(parsel).Imar_Max_Yukseklik;
if ($feature.Yukseklik_m > imar_max) {
    return {
        "errorMessage": "Bina yüksekliği imar limitini aşıyor: " + imar_max + " m"
    };
}
return true;

Bu kural belediyenin imar denetim biriminin haftalık olarak çalıştırdığı validation paketinin parçası olur. Bina veri seti büyüdükçe manuel kontrol pratiği yerine geçer.

Tasarım Akışı Adım Adım

Bir CBS biriminin yeni bir altyapı projesini geodatabase üzerine kurarken izlediği akış:

1. Varlık modeli kâğıt üzerinde: Hangi nesneler temsil edilecek? Aralarındaki ilişkiler? Yıllık veri büyümesi ne? Bu aşama hiçbir araç açılmadan biter.
2. Geodatabase tipi: File mı, enterprise mı? Tek kullanıcı varsa file; çok kullanıcı/versiyonlama gerekiyorsa enterprise.
3. Koordinat sistemi: Türkiye için ITRF96/TUREF veya ED50 3 derece Gauss-Krüger (TM30, TM33, TM36, TM39, TM42, TM45) — çalışma bölgesinin dilimi.
4. Feature dataset gruplama: Topoloji veya network gerekecekse dataset şart; basit projede atlanabilir.
5. Feature class oluşturma: Geometri tipi, alan adları ve veri tipleri.
6. Domain tanımlama: Listeler ve aralıklar geodatabase seviyesinde tanımlanır, alanlara atanır.
7. Subtype: Aynı feature class içinde davranışı farklı alt türler varsa.
8. Relationship class: Tablolar arası bağ.
9. Topoloji: Geometrik kurallar, validate edilerek hatalar temizlenir.
10. Attribute rules: Domain ve subtype'ın çözmediği iş kuralları için Arcade.
11. Veri yükleme: Mevcut shapefile, dwg, CSV verisi Conversion araçlarıyla aktarılır; alan eşlemesi domain ile uyumlu yapılır.
12. Test: Örnek veriyle yanlış giriş denenir; domain, subtype, attribute rules beklendiği gibi reddediyor mu? Edilemiyorsa kural yeniden yazılır.

Bu sıralama atlanırsa örneğin domain henüz tanımlanmadan veri yüklenir, sonra domain eklenir; mevcut yazım hatalarını domain tutmaz ve veri temizliği iki katına çıkar. Tasarımı önden bitirmek, üretime kalmadan kural koymak çok daha ucuzdur. ArcGIS Pro üzerinde uygulamalı ilerlemek ve gerçek senaryolarla pratik yapmak için ArcGIS Pro eğitimi içeriğindeki modüller adım adım yol gösterir.

En Sık Hangi Tasarım Hataları Yapılır?

Kurumsal CBS projelerinde tekrar eden hatalar bellidir ve hepsi proje ortasında geri dönüş maliyeti yüksek sorunlara dönüşür:

• File geodatabase ile başlayıp ekibe ikinci kişi geldiğinde versiyonlama eksikliğinin farkına varmak — başlangıçta enterprise değerlendirilmeli.
• Domain'i feature class içinde tanımlamak; halbuki domain geodatabase seviyesinde tanımlanır, birden fazla katmanda kullanılır.
• Subtype yerine her alt tür için ayrı feature class açmak — sembolizasyon, ilişki ve topoloji yönetimini gereksiz çoğaltır.
• Topoloji kurallarını veri yüklemeden önce kurup yüklemeyi bloke etmek — önce veriyi yükle, sonra kuralları aç ve hataları yönet.
• Attribute rule yazarken GlobalID'yi unutmak — kural eklenmez, hata mesajı kullanıcıyı yanıltır.
• Versiyonlama açıldıktan sonra schema değişikliği yapmak — replikasyon ve reconcile akışı bozulur, default version'a dönmek gerekir.
• Coordinate tolerance'i varsayılan değerlerle bırakıp kadastro hassasiyeti gerektiren projede çalışmak — köşe çakışmaları beklenmedik şekilde kümelenir.

Geodatabase tasarımı bir CAD dosyası kurmaktan çok bir veritabanı şeması tasarlamaya benzer. Belediye CBS birimleri, kadastro müdürlükleri ve altyapı kurumları için bu disiplin yıllar boyunca veriye değer katar; iyi tasarlanmış bir geodatabase başka projelere şablon olur, kurumun bilgi varlığına dönüşür. Esri'nin geodatabase üzerine yayınladığı kapsamlı belgeleri ArcGIS Pro dokümantasyon merkezinden inceleyebilir, özellikle topology rules ve attribute rules bölümlerinden kurumsal projelere kural seti uyarlayabilirsiniz.