یک مدل ساختمان واحد برای GIS شهری سه بعدی

چکیده

امروزه چندین کار در طراحی شهری و معماری در یک زمینه جغرافیایی انجام می شود. مدل‌های اطلاعات ساختمان (BIM) و فناوری‌های مکانی، مدل‌های داده سه‌بعدی را ارائه می‌کنند که اطلاعاتی درباره ساختمان‌ها و محیط اطراف ارائه می‌دهند. کلاس های بنیاد صنعت (IFC) و CityGML امروزه دو مدل معنایی برجسته به ترتیب برای نمایش مدل های BIM و مکانی هستند. CityGML به عنوان یک استاندارد برای مدل‌سازی مدل‌های شهر ظهور کرده است در حالی که IFC به عنوان یک مدل مرجع برای ساخت اشیاء و سایت‌ها توسعه یافته است. CAD فعلی و نرم افزارهای جغرافیایی ابزارهایی را ارائه می دهند که امکان تبدیل اطلاعات از یک فرمت به فرمت دیگر را فراهم می کند. با این حال، این ابزارها نسبتاً در قابلیت های خود محدود هستند، که اغلب منجر به از دست رفتن داده ها و اطلاعات در تحولات می شود. این مقاله یک رویکرد جدید برای یکپارچه سازی داده ها بر اساس یک مدل ساختمان یکپارچه (UBM) توصیف می کند که هر دو مدل CityGML و IFC را در بر می گیرد، بنابراین از ترجمه بین مدل ها و از دست دادن اطلاعات جلوگیری می کند. برای ساخت UBM، ابتدا تمام کلاس‌ها و مفاهیم مرتبط از هر دو مدل جمع‌آوری شد، مفاهیم همپوشانی با هم ادغام شدند، اشیاء جدیدی برای اطمینان از گرفتن اشیاء داخلی و خارجی ایجاد شدند و در نهایت، روابط فضایی بین اشیا دوباره تعریف شد. از نمادهای زبان مدلسازی یکپارچه (UML) برای نمایش اشیا و روابط بین آنها استفاده شد. دو سناریو مورد استفاده وجود دارد که هر دو در یک بیمارستان تنظیم شده‌اند: «تخلیه» و «تخصیص فضا برای بخش‌های بیماران» برای اعتبارسنجی و آزمایش مدل داده‌های UBM پیشنهادی توسعه داده شد. بر اساس این دو سناریو، چهار پرسش اعتبارسنجی به منظور اعتبارسنجی مناسب بودن مدل ساختمان یکپارچه پیشنهادی تعریف شد. از طریق سناریوهای موردی و چهار پرس و جو تأیید شده است که UBM در حال توسعه می‌تواند داده‌های CityGML و همچنین داده‌های IFC را به روشی ظاهراً یکپارچه ادغام کند. محدودیت ها و توابع غنی سازی برای پر کردن جداول و فیلدهای خالی پایگاه داده استفاده می شود. سناریوهای انگیزشی نیز نیازها و مزایای داشتن یک رویکرد یکپارچه برای مدل‌سازی ویژگی‌های فضایی داخلی و خارجی را نشان می‌دهند. محدودیت ها و توابع غنی سازی برای پر کردن جداول و فیلدهای خالی پایگاه داده استفاده می شود. سناریوهای انگیزشی نیز نیازها و مزایای داشتن یک رویکرد یکپارچه برای مدل‌سازی ویژگی‌های فضایی داخلی و خارجی را نشان می‌دهند. محدودیت ها و توابع غنی سازی برای پر کردن جداول و فیلدهای خالی پایگاه داده استفاده می شود. سناریوهای انگیزشی نیز نیازها و مزایای داشتن یک رویکرد یکپارچه برای مدل‌سازی ویژگی‌های فضایی داخلی و خارجی را نشان می‌دهند.

کلید واژه ها:

IFC _ CityGML ; UBM ; مدل یکپارچه ساختمان ; مدل سازی سه بعدی شهر

1. مقدمه

مدل شهر سه بعدی به طور کلی به عنوان نمایش دیجیتالی سطح زمین و محیط ساخته شده در یک شهر تعریف می شود. با استفاده از این مدل‌ها، برنامه‌های متنوعی ممکن است ایجاد شود که کل شهر یا یک مدل ساختمان خاص متمرکز را پوشش دهد. همانطور که مدل ها دقیق تر می شوند، روابط بین اشیاء فضایی باید مدل شود [ 1 ]. مدل های سه بعدی شهر در دو نوع طراحی و مدل های دنیای واقعی هستند. در حالی که مدل های طراحی توسط صنعت معماری، مهندسی و ساخت و ساز (AEC) استفاده می شود، مدل های دنیای واقعی معمولاً توسط صنعت اطلاعات مکانی (صنعت نقشه برداری) استفاده می شود [ 2 ]]. در نتیجه، مدل‌های طراحی معمولاً بر اساس حداکثر سطوح موجود از جزئیات نمایش هندسی هستند، در حالی که مدل‌های دنیای واقعی بر اساس الزامات مربوط به کار نقشه‌برداری (هزینه، پوشش و غیره ) هستند.

تمرکز فعلی مدل های شهر سه بعدی امروزی بر نمایش اشیاء هندسی و انواع عناصر است. این از استفاده از مدل های سه بعدی شهر عمدتاً برای اهداف تجسم پشتیبانی می کند. با این حال، بسیاری از برنامه‌های GIS از پرس‌و‌جوهای موضوعی، عملیات تحلیل، مدل‌سازی شبیه‌سازی و داده‌کاوی مکانی استفاده می‌کنند که نیاز به نمایش موجودیت‌ها و ویژگی‌های غیرمکانی در میان آنها دارد [ 3 ]. اگرچه برخی از پزشکان استدلال می کنند که تجسم بیشتر نیازهای کاربردی امروزی را برآورده می کند، مناطق مهم برنامه از داده های غنی تر بهره مند می شوند. نمونه هایی از این کاربردها عبارتند از برنامه ریزی شهری، تجزیه و تحلیل ساخت و ساز ساختمان، امنیت داخلی، مدیریت املاک و مستغلات، و آمادگی اضطراری و غیره [ 4 ، 5 ، 6 ]].

از منظر فنی، استفاده مجدد از اطلاعات برای ساخت برنامه های کاربردی بر اساس مدل های شهر سه بعدی مورد نیاز است. با افزایش تعداد کاربردهای فضایی، نیاز به استانداردهای ارتباطی مشترک آشکار می شود [ 3 ]. به عنوان مثال، در حوزه صنعت ساختمان، چندین سال تحقیق و توسعه منجر به توسعه مدل سازی اطلاعات ساختمان (BIM) شده است. BIM امروزه به عنوان یک حوزه تحقیقاتی مهم برای مقابله با مشکلات مربوط به یکپارچه سازی اطلاعات و قابلیت همکاری شناخته شده است [ 7 ]. به دنبال این تلاش ها، کلاس های بنیاد صنعت (IFC) به عنوان یک استاندارد مدل مرجع برای صنعت ساختمان توسعه داده شده است [ 8 ]]. استاندارد IFC تنها نشان دهنده و مدل سازی اجزای ساختمان نیست. همچنین از فرآیندهای پیشرفته مختلف و تحلیل‌های مبتنی بر روابط فضایی بین این مؤلفه‌ها پشتیبانی می‌کند. این فرآیندها را می توان به موقع برای فعالیت های مختلف برنامه ریزی کرد. اشیاء مختلف توسط موجودیت های پایگاه داده نشان داده می شوند که با ویژگی هایی مانند نام، هندسه، مواد و غیره مشخص می شوند [ 9 ]. در زمینه اطلاعات مکانی، CityGML به عنوان یک استاندارد مدل جغرافیایی توسعه یافته است که هندسی و همچنین موجودیت ها و روابط غیر فضایی بین موجودیت ها را نشان می دهد. با اجرای آن به عنوان یک طرح کاربردی برای زبان نشانه گذاری جغرافیایی 3 (GML3)، CityGML برای مدل سازی در فضای باز در سطوح مختلف جزئیات مناسب تر در نظر گرفته می شود [ 10 ]]. IFC و CityGML با توجه به توانایی آنها در مدل سازی اشیاء فضایی با توجه به موجودیت ها و ویژگی های هندسی و غیر فضایی، امروزه به عنوان دو مدل معنایی برجسته برای نمایش طراحی و اشیاء شهری در دنیای واقعی دیده می شوند [ 11 ].

این مقاله بر روی ادغام مدل‌های IFC و CityGML تمرکز دارد. انگیزه این کار، برنامه های توسعه بیمارستان در نورتله، سوئد است، جایی که شهر مشتاقانه منتظر گسترش خدمات ارائه شده توسط بیمارستان است. شهر نورتله در بخش شمالی شهرستان استکهلم واقع شده است و بیمارستان نورتله بزرگترین بیمارستان شهرداری است که به بیش از 120000 نفر خدمات ارائه می دهد. تمام ساختمان های بیمارستان در شهرداری متعلق به Locum AB است. بر اساس قرارداد سطح خدمات بین شهرداری و Locum AB، درخواست تمدیدهای مورد نیاز به Locum AB ارسال شده است. طراحان و سازمان های معماری مختلف طرح هایی را در یک رقابت آزاد پیشنهاد می کنند.

شایان ذکر است که در سال 2009 Locum AB تصمیم گرفت استاندارد IFC را در تمام ساختمان های عمومی جدید خود بپذیرد تا اطلاعات داخلی بیشتر و با کیفیت بهتری در مورد ساختمان بیمارستان خود داشته باشد. بیمارستان شهر نورتله اولین بیمارستانی بود که بر اساس IFC آزمایش و الگوبرداری شد. از این رو Locum AB مدل فعلی IFC ساختمان بیمارستان را در اختیار تمامی رقبا قرار داده و الحاقات جدید را نیز در قالب یکسانی در نظر گرفته است. این طرح های مختلف باید در برابر تعدادی از معیارهای تحمیل شده توسط مقامات برای ساختمان های بیمارستان مورد آزمایش قرار گیرند. برخی از این معیارها به وضوح به اطلاعاتی از طراحی ساختمان و همچنین اطلاعاتی از محیط اطراف و ساختمان ها نیاز دارند. از این رو، کمیته ای که مسئول ارزیابی طرح است، اطلاعاتی در مورد محیط اطراف از شهر Norrtälje درخواست کرده است. این شهر دارای مجموعه داده های جغرافیایی کاملی از شهر نورتله است که بر اساس داده های گرفته شده توسط فناوری های فتوگرامتری و اسکن لیزری است. این داده‌های شهر در حال حاضر در قالب CityGML سطح 2 برای کل شهر ذخیره می‌شوند. با این حال، سطوح دقیق تر (سطوح 3 و 4) برای مناطق متمرکز خاص در دسترس هستند. پس از جمع آوری داده ها در مورد محیط اطراف، تیم ارزیابی باید از طراحی IFC و اطلاعات CityGML برای محیط ساخته شده اطراف استفاده کند تا بهترین طرح را بر اساس مجموعه ای از معیارهای زیر ارزیابی کند: بر اساس داده های گرفته شده توسط فناوری های فتوگرامتری و اسکن لیزری. این داده‌های شهر در حال حاضر در قالب CityGML سطح 2 برای کل شهر ذخیره می‌شوند. با این حال، سطوح دقیق تر (سطوح 3 و 4) برای مناطق متمرکز خاص در دسترس هستند. پس از جمع آوری داده ها در مورد محیط اطراف، تیم ارزیابی باید از طراحی IFC و اطلاعات CityGML برای محیط ساخته شده اطراف استفاده کند تا بهترین طرح را بر اساس مجموعه ای از معیارهای زیر ارزیابی کند: بر اساس داده های گرفته شده توسط فناوری های فتوگرامتری و اسکن لیزری. این داده‌های شهر در حال حاضر در قالب CityGML سطح 2 برای کل شهر ذخیره می‌شوند. با این حال، سطوح دقیق تر (سطوح 3 و 4) برای مناطق متمرکز خاص در دسترس هستند. پس از جمع آوری داده ها در مورد محیط اطراف، تیم ارزیابی باید از طراحی IFC و اطلاعات CityGML برای محیط ساخته شده اطراف استفاده کند تا بهترین طرح را بر اساس مجموعه ای از معیارهای زیر ارزیابی کند:

