به سوی یکپارچه سازی داده های ناهمگن: یک راه حل فضایی DBMS از یک پروژه CRC-LCL در استرالیا †

خلاصه

طی دهه‌های اخیر، شهرهای بیشتری در سراسر جهان مدل‌های شهری سه‌بعدی معنایی محیط‌های ساخته شده خود را بر اساس استانداردها در حوزه‌های مختلف ایجاد کرده‌اند. مدل های سه بعدی شهر، که اغلب برای طیف وسیعی از وظایف به کار می روند، بسیار فراتر از تجسم خالص هستند. با توجه به نیازهای مختلف مقیاس فضایی برای برنامه ریزی و مدیریت محیط های ساخته شده مختلف، ادغام سیستم های اطلاعات جغرافیایی (GIS) و مدل سازی اطلاعات ساختمان (BIM) در سال های اخیر پدیدار شده است. اکنون تمرکز به مدل‌سازی اطلاعات منطقه (PIM) تغییر می‌کند که در یک مفهوم کلی‌تر به مدل‌سازی محیط ساخته شده است. با تغییر مقیاس ها، گزینه ها برای انجام مدل سازی اطلاعات برای برنامه های مختلف نیز تغییر می کنند. بنابراین، چگونگی پیاده‌سازی قابلیت همکاری داده‌ها در این نمایش‌های دیجیتال، به یک چالش نوظهور تبدیل می‌شود. علاوه بر این، با رشد داده‌های ناهمگن چند منبعی متشکل از نمایش‌های فضایی 2 بعدی/3 بعدی معنایی و متفاوت، مدیریت داده‌ها برای تسهیل توسعه و استقرار برنامه‌های PIM امکان‌پذیر می‌شود. نحوه استفاده از داده های ناهمگن به شیوه ای یکپارچه برای بیان بیشتر PIM یک موضوع باز و جامع است. در این مقاله، ما یک PIM معنایی را بر اساس داده‌های ناهمگن چند منبع توسعه می‌دهیم. سپس، مشکلات مدیریت داده های مکانی را در راه حل سیستم مدیریت پایگاه داده مکانی (SDBMS) برای مدل یکپارچه تعریف شده خود حل می کنیم. مطالعات موردی در محوطه دانشگاه نیو ساوت ولز (UNSW) کارایی راه حل ما را نشان می دهد. مدیریت داده ها برای تسهیل توسعه و استقرار برنامه های کاربردی PIM امکان پذیر می شود. نحوه استفاده از داده های ناهمگن به شیوه ای یکپارچه برای بیان بیشتر PIM یک موضوع باز و جامع است. در این مقاله، ما یک PIM معنایی را بر اساس داده‌های ناهمگن چند منبع توسعه می‌دهیم. سپس، مشکلات مدیریت داده های مکانی را در راه حل سیستم مدیریت پایگاه داده مکانی (SDBMS) برای مدل یکپارچه تعریف شده خود حل می کنیم. مطالعات موردی در محوطه دانشگاه نیو ساوت ولز (UNSW) کارایی راه حل ما را نشان می دهد. مدیریت داده ها برای تسهیل توسعه و استقرار برنامه های کاربردی PIM امکان پذیر می شود. نحوه استفاده از داده های ناهمگن به شیوه ای یکپارچه برای بیان بیشتر PIM یک موضوع باز و جامع است. در این مقاله، ما یک PIM معنایی را بر اساس داده‌های ناهمگن چند منبع توسعه می‌دهیم. سپس، مشکلات مدیریت داده های مکانی را در راه حل سیستم مدیریت پایگاه داده مکانی (SDBMS) برای مدل یکپارچه تعریف شده خود حل می کنیم. مطالعات موردی در محوطه دانشگاه نیو ساوت ولز (UNSW) کارایی راه حل ما را نشان می دهد. ما مشکلات مدیریت داده های مکانی را در راه حل سیستم مدیریت پایگاه داده مکانی (SDBMS) برای مدل یکپارچه تعریف شده خود حل می کنیم. مطالعات موردی در محوطه دانشگاه نیو ساوت ولز (UNSW) کارایی راه حل ما را نشان می دهد. ما مشکلات مدیریت داده های مکانی را در راه حل سیستم مدیریت پایگاه داده مکانی (SDBMS) برای مدل یکپارچه تعریف شده خود حل می کنیم. مطالعات موردی در محوطه دانشگاه نیو ساوت ولز (UNSW) کارایی راه حل ما را نشان می دهد.

کلید واژه ها:

SDBMS ; محیط ساخته شده ؛ PIM ; مدل شهر سه بعدی ; CityGML ; IFC

1. معرفی

با توجه به قدرت بیانی قوی مدل‌های شهر سه بعدی بصری، بسیاری از مناطق واقعی هندسه و ویژگی‌های گرافیکی سه‌بعدی و همچنین روابط متقابل فضایی و معنایی را به‌عنوان مدل شهری سه‌بعدی معنایی مدل‌سازی می‌کنند. با گسترش کاربردهای مدل شهر سه بعدی [ 1 ]، مانند برنامه ریزی شهری [ 2 ]، شبیه سازی های محیطی [ 3 ]، ناوبری [ 4 ]، مدیریت بلایا [ 5 ] و ارزیابی انرژی [ 6 ]]، تلاش های تحقیقاتی قابل توجهی به مدیریت کارآمد و موثر و تجزیه و تحلیل مدل های سه بعدی شهر که اطلاعات معنایی و مکانی غنی را حمل می کنند، اختصاص یافته است. در میان آنها، سیستم مدیریت پایگاه داده مکانی (SDBMS) یک زمینه امیدوارکننده برای پشتیبانی از آمیختگی داده ها و اکتشافات معنایی برای دریافت درک بهتر از محیط ساخته شده است [ 7 ].

سیستم های اطلاعات جغرافیایی (GIS) در دهه 1970 ظهور کردند [ 8 ]، و اخیراً، مدل سازی اطلاعات ساختمان (BIM) [ 9 ] برای پاسخگویی به نیازهای برنامه ریزان و معماران به ترتیب پیشنهاد شد [ 10 ]. علاوه بر این، همانطور که مدل های مختلف داده به طور فزاینده ای مورد استفاده قرار می گیرند، نیاز به روش های چند بعدی و چندگانه برای مشاهده و درک داده ها دارند. هستی شناسی های معنایی برای ارائه درک واضح تری از مرزهای مکانی و زمینه داده های مکانی طراحی شده اند [ 11 ]. GIS معنایی نیاز به مدیریت فضای خارج از محدوده فیزیکی در قالبی انتزاعی تر دارد. برنامه ریزی و طراحی شهری معمولاً اطلاعات GIS-BIM را در مقیاس محدوده مدل می کند. مدل سازی اطلاعات حوزه (PIM) همانطور که در سال 2017 پیشنهاد شد [ 10] به عنوان یک پلت فرم اطلاعات فعال دیجیتالی متشکل از مجموعه‌ای از استانداردها و پروتکل‌ها (شامل CityGML و IFC) در نظر گرفته شد که می‌تواند فعالیت تکه‌تکه‌شده را که شامل مدل‌سازی شهری مجموعه‌های داده‌های فضایی و معنایی بزرگ در مقیاس حوزه است، هماهنگ و هدایت کند.

در مقیاس محدوده، حجم داده‌های مورد نیاز برای مدل‌سازی مؤثر محیط ساخته‌شده به طور قابل‌توجهی فراتر از آن چیزی است که برای یک ساختمان فردی لازم است. نحوه سازماندهی این مقیاس از داده ها به یک مسئله مهم تبدیل می شود. سیستم مدیریت پایگاه داده مکانی (SDBMS) نقش مرکزی را به عنوان یکپارچه سازی داده ها و پلتفرم های انتقال داده های 2 بعدی و سه بعدی ارجاع داده شده جغرافیایی در سناریوهای کاربردی متعدد ایفا می کند. در همین حال، برنامه‌ریزی و مدل‌سازی شهری سه بعدی تحت استانداردهای مختلف کار می‌کند (به عنوان مثال، CityGML [ 12 ] و IFC [ 13 ]])، می تواند توسط SDBMS برای ذخیره و بازیابی کارآمد طرح ها، نقشه ها و مدل های سه بعدی پشتیبانی شود. SDBMS سیستم مدیریت پایگاه داده رابطه‌ای سنتی (RDBMS) را با ترکیب انواع داده‌های مکانی و توابع/عملیات بر روی انواع داده‌های پشتیبانی‌شده در مدل داده خود گسترش می‌دهد [ 14 ].

1.1. رویکردها و چالش های موجود

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

اکثر مدل های شهر سه بعدی فعلی با استفاده از استاندارد CityGML یا IFC طراحی شده اند. برخی تحقیقات در رابطه با مدل‌های CityGML و IFC برای تبدیل اطلاعات به سمت تولید دانش و هوش در سال‌های اخیر توسعه یافته‌اند [ 15 , 16 , 17]. با این حال، از آنجایی که داده‌های BIM و GIS به روش‌های مختلف از نظر سیستم‌های مختصات، محدوده مورد علاقه و ساختار داده ایجاد، مدیریت و تجسم می‌شوند، ناسازگاری داده‌ها به یک موضوع مهم تبدیل می‌شود. علاوه بر این، افزایش شدید و اخیر در دسترس بودن داده‌های جمع‌آوری‌شده توسط منابع داده‌های مختلف همراه با ماهیت ناهمگن قابل‌توجه آنها، امکان استفاده از مجموعه داده‌های چندوجهی را به شیوه‌ای مشترک برای بهبود بیشتر عملکرد رویکردهای پردازش با توجه به برنامه کاربردی در اختیار می‌گذارد. دست بنابراین، ادغام داده های چند منبع، به عنوان یک رویکرد چند رشته ای عمومی و محبوب، توجه زیادی را به خود جلب کرده است [ 18 ].

1.2. مشارکت ها

