ابزارهای یکپارچه سازی BIM-GIS (IFC Georeferencing و Conversions): نتایج از معیار GeoBIM 2019

خلاصه

ادغام مدل‌های سه‌بعدی شهر با مدل‌های اطلاعات ساختمان (BIM)، که به عنوان GeoBIM ابداع شده است، پشتیبانی بهتر داده‌ها را برای چندین برنامه تسهیل می‌کند، به‌عنوان مثال، به‌روزرسانی نقشه‌های سه‌بعدی، صدور مجوزهای ساختمانی، تجزیه و تحلیل دقیق شهر، طراحی زیرساخت، طراحی ساختمان مبتنی بر زمینه، تا چند نام ببرید برای حل یکپارچگی، چندین موضوع باید حل و فصل شوند، به عنوان مثال، هماهنگی ویژگی ها، قابلیت همکاری، تبدیل فرمت، یکپارچه سازی رویه ها. معیار GeoBIM 2019 که توسط ISPRS و EuroSDR تامین می‌شود، وضعیت پیاده‌سازی ابزارهایی را ارزیابی کرد که به برخی از این مسائل رسیدگی می‌کنند. به طور خاص، در بخشی از معیار شرح داده شده در این مقاله، کاربرد georeferencing برای مدل‌های کلاس‌های بنیاد صنعت (IFC) و ایجاد تبدیل‌های ثابت بین مدل‌های شهر سه بعدی و BIM بررسی می‌شود. در نظر گرفتن OGC CityGML و buildingSMART IFC به عنوان استانداردهای مرجع. در معیار، مجموعه داده‌های نمونه در دو استاندارد مرجع ارائه شد. از داوطلبان خارجی خواسته شد تا روش‌های ارجاع جغرافیایی را برای مدل‌های IFC و ابزارهای تبدیل بین CityGML و IFC توصیف و آزمایش کنند. از تجزیه و تحلیل پاسخ‌های ارائه شده و مجموعه داده‌های پردازش شده، می‌توان متوجه شد که در حالی که ابزارها و رویه‌هایی برای پشتیبانی از ارجاع جغرافیایی و تبدیل داده‌ها، تعریف جامع از الزامات، قوانین روشن برای انجام چنین دو وظیفه و همچنین فن‌آوری قوی وجود دارد. راه‌حل‌های پیاده‌سازی آنها، هنوز فاقد عملکرد هستند. این مسائل خاص می توانند نقطه شروع معقولی برای برنامه ریزی برنامه های ادغام GeoBIM بعدی باشند. در معیار، مجموعه داده‌های نمونه در دو استاندارد مرجع ارائه شد. از داوطلبان خارجی خواسته شد تا روش‌های ارجاع جغرافیایی را برای مدل‌های IFC و ابزارهای تبدیل بین CityGML و IFC توصیف و آزمایش کنند. از تجزیه و تحلیل پاسخ‌های ارائه شده و مجموعه داده‌های پردازش شده، می‌توان متوجه شد که در حالی که ابزارها و رویه‌هایی برای پشتیبانی از ارجاع جغرافیایی و تبدیل داده‌ها، تعریف جامع از الزامات، قوانین روشن برای انجام چنین دو وظیفه و همچنین فن‌آوری قوی وجود دارد. راه‌حل‌های پیاده‌سازی آنها، هنوز فاقد عملکرد هستند. این مسائل خاص می توانند نقطه شروع معقولی برای برنامه ریزی برنامه های ادغام GeoBIM بعدی باشند. در معیار، مجموعه داده‌های نمونه در دو استاندارد مرجع ارائه شد. از داوطلبان خارجی خواسته شد تا روش‌های ارجاع جغرافیایی را برای مدل‌های IFC و ابزارهای تبدیل بین CityGML و IFC توصیف و آزمایش کنند. از تجزیه و تحلیل پاسخ‌های ارائه شده و مجموعه داده‌های پردازش شده، می‌توان متوجه شد که در حالی که ابزارها و رویه‌هایی برای پشتیبانی از ارجاع جغرافیایی و تبدیل داده‌ها، تعریف جامع از الزامات، قوانین روشن برای انجام چنین دو وظیفه و همچنین فن‌آوری قوی وجود دارد. راه‌حل‌های پیاده‌سازی آنها، هنوز فاقد عملکرد هستند. این مسائل خاص می توانند نقطه شروع معقولی برای برنامه ریزی برنامه های ادغام GeoBIM بعدی باشند. از داوطلبان خارجی خواسته شد تا روش‌های ارجاع جغرافیایی را برای مدل‌های IFC و ابزارهای تبدیل بین CityGML و IFC توصیف و آزمایش کنند. از تجزیه و تحلیل پاسخ‌های ارائه شده و مجموعه داده‌های پردازش شده، می‌توان متوجه شد که در حالی که ابزارها و رویه‌هایی برای پشتیبانی از ارجاع جغرافیایی و تبدیل داده‌ها، تعریف جامع از الزامات، قوانین روشن برای انجام چنین دو وظیفه و همچنین فن‌آوری قوی وجود دارد. راه‌حل‌های پیاده‌سازی آنها، هنوز فاقد عملکرد هستند. این مسائل خاص می توانند نقطه شروع معقولی برای برنامه ریزی برنامه های ادغام GeoBIM بعدی باشند. از داوطلبان خارجی خواسته شد تا روش‌های ارجاع جغرافیایی را برای مدل‌های IFC و ابزارهای تبدیل بین CityGML و IFC توصیف و آزمایش کنند. از تجزیه و تحلیل پاسخ‌های ارائه شده و مجموعه داده‌های پردازش شده، می‌توان متوجه شد که در حالی که ابزارها و رویه‌هایی برای پشتیبانی از ارجاع جغرافیایی و تبدیل داده‌ها، تعریف جامع از الزامات، قوانین روشن برای انجام چنین دو وظیفه و همچنین فن‌آوری قوی وجود دارد. راه‌حل‌های پیاده‌سازی آنها، هنوز فاقد عملکرد هستند. این مسائل خاص می توانند نقطه شروع معقولی برای برنامه ریزی برنامه های ادغام GeoBIM بعدی باشند. می‌توان متوجه شد که در حالی که ابزارها و رویه‌هایی برای پشتیبانی از ارجاع جغرافیایی و تبدیل داده‌ها وجود دارد، تعریف جامع الزامات، قوانین واضح برای انجام چنین دو وظیفه و همچنین راه‌حل‌های فناورانه محکمی که آنها را پیاده‌سازی می‌کنند، هنوز فاقد عملکرد هستند. این مسائل خاص می توانند نقطه شروع معقولی برای برنامه ریزی برنامه های ادغام GeoBIM بعدی باشند. می‌توان متوجه شد که در حالی که ابزارها و رویه‌هایی برای پشتیبانی از ارجاع جغرافیایی و تبدیل داده‌ها وجود دارد، تعریف جامع الزامات، قوانین واضح برای انجام چنین دو وظیفه و همچنین راه‌حل‌های فناورانه محکمی که آنها را پیاده‌سازی می‌کنند، هنوز فاقد عملکرد هستند. این مسائل خاص می توانند نقطه شروع معقولی برای برنامه ریزی برنامه های ادغام GeoBIM بعدی باشند.

کلید واژه ها:

ارجاع جغرافیایی ; تبدیل ها قابلیت همکاری CityGML ; کلاس های بنیاد صنعت ; مدل های اطلاعات ساختمان ; مدل های سه بعدی شهر ; استانداردها

۱٫ معرفی

در سال‌های اخیر، ادغام اطلاعات جغرافیایی سه‌بعدی (مدل‌های شهر سه بعدی) و مدل‌های اطلاعات ساختمان (BIM)، که به عنوان GeoBIM ابداع شده‌اند، به موضوع مهمی تبدیل شده است که توسط جامعه رو به رشدی که از چندین زمینه در آکادمی (ژئو اطلاعات، ژئوماتیک، ساخت‌وساز، معماری و شهرسازی) و همچنین از سازمان های خارج از آکادمی (موسسات مرتبط با دولت، آژانس های نقشه برداری و کاداستر ملی، شرکت های خصوصی و غیره).

تبادل اطلاعات بین منابع جغرافیایی (مدل‌های شهر سه بعدی) و منابع BIM، غنی‌سازی متقابل دو نوع اطلاعات را با مزایایی برای هر دو زمینه، به عنوان مثال، به‌روزرسانی خودکار مدل‌های سه بعدی شهر با ویژگی‌های سطح بالای جزئیات، نمایش خودکار، امکان‌پذیر می‌سازد. BIM در زمینه خود، تست های خودکار طراحی و غیره [ ۱ ، ۲ ، ۳ ، ۴ ، ۵ ، ۶ ، ۷ ، ۸ ، ۹ ، ۱۰ ، ۱۱ ، ۱۲ ].

GeoBIM و به طور کلی، چالش یکپارچه سازی از چندین موضوع تشکیل شده است:

هماهنگی و سازگاری خود داده ها اولین نیاز است که باید به طور ملموس با ویژگی های مشابه یا قابل هماهنگی (به عنوان مثال، دقت، نمایش هندسی و معنایی، مقدار جزئیات، ارجاع جغرافیایی) با هم هماهنگ شوند.
قابلیت همکاری برای توسعه یک روش ادغام قابل اعتماد و تکرارپذیر اساسی است. ابرداده ها باید واضح و جامع باشند و قالب های داده باید به طور منحصر به فرد توسط انسان و هر نرم افزار پشتیبانی کننده درک و تفسیر شوند. علاوه بر این، قرار است یک مجموعه داده متقابل هنگام انجام چندین واردات و صادرات توسط ابزارهای نرم افزاری بدون تغییر باقی بماند، احتمالاً آن را به فرمت های بومی خاص خود تبدیل کرده و دوباره صادر می کند. در این راستا، برای تسهیل درک مشترک و قوانین مورد توافق، استفاده از استانداردهای باز مطلوب است.
تبدیل مؤثر بین قالب‌های مختلف باید مجاز باشد، به عنوان مثال، تبدیل یک مجموعه داده در قالب استاندارد شده به دیگری در انطباق کامل با مشخصات و ویژگی‌های قالب نهایی. در این نقطه، هر دو مفهوم قبلی از هماهنگی ویژگی‌های معمولی نمایش حاصل و قابلیت همکاری قالب تولید شده (اعتبار هندسه، سازگاری معناشناسی و غیره) باید در نظر گرفته شوند.
در نهایت، ارائه دهندگان داده و رویه ها باید تغییر کنند تا از اطلاعات GeoBIM یکپارچه به جای BIM و GIS به طور جداگانه استفاده شود. همکاری با بسیاری از سهامداران و بازیگران به طور کلی برای این مرحله ضروری است.

