Network Analyst’te en sık görülen veri hazırlama hataları nelerdir?

En sık hatalar; düğüm seviyesinde bağlı olmayan yol uçları, çakışan/tekrarlı segmentler, boş veya tutarsız hız-süre alanları, yanlış tek yön kodları ve eksik dönüş kısıtlarıdır. Bu sorunlar rotayı uzatabilir, erişilemeyen alan üretebilir veya gerçek dışı kısa güzergâhlar oluşturabilir. Düzenli QA metrikleriyle bu hatalar erken yakalanmalıdır.

Kopuk yol bağlantıları servis alanı sonucunu nasıl bozar?

Kopuk bağlantı, ağın bazı bölümlerini erişilemez hale getirir veya çözümleyiciyi dolambaçlı alternatiflere zorlar. Bu durum servis alanı poligonlarını beklenmedik biçimde daraltır ya da bazı bölgelerde “delik” oluşturur. Özellikle acil hizmet senaryolarında kapsama yüzdesi düşer ve karar vericiler yanlış kapasite yatırımı yapabilir.

Hız alanı eksikse TravelTime nasıl güvenli hesaplanır?

En güvenli yöntem, yol sınıfına göre varsayılan hız sözlüğü tanımlayıp boş değerleri bu sözlükle doldurmaktır. Tek bir sabit hız vermek, şehir içi ve kırsal yolları aynılaştırarak hataya yol açabilir. Varsayılanların kaynağı dokümante edilmeli ve sürüm değiştikçe regresyon testleriyle sapma izlenmelidir.

One-way kodları farklı kaynaklarda geliyorsa ne yapılmalı?

Kurum içinde tek bir yön sözlüğü belirleyip tüm kaynakları ETL aşamasında bu sözlüğe dönüştürmek gerekir. Örneğin FT/TF/B veya 1/0 gibi değerler tek bir standarda map edilir. Sözlük dışı değerler raporlanır ve kaynağa geri bildirim verilir. Böylece analiz ekibi her seferinde aynı kuralla çalışır.

Kurumsal projede QA ve regresyon testi nasıl kurgulanmalı?

Temsil gücü yüksek “altın rota” seti seçilerek beklenen süre aralıkları ve güzergâh mantığı tanımlanmalıdır. Veri güncellemesi sonrası aynı testler otomatik çalıştırılır; sapma eşiği aşarsa sürüm geri çekilir veya veri hazırlığı düzeltilir. Buna ek olarak servis alanı kontrol noktalarıyla kapsama oranı sürüm bazında izlenebilir.

NETWORK ANALYST’TE VERİ HAZIRLAMA HATALARINI ÖNLEMEK

Network Analyst’te analiz sonuçları “yanlış” çıktığında sorun çoğu zaman çözümleyicide değil, verinin hazırlık aşamasındadır. Kırık yol bağlantıları, eksik hız alanları veya tutarsız yön bilgileri, servis alanı ve rotalama çıktısını sessizce bozar; ekipler ise hatayı en sonda, rapor teslimine yakın fark eder.

Kurumsal ölçekte veri hazırlama; tek seferlik bir temizlikten çok, standardı olan bir QA süreci kurmayı gerektirir. Böyle bir süreç kurulmadığında aynı veri seti, farklı analistlerde farklı sonuç üretir; güven kaybı ve tekrar iş yükü artar.

Bu yazı; Network Analyst’te veri hazırlama hatalarını önlemek için yol ağı topolojisini doğrulamaktan, alan ve kural standardı belirlemeye; test senaryosu tasarlamaktan, otomasyonla kontrol etmeye kadar pratik bir çerçeve sunar. Odak, tekrarlanabilir ve izlenebilir bir hazırlık hattı kurmaktır.

ArcGIS Pro Network Analyst veri hazırlığında yol bağlantı kopukluklarının ve yön alanlarının kontrol edildiği düzenleme görünümü

Yol ağı geometri bütünlüğünü doğrulamak ve kopuklukları gidermek

Başlıktan türetilen primary keyword: veri hazırlama hataları. En sık görülen sorun, yol çizgilerinin birbirine temas ediyor görünmesine rağmen düğüm (node) seviyesinde bağlanmamasıdır. Bu durum, rota hesaplarını uzatır veya erişilemeyen bölge üretir.

Dangle ve overshoot hatalarını tespit etmek ve düzenlemek

Dangle uçlar, köprü/altgeçit gibi gerçek ayrımları temsil edebileceği gibi yanlış çizim sonucu da olabilir. Overshoot/undershoot hataları ise kesişimlerde gerçek bağlantıyı engeller. Bu hataları sınıflandırmak ve “düzeltilecek” ile “kabul edilecek” listesini ayırmak gerekir.

Çakışan çizgileri birleştirmek ve snapping standardı kurmak

Çok kaynaklı yol verilerinde üst üste binen segmentler görülebilir. Bu segmentler, maliyeti ikiye katlayabilir veya “paralel yol” gibi algılanıp rotayı şaşırtabilir. Snapping toleransını proje standardı olarak tanımlamak, aynı hatanın tekrar üretimini engeller.

# Örnek: Kesişim bağlantı kontrolü için basit mantık (temsili)
# Bir uç noktanın yakınında başka bir çizgi ucu yoksa "kopuk" işaretle
def is_dangling(endpoint, nearby_endpoints, tol=0.5):
    return all(distance(endpoint, p) > tol for p in nearby_endpoints)

Alan standardı tanımlamak ve maliyet hesaplarını tutarlı kılmak

