در عمل، داده‌های مدیریت راه معمولاً به شکل‌های مکانی دوبعدی (2 بعدی) مدیریت می‌شوند. با این حال، داده‌های مدیریت زیرساخت جاده‌ای مبتنی بر سیستم اطلاعات جغرافیایی دوبعدی (GIS) دارای محدودیت‌هایی در نمایش جاده‌های پیچیده، مانند مبادلات، پل‌ها و تونل‌ها هستند. به این ترتیب، داده های مدیریت شبکه جاده ای پیچیده و بزرگ را نمی توان به اندازه کافی در یک فرم مبتنی بر GIS دو بعدی مدیریت کرد. این مطالعه استفاده از استاندارد LandInfra برای مدیریت زیرساخت جاده‌ای در کره را با توجه به تمرکز آن بر زمین و تأسیسات زیرساختی مهندسی عمران مورد بحث قرار می‌دهد. برای تسهیل انتقال از GIS دو بعدی به سه بعدی، مدل‌های مدیریت راه موجود از روسازی جاده و اطلاعات ثبت جاده را تحلیل کردیم و نمودارهای کلاس زبان مدل‌سازی یکپارچه (UML) را ایجاد کردیم که این مدل‌ها را به تصویر می‌کشد. سپس، کلاس های مدیریت راه موجود و کلاس های LandInfra نقشه برداری شدند. بر اساس نتایج، ما یک مدل مدیریت راه را بر اساس بخش‌های تسهیلات، تراز و جاده LandInfra پیشنهاد می‌کنیم. برای اجرای آن، چندین کلاس از مدل داده پیشنهادی با استفاده از ورودی داده های دنیای واقعی در InfraGML کدگذاری شدند. روی هم رفته، این مطالعه نشان می‌دهد که چگونه استاندارد LandInfra را می‌توان در زمینه مدیریت زیرساخت‌های جاده‌ای در کره گسترش داد و اعمال کرد و از انتقال از یک مدل ۲ بعدی به یک مدل مبتنی بر GIS سه بعدی پشتیبانی کرد.

کلید واژه ها:

جاده ; بزرگراه ؛ مدیریت زیرساخت جاده ای ; LandInfra ; InfraGML ; GIS سه بعدی

1. مقدمه

1.1. اطلاعات جغرافیایی در مدیریت راه

جاده ها سیستم های حمل و نقل را به هم متصل می کنند و کیفیت زندگی و توسعه اقتصادی را تحت تأثیر قرار می دهند، علاوه بر این که یک بازیگر امیدوارکننده در افزایش پایداری در سطح جهانی هستند [ 1 ]. به عنوان یکی از اجزای اصلی شبکه های حمل و نقل، کیفیت جاده ها بر زندگی روزمره و بهره وری کاربران آن از نظر زمان و هزینه تأثیر می گذارد [ 2 ]. با توجه به اهمیت شبکه راه ها، فراهم آوردن شرایط مناسب برای تردد جاده ها و همچنین نگهداری و مدیریت راه ها ضروری است. زیرساخت‌های جاده‌ای به نگهداری و مدیریت مؤثر و به موقع نیاز دارند تا عمر مفید آن در صورت امکان افزایش یابد [ 2]. زیرساخت راه شامل تمام دارایی‌های فیزیکی جاده، از جمله کلیه امکانات جاده‌ای مرتبط و کارهای ژئوتکنیکی، زه‌کشی، و سازه‌های راه (مانند پل‌ها و تونل‌ها) می‌شود [ 3 ]. نمونه ای از تسهیلات جاده ای معمولی (یعنی دارایی های فیزیکی) به عنوان نمای مقطعی در شکل 1 ارائه شده است .
با این حال، مدیریت و نگهداری جاده‌ها و بزرگراه‌ها به داده‌های قابل توجهی برای تصمیم‌گیری در رابطه با تعمیرات جاده‌ها و همچنین نظارت و ارزیابی وضعیت جاده‌ها، اولویت‌بندی کار جاده‌ای و برآورد بودجه‌های مربوطه نیاز دارد. سایر فعالیت های تعمیر و نگهداری جاده شامل برف روبی، تعمیرات جاده، مدیریت نقطه عطف و تعویض مبلمان جاده است [ 4 ]. در حال حاضر، اطلاعات مربوط به مدیریت و نگهداری راه ها به طور کلی دیجیتالی شده و در یک فرم مبتنی بر GIS در یک پایگاه داده، به نام سیستم مدیریت راه، برای استفاده در نگهداری و مدیریت روسازی جاده ها ذخیره می شود [ 5 ، 6 ، 7 ]. دارایی های جاده ای (رجیستر جاده) 8 ، 9،10 ،10]، و سیستم های مدیریت یکپارچه راه [ 11 ، 12 ، 13 ].
اکثر داده‌های مدیریت راه در این سیستم‌ها در حال حاضر به صورت دو بعدی (2 بعدی) مدیریت می‌شوند. با این حال، داده‌های مدیریت زیرساخت جاده‌ای مبتنی بر GIS دوبعدی در توانایی آنها برای نمایش اطلاعات دارایی‌های جاده‌ای پیچیده، از جمله مبادلات، پل‌ها، تونل‌ها، زیرگذرها، و روگذرها، در میان دیگر امکانات جاده‌ای و کنار جاده‌ای محدود هستند [ 15 ، 16 ]. علاوه بر این، در چارچوب مدیریت شبکه راه، که بخشی از مدیریت زیرساخت راه را تشکیل می‌دهد، نشان‌دهنده شبکه‌های جاده‌ای پیچیده و موجودی‌ها و کاربردهای سیستم‌های حمل‌ونقل هوشمند، تحلیل جریان ترافیک محور محور به یک مدل داده‌های جغرافیایی چند بعدی نیاز دارد [ 17 ، 18 ].]. از این نظر، اطلاعات جاده مبتنی بر GIS سه بعدی نه تنها می‌تواند پیچیدگی دارایی‌های جاده‌ای را بهتر نشان دهد، بلکه می‌تواند شیوه‌های مدیریت راه را با امکان حسابداری چرخه عمر زیرساخت‌ها و مدل‌های شهر بهبود بخشد [ 4 ، 15 ].
چندین مطالعه کاربرد سیستم اطلاعات جغرافیایی سه بعدی را در مدیریت راه بررسی کرده اند. به عنوان مثال، الزامات کاربر برای موجودی‌های جاده‌ای سه بعدی [ 15 ] و اطلاعات دقیق در مورد دارایی‌های جاده‌ای مختلف، مانند جاده‌ها و تقاطع‌ها، اخیراً در ماژول حمل‌ونقل CityGML بر اساس v2.0 [ 4 ] گنجانده شده است. CityGML یک استاندارد داده باز است که یک مدل مفهومی و قالب مبادله را برای نمایش، ذخیره سازی و تبادل مدل های شهری سه بعدی مجازی تعریف می کند [ 19 ]. CityGML در بسیاری از کاربردها، به ویژه CityGML در سطح جزئیات (LoD) 2، هنگام نمایش فضای ترافیک جاده ای سه بعدی [ 20 ]، و همچنین توصیف فضاهای جاده استفاده می شود [ 21 ، 22 ]] و دارایی‌های جاده‌ای مانند پل‌ها، تونل‌ها و اثاثیه شهری (به عنوان مثال، علائم ایمنی و ترافیک، ایستگاه‌های اتوبوس و چراغ‌های خیابان)، به تفصیل [ 23 ].
علاوه بر CityGML، استانداردهای دیگری نیز در رابطه با ارائه و تبادل اطلاعات جاده و حمل و نقل بسته به هدف وجود دارد. اینها شامل زمین و زیرساخت (LandInfra)، زیرساخت برای اطلاعات فضایی در اروپا (INSPIRE)، نقشه خیابان باز (OSM)، کلاس‌های بنیاد صنعت (IFC)، فایل‌های داده جغرافیایی (GDF)، OpenDrive، RoadXML، و Austroads می‌شوند. تعدادی از مطالعات این استانداردها را با بررسی و مقایسه آنها ارزیابی کرده اند [ 4 ، 21 ، 22 ، 24 ، 25 ، 26 ، 27 ، 28 .]. اهداف این استانداردها متفاوت است و می توان آنها را به شرح زیر خلاصه کرد: OpenDrive، GDF، و RoadXML برای برنامه های خودرو استفاده می شود. INSPIRE، OSM و CityGML برای مدل‌سازی دیجیتال شهری استفاده می‌شوند. LandInfra و IFC برای مهندسی عمران استفاده می شوند [ 22 ]. و Austroads یک استاندارد داده برای مدیریت راه و فعالیت های سرمایه گذاری در استرالیا و نیوزیلند است [ 26 ].
اگرچه استاندارد LandInfra یک استاندارد نسبتاً جدید است و InfraGML هیچ پشتیبانی صریح از پیاده سازی نرم افزاری ندارد، این استاندارد اغلب در عمل مورد استفاده قرار نمی گیرد [ 10 ، 22 ، 29 ]. چندین مطالعه در مورد کاربردهای واقعی بالقوه LandInfra به طور کلی یا جاده ها به طور خاص بحث کرده اند. اینها شامل پیاده سازی InfraGML با IFC Alignment برای تأیید انتقال اطلاعات بین سیستم ها/نرم افزارهای مختلف است [ 30 ]. بررسی کاربرد LandInfra برای تبادل اطلاعات دارایی جاده [ 25 ]؛ توسعه پسوند دامنه برنامه CityGML برای LandInfra [ 29]؛ ادغام استانداردهای داده مانند CityGML، IFC، و مدل اطلاعات ساختمان (BIM)-GIS با استفاده از LandInfra برای ارائه قابلیت همکاری [ 31 ، 32 ، 33 ]. بررسی کاربرد LandInfra برای مدل‌سازی فضای خیابان [ 21 ، 22 ]؛ و زیرساخت های حمل و نقل [ 24 ]. اگرچه مطالعات دیگر [ 11 ، 14 ] رویکردهای دقیقی را برای اعمال LandInfra در سیستم مدیریت راه محلی برای موارد خاص ارائه کرده اند، استاندارد LandInfra به طور گسترده در عمل استفاده نشده است.
در این مطالعه، یک مدل داده مفهومی برای مدیریت زیرساخت راه با استفاده از استاندارد LandInfra در یک بافت محلی در کره در زمینه اجرای مدیریت سه بعدی زمین فضایی جاده با در نظر گرفتن تمرکز این استاندارد بر روی زمین و تاسیسات زیرساختی مهندسی عمران و آن مورد بحث قرار گرفت. پتانسیل بیشتر در بخش زیر مروری بر استاندارد LandInfra برای مدیریت زیرساخت جاده ای ارائه شده است.