این مقاله یک راه‌حل DBMS فضایی را برای مدیریت مدل شهر سه بعدی یکپارچه در مقیاس حوزه ارائه می‌کند که بر اساس ترکیب داده‌های ناهمگن چند منبعی است. ابتدا، ما یک PIM ایجاد می کنیم که معنایی، هندسه و ویژگی های گرافیکی اشیاء محیط ساخته شده را در مقیاس دانشگاه یکپارچه می کند. سپس، ما مطالعات موردی را در محوطه دانشگاه UNSW انجام می دهیم. مطالعات تجربی تایید می‌کنند که مدل شهر سه بعدی ما درک محیط ساخته شده در اطراف محوطه دانشگاه را بهبود می‌بخشد.

کمک های اولیه ما به شرح زیر است:

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

1.3. سازمان

ساختار بقیه این مقاله به صورت زیر است: بخش 2 نگاهی کوتاه به مدل های شهر سه بعدی و ترکیب داده ها می دهد. علاوه بر این، جنبه‌ها و رویکردهای ضروری برای مدل‌سازی داده‌های جغرافیایی با استفاده از DBMS فضایی مورد بحث قرار می‌گیرد تا پایه و اساس طراحی یک طرح پایگاه داده رابطه‌ای یکپارچه و سازگار برای PIM را فراهم کند. بخش 3 و بخش 4 داده های ناهمگن چند منبعی (GIS، BIM، LiDAR و حسگر) را با جزئیات در مورد طراحی مفهومی و طراحی پایگاه داده رابطه ای ارائه می کند. یک مطالعه موردی در محوطه دانشگاه UNSW برای نشان دادن قابلیت استفاده و کارایی مدل ما در بخش 5 نشان داده شده است.. بخش آخر نتیجه‌گیری را در مورد کار ارائه‌شده نشان می‌دهد و جنبه‌های مربوط به وظایف تحقیق و توسعه آینده ما را تشریح می‌کند.

2. پیشینه و کارهای مرتبط

2.1. مدل های سه بعدی شهر و PIM

مدل شهر سه بعدی نمایشی از یک محیط شهری با هندسه سه بعدی از اشیاء و سازه های شهری رایج است که ساختمان ها برجسته ترین ویژگی آن هستند [ 1 ، 19 ، 20 ].]. ظاهراً تجسم بر استفاده های اولیه از مدل های سه بعدی شهر غالب بود. با این حال، با توسعه فناوری، مدل‌های شهر سه بعدی برای اهداف مختلفی فراتر از تجسم ارزشمند شده‌اند و در بسیاری از حوزه‌ها (به عنوان مثال، تجزیه و تحلیل دید، کاداستر سه بعدی، برنامه‌ریزی زیرساخت، ناوبری داخلی، برآورد تقاضای انرژی) استفاده می‌شوند. از آنجایی که هر برنامه سه بعدی به داده های سه بعدی خاص خود نیاز دارد، یک فهرست جامع می تواند به پیوند الزامات به برنامه های خاص کمک کند. طراحی شهری شامل برنامه ریزی و معماری و همچنین اطلاعات و محیط های مدل سازی GIS-BIM است که عمدتاً در مقیاس محدوده عمل می کند. مدل سازی اطلاعات ناحیه (PIM) در سال 2013 [ 10 ] به عنوان محور این مقیاس از نوآوری شهری پیشنهاد شده است. همانطور که در شکل 1 نشان داده شده استمقیاس های فضایی برای مدل سازی محیط ساخته شده از اشیاء عمومی تا ساختمان ها و به بالا تا شهرها و کشورها را شامل می شود. با نیاز به قابلیت همکاری داده‌ها، انواع مختلفی از کاربردهای مدل‌سازی اطلاعات بر اساس مقیاس‌های چندگانه (یعنی BIM -> PIM -> GIS) در سال‌های اخیر پدید آمدند. در اینجا، مقیاسی که ما در PIM در مورد آن صحبت می‌کنیم، بیشتر در مورد دامنه مدل‌سازی است، در حالی که، سطح جزئیات در CityGML و IFC جزئیات کمتر یا بیشتر یک شی را از نظر هندسه و موضوعی نشان می‌دهد.

2.2. محیط ساخت هوشمند و فرصت های ترکیب داده ها

با پیدایش مفهوم «محیط ساخته شده هوشمند» که به محیط ساخته شده ای اطلاق می شود که با اشیاء هوشمند مانند حسگرها و محرک ها با قابلیت های محاسباتی و ارتباطی تعبیه شده است و محیط را به اندازه کافی «هوشمند» می کند تا بتواند هوشمندانه با آن تعامل داشته باشد. و از کاربران انسانی خود در فعالیت‌های روزانه‌شان [ 21 ] حمایت می‌کنند، محققان چگونگی طراحی مدل‌های ساختمانی را بررسی کرده‌اند که میزبان اطلاعات چندگانه در طول چرخه عمر آن هستند و بهره‌گیری از اطلاعات و قابلیت‌های BIM یا GIS چیست (نگاه کنید به [ 22 ]). ).

در حال حاضر، حجم عظیمی از داده ها در یک بازه زمانی سریع در محیط ساخته شده تولید می شود. اینکه چگونه این داده‌های منابع چندگانه را دقیق و بسیار دقیق کنیم، مشکلی است که باید مورد توجه قرار گیرد، زیرا کیفیت این اطلاعات نقش مهمی در تجسم، برنامه‌ریزی و تصمیم‌گیری ایفا می‌کند. ادغام داده ها [ 23 ، 24 ]، که به عنوان بخشی از یکپارچه سازی داده ها در نظر گرفته می شود، یک فرآیند موثر از ادغام داده های متعدد است که یک شیء دنیای واقعی یکسان را در یک نمایش سازگار، دقیق و مفید نشان می دهد. شکل 2پارادایم ادغام داده های عمومی را ارائه می دهد. به عنوان مثال، چندین مجموعه داده ساخت و ساز برای دامنه ساختمان عمومی وجود دارد که توسط ارائه دهندگان داده های مختلف تولید می شود. هدف ادغام داده ها، ادغام این مجموعه داده ها در یک پایگاه داده با یک طرح داده سازگار، از طریق فرآیند جذب، حذف تکراری و یکپارچه سازی است. سوابق (از مجموعه داده های مختلف) که یک شی را توصیف می کنند، به عنوان مثال، یک ساختمان تجاری، در همان دامنه ایجاد می شوند.

2.3. مدل سازی داده های جغرافیایی در DBMS فضایی

سیستم مدیریت پایگاه داده مکانی (Spatial DBMS) [ 14 ] معمولاً به عنوان یک سیستم مدیریت پایگاه داده رابطه‌ای اصلی (DBMS) در نظر گرفته می‌شود که شامل انواع داده‌های مکانی و هندسه، پشتیبانی از شاخص‌های مکانی، و ارائه عملکردها و عملیات برای تجزیه و تحلیل و پردازش می‌شود. از اشیاء فضایی مفاهیم توسعه‌یافته در زمینه‌های DBMS فضایی ممکن است برای برنامه‌های جغرافیایی ۲ بعدی و ۳ بعدی اعمال شوند [ 7 ، 25 ، 26 ].

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

2.4. استانداردهای CityGML و IFC

مدل سازی اطلاعات ساختمان (BIM) یک نمایش دیجیتالی از خصوصیات فیزیکی و عملکردی یک تأسیسات است [ 27 ]]. این مبتنی بر فناوری ترکیب اطلاعات در سه بعدی (3D) است و اطلاعات لازم مورد نیاز معماری، مهندسی، ساخت و ساز و مدیریت تسهیلات (AEC/FM) را ادغام می کند. در مقابل، علم اطلاعات جغرافیایی (GIS) برای مدیریت و تجزیه و تحلیل داده‌های مکانی توسعه یافته است که مبتنی بر فناوری‌های ژئوماتیک است. GIS به عنوان یک فناوری/سیستم امکان ذخیره سازی اطلاعات مکانی را در پایگاه داده رابطه ای فراهم می کند و به عنوان یک علم نیز فراتر از سیستم ذخیره سازی داده ها است. اطلاعات ویژگی مرتبط با ویژگی های فضایی ذخیره شده در پایگاه داده امکان تجزیه و تحلیل فضایی بیشتر را با استفاده از ویژگی های مکانی و غیر مکانی فراهم می کند.

به دلیل دسترسی بیشتر به اطلاعات، سهولت تجزیه و تحلیل و به دلایل عملگرایانه، مطالعات در مورد تبادل داده های BIM و GIS اغلب بر دو استاندارد باز برجسته در دو حوزه تمرکز می کنند: استاندارد OGC CityGML [ 12 ] برای GIS سه بعدی. دامنه، و کلاس‌های بنیاد صنعت (IFC) [ 13] برای دامنه BIM. مدل‌های IFC عناصر فیزیکی سازه‌های منفرد را با جزئیات زیاد نشان می‌دهند، در حالی که مدل‌های CityGML کل شهرها را در قالبی ساده‌تر نشان می‌دهند که برای تبادل، انتشار و تحلیل‌های فضایی، مانند برآورد پتانسیل خورشیدی و مصرف انرژی قابل استفاده است. دو پارادایم مدل‌سازی که توسط IFC و CityGML تجسم شده‌اند به طور کلی نماینده داده‌های BIM و 3D GIS هستند و هر دو به طور گسترده در حوزه‌های مربوطه مورد استفاده قرار می‌گیرند.

2.5. کارهای مرتبط برای CityGML و ادغام IFC

BIM و GIS مدل‌سازی سه بعدی را از دو دیدگاه متفاوت تفسیر می‌کنند: GIS بیشتر بر مدل‌سازی در دنیای واقعی تمرکز دارد، در حالی که BIM بیشتر بر فرآیند طراحی متمرکز است. بنابراین، در CityGML، به عنوان مثال، یک دیوار به عنوان سطح برای هر اتاق به طور جداگانه نشان داده می شود، در حالی که در IFC، یک دیوار یک جسم حجمی است که بین اتاق ها و پوسته بیرونی مشترک است [ 28 ]. مدل‌سازی دنیای واقعی GIS توسط الزامات وظایف نقشه‌برداری هدایت می‌شود، در حالی که مدل‌سازی طراحی BIM مبتنی بر نمایش جزئیات طراحی و ساخت هندسی است [ 29 ]]. با در نظر گرفتن ساختمان ها، GIS اغلب بر روی اطلاعات جغرافیایی و شکل ساختمان ها و اجزای ساختمان از منظر جغرافیایی تمرکز می کند. در مقابل، BIM اغلب بر اجزای ساختمانی دقیق مانند معماری و چشم انداز ساخت و ساز تمرکز می کند [ 30 ]. با تقاضای اخیر برای ادغام برنامه های کاربردی در فضای باز و داخلی [ 31 ] برای اهداف مختلف، تلاش هایی برای طراحی روش ها و ابزارهایی برای ادغام مدل های ساختمان در یک زمینه جغرافیایی انجام شده است.