طرح تخلیه : این معیار بیان می کند که همه افراد از جمله معلولان باید در یک بازه زمانی مشخص – دو دقیقه در مواقع اضطراری – تخلیه شوند. در مورد یک ساختمان واحد، تیم طراحی باید همه مکان‌های فضایی را در مقابل آزمایش کندنزدیک ترین خروجی های ممکن ماتریسی از زمان تخلیه بین تمام فضاها و خروجی های احتمالی در ساختمان باید ایجاد شود. این فرآیند با تعریف تمام فضاهای داخل ساختمان IFC (شامل تمام طبقات) و اتصال آنها به خروجی های احتمالی آغاز می شود. خروجی های احتمالی شامل کلیه درهای مناسب، پنجره هایی که به عنوان خروجی مناسب باز می شوند و همچنین خروجی های روی پشت بام ساختمان های مجاور که می توان از آنها برای تخلیه افراد استفاده کرد. علاوه بر این، خروجی های احتمالی باید به فضاهای مناسب اطراف (مانند مناطق باز، باغ ها، ایمن، سقف های مجاور هموار، دور از جاده های اصلی ترافیک و غیره محدود شود..). اطلاعات مورد نیاز برای معیارهای فوق الذکر نیازمند اطلاعاتی هم از طراحی داخلی ساختمان (برای تخصیص فضاها و خروجی های احتمالی) و هم از محیط خارجی (شامل اطلاعات ساختمان های اطراف و کاربری آنها، سقف های مجاور، ترافیک، فضاهای بیرونی احتمالی و … است. مناطق سبز).
استقرار در بخش بیماران : برای تحقق برنامه آینده، بیمارستان نیاز به اضافه کردن بخش بیماران برای 250 تخت دارد. این معیار اکیداً توصیه می‌کند که فاصله بخش‌ها با ترافیک سنگین یا مکان‌های پر سر و صدا حداقل 300 متر باشد، یعنی بخش بیمار نزدیک به مکان‌های پر سر و صدا توصیه نمی‌شود. طراحی باید در برابر محیط اطراف از نظر آلودگی صوتی آزمایش شود. این فرآیند با ایجاد حفاظ های 300 متری در اطراف تمام نقاط نویز در محیط اطراف (مثلاً ترافیک سنگین) و همچنین فعالیت های پر سر و صدا (مانند کارگاه ها، مدارس، رستوران ها و غیره ) شروع می شود. سپس موقعیت‌ها و فضاهای بخش‌های بیمار که به تازگی طراحی شده‌اند، در مقابل آزمایش می‌شونداین بافرها برای تصمیم گیری در مورد مناسب بودن طراحی خود. در برخی موارد، فاصله 300 متری برای تمام اتاق های بیمار دشوار است. بنابراین، جایگزین های پشتیبان دیگری در نظر گرفته می شود. این جایگزین ها شامل ساخت فواره ها یا کاشت درختان برای کاهش صدای خارجی است. این فرآیند همچنین به داده‌های طراحی داخلی (برای بخش‌های بیمار) و مدل پایگاه جغرافیایی شهر در فضای باز (برای فعالیت‌های اطراف، کاربری زمین و ساختمان‌ها) نیاز دارد.

در مواردی که در بالا توضیح داده شد، اطلاعاتی در مورد فضای داخلی ساختمان و همچنین محیط بیرونی مورد نیاز است. با این حال، انتقال داده ها از یک جهان به جهان دیگر گزینه ای نیست زیرا باعث از دست رفتن داده ها می شود. دو مثال: اطلاعاتی که ممکن است هنگام تبدیل از CityGML از بین برود، شامل اطلاعاتی در مورد خیابان های اطراف است، زیرا نمی توان آن را در IFC نشان داد. و ثانیاً، اطلاعات مربوط به عناصر ساختمان مانند دیوارها و جزئیات درها و پنجره‌هایی که از IFC به CityGML می‌آیند، ممکن است در مدل CityGML گم شوند. بنابراین، یک رویکرد جدید برای یکپارچه سازی داده های IFC و CityGML و ارائه اطلاعات به موارد فوق مورد نیاز است.

هدف این مقاله توصیف یک مدل ساختمان یکپارچه (UBM) است که هر دو مدل CityGML و IFC را در بر می گیرد، بنابراین از ترجمه بین مدل ها و از دست دادن اطلاعات جلوگیری می کند. چهار پرسش اعتبار سنجی تعریف شده است که به ما امکان می دهد تا مناسب بودن مدل ساختمان یکپارچه پیشنهادی را تأیید کنیم، یعنی:

Q.1. پنجره های احتمالی در یک طبقه خاص را که می توان در شرایط اضطراری به درب تبدیل کرد یا به سقف ساختمان مجاور دسترسی داشت را تعریف کنید.
Q.2. درهایی را که به محیط بیرونی ساختمان دسترسی دارند پیدا کنید و کاربرد فضای بیرونی قابل دسترسی را تعریف کنید.
Q.3. ساختمان های اطراف را که کاربری صنعتی دارند و در فاصله 300 متری از محل توسعه بیمارستان قرار دارند را بیابید.
Q.4. مناطق بیرونی را انتخاب کنید که دارای درخت هستند یا می‌توان آن‌ها را با آبنما یا مهارکننده‌های صدا کاشت و مبله کرد.

2. پیشینه تحقیق

2.1. مدل ساختمان IFC

IFC یک قالب شی گرا است که توسط اتحاد بین المللی برای تعامل (IAI) [ 12 ] توسعه یافته است. برای تسهیل قابلیت همکاری در صنعت ساختمان و به اشتراک گذاری اطلاعات بین شرکت کنندگان استفاده می شود. IFC ها برای جمع آوری مدل های قابل خواندن کامپیوتری استفاده می شوند که حاوی عناصر داده ای هستند که بخش هایی از ساختمان ها و اطلاعات مربوط به آنها را نشان می دهند [ 13 ]. با این حال، هیچ مدل ساختمانی پذیرفته شده جهانی برای IFC وجود ندارد [ 14 ]. در این بخش یک مدل ساختمان IFC را ارائه می کنیم که اساساً بر اساس کار انجام شده توسط IAI و ISO در قالب مستندات استاندارد IFC [ 12 ]، استاندارد ISO 16739 [ 15 ] و بنر و همکاران است. [ 16]. از این تلاش ها، مفاهیم مهم ( شکل 1 ) شناسایی می شوند. نمادهای استاندارد UML برای توسعه مدل ساختمان IFC استفاده می شود.

شکل 1. مدل ساختمان IFC.

بر اساس مدل IFC ارائه شده در اینجا، یک ساختمان باید حداقل یک طبقه و ممکن است چندین طبقه داشته باشد. هر طبقه ممکن است صفر یا چند فضا مرتبط با خود داشته باشد، یعنی سازه ساختمانی که فقط یک دیوار دارد، ساختمانی با فضاهای صفر است. عناصر ساختمانی و عناصر بازشو از زیرگروه های عناصر سازه ای هستند. هر عنصر ساختمانی دارای صفر یا چند عنصر بازکننده است، یعنی یک دیوار بدون در یا پنجره صفر بازشو دارد، در حالی که هر عنصر بازکننده (مانند در، پنجره) تنها به یک عنصر ساختمان متصل است. شکل 1دوازده نوع از عناصر ساختمانی را نشان می دهد که می توانند یک سازه ساختمان را در استاندارد IFC نشان دهند. دامنه این مطالعه به مدل‌های ساختمانی محدود می‌شود که فقط بخش‌های ساخته شده از ساختمان‌ها را نشان می‌دهند.

2.2. مدل ساختمان CityGML

CityGML یک استاندارد باز است که به عنوان یک طرح کاربردی برای GML3 پیاده سازی شده است [ 17 ، 18 ]. GML3 استاندارد بین المللی قابل گسترش برای تبادل داده های مکانی است که توسط کنسرسیوم فضایی باز (OGC) [ 19 ] و ISO TC211 [ 20 ] توسعه و صادر شده است. CityGML به عنوان یک مدل داده باز که توسط یک طرح XML بیان می شود، توسعه یافته است. فایل های CityGML می توانند اشیاء سه بعدی مجازی و مدل های شهر را در بین برنامه ها ذخیره و مبادله کنند [ 17 ]. بر اساس ISO 19107 [ 21 ] و ISO 19109 [ 22 ]، یک مدل ساختمانی CityGML در استاندارد CityGML [ 23 ] تولید شده است. مدل ساختمان ( شکل 2) یک نسخه گزیده شده از استاندارد CityGML است که در آن فقط مفاهیم تبدیل استفاده شده به IFC نشان داده شده است، یعنی BuildingFurniture و IntBuildingInstallation نمایش داده نمی شوند. نمادهای استاندارد UML برای توسعه مدل ساختمان CityGML استفاده می شود.

CityGML در پنج سطح از جزئیات (LoDs) توسعه یافته است که برای نمایش اشیاء مدل شهر با توجه به سطح جزئیات مورد نیاز در برنامه های مختلف استفاده می شود. LoD ها از LoD0 تا LoD4 شماره گذاری می شوند و دارای دقت های متفاوت و حداقل ابعاد اجسام فضایی هستند که می توانند در هر LoD نمایش داده شوند. ساختمان‌های منفرد در LoD1 ظاهر می‌شوند. بنابراین، ما یک مدل ساختمان CityGML از LoD1 تا LoD4 ارائه کرده‌ایم. شکل 2 LoD ها را با رنگ های مختلف نشان می دهد.

شکل 2. مدل ساختمان CityGML.

2.3. نیاز به ادغام

کاربردهای یکپارچه برای افزایش جهانی شدن و مشکلات رایج ضروری دیده می شود. در سطح اتحادیه اروپا، ابتکارات مختلفی مانند دستورالعمل زیرساخت اطلاعات فضایی در جامعه اروپا (INSPIRE) [ 24 ]، ایجاد کاربردهای فضایی مشترک برای کشورهای اتحادیه اروپا را پیشنهاد کرده است. برنامه ها و دستورالعمل های مرتبط (به عنوان مثال، دستورالعمل نویز، دستورالعمل محصولات ساختمانی، عملکرد انرژی، شرایط اضطراری، امنیت و موارد دیگر) در اینجا به عنوان انگیزه ای برای ادغام IFC و CityGML دیده می شوند ( شکل 3 ).

شکل 3. مدل مفهومی پیشنهادی برای ادغام CityGML و IFC.

استاندارد IFC به عنوان نقطه ورود برای کاربردهای مختلف همانطور که در شکل 3 نشان داده شده است ، که مناطق داخلی را در صنعت ساختمان در نظر می گیرد، دیده می شود. قرار است اشیاء داخلی از طریق تهیه پایگاه های داده غنی شده به استاندارد IFC ترجمه شوند. تعداد زیادی از نقشه‌ها، اسناد و فایل‌های CAD در حال حاضر در دسترس هستند، با این حال، روی کاغذ یا در قالب‌های فایل اختصاصی ذخیره شده‌اند، و تبدیل این اطلاعات به IFC ممکن است فرآیندی بسیار زمان‌بر باشد.