1.2. استاندارد LandInfra برای مدیریت زیرساخت جاده ای

کنسرسیوم فضایی باز (OGC) برای اولین بار در سال 2016 استاندارد باز بین المللی مدل مفهومی LandInfra را توسعه داد [ 34 ]. استاندارد LandInfra بر اساس زیر مجموعه ای از عملکرد LandXML [ 34 ] است. LandXML یک فرمت داده باز مبتنی بر XML است که برای ذخیره داده های اندازه گیری مهندسی عمران و بررسی در حوزه های زمین و حمل و نقل استفاده می شود [ 35 ]. مدل مفهومی LandInfra بر روی یک زبان مدلسازی یکپارچه (UML) به تصویر کشیده شده و در استاندارد رمزگذاری InfraGML پیاده سازی شده است.
طبقات مورد نیاز LandInfra شامل LandInfra، Facility، Project، Alignment، Road، RoadCrossSection، Railway، Survey، Equipment، Observations، Survey Results، LandFeature، LandDivision و Condominium است. این مطالعه به طور انحصاری کلاس‌های نیازمندی LandInfra، Facility، Alignment و Road را بررسی می‌کند، زیرا موضوع برنامه خاص جاده‌ها است. در این میان، LandInfra اصلی و تنها کلاس اجباری است. این کلاس حاوی اطلاعاتی در مورد مجموعه داده‌های تمام طبقات نیازمندی، امکانات شامل ساختمان‌ها، کارهای مهندسی عمران و سایت‌های مرتبط با آن‌ها است. با این حال، Alignment به عنوان یک عنصر موقعیت یابی استفاده می شود و یک سیستم مرجع خطی برای عناصر فیزیکی ارائه می دهد، در حالی که Road برای نمایش عناصر جاده به صورت سه بعدی استفاده می شود.
برای پشتیبانی از پیاده‌سازی LandInfra، InfraGML را می‌توان به هشت بخش تقسیم کرد: LandInfra Core، LandFeatures، امکانات و پروژه‌ها، ترازها، جاده‌ها، راه‌آهن‌ها، Survey و LandDivision. بخش های مختلف InfraGML و ارتباط آنها در شکل 2 نشان داده شده است. قسمت چهارم Road است و برای پشتیبانی از آن، یک برنامه باید از InfraGML Core (قسمت 0)، LandFeature (قسمت 1) و Facility (قسمت 2) پشتیبانی کند. علاوه بر این، ممکن است از کلاس الزامات Alignment (قسمت 3) پشتیبانی کند. هر یک از این قسمت ها در قسمت های InfraGML مربوطه پیاده سازی می شوند.
این مطالعه بر اساس یافته های مطالعات قبلی است [ 10 ، 13]، با هدف توسعه یک مدل داده مفهومی بر اساس استاندارد LandInfra برای مدیریت زیرساخت جاده در کره به منظور تسهیل پشتیبانی از مدیریت جاده توسط اطلاعات جغرافیایی سه بعدی و همچنین بررسی کاربردهای بالقوه بیشتر LandInfra. برای دستیابی به این هدف، توسعه مدل داده مبتنی بر LandInfra از دو منظر مورد بررسی قرار گرفت: (1) استفاده از استاندارد به عنوان اهرمی برای بهبود مدل مدیریت جاده مبتنی بر GIS دو بعدی به اطلاعات مکانی 3 بعدی در دنیای واقعی- مدل پشتیبانی شده؛ (2) تعریف یک مدل داده مفهومی استاندارد مفهومی مستقل از پلت فرم برای تسهیل تبادل اطلاعات جاده و قابلیت همکاری آن بین سایر پلت فرم ها، پروژه های زیرساختی و استانداردها، و همچنین ورودی مفید برای اجرای احتمالی آن در شهرهای هوشمند و برنامه های کاربردی دوقلوی دیجیتال. . بنابراین، هدف کلی تحقیق برای پاسخ به سؤالات زیر در زمینه فعال کردن مدیریت سه بعدی زمین فضایی جاده هدایت شد: (1) چگونه باید استاندارد LandInfra برای مدل مدیریت جاده کره گسترش یابد؟ (2) کدام کلاس های مدل مدیریت جاده کره ای را می توان در LandInfra ترسیم کرد؟ (3) چگونه می توان مدل خاص کشور مبتنی بر LandInfra را با استفاده از استاندارد رمزگذاری InfraGML کدگذاری کرد؟».
ادامه این مقاله به شرح زیر سازماندهی شده است. بخش 2 روش شناسی را توصیف می کند، که در آن ما یک نمودار کلاس UML از مدل مدیریت زیرساخت جاده برای بزرگراه ملی در کره را تحلیل و ارائه می کنیم. علاوه بر این، برای توسعه مدل داده های مفهومی مبتنی بر LandInfra، نقشه برداری بین LandInfra و مدل مدیریت جاده انجام شد. بخش 3 نتایج مطالعه را ارائه می کند که ایجاد مدل داده مدیریت زیرساخت جاده مبتنی بر LandInfra را با استفاده از نمودار کلاس UML توصیف می کند. برخی از نمونه ها با استفاده از استاندارد رمزگذاری InfraGML ایجاد شدند. در نهایت، در بخش 4 ، نتیجه‌گیری، محدودیت‌ها و دیدگاه‌های آتی مطالعه مورد بحث قرار می‌گیرد.

2. مواد و روشها

در این بخش روش شناسی مورد استفاده در پژوهش حاضر شرح داده می شود. ابتدا، ما یک مدل مدیریت جاده برای بکارگیری استاندارد LandInfra را مورد بحث قرار می دهیم. به طور خاص، ما یک مدل مدیریت راه را برای سیستم مدیریت بزرگراه ملی در کره در نظر می گیریم [ 12 ]. دامنه ما به سیستم های مدیریت راه روسازی و ثبت جاده ها محدود شد. برای دومی، ما داده های در دسترس عموم را به دست آوردیم و استفاده کردیم.
مدل داده ای از این سیستم ها توسط نمودار رابطه موجودیت (ERD) به زبان کره ای [ 12 ] ارائه شده است. مقایسه و مدل‌سازی مدل مدیریت جاده با کلاس‌های نیازمندی LandInfra نیازمند تبدیل ERD به نمودار کلاس UML بود. پس از ایجاد نمودارهای UML، کلاس های مدیریت جاده مربوطه را به LandInfra نگاشت کردیم. یک مدل داده مدیریت زیرساخت راه بر اساس همتایان LandInfra طراحی و پیشنهاد شد. برای پیاده سازی، چندین کلاس از مدل های پیشنهادی با استفاده از استاندارد رمزگذاری InfraGML کدگذاری شدند.
همانطور که در بخش 2.1 توضیح داده شد، تجزیه و تحلیل سیستم های مدیریت بزرگراه، از جمله روسازی جاده ها و ثبت جاده ها، انجام شد، در حالی که نتایج نقشه برداری سیستم های مدیریت راه و LandInfra در بخش 2.2 مورد بحث قرار گرفته است.

2.1. سیستم مدیریت بزرگراه (مدل) در کره

به طور کلی، چهار مرحله در چرخه عمر دارایی های راه وجود دارد: برنامه ریزی، ساخت، بهره برداری و نگهداری [ 37 ]. اکثر مطالعات تحقیقاتی در این زمینه در مورد بهره برداری و مدیریت دارایی های مرتبط با جاده بحث کرده اند، زیرا اطلاعات مربوط به زیرساخت های جاده نقش مهمی در تصمیم گیری بهتر ایفا می کند [ 38 ]. اطلاعات سیستم مدیریت بزرگراه برای مدیریت راه، بهره برداری و نگهداری به طور یکسان استفاده می شود.
در کره، از سال 2020، بزرگراه ملی تقریباً 14098 کیلومتر طول دارد و دارای 78 مسیر است [ 39 ]. نمایشی از شبکه بزرگراه ملی در شکل 3 الف ارائه شده است. برای مدیریت جاده‌ها و حفظ شرایط خوب، سیستم‌های نگهداری و مدیریت راه‌ها در قانون جاده کره معرفی شدند که عملکرد آن امکان مدیریت سیستماتیک و علمی امکانات اصلی جاده‌ها را فراهم می‌کند [ 40 ].
مفاهیم اصلی سیستم های نگهداری و مدیریت راه، شامل سیستم مدیریت بزرگراه (HMS)، سیستم مدیریت روسازی (PMS)، سیستم مدیریت شیب برش (CSMS)، سیستم مدیریت پل و تونل (BTMS)، سیستم مدیریت علائم جاده (RSMS) ، سیستم نظارت بر ترافیک (TMS)، سیستم مدیریت برف زدایی جاده (RSRMS)، سیستم گزارش مشکلات جاده (RPRS)، سیستم اشغال و دسترسی جاده (ROAS)، سیستم اطلاعات آمار و نگهداری جاده (RSMIS) و سیستم اطلاعات ثبت جاده کره (KRRIS)، که در حال حاضر در حال بهره برداری هستند، در شکل 3 ب نشان داده شده است. در میان این سیستم ها، HMS از سال 2003 برای مدیریت بزرگراه های ملی برای ادغام سایر سیستم ها توسعه یافته و مورد بهره برداری قرار گرفته است. 13 ].]. HMS برای اولین بار برای ارائه اطلاعات جغرافیایی در زیرساخت‌های جاده‌ای، از جمله روسازی جاده، پل‌ها، تونل‌ها، شیب‌های بریده جاده، علائم جاده‌ای، حجم ترافیک و ثبت جاده‌ها (به عنوان مثال، نقشه‌ها و طراحی هندسی) معرفی شد. سیستم‌های مدیریت راه و سیستم‌های موضوعی کاربردی ما در شکل 3 ب نشان داده شده‌اند (سیستم‌های روسازی راه و ثبت جاده به رنگ سبز هستند).

