POİNT CLOUD İLE AS BUİLT MODELLEME SÜRECİNİ YÖNETMEK

As built modelleme, “mevcut durum”u konuşmanın en hızlı yoludur; ama yalnızca modelin güzel görünmesi yetmez. Sahadan gelen point cloud verisi doğru yönetilmezse, model hatayı cilalar ve proje kararları yanlış zemine oturur.

Kurumsal projelerde en büyük risk, ekiplerin farklı toleranslarla çalışmasıdır. Bir ekip için kabul edilebilir sapma 10 mm iken, başka ekip 30 mm ile ilerleyebilir. Bu belirsizlik; keşif, revizyon ve hakediş süreçlerinde ölçüye dayalı güveni zayıflatır.

Bu rehber; point cloud ile as built modelleme sürecini uçtan uca yönetmek için veri toplama, registrasyon, temizleme, segmentleme, modelleme standardı, kalite raporu ve teslim paketi adımlarını kurgular. Amaç, tekrar üretilebilir bir akışla, her sprintte aynı kaliteyi yakalamaktır.

As built model hedeflerini tanımlamak ve kapsamı netleştirmek

Başlıktan türetilen primary keyword: as built modelleme. Süreç, “hangi kararlar bu modelle alınacak” sorusuyla başlar. Tasarım revizyonu mu, işletme-bakım mı, metraj mı, yoksa uyumsuzluk analizi mi? Amaç net değilse kalite kriteri de net olmaz.

LOD ve tolerans sözlüğünü oluşturmak ve ekipçe benimsemek

LOD, modelin detay seviyesini tanımlar; tolerans ise point cloud ile model arasındaki kabul edilebilir sapmayı sınırlar. Örneğin mekanik hatlarda 5–10 mm hedeflenirken, kaba mimaride daha esnek aralıklar görülebilir. Her disiplin için tolerans sözlüğü yazılmalı ve sprint başında sabitlenmelidir.

Teslimat formatını belirlemek ve paydaş beklentisini hizalamak

Model teslimi yalnızca bir BIM dosyası değildir; kontrol raporu, sınırlandırılmış bulut, koordinat referansı ve sürüm notu da teslim paketinin parçasıdır. Paydaşların hangi yazılımlarla tüketim yapacağı belirlenirse, gereksiz dönüşüm ve veri kaybı azaltılır.

• Kapsam sınırını çizmek ve dışarıda kalanları yazmak
• Tolerans sözlüğünü disiplin bazında standartlaştırmak
• LOD hedeflerini sprint çıktısına bağlamak
• Teslim paketi içeriklerini baştan tanımlamak

Registrasyon ve koordinat çerçevesini oturtmak ve sapmayı izlemek

As built sürecinde registrasyon kalitesi, modelin temelidir. Koordinat sistemi, datum ve birim standardı net değilse; model ile saha arasında “doğru gibi görünen” ama gerçekte kaymış bir ilişki oluşur. Bu aşamada kullanılan secondary keyword örnekleri: registrasyon doğrulama, kontrol noktası, koordinat dönüşümü, sapma analizi.

GCP ve check point ayrımını kurmak ve raporlamak

Kontrol noktalarının bir kısmı çözümü bağlamak (GCP), bir kısmı bağımsız doğrulamak (check point) için ayrılmalıdır. Aynı noktaları iki amaçla kullanmak, hatayı olduğundan küçük gösterir. Check point residual değerleri, sprint sonunda kalite kapısının ana girdisi olmalıdır.

Loop closure kurgulamak ve uzun eksen driftini sınırlamak

Uzun koridorlar ve geniş alanlarda drift birikimi artar. Kapanma döngüsü (loop closure) oluşturmak ve başlangıç-bitiş farkını izlemek, sapmayı erken görünür kılar. Kapanma yoksa segment bazlı çözüm ve aralıklı kontrol noktası yaklaşımı tercih edilmelidir.

# Örnek: Check point residual özetini üretmek (temsili)
def residual_summary(residuals_mm):
    n = len(residuals_mm)
    mean = sum(residuals_mm) / n if n else 0
    mx = max(residuals_mm) if n else 0
    return {"count": n, "mean_mm": round(mean, 2), "max_mm": round(mx, 2)}

Point cloud temizlemek ve sınıflandırma kurgusunu yerleştirmek

Ham veri, modelleme için çoğu zaman fazla gürültülüdür. Yansıma, cam, hareketli nesne ve düşük yoğunluklu alanlar; yanlış çizim ve hatalı yüzey üretir. Bu aşamada secondary keyword örnekleri: outlier temizleme, noise azaltma, voxel downsample, sınıflandırma.