در سمت CityGML ( شکل 3 )، تعدادی پایگاه داده موجود است که اطلاعات مربوط به اشیاء فضایی در فضای باز را ذخیره می کند. اینها معمولاً بر اساس استانداردهای GIS مدل‌سازی می‌شوند و در کاربردهای ساده و مجزا ارائه می‌شوند که مناطق کوچکی را پوشش می‌دهند. در آغاز کنسرسیوم فضایی باز (OGC) [ 17 ]، ساخت مجموعه ای پیشرفته از خدمات وب در حال انجام است. این وب سرویس ها کل اروپا را طبق دستورالعمل INSPIRE پوشش خواهند داد [ 24]، و سطوح مختلفی از جزئیات برای کاربردها و تحلیل های مختلف دارند. این بدان معناست که بسیاری از مجموعه داده‌های فضایی اروپایی احتمالاً با استفاده از فرمت‌های GML و CityGML منتقل می‌شوند. این مجموعه داده‌ها را می‌توان مستقیماً از سرویس‌های ویژگی‌های وب (WFS) یا از سایر قالب‌ها/پایگاه‌های داده GIS تبدیل کرد. تا چه حد CityGML در مشخصات داده های INSPIRE آینده استفاده خواهد شد، باید دید.

2.4. کار مرتبط

هدف IFC تعیین یک زبان مشترک برای فناوری صنعت ساختمان است که ارتباطات، بهره وری، زمان تحویل، هزینه و کیفیت را در طول چرخه عمر طراحی، ساخت و نگهداری ساختمان ها بهبود می بخشد [ 25 ]. سپس IFC برای جمع آوری مدل های قابل خواندن کامپیوتری که حاوی اطلاعات مربوط به بخش های مختلف یک ساختمان هستند استفاده می شود [ 8 ، 26 ]. با این حال، CityGML برای تعریف اطلاعات مربوط به ویژگی‌های توپولوژیکی و معنایی یک منطقه جغرافیایی، از جمله ساختمان‌ها استفاده می‌شود [ 17 ، 18 ]. از یک طرف، IFC به عنوان یک استاندارد ISO توسعه یافته است و تا حد زیادی برای صنعت ساختمان پذیرفته شده است [ 27 ]]؛ از سوی دیگر، CityGML اخیراً به عنوان یک استاندارد بین المللی برای مدل سازی شهرها در کنسرسیوم فضایی باز (OGC) و اتحادیه اروپا پذیرفته شده است [ 17 ، 18 ]. این امر منجر به افزایش عمده در توسعه حوزه‌های کاربردی جدید، کیت‌های ابزار نرم‌افزار و برنامه‌های افزودنی برای سیستم‌های موجود برای پشتیبانی از IFC و همچنین CityGML شده است.

ادغام IFC و CityGML امروزه به عنوان یک گام ضروری برای بدست آوردن تصویر کاملتر از مدلسازی سه بعدی در سطوح مختلف جزئیات دیده می شود.به اشتراک گذاری و تبادل اطلاعات بین اشیاء صنعت ساختمان (نمایش در IFC) و اشیاء جغرافیایی (نمایش داده شده در CityGML). چندین تلاش برای ادغام IFC و CityGML صورت گرفته است. تمام این تلاش‌ها عمدتاً در قالب توسعه چارچوب‌ها، گسترش بحث برای پرداختن به نیازمندی‌ها یا توسعه ابزارهای تبدیل است. برای چارچوب‌ها، پروژه IFC برای GIS (IFG) توسط سازمان برنامه‌ریزی دولتی نروژ (Statens Bygningstekniske Etat) آغاز شد و در سال 2007 تکمیل شد. هدف این چارچوب تبادل اطلاعات ساختمان بین سیستم‌های CAD و GIS با استفاده از IFC بود. این پروژه موفق به ایجاد مشخصات نقشه برداری از نسخه XML هندسه IFG به GML و بالعکس شد [ 28 ]]. با نگاهی خاص به جنبه های فنی، چارچوب دیگری توسط Nagel [ 29 ] پیشنهاد شد، با هدف الگوریتم هایی که به طور خودکار مدل های ساختمان IFC را به مدل های CityGML تبدیل می کنند. Isikdag و Zlatanova [ 11 ] تحقیقات Nagel را با پیشنهاد یک چارچوب راهنما برای تولید خودکار ساختمان ها در CityGML با استفاده از BIM و بر اساس تعریفی از معناشناسی و اجزای ساختمان تکمیل کردند. به دنبال دیدگاه کلی از جنبه های مدل سازی سه بعدی شهر، یک بحث گسترده در مورد الزامات مفهومی برای تبدیل CityGML به مدل های IFC در سال 2009 توسط تیمی به رهبری توماس کولبه در دانشگاه فنی برلین پیشنهاد شد [ 30 ]. آنها چارچوبی را پیشنهاد کردند که گرافیک سه بعدی / داده های ساختمان ها و مناطق شهری (X3D، DXF، KML، COLLADA، و غیره ) را یکپارچه می کند..) با داده های معنایی در طرحواره هدف CityGML. چند محیط تبدیل اضافی را می توان در این منطقه مشاهده کرد. Van Berlo [ 31 ] آخرین سهم تیم خود را به عنوان برنامه افزودنی دامنه کاربردی (ADE) نشان می دهد که داده های مدل اطلاعات ساختمان (BIM) را بر اساس استاندارد باز IFC در CityGML ادغام می کند. نه تنها تلاش‌های تحقیقاتی، بلکه محصولات نرم‌افزار تجاری برای تبدیل از IFC به CityGML (به عنوان مثال، IfcExplorer، 2008 [ 32 ] و Safe Software، 2008 [ 33 ]) همچنین به توسعه یکپارچه‌سازی مدل‌سازی سه بعدی شهر کمک می‌کنند.

با این حال، این تلاش ها یا (الف) رویکردی برای تبدیل یک طرفه با تمرکز بر تبدیل هندسه (عمدتا از IFC به CityGML) دارند. (ب) بحث در مورد آنچه که باید از نظر یکپارچگی انجام شود ، یعنی اینکه چگونه باید انجام شود هنوز به اندازه کافی اجرا نشده است. (ج) تمرکز بر تنزل رتبه IFC به LoDهای پایین در CityGML یا (د) بحث در مورد علاقه به معناشناسی غنی IFC.

چندین مطالعه، مانند [ 11 ، 16 ، 30 ] تأکید می کنند که یک چارچوب رسمی برای تبدیل معنایی و هندسی دقیق برای یکپارچگی کامل CityGML و IFC مورد نیاز است. هندسه به عنوان یکی از نگرانی های مشکل ساز اصلی برای ادغام IFC و CityGML برجسته شده است [ 27 ، 30 ]. با این حال، بیشتر تلاش‌های اخیر بر فرآیندهای ادغام مفهومی یا تبدیل متمرکز شده‌اند. با توجه به تلاش‌های گسترده برای تعریف تفاوت‌های هندسی و توسعه الگوریتم‌های تبدیل [ 13 ]]، ما در تحقیق خود به این نوع مشکل نمی پردازیم. در مطالعه حاضر، ما بر ادغام مفهومی و نقشه برداری اشیاء مختلف در استانداردهای IFC و CityGML تمرکز می کنیم.

3. رویکرد تحقیق

از سناریوی انگیزشی، نیاز به ترکیب اطلاعات IFC داخلی در ساختمان ها و اطلاعات محیط ساخته شده CityGML در فضای باز آشکار است. با این وجود، ما معتقدیم که تبدیل از IFC به CityGML می‌تواند منجر به محدودیت‌های زیر شود:

از دست دادن داده ها در تبدیل IFC به CityGML، زیرا CityGML نمی تواند تمام مفاهیم IFC را حفظ کند. به طور مشابه، IFC نمی تواند مفاهیم CityGML را حفظ کند. این نیز توسط یافته های [ 27 ] تایید شده است.
مدل‌های شهر سه بعدی در حال حاضر در بخش‌های عمومی و خصوصی در سیستم‌های مختلف، مدل‌های مفهومی مختلف، قالب‌های داده‌های مختلف، طرح‌واره‌های داده‌های مختلف، سطوح مختلف جزئیات و کیفیت متفاوت پراکنده شده‌اند [ 34 ]. علاوه بر این، پتانسیل مدل های سه بعدی فراتر از تجسم اشیاء سه بعدی صحنه های مجازی به مدل های سه بعدی شهر واقعی است. در چنین محیط‌هایی، تبدیل‌ها تعداد کاربرانی را که قادر به استفاده کامل از پتانسیل IFC یا CityGML به طور جداگانه هستند، بسیار محدود می‌کند.
امکان ادغام معنای IFC در CityGML به طور پیش فرض وجود ندارد [ 31 ]. یک جایگزین استفاده از مکانیزم توسعه برای CityGML و IFC است. با این حال، تنها چند تلاش برای توسعه گزارش شده است (به بخش 2.4 مراجعه کنید ).
CityGML و IFC یک مقیاس همپوشانی از داده های نمایش داده شده را نشان می دهند، که در آن CityGML دارای ساختاری است که توانایی مدیریت داده ها را در همه مقیاس ها دارد (به عنوان مثال، از مقیاس شهر تا 1:100 یا جزئیات بیشتر) و IFC بر مقیاس تمرکز دارد. اتاق ها، دیوارها و حتی جزئیات ساختاری. با این حال، نمونه‌هایی از تلاش‌ها برای گسترش مدل‌های CityGML یا IFC برای پوشش اطلاعات دقیق تحت پوشش دیگری، فرآیندهای پیچیده‌ای هستند که اندازه فایل‌های بسیار بزرگ و همچنین ناسازگاری داده‌ها را ایجاد می‌کنند. این را همچنین می‌توان با نتایج Van Berlo و De Laat [ 35 ] تکمیل کرد، که علاوه بر این بر نیاز به برنامه‌های افزودنی جدید و ملاحظات مختلف برای هر برنامه مورد نظر با توجه به مقیاس گنجانده شده داده‌های ارائه‌شده تأکید می‌کند.
انتقال مداوم داده ها از یک فرمت به فرمت دیگر می تواند ناکارآمد باشد زیرا سربار تبدیل را افزایش می دهد.

به دنبال این محدودیت‌ها، این مطالعه یک رویکرد مدل‌گرا یکپارچه برای توسعه یک مدل ساختمانی یکپارچه (UBM) پیشنهاد می‌کند که می‌تواند به افزایش ادغام CityGML و IFC برای گسترش برنامه‌های کاربردی مدل سه‌بعدی شهر کمک کند. ما معتقدیم که UBM به هر دو جهان IFC و CityGML اجازه می‌دهد تا بدون از دست دادن داده‌ها و بدون سربار تبدیل مکرر بین مدل‌های IFC و CityGML با آن تعامل داشته باشند. ماهیت این رویکرد، توسعه یک مدل واحد است که می تواند اطلاعات مربوط به IFC و CityGML را به دست آورد. با توجه به مدل اطلاعات دقیق خود، دسترسی به IFC و CityGML و همچنین دسترسی یکپارچه به اطلاعات ساختمان را امکان پذیر می کند. این مزایا نیاز UBM را برای تسهیل تبدیل از IFC به CityGML یا از CityGML به IFC ایجاد می کند. این همچنین به این معنی است که استانداردهای اصلی Revit/CAD در نظر گرفته نمی شوند. IFC در حال تبدیل شدن به یک استاندارد منحصر به فرد است که با قابلیت خواندن/نوشتن ابزارهای مختلف بدون توجه به منشأ آنها پشتیبانی می شود.