2.1.1. تجزیه و تحلیل سیستم مدیریت روسازی

از سال 1997، سیستم مدیریت روسازی برای اطمینان از تعمیر و نگهداری کارآمد راه ها، از جمله مدیریت وضعیت بزرگراه های ملی از طریق مسیر، انجام بررسی روسازی و تجزیه و تحلیل بخش های جاده، و انتخاب بخش های تعمیر و نگهداری (شامل روش ها و هزینه های تعمیر) در حال بهره برداری است [ 40 ]. . بر اساس تجزیه و تحلیل شرایط روسازی، مقاطع دارای ترک یا تغییر شکل انتخاب شده و با استفاده از روش تعمیر بهینه، در چارچوب محدودیت های بودجه ای نگهداری می شوند [ 41 ]. داده هایی که بر روی سیستم اطلاعات روسازی راه اجرا می شوند از طریق بررسی و تحلیل روسازی در میدان [ 13 ] جمع آوری می شوند که به موجب آن اطلاعات به دست آمده شامل چندین کلاس است. شکل 4نمودار کلاس UML را برای اطلاعات مدیریت روسازی نشان می دهد.
در این مطالعه چندین کلاس PMS شامل بخش بررسی روسازی، بخش تحلیل روسازی، بخش مورد نیاز بررسی، تاریخچه بازسازی و روش‌ها با توجه به لزوم مدل‌سازی در LandInfra حذف شدند. علاوه بر این، نام چندین کلاس را برای بهبود خوانایی اصلاح کردیم. کلاس‌های UML روسازی با ویژگی‌هایی مانند شناسه جاده، فاصله (فاصله) و طول در جدول 1 فهرست شده‌اند.
PMS_ROUTE_GENERAL کلاس اصلی است که نشان دهنده اطلاعات اساسی بزرگراه های سراسری است، از جمله جهت جاده، استان (موقعیت)، تعداد خطوط، عرض خط، تاریخ ساخت و زمان اولین آسفالت جاده. کد PAVEMENT نشان می دهد که آیا یک جاده برای اولین بار آسفالت شده است یا دوباره آسفالت شده است. کلاس PMS_ROUTE_GENERAL می تواند صفر یا بیشتر (0..*) کلاس PMS_EVENT داشته باشد که نام پل، طول، خطوط و مرز اداری را توصیف می کند.
کلاس‌های PMS_EVENT_CODE و PMS_REHAB_CODE می‌توانند کلاس‌های PMS_EVENT صفر یا بیشتر داشته باشند. PMS_EVENT_CODE رویدادها را توصیف می‌کند و دارای فهرست کد EVENT_DESC است که نشان می‌دهد یک رویداد یک پل، مرز اداری، بزرگراه، بزرگراه یا یک جاده محلی است. PMS_REHAB_CODE ویژگی‌های مربوط به بازسازی جاده را نشان می‌دهد و دارای فهرست کد REHAB_DESC است، که نشان‌دهنده نوع تصفیه انجام‌شده در سطوح جاده‌هایی با خطوط متعدد (مثلاً 4 خط و وصله‌سازی جاده، 4 خط و عملیات سطحی یا 2 خط و روکش مجدد و 2 است. خطوط و سنگفرش اول).
کلاس PMS_ROUTE_GENERAL می تواند صفر یا بیشتر کلاس PMS_TRF_VOL داشته باشد که حاوی اطلاعاتی در مورد حجم ترافیک در یک مسیر یا جاده خاص است. کلاس PMS_TRF_VOL دارای ویژگی های شناسه نقطه مشاهده حجم ترافیک، سال بررسی ترافیک، و میانگین کل ترافیک روزانه (ADT) برای وسایل نقلیه سبک، اتوبوس ها و کامیون ها است.
کلاس‌های PMS_ROUTE_CODE، PMS_PR_CODE، و PMS_MCO_CODE می‌توانند کلاس‌های PMS_ROUTE_GENERAL صفر یا بیشتر داشته باشند. PMS_ROUTE_GENERAL باید یک کلاس PMS_ROUTE_CODE، PMS_PR_CODE یا PMS_MCO_CODE داشته باشد و بالعکس.
PMS_ROUTE_CODE شناسه جاده و کد جاده را به عنوان لیست ROUTE_CODE توصیف می کند که شامل 78 مسیر بزرگراه های ملی است. PMS_PR_CODE اطلاعاتی در مورد استانی که یک جاده خاص به آن تعلق دارد ارائه می‌کند و دارای یک کد PR_CODE است که نام استان‌های کره را ارائه می‌کند که بر این اساس کدگذاری می‌شوند. PMS_MCO_CODE دفتر مدیریت راه را با استفاده از فهرست کد MCO_CODE توصیف می کند، که در آن دفاتر هر منطقه و/یا استان با نام رمز مربوطه فهرست شده اند.
کلاس PMS_ROUTE_GENERAL شامل یک یا چند (1..*) کلاس PMS_ASP_STRUC، PMS_CON_STRUC، و PMS_PAV_SURV است. کلاس‌های PMS_ASP_STRUC، PMS_CON_STRUC، PMS_PAV_SURV، PMS_TRF_VOL، و PMS_EVENT باید یک کلاس PMS_ROUTE_GENERAL داشته باشند و بالعکس.
کلاس‌های PMS_ASP_STRUC، PMS_CON_STRUC، و PMS_PAV_SURV کلاس‌های اصلی اطلاعات روسازی هستند که اساساً انواع و لایه‌های روسازی و اطلاعات وضعیت روسازی را توصیف می‌کنند. به طور خاص، PMS_ASP_STRUC ساختار آسفالت روسازی را توصیف می کند و شامل ویژگی هایی مانند ضخامت هر لایه (به عنوان مثال، آسفالت، قیری، شن)، تعداد خطوط و عرض خط است. PMS_CON_STRUC اطلاعاتی در مورد ساختار بتنی روسازی، از جمله ویژگی های ضخامت هر لایه (به عنوان مثال، دال، پایه، زیرپایه)، تعداد خطوط و عرض خط ارائه می دهد. هر دوی این کلاس ها را می توان به یک کد لیست PAVEMENT نسبت داد، که نشان می دهد که آیا آن روسازی برای اولین بار آسفالت شده است یا خیر (بازسازی شده). کلاس PMS_PAV_SURV برای ارائه اطلاعات وضعیت بررسی روسازی جاده استفاده می‌شود که شامل ویژگی‌های مربوط به آسیب و زوال جاده، مانند انواع شیار، انواع ترک، شاخص بین‌المللی زبری (IRI) و مقاومت در برابر لغزش است. یک نمایش شماتیک از سازه روسازی در به تصویر کشیده شده استشکل 5 .
در بخش 2.1.1 ، مدل داده PMS در کره را به تفصیل مورد بحث قرار دادیم. ما کلاس‌های اصلی روسازی جاده‌ها را با فهرست کدهای مربوطه برای مدل‌سازی بیشتر با استاندارد LandInfra شناسایی کردیم. از آنجایی که کلاس های اصلی اطلاعات روسازی، کلاس های مربوط به لایه روسازی PMS_ASP_STRUC و PMS_CON_STRUC هستند، ما یک تصویر ساده برای کمک به درک ارائه کرده ایم. علاوه بر این، کلاس‌های اطلاعات روسازی فوق‌الذکر نقشه‌برداری و با کلاس‌های LandInfra مقایسه شدند تا امکان گسترش احتمالی استاندارد برای مدل مدیریت جاده کره‌ای روسازی در زمینه تسهیل اطلاعات جغرافیایی جاده سه بعدی فراهم شود.
2.1.2. تجزیه و تحلیل سیستم اطلاعات ثبت راهها
ثبت جاده یک رکورد رسمی از جاده‌ها، امکانات کنار جاده‌ای و/یا دارایی‌ها است. نگهداری آن رسماً در ماده 24 قانون اجرای ماده 56 قانون جاده کره ذکر شده است. اطلاعات مربوط به ثبت جاده در سیستم اطلاعات ثبت جاده کره (KRRIS) مدیریت و نگهداری می شود که به صورت عمومی در دسترس نیست.
اطلاعات ثبت جاده را می توان به شش نوع اصلی گروه بندی کرد: تاسیسات اصلی (مانند پل ها و تونل ها)، هندسه راه (مانند پیچ ​​های جاده و شیب های طولی)، ژئوتکنیک و زهکشی (مانند ناودان ها و دیوارهای حائل)، تاسیسات ایمنی (به عنوان مثال، نوارهای میانی و حفاظ ها)، امکانات اضافی (مثلاً تأسیسات و علائم زیرزمینی)، و موارد دیگر (به عنوان مثال، استفاده از زمین و جاده های پرداختی) [ 9 ]. شکل 6 یک نمای کلی از ثبت جاده ها را ارائه می دهد که از 44 نوع شیء ثبتی (طبقه ها) تشکیل شده است.
با این حال، به دلیل اطلاعات ارائه شده توسط گزارش، همه انواع کلاس های ثبت جاده های ذکر شده در این مطالعه مورد استفاده قرار نگرفتند [ 13 ]. به جای آن، اطلاعات ثبت جاده شامل 21 کلاس و 17 کد لیست استفاده شد. نمودارهای کلاس UML و کد لیست ها به ترتیب در شکل 7 و شکل 8 ارائه شده است. جدول 2 شرح مختصری از این کلاس ها و ویژگی های داده های مکانی آنها را ارائه می دهد.
ثبت جاده اصلی شامل کلاس‌های MROAD، REALNTH، LANDUSE، DETOUR_ROAD، SIDE، STONE، XPOINT، WALL، DEFENCE، BOX_PIPE، SIGN، NORI، PAY_ROAD، DIP_EQP، DRAWING، SLOPE، و ROAD_AREA است. کلاس های ثبت جاده مربوط به سازه راه BRIDGE_REGISTER، BRIDGE، STR_DWG، و TUNNEL به طور جداگانه در شکل 9 نشان داده شده است.
کلاس MROAD شامل ویژگی هایی است که با اطلاعات عمومی و اساسی ثبت جاده مرتبط است. MROAD از نظر فضایی جاده ها را به عنوان یک خط مرکزی نشان می دهد، با ویژگی هایی مانند اطلاعات بخش جاده مربوطه در مورد طول بخش و اطلاعات پل ها، تونل ها، کاربری زمین و هندسه راه. علاوه بر این، همه کلاس ها شامل ویژگی های زیر هستند: دفتر مدیریت راه، شماره راه، شماره بخش، محل شروع بخش بر حسب کیلومتر (مرجع خطی)، و جهت جاده، (به عنوان مثال، به سمت بالا یا پایین). کلاس MROAD با یک یا چند کلاس ثبت جاده مرتبط است.
بقیه طبقات را می توان به اشیاء ثبت جاده (دارایی) طبقه بندی کرد، همانطور که در شکل 6 نشان داده شده است : BRIDGE و TUNNEL برای تاسیسات اصلی. XPOINT و SLOPE برای هندسه جاده. SIDE، STONE، WALL و BOX_PIPE برای ژئوتکنیک و زهکشی. DEFENCE، NORI، و SIGN برای امکانات ایمنی؛ DIP_EQP برای امکانات اضافی؛ و REALNTH، LANDUSE، PAY_ROAD، DETOUR_ROAD، و ROAD_AREA برای طبقه بندی های دیگر.
به طور خاص، کلاس BRIDGE اطلاعات اساسی در رابطه با پل ها، از جمله نوع ساختار، نام سازه و سطح ساختار را پوشش می دهد. BRIDGE می‌تواند دارای کلاس‌های صفر یا بیشتر BRIDGE_REGISTER باشد که مهمترین ویژگی‌های پل‌ها، از جمله اطلاعات مربوط به ساخت پل (به عنوان مثال، سازنده، ناظر، و هزینه ساخت)، اطلاعات اندازه پل (به عنوان مثال، ارتفاع، عرض، عرض جاده، و عرض پیاده رو)، مواد پل (به عنوان مثال، چوب، فولاد، و بتن مسلح)، اطلاعات تاسیسات (به عنوان مثال، تونل و منطقه جاده)، و هندسه مربوط به پل (به عنوان مثال، حداقل عرض جاده، شعاع منحنی، و شیب طولی) . BRIDGE و TUNNEL نقشه های سازه ای صفر یا بیشتر دارند (STR_DWG). کلاس TUNNEL در ثبت جاده اطلاعات اولیه در مورد ماهیت تونل ها را ارائه می دهد.
XPOINT اطلاعاتی در مورد هندسه راه، از جمله شروع و پایان منحنی، زاویه تقاطع، شعاع منحنی، و اطلاعات منحنی کلوتوئید ارائه می‌کند، در حالی که SLOPE حاوی اطلاعاتی در مورد شیب‌های طولی، از جمله ارتفاع شروع بخش و طول شیب است. SIDE برای نشان دادن اطلاعات ناودان و اندازه آن (به عنوان مثال، طول، ارتفاع و عرض) استفاده می‌شود و دارای فهرست کد GUT_TYPE است که انواع ناودان را نشان می‌دهد. STONE برای نشان دادن یک دیوار سنگی استفاده می شود که پایداری زمین را حفظ می کند، با ویژگی هایی که شامل طول، ارتفاع و اطلاعات مواد است. WALL یک دیوار حائل را نشان می دهد که علاوه بر طول، ارتفاع و مساحت تأسیسات، دارای فهرست کد WALL_TYPE است. BOX_PIPE برای زهکشی ها و کانال ها استفاده می شود و اطلاعات ابعادی لوله ها مانند قطر، طول،DEFENSE یک دیوار محافظ و یک نرده محافظ را نشان می دهد و حاوی کد لیست FACIL_TYPE است که ترکیب مواد را نشان می دهد. NORI نوعی تاسیسات جلوگیری از لغزش سنگ است که حاوی اطلاعات طول، ارتفاع و مواد است و دارای کد PIPE-TYPE است. SIGN یک تابلوی راه است و شامل اطلاعاتی در مورد نام تابلو، کد تابلو و روز نصب است. این شامل فهرست کدهای SIGN_TYPE (نقش علامت) و INSTALL_TYPE (روش نصب علامت) است. کلاس DIP_EQP نشان دهنده امکانات زیرزمینی و ویژگی های ابعادی آنها مانند اندازه، طول و مواد است. دارای ویژگی‌های شماره مجوز دفتر مدیریت و شغل و فهرست کد UNDER_FACIL_TYPE (انواع امکانات زیرزمینی) است.
REALNTH برای نشان دادن طول واقعی عناصر جاده، مانند طول جاده ها، پل ها، تونل ها، بخش ها، عرض جاده، میانه، شانه های چپ و راست و پیاده روها استفاده می شود. LANDUSE نوع کاربری زمین را در امتداد جاده نشان می دهد، یعنی اطلاعات اولیه کاداستر در اطراف جاده ها، مانند آدرس بخش، اهداف کاربری زمین، زمین مورد استفاده برای جاده ها، زمین های خصوصی و شماره مجوزها. دارای فهرست کد LU_PURPOSE (نوع هدف کاربری زمین). PAY_ROAD به جاده‌های عوارضی و طول تأسیسات مانند جاده‌ها، پل‌ها، و تونل‌ها و سایر اطلاعات مربوط به عوارض اشاره می‌کند. DETOUR_ROAD نشان‌دهنده جاده‌های کنارگذر است و دارای ویژگی‌های محل شروع کنارگذر بر حسب کیلومتر، و همچنین طول، عرض و منطقه عبور است. علاوه بر این، دارای فهرست کد ROAD_TYPE (انواع کد) است.
در بخش 2.1.2 ، مدل داده سیستم ثبت جاده در کره را به طور خاص مورد بحث قرار دادیم. ابتدا اشیاء ثبتی سیستم را مورد بحث قرار دادیم و سپس برخی از کلاس های مربوط به آن را با کد لیست مربوطه به تفصیل مورد بحث قرار دادیم. مدل داده‌های سیستم ثبت راه در دو بخش تشریح شد: کلاس‌های ثبت راه جاده‌ها و امکانات کنار جاده‌ای مانند مدل خط مرکزی جاده، هندسه راه، شیب‌های طولی و دیوارهای حائل، و کلاس‌های مرتبط با سازه راه، یعنی پل‌ها. و تونل ها علاوه بر این، طبقات اطلاعات ثبت جاده نقشه برداری شد و با کلاس های LandInfra مقایسه شد تا برای مدل مدیریت جاده کره ای در زمینه فعال کردن اطلاعات جغرافیایی جاده سه بعدی گسترش یابد.