Outlier ve hareketli nesneleri ayıklamak ve stabil taban üretmek

İnsan, araç ve şantiye ekipmanları taramalar arasında yer değiştirir. Bu nesneleri bulutta bırakmak, modelleyenin yanlış referansa tutunmasına neden olur. Temizleme; kaba outlier filtresi, sonra hareketli sınıf ayıklaması şeklinde iki katmanlı yapılmalıdır.

Bulutu segmentlemek ve çalışma alanlarını mantıksal parçalara ayırmak

Tek parça dev bulut, hem performansı düşürür hem de ekip içi paralel çalışmayı zorlaştırır. Bina katı, zon, disiplin veya grid bazlı segmentleme yapılırsa; sorumluluk netleşir ve versiyon kontrolü kolaylaşır. Segment isimlendirme standardı, model dosyası standardıyla aynı dilde tutulmalıdır.

// Örnek: Segment isimlendirme şablonu (temsili)
// Proje-Kat-Zon-Disiplin-Sürüm
function segmentName(project, floor, zone, discipline, version) {
  return `${project}-${floor}-${zone}-${discipline}-v${version}`;
}

Modelleme standardını belirlemek ve ölçülebilir kalite kapısı koymak

As built modelleme, “buluta bakıp çizmek” değildir; ölçülebilir bir hedefe ulaşmaktır. Burada secondary keyword örnekleri: deviation heatmap, clash kontrol, kalite raporu, teslim kriteri.

Modelleme kararlarını yazmak ve belirsizliği azaltmak

Silindirik boru mu, gerçek eğri yüzey mi? Çelik profil köşe pahı dahil mi? Bu tür kararlar yazılı hale getirilmezse, ekip her sprintte yeniden yorum yapar. Standart doküman; hangi elemanın nasıl temsil edileceğini ve hangi toleransla onaylanacağını tanımlamalıdır.

Kalite eşiğini uygulamak ve sapma haritasını rutinleştirmek

Kalite kapısı; belirli bölgelerdeki maksimum sapma, ortalama sapma ve check point residual limitleriyle tanımlanabilir. Sapma haritası (deviation heatmap) ile problemli zonlar hızlıca görülür. Bu sayede modelin “iyi” olması değil, kabul kriterini sağlaması hedeflenir.

İş akışını otomatikleştirmek ve sürüm yönetimiyle izlenebilirlik sağlamak

Kurumsal takımların verim artışı, manuel adımların azalmasıyla gelir. Aynı projede onlarca teslim döngüsü olduğunda, otomasyon küçük kazançları büyük zamana çevirir. Secondary keyword örnekleri: pipeline otomasyonu, versiyonlama, metadata.

Metadata üretmek ve her çıktı için iz bırakmak

Her bulut segmenti ve her model dosyası; kaynak tarama tarihi, koordinat referansı, kullanılan filtreler ve registrasyon sürümü gibi metadata taşımalıdır. Bu iz, daha sonra “hangi veriyle üretildi” sorusunu saniyeler içinde yanıtlar ve hatalı çıktının kök neden analizini kolaylaştırır.

Değişiklik günlüğü tutmak ve teslim paketi standardını sabitlemek

As built teslimi, çoğu zaman tasarım ekibinin ve saha ekibinin aynı anda kullandığı canlı bir varlıktır. Değişiklik günlüğü; hangi zon güncellendi, hangi tolerans uygulandı, hangi sorun kapandı gibi bilgileri taşır. Bu sayede karar vericiler, modelin güvenilirliğini sürdürülebilir biçimde izler.

1. Bulut segmentlerini versiyonlamak ve isim standardını korumak
2. Kalite metriklerini otomatik rapora dökmek
3. Teslim paketi içeriğini tek şablonda üretmek
4. Onay sonrası arşiv sürümünü kilitlemek

Bu yaklaşımı kurum içinde standartlaştırmak için point cloud eğitimi kapsamında registrasyon doğrulama, segmentleme, kalite raporu ve teslim paketi kurgusu birlikte ele alınabilir.

Sonuç olarak as built modelleme sürecini yönetmek; hedef ve toleransı netleştirmek, registrasyonu ölçüyle doğrulamak, bulutu temizleyip segmentlemek, modelleme kararlarını standardize etmek ve kalite kapısını raporlamakla mümkün olur. Bu sistem kurulduğunda, her teslim döngüsü daha hızlı ilerler ve modelin karar destek gücü artar.