Yazılarımız

Cadsay

NETWORK ANALYST'TE VERİ HAZIRLAMA HATALARINI ÖNLEMEK

Yol ağı segmentinde dangling node snap toleransı ve elevation farkı gösteren editör kompozisyon pale arka plan

Cuma akşamı, ulaşım planlama biriminden bir mesaj: pazartesi sabahına kadar Beşiktaş ilçesi için 8 dakikalık ambulans erişim haritası lazım. Veri 11'de geldi, 14'te Build Network çalıştı, "Build successful" mesajı ekrandaydı. Akşam saat 18'de ilk Closest Facility analizi koştuğunda Levent'in arkasındaki üç sokak hiç ulaşılamaz çıktı, Boğaziçi Köprüsü altından geçen vapur iskelesine yol "üzerinden" gidiyordu. Hata Closest Facility'de değildi — hata, 14'te "successful" diyen build log'unun atladığı dört uyarıdaydı.

Network Analyst veri kabul ettiğinde geometriyi ve özniteliği doğru sayar; build hata vermese bile veri yanlışsa sonuç sessizce yanlış çıkar. Esri'nin Network Analyst dokümantasyonu bu yüzden veri hazırlama bölümünü modülün kendisinden uzun anlatır. Veri tarafında atlanan tek bir kontrol, ihale dosyasındaki yanlış kararın, sahaya çıkmayan ambulansın veya yanlış konumlanan eczane şubesinin sessiz sebebi olur.

Build Successful Mesajı Neden Yanıltıcıdır?

Build Network aracı sonunda gelen "Build successful" yazısı tek başına anlamlı bir kalite kanıtı değildir. Esri tarafında bu durum açıkça belgelenmiştir: build, "warning 030116" tetiklenmediği sürece başarılı sayılır. Ancak warning altında onlarca farklı sebep gizlenir. Sık karşılaşılan kategoriler şunlardır:

  • Geometri uyarıları: "Geometry is empty", "feature's geometry has zero length", "a line feature has fewer than two vertices", "edge feature is too small to participate in snapping". Sıfır uzunluk veya iki vertex'ten az çizgi, build sayacında es geçilir.
  • Hierarchy uyarıları: "Invalid hierarchical value", "at least one feature should have hierarchy value 1". Yol sınıfı kolonu boşsa veya 1-5 aralığı dışında değer varsa, hiyerarşik routing sessizce devre dışı kalır.
  • Turn feature uyarıları: "Turn element already exists", "edges of the turn element are not connected", "cannot find at junction". Dönüş kısıtı çakışması veya kavşağa bağlanamayan dönüş, build başarılı görünür ama uygulanmaz.
  • Bağımsız junction uyarısı: "Standalone user-defined junction is detected". Yol ağına bağlı olmayan serbest kavşak noktası.
  • Connectivity policy eksikliği: "No connectivity policy found". Edge kaynağı için politika atanmamış.

Pratikte yapılması gereken: build çalıştırıldığında Geoprocessing penceresinin View Details butonuna basıp her warning'i tek tek okumak. Warning Log'u txt'e export etmek (Network Dataset üzerinde sağ tık > Export Build Errors) ve sayısını sıfırlamadan analize geçmemek. 100 km'lik bir İstanbul yol ağında 20-30 warning normaldir; 200-300 warning'de veri kalitesi sorgulanır.

Türkiye'de Yol Ağı Verisi Nereden Alınır?