2.2. نقشه برداری بین طبقات از مدل مدیریت جاده و LandInfra

برای اعمال کلاس‌های مدیریت راه به استاندارد LandInfra، بررسی کلاس‌های مربوطه بین کلاس‌های مدیریت راه و کلاس‌های نیازمندی LandInfra مورد نیاز بود. این فرآیند به عنوان نگاشت شناخته می شود و اولین گام به سمت نگاشت، مطابقت با کلاس های مربوطه با شناسایی هر کلاس است [ 10 ، 13 ].
برای اطلاعات روسازی، کلاس‌های روسازی PMS_ASP_STRUC و PMS_CON_STRUC به کلاس RoadElement نگاشت می‌شوند، زیرا این کلاس‌ها عناصر جاده در نظر گرفته می‌شوند. PMS_PAV_SURV، که اطلاعات وضعیت جاده را توصیف می کند، با عنصر فیزیکی بخش تسهیلات مطابقت دارد. PhysicalElement قسمت فیزیکی قسمت Facility [ 34 ] را مشخص می کند.
PMS_ROUTE_GENERAL که یک کلاس مسیر عمومی است، حاوی اطلاعات مسیر است. با کلاس Road مطابقت دارد، زیرا کلاس Road حاوی اطلاعات کلی در یک مسیر است. کلاس های PMS_TRF_VOL، PMS_ROUTE_CODE، PMS_PR_CODE، PMS_MCO_CODE، PMS_EVENT، PMS_EVENT_CODE، و PMS_REHAB_CODE به طور غیرمستقیم از طریق کلاس PMS_ ROUTE_GENERAL با کلاس Road مطابقت دارند. این کلاس‌ها را نمی‌توان به کلاس‌های LandInfra نگاشت به دلیل ویژگی‌های پشتیبانی آن‌ها در مدل اطلاعات روسازی. به طور خاص، PMS_TRF_VOL، که حاوی اطلاعات حجم ترافیک در یک مسیر خاص است، با هیچ کلاسی در LandInfra مطابقت ندارد، زیرا استاندارد فقط بر عناصر فیزیکی جاده ها و تأسیسات زیرساخت تمرکز دارد.
برای اطلاعات ثبت جاده، کلاس‌های MROAD، REALNTH، DETOUR_ROAD، و PAY_ROAD که بخش‌ها یا بخش‌هایی از جاده‌ها را نشان می‌دهند، با کلاس Alignment قسمت Alignment مطابقت دارند. کلاس‌های LANDUSE و ROAD_AREA، که نشان‌دهنده فضاهای جاده‌ها و مناطق نزدیک جاده‌ها هستند، می‌توانند کلاس PhysicalElement بخش Facility باشند، وقتی FacilityPartType به عنوان جاده تنظیم شود. از آنجایی که کلاس های SIDE، STONE، WALL، DEFENCE، BOX_PIPE، SIGN، NORI و DIP_EQP از جاده ها پشتیبانی می کنند، این کلاس ها به RoadElement نگاشت شدند. از آنجایی که کلاس XPOINT اطلاعات هندسی جاده ها از جمله انحنا، زاویه تقاطع و شعاع منحنی را به صورت افقی توصیف می کند، این کلاس می تواند با کلاس Alignment2DHorizontal قسمت Alignment مطابقت داشته باشد. کلاس SLOPE شیب جاده را به صورت عمودی توصیف می کند، که مربوط به کلاس Alignment2DVertical قسمت Alignment است. روش دیگر، SLOPE می‌تواند با کلاس Road مطابقت داشته باشد، جایی که ویژگی‌های SLOPE می‌توانند برای نمایش جاده‌های سه بعدی استفاده شوند.
کلاس‌های DRAWING و STR_DWG جاده‌ها را به‌عنوان نقشه‌های طراحی به کمک رایانه (CAD) نشان می‌دهند. DRAWING، که نشان دهنده یک نقشه راه مقطعی یا طرح نمای طولی برای ثبت جاده است، به کلاس Alignment نگاشت شد. STR_DWG که ترسیم سازه پل ها و تونل ها را نشان می دهد، به کلاس FacilityPart همراه با کلاس های BRIDGE و TUNNEL نگاشت شد.
BRIDGE_REGISTER، BRIDGE و TUNNEL اطلاعات ساختاری جاده ها را توصیف می کنند و این کلاس ها می توانند با کلاس FacilityPart قسمت Facility مطابقت داشته باشند زیرا Facility دارای انواع فرعی از چنین امکاناتی است. نتایج نقشه برداری در جدول 3 خلاصه شده است.