سیستم یکپارچه سازی BIM و GIS مدیریت موثر اطلاعات را در مراحل مختلف چرخه عمر پروژه، یعنی برنامه ریزی، طراحی، ساخت، بهره برداری و نگهداری را ممکن می سازد [ 17 ]. اطلاعات در هر مقیاس مکانی و زمانی می تواند در چنین سیستمی برای کاربردهای مختلف در دسترس باشد. مدیریت مؤثر اطلاعات ناهمگن از منابع مختلف نیز می تواند پشتیبانی های اساسی برای تصمیم گیری فراهم کند.

3. مدل سازی اطلاعات حوزه (PIM) با داده فیوژن

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

مدل یکپارچه در سطح حوزه ( بخش 3 )

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

مدل داده یکپارچه شی گرا به جداول رابطه ای نگاشت شده است. تعداد جداول برای به حداقل رساندن تعداد پیوست ها برای پرس و جوهای معمولی بهینه شده است.

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

کلاس هایی که به رنگ زرد رنگ شده اند متعلق به مدل خالص CityGML هستند که در بخش های فرعی زیر مورد بحث قرار می گیرد.
کلاس هایی که با رنگ سبز رنگ آمیزی شده اند متعلق به مدل خالص IFC هستند.
کلاس های رنگ آمیزی شده با رنگ آبی اشیاء یکپارچه از هر دو مدل IFC و CityGML هستند که در بخش 3.2.1 تعریف شده اند .
کلاس هایی که با رنگ صورتی رنگ آمیزی شده اند از داده های حسگر مانند گاز و برق هستند.

3.1. PIM مفهومی در مقیاس پردیس

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

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

ساختمان
سنسور
مبلمان شهری
زمین
حمل و نقل
زندگی گیاهی
کاربری زمین

هدف از مدل سازی صریح دستیابی به درجه بالایی از قابلیت همکاری معنایی بین برنامه های کاربردی مختلف است. با مشخص کردن مفاهیم موضوعی و معنایی آنها به همراه نگاشت آنها به UML، برنامه‌های مختلف می‌توانند به مجموعه‌ای کاملاً تعریف شده از انواع شی، ویژگی‌ها و هندسه پاسخ دهند. کلاس پایه همه کلاس‌های موضوعی در مدل داده ما، کلاس انتزاعی CampusObject است که تاریخ ایجاد و پایانی را برای مدیریت تاریخچه‌های اشیاء و همچنین ویژگی‌های عمومی و ارجاع‌های خارجی به اشیاء متناظر در سایر مجموعه‌های داده ارائه می‌کند. چنین مرجعی به نام ExternalReference نشان دهنده سیستم اطلاعات خارجی و شناسه منحصر به فرد شی در این سیستم است. زیر کلاس های CampusObjectشامل زمینه های موضوعی مختلف یک مدل پردیس می شود که در زیر توسط مدل های جداگانه پوشش داده می شود: مدل ساختمان ( ساختمان )، مدل مبلمان شهری ( CityFurniture )، مدل زمین دیجیتال (Train)، مدل کاربری زمین ( LandUse )، مدل حمل و نقل ( حمل و نقل ) , مدل گیاهی ( Vegetation ) و مدل حسگر ( Sensor ). از نظر کلاس خاص ساختمان ، هر دو مدل ساختمان IFC و CityGML را پوشش می دهد (جزئیات این دو مدل جداگانه را می توان در ضمیمه A و ضمیمه B یافت).

3.2. مدل ساختمان

3.2.1. مدل ساختمان یکپارچه (IBM)

مدل ساختمان کلاسی است که اطلاعات مربوط به سازه های فضایی و اشیاء ساختمانی را از داده های BIM و GIS در مدل پردیس سه بعدی ما جمع آوری می کند. همچنین می‌تواند مدل‌سازی یک طرح پایگاه داده را تسهیل کند که می‌تواند داده‌هایی را که برای تمام سطوح جزئیات (LOD) لازم است، حمل کند. بنابراین، مدل ساختمان یکپارچه (IBM)، به عنوان مدل یکپارچه برای واردات مدل ساختمان خالص IFC و CityGML ارائه شده توسط سهامداران مختلف استفاده می شود. همچنین، روش‌های خود را برای تبدیل اشیاء از IFC و CityGML به موارد موجود در IBM پیشنهادی ارائه می‌کنیم ( شکل 6 را ببینید ).

برای ساخت یک مدل ساختمان یکپارچه، تمام کلاس ها با مفاهیم خود از هر دو مدل CityGML و IFC جمع آوری شده اند. مفاهیم همپوشانی ادغام می شوند و بنابراین اشیاء جدید باید به گونه ای ایجاد شوند که اشیاء هر دو مدل را بتوان گرفت. شکل 6 مدل ساختمان یکپارچه را نشان می دهد که در زیر به اختصار توضیح داده شده است.

بر اساس مدل CityGML، مدل ساختمان امکان نمایش ساختمان‌های ساده که تنها از یک جزء تشکیل شده‌اند و همچنین نمایش روابط پیچیده بین بخش‌های یک ساختمان را می‌دهد. بنابراین، زیر کلاس Building و BuildingPart از کلاس محوری _AbstractBuilding را فراهم می کند . با این حال، در مدل IFC، تنها یک کلاس، IfcBuilding برای نمایش ساختار اصلی ساختمان استفاده می‌شود. برای راحتی کار، یک کلاس Building منحصر به فرد ایجاد می کنیم که مفاهیم IfcBuilding و _AbstractBuilding را برای نشان دادن ساختمان های ساده یا پیچیده ادغام می کند.

بر اساس مدل IFC، یک ساختمان برای ارائه یک عنصر اساسی در سلسله مراتب ساختار فضایی برای اجزای یک پروژه ساختمانی همراه با مکان، طبقه و فضا استفاده می‌شود. بنابراین، یک ساختمان باید حداقل یک طبقه (به نام BuildingStorey در IBM) داشته باشد که دارای ویژگی elevation به عنوان مقدار ارتفاع محلی نسبت به بالای دال ساختمانی باشد. یک فضا در IFC نشان دهنده یک منطقه یا حجم است که در واقع یا از لحاظ نظری در داخل یک ساختمان محدود شده است. با این حال، یک ساختمان در CityGML شامل اتاق هایی است که می تواند به عنوان فضایی در نظر گرفته شود که توسط سطوح مختلف مرزی احاطه شده است. بنابراین، ما یک کلاس Space ایجاد می کنیم که شی IfcSpace را کپی می کند. ما LOD2 را به اشیاء سطح مرزی LOD4 _BoundarySurface پیوند می دهیمبا شی فضایی، که در آن سطوح مرزی برای ساختار دهی پوسته بیرونی ساختمان و سطوح قابل مشاهده یک اتاق استفاده می شود. هر دو IFC و CityGML حاوی شی بازکننده هستند. با این حال، در CityGML کلاس پایه انتزاعی برای توصیف معنایی بازشوهایی مانند درها یا پنجره ها است ( شکل 7 )، در حالی که عنصر بازکننده در IFC نشان دهنده یک فضای خالی در هر عنصری است که جلوه فیزیکی دارد و باید در یک IfcBuildingElement درج شود. مانند IfcDoor و IfcWindow . در اینجا، ما یک کلاس انتزاعی _Opening شامل لیست ویژگی ها در IfcOpeningElement و دو کلاس خاص Door و Window ایجاد می کنیم. _افتتاحاشیاء در IBM فقط در مدل های LOD3 یا LOD4 وجود دارند و هر کدام با یک هندسه gml:MultiSurface مرتبط هستند.

المان ساختمانی شامل تمام عناصری است که در درجه اول بخشی از ساخت یک ساختمان هستند. با این حال، عناصر در CityGML به طور صریح تعریف نشده‌اند، اما می‌توانند به‌عنوان یک تجمع صریح از IntBuildingInstallation و BuildingInstallation نشان داده شوند. در این مورد، IntBuildingInstallation و BuildingInstallation را در یک کلاس انتزاعی به نام _BuildingInstallation ادغام می‌کنیم ، که برای عناصر ساختمانی مانند بالکن، دودکش، خوابگاه یا پله‌های بیرونی استفاده می‌شود که به شدت بر ظاهر بیرونی ساختمان و اشیاء داخل ساختمان تأثیر می‌گذارد که (در مقابل به مبلمان) قابل انتقال نیست. یک _BuildingInstallation ممکن است این ویژگی ها را داشته باشدکلاس ، تابع ، کاربرد ، و هندسه .

با در نظر گرفتن عناصر ساختمان، یک کلاس انتزاعی به نام _BuildingElement ایجاد می کنیم که شامل چندین زیر کلاس است. برای اینکه بتوانیم آنها را پر کنیم، باید اشیایی را از CityGML و IFC متعلق به تاسیسات داخلی یا خارجی ساختمان سازماندهی کنیم. در IFC، کلاسی به نام IfcBuildingElement وجود دارد که شامل تمام عناصری است که در درجه اول بخشی از ساخت یک ساختمان هستند. ما آنها را بر اساس مفاهیم IntBuildingInstallation و BuildingInstallation در CityGML به کلاس های مختلف تقسیم می کنیم . در این صورت عناصر ساختمانی مانند دودکش، ستون، پله، نرده که در هر دو مدل وجود دارد و می توانیم آنها را در یک کلاس یکپارچه مانند دودکش ، ستون ترکیب کنیم., پله , و نرده . علاوه بر این، عناصر دیگر فقط در IFC در حالی که متعلق به نصب ساختمان هستند (مانند Slab ، StairFlight ، Member ، Beam ، Plate ، Ramp ) نیز باید به عنوان زیر کلاس های _BuildingInstallation در IBM اضافه شوند.