Network Analyst için kullanılabilir yol ağı verisini hangi kaynaktan çekildiği, daha kontrol başlamadan hata olasılığını belirler. Türkiye için yaygın dört kaynak vardır:

  • MAKS (Mekansal Adres Kayıt Sistemi): Çevre, Şehircilik ve İklim Değişikliği Bakanlığı tarafından belediyelerle koordineli yürütülen sistem. Yol aksı, kapı numarası, bina poligonu içerir. Veri kalitesi belediyeden belediyeye değişir; büyük şehirlerde olgun, küçük belediyelerde topoloji boşlukları sıktır.
  • KGM (Karayolları Genel Müdürlüğü) verisi: Devlet yolu, il yolu, otoyol için referans. Şehir içi sokak ağı içermez ama şehirlerarası rotalama için omurga sağlar. Hız sınırı ve sınıf kolonları düzenli.
  • Belediye GIS birimi: İBB, Ankara Büyükşehir, İzmir Büyükşehir gibi büyük belediyeler kendi yol aksını üretir. Verinin kapsamı belediye sınırıyla biter; ilçe geçişi yapan analizde sınır kopukluğu çıkar.
  • OpenStreetMap (OSM): Topluluk verisi, ücretsiz. İstanbul, Ankara, İzmir gibi şehirlerde olgun; Doğu Anadolu küçük yerleşimlerinde eksik. Tek yön ve hız sınırı kolonu tutarsız olabilir — kaynak ne olursa olsun bu iki alan teklif öncesi denetlenir.

Karışık kaynak kullanımı — örneğin İBB sokak verisi + KGM devlet yolu birleştirme — Türkiye'de en sık görülen senaryodur. Birleştirme sırasında iki kaynağın sınırında 2-5 metrelik snap kopuklukları kalır. Build başarılı çıksa bile, KGM otoyolundan çıkıp İBB sokağına dönen analiz sınırı görmez ve rota o noktada kopar.

Connectivity Policy — Any Vertex mi, End Point mi?

Network dataset oluştururken her edge kaynağına bir bağlantı politikası atanır. Bu seçim sonucu doğrudan etkiler ve Türkiye yol ağı pratiğinde sık karıştırılır:

  • End Point: Çizgi sadece uç noktalarda diğer çizgilerle bağlanır. Tipik kullanım: köprüler, viyadükler, tüneller. Bir İstanbul köprü segmentinin altından geçen sahil yolu ile aynı XY'de buluşması bağlantı kurmaz — köprü kendi seviyesindedir.
  • Any Vertex: Çizgi her vertex'inde diğer çizgilerle bağlanabilir. Tipik kullanım: standart sokak ağı. Bir sokak ortasından başka bir sokağa kavşak çıkarsa, ortak vertex'te bağlantı kurulur.

Multimodal ağda (yol + metro + tramvay) her ulaşım türü kendi connectivity group'una atanır. Esri dokümantasyonundaki klasik örnek: Metro_Entrance junction kaynağı hem yol hem metro grup'larında yer alır; böylece yolcu sokakta yürür, metro girişinden metroya geçer, başka bir istasyonda iner. Türk şehirlerinde aynı mantık Marmaray, İstanbul metrosu, Ankara Ankaray ve İzmir Vapur hatları için kurulur.

Yaygın hata: tek bir yol kaynağına End Point politikası atayıp her sokağın sadece uç noktada bağlandığını varsaymak. Türk şehir verisinde sokaklar çoğunlukla orta vertex'lerde kavşak kurar; Any Vertex doğru seçimdir. Köprü-tünel ayrı feature class olarak End Point politikasıyla ayrı tutulur.

Snap Tolerance — Milimetre mi, Metre mi?

Network Analyst için en hassas parametrelerden biri snap toleransıdır. Esri'nin koyduğu kural net: iki çizgi crossing yapıyor ama coincident endpoint veya vertex paylaşmıyorsa, hiçbir connectivity policy onları bağlamaz. Crossing tek başına bağlantı kurmaz — geometri paylaşımı gerekir.

Snap tolerance tablosu Any Vertex End Point connectivity policy ve dangling node senaryolarını gösteren editör annotation görsel

Pratikte kullanılan tolerans bantları:

  • 0,001 m (1 mm): Veri zaten temizse vertex yapışmaları milimetre içinde. Tolerans bu seviyede tutulursa Integrate işlemi hiçbir şey birleştirmez; veri olduğu gibi kalır.
  • 0,5 m: İstanbul büyükşehir ölçeğinde güvenli başlangıç. MAKS verisi ile belediye sokak verisi birleştirildiğinde tipik kopukluklar 10-50 cm bandındadır.
  • 1 m: OSM verisi için tavsiye. Topluluk verisinde vertex hassasiyeti değişken.
  • 2-3 m: Çok riskli üst sınır. Dar sokaklı tarihi merkezlerde (İstanbul Fatih, İzmir Konak, Antep Şahinbey) farklı sokakların vertex'lerini birleştirip sahte kavşak üretebilir.
  • 5 m üstü: Yasak bant. Sokak genişliği civarında, kesinlikle ayrı olması gereken paralel sokaklar birleşir.