3. نتایج

3.1. مدل داده پیشنهادی بر اساس قطعات متناظر LandInfra

این مطالعه روشی را ارائه می‌کند که انتقال از مدل دو بعدی فعلی به مدل مبتنی بر GIS سه بعدی را تسهیل می‌کند. مدل پیشنهادی مدیریت راه مبتنی بر LandInfra بر اساس نتایج نقشه برداری ارائه شده در جدول 3 است.
یک مدل مدیریت راه متشکل از روسازی راه و داده‌های ثبت جاده برای بخش‌های جاده، تسهیلات و تراز LandInfra با توجه به نتایج نقشه‌برداری مدل‌سازی شد. نتایج مدل سازی داده ها در شکل 10 ، شکل 11 و شکل 12 نشان داده شده است، که در آن مدل داده پیشنهادی برای مدیریت زیرساخت جاده بر اساس همتایان LandInfra است. که در شکل 10، کلاس های مورد نیاز تسهیلات با رنگ فیروزه ای نشان داده شده اند و کلاس های وابسته آنها با رنگ زرد نشان داده شده اند. طبقات مربوط به ثبت روسازی و جاده به رنگ خاکستری با نام کلاس مربوطه نشان داده شده است. کلاس های مورد استفاده برای رمزگذاری InfraGML به رنگ سبز نشان داده شده است. کلاس BRIDGE به عنوان یک نمونه از قسمت Facility کدگذاری شده است و به رنگ سبز نشان داده شده است.
تسهیلات کلاس ملزومات LandInfra پشتیبانی کلی را برای تأسیسات زیرساختی، از جمله سدها، پل ها، جاده ها و خدمات شهری ارائه می کند. از این منظر، کلاس‌های BRIDGE و TUNNEL به عنوان زیر کلاس FacilityPart مدل‌سازی شدند. کلاس های BRIDGE_REGISTER و STR_DWG ارتباط یکسانی با کلاس BRIDGE نشان دادند. کلاس‌های PMS_PAV_SURV، ROAD_AREA و LANDUSE به عنوان زیر کلاس PhysicalElement مدل‌سازی شدند. این کلاس ها را می توان عناصر فیزیکی در نظر گرفت که وقتی FacilityPartType Road است FacilityPart را تشکیل می دهند.
در شکل 11 ، کلاس های الزامات تراز به رنگ فیروزه ای نشان داده شده اند و کلاس های وابسته مربوط به آنها با رنگ زرد نشان داده شده اند. کلاس های مربوط به ثبت جاده به رنگ خاکستری همراه با نام کلاس آنها نشان داده شده است. کلاس‌های MROAD، XPOINT و SLOPE به رنگ سبز نشان داده شده‌اند و این کلاس‌ها برای رمزگذاری InfraGML به عنوان نمونه استفاده می‌شوند.کلاس‌های MROAD، XPOINT]. بنابراین کلاس MROAD به عنوان زیر کلاس Alignment مدلسازی شد. کلاس‌های DETOUR_ROAD، PAY_ROAD، DRAWING و REALNTH ارتباط یکسانی با کلاس MROAD داشتند. این کلاس ها را می توان از طریق کلاس MROAD پیاده سازی کرد که تمام ویژگی ها را از کلاس Alignment به ارث می برد. کلاس XPOINT حاوی اطلاعات هندسی افقی جاده است و این کلاس به عنوان زیر کلاس Alignment2DHorizontal مدل شده است. کلاس SLOPE شیب طولی جاده ها را پوشش می دهد و بر این اساس به عنوان زیر کلاس Alignment2DVertical مدل شده است.
در شکل 12 ، طبقات مورد نیاز جاده با رنگ فیروزه ای نشان داده شده اند و کلاس هایی که طبقات جاده به آنها وابسته هستند با رنگ زرد نشان داده شده اند. طبقات مربوط به ثبت جاده و روسازی به رنگ خاکستری همراه با نام کلاس مربوطه نشان داده شده است. کلاس های SLOPE، WALL و PMS_ASP_STRUC (به رنگ سبز نشان داده شده است) برای رمزگذاری InfraGML استفاده شد.
جاده بخشی از یک تسهیلات است که یک بخش واحد است و باید پیوسته، غیر همپوشانی و غیر انشعاب باشد [ 34 ]. از این منظر، PMS_ROUTE_GENERAL که یک بخش از یک مسیر را نشان می‌دهد، به عنوان یک زیر کلاس از کلاس Road مدل‌سازی شد. کلاس‌های PMS_MCO_CODE، PMS_PR_CODE، PMS_ROUTE_CODE، PMS_TRF_VOL، PMS_EVENT، PMS_EVENT_CODE، و PMS_REHAB_CODE ارتباط یکسانی با PMS_ROUTE_GENERAL دارند که این کلاس‌ها را می‌توان از طریق PMS_ROUTE پیاده‌سازی کرد. کلاس‌های PMS_ASP_STRUC، PMS_CON_STRUC، DIP_EQP، NORI، BOX_PIPE، DEFENCE، WALL، STONE، SIDE و SIGN به عنوان زیر کلاس‌های RoadElement مدل‌سازی شدند. همه این کلاس ها ویژگی های کلاس RoadElement را به ارث می برند.

3.2. رمزگذاری InfraGML مدل داده پیشنهادی برای مدیریت راه