یک مدل یکپارچه در مطالعه حاضر به عنوان یک مفهوم مدل ابرمجموعه تعریف می‌شود که شامل ویژگی‌ها و اشیاء از هر دو مدل ساختمان IFC و CityGML است. مدل یکپارچه در اصل از مفاهیم ابرمجموعه ریاضیات در دهه 1970 به رهبری توماس جی جک [ 36 ] و سایر محققان مشتق شده است. همچنین از اواسط دهه 1990 در مهندسی نرم افزار استفاده شده است [ 37 ].

برای ساخت UBM، ابتدا همه کلاس‌ها با مفاهیمشان از هر دو مدل جمع‌آوری شدند، اما روابط آنها حذف شد. مفاهیم همپوشانی با هم ادغام شدند و اشیاء جدید به گونه ای ایجاد شدند که هم اشیاء داخلی و هم در خارج از خانه گرفته می شدند. در نهایت، روابط بین اشیاء برای تولید UBM ما بازسازی شد. مشابه IFC و CityGML، از نمادهای UML برای نمایش اشیاء UML و روابط بین آنها استفاده می شود. این مدل همچنین در LOD های مختلف توسعه یافته است که در شکل 4 در رنگ های مختلف نشان داده شده است. جزئیات در LOD ها مطابق با جزئیات CityGML در نظر گرفته می شود. در زیر توضیح مختصری از LOD1-LOD4 بدون LOD0 ارائه شده است، زیرا ساختمان ها فقط در LOD1 ظاهر می شوند:

LOD1 اولین نمایش ساختمان های منفرد است. آنها فقط به صورت بلوک هایی با سقف های مسطح برای همه انواع ساختمان ها به عنوان یک سطح پایه ظاهر می شوند.
LOD2 نمایانگر ساختمان های منفرد با سقف ها و سطوح بیرونی متفاوت است. جزئیات خارجی متصل به نمای ساختمان نیز در LOD2 ظاهر می شود.
LOD3 ساختمانها را در یک مدل معماری با جزئیات سقف، دیوارها و عناصر ساختاری بیرونی و داخلی نشان می دهد. دهانه ها نیز در این LOD در عناصر مختلف ساختمان به عنوان در یا پنجره ظاهر می شوند.
LOD4 یک مدل کامل از یک ساختمان را با اضافه کردن ساختارهای داخلی عناصر ساختمان ارائه می دهد. تمام جزئیات مورد نظر را می توان در LOD4 ارائه کرد، مانند تاسیسات بیرونی، تاسیسات داخلی و حتی عناصر مبلمان متحرک. در این تحقیق تنها بر روی عناصر سازه ای ساختمان تمرکز شده است. بنابراین، اشیاء مبلمان در مدل پیشنهادی یا هستی شناسی مرجع در نظر گرفته نمی شوند.

با توجه به مقبولیت گسترده آن، زبان مدل سازی یکپارچه (UML) به عنوان زبان مدل سازی برای رویکرد مدل ساختمان یکپارچه (UBM) پیشنهادی انتخاب شده است. الزامات UBM پیشنهادی مستلزم این بود که تبدیل با (الف) حداقل از دست دادن اطلاعات، و (ب) یک روند تطبیق و نقشه برداری طرحواره کارآمد انجام شود. بنابراین، UBM قصد دارد نمایش رایگان برای عناصر ساختمان مدل داده ارائه دهد، و تمام اطلاعات را از CityGML و IFC ادغام کند و همچنین موارد گمشده را پر کند. بنابراین همه آنها را می توان به یک مدل واحد تبدیل کرد که می تواند برای انجام تمام تحلیل ها و پرس و جوهای فضایی مورد نیاز استفاده شود.

شکل 4. مدل یکپارچه ساختمان.

4. مدل یکپارچه ساختمان

همانطور که در رویکرد تحقیق ذکر شد، برای ساخت UBM، ابتدا همه کلاس‌ها با مفاهیمشان از هر دو مدل جمع‌آوری شدند، در حالی که روابط آنها حذف شد. این حذف با دلیل مهمی در رابطه با تفاوت های ظاهری بین ساختار و روابط هر دو مدل ساختمان IFC و CityGML ایجاد شده است. در IFC، کاربران می توانند ساختار خود را برای نمایش فضاهای مختلف یک ساختمان تعریف کنند. کاربران می توانند مسیر اتصال خود را با توضیحات پیوست در مورد سیستم های خدمات مرجع در ساختار ساختمان ها ایجاد کنند. به عنوان مثال، این می تواند با یک دیوار یا دال شروع شود که سپس می تواند به یک فضا متصل شود، سپس یک طبقه و به یک ساختمان ختم شود. با این حال، هیچ راه منحصر به فردی برای اتصال یک شی IFC خاص به دیگری وجود ندارد. مسیر اتصالات تعریف شده توسط کاربر چیزی است که ما در طرح IFC نمی یابیم. در عوض، آنها در یک فایل داده خاص ذخیره می شوند (سطوح اختیاری مانند IfcSpace را به خاطر بسپارید). به عنوان مثال، IfcFlowSegment را می توان برای تعریف رابطه محفظه بین IfcWall و IfcSpace بر اساس اطلاعاتی که فضاها توسط دیوارها محصور شده اند استفاده کرد. به طور مشابه، IfcSpace می تواند به صورت فضایی با IfcStorey و سپس به IfcBuilding مرتبط شود. این نوع اتصالات فضایی در CityGML به صورت ایستا و واضح‌تر تعریف می‌شوند. رابطه بین پنجره، سطح دیوار، اتاق و ساختمان همیشه یکسان است. به عنوان مثال، پنجره (که زیرمجموعه ای از کلاس باز می باشد) باید به کلاس باز شونده، بازشو به WallSurface و WallSurface به Room متصل می شود. با این حال، کلاس دیوار به عنوان یک عنصر ساختمانی در CityGML وجود ندارد. بنابراین، برای پیاده سازی نرم افزار تبدیل داده ها از IFC به CityGML دشوار است.

روابط در ArcGIS بین کلاس ها و جداول UBM با توجه به روابط فضایی و همچنین جدولی بین آنها بازسازی می شوند. این روابط را می توان با توجه به ابزارهای موجود، به صورت متفاوتی ایجاد کرد. سپس مفاهیم همپوشانی با هم ادغام شدند و اشیاء جدید به گونه‌ای ایجاد شدند که هم اشیاء داخلی و هم خارجی ضبط می‌شوند. در نهایت، روابط بین اشیاء برای تولید UBM ما دوباره تعریف شد. از نمادهای UML برای نمایش اشیاء و روابط بین آنها استفاده می شود.

شکل 4 UBM را نشان می دهد که در آن از رنگ های مختلف برای نشان دادن LOD های مختلف استفاده می شود. عناصر UBM در زیر به اختصار توضیح داده شده است.

از آنجایی که مطالعه به ساختار ساختمان محدود می شود، اشیاء فراتر از ساختمان (مانند پروژه و سایت) در مدل نشان داده نمی شوند. از آنجایی که ساختمان یک شی مشترک برای IFC و CityGML است، شی UBMbuilding به عنوان نقطه شروع برای مدل استفاده شده است.

یک ساختمان در CityGML از اتاق هایی تشکیل شده است که در آن اتاق فضایی است که توسط سطوح مختلف مرزی احاطه شده است. طبقات به صراحت تعریف نشده‌اند، اما می‌توان آن‌ها را به‌عنوان یک تجمع صریح از تمام ویژگی‌های ساختمان در یک سطح ارتفاع معین نشان داد. با این حال، در IFC، سازه به آرامی با تقسیم یک ساختمان به طبقات و سپس به فضاهایی که یک طبقه خاص را تشکیل می دهند، سازماندهی می شود. در UBM، مفاهیم IFC و همچنین CityGML را در نظر می گیریم. یک ساختمان در UBM از یک تعریف صریح از طبقات تشکیل شده است. حداقل یک طبقه در یک ساختمان هر طبقه ساختمان ممکن است صفر یا بیشتر فضاهای مربوط به خود داشته باشد. همانطور که در شکل 4 نشان داده شده است، یک فضا می تواند باز یا بسته شود . فضای بسته نشان دهنده اتاقی است که با تعریف اتاق در CityGML مطابقت دارد.

در CityGML، سطوح مرزی توسط کلاس ( BoundarySurface ) برای ساختار دهی پوسته بیرونی ساختمان و سطوح قابل مشاهده یک اتاق استفاده می شود. با این حال، در IFC، یک اتاق یا فضا با عناصر ساختمانی ساخته می شود که آن را ساختار می دهد و آن را احاطه می کند. سپس می‌توانیم برخی از کلاس‌های IFC را برجسته کنیم (به عنوان مثال، IfcWall ، IfcDoor و IfcWindow) به عنوان (یا به عنوان) سطوح مرزی در CityGML. در UBM از مفاهیم CityGML و IFC استفاده کرده ایم. ما پیشنهاد می کنیم که یک سطح مرزی تنها زمانی استفاده شود که برای استخراج مدل جعبه یک ساختمان کامل، بخشی از یک ساختمان یا یک طبقه خاص مورد نیاز باشد. با این حال، عناصر ساختمانی برای نشان دادن عناصر موجود در ساختار ساختمان استفاده می‌شوند. همانطور که هر مکان فضایی در یک ساختمان (طبقه یا فضا) ممکن است یک در یا یک پنجره داشته باشد، بازشو هم به سطح مرزی و هم به اشیاء عنصر ساختمان متصل است.

برای عناصر ساختمان، مفاهیم جدیدی را به گونه‌ای تعریف کرده‌ایم که همه مفاهیم هم از IFC و هم از CityGML قابل پوشش باشند. تفاوت اصلی بین عناصر ساختمان در CityGML و IFC در نمایش سطوح مختلف، قسمت های داخلی و خارجی ساختمان (دیوار، سقف و زمین) است. به دلیل نیاز به نمایش و تعاریف مختلف LoD از عناصر مانند (سقف، سقف و دال) و (زمین، کف و دال)، عناصر ساختمان را به صورت زیر تعریف کرده‌ایم:

پوشش یک سطح بسته است که یک فضای را از سمت بالا پوشش می دهد. دو نوع دارد؛ سقف برای پوشش بالای ساختمان یا طبقه بالایی که شکل بیرونی ساختمان را از بالا می دهد و سقفی برای پوشش هر فضایی در ساختمان. در هر دو نوع فرعی تنها قسمت های ساخته شده برای یک فضا در نمای پوششی در نظر گرفته می شود.
Level یک سطح قابل راه رفتن (نه فقط افقی) است که سطح پایین یک فضا را نشان می دهد. دارای دو نوع است: همکف برای سطح زیرین طبقه همکف که با زمین بیرونی ارتباط دارد تا شکل بیرونی ساختمان را از سطح زیرین بدهد و کف برای سطح پایین یک فضا در هر فضایی از ساختمان به جز پایین ترین (پایین ترین) طبقه.
دیوار یک عنصر عمودی/نیمه عمودی است که فضاها را احاطه یا تقسیم می کند. دارای سه نوع فرعی است: (1) کرتین وال برای دیوار بیرونی که نمای کامل یک ساختمان یا بخشی از آن را می پوشاند. معمولاً فقط به یک طبقه محدود یا متصل نیست. (2) فضای داخلی دیوار داخلی بین اتاق ها یا فضاها (هیچ یک از وجوه آن با محیط بیرونی ارتباط ندارد). و (iii) نمای خارجی برای یک دیوار خارجی که با محیط بیرونی ارتباط دارد و نمایانگر بخشی از نماهای خارجی ساختمان است.