Pratik prosedür: önce 1 km²'lik bir pilot alanda 0,5 m toleransla Integrate çalıştır, sonucu manuel kontrol et, sonra tüm veriye uygula. Integrate işlemi geri alınamaz; veri yedeği şart. Bir başka kontrol noktası: Editing > Topology > Must Not Have Dangles kuralı. Yol uçlarındaki kopuk noktalar (cul-de-sac dışında) bu kuralla işaretlenir; analiz öncesi sıfıra indirilir.

Elevation Field Köprü ve Tüneli Nasıl Ayırır?

İstanbul Boğaziçi Köprüsü, Ankara Konya Yolu üst geçidi, İzmir Üçyol katlı kavşağı, Eskişehir tramvay altgeçidi — her büyük Türk şehrinde yol ağının düşey katmanı vardır. Bu noktalar için yatay konumda XY çakışıyor ama düşey katman ayrı. Network Analyst iki yöntemle çözer:

  • Z-coordinate (geometri tabanlı): Yol feature class'ı 3D olarak saklanır, her vertex'in Z değeri yüksekliği taşır. MAKS verisi 2D üretildiği için bu yöntem Türkiye pratiğinde nadirdir.
  • Elevation field (öznitelik tabanlı): Yol feature class'ında iki integer alan: F_ELEV (from end elevation) ve T_ELEV (to end elevation). Köprü segmentinin iki ucu için 1, altındaki sahil yolu için 0 değeri. Aynı integer değer paylaşan uçlar bağlanır, farklı değerler bağlanmaz.

Esri'nin kuralı çok net: elevation field integer olmak zorundadır. Float, double veya text alan kullanılamaz. Sebep: yükseklik seviyeleri (level 0 zemin, level 1 üst geçit, level -1 alt geçit) sayılabilir kategorilerdir, sürekli değer değil.

Türk şehir senaryosunda tipik kodlama:

  • Level 0 — zemin yol, sahil yolu, normal sokak
  • Level 1 — üst geçit, viyadük, köprü tabliyesi
  • Level 2 — ikinci kat köprü (FSM Köprüsü altındaki Marmaray hattı gibi nadir)
  • Level -1 — alt geçit, tünel (Avrasya Tüneli, Çamlıca Tüneli, Eurasia segments)
  • Level -2 — derin metro hattı

Önemli ayrıntı: elevation field yalnızca line endpoint'lerinde işler. Çizgi ortasındaki vertex'lerin elevation field değeri yoktur. Bir köprü segmentini doğru kodlamak için köprü ayrı bir line feature olmalı, başlangıç-bitiş vertex'leri köprü ucunda durmalı. Boğaziçi Köprüsü tek bir 1,5 km'lik segment olarak modellenir; ortadan kesilip iki parça yapılırsa orta vertex elevation taşımayacağı için bağlantı bozulur.

Tek Yön Kodlama — FT, TF ve Türk Şehir Yönetmeliği

Tek yön sokak kuralları her şehirde değişir. İstanbul Beyoğlu'nda turlayıp duran "İstiklal Caddesi yaya, çevresindeki sokaklar tek yön" karmaşası, Beşiktaş Barbaros Bulvarı'nın sabah-akşam zıt yön değiştiren şeritleri, Ankara Kızılay etrafındaki dönüş yasakları — bunların hepsi öznitelik tablosunda kodlanır.

Network Analyst için standart kodlama:

  • FT (From-To): Çizgi başlangıç vertex'inden bitiş vertex'ine doğru tek yön. Yön çizginin dijitize edildiği yön ile aynı.
  • TF (To-From): Çizgi bitiş vertex'inden başlangıç vertex'ine doğru tek yön. Yön çizginin dijitize edildiği yönün tersi.
  • B (Both) veya boş: Çift yön. Standart sokak.
  • N (No): Hiçbir yöne geçiş yok. Kapalı yol, tamamen yaya bölgesi.

