UrbanWater : ادغام EPANET 2 در یک سیستم مدیریت پایگاه داده جغرافیایی مبتنی بر PostgreSQL/PostGIS
خلاصه
ترکیب دادههای ذخیرهشده در یک سیستم اطلاعات جغرافیایی (GIS) در توسعه مدلهای شبیهسازی هیدرولیکی برای عملیات، بهروزرسانی و در نتیجه طراحی مجدد سیستمهای تامین آب (WSS) بسیار مهم است. ساخت و بهروزرسانی مدلهای هیدرولیک میتواند زمان و منابع را صرف کند. علاوه بر این، نیاز به به روز رسانی اطلاعات کاداستر زیرساخت، خود مدل را قدیمی می کند. علاوه بر این، پراکندگی معمولی داده ها در چندین پایگاه داده به تلاش بیشتری برای حفظ کل سیستم و اطمینان از مونتاژ صحیح آن نیاز دارد. اگرچه راهحلهای مدلسازی هیدرولیکی مبتنی بر GIS وجود دارد، اما معمولاً از اتصالات خارجی برای جمعآوری تمام اجزا استفاده میکنند که منجر به هزینههای اضافی و انعطافپذیری کمتر میشود. به منظور ایجاد یک مدل داده کاملاً یکپارچه واحد برای توصیف جهانی یک WSS و شبیهسازی هیدرولیکی مرتبط، این مقاله پیادهسازی خاص یک مدل EPANET 2 را در PostgreSQL همراه با پسوند PostGIS پیشنهاد میکند. سیستم توسعهیافته ساخت مدل، شبیهسازی هیدرولیکی و ذخیرهسازی نتایج را در یک پایگاه داده را امکانپذیر میسازد. رویه ها و توابع مورد نیاز در pgSQL یا Python کدگذاری شدند و اجرای آنها با استفاده از دستورات SQL انجام شد.
در نهایت، یک مطالعه موردی به منظور آزمایش سیستم پیشنهادی انتخاب شد. نتایج نشان میدهد که یک رویکرد یکپارچه در واقع امکان ایجاد سریع مدلهای هیدرولیکی واقعیتر را بر اساس اطلاعات کاداستر ذخیرهشده فراهم میکند. این مقاله اجرای خاص یک مدل EPANET 2 را در PostgreSQL همراه با پسوند PostGIS پیشنهاد میکند. سیستم توسعهیافته ساخت مدل، شبیهسازی هیدرولیکی و ذخیرهسازی نتایج را در یک پایگاه داده را امکانپذیر میسازد. رویه ها و توابع مورد نیاز در pgSQL یا Python کدگذاری شدند و اجرای آنها با استفاده از دستورات SQL انجام شد. در نهایت، یک مطالعه موردی به منظور آزمایش سیستم پیشنهادی انتخاب شد. نتایج نشان میدهد که یک رویکرد یکپارچه در واقع امکان ایجاد سریع مدلهای هیدرولیکی واقعیتر را بر اساس اطلاعات کاداستر ذخیرهشده فراهم میکند. این مقاله اجرای خاص یک مدل EPANET 2 را در PostgreSQL همراه با پسوند PostGIS پیشنهاد میکند. سیستم توسعهیافته ساخت مدل، شبیهسازی هیدرولیکی و ذخیرهسازی نتایج را در یک پایگاه داده را امکانپذیر میسازد. رویه ها و توابع مورد نیاز در pgSQL یا Python کدگذاری شدند و اجرای آنها با استفاده از دستورات SQL انجام شد. در نهایت، یک مطالعه موردی به منظور آزمایش سیستم پیشنهادی انتخاب شد. نتایج نشان میدهد که یک رویکرد یکپارچه در واقع امکان ایجاد سریع مدلهای هیدرولیکی واقعیتر را بر اساس اطلاعات کاداستر ذخیرهشده فراهم میکند. رویه ها و توابع مورد نیاز در pgSQL یا Python کدگذاری شدند و اجرای آنها با استفاده از دستورات SQL انجام شد. در نهایت، یک مطالعه موردی به منظور آزمایش سیستم پیشنهادی انتخاب شد. نتایج نشان میدهد که یک رویکرد یکپارچه در واقع امکان ایجاد سریع مدلهای هیدرولیکی واقعیتر را بر اساس اطلاعات کاداستر ذخیرهشده فراهم میکند. رویه ها و توابع مورد نیاز در pgSQL یا Python کدگذاری شدند و اجرای آنها با استفاده از دستورات SQL انجام شد. در نهایت، یک مطالعه موردی به منظور آزمایش سیستم پیشنهادی انتخاب شد. نتایج نشان میدهد که یک رویکرد یکپارچه در واقع امکان ایجاد سریع مدلهای هیدرولیکی واقعیتر را بر اساس اطلاعات کاداستر ذخیرهشده فراهم میکند.
کلید واژه ها:
GIS ; اتصال ؛ EPANET 2 ; مدل سازی هیدرولیک ; شبیه سازی ; سیستم مدیریت یکپارچه تامین آب
1. معرفی
1.1. انگیزه
طراحی روشهای مدیریت و بهرهبرداری برای سیستمهای آبرسانی شهری مؤثر (WSS) باید سیستمهای اطلاعات جغرافیایی (GIS) را در نظر بگیرد، که یک پلت فرم یکپارچه از انواع مختلف اطلاعات را تشکیل میدهند [1 ، 2 ] . به گفته شمسی [ 3 ]، حدود 80 درصد از اطلاعاتی که به طور بالقوه توسط صنعت آب در راه اندازی WSS استفاده می شود، مستعد ارجاع جغرافیایی هستند. به این ترتیب، یک رویکرد GIS ممکن است مجموعهای از فرصتها مانند کاهش هزینههای عملیاتی، کاهش زمان پاسخدهی، منظمسازی خرابیهای عملکردی و/یا ساختاری، شناسایی اولویتهای سرمایهگذاری و ایجاد طرحهای اضطراری را برای یک شرکت آب WSS فراهم کند. دیگران.
افزایش ظرفیت محاسباتی رایانهها و اجرای روشهای عددی قوی برای تعیین متغیرهایی مانند جریان و فشار، مدلهای هیدرولیک را به ابزاری بسیار عملی و مفید تبدیل کرد. با این حال، ساخت و به روز رسانی آن ممکن است به مصرف منابع و فرآیندی پیچیده و طولانی تبدیل شود – عواملی که استفاده سیستماتیک از چنین مدلهایی را عمدتاً در بین مدلسازان ابزارهای ابعاد کوچک تحمیل میکنند.
اطلاعات کاداستر زیرساختی را می توان در یک GIS برای ساخت و نگهداری مدل های شبیه سازی هیدرولیک استفاده کرد. این امر از افزونگی اطلاعات جلوگیری می کند و سازگاری مدل را افزایش می دهد. داده های جغرافیایی که اجزای فیزیکی یک WSS را مشخص می کند (به عنوان مثال، نوع مواد، قطر، طول و تاریخ نصب لوله ها، موقعیت جغرافیایی و وضعیت عملیاتی دریچه ها)، که می توانند در یک GIS ذخیره شوند، اجزای حیاتی برای ساخت یک مدل هیدرولیک را تشکیل می دهند. . با این حال، به روز رسانی مداوم آنها یک مدل هیدرولیک معین را به یک مدل نادرست و در نتیجه دقیق تر تبدیل می کند. ارتباط بین دادههای GIS و مدلهای هیدرولیکی از اهمیت بالایی برخوردار است و در حالت ایدهآل، یک مدل هیدرولیک معین باید به صورت پویا در زمان واقعی تنظیم شود.
برخی از راه حل های تجاری در حال حاضر برای مدل سازی WSS با ویژگی هایی ارائه شده است که امکان ایجاد پیوند بین داده های GIS، استفاده مستقیم از داده ها و همچنین تلاقی داده ها را فراهم می کند. با این وجود، ثابت شده است که این راه حل های تجاری کاملاً مؤثر نیستند، زیرا مبتنی بر رویکردهای عمومی طراحی شده برای پوشش طیف گسترده ای از واقعیت ها هستند. علاوه بر این، در برخی موارد، این بستههای تجاری نتایج مدلسازی را بلافاصله در دسترس همه انواع کاربران قرار نمیدهند. علاوه بر این، برخی موقعیتها به روشهای خاصی نیاز دارند، به عنوان مثال برای تشخیص و تصحیح ناسازگاریهای توپولوژیکی، یا حتی برای ارزیابی کامل بودن مدل تولید شده. به طور معمول، چنین رویه هایی در آن بسته های تجاری نرم افزاری موجود نیستند. سرانجام، راه حل های تجاری همیشه دارای هزینه های اضافی مربوط به نگهداری نرم افزار و صدور مجوز هستند. اغلب اوقات، راه حل با توسعه یک رویکرد منحصر به فرد مبتنی بر GIS ارائه می شود که با کار به عنوان دستیار متخصص، یکپارچه سازی یکپارچه از منابع داده ناهمگن را امکان پذیر می کند و درک آنها را در یک پلت فرم یکپارچه واحد ساده می کند.2 ].
با این وجود، ادغام مدل های هیدرولیک در GIS چندین چالش مرتبط با [ 4]: سطح صحت و دقت داده مورد نیاز؛ ادراکات مختلف در مورد نقش هر دو مدل GIS و هیدرولیک. ظرفیت توزیع موثر و انتخابی نتیجه مدل سازی؛ به روز رسانی و نگهداری خود مدل در ادبیات، در حال حاضر طیف گسترده ای از ابزارهای تخصصی منبع باز موجود است که ثابت کرده اند به اندازه کافی برای اهداف بالا قوی هستند و گزینه ای کم هزینه برای کاربر نهایی هستند. ما معتقدیم که استفاده ترکیبی از چنین ابزارهایی، همراه با تنظیمات مناسب، ساخت سکوهای یکپارچه مدل هیدرولیک مبتنی بر GIS را امکان پذیر می کند. چنین پلت فرم یکپارچه ای برای اهداف شبیه سازی اساسی است زیرا امکان استخراج اکثر متغیرهای نامطمئن و پیش بینی اثرات سناریوهای چشم انداز بلندمدت مختلف را فراهم می کند [ 5]].
1.2. هدف و اهداف
به منظور پرداختن به برخی محدودیتهای ذکر شده در بالا، هدف این مقاله توسعه یک پایگاه داده جغرافیایی است که قادر به ذخیره دادههای کاداستر زیرساخت با اشاره به اجزای اصلی WSS است، و همچنین قادر به ذخیره دادههای مورد نیاز برای توصیف دینامیکی و تولید مدلهای شبیهسازی هیدرولیکی است. همچنین به دنبال این بود که ویژگیهای سیستم پیشنهادی میتواند در طیف وسیعی از کاربردهای GIS دسکتاپ مورد استفاده قرار گیرد. با توجه به هدف اصلی فوق، اهداف اساسی به شرح زیر مشخص شد:
-
برای طراحی یک مدل مفهومی که خصوصیات اجزای مختلف WSS و همچنین شناسایی اطلاعات مورد نیاز برای فرآیند مدلسازی هیدرولیک را ممکن میسازد.
-
برای تعریف قوانین توپولوژیکی و اتصال برای هر نوع موجودیتی که باید مدلسازی شود.
-
توسعه توابع و رویه هایی که شبیه سازی هیدرولیکی را بر اساس داده های گرافیکی و الفبایی ذخیره شده در GIS ممکن می سازد.
به منظور دستیابی به اهداف بالا، یک سیستم مدیریت پایگاه داده شی رابطه ای PostgreSQL (DBMS) همراه با پسوند فضایی PostGIS استفاده شد – هر دو ابزار منبع باز هستند. در مورد شبیه سازی هیدرولیک، این با استفاده از کیت برنامه نویسی EPANET 2 [ 6 ] انجام شد.
2. پس زمینه
2.1. نقش GIS در مدیریت تامین آب
هدف اصلی WSS ارائه آب آشامیدنی با کیفیت و کمیت کافی برای کاربران است و در عین حال به دنبال تضمین شرایط عملیاتی مناسب در مواقع اضطراری مانند آتش سوزی شهری است. یک زیرساخت معمولی WSS شامل لولهها، پمپها، مخازن، شیرها، فلومترها، دریچههای هوا و سایر اجزای هیدرولیک است.
از دیدگاه مدیریت نهادها، ارتباط فناوری GIS در مدیریت WSS آشکار میشود، اگر ماهیت اطلاعاتی که به طور مداوم توسط چنین سیستمهایی تولید میشود، توزیع فضایی اجزای آنها و محلیسازی فضایی مصرفکنندگان و تقاضاها را در نظر بگیریم [ 7 ، 8 ، 9 ]. طبق USEPA [ 10 ]، ماهیت اطلاعات WSS اصولاً مکانی است. به این ترتیب، مدیریت آن شامل استفاده، دستکاری و تجزیه و تحلیل داده های جغرافیایی ارجاع شده است [ 11]. اینها ممکن است به محلی سازی یک نقطه مصرف، ترک لوله، یا ممکن است به محلی سازی مصرف کنندگان حساس (به عنوان مثال، بیمارستان ها، مدارس، رستوران ها و غیره) اشاره داشته باشند. توسعه و نگهداری یک کاداستر زیرساختی به خوبی سازماندهی شده و به روز وقت گیر و دست و پا گیر است [ 12 ]، اما ابزاری اساسی برای حمایت از تصمیم گیری کارآمد و موثر، کاهش هزینه های عملیاتی، کاهش زمان پاسخگویی و تعریف است. اولویت های سرمایه گذاری، برای ایجاد برنامه های اضطراری، از جمله.
در مقیاس جهانی، تکامل GIS در بخش بهداشت در اواخر دهه 1980 قرن بیستم اتفاق افتاد. در دهه بعد، استفاده از فناوری GIS برای مدیریت زیرساخت یا عملیات تعمیر و نگهداری بسیار رایج شد. در اواخر دهه 1990، بستههای نرمافزار تجاری در حال ظهور با رابطهای بسیار دوستانهتر، GIS را به یک فناوری بینرشتهای گستردهتر تبدیل کرد که در حال حاضر در طیف گستردهای از زمینهها، مانند مدلسازی هیدرولیک و ارزیابی کیفیت آب استفاده میشود [13]، به نقل از [ 3 ] . .
به گفته شمسی [ 3 ]، راهحلهای GIS عمدتاً برای اهداف نقشهبرداری، پایش، مدلسازی و نگهداری WSS اتخاذ شدهاند. این عمدتا به دلیل قابلیت های GIS برای توصیف کل سیستم، شناسایی نقاط بحرانی و ترسیم سناریوهای جایگزین، و برنامه ریزی و ثبت مداخلات (مانند ثبت رویداد، اندازه، وضعیت، نوع ماده، نوع خاک) است. . قابلیتهای پردازش جغرافیایی GIS، مانند همپوشانی و دستکاری لایههای مختلف اطلاعات، امکان تجزیه و تحلیل و برنامهریزی جغرافیایی سریعتر و مؤثرتر را فراهم میکند. توپولوژی مطمئناً یک ویژگی اصلی تعیین کننده یک GIS است [ 14] و از این رو در نظر گرفتن خواص توپولوژیکی در نمایش دیجیتالی یک WSS، اتصال بین اجزای آن را تضمین میکند و امکان تولید و توسعه یک مدل هیدرولیکی جهانی از نظر توپولوژیکی صحیح را فراهم میکند – این در واقع یکی از محورهای اصلی این مقاله است.
در نهایت، GIS ممکن است به عنوان یک پلت فرم یکپارچه فناوری اطلاعات دیده شود. چنین ویژگی همراه با ارتباطات سیار از قابلیت های داده، امکان جستجو و تولید در زمان واقعی اطلاعات جغرافیایی ارجاع شده را فراهم می کند و در نهایت امکان استفاده از ابزارهای پشتیبانی تصمیم را فراهم می کند. در مجموع، ویژگیهای تکنولوژیکی ذکر شده در بالا ممکن است مدلسازی هیدرولیک را در صورت پیادهسازی در یک محیط GIS تقویت کند.
2.2. مدلسازی هیدرولیک و ادغام آن در GIS
توانایی تعیین جریان محاسباتی و فشار در یک WSS داده شده همواره مورد توجه مدیریت نهادها بوده است. این به طور عمده برای برنامه ریزی، تصور و اهداف عملیاتی WSS که قادر به خدمت رسانی کارآمد و ایمن به مصرف کنندگان است، بسیار مهم است. به منظور تعیین متغیرهای فوق، تاکنون روشهای مختلفی مانند روشهای گرافیکی، قیاسهای فیزیکی و مدلسازی ریاضی ارائه شده است [ 15 ، 16 ، 17 ].
ظهور رایانههای شخصی در دهه 1980 قرن بیستم، پردازندههای مرکزی را اضافی کرد و مدلسازی هیدرولیک برای طیف وسیعتری از کاربران هدف در دسترس قرار گرفت. علاوه بر این، امکان مدلسازی کیفیت آب و همچنین اجزای پیچیدهتر WSS (مانند پمپها، شیرهای فشار شکن)، و همچنین امکان استفاده از رابطهای گرافیکی در برنامههای محاسباتی، تا حد زیادی باعث استفاده از رویکرد مدلسازی هیدرولیک توسط نهادهای مدیریتی شد. [ 16 ]. علاوه بر مدیریت تامین آب، مدلسازی هیدرولیک ابزار مهمی برای فعالیتهای مدیریت دارایی، برنامههای کنترل عملیاتی برای نظارت و بهبود کیفیت آب [ 1 ]، تعریف منطقه اندازهگیری شده [ 18 ، 19] است.]، ایجاد برنامه های نشت آب [ 20 ، 21 ، 22 ، 23 ]، و تجزیه و تحلیل ریسک شکست [ 24 ، 25 ، 26 ].
به طور معمول، ساخت یک مدل هیدرولیک WSS به داده ها و اطلاعات پراکنده در چندین سیستم اطلاعاتی مختلف نیاز دارد که ممکن است به یک فرآیند پیچیده و زمان بر تبدیل شود. داده های مورد نیاز برای این هدف به شدت به اجزای در نظر گرفته شده در WSS و نحوه مدل سازی رفتار آنها بستگی دارد. به طور کلی، دادههای مورد نیاز به ویژگیهای فیزیکی اجزای شبکه، دادههای مصرف آب، دادههای ارتفاع، و قوانین عملیاتی [ 10 ] مربوط میشوند. تمام داده های بالا را می توان در یک پلت فرم واحد – GIS ذخیره و مدیریت کرد.
از لحاظ تاریخی، مفهوم و اجرای مدلسازی هیدرولیک در یک پلت فرم GIS با کنجکاوی و انتظارات کاربران انجام شد. دقت نمایش جغرافیایی و صحت و دقت داده های الفبایی عددی مرتبط همیشه در GIS دارای امتیاز بوده است. علاوه بر این، نمایش اتصال (بسیار توسط GIS پشتیبانی می شود) برای مدل سازی هیدرولیک اساسی است. علاوه بر این، قابلیتهای محاسباتی، در دسترس بودن، پیچیدگی و قابلیت همکاری چندین برنامه مدیریت اطلاعات جغرافیایی، بلوغ مورد نیاز GIS را برای استفاده از آن هم بهعنوان جلویی و هم بهعنوان پشتیاند در زمینه مدلسازی هیدرولیک فراهم میکند.
ادغام این راه ها، GIS و مدل سازی هیدرولیک را می توان به عنوان فرآیندی تعریف کرد که در آن عملیات درج، حذف یا به روز رسانی داده های ذخیره شده در سیستم بر روی مدل هیدرولیک منعکس می شود. به نوبه خود، نتایج فرآیند مدل سازی نیز مدیریت و در سیستم ذخیره می شود. شمسی [ 27 ] یک طبقهبندی سه سطحی برای مدلسازی هیدرولیک ایجاد کرد: تبادل ، هر دو سیستم به طور جداگانه عمل میکنند، اطلاعات مورد علاقه توسط یک فایل میانی مبادله میشود. رابط ، هر دو سیستم به طور جداگانه نیز کار می کنند، اما نیازی به فایل تبادل اطلاعات نیست، پیوندی بین دو سیستم بر اساس پروتکل ها و ساختارهای سازگاری برقرار می شود. ادغام واقعی، مربوط به پیچیده ترین سطح یکپارچگی است که در آن هر دو سیستم به عنوان یک واحد عمل می کنند.
2.3. توپولوژی و قوانین اتصال
هنگام ساخت مدل هیدرولیک بر اساس داده های ذخیره شده در پایگاه داده جغرافیایی، اطمینان از اتصال بین اجزای WSS برای یک رابطه عملکردی سازگار بین آن اجزا ضروری است. تعریف و اجرای قوانین توپولوژیکی می تواند به این امر دست یابد. توپولوژی در واقع برای جلوگیری از خطاهای اتصال بسیار مهم است و هدف آن نشان دادن نحوه اتصال لوله ها، شیرها و سایر لوازم جانبی در واقعیت برای تشکیل یک شبکه واحد است. به منظور نمایش صریح و ذخیره روابط فضایی و ویژگی های آنها، چارچوب های توپولوژیکی داده ها معمولا استفاده می شود [ 14 ]. نمایش توپولوژیکی یک شبکه هندسی که در پشت یک WSS قرار دارد ممکن است با در نظر گرفتن یک انتزاع بر اساس مدل منطقی یک گراف، به عنوان مثال، شبکه ای از گره ها و یال ها انجام شود.
برای ویژگی های نقطه ای (مثلاً شیر، دبی سنج)، قوانین زیر باید وضع شود [ 28 ]: آنها باید در انتهای لبه نمودار قرار داشته باشند و باید یکی از نقاط مرز یک عنصر خطی (مثلاً لوله) را قطع کنند. ; موجودی که در انتهای یک بخش قرار دارد باید از نوع واحد باشد و کپی کردن موجودیت ممنوع است. خطاهای معمولی ممکن است شامل، به عنوان مثال (نگاه کنید به شکل 1 )، گره های یتیم، خطاهای گیرکردن (مانند زیر یا بیش از حد)، موجودیت های تکراری، عدم تقسیم بندی موجودیت های خطی در نقطه تقاطع داخلی آن با نقطه باشد.
برای ویژگیهای خطی (مثلاً لوله)، قوانین زیر باید رعایت شود: چنین موجودیهایی نمیتوانند با یکدیگر همپوشانی یا خود تلاقی داشته باشند. اگر موجودیت های خطی با هم تداخل داشته باشند، می توانند مجاز باشند اگر در واقعیت به صورت موازی اجرا شوند. انتهای هر یال باید یک گره گراف را قطع کند. خطاهای همپوشانی ممکن است به دلیل دیجیتالی شدن تصادفی موجودیت فضایی مشابه یا به دلیل هندسه های مشابه موجود مرتبط با ماهیت دو بعدی اطلاعات مکانی باشد. خطاهای snapping ممکن است بین انتهای یک لبه و یک موجودیت WSS که توسط یک گره مدلسازی شده است رخ دهد، یا همچنین ممکن است زمانی رخ دهد که گره به طور تصادفی گم شده باشد ( شکل 1 را ببینید ).
به عنوان مکمل قوانین توپولوژیکی عمومی، توصیه می شود که ایجاد قوانین دیگر منعکس کننده ویژگی های عملکردی و اتصالی خاص موجودیت های مختلف و تعامل آنها در موارد دنیای واقعی باشد. چنین قوانینی ممکن است برای مدلسازی موقعیتهایی مانند دو لوله با قطر متفاوت به مخروط کاهش، اتصال T نیاز به اتصال به سه لوله استفاده شود.
3. روش شناسی
3.1. مشخصات کلی سیستم پیشنهادی
سیستم پیشنهادی در این مقاله مبتنی بر رویکرد مشتری/ارائهدهنده است به گونهای که عملکردهای پیادهسازیشده مستقل از قسمت جلویی مورد استفاده هستند. همانطور که در بالا توضیح داده شد، توسعه مدل مفهومی بر اساس مدل منطقی پشتیبانی شده توسط تئوری گراف است و مدل فیزیکی مرتبط در محیط PostgreSQL 9.3، همراه با پسوند فضایی PostGIS 2.1 پیادهسازی شد که مدیریت شی فضایی را ممکن میسازد. نهادهای فضایی و روابط وابسته در نظر گرفته شده اجازه می دهد تا توصیف و مدیریت اطلاعات کاداستر زیرساخت. به نوبه خود، چنین اطلاعاتی امکان تولید مدلهای هیدرولیک مبتنی بر EPANET 2 را فراهم میکند [ 6]]. چندین سناریو ممکن است شبیه سازی شود و نتایج مربوطه در DBMS جغرافیایی ذخیره شود. اینها را میتوان از طریق نقشهبرداری نشان داد یا از طریق فرم جدولی به آنها دسترسی داشت ( شکل 2 ).
با توجه به قابلیتهای DBMS جغرافیایی، چندین عملکرد و رویه به منظور پر کردن خودکار ویژگیهای مورد علاقه، اعتبارسنجی قوانین اتصال، بهروزرسانی روابط توپولوژیکی یا اجرای شبیهسازیهای هیدرولیکی توسعه داده شد. چنین توابعی به نوبه خود با سایر رویههای ماشهای مرتبط بودند که هر بار که عملیات خاصی اتفاق میافتد، آنها را درخواست میکنند و اجرا میکنند (به عنوان مثال، هر درج/حذف موجودیتهای فضایی، یا هر بهروزرسانی WSS دیگر). همه اینها در pgSQL یا Python کدگذاری شده بودند.
برای اجرای یک شبیهسازی هیدرولیکی خاص، دستورالعملهای SQL باید با استفاده از توابع و رویههای بالا به اضافه دادههای ورودی مربوطه، مانند گزینههای هیدرولیک، پنجرههای زمانی، مقادیر مصرف آب، اطلاعات توپولوژیکی و ارتفاعات، یا خصوصیات فیزیکی اجزای شبکه هندسی اجرا شوند. سپس مدل هیدرولیک مربوطه یا از ابتدا تولید می شود یا به سادگی بر اساس داده های بالا به روز می شود و کد WSS مورد نیاز مشخص می شود.
3.2. مدل داده
در مدل داده، موجودیتهای اصلی WSS تعریف میشوند و روابط جغرافیایی آنها به منظور مدلسازی هستیشناسیهای دنیای واقعی و تعاملات آنها برقرار میشود. به این ترتیب، موجودیت هایی که خصوصیات فیزیکی WSS، ذخیره توپولوژی شبکه هندسی و همچنین سوابق مصرف آب را برای هر اتصال امکان پذیر می کنند، تعریف می شوند. برای اهداف تصویری، شکل 3 (فقط برای دریچهها) ویژگیها و حوزههایی را نشان میدهد که برای توصیف یک سناریوی معین برای مدلسازی و مشخص کردن گزینههای زمانی، همراه با روابط ایجاد شده برای مرتبط کردن نتایج با اجزای مدلسازی شده و با سناریوی مربوطه در نظر گرفته شدهاند.
جدول 1 مولفه های WSS در نظر گرفته شده را خلاصه می کند، جدول رابطه ای وابسته (همانطور که در [ 29 ، 30 ] تعریف شده است)، هندسه مربوطه برای نشان دادن آنها در یک پلت فرم GIS و کدام عنصر گراف برای مدل سازی آنها استفاده می شود.
ویژگی های جدولی پایگاه داده، دامنه های مرتبط و مقادیر پیش فرض برای هر موجودیت WSS تعریف شد. با توجه به وجود یک نوع فیلدهای جدول برای موجودیتهای مجزا و نیاز به پیادهسازی مکانیسمهایی برای اعتبارسنجی مقادیر دامنه، ماسکهای دامنه تعریف شدند (به عنوان مثال، حالت عملیاتی، حالت حفاظت، قطر اجزای مختلف و غیره).
به منظور تضمین یکپارچگی ارجاعی بین نهادها، کلیدهای خارجی پایگاه داده بر این اساس تعریف شدند. علاوه بر این، به منظور دسترسی کارآمدتر به دادهها، شاخصهای مختلف GiST برای کلیدهای اولیه پایگاه داده و همچنین برای ویژگیهای هندسی ایجاد شد.
موجودیتهای مورد نیاز و روابط فضایی مربوطه برای فرآیند مدلسازی، ایجاد گزینههای کلی، توصیف نرخ مصرف آب در سطح گره نمودار، و ایجاد یک کنترل عملیاتی مربوط به هر سناریوی شبیهسازیشده را امکانپذیر میسازد. جداول پایگاه داده نیز به منظور ذخیره داده های ویژگی مؤلفه WSS و همچنین نتایج شبیه سازی (صرف نظر از شبیه سازی استاتیک یا دینامیک) گنجانده شده است.
به عنوان یک مثال گویا، اجازه دهید opcoes و جداول رابطه ای سناریو را در نظر بگیریم . این روابط امکان تکمیل توصیف هر سناریوی شبیه سازی هیدرولیک را فراهم می کند. هر تاپل از رابطه سناریو اجازه می دهد تا کد ID شبیه سازی، کد سیستم مدل سازی شده، واحدهای مصرف، معادله تلفات مداوم سر و مجموعه گزینه های زمانی را ایجاد کند. مشخصه ای که به گزینه های زمانی اشاره می کند از یک کلید خارجی تشکیل شده است که به کلید اولیه در جدول رابطه ای op_tempo اشاره دارد ( شکل 3)در بالا) امکان اشتراک گذاری مجموعه گزینه های زمانی چندگانه را فراهم می کند و به نوبه خود کل پنجره زمانی شبیه سازی، مرحله زمانی هیدرولیک، مرحله زمانی الگو، مرحله زمانی گزارش و سایر گزینه های مشابه را ایجاد می کند.
ایجاد دو جدول رابطهای، ذخیرهسازی نتیجه را با توجه به هر سناریوی مدلسازی انجام میدهد. چنین رویه ای با هر مؤلفه مدل سازی شده مرتبط است ( جدول 1 در بالا). برای هر مؤلفه، رابطه ای که پیشوند آن inp_<nome componente> است ، ملزم به داشتن داده های مستقل از زمان محاسبه آن مؤلفه است. به نوبه خود، نتایج شبیهسازی هیدرولیک در رابطهای که پیشوند آن inp_rpt_<nome componente> است، گنجانده میشود .
برای اجزای مدل هیدرولیک که توسط گرههای گراف نشان داده میشوند، ویژگیهایی که به طور کلی در نظر گرفته میشدند نرخ مصرف، سر و فشار بودند. به نوبه خود، ویژگی هایی که به طور کلی برای موجودیت های لبه گراف در نظر گرفته می شد، سرعت، جریان و افت سر بود. با توجه به اینکه برخی از موجودات WSS در GIS و در مدل هیدرولیک به طور متفاوتی مدلسازی میشوند (مثلاً یک شیر به صورت هیدرولیکی به عنوان لبه و به عنوان یک گره در GIS مدلسازی میشود)، نه تنها نتایج مربوطه با آن موجودیتها مرتبط است، بلکه آنها نیز گره های بالادست و پایین دست به این ترتیب، زمانی که شبیهسازی هیدرولیکی انجام میشود، میتوان به طور مستقیم آن موجودیتها را از طریق هندسه GIS مرتبط با جستجو و دسترسی به ویژگیها و نتایج شبیهسازی به طور همزمان مدیریت کرد.
با در نظر گرفتن موجودیتهای WSS مشخصشده در یک سناریوی معین، جدول رابطهای calibration_param امکان تعریف مقادیر جدید متمایز از مقادیر تئوری از قبل برای هر پارامتر هیدرولیک را فراهم میکند. (مثلاً ضریب زبری). هدف تاپل های ذکر شده کالیبراسیون مدل هیدرولیک است.
3.3. توپولوژی: قوانین اتصال
هدف قوانین اتصال ذکر شده در بخش 2.3 ، برای مثال، تعیین حداکثر تعداد موجوداتی است که یک موجودیت معین می تواند با آنها تلاقی کند، تا از این واقعیت جلوگیری شود که بیش از یک موجودیت در یک گره معین قرار دارد (مثلاً یک متر یا یک شیر). برای ارزیابی اینکه آیا یک یا چند راس از مرز موجودیت خطی (معمولاً یک دریچه) را می توان حذف کرد یا خیر یا برای ارزیابی سازگاری بین اطلاعات مکانی و مدل هیدرولیک، در میان دیگران. مجموعهای از 37 قانون اتصال از طریق روشهای راهانداز مختلف که در جدول 2 خلاصه شدهاند، اجرا شدند .
رویههای ماشهای که در PL/pgSQL طراحی و کدگذاری شدهاند، به منظور تأیید اعتبار قوانین اتصال هستند. برای هر جدول رابطهای، یک رویه ماشه پیادهسازی شد که رویهها و توابع مرتبط را تحریک کرد. قوانین برای هر تاپل، با در نظر گرفتن نوع عملیات SQL (درج، بهروزرسانی یا حذف) بررسی میشوند، اگر یک قانون معین مطابقت نداشته باشد، یک استثنا ثبت میشود. استثناها تراکنشهای مربوطه را خاتمه میدهند و بهروزرسانیهای مرتبط انجام نمیشوند. برای نشان دادن این موضوع، الگوریتم 1 روش ماشهای ()pipeConectivityRulesInsert را نشان میدهد، هدف از آن اعتبارسنجی قوانین اتصال مربوطه برای هر تاپل زمانی است که درج آنها در رابطه لوله رخ میدهد.
| الگوریتم 1. کد شبه الگوریتم پیاده سازی شده برای تایید قوانین اتصال پس از وارد شدن یک لوله جدید به سیستم. |
| رویه pipeConectivityRulesInsert(): If IsSimple(NEW.geom)==TRUE And IsClosed(NEW.geom)==False ptF = st_startpoint(NEW.geom) ptT = st_endpoint(NEW.geom) برای هر نوع مؤلفه WSS تعداد تعداد ویژگی های متقاطع شده توسط ptF اگر شمارش > 0 تماس تأیید قوانین اتصال برای ویژگی متقاطع شده اگر قوانین تأیید نشده است استثناء را افزایش دهید اگر پایان اگر تعداد مؤلفه های متقاطع شده توسط ptT اگر شمارش > 0 تماس تأیید قوانین اتصال برای ویژگی متقاطع شده اگر قوانین تأیید نشد افزایش استثناء End If End If End برای هر تعداد لوله های لمس شده توسط ptF تعداد لوله های لمس شده توسط ptT اگر شمارش ptF> 3 یا تعداد ptT> 3 Raise Exception End If Return New Else افزایش استثنا پایان اگر |
هنگامی که اعتبار سنجی قانون اتصال انجام می شود، نمایش موجودیت در شبکه هندسی بر اساس توپولوژی گره قوس گراف به روز می شود. اجرای این بر این فرض استوار است که هر به روز رسانی کاداستر زیرساختی منجر به به روز رسانی شبکه هندسی جهانی نیز می شود. نگهداری اطلاعات توپولوژیکی به روشی منسجم اجرا شد به طوری که زمان محاسباتی با تولید مدل هیدرولیکی مرتبط کاهش مییابد.
همانطور که در بخش قبل ذکر شد، نمایش هندسی در GIS برخی از اجزای WSS ممکن است با مدل هیدرولیک متفاوت باشد ( جدول 1 ). به این ترتیب، در نظر گرفتن مکانیسم هایی برای به روز رسانی اطلاعات توپولوژیکی به منظور سازگار کردن هر دو انتزاع مورد نیاز بود. به عنوان مثال، موجوداتی مانند شیر کنترل و پمپ، در میان دیگران، به عنوان یک قوس اضافی در بین دو قوس مجاور مربوط به دو بیت حاصل از شکاف خط لوله مدلسازی میشوند، به دلیل سازگاری توپولوژیکی، یک گره اضافی نیز مورد نیاز است ( شکل 4 ).
با توجه به اینکه موجودیتهای WSS خاص اجزای جریان آب یک طرفه را تشکیل میدهند، رویههای ماشه مرتبط این ویژگی را منعکس میکنند که اجرای آن بر اساس لایه GIS مربوطه و همچنین ویژگیهای الفبایی عددی موجودیتها (به عنوان مثال، نوع پمپ) است. در مواردی مانند این، هر به روز رسانی اطلاعات توپولوژیکی با اجرای inp_arc_node “after trigger” انجام می شود، که برای هر رابطه مدل شده و رویه تریگر مرتبط مشخص می شود.
3.4. نمایش اجزای WSS در مدل هیدرولیک
برای هر جزء WSS، یک نمایش متناظر در مدل هیدرولیک با توجه به ویژگیهای خاص و عملکرد هیدرولیکی آنها ایجاد شد ( جدول 3 را ببینید ).
3.5. اطلاعات ارتفاع
از جمله ویژگی Elevation برای تمام اجزای WSS از نوع هندسی نقطه ای، در نظر گرفتن اطلاعات ارتفاع انجام شد. به نوبه خود، تا آنجا که به خطوط لوله مربوط می شود، چنین اطلاعاتی با گره های اتصال آنها مرتبط بود.
دو موقعیت مختلف و روش های مربوطه ممکن است از قبل شناسایی شوند. هنگامی که مقدار Elevation گم شده باشد، با تقاطع جزء WSS مرتبط با یک مدل زمین دیجیتال با فرمت شطرنجی (DTM) بازیابی می شود. این کار با روش تریگر elevation_insert (نگاه کنید به شکل 5 ) انجام می شود، که با توجه به قابلیت های PostGIS از نظر دسترسی و ذخیره سازی داده های شطرنجی پیاده سازی شده است. با تعریف روش تریگر ارتفاع در جداول رابطه ای مربوطه، این امر توسط هر تاپل و دستورالعمل های درج یا به روز رسانی برانگیخته می شود.انواع وضعیت دیگر به به روز رسانی داده های ارتفاع یک گره اتصال داده شده اشاره دارد. این بر اساس یک مؤلفه WSS که در همان مکان درج شده است و مقدار ارتفاع آن گم نشده است انجام می شود ( روش ماشه elevation_updt ، به شکل 5 مراجعه کنید ). در این مورد، تریگر node_elevation برای هر جدول رابطه ای که آن را با رویه تریگر مربوطه جفت می کند، تعریف شد.
3.6. داده های مصرف
دادههای مصرف آب به همراه حجم تلفات آب برای توصیف تقاضای کلی در یک WSS، هم مکانی و هم زمانی است. اطلاعات بالا در واقع برای تعریف سناریوی مدلسازی هیدرولیک مرتبط اهمیت زیادی دارد. این به صورت عملی با مرتبط کردن ارقام مصرف مختلف، که در امتداد یک بخش خط لوله رخ می دهد، با گره های مربوطه انجام می شود. در سیستم ما، جداول رابطه ای مورد نیاز برای مشخصات نرخ مصرف پایه برای هر گره از یک سناریوی معین تعریف شده است. علاوه بر این، در صورت شبیهسازیهای بلندمدت، روابط خاصی نیز برای ایجاد الگوهای زمانی اجرا شد ( شکل 6 را ببینید ).
رویکرد پیادهسازی اتخاذ شده، مشخصات هر گره از مجموعهای از تاپلها را که نشاندهنده نرخهای مصرف، تجمعی در میان آنها هستند، ممکن میسازد، که ممکن است الگوهای متمایز داشته باشند. هر الگو با مجموعه ای از عوامل ضربی مشخص می شود که در جدول رابطه ای Pattern_points تعریف شده اند . این رویکرد ساختار اطلاعات را به گونهای امکانپذیر میسازد که به راحتی قابل دسترسی باشد و بتوان آن را در فایل INP درج کرد (به بخش 3.8 مراجعه کنید ). فایل INP مسئول اجرای شبیهسازی هیدرولیک استاتیک/دینامیک است.
توصیف مصرف آب ممکن است به طور خودکار بر اساس ساده سازی نرخ های مصرف متشکل از غلظت نرخ ها در گره و/یا به گره بخش خط لوله مربوطه انجام شود. رویه junction_of_demand (کدگذاری شده در PL/pgSQL) رابطه تقاطع بین مرز شاخه و قسمت داخلی خط لوله را در نظر می گیرد. به این ترتیب، برای هر انشعاب، فاصله بین نقطه تقاطع آن و بخش خط لوله از گره محاسبه میشود – سپس نرخ مصرف آب که به آن شاخه اشاره میکند با نزدیکترین گره (گره اتصال بخش خط لوله) مرتبط میشود. چنین رویه ای توسط st_line_locate_point پشتیبانی می شودتابع، در پسوند فضایی PostGIS. به منظور محاسبه نرخ مصرف برای هر مصرف، کنتورهای آب مرتبط و سوابق صورتحساب آنها در نظر گرفته می شود که در DBMS جغرافیایی از طریق سیستم مدیریت ارتباط با مشتری (CRM) مشخص می شود.
با توجه به یک سناریوی هیدرولیک خاص، مصرف پایه برای هر گره محاسبه می شود و در جدول رابطه ای Demand قرار می گیرد . برای این منظور، رویه assign_demand بر اساس رویه شرح داده شده در بالا ایجاد شد که پارامترهای ورودی آن به شرح زیر است: کد سناریوی هیدرولیک، درصد تلفات هد در سیستم، تعداد کل سال های صورتحساب در نظر گرفته شده برای ارزیابی میانگین مصرف، و همچنین (در صورت شبیهسازی هیدرولیکی دینامیکی) نمودار مصرف – در مواردی که نمودار مصرف در دسترس نباشد، نرخهای مصرف محاسبه میشود و سپس بر اساس میزان جمعیت خدمترسانیشده در منطقه جغرافیایی مدلسازی شده محاسبه میشود.
3.7. کنترل های عملیاتی
به منظور انعکاس شرایط عملیاتی WSS در مدل هیدرولیک (به عنوان مثال، شروع و توقف یک پمپ تحت کنترل سطح آب مخزن)، رویه عملیاتی_کنترل در نظر گرفته شد تا تعریف کنترلهای ساده ( کنترلها ) یا کنترلهای چندگانه شرایط ( قوانین ) را امکانپذیر کند. . هر تاپل مربوط به یک کنترل خاص است که بر اساس نوع آن طبقه بندی می شود و با سناریوی خاصی مطابق با دستور EPANET toolkit مرتبط است. این با رویه validate_operational_control کدگذاری شده در PL/Python بررسی می شود.
3.8. ایجاد مدل هیدرولیک و اجرای شبیه سازی – فایل INP
پس از تعریف کلیه نهادها و ویژگی های آنها که مسئول مدیریت WSS هستند، اطلاعات خصوصیات فیزیکی، اطلاعات ارتفاع، اطلاعات توپولوژیکی، اطلاعات مصرف آب و کنترل های عملیاتی و همچنین گزینه های هیدرولیکی و زمانی برای سناریوی مدل سازی داده شده، امکان پذیر است. تمام بخش های فایل INP را پر کنید. فایل INP توسط cria_inp تولید می شودرویه (کدگذاری شده در PL/Python)، که پارامترهای ورودی آن کد سناریوی هیدرولیک و کد منطقه جغرافیایی است. دستورالعملهای SQL که باید اجرا شوند اساساً شامل روشهای انتخاب رایج یا از طریق اتصال به جدول، با انتخاب فیلدهای جدول موجود در جداول مختلف (پیشبینی) با توجه به اطلاعات مربوطه برای اهداف خصوصیات بخش است. دسترسی به دادهها با استفاده از ماژول plpy انجام میشود ، که وقتی PL/Python در DBMS استفاده میشود، بهطور خودکار وارد میشود. سپس هر رکورد با پیروی از قوانین نحوی هر بخش [ 31 ] در فایل خروجی نوشته میشود .
توابع PostGIS به طور مساوی برای بازیابی اطلاعات مربوطه در نظر گرفته می شوند. در مشخص کردن بخش [JUNCTIONS] ، هر دو تابع st_x و st_y امکان بازیابی جفت مختصات ( x,y ) را از نوع هندسه نقطهای که هر گره اتصال را مشخص میکند، میکنند.
رویه PL/Python processa_inp به منظور اجرای مدلسازی هیدرولیکی، استاتیک یا دینامیکی اجرا شد ( شکل 7 را ببینید ). رویه بالا توسط فایل INP ایجاد شده از قبل انجام می شود و نتایج مرتبط پس از آن در پایگاه داده برای هر مؤلفه مدل شده درج می شود، این کار مطابق با سرعت زمانی در نظر گرفته شده در سناریوی موجود انجام می شود. برای هر جزء، ( inp_<entity_name> ) جدول رابطه ای در نظر گرفته می شود که در آن داده ها مستقل از حالت اولیه و از دوره زمانی محاسباتی (به عنوان مثال، قطر، طول، ارتفاع)، (inp_rpt_<entity_name>) جدول رابطه ای نیز در نظر گرفته می شود. با هدف ذخیره نتایج مربوطه
مدلسازی هیدرولیک در واقع با استفاده از مجموعه توابع به شرح زیر انجام می شود، ENopenH – ENinitH – ENrunH – ENnextH – ENcloseH ، همچنین به توابع ENgetxxx برای دسترسی به نتایج موقت هر مرحله محاسباتی اشاره دارد ( شکل 7 ). روش LoadLibrary ، از کلاس windll ( ماژول ctypes )، توابع بارگیری بالا را از طریق جعبه ابزار EPANET فعال می کند .
4. مطالعه موردی: Casal-do-Ribeiro WSS
4.1. استفاده از پلاگین UrbanWater
یک شبیهسازی هیدرولیک، ایستا یا دینامیک، با اجرای رویههای شرح داده شده در بخش 3 از طریق دنبالههای دستورالعمل SQL مناسب به دست میآید. برای این منظور، برنامه UrbanWater توسعه یافت – یک افزونه پیادهسازی شده در پایتون برای پلتفرم Quantum GIS (QGIS) ( شکل 8 ).
پلاگین UrbanWater مشخصات پارامترهای مورد نیاز را فعال می کند. همچنین فیلتر کردن نتایج ذخیره شده در پایگاه داده مربوط به سناریوی شبیه سازی مربوطه را فعال می کند. علاوه بر این، برای لایههای کلاس ویژگی مبتنی بر گره یا لبه، میتوان انتخاب کرد که کاربر چه پارامتری را میخواهد نگاشت کند، در چنین حالتی، ویژگیهای نمایش مرتبط و افسانه به طور خودکار بهروزرسانی میشوند. تعامل با PostSQL DBMS از طریق آداپتور psycopg 2.5 برای زبان برنامه نویسی پایتون انجام می شود.
UrbanWater علاوه بر فعال کردن تولید نقشه های موضوعی بر اساس پارامترهای انتخاب شده، دارای ویژگی است که نمودار نموداری از نتایج به دست آمده برای پارامترهای مختلف انتخاب شده را در یک لایه GIS فعال (که اجرای کد پایتون از کتابخانه matplotlib استفاده می کند) را فعال می کند. برای ویژگی های نشان داده شده در مدل هیدرولیک توسط گره ها، نرخ مصرف، هد، و فشار ارائه شده است. به نوبه خود، برای ویژگی های مبتنی بر لبه، سرعت، جریان، و افت مداوم سر همراه با نتایج به دست آمده برای هر دو گره بالادست و پایین دست نشان داده شده است.
4.2. شرح مطالعه موردی
Casal-do-Ribeiro یک محله مدنی روستایی است که در ناحیه اورم (استان لیریا، مرکز غربی سرزمین اصلی پرتغال) واقع شده است. WSS منشأ خود را در یک منبع آب زیرزمینی (SL1) دارد و آب از طریق یک پمپ شناور تا مخزن اصلی محلی بالا می رود. آب تصفیه شده بعداً توزیع شده و به صورت گرانشی به ایستگاه پمپاژ Casal-da-Fonte اضافه می شود. این اداکشن 1.8 کیلومتر گسترش دارد که عمدتاً از مواد PVC و HDPE تشکیل شده است. شبکه توزیع دارای طول کل 39.1 کیلومتر است که شامل لوله های پی وی سی (99.8%) می باشد که 50% قطرهای آن کمتر یا مساوی 110 میلی متر، حداکثر قطر 160 میلی متر با 846 مشتری و 817 اتصال می باشد. کاداستر WSS های مختلف در ناحیه اورم در قالب طراحی به کمک رایانه (CAD) (جزء هندسی) و داده های الفبایی عددی مربوطه در Oracle 8i DBMS ذخیره می شود. یک ماژول پیاده سازی شده در Bentley MicroStation مدیریت و همگام سازی اطلاعات ذخیره شده در هر دو منبع داده را امکان پذیر می کند. برای اهداف ما، دادههای برداری و الفبایی به هم پیوستند و بعداً برای هر موجودیت مورد علاقه به فرمت شکل فایل ESRI صادر شدند.
به منظور تسهیل دستکاری داده ها برای هر مؤلفه، داده های بالا بر روی یک DBMS PostgreSQL آپلود شدند. با استفاده از دستورات SQL، دامنهها و ویژگیهای موجودیتهای مختلف از نظر مدل دادههای پیشنهادی و همچنین اعتبارسنجی و حل تضادهای ناشی از عدم انطباق با قوانین اتصال و خطاهای توپولوژیکی تطبیق داده شدند. توصیف مصرف مشتری مربوط به هر نصب از سیستم صورتحساب بر اساس میانگین مصرف روزانه 2012-2013 به دست آمد.
با توجه به این واقعیت که برخی از ویژگی های پیاده سازی شده به داده های ارتفاع برای هر گره اتصال نیاز دارند، یک مدل زمین دیجیتال (DTM) تولید و در قالب شطرنجی ذخیره شد.
سناریوی مدلسازی مرتبط با در نظر گرفتن تمام اجزای فیزیکی که WSS Casal-do-Ribeiro را تشکیل میدهند، با توجه به اطلاعات کاداستر موجود و مدل داده پیشنهادی، تعریف شد. به منظور در نظر گرفتن بیشترین حجم اطلاعات ممکن (به عنوان مثال، الگوهای نرخ مصرف)، یک رویکرد شبیه سازی پویا در نظر گرفته شد، که با مدت زمان 72 ساعت مطابقت دارد.
کنترل های عملیاتی مربوط به عملیات تجهیزات پمپاژ، برگرفته از سیستم مدیریت از راه دور پیاده سازی شده، در نظر گرفته شد. پارامترهای شیر کنترل با توجه به سوابق تعمیر و نگهداری ایجاد شد.
4.3. اجرای مدل هیدرولیک
همانطور که در بالا توضیح داده شد، ایجاد فایل INP، اجرای مدل و پردازش نتایج با تعریف و اجرای یک سری دستورات مختلف SQL انجام می شود. در ابتدا، مجموعه ای از گزینه های زمانی با قرار دادن تاپل مربوطه در رابطه op_tempo ( schema modelacao ) تعریف شد. سپس، سناریو از طریق رویه create_cenario تعریف شد ، به طور متناوب، می توان تاپل را در سناریو قرار داد.رابطه، همچنین معیار انتخاب مؤلفه WSS را نشان می دهد. هر گره ممکن است دسته های مصرف متفاوتی داشته باشد که هر کدام به نوبه خود نمودار مصرف خود را دارند. سپس فایل INP ایجاد شد، مدل هیدرولیکی حاصل آنالیز شد و نتایج خوانده شد و در پایگاه داده درج شد. برای اهداف بالا، دستورات SQL زیر به صورت زیر اجرا شد:
SELECT modelacao.cria_inp(‘CRB-MED-72H’);
SELECT modelacao.processa_inp(‘CRB-MED-72H’);
اولین دستور SQL بالا، تولید فایل INP را انجام می دهد، با اشاره به سناریوی مدل شده، که ورودی مدل EPANET است ( شکل 9 ).
دومین دستورالعمل SQL بالا، تجزیه و تحلیل هیدرولیک را با استفاده از توابع جعبه ابزار EPANET انجام می دهد .
4.4. نتایج
شکل 10 نتایج گرافیکی به دست آمده برای جزء سیستم انتخاب شده را نشان می دهد: سرعت، جریان و افت هد. نمایش بصری نتایج مبتنی بر گرافیک توسط ویژگی های مرتبط پیاده سازی شده در پلاگین UrbanWater (QGIS) فعال می شود.
بر اساس سناریویی که قبلاً تنظیم شده بود، تجزیه و تحلیل سرعت برای مقاطع لوله انجام شد ( شکل 11 ). یک فیلتر روی دادهها اعمال شد تا از طریق پلاگین توسعهیافته نقشهبرداری شوند و هم سناریو و هم پنجره زمانی شبیهسازی مورد نظر انتخاب شوند.
علاوه بر تولید سریع فایل INP، مزیت دیگر ذخیره سازی نتایج در یک DBMS مکانی، امکان استفاده مشترک از هر دو ویژگی DBMS و نقشه برداری است. شکل 12 نشان می دهد که چگونه مدیر پایگاه داده (DB) پلاگین در یک پرس و جوی SQL برای نقشه برداری جغرافیایی تمام لوله هایی که در آنها سرعت بالاتر از حداکثر آستانه مجاز است، استفاده شده است.
5. نتیجه گیری ها
5.1. ملاحظات نهایی
ایجاد مدل مفهومی، تعریف موجودیتهای مورد نیاز را در نظر گرفت که مدلسازی هیدرولیکی مبتنی بر EPANET 2 را فعال میکرد. رویکرد انجام شده به سادگی موجودیت های استاندارد EPANET را تکرار نمی کند. در واقع، ما همچنین به دنبال مدیریت دادههای کاداستر WSS کاملاً مبتنی بر یک DBMS منبع باز بودیم که بر اساس آن قابلیتهای مدلسازی سناریوهای هیدرولیکی مختلف و رویههای تحلیل مرتبط پیادهسازی شدند. رویهها و توابع پیادهسازی شده در DBMS در زبانهای برنامهنویسی ضروری، نمایش یک WSS مشخص را که کاملاً با مدل عددی هیدرولیک تعریفشده در فایل INP سازگار است، فعال میکنند. این واقعیت امکان جمع آوری داده های کاداستر WSS و همچنین داده های ورودی و خروجی از سناریوهای شبیه سازی شده مدل سازی هیدرولیک را در یک پایگاه داده واحد فراهم می کند.
راهحل سیستم پیشنهادی در این مقاله رایجترین گزینههای EPANET را به گونهای پیادهسازی میکند که میزان تلاش، منابع و زمان صرف شده برای ساخت مدلهای هیدرولیک کافی را به میزان قابل توجهی کاهش میدهد. این واقعیت در واقع با حذف کارهای دستی رایج تبدیل و برقراری ارتباط بین داده های ورودی و مدل هیدرولیک یا حتی سازگار کردن آنها به دست می آید. نتایج بهدستآمده برای سناریوهای مختلف شبیهسازی شده میتواند برای تولید گزارشها و/یا شاخصها استفاده شود. مدیریت و دسترسی به نتایج بهدستآمده به وضوح توسط ویژگیهای استاندارد DBMS، مانند پرسوجوها، دسترسی چند کاربره، یا خدمات نقشهبرداری وب، تقویت میشود.
به عنوان نکته پایانی، ادغام ظرفیت تبدیل WSS به یک مدل هیدرولیکی، اجرای شبیهسازی هیدرولیک و در دسترس قرار دادن نتایج از طریق یک DBMS جغرافیایی، به فرد اجازه میدهد تا مجموعهای از انواع مختلف تجزیه و تحلیل را انجام دهد که همه با هم باعث میشود سیستم یک سیستم را توسعه دهد. ارزش افزوده برای اهداف ارزیابی و بهینه سازی مدیریت WSS.
5.2. کار آینده
تا آنجا که به قوانین اتصال برقرار شده مربوط می شود، باید تاکید کرد که این قوانین از قبل رویه های ویرایش/رقومی کردن سختی را بر روی داده های کاداستر WSS تحمیل می کنند. به منظور غلبه بر موقعیتهای ویرایش همزمان ویژگی، ترتیب درج یا بهروزرسانی هر تغییری باید هر قانون اتصال ایجاد شده برای همه عناصر درگیر را در نظر بگیرد. سپس، هر تغییری که روی یک لایه GIS انجام میشود، باید از نظر توپولوژیکی اعتبارسنجی شده و قبل از رفتن به یک لایه GIS دیگر و غیره ذخیره شود.
تخصیص خودکار مصرف نیز باید بهبود یابد.
در مورد جنبههای مدلسازی، ادغام قابلیتهای مدلسازی محیطی نیز اهمیت زیادی دارد، به عنوان مثال، شبیهسازی کیفیت آب.
علاوه بر پیشرفتهایی که در بالا توضیح داده شد، با رایانه و قابلیتهای ارتباطی جدید، روشهای توسعهیافته ممکن است به توسعه بیشتر ابزارهای پشتیبانی تصمیم کمک کنند. این ابزارها ممکن است نه تنها از نظر رایانه های مستقل، بلکه از نظر دستگاه های تلفن همراهی که می توانند به طور مستقل کار کنند یا دسترسی از راه دور و/یا اطلاعات GIS را به روز کنند، توسعه داده شوند.
منابع
- برواست، اس. ریگ، اچ. Sægrov, S. بررسی پایداری بلندمدت راهبردهای احیای سیستم آب شهری با رویکردی جایگزین. پایداری 2018 ، 10 ، 1987. [ Google Scholar ] [ CrossRef ] [ نسخه سبز ]
- مارتین، سی. کامارا، او. برزوسا، آی. Badiola، پلت فرم JL Smart GIS که دیجیتالی کردن سیستم یکپارچه زهکشی شهری را تسهیل می کند. محیط زیست مدل. نرم افزار 2020 , 123 , 104568. [ Google Scholar ] [ CrossRef ]
- شمسی، U. کاربردهای GIS برای سیستمهای آب، فاضلاب و طوفان ; CRC Press: Boca Raton، CA، USA، 2005. [ Google Scholar ]
- مک کینی، دی سی؛ Cai، X. پیوند GIS و مدل های مدیریت منابع آب: یک روش شی گرا. محیط زیست مدل. نرم افزار 2002 ، 17 ، 413-425. [ Google Scholar ] [ CrossRef ]
- اوریچ، سی. Rauch, W. بررسی مسیرهای حیاتی برای مدیریت آب شهری برای شناسایی استراتژی های قوی تحت عدم قطعیت های عمیق. Water Res. 2014 ، 66 ، 374-389. [ Google Scholar ] [ CrossRef ] [ PubMed ]
- Rossman, L. EPANET 2 — راهنمای کاربر ; (EPA/600/R-00/057)؛ دفتر تحقیق و توسعه، آژانس حفاظت از محیط زیست ایالات متحده: سینسیناتی، OH، ایالات متحده آمریکا، 2000. [ Google Scholar ]
- مک فرسون، تی.ان. Witkowski، M. مدلسازی تقاضای آب شهری در یک GIS با استفاده از مدل تحرک جمعیت. در تأثیرات تغییر اقلیم جهانی ; انجمن مهندسین عمران آمریکا: Reston، VA، ایالات متحده آمریکا، 2005; صص 1-8. [ Google Scholar ]
- هاوس-پیترز، لس آنجلس; چانگ، اچ. مدلسازی تقاضای آب شهری: بررسی مفاهیم، روشها و اصول سازماندهی. منبع آب Res. 2011 ، 47 . [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
- Panagopoulos، GP; Bathrellos، GD; Skilodimou، HD; Martsouka، FA نقشه برداری تقاضای آب شهری با استفاده از تجزیه و تحلیل چند معیاره و GIS. منبع آب مدیریت 2012 ، 26 ، 1347–1363. [ Google Scholar ] [ CrossRef ]
- آژانس حفاظت از محیط زیست ایالات متحده (USEPA). تجزیه و تحلیل سیستم توزیع آب: مطالعات میدانی، مدلسازی و مدیریت. راهنمای مرجع برای Utilities ; (EPA/600/R-06/028)؛ دفتر تحقیق و توسعه، آژانس حفاظت از محیط زیست ایالات متحده: سینسیناتی، OH، ایالات متحده آمریکا، 2005. [ Google Scholar ]
- راموس، اچ ام. مک نابولا، ا. لوپز-جیمنز، PA; Pérez-Sánchez، M. مدیریت هوشمند آب به سمت شبکه های پایدار آب در آینده. Water 2020 ، 12 ، 58. [ Google Scholar ] [ CrossRef ] [ نسخه سبز ]
- ژائو، ال. لیو، ز. Mbachu، J. یک روش یکپارچه BIM-GIS برای برنامه ریزی سیستم توزیع آب. ISPRS Int. J. Geo Inf. 2019 ، 8 ، 331. [ Google Scholar ] [ CrossRef ] [ نسخه سبز ]
- شوک، ام آر. Clement، JA با این داده ها نمی توانید این کار را انجام دهید! یا: استفاده و سوء استفاده از تجزیه و تحلیل نظارت بر آب لوله کشی. در مجموعه مقالات کنفرانس ملی حل مسائل زیست محیطی با سیستم های اطلاعات جغرافیایی (EPA/625/R-95/004)، سینسیناتی، OH، ایالات متحده، 21-23 سپتامبر 1994; دفتر تحقیق و توسعه، آژانس حفاظت از محیط زیست ایالات متحده: سینسیناتی، OH، ایالات متحده آمریکا، 1995; صص 31-41. [ Google Scholar ]
- تئوبالد، دی. توپولوژی بازبینی کرد: نشان دهنده روابط فضایی. بین المللی جی. جئوگر. Inf. سیستم 2001 ، 15 ، 689-705. [ Google Scholar ] [ CrossRef ]
- Rossman, L. Computer Models/Epanet. در کتاب سیستم های توزیع آب ; میز، LW، اد. McGraw-Hill: نیویورک، نیویورک، ایالات متحده آمریکا، 2000; صفحات 12.1-12.23. [ Google Scholar ]
- Ormsbee, L. تاریخچه تجزیه و تحلیل شبکه توزیع آب: عصر کامپیوتر. در مجموعه مقالات هشتمین سمپوزیوم تحلیل سیستم های توزیع آب، سینسیناتی، OH، ایالات متحده آمریکا، 27 تا 30 اوت 2006. صص 1-6. [ Google Scholar ]
- والسکی، تی. چیس، دی. ساویک، دی. گریمن، دبلیو. بکویث، اس. کوئل، ای. مدلسازی و مدیریت توزیع آب پیشرفته . انتشارات موسسه بنتلی: Waterbury، CT، ایالات متحده، 2007. [ Google Scholar ]
- ماچل، جی. Mounce، SR; Boxall، JB مدل سازی آنلاین سیستم های توزیع آب: مطالعه موردی انگلستان. بنوشید. مهندسی آب علمی 2010 ، 3 ، 21-27. [ Google Scholar ] [ CrossRef ]
- گومز، آر. مارکز، آ. Sousa، J. طراحی مناطق اندازه گیری شده منطقه و گزینه های مختلف تصمیم گیرندگان: تجزیه و تحلیل هزینه. منبع آب مدیریت 2013 ، 27 ، 4527-4543. [ Google Scholar ] [ CrossRef ]
- آراجو، LS; راموس، اچ. کوئلیو، کنترل فشار ST برای به حداقل رساندن نشت در مدیریت سیستم های توزیع آب. منبع آب مدیریت 2006 ، 20 ، 133-149. [ Google Scholar ] [ CrossRef ]
- مطیعی، ح. مک بین، ای. مطیعی، ع. برآورد آب محاسبه نشده فیزیکی (UFW) در شبکه های توزیع با استفاده از مدل های شبیه سازی و GIS. Urban Water J. 2007 , 4 , 43-52. [ Google Scholar ] [ CrossRef ]
- گومز، آر. مارکز، آ. Sousa, J. برآورد مزایای حاصل از مدیریت فشار در سیستم های توزیع آب. Urban Water J. 2011 , 8 , 65-77. [ Google Scholar ] [ CrossRef ]
- ریبیرو، ال. سوزا، جی. مارکز، آ. Simões, N. مکان یابی نشت ها با پشتیبانی از الگوریتم TrustRank. آب 2015 ، 7 ، 1378–1401. [ Google Scholar ] [ CrossRef ]
- پیتروچا-اوربانیک، ک. Studzinski، A. مطالعه موردی شبیه سازی شکست خطوط لوله انجام شده در سیستم تامین آب انتخاب شده. Eksploat. Niezawodn 2017 , 19 , 317–323. [ Google Scholar ] [ CrossRef ]
- پیتروچا-اوربانیک، ک. Studzinski، A. تجزیه و تحلیل کیفی خطر شکست لوله های آب از نظر ایمنی تامین آب. مهندس شکست. مقعدی 2019 ، 95 ، 371-378. [ Google Scholar ] [ CrossRef ]
- استودزینسکی، آ. Pietrucha-Urbanik، K. تجزیه و تحلیل خطر شکست سیستم های توزیع آب با استفاده از مدل های هیدرولیکی بر روی داده های میدانی واقعی. Ekonomia i Środowisko 2019 ، 68 ، 152–165. [ Google Scholar ]
- شمسی، U. GIS و ادغام مدلسازی. اخبار CE 2001 ، 13 ، 46-49. [ Google Scholar ]
- لندت، بی. کووال، ای. گینتر، پ. سیاه، A. ادواردز، جی. Ray, R. اتصال به شبکه. در مدلسازی هیدرولیک و GIS ; آرمسترانگ، ال.، اد. ESRI Press: Redlands, CA, USA, 2012; ص 41-49. [ Google Scholar ]
- Codd, E. A Model Relational Data for Large Data Banks. اشتراک. دانشیار محاسبه کنید. ماخ 1970 ، 13 ، 377-387. [ Google Scholar ] [ CrossRef ]
- Worboys، M. پایگاه های داده رابطه ای و فراتر از آن. در سیستم های اطلاعات جغرافیایی: اصول، تکنیک ها، مدیریت و کاربردها (ویرایش خلاصه شده) ; Longley, P., Goodchild, M., Maguire, D., Rhind, D., Eds. جان وایلی و پسران: هوبوکن، نیوجرسی، ایالات متحده آمریکا، 2005; صص 373-384. [ Google Scholar ]
- راسمن، ال. جعبه ابزار برنامه نویس EPANET برای تجزیه و تحلیل سیستم های توزیع آب. در مجموعه مقالات کنفرانس برنامه ریزی و مدیریت منابع آب، تمپ، AZ، ایالات متحده آمریکا، 6-9 ژوئن 1999. صص 1-10. [ Google Scholar ]
شکل 1. مثالی از خطاهای توپولوژیکی معمولی: ( الف ) گره های یتیم. ( ب ) گره از دست رفته در انتهای لبه. ( ج ) خودتقاطع لبه.
شکل 2. مدل مفهومی سیستم پیشنهادی: داده های ذخیره شده در سیستم و توابع پیاده سازی شده در سیستم مدیریت پایگاه داده جغرافیایی (DBMS) ساخت مدل هیدرولیک (بر اساس مدل عددی EPANET) و اجرای آن (از طریق دستورالعمل های SQL) را امکان پذیر می کند.
شکل 3. ویژگی ها و حوزه های در نظر گرفته شده به منظور توصیف سناریوی مورد نظر و مشخص کردن گزینه های زمانی، نمونه ای از روابط ایجاد شده برای ارتباط نتایج با سناریو و اجزای مدل شده مربوطه (مورد خاص دریچه).
شکل 4. نمایش مدل توپولوژیک گره قوس و به روز رسانی آن پس از درج یک جزء مشخص در سیستم: ( الف ) همان جهت جریان در نقطه درج. ( ب ) جهت جریان همگرا در نقطه درج. ( ج ) جهت جریان واگرا در نقطه درج.
شکل 5. فلوچارت رویه های راه اندازی elevation_insert و elevation_updt.
شکل 6. نهادهای در نظر گرفته شده برای توصیف مصرف آب در هر گره اتصال از یک سناریوی معین.
شکل 7. فلوچارت جزئی رویه processa_inp که فرآیند مدلسازی هیدرولیک را اجرا می کند.
شکل 8. UrbanWater (برچسب ها به زبان انگلیسی درج شده اند): یک پلاگین سیستم اطلاعات جغرافیایی کوانتومی (QGIS) که برای اهداف شبیه سازی هیدرولیک توسعه یافته است ( الف ) پارامترهای سناریوی شبیه سازی. ( ب ) نتایج شبیه سازی.
شکل 9. تجسم اطلاعات موجود در فایل INP ایجاد شده در EPANET: ( الف ) نمایش جغرافیایی Casal-do-Ribeiro WSS. ( ب ) مصرف مشتری در محل اتصال 447. ( ج ) نرخ مصرف؛ ( د ) منحنی مشخصه پمپ در ایستگاه پمپاژ Casal-da-Fonte.
شکل 10. سرعت (m/s)، جریان (m3 / h) و افت هد (m/km) برای لولههای 744، 746 و 764، در طول دوره شبیهسازی ( افزونه UrbanWater ).
شکل 11. نمایش بصری سرعت، به ترتیب در سیستم اطلاعات جغرافیایی کوانتومی (QGIS) و EPANET.
شکل 12. در رنگ قرمز – مقاطع لوله که در آنها سرعت بالاتر از حداکثر آستانه مجاز است، در طول دوره شبیه سازی (پنجره SQL، برچسب ها به زبان انگلیسی درج شده است).
بدون دیدگاه