TEKLA STRUCTURES'DA IFC PROPERTY MAPPING YÖNETMEK

Tekla Structures'ta IFC property mapping, nesnenin taşıdığı bilgileri (şablon attribute'ları, UDA'lar, inquiry değerleri) IFC tarafındaki Property Set yapısına çeviren eşleştirme tablosudur. Bu sayfa mapping'in ne işe yaradığını, konfigürasyon dosyalarının üç katmanını (sistem, firma, proje), sıfırdan PSet kurmayı, UDA bağlamayı, IFC2x3-IFC4-IFC4.3 farkını, Türk BIM koordinasyon ortamına uyarlamayı ve export-doğrulama akışını anlatıyor. Amaç, modeldeki metadatanın IFC'ye eksiksiz düşmesi — çünkü mapping olmadan IFC dosyasında yalnızca geometri ve entity sınıfı taşınır, geri kalan bilgi aktarımda düşer.

1. IFC PROPERTY MAPPING ASLINDA NE İŞE YARAR?

Property mapping, Tekla nesnesinin sahip olduğu bilgileri — şablon attribute'ları, UDA'lar ve inquiry değerleri — IFC tarafındaki Property Set yapısına çeviren eşleştirme tablosudur. Mapping olmadan IFC dosyasında yalnızca geometri ve temel entity sınıfı taşınır; geri kalan tüm metadata aktarımda düşer. Üreticinin ürün dokümanları diyalog isimleri ve XML şeması için referans noktasıdır, sahada uygulanan ayar genelde firma şartnamesine göre özelleşir.

Pratik sonuç: Mimar Solibri ile çakıştırma yaptığında çelik kolonun ağırlığını, kaynak boyutunu, kaplama sınıfını okuyamaz. Quantity take-off motoru NetWeight alanını arar, bulamaz, metraj eksik çıkar. Property set konfigürasyon dosyası tam bu boşluğu kapatmak için var.

2. KONFİGÜRASYON DOSYALARININ ÜÇ KATMANI

Tekla, IFC export'ta üç katmandan property set okur. Bu hiyerarşi proje ofislerinin sık karıştırdığı yerdir:

• Sistem katmanı (XS_SYSTEM): Kurulumla gelen, üreticinin yayımladığı varsayılan IfcPropertySetConfigurations dosyaları. Read-only kabul edilir — buraya dokunulmaz.
• Firma katmanı (XS_FIRM): Mühendislik bürosunun veya inşaat firmasının ortak şablonu. Tüm projeler için geçerli kurumsal PSet seti burada tutulur. Genelde merkezi sunucu veya Git deposunda saklanır, modelcilere environment ile dağıtılır.
• Proje katmanı (XS_PROJECT): O projeye özel ek PSet'ler. Müşterinin istediği özel property'ler veya yapı denetçinin talep ettiği ek alanlar bu seviyeye yazılır.

Bunlara ek olarak modelin kendi klasöründe \AdditionalPsets alt dizini bulunur. Property Set Definitions diyaloğunda "Save" dediğinizde dosya buraya yazılır. Aynı PSet adı birden fazla katmanda tanımlıysa daha yakın katman (proje > firma > sistem) kazanır. Bu kuralı bilmeden yapılan override'lar "XML değişti ama IFC'de görünmüyor" tipi takılmaların başlıca nedenidir.

3. SIFIRDAN PSET NASIL KURULUR?

Export öncesi diyalog şu yolla açılır: Dosya → Export → IFC (veya IFC4) → Property sets listesinden <new> → Edit. Açılan Property Set Definitions ekranında dört adımlık bir akış işler:

1. Add property set — Yeni PSet kart oluşturulur. İsim, açıklama, hedef IFC entity'leri girilir. İsim maksimum 255 karakter; Pset_ ve Qto_ prefix'leri buildingSMART rezervi, kendi setleriniz için kullanılmaz.
2. Add property — Set içine tek tek property'ler eklenir. Her property için kaynak (template attribute veya UDA adı) ve veri tipi seçilir.
3. Veri tipi — String, Boolean, Integer, Real, Measurement, Time stamp opsiyonlarından biri. Measurement seçildiğinde conversion factor zorunlu (alan için 1E-06 mm²→m², hacim için 1E-09 mm³→m³).
4. Binding rule — PSet'in hangi IFC entity'sine bağlanacağı belirlenir. IfcBeam, IfcColumn, IfcElementAssembly gibi tek sınıf veya alt sınıflarla birlikte (subtypes="true").