این مفاهیم در شکل 5 نشان داده شده است.

شکل 5. مفاهیم پوشش، سطح و دیوار.

تاسیسات ساختمان (رمپ، دودکش، بالکن، تیرها، ستون‌ها و غیره ) در IFC و CityGML متفاوت تعریف شده‌اند. در IFC، آنها به عنوان عناصر ساختمانی معمولی (مانند دیوار، دال و غیره ) با مفاهیم هندسی یکسان تعریف می شوند. با این حال، در CityGML تاسیسات ساختمان در یک شی مجزا به نام “Building install” مشخص می شوند. در مورد دوم، هندسه این تاسیسات (رمپ، دودکش، بالکن، تیرها، ستون‌ها و غیره ) توسط چند سطحی که اشیاء را می‌سازند، تعریف شده و در CityGMLMultiSurface ذخیره می‌شوند . در UBM، ما این نصب ها را به عنوان زیر کلاس های UBMBuildingInstallation تعریف کرده ایم.کلاس به منظور نشان دادن تاسیسات ساختمان خارجی که برای شکل خارجی ساختمان در LoD2 مهم هستند. در صورتی که مدل کوچکتری برای پردازش سریعتر یا تجزیه و تحلیل با جزئیات کمتر مورد نظر باشد، این امر همچنین امکان خاموش کردن تاسیسات ساختمان را فراهم می کند.

هنگام ادغام کلاس ها، محدودیت هایی بین ویژگی ها ممکن است تعریف شود. برای مثال، ویژگی‌های کلاس UBMBuilding بر اساس ادغام IFCBuilding و CityGMLAbstractBuilding است. پس از آن می توان محدودیت های زیر را تعریف کرد:

5. پیاده سازی UBM

ابزارهای موجود برای تبدیل داده‌ها مانند IfcExplorer و Safe Software در قابلیت‌های تبدیل، پیچیدگی استفاده و تجسم نتایج متفاوت هستند [ 11 ]]. در اینجا مهم است که تأکید کنیم که ابزارهای مختلفی را می توان برای اجرای UBM پیشنهادی ما با سطوح مختلف پیچیدگی برای فرآیند پیاده سازی استفاده کرد. به منظور حفظ تمرکز بر UBM مفهومی و نشان دادن قابلیت‌های آن، ArcGIS را به عنوان یک محیط پیاده‌سازی و ابزاری انتخاب کرده‌ایم که عمدتاً به دلیل اجرای انعطاف‌پذیر قابلیت همکاری داده‌ای که ارائه می‌دهد، بلوغ آن در برنامه‌های GIS، گنجاندن یک ابزار بزرگ تعداد قابلیت های سه بعدی و آشنایی با آن در بین اعضای پژوهشگر ما. علاوه بر این، مزایای زیر ArcGIS نسبت به سایر ابزارها منجر به انتخاب آن برای پیاده سازی شده است:

هدایت فرآیندهای مختلف تبدیل و تجسم آنها را قبل از محصول نهایی تسهیل می کند.
این محیطی را فراهم می کند که در آن مدل داده ما می تواند بین هر دو دامنه IFC و CityGML ساخته شود. این می تواند فرآیندهای خودکار بین هر دو حوزه را تسهیل کند.
در یک محیط میانی، این امکان وجود دارد که جداول پر شده ما را از هر IFC و CityGML نظارت کنیم و نشان دهیم که چگونه مدل داده پیشنهادی می تواند غنی شود.
استفاده از محیط پردازش جغرافیایی ArcGIS، از جمله چارچوب ModelBuilder، که فرآیندهای ماژولار و سفارشی‌سازی را امکان‌پذیر می‌سازد را امکان‌پذیر می‌سازد.

پیاده سازی و نشان دادن قابلیت کاربرد UBM در سه بخش زیر ارائه شده است. دو بخش فرعی اول (5.1-5.2) توضیح می‌دهند که چگونه UBM را می‌توان در ArcGIS با استفاده از فناوری Geodatabase پیاده‌سازی کرد. با این حال، بخش سوم (5.3)، سودمندی UBM را بر مدل‌های ساختمان IFC و CityGML به طور جداگانه نشان می‌دهد.

5.1. نگاشت UBM به پایگاه جغرافیایی ArcGIS

به منظور پیاده سازی مدل UBM در ArcGIS، ابتدا پایگاه جغرافیایی فایل در ArcCatalog ایجاد می شود . انتخاب ما برای پایگاه داده های جغرافیایی فایل به جای پایگاه های جغرافیایی شخصی به دلایل زیر است: (i) فایل IFC و CityGML بسته به سطح جزئیاتی که نشان می دهند، می توانند از نظر اندازه بزرگ باشند . سپس پایگاه جغرافیایی فایل انتخاب می شود زیرا محدودیت اندازه ذخیره سازی ندارد، در حالی که پایگاه جغرافیایی شخصی تنها به 2 گیگابایت محدود می شود، (2) عملکرد در پایگاه جغرافیایی فایل در مقایسه با پایگاه جغرافیایی شخصی بهبود می یابد، به خصوص پس از رسیدن پایگاه داده به حدود 500 مگابایت، و ( iii) پایگاه جغرافیایی فایلقابلیت‌هایی را برای سفارشی‌سازی ذخیره‌سازی از طریق فشرده‌سازی داده‌های برداری و کلیدواژه‌های پیکربندی فراهم می‌کند که از پردازش فایل‌های بزرگ نیز پشتیبانی می‌کند.

پس از ساخت geodatabase فایل ، کلاس های ویژگی ایجاد می شوند که مطابق با کلاس های اصلی در UBM هستند. در این کلاس‌های ویژگی، زیرمجموعه‌های مختلفی نیز ایجاد می‌شوند تا زیرمجموعه ویژگی‌ها را در یک کلاس ویژگی متناظر که ویژگی‌های یکسانی دارند، تعریف کنند. زیرگروه ها برای دسته بندی داده ها در مدل داده ما استفاده می شوند. انتخاب برای ایجاد زیرگروه ها به جای کلاس های ویژگی یا روابط جدا شده با کلاس ویژگی supertype به دلایل زیر انجام می شود:

(i) افزایش عملکرد پایگاه جغرافیایی با نمایش اشیاء مختلف به عنوان زیرمجموعه ای از ویژگی در کلاس ویژگی اصلی. این مزیت ایجاد UBMRoof را به عنوان یکی از ویژگی‌های فرعی سوپرتایپ UBMCovering نشان می‌دهد که در آن UBMRoof سقف نهایی یک ساختمان را نشان می‌دهد که یک بار برای هر ساختمان نشان داده می‌شود. با این حال، نیازی به ایجاد یک کلاس ویژگی جداگانه برای آن وجود ندارد.
(ii) قابلیت تنظیم مقادیر پیش فرض برای فیلدهای از پیش تعریف شده که به طور خودکار هنگام ایجاد ویژگی های جدید اعمال می شود. به عنوان مثال زیرنوع UBMCeiling به گونه ای ساخته و تعریف شده است که هر زمان این نوع پوشش به کلاس ویژگی اضافه شد، ضخامت آن به طور خودکار روی 15 یا 20 سانتی متر تنظیم می شود.
(iii) امکان اعمال دامنه های کدگذاری شده یا دامنه دار برای ویژگی ها. این بیشتر اجازه می دهد تا اطلاعات ورودی را فقط به مجموعه ای معتبر از مقادیر که از پیش تعریف شده اند محدود کنیم. به عنوان مثال، مصالح ساختمانی را می توان با یک دامنه کدگذاری شده در UBMCeiling و UBMFloor محدود کرد ، متفاوت از UBMLevel و UBMCovering برای مواجهه با شرایط آب و هوایی خارجی.
(IV) فعال کردن قواعد اتصال با سایر زیرنوع‌ها و کلاس‌های ویژگی. این نشان می دهد که چگونه UBMCurtainWall باید فقط به دیوارهای خارجی ( UBMExteriorWall ) وصل شود اما نه به دیوار داخلی ( UBMInteriorWall ).
(v) امکان ایجاد قوانین توپولوژی با سایر زیرگروه ها و کلاس های ویژگی. در UBM، قوانین توپولوژی نحوه طبقه بندی کلاس UBMSpace را به کلاس های فرعی UBMOpenedSpace و UBMClosedSpace نشان می دهد. UBMClosedSpace با قوانین توپولوژی تعریف می شود تا اطمینان حاصل شود که تمام دیوارهای اطراف، سقف و کف به یک هندسه بسته متصل هستند. در غیر این صورت به عنوان UBMOpenedSpace طبقه بندی می شود .
(vi) امکان توسعه قواعد رابطه با سایر زیرگروه ها و کلاس های ویژگی. در UBM قوانین رابطه متفاوتی را می توان تعریف کرد که توضیح می دهد که دیوارهای چوبی نمی توانند دیوارهای خارجی باشند یا از پله های مارپیچ نمی توان به عنوان پله های اضطراری خارجی و غیره استفاده کرد.

جدول 1. کلاس های ویژگی با زیرگروه های مربوطه.

کلاس‌های ویژگی و زیرگروه‌های آن‌ها که نشان‌دهنده UBM هستند در جدول 1 نشان داده شده‌اند . توجه به این نکته مهم است که ما تمام کلاس‌ها و زیرگروه‌های ویژگی را فهرست کرده‌ایم که فقط اشیاء فضایی را در UBM نشان می‌دهند. سایر اطلاعات غیر مکانی (مانند جداول که فقط داده های قابل انتساب در مورد اشیاء مکانی را نشان می دهند) و جداول فراداده نیز در پایگاه داده جغرافیایی فایل ایجاد می شوند. به عنوان مثال: جدول سازمان (برای اطلاعات در مورد سازمان ساخت و ساز)، جدول مواد مرتبط (برای اطلاعات در مورد مصالح ساختمانی و توضیحات آنها)، و تاریخچه مالک (برای اطلاعات در مورد نحوه مالکیت و استفاده از ساختمان) و غیره .

برای تمام کلاس های ویژگی (نماینده اشیاء فضایی) در UBM، از نوع هندسه چند وصله استفاده می شود. این به این دلیل است که این نوع هندسه ما را قادر می‌سازد تا اجسام فضایی را در هندسه سه‌بعدی به‌عنوان سطوح متعدد نشان دهیم. علاوه بر این، امکان انجام کلیه عملیات GIS و ابزارهای تجزیه و تحلیل را به صورت دو بعدی و همچنین سه بعدی می دهد.

5.2. توابع غنی سازی داخلی UBM