Pratik kontrol: Symbology > Unique Values seçeneğiyle yön kolonuna renk ata (FT yeşil, TF mavi, B gri, N kırmızı). Haritayı hızlıca tarayıp İstiklal Caddesi gri görünüyorsa veride çift yön kodlanmış demektir — yanlış. Aynı şekilde Şişli Mecidiyeköy'den Mahmutbey'e giden D100 segmenti TF görünüyorsa, çizginin dijitize yönü hatalı veya kolonun değeri ters girilmiştir.

Restriction attribute olarak işaretlemek tek başına yetmez. Network Dataset Properties > Attributes > sağ tık > Restriction tipinde alan oluşturulur, sonra Travel Mode > Restrictions altında aktif edilir. İki aşamayı birden tamamlamadan tek yön kuralı çalışmaz; build başarılı görünür ama analiz tek yön kuralını uygulamaz.

Restriction ve Search Tolerance — Analiz Aşamasındaki Veri Bağı

Veri hazırlama sadece network dataset kurulumunda biten bir iş değil. Analiz aşamasında stop, facility, incident gibi nokta katmanları yol ağına snap edilirken kullanılan Search Tolerance parametresi yine veri bağlamına özgüdür.

  • Şehir merkezi (yoğun sokak ağı): 50-100 m. Adres geocoding sonucu nokta sokağa zaten yakın düşer.
  • Banliyö (orta yoğunluk): 200-500 m. Yeni gelişen mahallelerde yol ağı eksik olabilir.
  • Kırsal, çiftlik, OSB içi: 500-1000 m. OSB içindeki üretim tesisleri ana yola uzakta kalabilir.
  • Yasak bant: 5000 m üstü. Default değer 5000 m'dir, çoğu projede aşırı geniş — bir Bilecik fabrikasının teslimat noktası komşu il yolundaki segmente snap eder, gerçeklikle uyuşmaz.

Restriction attribute pratiği de analize taşınır. "Yaya yolu", "özel mülk girişi", "askeri bölge", "kapalı yol şantiye dönemi" gibi farklı restriction alanları feature class'a eklenir. Travel mode tanımında hangileri aktif olacağı seçilir: ambulans için "yaya yolu" geçilebilir, kamyon için "ağırlık sınırı 3,5 t" devrede, normal araç için sadece "kapalı yol" filtresi aktif.

Türkiye senaryosunda sık atlanan bir restriction: belediye düğüm bayram zamanı trafiğe kapatılan sokaklar. Bayram namazı sabahı bir mahalledeki ana cadde kapatılırsa, statik analiz bunu görmez; bu durum için zaman pencereli restriction veya günlük edit gerekir. Network Analyst eğitimi programında veri hazırlama tarafı bu zaman-bağımlı restriction kurgusu ve gerçek belediye verisi temizleme adımlarıyla işlenir; saha pratiği teoriden farklı çünkü Türk belediye verisinin kalite seviyesi her ilçede ayrı bir hikaye.

Build Öncesi Veri Hazırlama Checklist'i

Tek bir kontrol listesi tüm hataları kapatmaz ama büyük çoğunluğunu yakalar. Network dataset'i build etmeden önce şu sıralamayı uygulamak pratik fayda sağlar:

  1. Projeksiyon kontrolü: Feature dataset ITRF96/TM30, TM33, TM36 gibi metrik projeksiyonlu sistemde mi? Coğrafi koordinatlar (WGS84 derece) ile network dataset oluşturulmaz.
  2. Geometri temizliği: Multipart line yok mu, zero-length segment yok mu, dangling node sayısı kabul edilebilir mi (cul-de-sac dışında sıfır olmalı). Check Geometry aracı çalıştırıldı mı?
  3. Integrate sonrası snap kontrolü: 0,5 m tolerans uygulandı, manuel spot kontrol yapıldı.
  4. Topology kuralları: Must Not Have Dangles, Must Not Self-Intersect, Must Not Overlap. Hata sayısı sıfıra indirildi.
  5. Connectivity policy: Standart sokak için Any Vertex, köprü-viyadük için ayrı feature class ile End Point. Multimodal ağda connectivity group ayrımı.
  6. Elevation field: Köprü-tünel segmentlerinde F_ELEV ve T_ELEV alanları integer tipte, level 0/1/-1 kodlu.
  7. One-way kodlama: ONEWAY alanı FT/TF/B/N değerleriyle dolu, dijitize yönü ile uyumlu.
  8. Hierarchy alanı: 1 (otoyol), 2 (devlet yolu), 3 (ana arter), 4 (toplayıcı), 5 (sokak) seviyeleriyle dolu. En az bir feature'da hierarchy=1 var.
  9. Cost alanı: Length_m metre cinsinden Shape_Length ile uyumlu. Travel_time dakika cinsinden hız sınırı kolonundan türetilmiş.
  10. Build warning sayısı: 100 km segmentte 30 altında, log txt'e export edilip incelenmiş.