Save'e basıldığında konfigürasyon model klasörü altındaki \AdditionalPsets dizinine XML olarak yazılır. Bu dosyayı versiyonlama altına almak (Git, SVN, sade bir paylaşımlı klasör) yararlı; proje yaşadıkça PSet sayısı artar, hangi alanı kimin ne zaman eklediğini izlemek revizyon disiplini gerektirir.

4. UDA VE ŞABLON ATTRIBUTE NASIL BAĞLANIR?

Projede özel UDA tanımladığınızda (örn. atölye barkodu, üretim tarihi, korozyon sınıfı) bu değerler otomatik IFC'ye düşmez. Aktarmak için Property Set Definitions içine bir satır eklemek gerekir. Çelik konstrüksiyon ofislerinde yaygın bağlamalar:

UDA isimleri büyük-küçük harf duyarlıdır. ASSEMBLY_POS ile Assembly_Pos Tekla'nın iç tablosunda farklı kayıtlardır; XML'de bir harf kayar export sessizce property üretmez. Optional flag (optional="true") işaretlenmezse Tekla, kaynak değeri boş olan nesnelerde property'yi hiç oluşturmaz — IFC dosyası şişmesin diye varsayılan davranış budur.

5. IFC2x3, IFC4 VE IFC4.3 ARASINDAKİ SEÇİM

buildingSMART üç şema sunar ve mapping kuralları her birinde farklı çalışır. Pratikte tercih şu kriterlere göre yapılır:

• IFC2x3 Coordination View 2.0 — En yaygın versiyon, hemen her viewer destekler. Mimari ofislerin büyük çoğunluğu hâlâ bu şemayı bekler. Property tarafı sade, çelik metadata için yeterli ama parametre zenginliği sınırlı.
• IFC4 Reference View / Design Transfer View — Property template kavramı, çevresel etki property'leri, geliştirilmiş quantity tanımları. Kamu yapı işleri ihalelerinde son birkaç yıldır talep artıyor; Çevre ve Şehircilik Bakanlığı BIM yönergesi taslakları IFC4 referansı veriyor.
• IFC4.3 — Demiryolu, köprü, port gibi infra projeleri için genişletilmiş şema. Yapı binası projelerinde henüz yaygın değil, mega altyapı işlerinde gündemde.

Pratik tavsiye: Şartnamede şema belirtilmemişse mimariye sorulur, atölye eldeki ana sanayinin alıştığı versiyon teyit edilir. İki şema birden export etmek (aynı modelden hem IFC2x3 hem IFC4) yapılabilir, ancak mapping XML'leri her şema için ayrıdır; aynı XML iki şemada çalışmaz.

6. TÜRK BIM KOORDİNASYON ORTAMINA UYARLAMA

Türk yapı sektöründe son birkaç yıldır kamu mega projelerinde (yeni havalimanı terminalleri, şehir hastaneleri, raylı sistem hatları) BIM koordinasyon ekipleri standart hale geldi. Bu ekiplerde işveren tarafında BIM yöneticisi, kontrol mühendisi ve müşavir BIM koordinatörü oturur; yüklenici tarafında disiplin BIM sorumluları model üretir. IFC köprüsü bu iki taraf arasında günde defalarca geçiş yapar.

Türk ekipler için property mapping kurulurken dikkat edilen noktalar:

• CDE entegrasyonu: Trimble Connect, Autodesk Construction Cloud veya benzeri ortak veri ortamına yüklenen IFC'lerin property'leri filtreleme/sorgulama için kullanılır. Mark numarası, yapım grubu, montaj tarihi gibi alanlar CDE'nin metadata indeksine düştüğünde proje yöneticisi yüz binlerce parça içinden "3. blok 5. kat hazır olmayan kolonlar" sorgusunu yazabilir hale gelir.
• ÇŞB BIM yönergesi uyumu: Yönergedeki yapı elemanı sınıflandırması ve LOD seviyeleri PSet'lere yansıtılır. Yapı denetimi raporlamasında talep edilen alanlar (yapım yılı, yapı sınıfı, taşıyıcı eleman tipi) ayrı bir PSet altında derli toplu tutulur.
• Türkçe karakter: Property değerlerinde Türkçe karakter (ş, ğ, ç, ı, ö, ü) yer alıyorsa export kodlamasının UTF-8 olduğundan emin olun. Eski viewer'lar ANSI okuduğunda "çelik" → "çelik" mojibake'i görünür; mimari ofis bunu modelin sorunu sanır.
• Müşavir checklist'i: Büyük projelerde müşavir BIM ekibi her teslim öncesi PSet kontrol listesi gönderir — şu 14 alan dolu mu? Modelin hazır olup olmadığını gösteren bu sayfa property mapping'in işveren tarafından gözlemlenebilir tek aynasıdır.