به منظور ارزیابی میزان اثربخشی نرم افزارهای فعلی برای حل مسائل قابلیت همکاری و تبدیل، پروژه معیار GeoBIM ( https://3d.bk.tudelft.nl/projects/geobim-benchmark/ ) در سال ۲۰۱۹ پیشنهاد و راه اندازی شد. توسط انجمن بین المللی فتوگرامتری و سنجش از دور (ISPRS) و انجمن اروپایی تحقیقات داده های مکانی (EuroSDR). به طور خاص، هدف به دست آوردن تصویر بهتری از وضعیت پشتیبانی نرم افزار برای دو استاندارد باز پرکاربرد برای مدل های سه بعدی شهر و BIM، یعنی به ترتیب CityGML توسط کنسرسیوم فضایی باز (OGC) [13] و صنعت بود . کلاس های بنیادی (IFC) توسط کنسرسیوم buildingSMART [ ۱۴]. با توجه به تجربه نویسندگان و رد و بدل شده در چندین موقعیت غیررسمی با جامعه گسترده تر، در استفاده از این دو قالب داده استاندارد و به ویژه نحوه مدیریت آنها توسط نرم افزار، کاستی هایی وجود دارد. هدف از معیار بررسی قابلیت همکاری نرم افزار برای CityGML و IFC [ ۱۵ ] بود. این از طریق دو وظیفه مورد مطالعه قرار گرفت: وظیفه ۱: پشتیبانی از IFC در BIM و سایر نرم افزارها چیست؟ و وظیفه ۳: پشتیبانی از CityGML در GIS و سایر ابزارها چیست؟ نتایج این دو کار به تفصیل در مقاله ای متفاوت مورد بررسی قرار خواهد گرفت.

هدف اول این مقاله، مطالعه ژئو ارجاع جغرافیایی است که وظیفه ۲ در معیار بود. ارجاع جغرافیایی مدل‌های BIM یک موضوع اصلی در GeoBIM است که هم به هماهنگی (کیفیت اطلاعات ارجاع‌دهی) و هم به قابلیت همکاری (نحوه تفسیر و استفاده از این اطلاعات توسط نرم‌افزار) مربوط می‌شود. این مطالعه بر روی جنبه هماهنگی مشکل تمرکز دارد، یعنی اینکه چگونه نرم افزار می تواند اطلاعات ارجاع جغرافیایی را در فایل های IFC بخواند و بنویسد. این موضوع به ویژه مهم است زیرا IFC از چندین روش برای ذخیره اطلاعات ارجاع جغرافیایی پشتیبانی می کند ( بخش ۲٫۲٫۳ ).

هدف دوم این مقاله ارزیابی ابزارهای تبدیل است (وظیفه ۴). باز هم بحث هماهنگی (تغییر ویژگی های مدل) و قابلیت همکاری (خروجی فایل های معتبر قابل خواندن در نرم افزارهای دیگر) است. این در بخش ۲٫۳ مورد بحث قرار گرفته است . ارزیابی مهم است زیرا تعداد فزاینده ای از ابزارها برای تبدیل CityGML به IFC و به ویژه IFC به CityGML توسعه یافته است. مسائل مهمی که در اینجا باید ارزیابی شوند، قابلیت تبدیل ابزارها و اینکه چگونه نتیجه نهایی تبدیل بین آنها متفاوت است، است.

ساختار مقاله به شرح زیر است. بخش ۲ به شرح سه موضوع فرعی اول برای ادغام اختصاص داده شده است: هماهنگ سازی ( بخش ۲٫۱ )، قابلیت همکاری ( بخش ۲٫۲ ) و تبدیل ( بخش ۲٫۳ )، با برخی راه حل های موجود و کاستی ها و شکاف های بالقوه. سپس، در بخش ۳ ، تنظیم معیار و روش شناسی ارزیابی شرح داده شده است. نتیجه قابلیت همکاری جغرافیایی در بخش ۴ گزارش شده است و نتیجه مطالعه ابزارهای تبدیل در بخش ۵ آمده است . مقاله با اظهارات پایانی و یادآوری برای کارهای آینده پایان می یابد ( بخش ۶ ).

۲٫ پیشینه یکپارچه سازی

۲٫۱٫ هماهنگ سازی: مدل های سه بعدی شهر در مقابل ویژگی های BIM

در زمینه GeoBIM، آشکار است که مدل‌های شهر سه بعدی و BIM از جنبه‌های مختلفی متفاوت هستند (به جدول ۱ مراجعه کنید )، به عنوان مثال، De Laat و Van Berlo [ ۱۶ ]. این نشان می‌دهد که برای ادغام این دو مدل برای هر برنامه کاربردی (علاوه بر تجسم خالص)، مهم است که ویژگی‌های آنها سازگار و همسو باشند. چنین هماهنگی مستلزم آن است که همه داده ها با الزامات یکی از دو مدل، یا مدل های شهر سه بعدی یا BIM مطابقت داشته باشند. اگر مورد استفاده شخص ثالثی شناسایی شود، می‌توانند چیز دیگری باشند. در این مورد آخر، هر دو مدل باید تغییر کنند تا نیازهای جدید را به درستی برآورده کنند.

یکی از آشکارترین تناقضات بین این دو مدل مربوط به ارجاع جغرافیایی است. در حالی که ارجاع جغرافیایی یک عمل قدیمی در GIS به طور کلی و در مدل های سه بعدی شهر به طور خاص است، یک ویژگی نسبتاً جدید برای BIM است. طراحان معمولاً در یک سیستم محلی دکارتی کار می کنند، بدون اینکه نیاز به مدیریت پیچیده تری از سیستم مختصات جهانی/کروی باشد. مدل‌سازی سه‌بعدی، طراحی به کمک کامپیوتر (CAD) و نرم‌افزار BIM می‌توانند هنگام کار به دور از مبدا مختصات، مشکلاتی را ایجاد کنند، همانطور که در سیستم‌های georeferenced اتفاق می‌افتد. به همین دلیل، ذخیره اطلاعات مربوط به ارجاع جغرافیایی در BIM اولویت نداشت. بنابراین، نهادهای قدرتمندتر برای مدیریت آن در IFC فقط در جدیدترین نسخه ها اضافه می شوند ( بخش ۲٫۲٫۳ ).

۲٫۲٫ قابلیت همکاری و فرمت های استاندارد داده

قابلیت همکاری برای تفسیر دقیق و استفاده از داده ها در سیستم ها و ابزارها و همچنین برای استفاده مجدد و تبادل داده ها اساسی است. از این رو، ادغام به شدت توسط شفافیت و توضیح داده ها و ابرداده ها پشتیبانی می شود. اینجاست که استانداردها و به ویژه استانداردهای باز نقش حیاتی خود را دارند. چندین استاندارد و مدل داده باز برای نشان دادن، مبادله و پشتیبانی از یکپارچگی در زمینه مدل های شهر سه بعدی و در زمینه BIM تولید شده است. برخی از نمونه‌های بین‌المللی، مدل‌های داده‌ای هستند که توسط دستورالعمل اروپایی برای زیرساخت اطلاعات فضایی در اروپا (INSPIRE) پیشنهاد شده‌اند. gbXML؛ OGC LandInfra. در این میان، شناخته شده ترین و مورد استفاده ترین استانداردهای باز CityGML توسط OGC ( بخش ۲٫۲٫۱) است.برای مدل های سه بعدی شهر و IFC توسط buildingSMART برای BIM ها ( بخش ۲٫۲٫۲ ). در سطح ملی، مدل‌های خاصی وجود دارد که اغلب مبتنی بر استانداردهای بین‌المللی یا حداقل مرتبط با آن هستند [ ۱۷ ، ۱۸ ]. بنابراین، این استانداردهای باز به عنوان راهنمای مرجع برای بررسی یکپارچگی GeoBIM در اکثر مطالعات در نظر گرفته می‌شوند (به عنوان مثال، Sun و همکاران [ ۱۱ ]، Daum و همکاران [ ۱۹ ]) و در تلاش مشترک بین OGC و buildingSMART انتخاب شده‌اند. ادغام داده های جغرافیایی و داده های BIM.

۲٫۲٫۱٫ OGC CityGML

CityGML (توسط OGC) [ ۲۰ ] گسترده ترین استاندارد بین المللی برای ذخیره و تبادل مدل های سه بعدی شهر با معناشناسی در حوزه جغرافیایی است. شرح هندسه و معناشناسی اشیاء شهر را ساختار می دهد.

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

CityGML به طور سنتی به عنوان یک طرح کاربردی برای زبان نشانه گذاری جغرافیا (GML) پیاده سازی می شود. CityGML از نسخه ۳٫۱٫۱ GML [ ۲۱ ] استفاده می کند. این یک فرمت باز است و برای انسان قابل خواندن است. این بدان معناست که حتی در صورت از دست دادن سازگاری با نرم افزار، می توان اطلاعات را به طور بالقوه بازیابی کرد. با این حال، GML مسائل را از دیدگاه توسعه‌دهنده نرم‌افزار ارائه می‌کند (به عنوان مثال، در مورد نمایش هندسه، به http://erouault.blogspot.com/2014/04/gml-madness.html مراجعه کنید ). عواقب این امر توسط وظیفه ۳ معیار نیز اشاره شده است [ ۱۵ ].

برای غلبه بر مشکلات، پیاده‌سازی‌های جایگزینی مانند پایگاه داده زبان پرس و جو ساختاریافته (SQL) – PostgreSQL، در ۳DCityDB [ ۲۲ ] و اخیراً در نمادگذاری شی جاوا اسکریپت (JSON)، در CityJSON 1.0 ( https://www) پیشنهاد شدند. cityjson.org ) [ ۲۳ ]، بر اساس مدل داده CityGML 2.0. این گزینه ها برای بهبود قابلیت استفاده و اثربخشی مدل داده CityGML در نظر گرفته شده است.

پیاده سازی GML رسمی در نظر گرفته می شود که توسط استاندارد توصیه شده است. در نتیجه، مطالعات و ابزارهای پشتیبانی کننده از تبدیل ها نیز آن را به عنوان مرجع نگه می داشتند. به همین دلیل، برای تبدیل در این مطالعه معیار نیز استفاده می شود.

CityGML 2.0 (نسخه فعلی) شامل کلاس هایی است که به ۱۲ ماژول ساختار یافته اند، که هر یک از آنها ماژول اصلی را گسترش می دهند، شامل کلی ترین کلاس ها در مدل داده، با طبقه بندی های ویژه شهر، به عنوان مثال، ساختمان، پل، آب بدن، CityFurniture، LandUse، امداد، حمل و نقل، تونل، پوشش گیاهی. توسعه‌یافته‌ترین و پرکاربردترین ماژول در عمل، ماژول ساختمان است، که در آن مدل‌های سه‌بعدی شهر و BIM در اولویت قرار می‌گیرند، اگرچه گسترش اخیر دامنه BIM بیشتر و بیشتر شامل حوزه زیرساخت نیز می‌شود.

مدل داده های معنایی CityGML با نسخه پیشنهادی ۳٫۰ ( https://github.com/opengeospatial/CityGML-3.0CM ) در حال به روز رسانی است. برخی از ویژگی های نسخه ۳٫۰ برای نزدیک کردن مدل CityGML به BIM در نظر گرفته شده است. تغییر اصلی با توجه به نسخه ۲٫۰ اضافه شدن یک مفهوم فضایی جدید است [ ۲۴ ]. مفهوم فضای جدید را می توان برای تعریف با استفاده از وراثت، کلاس های جدید به عنوان مثال، ” BuildingConstructiveElement” استفاده کرد.“. این کلاس امکان ذخیره عناصر ساختمانی با جزئیات را، معمولی BIM، ارائه می دهد. یک رویکرد مشابه برای عناصر بازکننده (به عنوان مثال، دیوارهای خالی کردن جامدات) و عناصر پرکننده (به عنوان مثال، پنجره ها، درها) در مدل داده ۳٫۰ نیز اعمال می شود. نحوه پر کردن کلاس‌های جدید و نحوه تبدیل/تراز کردن مفاهیم جغرافیایی در مدل داده‌های CityGML به کلاس‌های جدید BIM گرا، سؤال بعدی برای حل قابلیت همکاری است.

هندسه‌های CityGML اساساً برای همه کلاس‌ها یکسان هستند: اشیاء به‌عنوان سطوح مرزی تعبیه‌شده در سه‌بعدی نشان داده می‌شوند و از چهره‌های مثلثی و چند ضلعی تشکیل شده‌اند. هیچ تغییری در مدیریت هندسه برای نسخه ۳٫۰ پیشنهاد نشده است.

۲٫۲٫۲٫ کلاس های بنیاد صنعت (IFC)

استاندارد کلاس‌های بنیاد صنعت buildingSMART (IFC) ( https://technical.buildingsmart.org/standards/ifc/ ) یک مدل داده استاندارد باز برای BIM است که از طریق برنامه‌های کاربردی نرم‌افزار، دامنه‌ها و موارد استفاده در معماری به اشتراک گذاشته و مبادله می‌شود. رشته های مهندسی و ساخت و ساز (AEC) و مدیریت تسهیلات (FM). این شامل کلاس هایی برای توصیف مفاهیم فیزیکی و انتزاعی (به عنوان مثال، هزینه، برنامه، و غیره) در مورد AEC-FM برای ساختمان ها است. نسخه های جدید برنامه ریزی شده آن را به زیرساخت ها و انواع دیگر ساخت و سازها گسترش می دهند ( https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/ ). همچنین به عنوان استاندارد بین المللی ISO 16739 اقتباس شده است [ ۲۵]. این استاندارد شامل سازه‌های مرتبط برای طیف گسترده‌ای از رشته‌ها، موارد کاربرد و فرآیندهای مرتبط با حوزه ساخت و ساز است، که برجسته‌ترین آنها توصیف معنایی و نمایش هندسی عناصر ساختمانی معمولی و روابط آنها است.

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

یک پیچیدگی اضافی به مدل معنایی با امکان ذخیره یک نوع شی با استفاده از چندین موجودیت داده شده است. برای مثال، لایه‌های درون یک شی دیوار مرکب را می‌توان با استفاده از IfcMaterialLayerSet مرتبط نشان داد، اما همچنین به‌عنوان یک تجزیه عمومی‌تر که در آن هر لایه دیواری به عنوان یک IfcBuildingElementPart مجزا مدل‌سازی می‌شود. علاوه بر این، تعداد زیادی از ویژگی‌ها را می‌توان با موجودیت‌ها مرتبط کرد، و هم به‌طور مستقیم یا از طریق مجموعه‌های ویژگی‌ها، از والد به ارث رسید.

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

اصطلاحات اضافی، که می توانند در IFC استفاده شوند، در فرهنگ لغت داده های buildingSMART (bSDD) تعریف شده اند و بر اساس چارچوب بین المللی برای فرهنگ لغت (IFD) ( http://bsdd.buildingsmart.org ) مدل شده اند. این بر اساس استاندارد ISO 12006-3 است.

نسخه های فعلی IFC عبارتند از: IFC2x3 که در سال ۲۰۰۵ منتشر شد (با آخرین تصحیح در سال ۲۰۰۷) و IFC4.1 از سال ۲۰۱۸٫ در زمان نگارش این مقاله، هنوز هم نسخه IFC2x3 که بیشتر اجرا شده و مورد استفاده قرار می گیرد، با اختلاف زیاد است. به همین دلیل، هر دو نسخه در این مطالعه معیار در نظر گرفته شدند.

IFC جنبه های بسیاری را از ISO 10303 [ ۲۶ ] که به طور غیررسمی به عنوان STEP شناخته می شود، مشتق می کند. اکثر تعاریف هندسه از ISO 10303-42 مشتق شده اند و فرمت های تبادل معمولی بر اساس فایل فیزیکی STEP (SPF، ISO 10303-21) و رمزگذاری XML (ISO 10303-28) است.

مدل‌سازی پارامتری معمولاً در BIM و IFC استفاده می‌شود که کدگذاری انواع هندسه‌ها را ممکن می‌سازد. این شامل عملیات بولی و جابجایی های پیچیده است، به عنوان مثال جابجایی یک نمایه دلخواه در امتداد یک منحنی در حالی که بردار عادی را محدود می کند. علاوه بر این، هندسه های صریح در قالب نمایش های مرزی و (افزوده شده در IFC4) پشتیبانی کارآمد برای مش های مثلثی پشتیبانی می شوند. اجرای نوع قبلی هندسه به این صورت است که پشتیبانی از پشته کامل رویه‌های هندسی در IFC یک تلاش اجرایی اصلی است و به دلیل انتخاب‌های پیاده‌سازی گاهی اوقات می‌تواند به نتایج متفاوتی در واردات برنامه‌ها منجر شود. بنابراین، پیچیدگی می‌تواند پیامدهایی بر قابلیت همکاری و نحوه خواندن و صدور مجدد قطعات مختلف نرم‌افزار هندسه مشابه داشته باشد.

این سطح بالایی از پیچیدگی می تواند برای اطمینان از سازگاری در استفاده از مدل، از جمله تبدیل به فرمت های دیگر و از آن، چالش برانگیز باشد.

۲٫۲٫۳٫ ارجاع جغرافیایی فایل های IFC

ارجاع جغرافیایی مناسب یک فایل IFC امکان پیوند بین مدل یک ساختمان یا ساخت و ساز واحد را در زمینه و محیط آن فراهم می کند. چندین گزینه برای ذخیره اطلاعات مربوط به ارجاع جغرافیایی در IFC وجود دارد، با سطوح مختلف جزئیات همانطور که توسط کلمن و هندریک [ ۲۷ ] توضیح داده شده است. این گزینه ها از اطلاعات آدرس اولیه تا تعریف یک افست بین سیستم مختصات پروژه و مبدأ جهانی یک سیستم مرجع مختصات (CRS) و چرخش متناظر XY-Plane (جدول ۲) را شامل می شود . با در نظر گرفتن مدل هایی که از عمل به دست می آیند، می توان متوجه شد که گزینه LoGeoRef20 رایج ترین مورد استفاده در مدل های صادراتی IFC توسط نرم افزار BIM است. LoGeoRef30یک روش ارجاع جغرافیایی رسمی تعریف شده در استاندارد IFC نیست، اما گاهی اوقات توسط ابزارهای نرم افزاری و متخصصان استفاده می شود. LoGeoRef50 بهترین گزینه برای ارجاع جغرافیایی از دیدگاه geodata/geomatics است، اما هنوز در عمل برای ساخت مدل‌های IFC بسیار غیر معمول است (احتمالاً بیشتر در مدل‌های BIM زیرساخت استفاده می‌شود). معمولاً درک اینکه آیا و چگونه یک فایل IFC ارجاع داده می شود پیچیده است، اگرچه برخی از ابزارها (به عنوان مثال، IfcGeoRefChecker در https://github.com/dd-bim/IfcGeoRef ) برای بررسی این موضوع در دسترس هستند.

ارجاع جغرافیایی BIM برای معماران و توسعه دهندگان نرم افزار در اولویت نبوده است. بنابراین، موضوع ژئو ارجاع و CRS ها که به طور سنتی متعلق به حوزه ژئوماتیک و کارتوگرافی است، به تازگی به دنیای بازنمایی معماری و ابزارهای BIM رسیده است. مشکل دیگر برای توسعه دهندگان ابزار BIM، تنوع گزینه های ارجاع جغرافیایی مورد استفاده در IFC است (همانطور که در جدول ۲ ذکر شده است ). در نتیجه، معماران و مدل سازان به طور منظم اطلاعات مربوط به ارجاع جغرافیایی دقیق را ذخیره و استفاده نمی کنند.

در معیار، توانایی ابزار برای ارجاع جغرافیایی IFC از دو منظر مورد بررسی قرار گرفت (به بخش ۳٫۱ مراجعه کنید ):

تفسیر اطلاعات ارجاع جغرافیایی ارائه شده در فایل IFC،
قابلیت ویرایش اطلاعات ارجاع جغرافیایی

بنابراین تمرکز معیار مطالعه روش‌های وارد کردن و ایجاد اطلاعات ارجاع جغرافیایی بود. دیدگاه دیگری که مورد مطالعه قرار نگرفت، قابلیت ابزارها برای استفاده از این اطلاعات برای بهینه سازی ارجاع جغرافیایی است. این یک مسئله غیر پیش پا افتاده است، به ویژه از آنجایی که سیستم مختصات در مدل IFC بر اساس یک سیستم دکارتی محلی است در حالی که CRS بر اساس یک مدل زمین بیضی شکل است (که باعث می شود مقیاس در مدل تغییر کند). جنبه‌های ژئودتیکی تفصیلی از ارجاع جغرافیایی به‌عنوان مثال، توسط Uggla و Horemuz [ ۲۸ ] بررسی شده‌اند و یک روش عمل‌گرایانه برای بازیابی اطلاعات georeference برای تجسم در Diakité و Zlatanova [ ۲۹ ] یافت می‌شود .

۲٫۳٫ تبدیل ها

تبدیل از BIM به مدل های شهر سه بعدی و از مدل های سه بعدی شهر به BIM باید هر دو با مسائل همکاری و هماهنگی سروکار داشته باشد. بنابراین مدل به دست آمده باید از نظر هندسی و معنایی با توجه به فرمت خروجی انتخاب شده معتبر باشد. علاوه بر این، ویژگی‌های مدل حاصل باید با ویژگی‌های پیش‌بینی‌شده برای فرمت خروجی سازگار باشد (به بخش ۲٫۱ مراجعه کنید.). یک روش تبدیل بهینه امکان انتخاب ویژگی‌های خاص را با توجه به مدلی که چنین نتیجه‌ای قرار است در آن ادغام شود، می‌دهد. به عنوان مثال، اگر قرار است یک BIM در یک مدل شهری LoD1 ادغام شود (طبق LoD های CityGML)، نتیجه تبدیل باید یک نمایش مرزی از تعمیم ساختمان به عنوان یک ردپای اکسترود شده به ارتفاع باشد. اگرچه چالش برانگیزتر است، حتی برعکس آن نیز باید صادق باشد: نمایش مرزی یک مدل شهر سه بعدی، اگر به BIM تبدیل شود، باید دیوارهای جامد ضخیم و جزئیات مدل‌سازی شده را تا آنجایی که ممکن است و برای کاربرد خاص در نظر گرفته شده معقول باشد، به دست آورد.

علاوه بر نرم افزار خارج از قفسه قادر به تبدیل، مطالعات متعددی برای پیشنهاد روش های تبدیل توسعه یافته است. بیشتر آنها بر روی تبدیل IFC به CityGML تمرکز دارند، به عنوان مثال، Arroyo Ohori و همکاران. [ ۷ ]، استوفس و همکاران. [ ۹ ]، دانکرز و همکاران. [ ۳۰ ]، اولسون [ ۳۱ ]، یو و تئو [ ۳۲ ]. مواردی که در اینجا ذکر شد، تلاش‌هایی هستند، در میان ادبیات عظیمی (مثلاً، لیو و همکاران [ ۱ ])، با در نظر گرفتن هماهنگی ویژگی‌های مربوطه، از جمله معناشناسی و هندسه، و گاهی کاوش در تعمیم سطوح مختلف جزئیات CityGML. .

با این حال، همانطور که قبلا ذکر شد، توسط Arroyo Ohori و همکاران. [ ۷ ]، یک روش شناسی کامل که هم معناشناسی و هم هندسه را با ویژگی های مدل سه بعدی شهر تبدیل می کند، به عنوان مفید برای استفاده از مدل برای تجزیه و تحلیل، در تلاش های قبلی موفقیت چندانی نداشت. علاوه بر این، یافتن مسائلی در کیفیت داده‌های حاصل، متشکل از نادرستی معنایی و هندسی، ناهماهنگی یا از دست دادن اطلاعات، استفاده از پارادایم فضایی- معنایی اشتباه در مدل‌های حاصل، علاوه بر خطاهای احتمالاً جدی‌تر عدم اعتبار، کاملاً رایج است. نامناسب یا تغییر شکل [ ۳۳ ].

مطالعات کمتری تبدیل از یک مدل CityGML به IFC را بررسی کردند (به عنوان مثال، Salheb [ ۳۴ ]).

آزمایش‌های انجام‌شده در معیار GeoBIM با هدف ارزیابی کیفیت مدل‌های حاصل از ابزارهای تبدیل فعلی، در هر دو جهت، از IFC به CityGML و از CityGML به IFC، از نظر اعتبار مدل‌های تولید شده (هم‌کاری) و تبدیل و نقشه برداری از ویژگی های عنصر، سازگار با خروجی حاصل (هماهنگی).

۳٫ روش شناسی

۳٫۱٫ تنظیم عمومی معیار GeoBIM

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

وظیفه ۱: پشتیبانی از IFC در نرم افزار BIM (و سایر نرم افزارها) چیست؟
وظیفه ۲: چه گزینه هایی برای ارجاع جغرافیایی داده های BIM موجود است؟ (این وظیفه اولین هدف این مقاله است.)
وظیفه ۳: پشتیبانی از CityGML در GIS (و سایر ابزارها) چیست؟
وظیفه ۴: چه گزینه هایی برای تبدیل (نرم افزار و رویه ای) (هم IFC به CityGML و هم CityGML به IFC) موجود است؟ (این وظیفه دومین هدف این مقاله است.)

برای تسهیل این کارها مجموعه ای از مجموعه داده های نماینده IFC و CityGML ارائه شد [ ۳۵ ] و توسط شرکت کنندگان خارجی، داوطلبانه، در نرم افزار یا روشی که می خواهند آزمایش کنند استفاده می شود [ ۶ ]. جزئیات کامل در مورد نرم افزار تست شده و لیست کامل شرکت کنندگان را می توانید در صفحات مربوطه وب سایت بنچمارک ( https://3d.bk.tudelft.nl/projects/geobim-benchmark/software.html برای نرم افزار تست شده و https://3d.bk.tudelft.nl/projects/geobim-benchmark/participants.html برای لیست شرکت کنندگان.).

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

۳٫۲٫ مجموعه داده های ارائه شده

تعدادی مجموعه داده از چندین سازمان شناسایی، پیش پردازش شده و برای این فعالیت معیار تایید شده است ( جدول ۳ – برای جزئیات بیشتر به Noardo و همکاران [ ۳۵ ] مراجعه کنید). مجموعه داده‌ها برای آزمایش رایج‌ترین ویژگی‌های این داده‌ها و مسائل اصلی شناسایی شده در رابطه با جنبه‌های جالب اما دشوار قالب انتخاب شدند.

۳٫۲٫۱٫ مجموعه هندسه IFC

هندسه های مورد استفاده در مدل های BIM می توانند تغییرات زیادی داشته باشند و بررسی کامل آنها و سازگاری و صحت آنها هنوز یک کار حل نشده است. علاوه بر این، IFC به تعدادی از انواع هندسه اجازه می دهد که می توانند برای مدل سازان مفید باشند، اما گاهی اوقات پشتیبانی نمی شوند و می توانند به روش های مختلف توسط نرم افزار تفسیر شوند. از سوی دیگر، IFC محدودیت‌های اعتباری را بر هندسه‌های خاصی اعمال می‌کند. برخی از نرم‌افزارها راه‌حل‌هایی را برای خواندن هندسه‌های نامعتبر، که اغلب غیرمستند هستند، پیاده‌سازی کرده‌اند. در نتیجه، اغلب امکان کمی برای پیگیری این راه حل ها وجود دارد. به این دلایل، مجموعه خاصی از هندسه ها ( جدول ۴ ، شکل ۱ ) در میان مجموعه داده های معیار به منظور آزمایش موارد خاص ارائه شد.

۳٫۳٫ الگوهای پاسخ برای شرکت کنندگان

شرکت‌کنندگان به دو طریق به وظایف ارزیابی‌شده در این مقاله کمک کردند، یعنی کار ۲ و ۴٫ ابتدا یک فرم آنلاین طراحی شده به عنوان الگوی پاسخ را پر کردند و در آنجا اقدامات انجام شده در ابزار و تنظیمات و پارامترهای مورد نیاز را شرح دادند ( بخش ۳٫۳٫۱ و بخش ۳٫۳٫۲ ). هدف از این کار در درجه اول تهیه راهنمایی برای افرادی بود که قصد استفاده از ابزار مشابه را برای محدوده مورد نظر دارند (یعنی ارجاع جغرافیایی یا تبدیل داده). علاوه بر این، شرکت‌کنندگان می‌توانند نظرات و مشاهداتی را برای بحث در مورد نتایج خود، به‌طور خاص و احتمالاً موضوعات مرتبط با موضوع کلی‌تر هر کار اضافه کنند.

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

۳٫۳٫۱٫ الگوی پاسخ برای وظیفه ۲: ارجاع جغرافیایی

در کار ۲، فرم پرس و جو به دو بخش تقسیم شد – جزئیات بیشتر در https://3d.bk.tudelft.nl/projects/geobim-benchmark/task2.html یافت می شود.. در بخش اول، از شرکت‌کنندگان خواسته شد تا زمان‌های پردازش و روان بودن تعاملات کاربر را اندازه‌گیری کنند، به‌عنوان مثال، مشاهده کنش‌ها (پان‌کردن و بزرگ‌نمایی) و همچنین تحلیل‌ها/پرسش‌های ساده برای بررسی اینکه آیا این زمان بستگی به ارجاع داده‌های BIM دارد یا خیر. یا نه. دلیل این امر این بود که کار با یک سیستم مختصات محلی مزیتی دارد زیرا مقادیر مختصات کوچکتر خواهند بود، که بسته به نحوه پیاده سازی ممکن است بر نرمی نرم افزار تأثیر بگذارد. به عنوان مثال، استفاده از مختصات بزرگ با محاسبات ممیز شناور می‌تواند به دلیل از دست دادن دقت در تبدیل‌ها، باعث مشکلات سوسو زدن شود.

بخش دوم فرم پرس و جو به شرح عملکرد ارجاع جغرافیایی مربوط می شود، مانند اینکه آیا ارجاع جغرافیایی یک عملکرد داخلی است یا به یک افزونه نیاز است. سؤالات دیگر مربوط به نحوه رسیدگی به CRS بود. آیا برنامه می تواند تمام CRS ها را مدیریت کند؟ آیا CRS در سطح پروژه یا شیء است؟ لازم به ذکر است که وظیفه ۲ شامل سؤالاتی در مورد اینکه آیا و چگونه می توان اطلاعات ارجاع جغرافیایی را از فایل های IFC/CityGML وارد یا صادر کرد، نیست، زیرا این مسائل توسط وظیفه ۱ مورد بررسی قرار گرفته است.

۳٫۳٫۲٫ الگوی پاسخ برای وظیفه ۴: تبدیل

قالب Task 4 ساده بود، زیرا می‌توان از ابزارهای بسیار متنوع با رویه‌های کاملاً متفاوت استفاده کرد. لازم بود توضیحی در مورد ابزار مورد استفاده ارائه شود، جزئیاتی در مورد تنظیمات و احتمالاً اقدامات احتیاطی لازم برای به دست آوردن نتایج خوب، به همراه یک ارزیابی تقریبی از زمان‌های پردازش مورد نیاز، اضافه شود. اگر از یک نرم‌افزار سفارشی استفاده می‌شد، به جای یک ابزار آماده، باید اسناد و ارجاعات مربوط به آن اضافه می‌شد. علاوه بر این، این فرم دارای مکانی برای گفتگوی آزاد بود، هم به عنوان فضایی برای نظرات رایگان و هم با پرسیدن صریح در مورد اینکه آیا هرگونه تغییر در فایل های اصلی می تواند تبدیل را آسان تر کند. این بخش از فرم – جزئیات در https://3d.bk.tudelft.nl/projects/geobim-benchmark/task4.html یافت می شود- به ویژه به عنوان سند و مرجع برای کسانی که قصد استفاده از ابزارهای مشابه را دارند، ارزش دارد.

از آنجایی که ابزارها می توانند به طور قابل توجهی از یکی به دیگری تغییر کنند، فقط می توان نتیجه گیری مستقیم کمی از این موضوع گرفت. با این حال، نتایج جالب‌تری را می‌توان با تجزیه و تحلیل مدل‌های تبدیل‌شده ارائه‌شده ( بخش ۳٫۴٫۲ ) مشخص کرد، که مستقیماً قابل مقایسه هستند، حتی با توجه به اینکه هیچ راه‌حل مرجعی برای تبدیل «کامل» وجود ندارد.

۳٫۴٫ روش های ارزیابی برای مدل های ارائه شده

۳٫۴٫۱٫ ارجاع جغرافیایی IFC (تکلیف ۲)

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

در بخش دوم ارزیابی، ارجاع جغرافیایی حاصل از مدل‌های ارائه شده توسط شرکت‌کنندگان بررسی شد و به سطح صحیح ارجاع جغرافیایی (LoGeoRef) ارجاع شد، به بخش ۲٫۲٫۳ مراجعه کنید .

ما سازگاری بین اطلاعات ارجاع جغرافیایی که احتمالاً چندین بار ذخیره شده است را بررسی نکردیم، مانند هر دو ویژگی IfcSite مطابق با LoGeoRef 20 و همچنین همانطور که توسط LoGeoRef 30 پیش بینی شده است . ما فرض می‌کنیم که جایگزین‌های مختلف می‌توانند به‌طور معتبر همزیستی داشته باشند و با توجه به درجه دقت مورد نیاز مورد استفاده (به عنوان مثال، تقریب برای تجزیه و تحلیل انرژی یا ادغام GeoBIM برای برنامه‌ریزی و پشتیبانی طراحی شهر) توسط نرم‌افزارهای مختلف استفاده شوند.

از این بخش از نتایج می توان دید که چگونه امکانات مجاز توسط استاندارد IFC در حال حاضر در ابزارها پیاده سازی شده است.

۳٫۴٫۲٫ تبدیل IFC به CityGML و CityGML به IFC (وظیفه ۴)

مرتبط ترین بخش در مواد ارائه شده توسط شرکت کنندگان برای کار ۴، مدل های تبدیل شده است.

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

در مورد داده‌های CityGML به‌دست‌آمده، مدل‌های ارائه‌شده با استفاده از ابزارهای geovalidation موجود در http://geovalidation.bk.tudelft.nl : val3dity (که آزمایش‌هایی را برای هندسه اعمال می‌کند) و بررسی‌کننده طرحواره CityGML تأیید شدند. علاوه بر این، تجسم آنها در دو بیننده سه بعدی بررسی شد: azul ( https://github.com/tudelft3d/azul ) [ ۳۷ ] و نمایشگر FZK ( https://www.iai.kit.edu/english/1648.php ). محصولات تبدیل با استفاده از ابزار IFC2CityGML ، که داده‌های CityGML نسخه ۳ را تولید می‌کنند، قابل بررسی نیستند، زیرا توسط نرم‌افزار مورد استفاده پشتیبانی نمی‌شوند. فقط اعتبار هندسه را می توان تأیید کرد.

برای اعتبارسنجی سیستماتیک طرحواره و هندسه IFC، هیچ ابزار جامع شناخته شده ای در دسترس نیست. بنابراین، ما همچنین مجبور بودیم به بازرسی دستی مدل‌های تولید شده در چندین نمایشگر سه‌بعدی تکیه کنیم تا سوگیری ناشی از عدم دقت احتمالی در تفسیر مدل توسط خود نرم‌افزار را کاهش دهیم. نمایشگر مدل Solibri ( https://www.solibri.com )، RDF IFCViewer ( http://rdf.bg/product-list/ifc-engine/ifc-viewer/ )، نمایشگر FZK ( https://www.iai ) .kit.edu/english/1648.php )، BIMVision ( https://bimvision.eu/en/download/ ).

۴٫ نتایج ارجاع جغرافیایی (تکلیف ۲)

۴٫۱٫ نرم افزار تست شده برای Georeference مدل های IFC

جدول ۵ شش بسته نرم افزاری مورد استفاده در آزمون را فهرست می کند.

IfcGeoRefChecker ( https://github.com/dd-bim/IfcGeoRef/ ) یک ابزار اختصاصی است که توسط دانشگاه علوم کاربردی درسدن برای ارجاع جغرافیایی فایل های IFC توسعه یافته است. دو تست با استفاده از Autodesk Revit (نسخه‌های ۲۰۱۹ و ۲۰۲۰) و دو تست با استفاده از FME Desktop انجام شد : یکی از تست‌های FME توسط متخصص در Safe Software (از اینجا در “FME_Desktop”) و یک تست بر اساس اسکریپت FME انجام شد. توسعه یافته برای ارجاع جغرافیایی فایل های IFC (از اینجا در “FME_script”).

۴٫۲٫ ابزارهایی برای ارجاع جغرافیایی IFC: یادداشت هایی از گزارش های شرکت کنندگان

سوالات در بخش اول عملکرد زمانی را برای تجسم و پرس و جوها/تحلیل ها در نظر می گرفتند، و به خصوص اگر تفاوت های عملکردی بین یک مدل غیرزمین مرجع و یک مدل جغرافیایی مرجع وجود داشت. نتایج (فرم‌های تحویل‌شده کامل را در https://www.dropbox.com/sh/3ezbcjm8zlysz95/AADqkTeRQGy8tPawBrgcNaLpa بیابید ) نشان می‌دهد که برای همه نرم‌افزارها، عملکرد بستگی به این ندارد که آیا مدل BIM دارای ارجاع جغرافیایی بوده یا خیر، زیرا ابزارها احتمالاً اطلاعات مربوط به ارجاع جغرافیایی را به عنوان یک مقدار ذخیره می کند، اما کار در همان سیستم محلی را دنبال کنید، بدون اینکه کل سیستم را به نقطه ارجاع جغرافیایی ترجمه کرده و بچرخانید، و حتی کمتر مدل را در یک سیستم نقشه برداری نشان دهید.

همه نرم افزارها از ابزارهای ارجاع جغرافیایی بدون استفاده از هیچ پلاگین یا مشابهی استفاده می کردند.

در برخی موارد امکان تنظیم CRS مورد نیاز و حتی سیستم مرجع ارتفاع وجود دارد. با این حال، فایل IFC مقصد، به ویژه در نسخه ۲×۳، همیشه قادر به ذخیره چنین متادیتا نیست. برخی از بسته‌های پیشرفته‌تر، مانند FME ، امکان انجام تبدیل‌های پیچیده‌تر بین CRSهای مختلف را پیش‌بینی می‌کنند، طبق معمول برای ابزارهای مرتبط با اطلاعات جغرافیایی. علاوه بر این، در این مورد، موضوع ذخیره نهایی نتیجه در موجودیت ها و ویژگی های مناسب در مدل IFC است.

ارجاع جغرافیایی به روش های مختلفی کار می کرد. برای مثال، eveBIM با استفاده از IfcLocalPlacement (تنظیم پیش‌فرض) یا تنظیمات چند مقیاسی (با استفاده از ارجاع جغرافیایی IfcSite ، از جمله TrueNorth ، IfcLocalPlacement و ارتفاع IfcSite یا یک گزینه شخصی‌شده) توانسته است ارجاع جغرافیایی را از فایل‌های IFC وارد کند .

چندین برنامه امکان ارجاع جغرافیایی تعاملی را فراهم می کند. به عنوان مثال در Revit کاربر می تواند مختصات ژئودتیکی مبدا سیستم محلی دکارتی را مشخص کند. علاوه بر این، بیشتر نرم افزارها به کاربر اجازه می دهند که مدل را به عنوان بخشی از ارجاع جغرافیایی (به سمت شمال CRS) بچرخاند، به استثنای eveBIM و IfcGeorefChecker . اکثر نرم افزارها اجازه می دهند چندین CRS تعریف شوند، به عنوان مثال، با استفاده از کدهای EPSG، اگرچه فهرست CRS های پشتیبانی شده می تواند متفاوت باشد. محدودیت عمدتاً در مولفه ارتفاع است. برای مثال، هیچ پشتیبانی از سیستم مرجع ارتفاع در FZK Viewer وجود ندارد .

۴٫۳٫ مدل‌های IFC با مرجع جغرافیایی صادر شده: کدام LoGeoRef؟

مدل های صادر شده توسط چهار برنامه تحویل داده شدند (آنها را در https://www.dropbox.com/sh/rqvk7x2w0zacxsr/AADd9jqyhM1ymhHUE0UIizPxa بیابید ) ( جدول ۶ و جدول ۷ ): eveBIM ، FZK Viewer ، Revit و FME . IfcGeoRefChecker گزارش شده است که می تواند مدل جغرافیایی مرجع را نیز صادر کند، اما به دلایلی مدل ارائه نشد. همچنین می‌تواند تنها ابزاری باشد که LoGeoRef را که توسط کلمن و هندریک [ ۲۷ ] تعریف شده است، در نظر می‌گیرد، زیرا نویسندگان یکسان هستند.

بالاترین LoGeoRef به دست آمده در مدل های صادر شده توسط eveBIM و FME_script ذخیره می شود . معیار LoGeoRef ۳۰ برای ذخیره مختصات پیش بینی شده در نقطه دکارتی مرتبط با IfcSite برای ۳ محور: شمال، شرق و ارتفاع دنبال می شود. با این حال، ذخیره سازی جهت صحیح در مدل های مختلف متفاوت است. به عنوان ویژگی TrueNorth موجودیت IfcGeometricRepresentationContext برای مدل Myran.ifc توسط هر دو ابزار ذخیره می شود . در مدل Savigliano.ifc ، فقط توسط FME_script ، هر دو TrueNorth ارجاع داده شده است.ویژگی و IfcDirection ذخیره شده با ارجاع به IfcSite پر شده اند، اما مقادیر متفاوتی دارند. برای مدل UpTown.ifc ، جهت به طور پیوسته با LoGeoRef 30 در IfcDirection مرتبط با IfcSite توسط FME_script ذخیره می شود .

برعکس، مدل UpTown.ifc که توسط eveBIM ارجاع داده شده است یک انتخاب غیرمعمول ارائه می دهد: نقطه ذخیره مختصات جغرافیایی مرجع به IfcSite مرتبط است . با این حال، چنین نقطه ای اضافی نیست، اما IfcCartesianPoint معمولاً به عنوان شی شماره ۶ در فایل IFC STEP ذخیره می شود که نشان دهنده مبدا مدل است. و جهت به درستی ذخیره نمی شود (مقدار دارد (۰،۱)) کیفیت ارجاع جغرافیایی را کمی پایین تر می کند.

مدل‌های ارجاع‌شده توسط FZK Viewer با LoGeoRef 30 در رتبه دوم قرار می‌گیرند ، اما بدون ذخیره جهت درست: جهت‌های فعلی دارای مقادیر کلی هستند. (۰،۰،۱)یا (۱،۰،۰). علاوه بر این، مختصات پیش بینی شده نه تنها به نهاد IfcSite ، بلکه به بسیاری دیگر (مثلا IfcBuildingStoreys و سایر اشیاء) مرتبط است. به همین دلیل است که اندازه فایل ها بسیار افزایش می یابد: تقریباً سه برابر در موارد Myran.ifc و Savigliano.ifc و بیش از پنج برابر برای مدل Uptown.ifc .

با Revit ، اطلاعات مربوط به ارجاع جغرافیایی فقط برای مدل UpTown.ifc به درستی ذخیره شد . به طور خاص، شمال و شرق در IfcCartesianPoint مرتبط با IfcSite اضافه شدند (مانند LoGeoRef 30 )، در حالی که Height در ویژگی RefElevation IfcSite (مانند LoGeoRef 20 ) ذخیره شد.

با مدل های Myran.ifc و Savigliano.ifc ، ارجاع جغرافیایی از طریق Revit در عوض ناموفق بود.

FME_Desktop می‌تواند یک ارجاع جغرافیایی صحیح را مرتبط کند و آن را به‌عنوان ویژگی‌های LoGeoRef 20 : RefLatitude و RefLongitude صحیح در IfcSite در WGS84 ذخیره کند. با این حال، ویژگی RefElevation دارای مقدار ۰ است. علاوه بر این، مختصات پیش بینی شده برای ترجمه (اضافه شده به) چندین IfcCartesianPoints مرتبط با اشیاء موجود در فایل، شامل شمال شرق و ارتفاع استفاده می شود .

در نهایت، استفاده از موجودیت های معرفی شده توسط نسخه ۴ IFC برای اجازه دادن به ارجاع جغرافیایی دقیق تر، مانند IfcMapConversion و IfcProjectedCRS ، برای مدل های صادر شده به IFC4 بررسی شد ( جدول ۷ ). در مدل‌های صادر شده توسط FZK Viewer ، چنین موجوداتی در فایل وجود دارند، اما به طور مداوم برای اعمال ارجاع جغرافیایی استفاده نمی‌شوند: IfcMapConversion فقط مقادیر پیش‌فرض را میزبانی می‌کند و به یک ارجاع می‌دهد. (۰،۰،۰)در تمام موارد اشاره کنید در عوض، مقادیر IfcProjectedCRS در فایل‌های مختلف ارجاع‌شده توسط FZK Viewer متفاوت است: در Myran.ifc «SRS ناشناخته» است. در UpTowin.ifc “CRS محلی، سیستم مختصات دکارتی محلی” است. در حالی که در مدل Savigliano.ifc نام و کد EPSG CRS پیش بینی شده (‘EPSG:32632’، ‘WGS84/UTM Zone 32N’) به درستی پر شده است.

در مدل جغرافیایی مرجع IFC4 Savigliano.ifc که توسط Revit و توسط FME_script صادر شده است، موجودیت‌های اضافه شده در نسخه ۴ مدل داده IFC برای اجازه دادن به ارجاع جغرافیایی دقیق‌تر ( LoGeoRef 50 ) استفاده نمی‌شوند و در فایل صادر شده نیز وجود ندارند.

۴٫۴٫ ارجاع جغرافیایی بحث IFC

این مطالعه برخی از ابزارها (افزایش تعداد) را آزمایش کرد که امکان ارجاع جغرافیایی فایل‌های IFC را فراهم می‌کرد، که به طور فزاینده‌ای برای ادغام داده‌های IFC با مدل‌های شهر سه‌بعدی و سایر داده‌های مکانی، به‌ویژه برای برنامه‌های کاربردی آتی مرتبط با زیرساخت، ضروری است. طرح. ارتباط این آزمون همچنین در مقایسه نرم‌افزار اجرا شده در حال حاضر و سطح تحقیق در مورد ارجاع جغرافیایی در BIM است (به عنوان مثال، کلمن و هندریک [۲۷]، اوگلا و هورموز [ ۲۸ ]).

نتایج نشان می‌دهد که چگونه ذخیره‌سازی پارامترهای georeferencing می‌تواند از قوانین مختلفی پیروی کند، همانطور که توسط IFC مجاز است، گروه‌بندی شده توسط Clemen و Hendrik [ ۲۷ ] در سطوح LoGeoRefs مرجع جغرافیایی ( جدول ۲ را ببینید ). با این حال، ابزارها به طور کلی در نحوه اعمال ارجاع جغرافیایی شفاف نیستند و بنابراین کنترل کمی روی آن توسط کاربر امکان پذیر است. (LoGeoRefs) بخشی از تعاریف استاندارد نیستند که قرار است با پیاده سازی نرم افزار دنبال شوند. با این حال، آنها می توانند یک روش ثابت برای ذخیره پارامترهای ارجاع جغرافیایی در IFC را نشان دهند. چنین قوانین ذخیره سازی همیشه به طور مداوم در میان مختصات شمال شرقی، مقادیر ارتفاع و چرخش رعایت نمی شوند (پارامترهای مختلف می توانند از LoGeoRef متفاوت پیروی کنند.). علاوه بر این، در برخی موارد، همان نرم‌افزار، georeferencing را بر اساس معیارهای مختلف در فایل‌های مختلف ذخیره می‌کند.

با ابزارهای آزمایش شده، که از پیشرفته‌ترین ابزارهایی هستند که فرآیندهای مورد بررسی را پیاده‌سازی می‌کنند، رسیدن به LoGeoRef بالاتر از ۳۰ برای مقادیر North-East و Height امکان‌پذیر نیست ، اگرچه ویژگی TrueNorth در برخی موارد چرخش را ذخیره می‌کند. تعریف LoGeoRef40 _

می توان بحث کرد که LoGeoRef های مختلف ، به ویژه LoGeoRef 30 و LoGeoRef 40 ، تفاوت های کمی در دقت دارند، اما آنها عمدتا برای ذخیره سازی پیش بینی شده داده ها تغییر می کنند. اولویت برای یکی از دو سیستم باید توسط ابزارها و برنامه های کاربردی با استفاده از مدل ها برای پردازش خاص تعیین شود. اهمیت ثبات اطلاعات ذخیره شده بر اساس چنین الزاماتی باید بیشتر مورد مطالعه قرار گیرد و اکنون نمی توان در مورد آن قضاوت کرد.

دو گزینه دیگر، که در بین نتایج رخ داده اند، می توانند با رویکردی مشابه از موارد استفاده و نرم افزار پردازش در نظر گرفته شوند.

گزینه اول تداعی مختصات به بسیاری از نقاط داخل فایل و نه تنها به موجودیت های در نظر گرفته شده توسط کلمن و هندریک [ ۲۷ ]، یا افزودن آنها به نمونه های محلی مدل است. امکانات ایجاد شده توسط این و اینکه چقدر می تواند مناسب باشد با توجه به پیامدهای محاسباتی نیاز به مطالعه دارد.

به طور مشابه، ارتباط مختصات پیش بینی شده با شی شماره ۶ فایل های IFC STEP یک گزینه رسمی نیست، اما بحث در مورد مزایا/معایب چنین انتخابی می تواند برای پیاده سازی های آینده مفید باشد.

علاوه بر این، مشاهده می‌کنیم که ابزارهای کمی (یا هیچکدام) گزینه سخت‌تر استفاده از ترکیبی از IfcMapConversion و IfcProjectedCRS را که توسط نسخه ۴ IFC مجاز شده است، اجرا می‌کنند. البته یک دلیل این است که این امکان در IFC 2×3 که هنوز بسیار مورد استفاده قرار می‌گیرد گنجانده نشده است. در عمل

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

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

۵٫ نتایج تبدیل (وظیفه ۴)

به طور کلی ابزارهای کمی برای تبدیل وجود دارد، و بسیاری از ابزارهای شرح داده شده در ادبیات (به بخش ۲٫۳ مراجعه کنید ) اغلب به صورت عمومی در دسترس نیستند. اگر آنها به عنوان مثال منبع باز منتشر شوند، معمولاً به گونه ای مستند نمی شوند که به راحتی توسط دیگران قابل استفاده باشند. بنابراین، ابزارهای کمی در این کار تبدیل استفاده شد.

نتایج تبدیل‌ها (مجموعه کامل پاسخ‌های شرکت‌کنندگان را در https://www.dropbox.com/sh/62yzpa5f3t3ty3f/AAASXHySqbtVFH-dOsY2i0cya?dl=0 و همه مدل‌های تبدیل شده توسط ابزارها را در https://www بیابید. dropbox.com/sh/p0f7ds1dnbu0qsh/AACF06kT5yI2qEpuOSs52X2Ta?dl=0 ) از IFC به CityGML و از CityGML به IFC به ترتیب در بخش ۵٫۱ و بخش ۵٫۲ زیر تجزیه و تحلیل شده است .

۵٫۱٫ تبدیل IFC به CityGML

برای تبدیل IFC به CityGML، عمدتاً سه نرم افزار ( جدول ۸ ) با تنظیمات مختلف مورد آزمایش قرار گرفتند .

اکثر تست‌ها از الگوریتم‌های Safe Software FME ، به‌طور مستقیم یا به‌عنوان پلاگین در نرم‌افزارهای شخص ثالث، مانند ESRI ArcGIS ، با اسکریپت‌ها و پیکربندی‌های مختلف برای تبدیل استفاده می‌کردند (برخی نمونه‌هایی از نحوه استفاده از FME برای انجام چنین تبدیلی را می‌توانید در https پیدا کنید. ://knowledge.safe.com/articles/591/bim-tutorial.html ). جدول ۹جزئیات چنین تنظیماتی را همراه با سطح تخصص شرکت‌کننده‌ای که از آن استفاده می‌کند (از L1—«مبتدی» تا L4—«توسعه‌دهنده») را نشان می‌دهد (L1—کاربر مبتدی (تقریباً اولین باری که از نرم‌افزار استفاده می‌کند)؛ L2—معمولی کاربر؛ L3 – کاربر خبره (جزئیات فنی و ترفندهای کمتر مستند را به خوبی می داند؛ L4 – توسعه دهنده نرم افزار آزمایش شده). ستون “Test ID” کدی را تعریف می کند که در بخش های زیر برای گزارش نتایج مرتبط استفاده می شود. در قسمت سمت راست جدول، مجموعه داده های تبدیل شده گزارش شده است.

اگرچه مترجم FME Quick توسط فروشندگان Safe Software به عنوان یک گزینه قابل اعتماد برای انجام تبدیل ها و تبدیل های پیچیده توصیه نمی شود ، اما در چندین آزمایش، عمدتاً توسط شرکت کنندگان غیر متخصص، استفاده شد. به همین دلیل، نتایج حاصله نیز در این بخش گنجانده شده است. برخی از آزمایش‌ها با مترجم سریع FME ، در واقع، گزارش کردند که همه ویژگی‌هایی که خوانده شدند تغییر شکل ندادند (به عنوان مثال، ۳۱۴۷ IfcTypeObjects از ۴۹۸۲۶ ویژگی خوانده شده برای UpTown.ifcمجموعه داده). توضیحی در این مورد توسط شرکت کنندگان ارائه شد، به عنوان مثال، جامدات ممکن است بیش از حد پیچیده، بسته نباشند یا غیر قابل جهت گیری باشند. برخی از هندسه‌های جامد ممکن است دارای ویژگی‌ها، ظاهر، اندازه‌گیری یا ویژگی‌هایی نباشند. با این حال، باید با چنین ابزاری انتظار داشت که عمدتاً برای تبدیل فرمت های ساده (مانند GIS به GIS) بدون نیاز به تبدیل های پیچیده یا نقشه برداری طرحواره ها در نظر گرفته شده است.

ESRI ArcGIS Pro با افزونه قابلیت همکاری داده‌های خود آزمایش شد که یک الگوریتم مبتنی بر FME را با همان خواننده‌های فوق پیاده‌سازی می‌کند.

در نهایت، ابزار IFC2CityGML [ ۹ ] برای داده های IFC4 آزمایش شد (تبدیل داده ها به CityGML نسخه ۳).

۵٫۱٫۱٫ تبدیل هندسه های خاص IFC به CityGML

با بررسی مجموعه داده هندسی خاص IFC تبدیل شده، با استفاده از نمایشگرهای سه بعدی، دو نتیجه اصلی به دست آمد:

مورد الف: همه چیز GenericCityObject با Lod4Geometry است ( شکل ۲ را ببینید ).
مورد B: همه چیز با هندسه lod4Solid ساخته می شود ، به جز هندسه زرد (مرتبط با هندسه A5، به بخش ۳٫۲٫۱ مراجعه کنید ) که یک هندسه چند سطحی lod4 است ( شکل ۳ را ببینید ).

همه اشیاء در مجموعه داده های IFCgeometries تبدیل نشدند ( شکل ۲ و شکل ۳ را ببینید ). هندسه هایی که تبدیل نشده اند، آنهایی هستند که توسط اکستروژن ریل های جرثقیل (اشکال A)، چرخش ها و دیسک های جارو شده ایجاد می شوند. هندسه A5، که در حالت B به عنوان lod4multisurface تبدیل می‌شود، تنها هندسه‌ای است که به‌عنوان یک پوسته مدل‌سازی شده است (یعنی مدل سطح مبتنی بر پوسته، مجموعه‌ای صریح از چهره‌ها). عناصر دیگر اکستروژن، چرخش یا نتایج عملیات بولی بین جامدات هستند. یک نمایش مرزی در مجموعه داده IFC (B1) است، اما به عنوان یک پوسته ذخیره نمی شود، بلکه به عنوان یک نمایش مرز وجهی ذخیره می شود.

بنا به دلایلی، به نظر می رسد مجموعه داده هایی که در آن اشیاء به عنوان bldg:buildings با هندسه lod4solid تفسیر شده اند ( شکل ۳ ) با توجه به تبدیل جایگزین (به عنوان شی شهر عمومی) و همچنین فایل اصلی منعکس شده است.

فقط این مجموعه داده را می توان در ابزارهای اعتبارسنجی جغرافیایی تجزیه و تحلیل کرد، زیرا بقیه بسیار سنگین بودند و از هر دو نسخه IFC 2×3 و IFC 4 به CityGML نسخه ۲ تبدیل شدند. در جدول ۱۰ و جدول ۱۱ مرتبط ترین نتایج اعتبار سنجی و بازرسی خلاصه شده است. می توان متوجه شد که تعداد کمی از اشیاء تبدیل شده به یک هندسه معتبر منجر می شوند. علاوه بر این، نتایج ابزار IFC2CityGML ، تولید فایل CityGML v.3 توسط val3dity قابل آزمایش نبود، زیرا CityGML نسخه ۳ پشتیبانی نمی‌شود. در عوض طرح معنایی به طور کلی به یک خروجی معتبر تبدیل می شود (اگرچه برای آن مجموعه داده ها، از جمله چند موجودیت ساده، بسیار ساده بود).

۵٫۱٫۲٫ تبدیل UpTown.ifc به CityGML

مدل‌های UpTown.ifc تبدیل‌شده (از ۱ گیگابایت تا ۱٫۴۸ گیگابایت) برای تأیید اعتبار با ابزارهای قبلی بسیار سنگین بودند. بنابراین آنها فقط در نمایشگر سه بعدی azul بازرسی شدند. در همه موارد، همه چیز با lod4geometry به GenericCityObject تبدیل می شود . اطلاعات مربوط به موجودیت های IFC فقط در ویژگی ها ذخیره می شود (به عنوان مثال، جدول ۱۲ ). تلاش برای تجسم آن در FZK Viewer ناموفق بود و فقط یک خط قابل مشاهده بود.

۵٫۱٫۳٫ تبدیل Savigliano.ifc به CityGML

مدل Savigliano.ifc ، در IFC 4، با موفقیت توسط IFC2CityGML [ ۹ ] و مترجم سریع FME ( FME19qt-L1 ) نیز تبدیل شد. علاوه بر این، ابعاد مدل ها (به ترتیب ۲۵٫۵ مگابایت و ۱۳٫۲۷ مگابایت) اجازه نمی دهد اعتبار آنها (هندسی و معنایی) با ابزارهای اعتبارسنجی زمین بررسی شود.

هنگامی که در آزول تجسم می شود، می توانیم ببینیم که مدل تبدیل شده توسط FME تمام قطعات خود را بدون هیچ تلاشی برای هماهنگی حفظ می کند: بدون انتخاب اشیا و یا تغییر در نمایش (یعنی، هر دیوار موازی هنوز با استفاده از ۶ سطح متصل نشان داده می شود، حتی اگر این دیگر یک جامد نیست بلکه چند سطحی است). در عوض، همه چیز به GenericCityObject با lod4Geometry به عنوان هندسه، با الگوی مشابه مورد A که در بخش ۵٫۱٫۱ توضیح داده شده است ، تبدیل می شود . قسمت بالای ساختمان از دست رفته است ( شکل ۴ ).

به طور مشابه، مدل تبدیل شده توسط IFC2CityGML نیز قسمت بالایی خود را از دست می دهد. علاوه بر این، شرکت‌کنندگانی که آزمایش را انجام می‌دهند، پس از تبدیل با مجموعه قوانین، از دست دادن برخی از عناصر را نیز گزارش می‌کنند (توجه داشته باشید که در حالی که IFC2CityGML از چندین مجموعه قوانین [ ۳۸ ] پشتیبانی می‌کند، تنها یک مجموعه قانون برای این کار در دسترس بود.) ( IfcStairFlight ، IfcSlab ، IfcRailing ، IfcDoor ، IfcWindow ، IfcBuildingelementProxy ). همانطور که آنها متوجه شده اند، به نظر می رسد اکثر عناصر گم شده اشیاء IfcClosedShell هستند که قبلاً هنگام بررسی در BIMserver دچار مشکل شده بودند.. از سوی دیگر، عناصری که با موفقیت تبدیل شده‌اند احتمالاً به جای آن از نمایش IfcExtrudedAreaSolid استفاده می‌کنند . یکی از دلایل احتمالی این واقعیت است که این تبدیل بر اساس مجموعه محدودی از مدل‌های عملی توسعه یافته است و عناصر موجود در این مدل‌ها را منعکس می‌کند.

در این مورد، نگاشت معنایی از رویکردی پیروی می‌کند که معنایی بیشتری را حفظ می‌کند: عناصر تبدیل‌شده، buildingConstructiveElements هستند که در bldg:Storeys و در یک bldg:Building به نوبه خود، طبق مدل داده CityGML نسخه ۳ سازمان‌دهی شده‌اند. مدل داده ارائه شده توسط CityGML v.3 اعتبار چنین مدلی را امکان پذیر می کند، اگرچه می توان بحث کرد که پارادایم فضایی- معنایی [ ۳۳ ] در یک تلاش هماهنگ با یک نمایش سازگار با GIS تغییر نمی کند.

۵٫۱٫۴٫ تبدیل Myran به CityGML

همه مدل‌های Myran تبدیل‌شده عموماً بزرگ‌تر از آن بودند که در ابزارهای geovalidation ( http://geovalidation.bk.tudelft.nl ) باز شوند یا به‌درستی کار نمی‌کردند. اما در مواردی که طرح واره معنایی قابل بررسی بود، معتبر بود.

هنگامی که توسط ابزارهای مبتنی بر مترجم FME Quick صادر می شود، مدل Myran.ifc رفتاری مشابه با Savigliano.ifc و UpTown.ifc دارد و اکثر عناصر را بدون هیچ گونه انتخابی (مثلاً داخل-خارج) و هر نوع تغییری در آن حفظ می کند. نمایندگی آنها همه اشیا با یک lod4Geometry عمومی به GenericCityObject تبدیل می شوند . اگرچه نمی توان فهمید که چه نوع هندسه ای استفاده می شود، اما ظاهراً جامدات به صورت تبدیل نمی شوند. با این حال، همانطور که قبلاً بحث شد، مترجم Quick مناسب ترین FME نیستابزاری برای انجام چنین تبدیل پیچیده ای که توسط خود فروشندگان نرم افزار توصیه می شود.

با مدل Myran.ifc ، تلاش بیشتری توسط دو نفر از شرکت‌کنندگان به منظور محدود کردن تبدیل به قالب ذخیره‌سازی، بلکه برای ترسیم معنایی درست بین دو مدل داده و تغییر نوع هندسه مورد استفاده، توسعه یافت. به طور خاص، این در آزمایشات انجام شد: FME19-L3. FME17-RVTr-L1; FME17-IFCr-L1; AGIS-FME-L1; AGIS-FME-IFCr-L1؛ AGIS-FME-RVTr-L1.

در آزمون FME19-L3 یک مدل CityGML LoD4 ( شکل ۵ ) با استفاده از یک فضای کاری بسیار پیچیده به دست آمد.

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

در بین آخرین مدل ها، مدل هایی که می توانستند در بینندگان باز شوند کاملاً مشابه بودند. درب ها به درستی به bldg:درب ها ، پنجره ها به درستی به bldg:windows تبدیل شده اند . سقف سقف است سطح و سطح کف به bldg:floorSurface تبدیل شده است . اما برخی از عناصر (دیوار، پله، نرده و دال، ستون ها و سنگفرش بالکن و تابلوها) (به اشتباه) به تاسیسات ساختمان تبدیل شده اند .

همه هندسه‌های تبدیل شده به lod3MultiSurface تبدیل می‌شوند که با توجه به ویژگی‌های روش فعلی برای داده‌های CityGML، تبدیل صحیحی است. با این حال، عمدتاً سطوح مثلثی ایجاد می‌شوند و هندسه به طور کامل کنترل نمی‌شود، در برخی موارد: هر جامد به چند سطح تبدیل می‌شود که ظاهراً همان شکل را نشان می‌دهند (این تغییر در نمایش دال‌های سقف تقریباً موفقیت‌آمیز است، اگرچه این امکان وجود دارد که هندسه کاملاً بسته نشده باشد)، اما در بیشتر موارد آنها در دسته‌ای از مثلث‌ها احتمالاً تکراری نیز تبدیل می‌شوند ( شکل ۶ ، شکل ۷ ، شکل ۸ و شکل ۹ را ببینید ).

با وجود ایرادات باقیمانده، این آخرین آزمایش‌ها نزدیک‌ترین به دستیابی به یک نتیجه تبدیل مناسب هستند. آنها از یک گردش کار تبدیل پیچیده متشکل از چندین مرحله (فیلتر کردن، انتخاب، نقشه برداری، تبدیل) استفاده کردند – جزئیات را ببینید و فضاهای کاری ساخته شده را در میان پاسخ های ارائه شده توسط شرکت کنندگان در https://www.dropbox.com/s/5oof86wys9db6e7/Task4_DeliveredResults_human دانلود کنید . .docx .

IFC2CityGML همچنین به یک نتیجه خوب دست می یابد که با نوع نمایش مجاز نسخه ۳ CityGML مطابقت دارد، علیرغم اتخاذ یک الگوی نمایش متفاوت از نمونه ای که معمولاً در مدل های شهر سه بعدی اتخاذ می شود.

۵٫۲٫ تبدیل CityGML به IFC

در جدول ۱۳ ، نرم افزار آزمایش شده برای تبدیل CityGML به IFC در کار ۴ معیار خلاصه شده است. CityGML2IFC و FZK Viewers با هر سه فایل موجود آزمایش شدند، در حالی که FME فقط با BuildingsLoD3.gml با گزینه Quick Translator و با RotterdamLoD12.gml با استفاده از یک فضای کاری پیچیده تر آزمایش شد.

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

۵٫۲٫۱٫ BuildingsLoD3.gml تبدیل به IFC

در تبدیل فایل BuildingsLoD3.gml از CityGML به IFC ( جدول ۱۴ )، می‌توانیم متوجه شویم که تبدیل معناشناسی از قوانین ساده پیروی می‌کند، زیرا منطقی است. هندسه نیز به مشابه ترین نوع هندسه در فرمت تبدیل شده، بدون پردازش بیشتر، تبدیل می شود. بنابراین سطوح به صورت سطوح و جامدات جامد باقی می مانند.

علاوه بر این، سقف یک قسمت بیرون زده کوچک در ورودی یک ساختمان به صورت bldg:outerFloorSurface در مدل CityGML نشان داده شده و به IfcBuildingElementProxy تبدیل شده است .

دودکش ها با استفاده از bldg:BuildingInstallation نشان داده می شوند که به نوبه خود ترکیبی از bldg:Wall و bldg:ClosureSurface است . آنها به طور کامل در برخی از مدل های تبدیل شده توسط FZKViewer و مدلی که از FME Quick Translator استفاده می کند ، وجود ندارد .

نقشه برداری برای همه نرم افزارها یکسان بود، به جز تغییرات جزئی ذکر شده، و صادرات به IFC v.4 و v.2×3 نتایج یکسانی را نشان می دهد.

مورد CityGML2IFC کمی متفاوت است، زیرا این ابزار برای مدیریت داده های LoD2 CityGML توسعه یافته است. بنابراین، در این حالت درها و پنجره‌ها معنای خود و هویت خود را به عنوان یک شی از دست می‌دهند و در دیوارهای مربوطه قرار می‌گیرند ( شکل ۱۰ ). تنها موجودیت‌هایی که در اینجا باقی می‌مانند IfcWalls هستند ، از تبدیل bldg:Walls و همچنین bldg:Doors ، bldg:Windows و bldg:Installations . IfcRoof ، که از تبدیل bldg:RoofSurface ، و IfcSlab [BaseSlab، GroundSlab] از تبدیل bldg :GroundSurface به دست می‌آید.. عنصر Bldg :OuterFloorSurface از بین رفته است.

۵٫۲٫۲٫ تبدیل RotterdamLoD12 به IFC

مدل RotterdamLoD12.gml توسط FZK Viewer ، FME ، با استفاده از یک فضای کاری پیچیده و ابزار CityGML2IFC تبدیل شد .

مدل های روتردام تبدیل شده توسط FZK Viewer فقط می تواند توسط خود FZK Viewer باز شود (که خطاهای نحوی می دهد). در عوض باعث خرابی سایر نرم افزارها قبل از باز شدن می شود (به عنوان مثال، BIMVision و RDF IfcViewer ).

پس از تبدیل، بسیاری از سطوح (هم bldg:wall ، برخی bldg:groundSurfaces و برخی از قطعات bldg:Roof ) اکنون IfcBuildingElementProxy هستند . برخی از آنها می تواند نمایش LoD1 مجموعه داده باشد که همراه با LoD2 در مجموعه داده گنجانده شده است. جداسازی هندسه با داشتن مناسب ترین LoD پیچیدگی بیشتری را برای این نوع مجموعه داده های چند LoD می دهد. احتمالاً LoD2 مناسب ترین است، زیرا به جزئیات BIM نزدیک تر است، اگرچه باید در نهایت بر اساس موارد استفاده تصمیم گیری شود.

در آزمون CityGML2IFC ، قبلاً در نتایج ارائه شده گزارش شده بود که نرم افزار به طور کامل بخش LoD1 فایل را نادیده گرفته است. این با موفقیت بخش‌هایی از داده‌های LoD2 را تبدیل می‌کند، که از زمان توسعه برای تبدیل از داده‌های LoD2 CityGML منطقی است. با این حال، مشکل دیگری وجود داشت که احتمالاً مربوط به تبدیل بخش‌هایی از داده‌ها است که در آن LoD1 و LoD2 همپوشانی دارند. بنابراین ممکن است برخی از بخش‌ها از دست رفته باشند، اما اشیاء باقی‌مانده سازگار هستند: bldg:wallSurface به IfcWall ; bldg:GroundSurface به IfcSlab و bldg:RoofSurface به IfcRoof .

در آزمون فضای کاری FME ، پردازشی از هندسه به منظور اکسترود کردن وجه ها و تبدیل آنها به جامد، همانطور که در توضیحات ارائه شده توضیح داده شد، اعمال شد. این گامی رو به جلو برای ایجاد یک الگوی بازنمایی سازگار با BIM است. با این حال، همانطور که با RDF IfcViewer ( http://rdf.bg/product-list/ifc-engine/ifc-viewer/ ) بررسی شده است، چنین ضخامتی همیشه در مدل قابل مشاهده نیست . نگاشت معنایی موجودیت‌ها در این مورد کاملاً سازگار است، که منجر به ایجاد IfcWalls ، IfcSlabs ، IfcRoof و IfcSite در ناحیه اطراف ساختمان‌ها می‌شود. برخی از نادرستی های باقی مانده وجود دارد، به عنوان مثال برخی از IfcSlabsبرای نشان دادن دیوارها استفاده می شود ( شکل ۱۱ a). علاوه بر این، نمایش IfcSpaces متناقض است: آنها فقط در بخشی از ساختمان ها ایجاد می شوند و در برخی موارد حجم ها دقیقاً در دیوارها قرار نمی گیرند اما در عوض کمی متفاوت هستند و در برخی موارد آنها را متقاطع یا همپوشانی می کنند (شکل ۱۱ ب ) . ).

هندسه در تمام موارد از GML MultiSurface به IFC SurfaceModel تبدیل می شود . با این حال، اگرچه مجموعه داده های تبدیل شده RotterdamLoD12.gml را می توان در برخی از نمایشگرهای سه بعدی باز کرد (با هشدارها و خطاهای گزارش شده گاهی اوقات)، آنها را نمی توان به عنوان مثال در Autodesk Revit که یکی از پرکاربردترین نرم افزارها است باز کرد. نتیجه تبدیل انجام شده توسط FME 2019 را می توان در Revit باز کرد ، اگرچه فقط IfcSite نشان داده می شود، بدون IfcBuildings . البته اگر قرار باشد از چنین مجموعه داده هایی به عنوان مرجع در نرم افزار برای طراحی استفاده شود، مسئله بزرگی است.

۵٫۲٫۳٫ تبدیل آمستردام به IFC

تبدیل مدل amsterdam.gml با FZK Viewer به هر دو IFC v.2×3 و v.4 و FME Quick مترجم آزمایش شد .

همه مدل های تبدیل شده دارای ویژگی های کاملا یکسان هستند. آن‌ها ساختمان‌های صادر شده را به‌عنوان IfcBuildings و بقیه موجودیت‌ها را به‌عنوان IfcBuildingElementProxy، به‌عنوان منصفانه برای IFC v.2×3 معرفی می‌کنند، زیرا سایر موجودیت‌ها به‌صراحت مرتبط با زیرساخت‌ها هنوز در مدل نیستند. معنایی اشیا در ویژگی Name هر موجودیت باقی می ماند. علاوه بر این، سایر ویژگی ها به درستی به اشیاء تبدیل و مرتبط می شوند.

با این حال، همانطور که در RDF IfcViewer ( شکل ۱۲ ) مشاهده می شود، تقریباً همه هندسه ها به شکل های ۲ بعدی مسطح شده اند .

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

۵٫۳٫ بحث تبدیل

نتایج هر دو تبدیل از IFC به CityGML و از CityGML به IFC نشان می دهد که چگونه انجام یک تبدیل کامل و ثابت از یک نوع مدل به مدل دیگر بسیار دشوار است. این امر هم نیازهای قابلیت همکاری برای تولید یک قالب خروجی معتبر و هم مسائل هماهنگی ایجاد ویژگی‌های مدل ورودی با خروجی را در نظر می‌گیرد.

یکی از نزدیک‌ترین تلاش‌ها توسط IFC2CityGML انجام شد ، که مزیت الگوی بازنمایی CityGML v.3 را دارد که امکان گنجاندن کامل تمام مفاهیم BIM در مدل را بدون نیاز به تبدیل آنها به مفاهیم جغرافیایی فراهم می‌کند.

نمونه‌های خوب دیگر، دو نمونه‌ای هستند که از FME استفاده می‌کنند ، همانطور که در بخش ۵٫۱٫۴ توضیح داده شد، با توجه به تغییر شکل هندسه جامد معمولی BIM به سطوح رو به رو و محصور در قسمت بیرونی ساختمان. یکی از آنها (FME19-L3) با توسعه یک مدل پردازش بسیار پیچیده، به تبدیل CityGML LoD4 با نتایج خوبی از نظر هندسه و معنایی دست یافت.

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

یکی از سوالات نهایی به شرکت کنندگان در مورد پیشنهادهایی برای بهبود فایل های ورودی IFC به منظور دستیابی به تبدیل بهتر بود. در میان آنها، شرکت کنندگان ذکر شده اند:

ارجاع جغرافیایی صحیح؛
خاصیتی که بیان می کند یک موجود دارای هندسه حجمی یا سطحی است.
مدلسازی داخلی و خارجی به طور جداگانه.
ملکی که مشخص می کند کدام طبقات بالای زمین هستند.
دهانه های موجود در موجودیت های دیوار و دال.
گروه بندی صحیح در طبقات (به عنوان مثال، مجموعه داده Myran.ifc دارای ویژگی های wrt اطلاعات معنایی صحیح است، اما نه برای روابط بین موجودیت ها، به عنوان مثال، سقف یک طبقه بخشی از طبقه دیگر است، یک طبقه کامل فقط برای لوله کشی و عناصر تیر تعریف شده است. نه تنها برای تجزیه و تحلیل مشکل ساز هستند، بلکه از نظر معنایی نیز نادرست هستند).
اجتناب از همپوشانی هندسه ها؛
استفاده صحیح و مداوم از IfcSpaces .

تبدیل CityGML به IFC بر روی یک تجربه محدود در رابطه با تبدیل IFC به CityGML حساب می‌کرد، زیرا بیشتر تلاش‌های اولیه صرف استفاده از اطلاعات BIM برای ادغام در مدل‌های سه بعدی شهر بود و نه برعکس. ، که همچنین به چالش های رسمی تر (نه فقط چالش های فنی) دلالت دارد.

علاوه بر این، توجه به این نکته مهم است که به طور کلی، IFC به CityGML یک تبدیل با ضرر است. طرح‌واره و مدل‌های IFC معمولاً دارای جزئیات دقیق‌تری نسبت به مدل‌های CityGML در مقیاس شهر هستند. بنابراین، انتظار نتایج بهتر از تبدیل IFC (BIM) به CityGML (مدل شهر) نسبت به برعکس (CityGML به IFC) منطقی است.

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

اکثر تبدیل‌ها از CityGML به IFC مدل‌های نمایش مرزی را تولید می‌کنند که احتمالاً در مدل IFC معتبر هستند، اگرچه پارامترهای مختلفی باید در این رابطه در نظر گرفته شوند. مثلاً برای چه مواردی استفاده خواهند شد؟ این مورد استفاده به چه نوع اطلاعاتی نیاز دارد؟ در داخل آن، نمایشی از IfcRoofs و IfcWalls بسیار عمومی مفید هستند؟ آیا نمایش ویندوز کمکی می کند یا خیر؟ چه نوع هندسه ای لازم است؟ و غیره.

تولید یک BIM با الگوی بازنمایی مناسب خود (دیوارهایی با ضخامت و شاید مواد، اسلب و غیره) به روشی پیچیده‌تر نیاز دارد که ترکیبی از فن‌آوری‌های پیچیده‌تر و مطالعات پشتیبانی از آنها را بکار می‌گیرد.

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

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

همچنین شایان ذکر است که ابزارهای منبع باز بسیار کمی وجود داشته است که تا حد زیادی نشان دهنده کمبود ابزارهای منبع باز در حال حاضر برای این کار است. در حالی که این نتایج معیار را تضعیف می کند، این بیشتر یک نقص در وضعیت هنر است تا نقص خود معیار.

این مطالعه می‌تواند اول از همه روشن کند که برخی از هندسه‌ها در تبدیل شدن با مشکلاتی مواجه می‌شوند، همانطور که از آزمایش‌های مجموعه داده IFCgeometries.ifc ( بخش ۵٫۱٫۱ ) آشکار است. علاوه بر این، نیاز به یک روش کلی را با در نظر گرفتن نه تنها موضوع قابلیت همکاری، بلکه همچنین جنبه هماهنگی مشکل را که هنوز به طور کامل حل نشده است، روشن کرد.

علاوه بر این، فایل‌های چند LoD چالش‌های بیشتری را ارائه می‌کنند، زیرا هندسه‌های LoD مختلف می‌توانند با هم همپوشانی داشته باشند، علی‌رغم اینکه بخشی از مدل‌های سازگار و معتبر هستند. بنابراین، در بیشتر موارد، یک مرحله اولیه انتخاب تنها LoD که برای تبدیل در نظر گرفته می‌شود، کمک می‌کند.

واضح است که چگونه یک ترکیب آگاهانه از فرآیندهای میانی (مانند ترانسفورماتورهای FME یا الگوریتم های خود توسعه یافته) برای رسیدن به نتایج با کیفیت بالا ضروری است.

مراحل دخیل در موفقیت آمیزترین تبدیل ها به طور کلی به این صورت خلاصه می شود: نگاشت ویژگی – نگاشت ویژگی ها – نگاشت هندسه و پردازش – نگاشت روابط و ویژگی ها.

این بدان معناست که دانش کافی از هر دو استاندارد (IFC و CityGML) و ابزار ضروری است.

۶٫ نتیجه گیری

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

نتایج کار ۲ معیار ( بخش ۴ ) نشان داد که چه ابزارهایی برای اعمال ارجاع جغرافیایی به داده های IFC در دسترس هستند. نقص عمده به دلیل عدم کنترل در نحوه ذخیره ارجاع جغرافیایی در فایل IFC است. برای تصمیم گیری در مورد توافقات در این زمینه، همکاری بین ذینفعان و محققین، توسعه دهندگان و سازمان های استانداردسازی لازم است. علاوه بر این، نتایج ارائه‌شده از موجودیت‌های موجود IFC v.4 برای صدور فایل‌های جغرافیایی مرجع IFC در نسخه ۴ استفاده نمی‌کند.

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

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

محدودیت‌های مطالعه، و همچنین قدرت آن، در مشارکت داوطلبانه شرکت‌کنندگان برای انجام آزمون‌ها نهفته است. این به طور بالقوه مشارکت را برای هر کسی که رویه ای مناسب برای یکی از وظایف را با رویکردی فراگیر توسعه می دهد، باز کرد. با این حال، آنها را ملزم به پیوستن فعالانه و سرمایه گذاری در آن می کرد که می توانست مانع مشارکت کامل شود. بر خلاف اقدامات اتخاذ شده برای کار ۱ و وظیفه ۳، که برای آنها تست ها در مورد ابزارهای هنوز کشف نشده یکپارچه شده بودند، در این موارد مسائل بسیار پیچیده بود، و با گسترده ترین ابزارهای خارج از قفسه که قبلاً در نظر گرفته شده بود، چنین نبود. آزمایش کدهای دیگری که به طور بالقوه در ادبیات موجود است ضروری است (علاوه بر اینکه احتمالاً ساده نیست).

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

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

در مورد نرم افزار، ما توسعه دهندگان ابزار را تشویق می کنیم تا روی پیاده سازی سطوح LoGeoRef در ابزارهای ارجاع جغرافیایی خود کار کنند. به طور مشابه، توسعه‌دهندگانی که روی روش‌های تبدیل کار می‌کنند باید ویژگی‌های این دو استاندارد (رسمی و نانوشته) را در نظر بگیرند. در حالی که انجام یک نقشه برداری ۱:۱ از هندسه در موقعیت های خاص مفید است، در بسیاری از موقعیت ها نیز کافی نیست، که نیاز به هندسه و پردازش معنایی دارد تا با استاندارد دیگر مطابقت داشته باشد.

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

منابع

لیو، ایکس. وانگ، ایکس. رایت، جی. چنگ، جی سی. لی، ایکس. لیو، آر. یک بررسی پیشرفته در مورد ادغام مدل سازی اطلاعات ساختمان (BIM) و سیستم اطلاعات جغرافیایی (GIS). ISPRS Int. J. Geo Inf. ۲۰۱۷ ، ۶ ، ۵۳٫ [ Google Scholar ] [ CrossRef ] [ نسخه سبز ]
فوسو، آر. سوپرابهاس، ک. راتور، ز. کوری، سی. ادغام مدل سازی اطلاعات ساختمان (BIM) و سیستم های اطلاعات جغرافیایی (GIS) – بررسی ادبیات و نیازهای آینده. در مجموعه مقالات سی و دومین کنفرانس CIB W78، آیندهوون، هلند، ۲۷-۲۹ اکتبر ۲۰۱۵٫ ص ۲۷-۲۹٫ [ Google Scholar ]
الکساندروف، م. دیاکیته، آ. یان، جی. لی، دبلیو. Zlatanova، S. معماری سیستم ها برای مدیریت داده های BIM، GIS سه بعدی و حسگرها. ISPRS Ann. فتوگرام حسگر از راه دور اسپات. Inf. علمی ۲۰۱۹ ، ۴ . [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
کومار، ک. لابتسکی، آ. آرویو اوهوری، ک. لدوکس، اچ. Stoter, J. استاندارد LandInfra و نقش آن در حل باتلاق BIM-GIS. Geospat را باز کنید. نرم افزار داده ایستادن. ۲۰۱۹ ، ۴ ، ۱-۱۶٫ [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
نیو، س. یانگ، ی. Pan, W. برنامه ریزی لجستیک و تجسم پروژه های ساختمانی یکپارچه مدولار بر اساس الگوریتم ادغام BIM-GIS و مسیریابی خودرو. در مجموعه مقالات اجلاس سران ساختمان مدولار و خارج از سایت (MOC) ; دانشگاه آلبرتا: ادمونتون، AB، کانادا، ۲۰۱۹؛ صص ۵۷۹-۵۸۶٫ [ Google Scholar ]
نواردو، اف. ایلول، سی. هری، ال. زمینی، I.; شریعت، م. آرویو اوهوری، ک. Stoter, J. فرصت ها و چالش ها برای GeoBIM در اروپا: توسعه یک مورد استفاده از مجوزهای ساختمانی برای افزایش آگاهی و بررسی چالش های قابلیت همکاری فنی. جی. اسپات. علمی ۲۰۱۹ ، ۶۵ ، ۲۰۹-۲۳۳٫ [ Google Scholar ] [ CrossRef ]
آرویو اوهوری، ک. دیاکیته، آ. کریجنن، تی. لدوکس، اچ. Stoter، J. پردازش مدل های BIM و GIS در عمل: تجربیات و توصیه های یک پروژه GeoBIM در هلند. ISPRS Int. J. Geo Inf. ۲۰۱۸ ، ۷ ، ۳۱۱٫ [ Google Scholar ] [ CrossRef ] [ نسخه سبز ]
کانگ، TW; Hong, CH مطالعه ای بر روی معماری نرم افزار برای یکپارچه سازی داده های مدیریت تسهیلات مبتنی بر BIM/GIS. خودکار ساخت و ساز ۲۰۱۵ ، ۵۴ ، ۲۵-۳۸٫ [ Google Scholar ] [ CrossRef ]
استافز، آر. تاوشر، اچ. Biljecki, F. دستیابی به تبدیل کامل و تقریباً بدون ضرر از IFC به CityGML. ISPRS Int. J. Geo Inf. ۲۰۱۸ ، ۷ ، ۳۵۵٫ [ Google Scholar ] [ CrossRef ] [ نسخه سبز ]
لیم، جی. تاوشر، اچ. Biljecki، F. قوانین تبدیل نمودار برای تبدیل ویژگی IFC به شهر GML. ISPRS Ann. فتوگرام حسگر از راه دور اسپات. Inf. علمی ۲۰۱۹ ، IV-4/W8 ، ۸۳-۹۰٫ [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
سان، ج. می، اس. اولسون، پو؛ پالسون، جی. Harrie, L. استفاده از BIM و GIS برای نمایش و تجسم کاداستر سه بعدی. ISPRS Int. J. Geo Inf. ۲۰۱۹ ، ۸ ، ۵۰۳٫ [ Google Scholar ] [ CrossRef ] [ نسخه سبز ]
ایسیکداغ، یو. زلاتانوا، اس. تجزیه و تحلیل SWOT در مورد اجرای مدل های اطلاعات ساختمان در محیط جغرافیایی. در مدیریت داده های شهری و منطقه ای ; CRC Press: Boca Raton، FL، USA، ۲۰۰۹; صص ۱۵-۳۰٫ [ Google Scholar ]
گروگر، جی. Plümer, L. CityGML—مدل های شهری سه بعدی معنایی قابل تعامل. ISPRS J. Photogramm. Remote Sens. ۲۰۱۲ ، ۷۱ ، ۱۲-۳۳٫ [ Google Scholar ]
لااکسو، ام. Kiviniemi, A. استاندارد IFC: مروری بر تاریخچه، توسعه و استانداردسازی، فناوری اطلاعات. ITcon ۲۰۱۲ ، ۱۷ ، ۱۳۴-۱۶۱٫ [ Google Scholar ]
نواردو، اف. آرویو اوهوری، ک. بیلجکی، اف. ایلول، سی. هری، ال. کریجنن، تی. Stoter, J. معیار ISPRS-EuroSDR GeoBIM 2019. در مجموعه مقالات ISPRS-بایگانی بین المللی فتوگرامتری، سنجش از دور و علوم اطلاعات فضایی — مجموعه مقالات کنگره XXIV ISPRS، والنسیا، اسپانیا، ۹–۱۲ سپتامبر ۲۰۲۰ [ Googlecholar . ]
د لعات، ر. Van Berlo, L. ادغام BIM و GIS: توسعه پسوند CityGML GeoBIM. در پیشرفت در علوم ژئو اطلاعات سه بعدی ؛ Springer: برلین/هایدلبرگ، آلمان، ۲۰۱۱; ص ۲۱۱-۲۲۵٫ [ Google Scholar ]
استوتر، جی. لدوکس، اچ. پنینگا، اف. ون دن برینک، ال. رویورز، ام. ورمیج، م. Wiersma, M. به سوی یک رویکرد استانداردسازی سه بعدی عمومی برای هلند که از برنامه ها و کدگذاری های مختلف پشتیبانی می کند. بین المللی قوس. فتوگرام حسگر از راه دور اسپات. Inf. علمی ۲۰۱۹ , ۴۲ . [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
اریکسون، اچ. یوهانسون، تی. اولسون، PO; اندرسون، ام. انگوال، جی. هاست، من. هری، ال. الزامات، توسعه و ارزیابی استاندارد ملی ساختمان – مطالعه موردی سوئدی. ISPRS Int. J. Geo Inf. ۲۰۲۰ ، ۹ ، ۷۸٫ [ Google Scholar ] [ CrossRef ] [ نسخه سبز ]
داوم، اس. بورمان، ا. Kolbe، TH یک زبان پرس و جوی فضایی- معنایی برای تجزیه و تحلیل یکپارچه مدل های شهر و مدل های اطلاعات ساختمان. در پیشرفت در ژئو اطلاعات سه بعدی ; Springer: برلین/هایدلبرگ، آلمان، ۲۰۱۷; صص ۷۹-۹۳٫ [ Google Scholar ]
OGC. استاندارد رمزگذاری ۲٫۰٫۰ زبان نشانه گذاری جغرافیای شهر OGC (CityGML). Doc. شماره ۱۲۰۱۹ ; OGC: Wayland، MA، ایالات متحده آمریکا، ۲۰۱۲٫ [ Google Scholar ]
OGC. مشخصات پیاده سازی OGC Geographic Markup Language (GML) نسخه ۳٫۱٫۱ Doc. شماره ۰۳-۱۰۵r1 ; OGC: Wayland، MA، ایالات متحده آمریکا، ۲۰۰۴٫ [ Google Scholar ]
یائو، ز. ناگل، سی. کونده، اف. هدرا، جی. ویلکوم، پی. دوناوبائر، آ. آدولفی، تی. Kolbe، TH 3DCityDB – یک راه حل پایگاه داده جغرافیایی سه بعدی برای مدیریت، تجزیه و تحلیل و تجسم مدل های شهری سه بعدی معنایی مبتنی بر CityGML. Geospat را باز کنید. نرم افزار داده ایستادن. ۲۰۱۸ ، ۳ . [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
لدوکس، اچ. آرویو اوهوری، ک. کومار، ک. دوکای، بی. لابتسکی، آ. Vitalis, S. CityJSON: یک رمزگذاری فشرده و آسان برای استفاده از مدل داده CityGML. Geospat را باز کنید. نرم افزار داده ایستادن. ۲۰۱۹ ، ۴ . [ Google Scholar ] [ CrossRef ]
کوتزنر، تی. چاتورودی، ک. Kolbe، TH CityGML 3.0: توابع جدید برنامه های جدید را باز می کند. PFG J. Photogramm. سنسور از راه دور Geoinf. علمی ۲۰۲۰ ، ۱-۱۹٫ [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
ISO کلاس های بنیاد صنعت ISO 16739 (IFC) برای به اشتراک گذاری داده ها در صنایع ساخت و ساز و مدیریت تاسیسات ؛ سازمان بین المللی استانداردسازی: ژنو، سوئیس، ۲۰۱۳٫ [ Google Scholar ]
ISO ISO 10303 سیستم‌های اتوماسیون صنعتی و یکپارچه‌سازی – ارائه و تبادل داده‌های محصول ؛ سازمان بین المللی استانداردسازی: ژنو، سوئیس، ۲۰۱۴٫ [ Google Scholar ]
کلمن، سی. هندریک، جی. سطح ارجاع جغرافیایی (LoGeoRef) با استفاده از IFC برای BIM. جی. جئود. ۲۰۱۹ ، ۱۰ ، ۱۵-۲۰٫ [ Google Scholar ]
اوگلا، جی. هورموز، م. قابلیت‌های جغرافیایی و محدودیت‌های کلاس‌های بنیاد صنعت. خودکار ساخت و ساز ۲۰۱۸ ، ۹۶ ، ۵۵۴-۵۶۶٫ [ Google Scholar ] [ CrossRef ]
دیاکیته، AA; زلاتانوا، اس. ارجاع جغرافیایی خودکار BIM در محیط های GIS با استفاده از ردپای ساختمان. محاسبه کنید. محیط زیست سیستم شهری ۲۰۲۰ , ۸۰ , ۱۰۱۴۵۳٫ [ Google Scholar ] [ CrossRef ]
دانکرز، اس. لدوکس، اچ. ژائو، جی. Stoter, J. تبدیل خودکار مجموعه داده های IFC به ساختمان های CityGML LOD3 از نظر هندسی و معنایی درست. ترانس. GIS ۲۰۱۶ , ۲۰ , ۵۴۷–۵۶۹٫ [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
اولسون، PO تبدیل یک مدل IFC به یک مدل ساختمان ۳D-GIS lod2-3. در کنفرانس چابک ; Agile: Wageningen، هلند، ۲۰۱۸; صص ۱۲-۱۵٫ [ Google Scholar ]
یو، SC; Teo، TA تعمیم مدل BIM/IFC برای مدل های GIS/CityGML سه بعدی چندمقیاس. در مجموعه مقالات سی و پنجمین کنفرانس آسیایی سنجش از دور، نای پی تاو، میانمار، ۲۷ تا ۳۱ اکتبر ۲۰۱۴; ص ۲۷-۳۱٫ [ Google Scholar ]
بیلجکی، اف. Tauscher, H. کیفیت تبدیل BIM-GIS. ISPRS Ann. فتوگرام حسگر از راه دور اسپات. Inf. علمی ۲۰۱۹ ، ۴ . [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
Salheb, N. تبدیل خودکار CityGML به IFC. پایان نامه کارشناسی ارشد، دانشگاه صنعتی دلفت، دلفت، هلند، ۲۰۱۹٫ [ Google Scholar ]
نواردو، اف. آرویو اوهوری، ک. بیلجکی، اف. ایلول، سی. هری، ال. کریجنن، تی. Stoter، J. GeoBIM Benchmark 2019: طراحی و نتایج اولیه. ISPRS Int. قوس. فتوگرام حسگر از راه دور اسپات. Inf. علمی ۲۰۱۹ ، ۴۲ ، ۱۳۳۹–۱۳۴۶٫ [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
بیلجکی، اف. لدوکس، اچ. Stoter, J. تولید مدل‌های شهر سه بعدی چند-LOD در CityGML با موتور مدل‌سازی رویه‌ای Random3Dcity. ISPRS Ann. فتوگرام حسگر از راه دور اسپات. Inf. علمی ۲۰۱۶ ، IV-4/W1 ، ۵۱-۵۹٫ [ Google Scholar ] [ CrossRef ]
Arroyo Ohori، K. azul: نمایشگر مدل سه بعدی شهر سریع و کارآمد برای macOS. ترانس. GIS ۲۰۲۰ ، ۱۴۶۷–۹۶۷۱٫ [ Google Scholar ] [ CrossRef ]
تاوشر، اچ. Stouffs, R. استخراج ساختارهای فضایی- معنایی مختلف از IFC با استفاده از گرامر نمودار سه گانه. به صورت هوشمند و آگاه: بیست و چهارمین کنفرانس سالانه انجمن تحقیقات طراحی معماری به کمک رایانه در آسیا (CAADRIA 2019) ؛ کادریا: هنگ کنگ، چین، ۲۰۱۹؛ جلد ۱، ص ۶۰۵–۶۱۴٫ [ Google Scholar ]

شکل ۱٫ طرح واره مرجع هندسه های IFC مدل شده.

شکل ۲٫ مورد الف: هندسه‌های IFC، هر دو در IFC v.2×3 و v.4 به اشیاء شهر عمومی تبدیل شده‌اند ، که در azul تجسم شده‌اند.

شکل ۳٫ مورد B: هندسه‌های IFC، هر دو در IFC v.2×3 و v.4، به bldg:buildings تبدیل شده‌اند که در azul تجسم شده‌اند. می توان متوجه شد که به دلایلی، اینها با توجه به توزیع اصلی خود معکوس شده اند.

شکل ۴٫ نمونه ای از مدل Savigliano تبدیل به CityGML. هر شی با lod4Geometry به GenericCityObject تبدیل می شود .

شکل ۵٫ نماهایی از مدل Myran که با استفاده از FME 2019 به CityGML تبدیل شده است .

شکل ۶٫ نماهایی از مدل Myran که توسط آزمایش AGIS-FME-RVTr-L1 به CityGML تبدیل شده است، در azul مشاهده می شود.

شکل ۷٫ نماهایی از مدل Myran که توسط آزمایش AGIS-FME-IFCr-L1 به CityGML تبدیل شده است، در azul مشاهده می شود. در این حالت سقف از بین رفته است.

شکل ۸٫ نماهایی از مدل Myran که توسط آزمون FME-RVTr-L1 به CityGML تبدیل شده است، در azul مشاهده می شود.

شکل ۹٫ نماهایی از مدل Myran که توسط آزمون FME-IFCr-L1 به CityGML تبدیل شده است، در azul مشاهده می شود.

شکل ۱۰٫ مدل BuildingsLoD3.gml که توسط ابزار CityGML2IFC به IFC تبدیل شده است ، در FZKViewer نمایش داده شده است .

شکل ۱۱٫ نتیجه تبدیل FME که در RDF IfcViewer مشاهده می شود. ( الف ) IfcWalls در بنفش و IfcSpaces با رنگ‌های مختلف؛ ( ب ) IfcSlabs.

شکل ۱۲٫ نتیجه تبدیل FZK مدل amsterdam.gml به IFC 2×3، که در RDF IfcViewer نمایش داده شده است. ( الف ) مدل کامل، ( ب ) ساختمان‌های به‌دست‌آمده و ( ج ) نمای جانبی مدل است که در آن می‌توان فقدان ارتفاع را در تقریباً همه اشیا درک کرد.

ونوس نصیرفام

11 فوریه 2023

مقالات