InfraGML یک استاندارد رمزگذاری برای اجرای استاندارد مدل مفهومی LandInfra [ 36 ] است. در بخش 3.1 ، ما یک مدل داده برای مدیریت جاده بر اساس همتایان متناظر LandInfra، از جمله تسهیلات، تراز، و جاده پیشنهاد کردیم. برای پیاده‌سازی مدل پیشنهادی، این مدل‌ها باید از کلاس‌های InfraGML Core، Facility، Alignment و Road پشتیبانی کنند.
بنابراین، هدف تعیین چگونگی تبدیل مدل مدیریت جاده مبتنی بر GIS دو بعدی به یک مدل مبتنی بر جغرافیایی سه بعدی دنیای واقعی با استفاده از LandInfra با استاندارد رمزگذاری InfraGML بود. در این بخش، نمونه های دنیای واقعی را بر اساس مدل پیشنهادی با استفاده از استاندارد رمزگذاری InfraGML به عنوان نتیجه بعدی مطالعه خود ارائه می دهیم. داده‌های مورد استفاده در رمزگذاری‌ها به‌عنوان نمونه از اطلاعات ثبت جاده در قالب shapefile (موجود در https://www.data.go.kr/data/3049884/fileData.do (در 23 مارس 2022) به دست آمده است.
بر اساس تحلیل قبلی، ما چندین کلاس از جمله MROAD، WALL، BRIDGE، XPOINT، SLOPE و PMS_ASP_STRUC را برای رمزگذاری در نظر گرفتیم. برخی از داده های مربوطه به طور خلاصه بر روی نقشه پایه قرار گرفتند، همانطور که در شکل 13 نشان داده شده است ، به جز PMS_ASP_STRUC که هیچ داده ای در دسترس عموم نداشت. در شکل 13 ، کلاس های MROAD، WALL، XPOINT و SLOPE در فرم LineString نشان داده شده است. در حالی که کلاس های MROAD و SLOPE به صورت خطی پیوسته بودند، کلاس های XPOINT و WALL به شکل خطی غیرپیوسته بودند.
کلاس BRIDGE به شکل چندضلعی غیر پیوسته نمایش داده می شود. در این بخش هر یک از این کلاس ها توسط InfraGML به عنوان ورودی کدگذاری می شوند. طبق استاندارد رمزگذاری InfraGML، کلاس Road FacilityPart را می توان به چهار صورت نشان داد: RoadElements به صورت جامد (معمولاً)، سطوح به صورت سطوح وجهی (مثلثی)، StringLines به عنوان خطوط طولی در جاده ها، و RoadCrossSections به عنوان نماهای دوبعدی برش عمود بر. خط مرکزی یک جاده
شکل 14 این روش ها را نشان می دهد، به جز RoadCrossSections که ما از آنها استفاده نکردیم. یک برنامه کاربردی مطابق با این کلاس از الزامات جاده می تواند شامل هر یک از سه نمایش اول، به تنهایی یا ترکیبی باشد [ 36 ]. در مطالعه حاضر، ما جاده ها را با استفاده از یک سطح مثلثی، نمایش StringLine جاده (چپ، راست و خط مرکزی) و RoadElement در Polyfacemesh نشان دادیم. شکل 15 قطعه ای از نتایج رمزگذاری InfraGML را نشان می دهد که در سطوح وجهی مثلثی بر اساس قسمت جاده نمایش داده شده است. توجه داشته باشید که همه داده ها کدگذاری نشده اند. با این حال، همه نتایج رمزگذاری را می‌توانید در https://github.com/baataraa1/InfraGML-Encoding-Instances (در 15 مه 2022 در دسترس قرار دهید) پیدا کنید.
رمزگذاری SLOPE InfraGML با LandInfraDataset آغاز می‌شود که از بخش LandInfra هسته [ 42 ] است و اطلاعاتی را در مورد ایجاد و تاریخ داده‌ها (یعنی ابرداده) ارائه می‌کند. هر قسمت کدگذاری شده با LandInfraDataset شروع می شود و کلاس های SLOPE و WALL که به Road کدگذاری شده اند یک LandInfraDataset مشترک دارند.
برای قسمت Road، علاوه بر کلاس داده، از SLOPE برای نمایش سطح جاده سه بعدی به عنوان یک سطح مثلثی و StringLine استفاده شد. SLOPE به عنوان یک RoadElement در Polyfacemesh برای نشان دادن PMS_ASP_STRUC استفاده شد. برای نمایش PMS_ASP_STRUC به عنوان یک دوره روسازی آسفالتی، از هر دو کلاس SLOPE و MROAD استفاده کردیم. برای کلاس SLOPE از مقادیر (به عنوان مثال ارتفاع) و برای کلاس MROAD از اطلاعات ویژگی آن استفاده کردیم که شامل اطلاعات ضخامت روسازی (20 سانتی متر آسفالت) به عنوان ورودی است. برای رمزگذاری، از برخی از داده‌های مکان مرجع با فاصله و ارتفاع طولی و عرضی (افست) به عنوان مقادیر هندسی استفاده کردیم.
علاوه بر این کلاس ها، یک کلاس دیواری که دیوارهای حائل را ارائه می کند، کدگذاری شد. در 2D LineString نشان داده شد و خطوطی در جایی که دیوار حائل قرار داشت وجود داشت. ویژگی‌های اساسی دیوار حائل، مانند حداکثر و حداقل طول دیوار حائل، با کلاس‌های Road و RoadElement پوشانده شد. دیوار حائل همانطور که در شکل 13 نشان داده شده است در امتداد خط مرکزی جاده قرار داشت و تقریباً 13 متر از خط مرکزی جاده فاصله داشت. بنابراین، این اطلاعات به عنوان فاصله افست جانبی در رمزگذاری گنجانده می شود. طول دیوار حائل مورد استفاده به عنوان نمونه 170 متر بود، یعنی طولانی ترین دیوار در میان دیوارهای حائل در داده ها.
برای بخش تسهیلات [ 43]، کلاس BRIDGE به InfraGML کدگذاری شد. کدگذاری با کلاس LandInfraDataSet شروع شد که متادیتا را توصیف می کند. بر خلاف کلاس های دیگر، BRIDGE به شکل چند ضلعی دو بعدی نشان داده شد. برای ویژگی SpatialRepresentation FacilityPart، چهار مقدار مختصات از لبه های پل به دست آمد و به عنوان IndexedPoint اضافه شد. علاوه بر این، چندین ویژگی از BRIDGE، مانند کلاس پل، نوع ستون و کمیت ستون، به عنوان نمونه در رمزگذاری تسهیلات گنجانده شده است. از سوی دیگر، ویژگی های BRIDGE بر اساس جهت های بالا و پایین جاده تقسیم می شوند. با این حال، مقادیر داده برای هر جهت یکسان بود، مگر اینکه طول یا ابعاد دیگر متفاوت باشد. بنابراین، رمزگذاری BRIDGE بر اساس یک رکورد انجام شد، زیرا رکوردها مقادیر یکسانی داشتند.
برای Alignment [ 44 ]، ما MROAD را به عنوان یک گذرگاه در نظر گرفتیم، به طوری که خط مرکزی جاده یک تراز باشد، که یک خط پیوسته، غیر همپوشانی و غیر انشعاب است. کلاس MROAD از قسمت Alignment به ارث برده شد و سایر ویژگی های MROAD کدگذاری شدند. به طور خاص، خط مرکزی جاده در 2D LineString بزرگراه ملی 30، بخش 5 بود، با طول تقریبی 7560 متر. پس از آن، XPOINT که اطلاعات هندسی جاده را نشان می دهد، برای Alignment کدگذاری شد. همچنین در فرم 2D LineString ارائه شد. با این حال، خطوط تنها در جاهایی وجود داشت که بخش‌های جاده منحنی وجود داشت. در رمزگذاری، ویژگی های اساسی مانند طول منحنی، موقعیت های شروع و پایان و سایر ویژگی های XPOINT گنجانده شده است. در داده‌های XPOINT، بیشترین طول انحنا تقریباً 1020 متر و کوچک‌ترین آن تقریباً 102 متر بود. SLOPE اطلاعات شیب را در طول یک جاده نشان می دهد. SLOPE شبیه خط مرکزی MROAD است و به شکل 2D LineString بود. به این ترتیب، خط از ابتدای بخش تا پایان ادامه یافت. ویژگی های اساسی، مانند طول شیب با موقعیت های شروع و پایان، درصد شیب، و ارتفاع نقطه شروع زمین، گنجانده شد.

4. بحث

ما بخش‌هایی از LandInfra را با استفاده از یک مدل مدیریت زیرساخت جاده‌ای کره گسترش دادیم، اگرچه LandInfra به صراحت از یک توسعه پشتیبانی نمی‌کند. برای گسترش مدل مدیریت راه به LandInfra، و در پاسخ به سؤالات مطالعه خود، مدل مدیریت راه فعلی را تحلیل کردیم. در نتیجه، نمودارهای کلاس UML را برای مدل‌های روسازی و ثبت جاده ایجاد کردیم. علاوه بر این، برای مقایسه و یافتن کلاس‌های مشابه بین LandInfra و مدل مدیریت جاده، یک روش نقشه‌برداری انجام شد و ما یک مدل داده مدیریت جاده را بر اساس بخش‌های LandInfra-تأسیسات، تراز، و جاده پیشنهاد کردیم. متعاقباً، مدل‌های پیشنهادی برای پیاده‌سازی در InfraGML کدگذاری شدند. ما از نمونه های دنیای واقعی برای رمزگذاری استفاده کردیم و چندین کلاس از مدل مدیریت جاده برای هر مدل پیشنهادی استفاده شد.
با این حال، ما داده های دنیای واقعی کافی برای پوشش کل مدل خود نداشتیم و فقط برخی از داده های مربوط به اطلاعات ثبت جاده در دسترس بود. علاوه بر این، داده های اضافی با مختصات دنیای واقعی برای تجسم جاده های سه بعدی با اعمال و پیاده سازی استانداردهای رمزگذاری LandInfra و InfraGML مورد نیاز است. در رابطه با تجسم رمزگذاری InfraGML و برای استفاده بیشتر از استاندارد، عدم پشتیبانی نرم افزاری در دسترس عموم (به عنوان مثال، نرم افزار منبع باز) برای استانداردهای رمزگذاری LandInfra و InfraGML باعث دشواری بیشتر می شود.
روش دیگر، همانطور که توسط کومار و همکاران پیشنهاد شده است، [ 29 ، 31 ] کلاس های LandInfra را می توان از طریق LandInfra ADE به CityGML منتقل کرد، جایی که پشتیبانی زیادی در قالب نرم افزار و اعتباردهنده ها و همچنین از طریق نمادگذاری شی جاوا اسکریپت (JSON) در دسترس است. پیاده سازی مبتنی بر ) که از XML بزرگ جلوگیری می کند و بالعکس. بنابراین، برای اعمال و تجسم رمزگذاری InfraGML به یک برنامه یا نرم افزار نیاز است. علاوه بر این، وجود چنین نرم‌افزاری، یعنی نرم‌افزاری که می‌تواند به‌طور خودکار فایل‌های مکانی یا غیرمکانی را به InfraGML تبدیل کند، به دانشگاهیان و متخصصان اجازه می‌دهد از مزایای LandInfra استفاده کنند.
از سوی دیگر، برای پشتیبانی از پیاده سازی InfraGML با IFC Alignment، Malmkvist و همکاران. [ 30 ] تغییر اطلاعات بین نرم افزارها یا سیستم های مختلف را بر اساس یک قالب استاندارد شده با استفاده از یک محصول تجاری مانند Trimble Novapoint، که برای پروژه های مهندسی عمران و پشتیبانی BIM است، پیشنهاد کرد. علاوه بر این، آنها از نرم افزار Feature Manipulation Engine (FME) که توسط یک فروشنده نرم افزار کانادایی توسعه یافته است، برای تجسم و اعتبارسنجی داده های InfraGML پردازش شده از Novapoint استفاده کردند. با این حال، آنها اشاره کردند که FME در آن زمان نمی توانست InfraGML را پشتیبانی کند و به جای آن یک فضای کاری سفارشی ایجاد شد.
علاوه بر این، InfraGML یک کاندید ایده آل برای ادغام احتمالی CAD، BIM و GIS خواهد بود. از آنجایی که بیشتر کارهای مهندسی عمران و زیرساخت های جاده ای در یک محیط CAD به تصویر کشیده می شوند، مدل های داده های CAD و BIM دو بعدی و سه بعدی را می توان با استفاده از استاندارد LandInfra/InfrGML در محیط GIS ادغام کرد. به ویژه، برای برآورده ساختن تقاضاها برای ارزیابی اثرات زیست محیطی مبتنی بر GIS پروژه های ساختمانی، شالر و همکاران. [ 45 ] استدلال کرد که مدل BIM (IFC) را می توان از AutoDesk Revit صادر کرد و پس از این فرآیند، BIM را می توان بدون از دست دادن اطلاعات به فرمت GIS تبدیل کرد. در این فرآیند، InfraGML Alignment می‌تواند همراه با IFC Alignment و احتمالاً با سایر بخش‌های مرتبط LandInfra برای ادغام اطلاعات در GIS استفاده شود.