Property mapping konusunu detaylı pratikle pekiştirmek isteyenler için Tekla Structures eğitiminin IFC modülü, baştan bir konfigürasyon dosyası kurup farklı viewer'larda doğrulama yapma akışını içerir.

7. EXPORT VE DOĞRULAMA AKIŞI

Konfigürasyon hazır, mapping kuralları yazıldı — export adımına geçilir:

1. Dosya → Export → IFC menüsünden export panelini açın.
2. Export type alanından hedef şemayı seçin (Coordination view 2.0, Surface geometry, Steel fabrication view veya IFC4 varyantları).
3. Property sets listesinden hazırladığınız özel konfigürasyon dosyasını seçin. Birden fazla mapping varsa diyalog hangisinin aktif olduğunu gösterir.
4. Base quantities seçeneğini işaretleyin — hacim, alan, net ağırlık gibi geometrik miktarlar otomatik olarak BaseQuantities grubu altına yazılır, viewer'ların ayrı ayrı hesaplamasına gerek kalmaz.
5. Location by GUID veya Shared coordinates seçeneğini projenin koordinat sistemine göre belirleyin. Mimar ile aynı origin kullanılmazsa modeller üst üste binmez.
6. Export'tan sonra dosyayı en az iki bağımsız viewer'da açın — Solibri Anywhere ile usBIM.viewer+ veya FZK Viewer kombinasyonu pratik. Aynı dosyayı iki ayrı okuyucu farklı yorumlarsa export tarafında bir uyumsuzluk vardır.

Doğrulama adımı kritik. Tekla'nın kendi IFC viewer'ı export'u kendi yazdığı gibi okuyacağı için yanılgıyı yakalamaz. Rastgele bir kolon seçin, property panelinde tanımladığınız tüm PSet'lerin geldiğini, değerlerin dolu olduğunu, veri tiplerinin (sayı sayı, tarih tarih) doğru göründüğünü kontrol edin.

8. MAPPING ÇALIŞMAZSA NE YAPILIR?

Property görünmüyor — şu sırayla bakın, çoğu durumu çözer:

• Konfigürasyon dosyası export diyaloğunda gerçekten seçili mi? Listede görünüyor ama radyo butonu başka bir konfigürasyonda olabilir.
• PSet'in binding rule'unda hedef IFC entity tanımlı mı? IfcBeam bağladınız ama nesne Tekla'da IfcMember olarak çıkıyor olabilir.
• UDA adı XML'de harf harf doğru mu? Tekla case-sensitive okur, isim eşleşmezse property hiç üretilmez.
• Kaynak değer modelde gerçekten dolu mu? Inquiry ile bir parçanın UDA değerini görüntüleyin. Boş ise mapping kabahatli değil, asıl veri eksik.
• XML syntax hatası var mı? Kapanmamış tek bir tag tüm dosyayı geçersiz kılar; Tekla başlangıçta dosyayı reddetmiş olabilir.
• Üç katman çakışması — sistem, firma, proje seviyesinde aynı PSet adı farklı tanımlı olabilir. Yakın katman kazanır; beklenmedik davranış gördüğünüzde hiyerarşiyi izleyin.
• Mapping XML değişikliğinden sonra Tekla yeniden başlatıldı mı? Konfigürasyon dosyaları başlangıçta belleğe yüklenir; çalışırken yapılan değişiklikler her zaman anında yansımaz.

Mapping küçük bir XML olarak görünür ama proje yaşadıkça büyür ve sahiplenilmesi gereken bir konfigürasyon varlığına dönüşür. Model dosyalarını nasıl yedekliyorsanız, versiyonluyorsanız, gözden geçiriyorsanız property set konfigürasyonuna da en az o disiplini uygulamak gerekir — IFC'nin BIM koordinasyonunda ne kadar işe yarayacağı tam buradaki özene bağlıdır.