همانطور که در بخش 3 و بخش 4 بحث شد، UBM شامل تمام ویژگی ها و اشیاء فضایی از هر دو مدل ساختمان IFC و CityGML است. با این حال، اطلاعات ساختمان معمولاً در استاندارد IFC یا CityGML موجود است که در نتیجه UBM ناقصی را ارائه می‌کند. به عنوان مثال، در سناریوی بیمارستان Norrtälje، Locum AB اطلاعات فضای داخلی (در استاندارد IFC) را جمع‌آوری می‌کند، اما برای ارزیابی طراحی گسترده ساختمان به اطلاعات فضای باز نیز نیاز دارد. در این شرایط، اطلاعاتی که تنها از یک طرف، IFC یا CityGML می آید، برای نشان دادن کل مدل داده UBM کافی نیست. در مثال ساختمان بیمارستان، تنها بخش‌هایی از مدل داده‌های UBM که مربوط به IFC هستند، می‌توانند پر شوند. علاوه بر این، تفاوت های مفهومی در نمایش قطعات و عناصر ساختمان بین IFC و CityGML با توجه به نمایش هندسی وجود دارد. راه حل ما برای پر کردن جداول خالی مدل داده UBM بر اساس تعریف توابع و محدودیت های غنی سازی داخلی در پیاده سازی UBM ما است. هدف این توابع غنی سازی استفاده از اطلاعات موجود برای پر کردن جداول یا فیلدهای خالی است. ساخت جداول UBM تا حدی به صورت خودکار انجام می شود. این بدان معنی است که بر اساس پیاده سازی در ArcGIS، داده های جدولی (جدول های توصیفی) و جداول هندسی به طور خودکار از IFC یا CityGML ایجاد می شوند. با این حال، جداول دیگر نیاز به سطوح مختلف پردازش دستی، بر اساس تحلیل های فضایی مورد نیاز دارند. در اینجا شایان ذکر است که ArcGIS می تواند به طور خودکار داده های IFC و CityGML را با هندسه آنها بیاورد. علاوه بر آن، جزئیات سفارشی را می توان به صورت دستی اضافه کرد. برخی از توابع غنی سازی در زیر ارائه شده است:

(1) استخراج سطوح از IFCSpace و IFCWall

شکل 6 (الف) نمونه ای از ساختمان IFC را نشان می دهد. هنگام وارد کردن این مدل ساختمان IFC به یک پایگاه داده ژئودیتابیس فایل جدید ایجاد شده در ArcGIS ، تعدادی کلاس ویژگی که تمام عناصر ساختمان در IFC را نشان می دهد ایجاد می شود.

شکل 6. ( الف ) ساختمان IFC. ( ب ) فضاها در کلاس ویژگی IFCSpace. ( ج ) دیوارها در کلاس ویژگی IFCWallStandardCase.

دو تا از این کلاس های ویژگی عبارتند از IFCSpace ( شکل 6 (b)) و IFCWallStandardCase ( شکل 6 (c)). نمایش قطعات ساختمان (به عنوان مثال، IFCSpace و برای IFCWallStandardCase ) بدون نمایش سطوح آنها، نمایش این عناصر را در CityGML برآورده نمی کند. بنابراین، نیاز به یک عملکرد داخلی در UBM برای استخراج سطوح مختلف دیوارها (داخلی و بیرونی) به منظور پر کردن نمایش آنها در CityGML وجود دارد.

شکل 7 (الف) نشان می دهد که چگونه یک فضا، یک اتاق در این مورد، توسط چهار دیوار اطراف نمایش داده می شود. سقف و کف به عمد حذف شده اند تا فضای داخلی را در شکل نشان دهند. دو مرحله زیر نحوه انجام این کار در عملکرد ArcGIS را توضیح می دهد:

با استفاده از ابزارهای تحلیلگر سه بعدی، یک تقاطع سه بعدی بین فضاها در IFCSpace و دیوارها در IFCWallStandardCase انجام می شود. نتیجه این فرآیند فقط مرزهای داخلی فضاها است ( شکل 7 (ب)) که در آن حجم فضاها دیوارهایی را که هر فضا را احاطه کرده اند قطع می کنند. به طور مشابه، همین فرآیند برای تقاطع فضاها با IFCSlab برای استخراج سطوح سقف و کف تکرار می شود.
برای استخراج سطوح دیوار خارجی، عملیات ساده ای برای انتخاب قسمت های باقی مانده از تقاطع انجام می شود. این منجر به مرزهای بیرونی می شود که در شکل 7 (ج) نشان داده شده است.

شکل 7. ( الف ) نشان دهنده فضا در IFCSpace. ( ب ) نتیجه تقاطع بین IFCSpace و IFCWallStandardCase. ج ) سطوح دیواری داخلی در مقابل خارجی فضا.

(2) استخراج ویندوز از سطوح CityGML

سطوح در CityGML به عنوان کلاس های انتزاعی تعریف می شوند که ساختار یک پوسته بیرونی ساختمان و سطوح قابل مشاهده فضاهای داخلی ساختمان را نشان می دهند. در این سطوح، عناصر بازکننده (درها و پنجره ها) به صورت سوراخ هایی در داخل سطوح نمایش داده می شوند. یک سوراخ که نمایانگر یک عنصر بازکننده است، با یک حلقه داخلی و خارجی در شیء هندسی سطح مربوطه نشان داده می شود. دو حلقه معمولاً یکسان هستند، به عنوان مثال ، مرز بیرونی ممکن است از همان نقاط حلقه داخلی (نشان دهنده سوراخ) باشد ( شکل 8 ). نشان دادن یک بازشو توسط سطوح تنها نشان دهنده نمایش پنجره ها و درها در IFC به عنوان عناصر ساختمانی نیست. بنابراین یک عملکرد داخلی در UBM باید انجام شود.

شکل 8. ( الف ) سطحی در CityGML با یک پنجره در دیوار آن. ( ب ) اکسترود کردن پنجره از داخل به سطح بیرونی دیوار.

شکل 8 (الف) اتاقی را نشان می دهد که یک پنجره در یکی از دیوارها نشان داده شده است. یک عملکرد اکسترود از سطح داخلی به سمت سطح خارجی انجام می شود ( شکل 8 (ب)) به منظور ساخت پنجره به عنوان یک عنصر ساختمان. ضخامت پنجره ها و درها برای تعیین اندازه گیری اکسترود استفاده می شود.

(3) استخراج عناصر ساختمانی (دیوارها و اسلب ها) از سطوح CityGML

در این تابع داخلی، نحوه پر کردن دیوارها، دال‌ها و کف‌ها را به عنوان عناصر ساختمانی در UBM از یک مدل CityGML ارائه می‌کنیم. این البته فقط برای سطوح جزئیات 3 (LoD3) و 4 (LoD4) اعمال می شود، زیرا این عناصر ساختمانی در سطح پایین تر جزئیات CityGML نشان داده نمی شوند. شکل 9 (الف) بخشی از طرح معماری را نشان می دهد که تنها چهار اتاق را نشان می دهد. از CityGML آمده است، هر اتاق دارای چهار دیوار اطراف، یک سقف و یک طبقه است که به عنوان فضای اتاق در نظر گرفته می شود. شکل 9 (ب) نمای پرسپکتیو این پلان معماری را با دیوارها و کف نشان می دهد که در آن سقف به منظور تجسم برداشته شده است. هر اتاق در CityGML دارای سطوح داخلی و خارجی است، همانطور که در شکل 9 نشان داده شده است(آ). نوع هر سطح، داخلی یا خارجی، با یک ویژگی در هر عنصر در CityGML تعریف می شود. با این حال، نشان دادن تنها سطوح، نمایش دیوار، سقف و کف را در IFC به عنوان عناصر ساختمانی برآورده نمی کند. بنابراین یک عملکرد داخلی در UBM باید انجام شود.

شکل 9. ( الف ) بخشی از طرح معماری یک ساختمان. ( ب ) نمای پرسپکتیو طراحی معماری.

مراحل زیر نشان می دهد که چگونه این عملکرد داخلی برای استخراج عناصر ساختمان باید انجام شود:

انتخاب یک اتاق و سطوح اطراف آن این مرحله با یک پرس و جو انتخاب ساده در جدول انجام می شود که اطلاعات اتاق ها و سطوح مرزی آنها را ذخیره می کند.
با شروع از سطوح داخلی، به عنوان مثال، تمام سطوح داخلی فضا را می توان بر اساس نوع تعریف سطح از جدول انتخاب کرد. به عنوان مثال، شکل 10 یک سطح داخلی را فقط برای مصورسازی نشان می دهد.
ایجاد یک بافر سه بعدی در اطراف سطوح انتخاب شده. فاصله بافر توسط کاربر تعریف می شود و باید از ضخامت ضخیم ترین دیوار، سقف یا کف بزرگتر باشد. شکل 10 (ب) نمونه ای از بافر سه بعدی ایجاد شده در اطراف دیوار هدف را در این مثال نشان می دهد.
تقاطع بافر سه بعدی با تمام سطوح. این مرحله ( شکل 10 (c)) برای بررسی اینکه کدام سطوح به طور کامل توسط بافر 3 بعدی محصور شده اند مهم است. این تضمین می کند که فقط سطوح مربوط به همان دیوار انتخاب می شوند زیرا هیچ سطح دیوار دیگری به طور کامل در این بافر قرار نمی گیرد. در شکل 10 (ج)، شش سطح تنها به منظور تجسم از یکدیگر جابجا شده اند.
ساخت دیوار. این مرحله برای ترکیب سطوح انتخاب شده با یکدیگر برای ساخت یک دیوار از 6 سطح مختلف انجام می شود. شکل 10 (د) نمونه ای از دیوار هدف ساخته شده به عنوان یک عنصر ساختمانی را نشان می دهد.
مرحله نهایی باید طبقه بندی دیوار حاصل باشد. این طبقه بندی بر اساس شرایط موجود در سطح هدف (دیوار در این مثال) است. اگر حداقل یکی از سطوح موجود یک سطح خارجی باشد، دیوار به عنوان دیوار خارجی در UBM ذخیره می شود. در غیر این صورت، اگر تمام سطوح داخلی باشند، به عنوان دیوار داخلی ذخیره می شود. به طور مشابه، برای مورد سقف، سطح خارجی منجر به طبقه بندی سقف به عنوان UBMCovering-UBMRoof و برای مورد یک طبقه، سطح خارجی منجر به طبقه بندی کف به عنوان UBMLevel-UBMGround می شود.

شکل 10. ( الف ) نمای پرسپکتیو دیوار هدف. ( ب ) دیوار مورد نظر که توسط یک بافر سه بعدی احاطه شده است. ج ) دیواره هدف از 6 سطح آن تشکیل شده است. ( د ) دیوار مورد نظر که به عنوان یک عنصر ساختمانی ساخته شده است.

5.3. نمایش UBM برای موارد استفاده

برای نشان دادن کاربرد UBM برای سناریوهای مورد استفاده قبلا ارائه شده ( بخش 3 )، ما در این بخش نحوه اجرای پرس و جوهای انتخاب شده در سناریو را ارائه می دهیم. این پرس و جوها در طول عملیات اجرایی انجام شده برای موارد استفاده ارائه شده مطرح می شوند. دو پرسش اول ابتدا مورد بحث قرار می گیرند:

Q.1. پنجره های احتمالی در یک طبقه خاص را تعریف کنید که می توانند در مواقع اضطراری به عنوان درب باز شوند یا به سقف ساختمان مجاور دسترسی داشته باشند.
Q.2. درهایی را که به محیط بیرونی ساختمان دسترسی دارند پیدا کنید و کاربرد فضای بیرونی قابل دسترسی را تعریف کنید.

این دو پرس و جو شامل عملیاتی است که برای معیار طرح تخلیه ساختمان مورد نیاز است، یعنی در عرض 2 دقیقه. شکل 11 بخشی از یک مدل پرسپکتیو را نشان می دهد که یک ساختمان IFC در سمت راست شکل و ترکیبی از یک ساختمان CityGML در سمت چپ و محیط اطراف آن CityGML را نشان می دهد. همه آنها با هم در UBM پیاده سازی شده در ArcGIS آورده شده اند.