5. نتیجه گیری ها

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

منابع

  1. کافيسو، اس. گرازیانو، AD; داگوستینو، سی. پاپالاردو، جی. Capace, B. Road Asset Management for Sustainable Development, Environmental Science and Sustainable Development: Conference International on Environmental Science and Sustainable Development (ICESSD 2015) ; World Scientific: سنگاپور، 2016; صص 337-342. [ Google Scholar ]
  2. فدراسیون جاده اتحادیه اروپا ERF Road Asset Management – ​​یک مقاله موقعیت ERF برای حفظ و بهبود شبکه جاده ای پایدار و کارآمد . فدراسیون جاده اتحادیه اروپا (ERF): بروکسل، بلژیک، 2014. [ Google Scholar ]
  3. رابرتز، جی. سیستم های مدیریت زیرساخت جاده ای (RIMS): اجزای اصلی. جاده ترانسپ. Res. 2004 ، 13 ، 94. [ Google Scholar ]
  4. لابتسکی، آ. ون گرون، اس. تامینگا، جی. لدوکس، اچ. Stoter, J. پیشنهادی برای یک مدل حمل و نقل بهبود یافته در CityGML. بین المللی قوس. فتوگرام حسگر از راه دور اسپات. Inf. علمی 2018 ، XLII-4 ، 89–96. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  5. کیما، جی. Mwangi, JM نمونه اولیه اطلاعات و سیستم مدیریت روسازی جاده مبتنی بر GIS. J. Civ. مهندس Res. 2009 ، 6. [ Google Scholar ] [ CrossRef ]
  6. موروا، ن. ترزی، س. گوکووا، اس. Karaşahin, M. کاربرد سیستم های مدیریت روسازی با روش سیستم اطلاعات جغرافیایی. جی. نات. Appl. علمی 2016 ، 20 ، 103-110. [ Google Scholar ] [ CrossRef ]
  7. Acquah، PC; فوسو، سی. پیاده سازی کاربرد سیستم اطلاعات جغرافیایی در مدیریت نگهداری جاده ها در غنا: مطالعه موردی جاده ها در کلانشهر کوماسی. صبح. جی. جئوگر. Inf. سیستم 2017 ، 6 ، 90-102. [ Google Scholar ]
  8. موسی، آی جی; ریچارد، تی اس; ایگویسی، سیستم مدیریت زیرساخت حمل و نقل جاده ای مبتنی بر EO GIS برای آداماوا مرکزی، ایالت آداماوا، نیجریه. جی. محیط زیست. علوم زمین 2015 ، 5 ، 1-16. [ Google Scholar ]
  9. وزارت زمین، زیربنا و حمل و نقل. مطالعه بهبود کامپیوتر ثبت جاده ها. 2015. در دسترس آنلاین: https://www.codil.or.kr/filebank/original/RK/OTKCRK160181/OTKCRK160181.pdf?stream=T (در 1 فوریه 2022 قابل دسترسی است).
  10. بوویباتر، م. کیم، ام جی؛ Shin, SP به سمت کاربرد استاندارد LandInfra برای مدیریت بزرگراه در کره. بین المللی قوس. فتوگرام حسگر از راه دور اسپات. Inf. Sci.-ISPRS Arch. 2020 ، 43 ، 435-439. [ Google Scholar ] [ CrossRef ]
  11. ریچارد، تی اس; موسی، آی جی; ایگویسی، EO توسعه سیستم مدیریت اطلاعات حمل و نقل جاده ای مبتنی بر GIS برای آداماوا مرکزی، ایالت آداماوا، نیجریه. J. Inf. علمی مهندس 2015 ، 5 ، 56-73. [ Google Scholar ]
  12. موسسه مهندسی عمران و فناوری ساختمان کره. توسعه سیستم مدیریت بزرگراه: مرحله پنجم. 2003. در دسترس آنلاین: https://www.codil.or.kr/filebank/original/RK/OTMCRK040495/OTMCRK040495.pdf?stream=T (در 28 ژانویه 2022 قابل دسترسی است).
  13. بوویباتر، م. Shin, S. طراحی مدل داده برای مدیریت سه بعدی بزرگراه مبتنی بر اطلاعات جغرافیایی با استفاده از استاندارد LandInfra. بین المللی جی. هایو. مهندس 2021 ، 23 ، 87-94. [ Google Scholar ] [ CrossRef ]
  14. ماه، اچ. چوی، دبلیو. کانگ، ال. نه، ح. استخراج عناصر ساختار جاده برای توسعه مدل IFC (کلاسهای بنیاد صنعت) برای جاده. J. Korea Acad.-Ind. قفس. Soc. 2014 ، 15 ، 1195-1203. [ Google Scholar ]
  15. گریستینا، اس. ایلول، سی. Scianna، A. توسعه یک سیستم کاداستر جاده ای سه بعدی: مقایسه الزامات قانونی و نیازهای کاربر. بین المللی قوس. فتوگرام حسگر از راه دور اسپات. Inf. Sci.-ISPRS Arch. 2016 ، 4 ، 223-231. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  16. هتگر، سی. برنر، سی. استخراج پارامترهای هندسه جاده از اسکن لیزری و پایگاه های داده موجود. بین المللی قوس. فتوگرام حسگر از راه دور اسپات. Inf. Sci.-ISPRS Arch. 2003 ، 34 ، 225-230. [ Google Scholar ]
  17. سان، م. چن، جی. تحقیق ساختار داده شبکه سه بعدی جاده شهری. بین المللی قوس. فتوگرام حسگر از راه دور اسپات. Inf. Sci.-ISPRS Arch. 2000 ، 33 ، 1025-1037. [ Google Scholar ]
  18. زو، س. Li، Y. مدل شبکه سه بعدی جاده ای خط محور سلسله مراتبی. بین المللی جی. جئوگر. Inf. علمی 2008 ، 22 ، 479-505. [ Google Scholar ] [ CrossRef ]
  19. OGC (کنسرسیوم فضایی باز). استاندارد رمزگذاری زبان جغرافیای شهر (CityGML)، نسخه 2.0.0 . OGC: Wayland، MA، ایالات متحده آمریکا، 2012. [ Google Scholar ]
  20. کیم، BS; جئونگ، DW; اوه، SH; Ahn، JW; Hong, SK طراحی و پیاده سازی مدل داده برای داده های دقیق جاده سه بعدی. J. کره ای Soc. Geogr. Inf. علمی 2019 ، 27 ، 13-23. [ Google Scholar ] [ CrossRef ]
  21. بیل، سی. Kolbe، TH CityGML و خیابان‌های نیویورک – پیشنهادی برای مدل‌سازی دقیق فضای خیابان. ISPRS Ann. فتوگرام حسگر از راه دور اسپات. Inf. علمی 2017 ، 2-9. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  22. بیل، سی. روهدوفر، آر. کودورو، تی. Kolbe، TH مدلسازی تفصیلی فضای خیابان برای کاربردهای متعدد: بحث در مورد مدل حمل و نقل پیشنهادی CityGML 3.0. ISPRS Int. J. Geo-Inf. 2020 ، 9 ، 603. [ Google Scholar ] [ CrossRef ]
  23. جانگ، اچ. کیم، اچ. Kang, H. ساخت ویژگی CityGML در مقیاس بزرگ برای زیرساخت های دیجیتال سه بعدی. J. کره ای Soc. Surv. Geod. فتوگرام کارتوگر. 2021 ، 39 ، 187-201. [ Google Scholar ]
  24. بیل، سی. Kolbe، TH مدل سازی ترکیبی زیرساخت های حمل و نقل چندگانه در مدل های سه بعدی شهر و پیاده سازی آن در CityGML 3.0. ISPRS Ann. فتوگرام حسگر از راه دور اسپات. Inf. علمی 2020 ، 6 ، 29-36. [ Google Scholar ] [ CrossRef ]
  25. Niestroj، MG; مک میکین، دی. Helmholz, P. بررسی اجمالی استانداردها نسبت به تبادل اطلاعات دارایی جاده. 2018، صفحات 443-450. در دسترس آنلاین: https://www.int-arch-photogramm-remote-sens-spatial-inf-sci.net/XLII-4/443/2018/ (دسترسی در 19 سپتامبر 2018).
  26. اتریش. استاندارد داده برای مدیریت راه و سرمایه گذاری در استرالیا و نیوزلند نسخه 3.0. شماره AP-R597-19; استرالیا، 2019. در دسترس آنلاین: https://austroads.com.au/publications/asset-management/ap-r597-19 (در 30 ژانویه 2019 قابل دسترسی است).
  27. جتلوند، ک. اونشتاین، ای. Huang, L. تبادل اطلاعات بین GIS و پایگاه‌های اطلاعات مکانی آن بر اساس یک مدل عمومی. ISPRS Int. J. Geo-Inf. 2019 ، 8 ، 141. [ Google Scholar ] [ CrossRef ] [ نسخه سبز ]
  28. کالوجیانی، ای. فلوروس، جی اس. دیموپولو، ای. Skanska، UK بررسی اشیاء زیرساخت حمل و نقل در چرخه حیات توسعه فضایی آنها. ISPRS Ann. فتوگرام حسگر از راه دور اسپات. Inf. علمی 2021 ، 8 ، 129-136. [ Google Scholar ] [ CrossRef ]
  29. کومار، ک. لابتسکی، آ. اوهوری، کالیفرنیا؛ لدوکس، اچ. Stoter، J. هماهنگ کردن استانداردهای OGC برای محیط ساخته شده: یک توسعه CityGML برای LandInfra. ISPRS Int. J. Geo-Inf. 2019 ، 8 ، 246. [ Google Scholar ] [ CrossRef ] [ نسخه سبز ]
  30. مالمکویست، م. اکسلسون، پی. ویکستروم، ال. برگمن، او. نیلسون، ا. گرانبرگ، اس. جنسن، جی. هاگستروم، ای. زیگفرید، جی. کارلسون، ک. استقرار تراز. گزارش اجرا در تأیید IFC Alignment و InfraGML . گزارش فنی؛ تیم پروژه نوردیک، BuildingSMART: هرتفوردشایر، بریتانیا، 2017. [ Google Scholar ]
  31. کومار، ک. لابتسکی، آ. اوهوری، کالیفرنیا؛ لدوکس، اچ. Stoter, J. استاندارد LandInfra و نقش آن در حل باتلاق BIM-GIS. Geospat را باز کنید. نرم افزار داده ایستادن. 2019 ، 4 ، 1-16. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  32. گیلبرت، تی. رونزدورف، سی. پلوم، ج. سیمونز، اس. Nisbet، N. گرولر، اچ. کلبه، تی. ون برلو، ال. مرسر، A. استانداردهای داده های محیطی ساخته شده و ادغام آنها: تجزیه و تحلیل IFC، CityGML و LandInfra. نسخه 1.0، 2 مارس 2020، سند OGC 19-091r1، bSI TR1012. 2020. در دسترس آنلاین: https://portal.ogc.org/files/?artifact_id=92634 (در 4 فوریه 2022 قابل دسترسی است).
  33. گویو، ای. هارتمن، تی. Ungureanu، L. قابلیت همکاری بین BIM و GIS از طریق استانداردهای داده باز: مروری بر ادبیات فعلی. در مجموعه مقالات نهمین کارگاه داده های پیوندی در معماری و ساخت و ساز-LDAC2021، لوکزامبورگ، 11 تا 13 اکتبر 2021؛ جلد 3، ص 5-9. در دسترس آنلاین: https://ceur-ws.org/Vol-3081/10paper.pdf (دسترسی در 14 ژانویه 2022).
  34. Doc. شماره 15-111r1 ; استاندارد مدل مفهومی زمین و زیرساخت. OGC: Rockville، MD، ایالات متحده آمریکا، 2016.
  35. LandXML-1.2. در دسترس آنلاین: https://landxml.org/About.aspx (در 4 مارس 2022 قابل دسترسی است).
  36. سند شماره 16-104r2 ; OGC InfraGML 1.0: Part 4–LandInfra Roads-Encoding Standard. OGC: Rockville، MD، ایالات متحده آمریکا، 2017.
  37. اتریش. راهنمای مدیریت دارایی – نمای کلی قسمت 1: مقدمه ; Austroads Ltd.: سیدنی، استرالیا، 2018. [ Google Scholar ]
  38. لی، ایکس. وو، پی. ژو، جی. وانگ، جی. یکپارچه سازی اطلاعات مبتنی بر هستی شناسی: بررسی پیشرفته در مدیریت دارایی جاده. قوس. محاسبه کنید. مهندسی روش ها 2021 ، 1-19. [ Google Scholar ] [ CrossRef ]
  39. سامانه اطلاعاتی آمار و نگهداری راه. در دسترس آنلاین: https://www.rsis.kr/statistics_road_national.htm (در 2 فوریه 2022 قابل دسترسی است).
  40. موسسه مهندسی عمران و فناوری ساختمان کره. مطالعه برنامه ریزی در سیستم یکپارچه سازی مدیریت راه هوشمند و فناوری ابتدایی. 2018. در دسترس آنلاین: https://www.codil.or.kr/filebank/original/RK/OTKCRK190422/OTKCRK190422.pdf?stream=T (در 4 فوریه 2022 قابل دسترسی است).
  41. وزارت زیربناهای زمینی و حمل و نقل. کتاب راهنمای وظیفه جاده. 2021. در دسترس آنلاین: https://www.codil.or.kr/filebank/original/MA/OTKCMA211234/OTKCMA211234.pdf?stream=T (در 22 مارس 2022 قابل دسترسی است).
  42. سند شماره 16-100r2 ; OGC InfraGML 1.0: قسمت 0– LandInfra Core–Encoding Standard. OGC: Rockville، MD، ایالات متحده آمریکا، 2017.
  43. سند شماره 16-102r2 ; OGC InfraGML 1.0: Part 2–LandInfra Facilities and Projects–Encoding Standard. OGC: Rockville، MD، ایالات متحده آمریکا، 2017.
  44. سند شماره 16-103r2 ; OGC InfraGML 1.0: قسمت 3–LandInfra Alignments–Encoding Standard. OGC: Rockville، MD، ایالات متحده آمریکا، 2017.
  45. شالر، جی. گنادینگر، جی. ریث، ال. فرلر، اس. Mattos, C. GeoDesign: Concept for ادغام BIM و GIS در برنامه ریزی منظر. جی دیجیت. Landsc. آرشیت. 2017 ، 2 ، 102-112. [ Google Scholar ]