Bu listenin her kalemi için iki kuralla hareket etmek işi rahatlatır: her kontrol pilot bir alanda denenir, geri alınamayan işlem öncesi yedek alınır. İstanbul'un tamamı için Integrate çalıştırıp veri bozulduğunda saatlerce kayıp yaşamaktansa, önce Üsküdar'da pilot uygula, sonuç temizse Avrupa yakasına geç.

Build öncesi veri hazırlama checklist'i projeksiyon snap tolerance elevation field one-way hierarchy adımları annotation kompozisyon

Saha Tecrübesinden Pratik Notlar

  • MAKS verisi kapı numarası içerir ama yol aksı kalitesi belediye sayısallaştırma kalitesine bağlıdır; teklif öncesi 1 km² pilot örneklem alın.
  • OSM verisinde tek yön kolonu (oneway) "yes/no/-1/reversible" karışık değerler taşır; Network Analyst için FT/TF/B'ye çevirmeden build edilmez.
  • Boğaziçi Köprüsü, FSM Köprüsü, Yavuz Sultan Selim Köprüsü ayrı line segment olarak modellenir; aksi halde Marmaray, sahil yolu ve köprü tabliyesi sahte kavşak üretir.
  • Avrasya Tüneli ve Eurasia segmentleri level -1 olarak kodlanır; sahil yolu (level 0) ile çakışan XY noktasında geçiş olmamalı.
  • İBB veri portalından inen yol verisinin koordinat sistemi ED50 olabilir; ITRF96'ya dönüştürmeden TM30 feature dataset'e eklenmez.
  • İstiklal Caddesi, Mısır Çarşısı çevresi, Eminönü meydanı gibi yaya bölgeleri ayrı restriction alanı ile işaretlenir; ambulans travel mode'da geçilebilir, normal araç mode'da yasak.
  • Ankara Kızılay, Konya Mevlana, Trabzon meydanı gibi merkez dönüş yasakları Turn Feature Class olarak ayrı tutulur, öznitelik kolonu olarak değil.
  • Mahalle sınırı dışına çıkan stop noktası için Search Tolerance dar tutulursa unlocated kalır; 200-300 m bandı genelde güvenli.
  • Edit aşamasında snap on tutulur ama tolerance 0,5 m'yi geçmez; aksi halde paralel sokaklar yapışır.
  • Build çalıştırıldığında uzun sürerse — 1 milyon segment için 30 dakika+ — ya hierarchy hesaplaması ya da turn evaluator karmaşıktır; öncelikle bu iki noktayı kontrol et.

Network Analyst veri hazırlama; build successful mesajının yarattığı yanılgıyı yıkmak, warning log'unu okumayı disiplin haline getirmek ve Türkiye yol ağı verisinin kendine özgü tuzaklarını (köprü-tünel kodlama, MAKS-OSM karışımı, tek yön tutarsızlığı) baştan tanımakla başlar. Bu disiplini kuran analist, ihale dosyasındaki ambulans erişim haritasını da, eczane zinciri lokasyon analizini de, lojistik VRP modelini de gerçeğe yakın çıkarır. Veri tarafı sıkı kurulduğunda Closest Facility, Service Area ve OD Cost Matrix sonuçları zaten kendiliğinden tutarlı gelir; veri zayıf bırakılırsa hangi analiz aracı kullanılırsa kullanılsın sessiz hata zinciri kaçınılmaz olur.

 CADSAY