علاوه بر این، مبلمان اتاق مانند میز و صندلی را می توان در مدل ساختمان CityGML با کلاس BuildingFurniture نشان داد. یک BuildingFurniture ممکن است دارای ویژگی های کلاس , عملکرد , کاربرد و هندسه باشد . یک شیء BuildingFurniture باید دقیقاً به یک شیء اتاق مربوط باشد. اما در IFC به قسمت متحرک ساختمان مانند صندلی یا مبلمان توجه نمی شود. بنابراین، ما به سادگی کلاس BuildingFurniture را از مدل CityGML در IBM ایجاد می کنیم. تمام هندسه داخلی یک ساختمان در LOD4 است که بالاترین سطح وضوح است. می توانیم در نظر بگیریمBuildingFurniture به عنوان زیرشاخه های کلاس _BuildingElement جدید است و فقط اشیاء را از مدل ساختمان CityGML می پذیرد.

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

_دیوار یک عنصر عمودی/نیمه عمودی است که فضاها را احاطه یا تقسیم می کند. دارای سه نوع فرعی است:

–

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

–

ExteriorWall برای دیوار خارجی که با محیط بیرون ارتباط داشته و نمایانگر بخشی از نمای خارجی ساختمان است.

–

کرتین وال برای دیوار بیرونی که نمای کامل یک ساختمان یا بخشی از آن را می پوشاند.
_پوشش سطح بسته شدنی است که از سمت بالا فضایی را می پوشاند. سه نوع دارد:

–

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

–

سقف برای پوشش داخلی هر فضای یک ساختمان;

–

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

–

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

–

طبقه برای سطح پایین یک فضا در هر فضای یک ساختمان به جز طبقه پایین (پایین ترین)؛

–

OuterFloor برای سطح افقی متعلق به پوسته بیرونی ساختمان و با جهت گیری رو به بالا.

3.2.2. تبدیل از IFC و CityGML به IBM

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

از IFC تا IBM

قانون تبدیل از IFC به IBM. معمولاً از مدل IFC برای نمایش جزئیات قسمت داخلی ساختمان استفاده می شود که می تواند مکمل جزئیات معماری باشد. بنابراین ما فقط مدل IFC را در LOD3 و LOD4 IBM در نظر می گیریم.

در LOD3، بخش هایی از اشیاء خارجی و عناصر داخلی سازه ساختمان نشان داده شده است. اطلاعات مورد نیاز برای BuildingStorey و Space را می توان مستقیماً از IfcBuildingStorey و IfcSpace دریافت کرد. در IFC، عناصر ساختمانی ( IfcBuildingElement ) و عناصر بازکننده ( IfcOpeningElement ) داریم. یک IfcOpeningElement باید با استفاده از رابطه IfcRelVoidsElement در IfcBuildingElement درج شود. ممکن است توسط یک IfcDoor ، IfcWindow یا یک عنصر پرکننده دیگر با استفاده از رابطه پر شودIfcRelFillsElements . اطلاعات هندسی در مورد درها و پنجره ها به عنوان Sweeping و مدل های CSG به عنوان سایر عناصر ساختمان (به عنوان مثال، دیوارها و دال ها) تعریف می شوند. در مدل پیشنهادی ما، هندسه BRep را برای عناصر باز مانند CityGML اتخاذ می‌کنیم. بنابراین، تبدیل از مدل‌های هندسی Sweeping/CSG که در IFC استفاده می‌شوند به مدل‌های BRep باید انجام شود.

در LOD4 IBM، تمام اشیاء یک سازه ساختمان، به عنوان مثال، عناصر ساختمان (دیوار داخلی، سقف، کف، و غیره)، مبلمان ساختمان، سطح مرز نشان داده شده است. مانند تمام اشیاء IFC، هندسه Sweeping/CSG برای فضاها و عناصر آنها استفاده می شود که نیازمند تبدیل به مدل های هندسی BRep است که ما در IBM استفاده می کنیم. برای ایجاد فضاها در UBM، از اطلاعات IfcWall ، IfcRoof و IfcSlab که مرزهای اتاق ها را تشکیل می دهند استفاده می شود. در اینجا ذکر این نکته ضروری است که اطلاعات تمام عناصر ساختمانی که یک فضا را تشکیل می دهند در کلاس _BuildingElement ذخیره می شود.

از CityGML تا IBM

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

در LOD1، یک مدل ساختمان از یک نمایش هندسی تعمیم یافته از پوسته بیرونی تشکیل شده است. به دلیل عدم نیاز به اطلاعات از IFC در این سطح از جزئیات، شی _ AbstractBuilding می تواند مستقیماً به عنوان شی ساختمان در IBM مطابقت داده شود و ممکن است هندسه های gml:MultiCurve و gml:Solid را برای پوشش پوسته خارجی داشته باشد.

در LOD2، پوسته بیرونی ساختمان شروع به تجزیه شدن به جزئیات می کند. CityGML _BoundarySurface کلاس پایه را برای تمام اشیاء دیگری که یک پوسته ساختمان را تشکیل می دهند، نشان می دهد. در این LOD، تنها جزئیات مورد نیاز در مورد: (1) پوشش یک ساختمان و اشکال سقف و سقف بیرونی آن (از RoofSurface و OuterCeilingSurface ) است. (ii) دیوار ساختمان و سطوح دیوارهای بیرونی آن با جزئیات آنها (از WallSurface ). و (iii) سطح ساختمان و اشکال طبقه همکف و بیرونی آن (از GroundSurface و OuterFloorSurface )). در IBM، ما همان مدل هندسی CityGML را نگه می داریم (فقط BRep را در نظر می گیریم)، بنابراین در این مرحله هیچ تبدیل هندسی وجود ندارد. برای تاسیسات ساختمانی، مفهوم در IBM بسیار نزدیک به CityGML است. بنابراین، می توانیم از نگاشت یک به یک هندسه های BuildingInstallation به هندسه _BuildingInstallation استفاده کنیم .

LOD3 نشان دهنده مدل های معماری با ساختار دیوار و سقف دقیق است که به طور بالقوه شامل درها و پنجره ها می شود. اطلاعات مربوط به اشیایی که در یک طبقه ساختمان دارای سطح افقی یکسانی هستند (یا ممکن است بر اساس تعاریف کاربر باشد) را می توان برای تشکیل BuildingStorey جمع آوری کرد . BuildingStorey به طور هندسی توسط تمام فضاهایی که سطح کف یکسانی دارند توصیف می کند. این فضاها از سطوح مرزی سقف ، دیوار و سطح زمین ارجاع داده خواهند شد.که پوسته خارجی هر طبقه را مشخص می کند. در این LOD، عناصر بازکننده نیز باید در مدل ظاهر شوند. مفهوم ما از عناصر بازکننده شبیه به CityGML است زیرا در و پنجره زیرمجموعه‌های باز کردن کلاس هستند. بنابراین، نگاشت یک به یک را می توان بین _Opening ، Window و Door در کلاس های مربوطه در IBM انجام داد.

LoD4 نشان دهنده بالاترین LOD با جزئیات است که در آن تمام عناصر ساختمان، نمای بیرونی و داخلی، باید نشان داده شوند. برای ساخت مبلمان، می‌توانیم مستقیماً نقشه‌برداری یک به یک از BuildingFurniture در CityGML به BuildingFurniture در IBM انجام دهیم. برای _BoundarySurface ، در این LOD، جزئیات داخلی مورد نیاز عبارتند از: (1) پوشش یک ساختمان و اشکال سقف داخلی آن (از CeilingSurface ). (ii) دیوار ساختمان و اشکال دیوار داخلی آن (از InteriorWallSurface ). و (iii) سطح ساختمان و اشکال کف آن (از FloorSurface )). اطلاعات مربوط به عناصر ساختمان در زیر کلاس های مختلف کلاس _BuildingElement ذخیره می شود . در میان آنها، برای برخی از اشیاء متعلق به تاسیسات ساختمان (مانند دودکش، ستون، پله، نرده)، آنها را از IntBuildingInstallation به زیر کلاس های مربوطه _BuildingInstallation در IBM نگاشت می کنیم. علاوه بر این، اگر زیر کلاس‌های فوق توسط مدل IFC ایجاد شده‌اند، باید با وارد کردن هندسه‌ها و ویژگی‌های خاص در موارد موجود، آنها را با هم ادغام کنیم. ما مجموعه قوانین تبدیل را در قالب یک جدول ارائه می دهیم ( جدول 1 ).

3.3. مدل سنسور

مدل حسگر شامل چندین منبع داده مختلف بدون هندسه صریح است که در شکل 9 نشان داده شده است ، که توسط کلاس های انتزاعی _Sensor نشان داده شده در نمودار UML ارائه شده اند. انواع مختلفی از حسگرها وجود دارد که در آنها ساختمان ، اتاق و مهر زمانی مشخصه‌های رایج هستند. در میان آنها، حسگرهای دما، گرما را برای تشخیص تغییرات دما اندازه‌گیری می‌کنند، که ممکن است ویژگی سلسیوس نشان دهنده مقیاس دما باشد. سنسورهای رطوبت برای اندازه گیری میزان بخار آب در جو استفاده می شود. کیفیت گاز و هواسنسورها برای نظارت بر مصرف گاز و تغییرات کیفیت هوا از جمله دی اکسید کربن، مونوکسید کربن، هیدروژن، اکسید نیتروژن، اکسیژن استفاده می شوند. سنسورهای جریان الکتریکی (CT) مصرف انرژی بلادرنگ را در سطح مدار، منطقه یا ماشین اندازه گیری می کنند. دانستن میزان مصرف انرژی دو کاربرد اصلی دارد. ابتدا، می‌توان مشخص کرد که کجا بیشترین انرژی را مصرف می‌کنید و آن را هدر می‌دهید و به شما امکان می‌دهد پس‌انداز کنید. همچنین می توان به طور خودکار دارایی ها را هنگامی که استفاده نمی شود خاموش کرد. این حسگرها ممکن است یک قطعه اطلاعات متنی در جایی که قرار دارند (اتاق، ساختمان، خیابان) یا در برخی موارد حتی مختصات x، y، z واحد اندازه گیری داشته باشند.