Ijgi 11 00316 g001 550
شکل 1. عناصر معمولی راه (دارایی) [ 14 ].
Ijgi 11 00316 g002 550
شکل 2. کلاس های نیازمندی LandInfra و وابستگی های آنها [ 36 ].
Ijgi 11 00316 g003 550
شکل 3. ( الف ) شبکه بزرگراه ملی. (پایگاه داده حمل و نقل کره، https://www.ktdb.go.kr/www/joinStep1Form.do?key=163 ؛ در 10 فوریه 2022 مشاهده شده است). ( ب ) مفاهیم اصلی مدیریت راه و سیستم های نگهداری در سیستم مدیریت بزرگراه.
Ijgi 11 00316 g004 550
شکل 4. نمودار کلاس UML اطلاعات روسازی جاده.
Ijgi 11 00316 g005 550
شکل 5. ساختار معمولی روسازی ها.
Ijgi 11 00316 g006 550
شکل 6. اشیاء ثبت جاده [ 10 ].
Ijgi 11 00316 g007 550
شکل 7. نمودار کلاس UML اطلاعات ثبت جاده.
Ijgi 11 00316 g008 550
شکل 8. فهرست کدهای کلاس UML اطلاعات ثبت جاده.
Ijgi 11 00316 g009 550
شکل 9. نمودار اطلاعات ثبت جاده UML کلاس (پل و تونل) با فهرست کد.
Ijgi 11 00316 g010 550
شکل 10. مدل داده پیشنهادی برای مدیریت راه بر اساس بخش LandInfra Facility.
Ijgi 11 00316 g011 550
شکل 11. مدل داده پیشنهادی برای مدیریت راه بر اساس قسمت LandInfra Alignment.
Ijgi 11 00316 g012 550
شکل 12. مدل داده های پیشنهادی برای مدیریت راه بر اساس قسمت LandInfra Road.
Ijgi 11 00316 g013 550
شکل 13. ترسیم داده های نمونه برای مدل داده پیشنهادی برای رمزگذاری InfraGML.
Ijgi 11 00316 g014 550
شکل 14. بیان جغرافیایی سه بعدی جاده ها. ( الف ) سطح جاده مثلثی. ( ب ) چپ، راست و خط مرکزی جاده در StringLines نشان داده شده است. ( ج ) Road با RoadElement نشان داده شده در PolyfaceMesh [ 34 ] نشان داده می شود.
Ijgi 11 00316 g015 550
شکل 15. گزیده ای از رمزگذاری InfraGML مدل داده پیشنهادی بر اساس بخش جاده.

مقالات داخلی و بین المللی

مطالب مرتبط ...

بدون دیدگاه

دیدگاهتان را بنویسید