برای فضای انتخاب شده در شکل 12 (الف)، تیم طراحی باید نزدیکترین گزینه تخلیه را بررسی کند. بنابراین، ابتدا تیم از UBM برای انتخاب تمام درهای خروجی احتمالی یا پنجره هایی که می توانند به عنوان درهای ساختمان باز شوند، استفاده می کند. این خروجی ها معمولاً از قسمت IFC می آیند که در آن ویژگی های مختلف ابعاد فضاها را ارائه می دهند. این ابعاد برای محاسبه فواصل و زمان عبور از فضاها و راهروها همانطور که در شکل 12 (ب) ارائه شده است، استفاده می شود. نتیجه نشان داده شده در شکل 12 (ب) فقط با مدل IFC ارائه می شود. با این حال، دسترسی به محیط ساخته شده اطراف ساختمان ممکن است به راه حل های متفاوتی منجر شود که ممکن است با در نظر گرفتن فضای موجود در شکل 13 نشان داده شود.(آ). فاصله محاسبه شده از این فضا تا هر درب احتمالی در ساختمان بیش از 2 دقیقه است، زیرا اتصال عمودی فقط از طریق پله وجود دارد، زیرا آسانسور در مواقع اضطراری ممنوع است. با این حال، با افزودن اطلاعات ساختمان CityGML مجاور، دسترسی به سقف مسطح امن ساختمان مجاور به عنوان داشتن زمان فرار کمتر از 2 دقیقه در نظر گرفته می شود. بر اساس داده های ترکیبی داخلی و خارجی ذخیره شده در UBM، سپس می توان درها و پنجره هایی را که می توانند به عنوان خروجی در موارد اضطراری مورد استفاده قرار گیرند، تعریف کرد ( شکل 13 (ب)).

شکل 11. نمایش UBM از داده های IFC و CityGML.

شکل 12. ( الف ) فضایی که باید در مقابل طرح تخلیه آزمایش شود. ( ب ) اتصالات از فضا به تمام خروجی ها برای محاسبه فواصل و زمان استفاده می شود.

شکل 13. ( الف ) فضایی که باید در مقابل طرح تخلیه آزمایش شود. ( ب ) در نظر گرفتن سقف ساختمان CityGML مجاور برای طرح تخلیه.

در پرسش دوم (Q.2.)، تخلیه باید به فضاهای بیرونی مانند مناطق باز یا باغ ها محدود شود و نه به یک جاده اصلی ترافیک یا مناطق ناامن. اجرای این پرس و جو مستلزم انتخاب درب های خروجی است. اجازه دهید فرض کنیم که درهای خروجی احتمالی همانهایی هستند که در شکل 14 مشخص شده است(آ). تیم طراحی باید به هر یک از این درها نگاه کند و فضای بیرونی که هر در به آن می‌رسد، کاربری زمین و فعالیت‌های آن را بررسی کند. این اطلاعات فقط در داده های CityGML در فضای باز ذخیره می شود و تنها با استفاده از داده های IFC برای آنها در دسترس نیست. از طریق پرس‌و‌جوهای فضایی، می‌توان بین نماهایی که خروجی‌های مشخص‌شده در آن قرار دارند و کلاس ویژگی کاربری زمین، تلاقی کرد و خروجی‌های ناامن نامطلوب را که باید از طرح تخلیه حذف شوند، همانطور که در شکل 14 (ب) نشان داده شده است، تعریف کرد.

شکل 14. ( الف ) سه خروجی احتمالی تخلیه تنها بر اساس اطلاعات ساختمان IFC. ( ب ) ترکیب اطلاعات اطراف برخی از گزینه های خروج را محدود می کند.

Q.3. مناطق بیرونی را انتخاب کنید که دارای درخت یا قابلیت کاربرد/قابلیت کاشت و تجهیز آن با آبنما یا بازدارنده صدا هستند.
Q.4. ساختمان های اطراف را که کاربری صنعتی دارند و در فاصله 300 متری از محل توسعه بیمارستان قرار دارند را بیابید.

سومین پرس و جو (Q.3.) مربوط به بخش بیمار جدید اضافه شده با 250 تخت است. طراحی الحاقیه جدید آن را در قسمت پشتی ساختمان اصلی قرار می دهد. با این حال، یک تجزیه و تحلیل مناسب برای آزمایش تعداد تخت از 250 تخت که بیش از 300 متر از ترافیک سنگین یا مکان های پر سر و صدا فاصله دارند، ارائه شده است. برای انجام این آزمایش، تیم طراحی قبل از هر چیز نیاز به دانستن کاربری‌های تمام ساختمان‌های اطراف دارد تا کاربری‌های دارای آلودگی هوا یا صوتی نامطلوب را شناسایی کند. ثانیا، داده های حمل و نقل نیز برای شناسایی سطوح ترافیک در اطراف بخش های بیمار مورد نیاز است. شکل 15 طرح پیشنهادی را نشان می دهد که باید در مقابل آزمایش شودضوابط فوق الذکر و ساختمانی چند منظوره که دارای کارگاه های پر سروصدا و گروهی رستوران می باشد. علاوه بر این، یک جاده ترافیک سنگین نیز با فاصله نزدیک که باید در تست طراحی گنجانده شود، مشخص شده است.

شکل 15. گسترش پیشنهادی برای بخش بیمار.

با به دست آوردن اطلاعات در مورد محیط ساخته شده اطراف، ما توانسته ایم یک بافر سه بعدی با 300 متر در اطراف ترافیک سنگین و ساختمان نامطلوب ایجاد کنیم. نتیجه در شکل 16 نشان داده شده است . در شکل، دو بافر سه بعدی به وضوح طرح آزمایش شده را قطع می کنند و نشان می دهد که تقریباً 30٪ (حدود 77 تخت) از بخش های بیمار معیارهای آزمایش را برآورده نمی کنند. همچنین می‌توانیم یک کلاس ویژگی جداگانه ایجاد کنیم که فقط شامل اتاق‌های بیمار متقاطع برای گزارش یا بررسی بیشتر باشد.

شکل 16. بافر سه بعدی با طرح آزمایش شده تلاقی می کند

شکل 16 همچنین نشان می دهد که منطقه مشخص شده برای پسوند تا حدودی محدود است. با توجه به اینکه گسترش عمودی نیز با توجه به مقررات ساختمانی در کل منطقه به پنج طبقه محدود شده است، برآورده کردن معیارهای تمام 250 تخت ممکن است دشوار باشد. بنابراین، جایگزین‌های دیگری مانند کاشت درختان، ساخت بازدارنده‌های نویز یا استفاده از ویژگی‌های چشم‌انداز نیز می‌تواند برای تعداد محدودی از تخت‌ها در نظر گرفته شود که توسط تصمیم‌گیرندگان تعریف می‌شود.

این گزینه‌ها بیشتر به طراحی اختصاص دارند. بنابراین، آنها باید بر اساس یک طراحی خاص مبتنی بر ترکیب اطلاعات ساختمان داخلی و داده های محیط ساخته شده در فضای باز، تکمیل شده توسط مطالعات اضافی در مورد حرکات و اثرات باد، سیستم های اکو، تهویه طبیعی و غیره باشند. در مورد ما، ما نه همه این داده ها را دریافت کردیم و نه طراحی نهایی را همانطور که در مرحله تصمیم گیری است. به جای ارائه چیزی غیرواقعی، ترجیح می‌دهیم همه ملاحظات را ارائه کنیم و این جایگزین‌ها را برای مطالعات آینده بگذاریم.

6. نتیجه گیری

با توجه به استانداردهای CityGML و IFC در بخش 3 ، هدف این مقاله توصیف یک مدل ساختمانی یکپارچه (UBM) است که هر دو مدل CityGML و IFC را در بر می گیرد و بنابراین از ترجمه بین مدل ها و از دست دادن اطلاعات جلوگیری می کند. چهار پرسش اعتبارسنجی برای اعتبارسنجی مناسب بودن مدل ساختمان یکپارچه پیشنهادی استفاده شده است. نتایج را می توان به صورت زیر خلاصه کرد:

این واقعیت که UBM در حال توسعه می‌تواند داده‌های CityGML و داده‌های IFC را به‌طور ظاهراً یکپارچه مدیریت کند، از طریق مطالعه موردی تأیید می‌شود. این ادغام از طریق یک مدل ساختمان یکپارچه که هر دو مدل CityGML و IFC را در بر می گیرد، به دست می آید. علاوه بر این، از محدودیت ها و توابع غنی سازی برای پر کردن جداول و فیلدهای خالی پایگاه داده استفاده می شود.
سناریوی انگیزشی به وضوح نیازها و مزایای داشتن یک رویکرد یکپارچه برای مدل‌سازی ویژگی‌های فضایی داخلی و خارجی را نشان می‌دهد.
برخی از محدودیت ها در تنظیم فعلی مشاهده شده است. مدل تنها در چند مورد تایید شده است. برای ارزیابی پتانسیل کامل UBM، مطالعات موردی و تست های اعتبار سنجی بیشتری مورد نیاز است، به عنوان مثال، مجموعه محدودیت ها و توابع غنی سازی هنوز به طور کامل کامل نشده است.

این مقاله موفق شد نشان دهد که چگونه رویکرد تحقیق نقطه شروعی را برای ادغام کامل CityGML و IFC فراهم می کند. پیروی از بحث در مورد تفاوت در مقیاس رویکرد مدیریت داده نشان می دهد (برای موارد ارائه شده) سازگاری بالایی از داده ها، فرآیندهای تبدیل و ردیابی واضح، علاوه بر مراقبت از تمام اطلاعات مکانی مورد نیاز از هر دو استاندارد، بدون هیچ گونه ضرر. . در این صورت نیازی به گسترش هیچ یک از استانداردها با افزونه های دامنه برنامه (ADE) جدید اضافه شده در هر برنامه نیست.

UBM به جای اینکه صرفاً یک ابزار تبدیل بین استانداردهای CityGML و IFC باشد، هم به عنوان یک محیط یکپارچه اجرا شده و هم آزمایش شده است. علاوه بر این، پیاده‌سازی UBM نشان می‌دهد که محاسبات و تحلیل‌های فضایی مختلف را نمی‌توان تنها توسط IFC یا CityGML به صورت جداگانه انجام داد. در صورت بروز بحران، یک رویکرد واحد برای مدلسازی سه بعدی شهر مورد نیاز است. برای مدل سازی یکپارچه، دو رویکرد را می توان برجسته کرد. اولین اطلاعات IFC و CityGML را در UBM ذخیره می کند. این مورد برای مثال در پرس و جوهایی (Q.1 و Q.2) که در آن فرآیندهای مختلفی مورد نیاز است که داده‌های IFC و CityGML را ترکیب می‌کنند، مورد نیاز است. با این حال، در موارد دیگر (به عنوان مثال، Q.3 و Q.4) توابع در حال پرواز را می توان به عنوان ورودی برای عملکردهای دیگر بدون ذخیره داده ها در UBM انجام داد.

به دنبال انگیزه ما در بخش 5 ، شایسته است دوباره تاکید کنیم که هدف ما آزمایش قابلیت کاربردی بودن عملکرد UBM به جای ارزیابی کمی ابزارهای پیاده سازی بود، که البته می تواند موضوع جالبی برای تحقیق در آینده باشد. نه تنها ArcGIS، بلکه رویکردهای مشابه برای پیاده سازی UBM ممکن است بر اساس دیگر پلتفرم های تجاری یا منبع باز باشد.

گام بعدی برای این تحقیق شامل انجام تست های مفصل به منظور ارزیابی و ارتقای مسائل عملکردی در نظر گرفته شده است. با این حال، این بر گسترش مدل به منظور گنجاندن مفاهیم دیگری که در هر استاندارد به طور جداگانه در دسترس هستند، تمرکز خواهد کرد. توابع غنی سازی نیز برای این منظور باید توسعه یابد تا امکان استخراج کلاس های از دست رفته فراهم شود.