3.4. مدل کاربری زمین

اشیاء LandUse مناطقی از سطح زمین را توصیف می کنند که به کاربری خاصی اختصاص داده شده است. می توان از آنها برای نمایش بسته ها به صورت سه بعدی استفاده کرد. شکل 10 نمودار UML اشیاء کاربری زمین را نشان می دهد.

هر شی LandUse ممکن است دارای کلاس ویژگی ها (مثلاً منطقه سکونت، منطقه صنعتی، زمین کشاورزی)، تابع (به عنوان مثال، مزرعه ذرت) و کاربری باشد که می تواند مورد استفاده قرار گیرد، اگر نحوه استفاده از شی با تابع متفاوت باشد. از آنجایی که استفاده و تابع ویژگی ها ممکن است چندین بار مورد استفاده قرار گیرند، ذخیره آنها تنها در یک رشته نیاز به یک فضای while واحد به عنوان طرحواره پایگاه داده رابطه ای جداکننده منحصر به فرد دارد. این سه ویژگی به صورت gml::CodeType مشخص می شوند . مقادیر این ویژگی ها را می توان در لیست های کد (که در نمودار UML با رنگ سبز رنگ آمیزی شده اند) برشمرد. کاربری زمینشی برای همه LOD 1-4 تعریف شده است و ممکن است هندسه های متفاوتی برای هر LOD داشته باشد. هندسه سطح یک شی LandUse باید دارای مقادیر مختصات سه بعدی باشد. باید یک GML3 MultiSurface باشد.

3.5. مدل مبلمان شهری

اشیاء مبلمان شهری اشیای غیر منقول مانند بولاردها، فانوس ها، سطل های گل، ستون های تبلیغاتی یا پایه های تعیین حدود هستند. نمودار UML مدل مبلمان شهری در شکل 11 نشان داده شده است .

کلاس CityFurniture ممکن است دارای ویژگی های کلاس , عملکرد و کاربرد باشد . ویژگی کلاس به یک طبقه بندی شی مانند چراغ راهنمایی، علائم راهنمایی و رانندگی، تعیین حدود یا سطل زباله اجازه می دهد و فقط یک بار می تواند رخ دهد. ویژگی تابع توصیف می کند که شی مبلمان شهری به کدام منطقه موضوعی تعلق دارد (مانند حمل و نقل، تنظیم ترافیک، معماری و غیره)، و می تواند چندین بار رخ دهد. استفاده از ویژگی نشان دهنده هدف واقعی شی شهر است و همچنین می تواند چندین بار رخ دهد. کلاس صفات ، تابع ، و استفاده از شیCityFurniture به عنوان gml:CodeType مشخص شده است. مقادیر این ویژگی ها را می توان در لیست کدها برشمرد. اجسام مبلمان شهری را می‌توان در مدل‌های شهری با هندسه خاص خود نشان داد، اما در بیشتر موارد همان شیء دارای هندسه یکسانی است. هندسه اشیاء CityFurniture در LOD 1-4 ممکن است با یک هندسه صریح نشان داده شود.

3.6. مدل حمل و نقل

مدل حمل و نقل یک مدل چند منظوره و چند مقیاسی است که بر جنبه های موضوعی و عملکردی و همچنین هندسی / توپولوژیکی تمرکز دارد. کلاس اصلی حمل و نقل است که به عنوان مثال یک جاده، یک مسیر، یک راه آهن یا یک میدان را نشان می دهد. در CityGML، حمل‌ونقل از بخش‌های TrafficArea و AuxiliaryTrafficArea تشکیل شده است که برخی از عناصر از نظر استفاده از ترافیک یا جاده هستند، مانند خطوط رانندگی خودرو، مناطق عابر پیاده، خطوط دوچرخه‌سواری، سنگ‌های کناری، خطوط میانی و مناطق سبز. در مدل پردیس خود، ما هر دو را نادیده می‌گیریم زیرا چنین محتوای جزئیاتی در پردیس عمومی وجود ندارد. اشیاء حمل و نقل را می توان به صورت موضوعی با استفاده از زیر کلاس های Track , Road متمایز کرد، و مربع . نمودار UML مدل حمل و نقل در شکل 12 نشان داده شده است .

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

3.7. مدل پوشش گیاهی

ویژگی های پوشش گیاهی اجزای مهم یک مدل پردیس سه بعدی هستند زیرا از شناخت محیط اطراف پشتیبانی می کنند. با تجزیه و تحلیل و تجسم اشیاء گیاهی می توان اظهاراتی در مورد توزیع، ساختار و تنوع آنها بیان کرد. مدل پوشش گیاهی CityGML بین اشیاء پوشش گیاهی منفرد مانند درختان و پوشش گیاهی مانند جنگل ها تمایز قائل می شود. ضمناً در مدل پردیس، اشیاء پوشش گیاهی نیازی به در نظر گرفتن ندارند و پوشش گیاهی منفرد را پوشش گیاهی در طبقه ای به نام Vegetation می دانند . نمودار UML مدل پوشش گیاهی در شکل 13 نشان داده شده است .

یک شیء گیاهی ممکن است دارای کلاس صفات (به عنوان مثال، درخت، بوته، علف)، گونه (نام گونه، به عنوان مثال، Abiesalba)، کاربرد ، و عملکرد (به عنوان مثال، بنای گیاه شناسی) باشد. هندسه یک گیاه ممکن است در LOD 1-4 به صراحت توسط یک هندسه GML با مختصات مطلق، مرتبط با gml::_Geometry کلاس هندسه GML دلخواه تعریف شود.

3.8. مدل زمین

بخش اساسی یک مدل پردیس، زمین است. CityGML شامل یک مدل زمین دیجیتال بسیار سازگار (DTM) است که امکان ترکیب انواع DTM ناهمگن (شبکه، TIN، خطوط شکست، نقاط جرم) موجود در سطوح مختلف جزئیات را فراهم می‌کند. ما کلاس Terrain را برای نشان دادن یک DTM متناسب با مدل پردیس خود بازتعریف می کنیم. این یک CampusObject با مرحله LOD است که با DTM به عنوان یک ویژگی مطابقت دارد. نمودار UML مدل زمین در شکل 14 نشان داده شده است .

انواع هندسی مجزای اشیاء Terrain توسط چهار زیر کلاس تعریف می‌شوند: خطوط شکست، شبکه‌های مثلثی (TIN)، نقاط جرمی و شبکه‌ها (رستر). از نظر هندسی، کلاس‌های ISO 19107 یا GML مربوطه این انواع را تعریف می‌کنند: خطوط شکست توسط یک MultiCurve ، TIN‌ها توسط TriangulatedSurfaces ، نقاط جرمی توسط MultiPoint ، و رستر توسط RectifiedGridCoverage .

4. راه حل های پایگاه داده برای PIM

همانطور که در بخش 2 ذکر شدDBMS فضایی در پاسخ به الزامات جدید برای کاربردهای اطلاعات جغرافیایی در سال های اخیر توسعه یافته است. در میان آنها، استفاده از سیستم‌های مدیریت پایگاه داده رابطه‌ای گسترش‌یافته (spatial-RDBMS) برای ذخیره و مدیریت مدل‌های ساختمانی پیچیده، مزایای زیادی را به همراه خواهد داشت. از یک طرف، Spatial-RDBMS از انواع داده‌های مکانی، روش‌های دسترسی مکانی و زبان‌های پرس و جو فضایی پشتیبانی می‌کند، و همچنین ابزارهایی را برای ساختار نمایه‌سازی فضایی کارآمد و تحلیل‌های هندسی و توپولوژیکی فراهم می‌کند. از سوی دیگر، DBMS فضایی نقش مهمی در پل زدن مدل‌سازی هندسی اجسام جغرافیایی ساخته دست بشر و طبیعی دارد. بنابراین، ارائه ی مفاهیم اولیه هندسی مانند نقاط، پاره خط ها، مثلث ها،7 ]. بنابراین، DBMS های فضایی مانند نرم افزار تجاری ORACLE Spatial/Locator و نرم افزار منبع باز PostgreSQL با پسوند PostGIS به دلیل قابلیت های گسترده آنها در مدیریت داده های فضایی سه بعدی ، نقش عمده ای را برای مدل های علم زمین 2D/3D [ 32 ] ایفا می کنند.

راه‌حل مفهومی برای مدیریت مدل‌های داده شی‌گرا مانند CityGML و IFC در فضایی-RDBMS را می‌توان برای حل مشکل نگاشت مدل داده شی‌گرا بر روی یک مدل داده رابطه‌ای انتزاع کرد. قوانین نگاشت زیر در روش طراحی پایگاه داده رابطه ای ما اتخاذ می شود:

یک کلاس باید در یک جدول نگاشت شود. جدول نگاشت شده باید حداقل یک ستون کلید اصلی برای ذخیره شناسه شی داشته باشد که ممکن است به عنوان “ID” شناخته شود و باید در جدول منحصر به فرد باشد. ستون‌های اضافی را نیز می‌توان به جدول نگاشت شده برای ذخیره مقادیر ویژگی فضایی و غیرمکانی اشیاء کلاس مربوطه اضافه کرد.
یک محدودیت کلید خارجی باید در رابطه 1:1 یا 1:N اضافه شود. برای هر نوع رابطه باینری 1:1 یا 1:N، یکی از روابط را انتخاب می کنیم و کلید اصلی یک رابطه دیگر را به عنوان کلید خارجی در رابطه انتخاب شده قرار می دهیم. بهتر است رابطه S را که نشان دهنده شرکت کننده در سمت N از نوع رابطه است، شناسایی کنیم.
یک جدول انجمنی در مورد رابطه M:N باید برای پیوند دادن جداول نگاشت شده از کلاس های مرتبط استفاده شود. برای هر نوع رابطه باینری N:M، یک رابطه جدید برای نمایش این رابطه ایجاد کنید. به عنوان ویژگی های کلید خارجی در رابطه انتخابی، کلیدهای اصلی روابط را که نشان دهنده روابط مشارکت کننده هستند، بگنجانید. ترکیب آنها کلید اصلی انتخاب شده را تشکیل می دهد.
یک محدودیت کلید خارجی یا یک جدول ارتباطی باید برای رابطه ارثی تنظیم شود. رابطه وراثت بین دو کلاس می تواند با استفاده از یک محدودیت کلید خارجی برای پیوند دادن جداول زیر کلاس و سوپرکلاس با پیوستن کلیدهای اصلی آنها پیاده سازی شود یا به جدولی نگاشت شود که همزمان دو کلاس ارثی را نشان می دهد.