Network Analyst kararları, maliyet alanlarına dayanır. Bu alanlar tutarsız olduğunda en iyi çözümleyici bile hatalı sonuç verir. Bu nedenle hız, süre, yol sınıfı ve erişim alanları için net bir şema gerekir.

Speed ve TravelTime alanlarını standartlaştırmak ve boş değerleri yönetmek

Hız alanı (Speed_KMH) boş kaldığında süre hesabı sıfıra yaklaşabilir veya aşırı büyüyebilir. Boş değer yönetimini “varsayılan hız” ile yapmak mümkündür; ancak varsayılanın yol sınıfına göre farklılaşması daha gerçekçidir.

Yol sınıfı ve kaplama bilgisi eklemek ve senaryolaştırmak

Kırsal yollar, stabilize güzergâhlar veya dar sokaklar, aynı hızla modellenirse servis alanı şişer. Yol sınıfı veya kaplama türü alanı eklemek; farklı iş birimlerinin “şehir içi / şehir dışı” gibi senaryoları ayrı koşmasına imkân verir.

// Örnek: Varsayılan hız atama tablosu (temsili)
const defaultSpeedByClass = {
  "motorway": 90,
  "primary": 60,
  "secondary": 50,
  "residential": 30,
  "service": 20
};

Yön ve dönüş kısıtlarını tanımlamak ve erişim kurallarıyla hizalamak

Tek yön alanı yanlışsa, erişilebilirlik dramatik biçimde bozulur. Dönüş yasakları eksikse, gerçek hayatta mümkün olmayan kısa rotalar oluşur. Bu nedenle yön ve dönüş kısıtları, veri hazırlığın kritik parçalarıdır.

One-way kodlarını doğrulamak ve değer sözlüğü oluşturmak

“FT/TF/B” gibi kodlar, “1/0” gibi ikili alanlar veya metinsel değerler bir arada kullanılabilir. Kurum içinde tek bir kod sözlüğü oluşturmak ve ETL aşamasında bu sözlüğe dönüştürmek, hatayı azaltır.

Turn feature ve restriction kullanmak ve araç tipine göre ayrıştırmak

Bazı dönüş yasakları sadece belirli araç tipleri için geçerlidir. Kamyon yasağı, yükseklik sınırı veya özel izin gerektiren yol gibi kuralları restriction olarak modellemek, rotalama doğruluğunu artırır.

Yön alanı için tek sözlükte buluşmak
Dönüş kısıtı verisini kaynak bazında doğrulamak
Araç profili için ayrı restriction seti kurmak
Test rotaları ile kuralı sahada doğrulamak

QA senaryosu tasarlamak ve regresyon testini oturtmak

Veri hazırlığın kalitesi, ölçülebilir bir test setiyle güvenceye alınır. “Birkaç örnek rota baktık” yaklaşımı kurumsal üretimde yetersiz kalır. Bunun yerine küçük ama temsil gücü yüksek test senaryosu gereklidir.

Altın rota seti oluşturmak ve beklenen çıktı eşiği belirlemek

Seçili başlangıç-bitiş noktaları için beklenen süre aralığı ve güzergâh mantığı tanımlanabilir. Yeni veri güncellemesinden sonra aynı testler koşulur; sapma belirli eşiği aşarsa veri hazırlanışına geri dönülür.

Servis alanı kontrol noktaları koymak ve kapsama boşluğunu izlemek

Özellikle acil hizmette, belirli mahallelerin 10 dakikada kapsanması gibi hedefler olur. Bu mahalleler kontrol noktası olarak belirlenir; kapsama oranı düştüğünde veri güncellemesi veya kural değişimi hemen yakalanır.

Bu yaklaşımı örneklerle pekiştirmek için Network Analyst eğitimi kapsamında veri hazırlama, QA kontrol listesi ve test senaryosu birlikte kurgulanabilir.

Otomasyon kurmak ve hatayı erken yakalamak

Manuel kontrol, ölçek büyüdükçe sürdürülemez hale gelir. Basit betikler ve kontrol raporları ile hatayı daha veri üretim hattında yakalamak mümkündür. Böylece analiz ekibi, hatalı veriyi “sonuçta” değil “girişte” görür.

Kontrol raporu üretmek ve sorunları sınıflandırmak

Bağlantı kopukluğu sayısı, boş hız alanı yüzdesi, yön alanı sözlük dışı değer sayısı gibi metrikler raporlanabilir. Bu metrikleri sürüm bazında takip etmek, veri kalitesinin trendini görünür kılar.

ETL akışına kural doğrulaması eklemek ve geri bildirim döngüsü kurmak

ETL sürecinde sözlük dönüşümü ve eksik alan doldurma uygulanabilir. Ayrıca sorunlu ögeler “düzeltilecek liste” olarak kaynak ekibe döndürülür. Bu döngü, veri kalitesini her iterasyonda iyileştirir.

Network dataset QA raporunda boş hız alanları yön kodu uyumsuzlukları ve kopuk bağlantı sayıları özet tablosu

Sonuç olarak Network Analyst’te veri hazırlama hatalarını önlemek; geometri bütünlüğünü doğrulamak, maliyet alanlarını standartlaştırmak, yön ve kısıtları doğru modellemek, QA senaryosu kurmak ve otomasyonla erken uyarı üretmekle mümkün olur. Bu yaklaşım, analiz çıktılarının güvenilirliğini artırır ve kurumsal ekiplerde tekrar iş yükünü azaltır.