منابع

استدلر، آ. Kolbe، T. انسجام فضایی- معنایی در ادغام مدل های سه بعدی شهر. در مجموعه مقالات پنجمین سمپوزیوم بین المللی ISPRS در مورد کیفیت داده های مکانی ISSDQ، Enschede، هلند، 13-15 ژوئن 2007.
پو، اس. زلاتانوا، S. ادغام GIS و CAD در سطح DBMS. در مجموعه مقالات UDMS’06 آلبورگ، آلبورگ، دانمارک، 15–17 مه 2006; ص 961-971.
کلبه، تی. Bacharach, S. CityGML: استانداردی باز برای مدل های سه بعدی شهر . در دسترس آنلاین: http://www.directionsmag.com/articles/citygml-an-open-standard-for-3d-city-models/123103 (در 20 نوامبر 2011 قابل دسترسی است).
Open Geospatial Consortium, Inc. Candidate OpenGIS CityGML Implementation Specification (City Geography Markup Language); گزارش مهندسی OpenGIS® . Gröger, G, Kolbe, T, Czerwinski, A., Eds. 2007. در دسترس آنلاین: http://portal.opengeospatial.org/modules/admin/licence_agreement.php?suppressHeaders=0&access_license_id=3&target=http://portal.opengeospatial.org/files/?artifact_id=22120 نوامبر ( access 2011).
پونتگیا، م. درودی، م. آلبا، MI; اسکایونی، م. Rota, R. ارزیابی پیامدهای انتشار گازهای خطرناک در مناطق شهری از طریق مدل سازی CFD. جی. هازارد. ماتر 2010 ، 176 ، 589-596. [ Google Scholar ] [ CrossRef ]
اسکایونی، م. آلبا، م. روتا، آر. Caragliano، S. یک نمونه اولیه SW مبتنی بر GIS برای مدیریت آمادگی اضطراری که در یک مطالعه موردی واقعی به کار گرفته شد. در مجموعه مقالات کنفرانس بین المللی علوم محاسباتی و کاربردهای آن، سئول، کره، 29 ژوئن تا 2 ژوئیه 2009. Gervasi, O., Taniar, D., Murgante, B., Mun, YS, Lagana, A., Gavrilova, M., Eds.; Springer-Verlag: برلین، آلمان، 2009; جلد 5592، صفحات 79-93، قسمت 1. [ Google Scholar ]
پیچاوانیش، ر. کریمی، ح. آکینجی، بی. Boukamp، F. یک رویکرد مهندسی هستی شناسی برای یکپارچه سازی cad و gis در پشتیبانی از مدیریت زیرساخت. Adv. مهندس به اطلاع رساندن. 2006 ، 20 ، 71-88. [ Google Scholar ]
IAI. صفحه وب سند مدل IFC. اتحاد بین المللی برای قابلیت همکاری در دسترس آنلاین: http://www.buildingsmart-tech.org/specifications/ifc-releases/summary (در 10 ژوئیه 2012 قابل دسترسی است).
راهنمای پیاده سازی مدل Liebich, T. IFC 2x Edition 4 . در دسترس آنلاین: http://www.buildingsmart-tech.org/downloads/ifc (در 10 ژوئیه 2012 قابل دسترسی است).
کلبه، تی. گروگر، جی; Plümer, L. CityGML–دسترسی تعاملی به مدل های سه بعدی شهر. در مجموعه مقالات سمپوزیوم بین المللی اطلاعات جغرافیایی برای مدیریت بلایا، دلفت، هلند، 21 تا 23 مارس 2005.
ایسیکداغ، یو. زلاتانوا، اس. به سوی تعریف چارچوبی برای تولید خودکار ساختمان‌ها در CityGML با استفاده از BIM. در علوم ژئو اطلاعات سه بعدی ; Lee, J., Zlatanova, S., Eds. Springer-Verlag: برلین، آلمان، 2009; صص 79-96. [ Google Scholar ]
IAI. BuildingSMART . در دسترس آنلاین: http://www.iai-tech.org/ (در 25 نوامبر 2011 قابل دسترسی است).
لاپیر، ا. Cote, P. استفاده از خدمات وب باز برای مدیریت داده های شهری: بستر آزمایشی حاصل از ابتکار OGC که خدمات استاندارد CAD/GIS/BIM را ارائه می دهد. در مدیریت داده های شهری و منطقه ای ; شایعه، M.، Coors، V.، Fendel، EM، Zlatanova، S.، Eds. گروه تیلور و فرانسیس: لندن، انگلستان، 2008; صص 381-393. [ Google Scholar ]
قیزلتاس، س. لیت، اف. آکینجی، بی. لیپمن، RR CAD و ادغام GIS. در روش ها و تکنیک های تعاملی در CAD ; انتشارات Auerbach: Boca Raton، FL، USA، 2009; صص 73-110. [ Google Scholar ]
ISO 16739. کلاس های بنیاد صنعت، انتشار 2x، مشخصات پلت فرم . در دسترس آنلاین: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=38056 (دسترسی در 25 نوامبر 2011).
بنر، جی. گایگر، ا. Leinemann, K. Flexible Generation of Semantic Building 3D Models. در مجموعه مقالات اولین کارگاه بین المللی در مورد مدل های شهر سه بعدی نسل بعدی، بن، آلمان، 21 تا 22 ژوئن 2005. صص 17-22.
OGC. کنسرسیوم فضایی باز در دسترس آنلاین: http://www.opengeospatial.org/ (دسترسی در 25 نوامبر 2011).
گروگر، جی. کلبه، تی. چروینسکی، آ. Nagel, C. (Eds.) Open Geospatial Consortium Inc. OpenGIS City Geography.Markup Language (CityGML) Encoding Standard . در دسترس آنلاین: http://portal.opengeospatial.org/modules/admin/license_agreement.php?suppressHeaders=0&access_licence_id=3&target=http://portal.opengeospatial.org/files/?artifact_id=2828011 (در 25 نوامبر قابل دسترسی است ).
OpenGIS Geospatial Consortium, Inc. OpenGIS GeographyMarkup Language (GML3)، مشخصات پیاده سازی . Cox, S., Daisy, P., Lake, R., Portele, C., Whiteside, A., Eds. در دسترس به صورت آنلاین: http://portal.opengeospatial.org/modules/admin/license_agreement.php?suppressHeaders=0&access_ license_id=3&target=http://portal.opengeospatial.org/files/?artifact_id=4700 (در 22011 نوامبر قابل دسترسی است ).
ISO TC211. اطلاعات جغرافیایی/ژئوماتیک . در دسترس آنلاین: http://www.isotc211.org/ (دسترسی در 25 نوامبر 2011).
اطلاعات جغرافیایی – طرح واره فضایی. ISO 19107:2003. در دسترس آنلاین: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=26012 (در 25 نوامبر 2011 قابل دسترسی است).
اطلاعات جغرافیایی-قوانین طرحواره کاربردی. ISO 19109:2005. در دسترس آنلاین: http://www.iso.org/iso/catalogue_detail.htm?csnumber=39891 (در 25 نوامبر 2011 قابل دسترسی است).
Kolbe, T. ارائه و مبادله مدل های سه بعدی شهر با CityGML. در علوم ژئو اطلاعات سه بعدی ; Lee, J., Zlatanova, S., Eds. Springer-Verlag: برلین، آلمان، 2009; صص 15-31. [ Google Scholar ]
کمیسیون اروپایی. دستورالعمل INSPIRE . در دسترس آنلاین: http://www.ec-gis.org/inspire (دسترسی در 25 نوامبر 2011).
هالبرگ، دی. ترندی، وی. در مورد استفاده از BIM 4 بعدی در LMS برای کارهای ساختمانی. J. اطلاع دهید. تکنولوژی ساخت و ساز 2009 ، 16 ، 445-466. [ Google Scholar ]
کارولا، ا. لاهتله، ح. هانیننا، آر. هیچکاک، آر. Chenc، Q. دژکدان، س. Hagströmer, K. BSPro COM-Server- قابلیت همکاری بین ابزارهای نرم افزاری با استفاده از کلاس های پایه صنعتی. انرژی ساختمان 2002 ، 34 ، 901-907. [ Google Scholar ]
ایسیکداغ، یو. زلاتانوا، اس. تجزیه و تحلیل SWOT در مورد اجرای BIM در محیط جغرافیایی. در مدیریت داده های شهری و منطقه ای، UDMS Annuals 2009 ; Krek, A., Rumor, M., Zlatanova, S., Fendel, EM, Eds. CRC Press: Boca Raton، FL، USA، 2009; صص 15-30. [ Google Scholar ]
اتحاد بین المللی برای قابلیت همکاری کلاس های بنیاد صنعت برای GIS . در دسترس آنلاین: http://www.iai.no/ifg/index_history.html (دسترسی در 25 نوامبر 2011).
Nagel, C. تبدیل IFC به CityGML. در مجموعه مقالات نشست گروه کاری OGC 3DIM در نشست OGC TC/PC، فرانسه، پاریس، 9 تا 12 ژوئیه 2007.
ناگل، سی. استدلر، آ. Kolbe، TH الزامات مفهومی برای بازسازی خودکار مدل‌های اطلاعات ساختمان از مدل‌های سه بعدی تفسیر نشده. در مجموعه مقالات آهنگ آکادمیک کنفرانس Geoweb 2009، ونکوور، کانادا، 27-31 ژوئیه 2009.
Van Berlo، L. CityGML Extension for Building Information Modeling (BIM) و IFC. در مجموعه مقالات نرم افزار رایگان و متن باز برای کنفرانس جغرافیایی (FOSS4G) 2009، سیدنی، استرالیا، 4 نوامبر 2009.
IfcExplorer. IfcExplorer CityGML Export . در دسترس آنلاین: http://www.ifcwiki.org/index.php/IfcExplorer_CityGML_Export (در 20 نوامبر 2011 قابل دسترسی است).
نرم افزار ایمن نرم افزار مترجم/تبدیل دسکتاپ FME . در دسترس آنلاین: http://www.safe.com/products/desktop/formats.php (در 20 نوامبر 2011 قابل دسترسی است).
تولک، ا. دیالو، اس. تورنیتسا، سی. Winters, L. خدمات وب M&S Composable برای برنامه های کاربردی شبکه محور. JDMS 2006 ، 3 ، 27-44. [ Google Scholar ]
ون برلو، ال. De Laat، R. ادغام BIM و GIS: توسعه شهر GML GeoBIM Extension. در پیشرفت در علوم ژئو اطلاعات سه بعدی ؛ Kolbe, TH, König, G., Nagel, C., Eds.; Springer-Verlag: برلین، آلمان، 2011; صص 211-225. [ Google Scholar ]
Jech، TJ Lectures در نظریه مجموعه ها . Springer-Verlag: برلین، آلمان، 1971. [ Google Scholar ]
میگل، ام. جردان، ج. سالیکی، اس. تجربیات عملی در کاربرد MDA. در مجموعه مقالات پنجمین کنفرانس بین المللی زبان مدلسازی یکپارچه – زبان و کاربردهای آن، درسدن، آلمان، 30 سپتامبر تا 4 اکتبر 2002.

© 2012 توسط نویسندگان; دارنده مجوز MDPI، بازل، سوئیس. این مقاله یک مقاله با دسترسی آزاد است که تحت شرایط و ضوابط مجوز Creative Commons Attribution (http://creativecommons.org/licenses/by/3.0/) توزیع شده است

;کاربردهای GIS مقالات

درخواست مشاوره

09120049370

8 صبح تا 12 شب