با این حال، اگرچه این قوانین نگاشت به نگاشت مدل ساختمان بر روی مدل پایگاه داده رابطه ای اجازه می دهد، اما ممکن است به راحتی به تعداد زیادی جداول پایگاه داده به دلیل وجود اشیاء بسیار ساختمانی (مانند در، پنجره، دال، صفحه، دیوار و غیره) در مدل های ساختمان CityGML و IFC. در همین حال، اشیاء مختلف ممکن است یک لیست مشخصه کاملاً متفاوت داشته باشند و ویژگی‌های وسیع ممکن است تعداد مقادیر تهی داشته باشند. علاوه بر این، این ممکن است منجر به روابط پیوستن زیادی در هنگام درخواست درخواست شود. تجزیه و تحلیل سیستم های پایگاه داده رابطه ای موجود نشان داد که یک طرح پایگاه داده فشرده تر برای پرس و جو و پردازش داده های بزرگ و با ساختار پیچیده بسیار کارآمدتر است تا عملکرد خوب هنگام تعامل با پایگاه داده در یک برنامه بلادرنگ را تسهیل کند [ 33]. برای رسیدن به این هدف، طرح پایگاه داده ما باید از یک فرآیند دستی دقیق با شناسایی و ساده‌سازی کلاس‌ها و نوع داده‌های پیچیده و نگاشت آن‌ها در جدول‌های کمتری با توجه به قابلیت همکاری پایگاه‌داده حاصل شود. با توجه به این نیاز، انواع ویژگی ها به انواع داده های پایگاه داده مربوطه (PostgreSQL) سفارشی می شوند ( جدول 2 را ببینید ).

علاوه بر این، ما مجموعه ای از قوانین نگاشت ریز را پیشنهاد می کنیم:

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

5. مطالعه موردی

به عنوان یک منطقه مورد مطالعه، پردیس UNSW انتخاب شده است. در میان تمام داده‌های موجود، ما بر سه نوع تمرکز کرده‌ایم: GIS (به عنوان مثال، داده‌های مکانی دوبعدی یا سه بعدی)، اطلاعات BIM و حسگرها. ما هیچ شکل پیچیده ای از IFC برای اجرا نداریم زیرا تمام IFC که داریم تکرارهای B هستند. بیشتر داده های GIS عمدتاً به صورت دو بعدی هستند و ما اشیاء سه بعدی را از آن بازسازی می کنیم. Rhinoceros (با ملخ) برای پردازش کل بازسازی استفاده می شود [ 34 ]. ما مدل های BIM (به دست آمده به عنوان فایل IFC) را با استفاده از کتابخانه IFC++ [ 35 ] وارد می کنیم و اطلاعات هندسی، توپولوژیکی و معنایی را با استفاده از CGAL [ 36 ] پردازش می کنیم.]. به عنوان منبع اصلی برای پیش پردازش داده ها، از زمین تولید شده از ابرهای نقطه ای استفاده می شود. بنابراین، داده‌هایی که مدل‌های BIM، پلان‌های دوبعدی، جاده‌ها، مناطق سبز و درختان را نشان می‌دهند به زمین منتقل می‌شوند.

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

علاوه بر این، نرم افزار QGIS می تواند برای تجسم موجودیت ها استفاده شود. این می تواند یک مدل را در سراسر اتصال اینترنت به سرور پایگاه داده باز کند، آن مدل را ویرایش کند و مدل اصلاح شده را در یک فایل مدل در سیستم محلی ذخیره کند یا آن را دوباره در مدل منبع روی سرور ادغام کند. ما دسترسی به پایگاه داده و موارد استفاده از پرس و جو را در مقاله کنفرانس خود [ 37 ] از طریق مجموعه داده های سفارشی نشان داده ایم. بنابراین، آزمایش های پرس و جو مبتنی بر SQL را می توان در [ 37 ] یافت.

5.1. طراحی مفهومی

با توجه به طرح مفهومی کلی برای مدل شهر سه بعدی یکپارچه در مقیاس پردیس در بخش 3.1 ، ما مدل سه بعدی خاص خود را برای پردیس UNSW بر اساس اشیایی که داریم توسعه می دهیم. در شکل 15 ، زیر کلاس های _CampusObject شامل کلاس های موضوعی مختلف مربوط به محیط ساخته شده در محوطه دانشگاه UNSW است که در زیر توسط مدل های داده جداگانه پوشش داده شده است: مدل ساختمان ( _Building )، مدل حسگر ( _Sensor )، مدل حمل و نقل ( جاده )، پوشش گیاهی. مدل ( _Vegetation )، مدل زمین ( Train) و مدل خارجی (به نام _ExternalReference ).

در جزئیات، مدل خارجی اطلاعاتی را از سیستم مدیریت تسهیلات UNSW ARCHIBUS ( https://archibus.unsw.edu.au/ ) دریافت می‌کند که شامل ویژگی‌های فعلی برای طبقات و اتاق‌ها با هدف شناسایی فضاها/میزهای کاری فردی است که بازی می‌کند. به عنوان داده های آماری مربوط به هر اتاق در ساختمان. مدل حسگر شامل دو منبع داده متفاوت است که توسط کلاس های Energy و Air Quality نشان داده شده در نمودار UML به عنوان زیر کلاس _Sensor نشان داده شده است. در میان آنها، انرژی کلاسی است که شامل مصرف گاز و برق هر ساختمان در پردیس UNSW است، در حالی که داده‌های کیفیت هوای هر اتاق از سیستم MyAir می‌آید.https://citydata.be.unsw.edu.au/layers/geonode%3Amyair ). فاصله زمانی برای هر دو سنسور 15 ثانیه است. برای مدل حمل و نقل، فقط زیر کلاس جاده در محوطه دانشگاه UNSW وجود دارد. بنابراین، Superclass حمل و نقل تعریف شده در بخش 3.6 را حذف می کنیم و آن را با کلاس منحصر به فرد Road جایگزین می کنیم . با توجه به مدل گیاهی، ما یک کلاس انتزاعی _Vegetation و دو کلاس خاص Lawn و Tree را به جای نمایش اشیاء خاص در سبک CodeList همانطور که در بخش 3.7 نشان داده شده است، تعریف می کنیم . از نظر مدل زمین، ما اشیاء زمین را در هندسه شبکه های مثلثی (TIN) پردازش می کنیم. بنابراین، زمین کلاس بتنکه حامل هندسه TIN ها است و سه رأس آن در طراحی مفهومی ما ایجاد می شود.

مدل ساختمان یکپارچه پیچیده ترین مدلی است که از داده های GIS و BIM تشکیل شده است. با پیروی از قوانین نگاشت تعریف شده در بخش 3.2 ، یک کلاس انتزاعی _Building اهداکننده ساختمان یا بخش ساختمان از داده های LOD1 CityGML ایجاد می کنیم. _ساختمان ممکن است دارای ویژگی هایی مانند نام ، حداکثر_ارتفاع ، کاربری زمین و غیره باشد. این ساختمان فقط دارای هندسه gml:LOD1MultiSurface است. برای ایجاد ارتباط بین شی ساختمان و داده‌های حسگر انرژی، از طریق نام ساختمان بین آنها ارتباط اضافه می‌کنیم. _Storey تلفیقی از عناصر ساختمانی و فضاها و Space استیک کلاس مشخص با ویژگی های مدل IFC است. به دلیل نداشتن اطلاعات سطح مرزی LOD2 تا LOD4 در مدل CityGML ما، در اینجا ما در آزمایش‌های زیر به سادگی فضا را به عنوان اتاق در نظر می‌گیریم. در اینجا، از طریق نام اتاق پیوندی بین Space و کیفیت هوا اضافه می کنیم. مدل IFC همچنین IfcFurnishingElement را ارائه می دهد که به عنوان تعمیم تمام اشیاء مربوط به مبلمان استفاده می شود، کلاس BuildingFurniture را ایجاد می کنیم و داده ها را در IfcFurnishingElement در آن می ریزیم. برای عناصر ساختمان، شامل سه زیر کلاس است: Wall (از IfcWall )، _Covering (از IfcCovering و IfcRoof )، و_نصب ساختمان . در میان آنها، به عنوان یک کلاس انتزاعی، _BuildingInstallation شامل باقیمانده اشیاء عنصر ساختمان IFC است. علاوه بر این، عناصر باز کننده ( IfcOpeningElement ) به عناصر ساختمان متصل می شوند. در داخل هر عنصر باز، ممکن است چندین عنصر IfcDoor و IfcWindow با ارجاع هندسه آنها از مدل IFC وجود داشته باشد. بنابراین کلاس انتزاعی _Opening را با دو ترکیب Door و Window در طراحی خود ایجاد می کنیم.

5.2. طراحی پایگاه داده رابطه ای

استفاده از فضایی-RDBMS راه حلی پیشرفته برای ذخیره و مدیریت مدل ساختمان پیچیده سه بعدی است، مانند نرم افزار متن باز PostgreSQL با پسوند PostGIS ( https://postgis.net/ ) دارای قابلیت های گسترده ای در مدیریت سه بعدی است. داده های مکانی را پشتیبانی می کند و از انواع هندسه مورد نیاز پشتیبانی می کند و ابزاری برای نمایه سازی فضایی مناسب و همچنین برای تجزیه و تحلیل هندسی و توپولوژیکی فراهم می کند. برای مثال، حجم‌های مدل‌های IFC یا بازسازی‌شده از داده‌های دوبعدی را می‌توان به عنوان یک شیء POLYHEDRALSURFACE نشان داد. هر نوع داده حاوی یک شناسه مرجع مکانی (SRID) برای توصیف سیستم مختصات نیز می باشد. استفاده از POLYHEDRALSURFACE بیش از سایر احتمالات (به عنوان مثال، MULTIPOLYGON Z) امکان استفاده از توابع هندسی بیشتر PostGIS با پسوند SFCGAL را فراهم می کند ( https://www.sfcgal.org/).

مدل دانشگاه UNSW، که در بخش 5.1 در سطح مفهومی توضیح داده شده است، با جداول نشان داده شده در شکل 16 تحقق می یابد . کلاس CityGML خالص Terrain و ویژگی های آن مشخص شده در نمودار UML (ر.ک. شکل 15 ) مستقیماً از جدول TERRAIN و ستون های مربوط به آن نگاشت می شوند. به همین ترتیب، کلاس Road را با جدول ROAD درک می کنیم . برای تحقق اشیاء پوشش گیاهی، دو جدول مجزا ارائه شده است: چمن و درخت . با توجه به لیست ویژگی های متفاوت در دو نوع شیء گیاهی، می توانیم کلاس انتزاعی _Vegetation را نادیده بگیریم.در تحقق ما همانند پوشش گیاهی، تنها یک شی مرجع خارجی در نمودار UML ما وجود دارد، ما فقط باید کلاس Room Property را به جدول ROOMPROPERTY با ستون‌های ویژگی‌های آن تبدیل کنیم. به همین ترتیب، کلاس کیفیت هوا و انرژی را به ترتیب به جدول AIRQUALITY و ENERGY نگاشت می کنیم .

ساختمان پیچیده ترین است. کلاس _Building مستقیماً از جدول BUILDING و ستون های مربوط به آن نگاشت می شود. رابطه با جدول ENERGY با نام کلید اصلی ایجاد می شود . کلاس Space و BuildingFurniture را می توان مستقیماً توسط جدول SPACE و BUILDINGFURNITURE درک کرد و تمام ویژگی های مشخص شده در نمودار UML در ستون های مربوطه ذخیره می شوند. علاوه بر این، رابطه با جدول AIRQUALITY از نام کلید نشات گرفته است . کلاس های UML _Opening ، Door وپنجره با باز کردن میز منفرد محقق می شود . اشیاء در و پنجره با ویژگی Fill_type (‘door’ یا ‘window’) متمایز می شوند. برای تحقق اشیاء عناصر ساختمانی، می‌توانیم همه را در یک جدول BUILDINGELEMENT نگاشت کنیم، زیرا آنها لیست ویژگی‌های یکسانی در مجموعه داده ما دارند. ما اشیاء مختلف را در _BuildingElement بر اساس نوع ویژگی متمایز می کنیم . همچنین می‌توانیم سه جدول WALL ، COVERING و BUIDLINGINSTALLATION برای دسته‌های مختلف عناصر ساختمان ایجاد کنیم. در بخش آزمایشی زیر، یک BUILDINGELEMENT را اتخاذ می کنیماستراتژی کاهش تعداد جداول در پایگاه داده ما.

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

علاوه بر این، داده‌های GIS که یک ساختمان کامل را توصیف می‌کنند، اغلب از هندسه‌های متعددی استفاده می‌کنند که هر کدام بخشی از یک ساختمان را به تصویر می‌کشند. بنابراین، می‌توانیم یک رابطه BUILDING را برای ذخیره ID و NAME ساختمان ارتقا دهیم و به ترتیب از BUILDINGPART برای ذخیره اطلاعات معنایی یک ساختمان استفاده کنیم. یک ستون کلید خارجی building_id را می توان در BUILDINGPART برای نمایش رابطه ترکیب به عنوان قانون نگاشت پیشنهادی در بخش 4 اضافه کرد. به همین ترتیب، برای سرعت بخشیدن به پرس و جوها، می توانیم شناسه ساختمان را به عنوان مرجع کلید خارجی Space و BuildingElement اختصاص دهیم تا رابطه Storeyرا می توان حذف کرد زیرا به عنوان یک رابطه پل در طراحی پایگاه داده فعلی کار می کند. شکل 16 مدل داده های منطقی را برای طراحی پایگاه داده رابطه ای ما نشان می دهد.

6. بحث و نتیجه گیری

در این مقاله، یک راه حل پایگاه داده فضایی سه بعدی رابطه ای برای مدیریت و تجزیه و تحلیل PIM با ترکیب داده های چند منبع ارائه شده است. ما یک مدل داده مفهومی و منطقی کلی از دامنه ساختمان پیشنهاد کردیم. برای بهبود عملکرد مدل ساختمان یکپارچه خود (IBM)، داده‌های محیط ساخته‌شده چند منبع را برای افزایش قدرت معنایی ترکیب کردیم و قوانین نقشه‌برداری کارآمد را برای ساده‌سازی طراحی پایگاه داده رابطه‌ای ایجاد کردیم. مطالعه موردی نشان می‌دهد که مدل ساختمان یکپارچه ما می‌تواند به درک بهتری از محیط ساخته شده دست یابد و این یک رویکرد امیدوارکننده برای کار مدل‌سازی شهر یا مقیاس شهری آینده خواهد بود. محدودیت های رویکرد ما عبارتند از: (1) CityGML و IFC به طور کامل نشان داده نشده اند و IBM باید تغییرات جزئی برای برنامه ها/سناریوهای واقعی مختلف ایجاد کند. (2) تبدیل یا نقشه برداری در بین CityGML، IFC و IBM نقطه شروعی برای ادغام CityGML و IFC در مفهوم است. محدودیت‌های شناسایی‌شده نیز جهت‌های تحقیقاتی آینده ما هستند. به جز موارد استفاده از دسترسی به پایگاه داده و پرس و جو در مقاله کنفرانس ما [37 ] از طریق مجموعه داده های سفارشی شده، در آینده با منابع داده چندگانه مناسب با چندین سطح از جزئیات سروکار خواهیم داشت و سپس PIM را تحت برنامه خاص ایجاد می کنیم. علاوه بر این، در مورد چگونگی تجزیه و تحلیل مدیریت کیفیت و بررسی اعتبار تحت سناریوهای کاربردی چندگانه نیز در کار بعدی ما جالب است.

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

در پیاده سازی فعلی ما فقط از انواع داده های موجود DBMS فضایی استفاده کرده ایم. با این حال، تبدیل CSG، جارو کردن و هندسه پارامتری ارائه شده در مدل های IBM منجر به BRep پیچیده و غیر ضروری می شود. دو جهت جایگزین برای ذخیره سازی فشرده تر را می توان بررسی کرد. یک گزینه سازماندهی هندسه هایی مانند BLOB در پایگاه داده خواهد بود. گزینه دوم معرفی انواع داده های تعریف شده توسط کاربر است که می توانند هندسه تعریف شده ریاضی را حفظ کنند [ 39 ].

اختصارات

در این نسخه از اختصارات زیر استفاده شده است:

BIM	مدلسازی اطلاعات ساختمان
CAD	طراحی به کمک رایانه
DBMS	سامانهی مدیریت پایگاه داده
GIS	سیستم اطلاعات جغرافیایی
GML	زبان نشانه گذاری گرافیکی
IFC	کلاس های بنیاد صنعت
ISO	سازمان بین المللی استاندارد
OGC	کنسرسیوم فضایی باز
PIM	مدل سازی اطلاعات حوزه
SQL	زبان پرس و جو ساختاریافته

پیوست A. مدل ساختمان IFC

از استانداردهای IFC4، مفاهیم مهمی را برای مدل ساختمان شناسایی می کنیم ( شکل A1 ).

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

ضمیمه B. مدل ساختمان CityGML

از استانداردهای CityGML2.0 مفاهیم مهمی را برای مدل ساختمان شناسایی می کنیم ( شکل A2 ).

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

منابع

بیلجکی، اف. استوتر، جی. لدوکس، اچ. زلاتانوا، اس. Çöltekin، A. کاربردهای مدل های شهر سه بعدی: بررسی وضعیت هنر. ISPRS Int. J. Geo-Inf. 2015 ، 4 ، 2842-2889. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
موراتا، M. برنامه 3D-GIS برای برنامه ریزی شهری بر اساس مدل شهر سه بعدی. در مجموعه مقالات بیست و چهارمین کنفرانس بین المللی کاربران سالانه ESRI، سن دیگو، کالیفرنیا، ایالات متحده آمریکا، 9 تا 13 اوت 2004. [ Google Scholar ]
Shiode, N. مدل های شهری سه بعدی: پیشرفت های اخیر در مدل سازی دیجیتال محیط های شهری در سه بعدی. ژئوژورنال 2000 ، 52 ، 263-269. [ Google Scholar ] [ CrossRef ]
فضلی، ف. کوتی، ن. وانگ، ز. زلاتانوا، اس. مهجوبی، ل. بوگوسلاوسکی، پ. زوروویچ، وی. گسترش محیط‌های نقشه‌برداری خیابان باز داخلی به مدل‌های ساختمان سه‌بعدی CityGML قابل کشتی‌رانی: ارزیابی واکنش اضطراری. بین المللی قوس. فتوگرام حسگر از راه دور اسپات. Inf. علمی 2018 ، 42 ، 161-168. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
والنسیاک، جی. استولبرگ، بی. نوبائر، اس. Zipf، A. گسترش زیرساخت‌های داده‌های مکانی سه‌بعدی با عملیات ژئوپردازش – شبیه‌سازی‌های سه بعدی در مدیریت بلایا و تحقیقات زیست‌محیطی. در مجموعه مقالات کنفرانس بین المللی 2009 در سیستم های اطلاعات جغرافیایی پیشرفته و خدمات وب، کانکون، مکزیک، 1 تا 7 فوریه 2009. ص 40-44. [ Google Scholar ]
کروگر، آ. Kolbe، T. تجزیه و تحلیل ساختمان برای برنامه ریزی انرژی شهری با استفاده از شاخص های کلیدی در مدل های شهر سه بعدی مجازی – اطلس انرژی برلین. بین المللی قوس. فتوگرام حسگر از راه دور اسپات. Inf. علمی 2012 ، 39 ، 145-150. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
برونیگ، ام. زلاتانوا، S. تحقیقات پایگاه داده های جغرافیایی سه بعدی: گذشته نگر و جهت های آینده. محاسبه کنید. Geosci. 2011 ، 37 ، 791-803. [ Google Scholar ] [ CrossRef ]
Lo, CP; Yeung, AK مفاهیم و تکنیک های سیستم های اطلاعات جغرافیایی ; Prentice Hall: Upper Saddle River، نیوجرسی، ایالات متحده آمریکا، 2002. [ Google Scholar ]
ازهر، س. خلفان، م. مقصود، تی. مدل سازی اطلاعات ساختمان (BIM): اکنون و فراتر از آن. ساختن. اقتصاد ساختن. 2012 ، 12 ، 15-28. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
نیوتن، پی. پلوم، ج. مارچانت، دی. میچل، جی. Ngo، T. مدل سازی اطلاعات منطقه: یک پلت فرم دیجیتال جدید برای طراحی، ارزیابی و مدیریت یکپارچه محیط ساخته شده. در یکپارچه سازی اطلاعات در محیط های ساخته شده ؛ Routledge: لندن، بریتانیا، 2017; صص 111-132. [ Google Scholar ]
Cai، G. زمینه سازی معنایی پایگاه داده جغرافیایی برای تعامل انسان-GIS. Geoinformatica 2007 ، 11 ، 217-237. [ Google Scholar ] [ CrossRef ]
گروگر، جی. کلبه، تی. ناگل، سی. Häfele، K. OGC زبان نشانه گذاری جغرافیای شهر (CityGML) استاندارد رمزگذاری ; کنسرسیوم فضایی باز: Wayland، MA، ایالات متحده آمریکا، 2012. [ Google Scholar ]
ISO کلاس های بنیاد صنعت (IFC) برای به اشتراک گذاری داده ها در صنایع ساخت و ساز و مدیریت تاسیسات . سازمان بین المللی استانداردسازی: ژنو، سوئیس، 2013. [ Google Scholar ]
Güting، RH مقدمه ای بر سیستم های پایگاه داده فضایی. VLDB J. Int. J. پایگاه داده های بسیار بزرگ 1994 ، 3 ، 357-399. [ Google Scholar ] [ CrossRef ]
تولمر، م. کاستینگ، سی. دیاب، ی. Morand، D. CityGML و IFC: فراتر از LOD. در مجموعه مقالات کنگره بین المللی میراث دیجیتال 2013 (Digital Heritage)، مارسی، فرانسه، 28 اکتبر تا 1 نوامبر 2013. جلد 1، ص 645–648. [ Google Scholar ]
دنگ، ی. چنگ، جی سی. Anumba، C. نقشه برداری بین BIM و 3D GIS در سطوح مختلف جزئیات با استفاده از میانجیگری طرحواره و مقایسه نمونه. خودکار ساختن. 2016 ، 67 ، 1-21. [ Google Scholar ] [ CrossRef ]
لیو، ایکس. وانگ، ایکس. رایت، جی. چنگ، جی. لی، ایکس. لیو، آر. یک بررسی پیشرفته در مورد ادغام مدل سازی اطلاعات ساختمان (BIM) و سیستم اطلاعات جغرافیایی (GIS). ISPRS Int. J. Geo-Inf. 2017 ، 6 ، 53. [ Google Scholar ] [ CrossRef ] [ نسخه سبز ]
غمیسی، پ. راستی، ب. یوکویا، ن. وانگ، کیو. هوفل، بی. بروزون، ال. بوولو، اف. چی، م. اندرس، ک. گلوگوئن، آر. و همکاران ترکیب داده های چندمنبعی و چند زمانی در سنجش از دور. arXiv 2018 , arXiv:1812.08287. [ Google Scholar ]
زو، س. هو، م. ژانگ، ی. Du, Z. تحقیق و تمرین در مدلسازی سه بعدی شهر. ژئو اسپات. Inf. علمی 2009 ، 12 ، 18-24. [ Google Scholar ] [ CrossRef ]
بیلن، آر. Cutting-Decelle، AF; مارینا، او. دی آلمیدا، جی پی؛ کالیونی، ام. فالکت، جی. لدوچ، تی. مترال، سی. مورو، جی. پرت، جی. و همکاران مدل‌های سه بعدی شهر و اطلاعات شهری: مسائل و دیدگاه‌های کنونی-اقدام هزینه اروپایی TU0801 ; EDP Sciences: Les Ulis، فرانسه، 2014. [ Google Scholar ]
ناکاشیما، اچ. آقاجان، ح. آگوستو، JC Handbook of Ambient Intelligence and Smart Environments ; Springer Science & Business Media: Cham, Switzerland, 2009. [ Google Scholar ]
ژانگ، جی. Seet، BC; Lie, T. مدل سازی اطلاعات ساختمان برای محیط های ساخته شده هوشمند. ساختمان ها 2015 ، 5 ، 100-115. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
بلیهولدر، جی. Naumann, F. ادغام داده ها. کامپیوتر ACM. Surv. (CSUR) 2009 , 41 , 1. [ Google Scholar ] [ CrossRef ]
دونگ، جی. ژوانگ، دی. هوانگ، ی. فو، جی. پیشرفت در ترکیب داده های چند حسگر: الگوریتم ها و برنامه ها. Sensors 2009 , 9 , 7771-7784. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
ریگو، پی. شول، ام. Voisard، A. پایگاه های داده فضایی: با کاربرد در GIS ; الزویر: آمستردام، هلند، 2001. [ Google Scholar ]
زلاتانوا، S. هندسه های سه بعدی در DBMS فضایی. در نوآوری در سیستم های اطلاعات جغرافیایی سه بعدی ; Springer: برلین/هایدلبرگ، آلمان، 2006; صص 1-14. [ Google Scholar ]
وانگ، ایکس. عشق، PE; کیم، ام جی؛ پارک، CS; بخوان، CP; Hou, L. چارچوبی مفهومی برای ادغام مدل سازی اطلاعات ساختمان با واقعیت افزوده. خودکار ساختن. 2013 ، 34 ، 37-44. [ Google Scholar ] [ CrossRef ]
ناگل، سی. استدلر، ا. Kolbe، TH الزامات مفهومی برای بازسازی خودکار مدل‌های اطلاعات ساختمان از مدل‌های سه بعدی تفسیر نشده. در مجموعه مقالات آهنگ آکادمیک کنفرانس Geoweb 2009-3D Cityscapes, Vancouver, BC, Canada, 27-31 ژوئیه 2009. [ Google Scholar ]
المکاوی، م. اوستمن، ا. حجازی، اول. یک مدل ساختمان واحد برای GIS شهری سه بعدی. ISPRS Int. J. Geo-Inf. 2012 ، 1 ، 120-145. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
چنگ، جی سی. دنگ، ی. Anumba، C. نقشه برداری طرحواره BIM و طرحواره سه بعدی GIS به صورت نیمه خودکار با استفاده از تکنیک های زبانی و متن کاوی. J. Inf. تکنولوژی ساختن. 2015 ، 20 ، 193-212. [ Google Scholar ]
کانگ، TW; Hong, CH مطالعه ای بر روی معماری نرم افزار برای یکپارچه سازی داده های مدیریت تسهیلات مبتنی بر BIM/GIS. خودکار ساختن. 2015 ، 54 ، 25-38. [ Google Scholar ] [ CrossRef ]
عقوب، ع. کونده، اف. کادا، م. پتانسیل پایگاه‌های اطلاعاتی گراف در ارائه و غنی‌سازی ژئوداده استاندارد شده. Tagungsband der 2016 ، 36 ، 1-9. [ Google Scholar ]
استدلر، ا. ناگل، سی. کونیگ، جی. Kolbe، TH ایجاد پایداری قابلیت همکاری: یک پایگاه داده جغرافیایی سه بعدی مبتنی بر CityGML. در علوم ژئو اطلاعات سه بعدی ; Springer: برلین/هایدلبرگ، آلمان، 2009; صص 175-192. [ Google Scholar ]
رابرت مک نیل و همکاران Rhinoceros: گرافیک کامپیوتری سه بعدی و برنامه طراحی به کمک کامپیوتر). 2019. در دسترس آنلاین: https://www.rhino3d.com/ (در 27 مه 2019 قابل دسترسی است).
IFC++. IFC++: اجرای IFC منبع باز برای C++). 2019. در دسترس آنلاین: https://ifcquery.com/ (در 27 مه 2019 قابل دسترسی است).
پروژه CGAL راهنمای کاربر و مرجع CGAL ، ویرایش چهارم. هیئت تحریریه CGAL: تل آویو، اسرائیل، 2019. [ Google Scholar ]
لی، دبلیو. زلاتانوا، اس. یان، جی. دیاکیت، ا. الکساندروف، ام. یک راه حل پایگاه داده جغرافیایی برای مدیریت و تحلیل مدل ساختمان با ترکیب داده های چند منبع. بین المللی قوس. فتوگرام حسگر از راه دور اسپات. Inf. علمی 2019 ، 42 ، 55-63. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
امگارد، ال. Zlatanova، S. جایگزین های پیاده سازی برای یک مدل اطلاعات یکپارچه سه بعدی. در پیشرفت در سیستم های اطلاعات جغرافیایی سه بعدی ; Springer: برلین/هایدلبرگ، آلمان، 2008; صص 313-329. [ Google Scholar ]
زلاتانوا، اس. پو، اس. منحنی ها و سطوح Freeform Bronsvoort، W. در DBMS-گامی رو به جلو در یکپارچه سازی داده های مکانی. در مجموعه مقالات کمیسیون ISPRS IV سمپوزیوم در مورد “پایگاه های اطلاعات مکانی برای توسعه پایدار، گوا، هند، 27-30 سپتامبر 2006; ص 27-30. [ Google Scholar ]