نقشه راه GIS

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

09120049370

8 صبح تا 12 شب

09120049370

Telegram Whatsapp Youtube
کاربرد جی ای اس

خلاصه

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

TERENO ; خدمات مشاهده حسگر (SOS) ; SWE ; OGC ; داده های شطرنجی

 

چکیده گرافیکی

1. معرفی

ایستگاه‌های اندازه‌گیری درجا برای مشاهده پدیده‌های فیزیکی (مانند دما، رطوبت خاک و غیره ) همیشه به یک نقطه جغرافیایی مرتبط هستند. نتیجه این اندازه‌گیری‌ها، پدیده مشاهده‌شده را برای این نقطه خاص به عنوان یک سری زمانی از مقادیر اسکالر کمی نشان می‌دهد. در مقابل، ایستگاه‌های سنجش از دور داده‌های متمایز منطقه‌ای مربوط به یک منطقه جغرافیایی خاص را ارائه می‌دهند و پدیده مشاهده‌شده را به‌عنوان یک سری زمانی از داده‌های شطرنجی کمیت می‌کنند. کنسرسیوم فضایی باز (OGC) دو استاندارد را برای دسترسی به داده های سری زمانی شطرنجی ارائه می دهد: WCS و SOS.
رویکرد رایج برای دسترسی استاندارد شده به داده های شطرنجی، استاندارد سرویس پوشش وب OGC (WCS) است. به طور کلی، مشخصات WCS هیچ جزء زمانی را در نظر نمی گیرد. با این حال، از نسخه 2.0 استاندارد WCS قادر به مدیریت آرایه های چند بعدی است که می تواند برای گنجاندن یک بعد زمانی استفاده شود. محبوب ترین و جامع ترین پیاده سازی استاندارد WCS پروژه rasdaman است ( http://www.rasdaman.org). علاوه بر اجرای اجباری استاندارد اصلی WCS 2.0، افزونه WCS-T را برای درج استاندارد داده، پسوند WCS-EO برای دسترسی به مشاهدات زمین و استاندارد OGC WMS برای دسترسی به تصاویر را نیز پیاده‌سازی می‌کند. هنر مدیریت داده های شطرنجی به عنوان مثال، WCS-EO از یک شبکه دو بعدی (EO-coverage)، یک جعبه محدود کننده WGS84 و یک مجموعه فراداده اضافی (EO-Matadata) استفاده می کند. در این ابرداده اضافی، رابطه زمانی هر مجموعه داده مشخص شده است. یک عملیات جدید (DescribeEOCoverageSet) تعریف شده است که شرحی از هر مجموعه داده شامل رابطه زمانی آن را برمی گرداند. خود مجموعه داده را می توان با فیلترهای زمانی انتخاب کرد و توسط عملیات GetCoverage با استفاده از شناسه های منحصر به فرد مجموعه داده ها درخواست کرد.
استاندارد سرویس مشاهده سنسور OGC (SOS) شامل روش هایی برای دسترسی استاندارد به انواع داده های سری زمانی با ارتباط فضایی با زمین است. برخلاف WCS(-EO)، که هیچ توجه ذاتی به مرجع زمانی ندارد، SOS رابطه زمانی هر مجموعه داده را به ارث می برد، اما بیشتر از یکپارچگی جامد در چارچوب فعال سازی وب حسگر (SWE) OGC، که ” کشف حسگرها و مشاهدات مربوطه، تبادل و پردازش مشاهدات حسگر، و همچنین وظیفه سنسورها و سیستم های حسگر ” [ 1]. به طور خاص، استاندارد OGC SensorML قابلیت هایی را برای توصیف تجهیزات نصب شده و کل فرآیند جمع آوری و آماده سازی داده ها فراهم می کند که برای WCS(-EO) در دسترس نیست. علاوه بر این، یک SOS از کاربرد فیلترهای موضوعی برای استخراج ویژگی های موضوعی داده ها پشتیبانی می کند. تعدادی از پیاده سازی های استاندارد OGC-SOS وجود دارد که داده های سری زمانی حسگر را در محل ارائه می دهد. با این حال، هیچ پیاده سازی برای ارائه داده های شطرنجی سری زمانی وجود ندارد.
در این مقاله ما مفهوم و اجرای یک SOS سازگار با OGC را برای دسترسی استاندارد به داده‌های سری زمانی شطرنجی توصیف می‌کنیم، که به ما امکان می‌دهد مجموعه داده‌های شطرنجی را با استفاده از فیلترهای زمانی، مکانی و موضوعی انتخاب کنیم و آنها را به روشی استاندارد ارائه کنیم. این کار در ابتکار TERENO (رصدخانه های محیطی زمینی)، یک پروژه تحقیقاتی میان رشته ای بلندمدت که نتایج بلندمدت اکولوژیکی، اجتماعی و اقتصادی تغییرات جهانی را در مقیاس منطقه ای جمع آوری می کند، سرچشمه گرفته است [2، 3 ] .]. چهار رصدخانه زمینی تأسیس شده‌اند که هر کدام داده‌های سری زمانی در مورد رطوبت خاک، دمای خاک، و یک سنج آب و همچنین انرژی و شار سیال از تعدادی از شبکه‌های حسگر ارائه می‌دهند. چهار دستگاه رادار هواشناسی و اسکنر باران برای اندازه گیری میزان بارندگی نصب شده است. SOS توسعه یافته برای دسترسی استاندارد به داده ها و ابرداده های اندازه گیری شده توسط این دستگاه ها استفاده می شود.

2. خدمات مشاهده سنسور OGC

کنسرسیوم فضایی باز (OGC) یک کنفدراسیون متشکل از تولیدکنندگان پیشرو GIS، تولیدکنندگان داده، مقامات، سازمان ها، مراکز تحقیقاتی و دانشگاه ها است. در سال 1994 تأسیس شد و رابط های استاندارد شده ای را برای دسترسی متقابل به داده های جغرافیایی توسعه می دهد. قابلیت همکاری شبکه‌های حسگر و حسگر توسط ابتکار فعال‌سازی وب OGC [ 4 ] پوشش داده می‌شود که چندین مورد از این شبکه‌ها را از نظر استانداردها و رابط‌های همسو با یکدیگر تعریف می‌کند:

•
استاندارد سرویس مشاهده حسگر (SOS) یک سرویس وب استاندارد شده را برای جستجو، فیلتر کردن و بازیابی داده های مشاهداتی و اطلاعات حسگر تعریف می کند [ 5 ، 6 ].
•
مشاهده و اندازه‌گیری (O&M) استانداردی برای توصیف، تبادل و رمزگذاری داده‌های جغرافیایی است [ 7 ، 8 ، 9 ، 10 ].
•
زبان مدل حسگر (SensorML) یک مدل اطلاعاتی برای توصیف حسگرها ارائه می‌کند – ویژگی‌های مشاهده‌شده و همچنین فرآیند جمع‌آوری و آماده‌سازی داده‌ها [ 11 ].
•
سرویس هشدار سنسور (SAS) به کاربران امکان دریافت پیام‌های هشدار از حسگرها را از طریق یک رابط استاندارد می‌دهد [ 12 ]. در حال حاضر بحثی در مورد گسترش SAS به یک سرویس رویداد حسگر (SES) وجود دارد که قادر به مدیریت انواع پیام‌های رویداد است [ 13 ].
علاوه بر این، SWE همچنین یک سرویس برنامه ریزی حسگر (SPS) و یک سرویس اطلاع رسانی وب (WNS) را تعریف می کند که در محدوده این مقاله نیستند.
استاندارد SOS شامل 11 عملیات است، اما تنها سه عملیات – GetCapabilities ، DescribeSensor و GetObservation – اجباری هستند. عملیات GetCapabilities اطلاعات کلی در مورد سرویس و تمام اطلاعات لازم برای فراخوانی عملیات پشتیبانی شده را ارائه می دهد. عملیات DescribeSensor شرحی از یک حسگر کدگذاری شده توسط زبان SensorML [ 11 ] ارائه می‌دهد و شامل شناسه‌هایی برای ویژگی‌های مشاهده‌شده، مختصات ایستگاه، و دامنه زمانی است که داده‌هایی برای آن در دسترس است. در نهایت، داده ها را می توان با استفاده از عملیات GetObservation درخواست کرد . قطعه XML در شکل 1نمونه ای از درخواست GetObservation را با تمام پارامترهای موجود نشان می دهد [ 5 ].
Ijgi 04 01076 g001 1024
شکل 1. یک درخواست SOS GetObservation با تمام عناصر موجود.
پیشنهاد منحصربه‌فرد و اجباری ، ترکیب منطقی حسگرها (مثلاً با ویژگی‌های مشاهده‌شده) قابل انتخاب رایگان و وابسته به مورد استفاده را مشخص می‌کند [ 5 ]. پارامترهای فیلترهای زمانی، مکانی و موضوعی (زمان رویداد، خطوط 3-11، featureOfInterest، خطوط 14-21 و نتیجه، خطوط 22-27)، شناسه های منحصر به فرد ایستگاه (رویه، خط 12)، و ویژگی های مشاهده شده (observedProperty، خط 13) اختیاری هستند.
استاندارد SOS از پرس و جوی داده با توجه به فیلترهای موضوعی و مکانی پشتیبانی می کند. یک فیلتر موضوعی اشیاء را با توجه به مقادیر یک متغیر انتخاب می کند. در خطوط 3-11 شکل 1 ، یک فیلتر زمانی مشخص شده است که داده ها را از یک دوره زمانی نمونه برداری معین انتخاب می کند. در خطوط 22-27 شکل 1 ، یک فیلتر موضوعی مشخص شده است که تمام مش های یک مجموعه داده شطرنجی را انتخاب می کند. خصیصه “Reflectivity” مقداری بیشتر از 36 دارد. شکل 2چند نمونه از فیلترهای فضایی را نشان می دهد که توسط استاندارد SOS پشتیبانی می شوند. در سمت چپ یک فیلتر بخش خط به تصویر کشیده شده است که تمام مقادیر واقع در یک مسیر خیابان را استخراج می کند. در مرکز یک فیلتر مستطیل و در سمت راست یک فیلتر چند ضلعی غیر متعامد به تصویر کشیده شده است. هر دو فیلتر در حال انتخاب اشیایی هستند که در داخل صفحه فیلتر قرار دارند.
Ijgi 04 01076 g002 1024
شکل 2. فیلترهای فضایی، ( سمت چپ ) یک فیلتر پاره خط، ( مرکز ) یک فیلتر مستطیل، و ( سمت راست ) یک فیلتر چند ضلعی متعامد).
SOS درخواست ها را با استفاده از شرایط فیلتر مشخص شده پردازش می کند و نتایج را به عنوان اسناد O&M برمی گرداند [ 7 ، 8 ، 9 ، 10 ]. بنابراین استاندارد O&M رمزگذاری داده های برداری و همچنین داده های شطرنجی را به عنوان اسناد XML تسهیل می کند [ 10 ]. داده های شطرنجی بر اساس یک مدل مفهومی برای پوشش های فضایی تعریف شده در ISO19123 با GML کدگذاری می شوند، در حالی که برای داده های برداری تعدادی از رمزگذاری های مختلف استفاده می شود. در یک درخواست GetObservation ، مدل نتیجه مورد نظر توسط پارامتر ResultModel (خط 46 در شکل 1 ) مشخص می شود [ 5]. بنابراین امکان درخواست داده های رستری و همچنین برداری از یک SOS به صورت استاندارد وجود دارد.

3. اجرا

تعدادی از پیاده سازی استاندارد SOS در زبان های برنامه نویسی مختلف وجود دارد [ 14 ]. ما پیاده‌سازی SOS شرکت 52°N را به عنوان مبنایی برای گسترش به یک Raster-SOS انتخاب کردیم، زیرا این پیاده‌سازی معمولاً استفاده می‌شود، منبع باز و به راحتی قابل تغییر است. افزونه شامل مراحل زیر بود:

•
یک مدل داده برای ذخیره داده های شطرنجی و ابرداده های توصیف کننده آن به روشی کارآمد، بر اساس مدل داده SOS 52 درجه شمالی توسعه یافته است ( شکل 3 را ببینید ).
•
الگوریتم های کارآمد برای اعمال فیلترها پیاده سازی شده است.
•
چندین مدل O&M برای برگرداندن داده های شطرنجی به شیوه ای استاندارد و انعطاف پذیر محقق شده است.
Ijgi 04 01076 g003 1024
شکل 3. مدل داده.
شکل 3 مدل داده توسعه یافته را نشان می دهد. ابرداده‌هایی که داده‌های سری زمانی را توصیف می‌کنند در جداول نرمال‌شده coverage_structure، پدیده‌ها، ایستگاه‌ها، پیشنهادات، و coverage_-out_of_band ذخیره می‌شوند. علاوه بر این، شبکه درشت تر در جدول coverage_coarse_raster و coverage_coarse_geometry نرمال شده ذخیره می شود. خود داده های شطرنجی به عنوان یک فیلد BLOB در جدول weatherradar_coverage با یک پیوند کلید خارجی به سری زمانی آن در جدول coverage_structure ذخیره می شود.

3.1. مدل داده

داده های شطرنجی در یک سیستم مدیریت پایگاه داده رابطه ای (RDBMS) ذخیره می شوند. در پیاده سازی ما از PostgreSQL [ 15 ] با پسوند PostGIS [ 16 ] برای داده های مکانی استفاده شد، با این حال، هر RDBMS دیگری که بتواند داده های جغرافیایی را مدیریت کند (به عنوان مثال، Oracle با پسوند OracleSpatial) ممکن است به جای آن استفاده شود. ما می خواهیم بر این واقعیت تأکید کنیم که پردازش شطرنجی ذاتی پایگاه داده، مانند نسخه PostGIS (2.0) ارائه شده است، نمی تواند در اینجا استفاده شود. از آنجایی که برای مثال PostGIS از یک جدول برای هر مجموعه داده شطرنجی استفاده می کند [ 17 ]، ممکن است تعداد زیادی جداول داده ایجاد شود. در دوره پروژه TERENO ما انتظار داریم تا 1.5 Mio ایجاد کنیم. مجموعه داده های رادار آب و هوا، که استفاده از جداول داده شطرنجی PostGIS را عملی نمی کند.
بنابراین، یک مدل داده توسعه داده شد که تمام داده های شطرنجی را در یک جدول داده واحد نگهداری می کند. این را می توان به دو روش مختلف انجام داد: مبتنی بر ردیف یا به عنوان یک شی بزرگ باینری (BLOB). BLOB یک نوع پایگاه داده برای اشیاء باینری بزرگ و نامشخص است که از مقدار ذخیره سازی به حداقل می رسد. از سوی دیگر، ذخیره سازی به عنوان یک BLOB برای فیلتر موضوعی داده ها ناخوشایند است، زیرا کل شی باینری باید خوانده شود و شرایط فیلتر باید برای هر مش شطرنجی اثبات شود. از طرف دیگر، نگه داشتن هر مش شطرنجی در یک ردیف از جدول داده، مزیت جستجوی مؤثر را دارد. نقطه ضعف آن تعداد زیاد درج‌ها و ردیف‌هایی است که برای هر مجموعه داده شطرنجی جمع می‌شود (به عنوان مثال، برای یک رستر نسبتاً کوچک با 800 × 800 پیکسل باید 640.000 درج و ردیف انجام شود).
به منظور ایجاد مصالحه بین ذخیره‌سازی مؤثر و جستجوی مؤثر، از ذخیره‌سازی BLOB داده‌ها استفاده می‌کنیم، اما از شبکه‌ای درشت‌تر برای دستیابی به قابلیت‌های جستجوی موضوعی کارآمد استفاده می‌کنیم. وضوح شبکه درشت تر آزادانه قابل انتخاب است و حداکثر و حداقل مش های شطرنجی اصلی زیرین را برای هر یک از مش های شطرنجی خود حفظ می کند. رزولوشن گرید به گونه ای انتخاب می شود که از یک طرف بتوان درج ها را در یک بازه زمانی مناسب انجام داد و از طرف دیگر نیازی به خواندن و بررسی تعداد زیادی پیکسل اصلی نیست. با این حال، بزرگترین مزیت این است که شاخص های پایگاه داده می توانند برای دسترسی بسیار کارآمدتر به داده ها نسبت به روش متوالی استفاده شوند [ 18 ].

3.2. فیلترها

فیلترهای موجود پیاده‌سازی 52 درجه شمالی با توابع پایگاه داده ذاتی، که فقط درخواست‌های مبتنی بر برداری را پشتیبانی می‌کنند، همراه هستند. با این حال، در اینجا ما به عملیات فیلتر موضوعی و فضایی نیاز داریم که می تواند روی داده های شطرنجی نیز اعمال شود. فیلترهای موضوعی سلول های شطرنجی را با استفاده از مقادیر یک متغیر انتخاب می کنند که برای آن از شبکه درشت فوق الذکر استفاده شده است. این مزیت دارد، زیرا فقط قطعات مرتبط از مجموعه داده اصلی باید خوانده شوند. از آنجا که پیکسل انتخاب شده از شبکه درشت همیشه یک چند ضلعی متعامد را نشان می دهد، ما یک الگوریتم جابجایی کارآمد [ 19 ] را پیاده سازی کردیم که چند ضلعی را در جهت عمودی از بالا به پایین اسکن می کند و آن بخش های خط را در یک حافظه پنهان موقت نگه می دارد، که دامنه هایی را مشخص می کند که را می توان در بلوک از مجموعه داده شطرنجی اصلی خواند (نگاه کنید بهشکل 4 ). وضعیت فیلتر فقط برای بخش های ذخیره شده باید بررسی شود.
Ijgi 04 01076 g004 1024
شکل 4. الگوریتم Sweep برای اسکن چند ضلعی های متعامد.
الگوریتم جابجایی را می توان برای همه فیلترهای فضایی که مستقیماً با مجموعه داده شطرنجی اصلی سر و کار دارند (نه روی شبکه درشت)، به عنوان مثال، اگر فیلتر فضایی متعامد است ( شکل 2 را در سمت راست ببینید) استفاده کرد. اگر فیلتر فضایی متعامد نباشد، نمی توان از الگوریتم رفت و برگشت استفاده کرد. در عوض، یک نمایش برداری از شطرنجی استفاده می شود که هندسه و شاخص سلولی مجموعه داده شطرنجی اصلی را در هر مش نگه می دارد. با این شطرنجی برداری شده، توابع ذاتی PostGIS مانند تقاطع، حاوی و غیره را می توان استفاده کرد [ 16 ]. به این ترتیب، پیاده سازی ما از هر هندسه فیلتر فضایی، که می تواند با GML در GetObservation کدگذاری شود، پشتیبانی می کند .درخواست کرد و به فرمت WKT (متن شناخته شده) تبدیل شد [ 20 ].
جدول
جدول 1. ترکیبات فیلتر و نتایج آنها.
جدول 1 تمامی ترکیبات فیلترهای زمانی، مکانی و موضوعی و نتایج پس از اعمال آنها را نشان می دهد. اگر فقط یک فیلتر زمانی اعمال شود (ردیف 1 از جدول 1 )، نتایج تطبیق داده شده کل مجموعه داده های شطرنجی هستند. ردیف دو جدول 1 نمونه ای از ترکیب فیلتر چند ضلعی زمانی و مکانی است. تمام پیکسل‌های موجود در ناحیه برش چند ضلعی هر مجموعه داده، که توسط فیلتر موقت انتخاب شده‌اند، به مجموعه نتیجه اضافه می‌شوند. مانند ردیف 3 جدول 1نشان می دهد، ترکیبی از یک فیلتر زمانی و موضوعی (ردیف 3) ردیابی یک شی متحرک را تسهیل می کند. در هر مجموعه داده انتخابی موقت، شی با فیلتر کردن ویژگی موضوعی آن استخراج می شود. به عنوان مثال، در مورد رادار هواشناسی ما، شی می تواند یک ابر بارشی باشد که می تواند با اعمال یک فیلتر موضوعی با آستانه بارندگی یا بازتاب با یک مقدار معین (مثلاً 48 میلی متر در ساعت، که 50 دسی بل را برآورده می کند) استخراج شود. بخش 0 را مقایسه کنید). ردیف آخر ترکیبی از هر سه نوع فیلتر را نشان می دهد. پس از انتخاب موقت مجموعه‌های داده، پیکسل‌ها توسط یک فیلتر چند ضلعی انتخاب می‌شوند، اما تنها در صورتی به مجموعه نتیجه اضافه می‌شوند که معیار فیلتر موضوعی مطابقت داشته باشد. یک مورد استفاده احتمالی، یافتن رویدادهای آب و هوایی است که فقط در یک منطقه خاص رخ می دهد.

3.3. مدل های نتیجه

استاندارد SOS اجازه می دهد تا داده ها را به عنوان پاسخ به درخواست GetObservation به صورت INLINE، OUT-OF-BAND و ATTACHED بسته بندی کنید. ما از هر سه امکان برای رسیدگی به موارد استفاده مختلف استفاده می کنیم. مدل‌های O&M مورد استفاده برای رمزگذاری مستقیم (INLINE) داده‌های شطرنجی فیلتر نشده و موضوعی و فضایی فیلتر شده عبارتند از DiscreteCoverageObservation، TimeSeriesObservation ، و یک مدل O&M عمومی [ 10 ، 21] .]. کل یا بخش‌هایی از مجموعه داده‌های شطرنجی به‌عنوان تصاویر جغرافیایی ارجاع‌شده (نه خود مقادیر داده‌ها) بر روی یک سرویس نقشه وب سازگار خارجی (OUT-Of-BAND) OGC ارائه می‌شوند. ATTACHED کل یا بخش‌هایی از مجموعه داده‌های شطرنجی را در قالب NetCDF باینری رمزگذاری می‌کند تا دسترسی به مقادیر داده‌ها را در قالبی علمی شناخته شده فراهم کند.
برای انتقال داده ها با استفاده از روش INLINE (نگاه کنید به شکل 1 )، دو مدل مختلف، که هر دو در استاندارد ISO 19123 [ 22 ] گنجانده شده اند، پیاده سازی شده اند. مدل O&M DiscreteCoverageObservation را می توان برای رمزگذاری داده های فیلتر شده مکانی و موضوعی استفاده کرد، در حالی که مدل TimeSeriesObservation O&M برای رمزگذاری یک سری زمانی از یک مش شطرنجی انتخاب شده مناسب است. در این مورد درخواست ها از فیلتر نقطه ای استفاده می کنند. شکل 5 جفت هندسه-مقدار یک مش شطرنجی کدگذاری شده با مدل DiscreteCoverageObservation را نشان می دهد .
Ijgi 04 01076 g005 1024
شکل 5. جفت مقدار هندسه یک مش شطرنجی با مدل DiscreteCoverageObservation – کد می کند .
هندسه به عنوان یک چند ضلعی در زبان نشانه گذاری جغرافیا (GML) کدگذاری می شود، در حالی که مقدار موضوعی به عنوان یک مقدار اعشاری با واحد اندازه گیری آن (UOM) کدگذاری می شود. در مدل TimeSeriesObservation مجموعه داده به طور مشابه کدگذاری می شود با این تفاوت که هندسه با یک مهر زمانی جایگزین می شود. از آنجایی که هر دو مدل مبتنی بر XML هستند و بسیار کاراکتر فشرده هستند، سومین مدل عمومی O&M [ 10 ] برای رمزگذاری داده‌ها با مقادیر جدا شده با کاما استفاده شد. برای هر سلول شطرنجی شاخص یا هندسه و مقدار داده داده می شود. کاهش اضافی حجم داده با فشرده سازی gzip (فرمت فایل Gzip RFC 1952) سند پاسخ انجام می شود. برای این منظور استاندارد SOS به ما اجازه می دهد تا از نوع mime “application/zip” برای ResponseFormat استفاده کنیم .پارامتر ( شکل 1 خط 28 را ببینید).
برای انتقال غیرمستقیم داده، استاندارد SOS امکان پاسخ به درخواست GetObservation را با ارجاع به یک منبع خارجی فراهم می کند [ 10 ]. ما از این گزینه برای ارائه شطرنجی به عنوان یک تصویر زمین مرجع از یک سرویس نقشه وب (WMS) سازگار با OGC استفاده می کنیم [ 23 ]. منابع به عنوان یک URL GetMap WMS کدگذاری شده و در سند پاسخ گنجانده شده است، که به عنوان مدل عمومی O&M کدگذاری می شود. در درخواست GetObservation حالت پاسخ با مقدار OUT-OF-BAND برای پارامتر ResponseMode داده می شود ( شکل 1 خط 30 را ببینید). شکل 6اشاره ای به یک تصویر شطرنجی ارائه شده توسط WMS را نشان می دهد که در یک مدل O&M عمومی گنجانده شده است.
Ijgi 04 01076 g006 1024
شکل 6. ارجاع به یک تصویر شطرنجی ارائه شده توسط WMS و کدگذاری شده با یک مدل عمومی O&M.
از آنجایی که WMS فقط از فیلترهای فضایی مستطیلی پشتیبانی می کند، شرایط فیلتر داده شده در درخواست GetObservation به مستطیل محصور تبدیل شده و به WMS ارسال می شود. اگر یک فیلتر موضوعی مشخص شده باشد، مستطیل محصور شده تمام مش های شطرنجی تعیین شده محاسبه می شود. ما این نوع ارائه داده را توسط یک برنامه افزودنی خود توسعه یافته [ 24 ] از پروژه GeoServer منطبق با WMS ( http://geoserver.org ) اجرا کردیم. پلاگین GeoServer ما با بازیابی داده‌های لازم از مدل داده‌های SOS، تصویر ارجاع‌شده جغرافیایی درخواستی را ایجاد می‌کند. این افزونه روش های اجباری GetCapabilities و GetMap را پیاده سازی می کندمطابق با استاندارد WMS نسخه 1.3 برای ارائه توضیحات خدمات و همچنین دسترسی به داده ها.
استاندارد SOS به ما اجازه می دهد تا داده ها را در قالب دلخواه به عنوان پیوست اضافی از پاسخ GetObservation ارائه کنیم [ 5 ]. در این مورد پیوست باید توسط سند پاسخ O&M ارجاع شود. برای دریافت داده‌های درخواستی به‌عنوان پیوست باینری، مقدار پارامتر حالت پاسخ در درخواست GetObservation باید «ATTACHED» باشد ( شکل 1 خط 30 را ببینید). بنابراین، سند O&M و همچنین داده ها در یک بدنه HTTP چند قسمتی (RFC 2046 MIME) منتقل خواهند شد. همه قسمت ها توسط یک نشانه مرزی منحصر به فرد از هم جدا می شوند که در سربرگ HTTP Content-Type تعریف شده است.
ما داده های شطرنجی را در قالب فایل NetCDF [ 25 ] رمزگذاری می کنیم و آن را به عنوان پیوست انتقال می دهیم. NetCDF یک فرمت فایل مبتنی بر ماتریس باینری خود توصیفی برای مجموعه داده های بزرگ است. یک API برای خواندن و نوشتن داده ها تقریباً در تمام زبان های برنامه نویسی رایج مانند JAVA، C++ یا Python ارائه شده است. داده ها در داخل ماتریس ها (متغیرها) سازماندهی می شوند که هر یک از آنها با یک ویژگی فراداده توصیف می شوند.
علی‌رغم ویژگی‌های فراداده ذاتی قالب NetCDF، قابلیت همکاری مستقیماً ارائه نشده است، زیرا ساختار و محتوای عناصر فراداده باید از قراردادهای رسمی پیروی کند تا قابلیت همکاری را انجام دهد. برای این منظور چندین قرارداد برای سازماندهی داده ها و همچنین ویژگی های فراداده اجباری با واژگان کاملاً تعریف شده تعریف شده است. ما از CF-Convention [ 26 ] استفاده می کنیم که به ویژه برای داده های مکانی مناسب است. در آن یک سری زمانی شطرنجی با دو آرایه یک بعدی و دو بعدی تعریف می شود.
Ijgi 04 01076 g007 1024
شکل 7. فایل NetCDF فرمت شده در CDL.
شکل 7 سرصفحه یک رکورد شطرنجی را نشان می دهد که در NetCDF کدگذاری شده و در قالب CDL قابل خواندن توسط انسان نمایش داده شده است. مختصات x (عرض جغرافیایی) مرکز هر شبکه شطرنجی در جهت x و مختصات y (طول جغرافیایی) در جهت y در دو آرایه یک بعدی ذخیره می شود. مرزهای مش مرتبط با هر مختصات x و همچنین y در دو آرایه دو بعدی ذخیره می شوند. آرایه x-bounds چپ و راست و y-bounds بالا و پایین را نگه می دارد.
در پیاده سازی خود، ما رستر پایه را به عنوان یک فایل NetCDF سازگار با CF هنگام راه اندازی سرویس برای هر سری زمانی شطرنجی مدیریت شده ایجاد می کنیم. برای ایجاد فایل‌های NetCDF درخواستی به روشی کارآمد، یک فایل NCML به‌علاوه تولید می‌شود که شامل ساختار کامل، ابرداده، و با ارجاع به فایل شطرنجی پایه NetCDF فوق‌الذکر، داده‌های شطرنجی پایه است. NCML یک زبان توصیفی مبتنی بر XML است که دقیقاً برای این منظور طراحی شده است [ 27 ]. برای ایجاد یک پاسخ سازگار با SOS، باید به هر پیوست NetCDF در یک سند O&M ارجاع دهیم. در پیاده‌سازی ما، مرجع توسط یک CID-URL کدگذاری می‌شود، که در واقع به پیوست‌های مرجع در یک ایمیل mime تعریف می‌شود [ 28 ]. شکل 8نمونه ای از چنین سند O&M را نشان می دهد. می‌توانید ببینید که هر بخش مشاهده، داده‌های ارجاعی خود را با برخی از عناصر فراداده مفید توصیف می‌کند و به پیوست از طریق CID-URL ارجاع می‌دهد. داده‌های مشاهده بر اساس ایستگاه‌ها (روش‌ها) و پارامترها (پدیده‌ها) گروه‌بندی می‌شوند، به این معنی که هر پیوست NetCDF شامل یک سری زمانی شطرنجی است.
Ijgi 04 01076 g008 1024
شکل 8. قطعه XML پاسخ O&M که در آن داده ها توسط یک CID-URL پیوند داده شده اند.

4. برنامه های کاربردی

در این بخش ما دو برنامه کاربردی را در نظر می گیریم که با داده های بازیابی شده از SOS توصیف شده برای داده های شطرنجی سروکار دارند. این SOS برای دسترسی استاندارد به داده های رادار آب و هوای Jülicher Weatherradar استفاده می شود. رادار هواشناسی در برجی به ارتفاع 30 متر در تپه 270 متری سوفین هوهه در نزدیکی جولیخ قرار دارد. رادار امواج مایکروویو را منتقل می کند که توسط ابرهای بارشی منعکس می شوند. از شدت بازتاب، نرخ بارندگی را می توان به عنوان مثال، با استفاده از معادله مارشال-پالمر [ 29 ] محاسبه کرد. رادار در محدوده 100 کیلومتری هر نوع بارش (باران، تگرگ، برف و … ) را مشاهده می کند. داده های جمع آوری شده رادار یک سری زمانی با وضوح زمانی پنج دقیقه و تفکیک مکانی 250 متر در 31416 کیلومتر مربع است .حوزه. هر رکورد سری زمانی یک تصویر PNG با وضوح 800 × 800 پیکسل است که در هر پیکسل یک مقدار بازتاب همگن برای منطقه 62500 متر مربعی مرتبط ارائه می دهد .
اولین برنامه، داده های رادار آب و هوا را به عنوان یک انیمیشن در یک صفحه وب برای بررسی سریع کیفیت توسط کاربر تجسم می کند. دومی سیستمی از اجزای نرم افزاری برای هشدار به کاربران ثبت نام شده در مورد رویدادهای بارش سنگین است که همچنین داده های رادار آب و هوا را از SOS به روشی استاندارد بازیابی می کند. قبل از تشریح این برنامه ها، پیکربندی و وارد کردن داده ها به رستر SOS در نظر گرفته می شود.

4.1. واردات داده

در مرحله اول، هر پیکسل از شطرنجی پایه برای فعال کردن کاربرد فیلترهای فضایی بردار شده است. برای داده‌های رادار آب‌وهوا که در اینجا در نظر گرفته می‌شود، شطرنجی غیر تکراری است و به 640000 چند ضلعی تقسیم می‌شود، که به همراه شاخص‌های پیکسلی در جدول پایگاه داده قرار می‌گیرند (در شکل 3 به weatherradar_geometries مراجعه کنید ). یک شبکه درشت باید ایجاد شود تا یک فیلتر بالا/پایین گذر به شیوه ای کارآمد اعمال شود. در اینجا، از شبکه درشت با پسوند شطرنجی اصلی و وضوح 20 کیلومتر استفاده شده است (به پوشش_درشت_هندسه در شکل 3 مراجعه کنید.). جدول رنگی نگاشت بین بازتاب پذیری و مقادیر رنگ را فراهم می کند. علاوه بر این، ابرداده‌هایی مانند پسوند و وضوح شطرنجی، واحد بازتاب (dbZ دسی‌بل Z، جایی که Z مخفف بازتاب‌پذیری است)، نام، و توضیحات دستگاه رادار و همچنین مختصات جغرافیایی در یک فایل SensorML با هم ترکیب می‌شوند. . آخرین اما نه کم اهمیت ترین، پارامترهای ارائه تصاویر جغرافیایی مرجع در یک WMS در یک جدول پایگاه داده نگهداری می شوند (به coverage_out_of_band در شکل 3 مراجعه کنید ).
وارد کردن تصاویر png توسط یک برنامه JAVA پیاده سازی می شود، که ابتدا مهر زمانی را از نام فایل استخراج می کند، به طور موقت مقادیر خاکستری هر پیکسل را در یک آرایه ذخیره می کند و این آرایه را به عنوان یک شی بزرگ باینری (BLOB) در پایگاه داده توسط به معنی PostgreSQL API برای اشیاء بزرگ [ 30 ]. در حین وارد کردن، مقادیر شبکه درشت محاسبه شده و در جدول شبکه درشت درج می شود ( شکل 3 coverage_coarse_raster را ببینید).

4.2. تجسم داده های رادار آب و هوا

برای تجسم متحرک داده های رادار آب و هوا، یک برنامه کاربردی وب پیاده سازی شده است که از روش OUT-OF-BAND استفاده می کند (به بخش 3.3 ، مدل های نتیجه مراجعه کنید). یک پیوند به یک لایه WMS توسط پاسخ داده ارائه می شود، که تصاویر رادار آب و هوا را برای یک بازه زمانی معین ارائه می دهد. داده های لایه به صورت لایه ها بر روی یک لایه پایه ارائه شده توسط وب سرویس OpenStreetMap (OSM) ( http://www.openstreetmap.org ) ارائه می شوند. این برنامه با Google Web Toolkit [ 31 ] و یک پوشش لایه باز برای GWT ( https://bitbucket.org/gwtopenlayers/gwt-openlayers ) توسعه یافته است و رابط کاربری گرافیکی نشان داده شده در شکل 9 را ارائه می دهد.. رابط های کاربری تصویری از محلی سازی داده های آب و هوا ارائه می دهند. یک دایره روکش شده مرزهای محدوده رادار را نشان می دهد. در شکل 9، یک جبهه رنگی آب و هوا به سمت دامنه حرکت می کند، با سطوح بارش متفاوت همانطور که در افسانه در پایین مشخص شده است. در قسمت سمت چپ رابط چند دکمه برای کنترل انیمیشن و تجسم سری زمانی یک پیکسل انتخاب شده قرار داده شده است. اگر مقدار “سری های زمانی” در جعبه ترکیبی انتخاب شده باشد، با کلیک بر روی یک پیکسل روی نقشه، نموداری ایجاد می شود که سری زمانی شبکه شطرنجی انتخاب شده را به تصویر می کشد.
شکل 10 تعامل و ارتباط بین SOS و برنامه مشتری را نشان می دهد. در مرحله اول کلاینت تمام مراجع WMS را برای دو ساعت گذشته با یک درخواست GetObservation شناسایی می کند. در درخواست، پارامتر ResponseMode روی OUT-OF-BANND تنظیم می شود تا به جای داده های رمزگذاری شده مستقیم، منابع WMS دریافت شود. تا زمانی که سرویس دارای داده هایی برای بازه زمانی معین باشد، هر رکورد داده توسط یک URL GetMap WMS در یک سند نتیجه O&M ارجاع داده می شود. برای هر URL WMS بدست آمده یک لایه ایجاد می شود، اما بلافاصله نشان داده نمی شود. این کار در یک حلقه روی تمام لایه ها انجام می شود، جایی که هر لایه به مدت 500 میلی ثانیه قابل مشاهده است و در نتیجه یک تصویر متحرک ایجاد می شود.
علاوه بر امکان کنترل انیمیشن و همچنین بزرگنمایی/کوچک کردن یا جابجایی نقشه، گزینه ای برای تجسم یک سری زمانی از یک مش شطرنجی (نگاه کنید به نمودار پاپ آپ شکل 9 ) گنجانده شده است. داده‌های سری زمانی از یک درخواست GetObservation سازگار با استاندارد تحویل داده می‌شوند ، که علاوه بر مقدار om:TimeSeriesObservation برای پارامتر ResultModel ، یک بازه زمانی و مختصات شبکه شطرنجی انتخاب‌شده را به‌عنوان یک فیلتر فضایی دارد.
Ijgi 04 01076 g009 1024
شکل 9. تصویری از برنامه وب که داده های رادار آب و هوا را تجسم می کند.
Ijgi 04 01076 g010 1024
شکل 10. نمودار UML ارتباط بین مشتری، SOS و WMS.

4.3. برنامه مشتری برای تشخیص مناطق بارش سنگین

برنامه دوم سرویسی را برای تشخیص مناطق بارش شدید و هشدار به کاربران در مورد این رویداد زمانی که برای اطلاع رسانی برای منطقه مربوطه ثبت نام کرده اند، پیاده سازی می کند. برای ثبت و سیگنال دهی از پیاده سازی 52 شمال استاندارد خدمات هشدار سنسور OGC (SAS) که به عنوان میان افزار بین سنسور و کلاینت عمل می کند، استفاده شد. اگر یک سنسور پیام های هشدار از نوع خاصی را فشار دهد و کاربر برای این نوع زنگ هشدار ثبت شود، یک دسته به کانالی که توسط SAS باز شده است، دریافت می کند که به پیام های هشدار دریافتی گوش می دهد. در داخل، پروتکل پیام‌رسانی و حضور توسعه‌پذیر مبتنی بر XML (XMPP) [ 32 ] برای توزیع پیام‌های هشدار روی اتاق‌های گفتگوی چند کاربره (MUC) استفاده می‌شود. در پیاده سازی خود از سیستم نرم افزار متن باز ejabberd (http://www.process-one.net/ ) به عنوان XMPP-Server. کاربران این فرصت را دارند که برای 100 منطقه مختلف ثبت نام کنند، که منطقه مشاهده شده توسط رادار هواشناسی را به یک شطرنجی با مش های شطرنجی 10 × 10 تقسیم می کند.
Ijgi 04 01076 g011 1024
شکل 11. ارتباط بین SOS، سنسور، SAS و مشتری.
شکل 11 ارتباط بین اجزای مربوطه را نشان می دهد، جایی که تعامل بین یکدیگر به طور موقت صعودی است و با اعداد نشان داده می شود. در سمت چپ یک جزء نرم افزاری (حسگر) که برای این منظور توسعه یافته است، یک نوع هشدار را در SAS برای هر منطقه ثبت می کند و شاخص منطقه مرتبط را در کانال دریافتی MUC (1) ذخیره می کند. یک شاخص منطقه برای شناسایی کانال برگردانده می شود. اگر کاربر برای منطقه (2) ثبت نام کند، شاخص منطقه مورد نظر ارجاع می شود و SAS را قادر می سازد کانال مناسب (XMPP-MUC) را شناسایی کند. جزء حسگر از GetObservation استفاده می کنددرخواست می کند تا در صورت وقوع یک رویداد بارش شدید، هر پنج دقیقه را شناسایی کند (3). برای این منظور یک فیلتر موضوعی با آستانه 50 دسی بل (این برابر با مقدار بارندگی حدود 48 میلی متر در ساعت است)، یک فیلتر زمانی که آخرین رکورد را انتخاب می کند و یک پارامتر ResultModel با مقدار om:DiscreteCoverageObservation.استفاده می شود. SOS به مش های شطرنجی پاسخ می دهد که در آن یک رویداد بارش شدید رخ داده است. همه مش ها به یک چند ضلعی متصل نمی شوند و با استفاده از تابع “تقاطع” PostGIS با شبکه منطقه قطع می شوند. با استفاده از نمایه منطقه حاصل، کانال مناسب (XMPP-MUC) شناسایی می شود و پیام هشدار به همه کاربرانی که قبلاً به اتاق گفتگوی ثبت شده برای این منطقه (4 و 5) پیوسته اند منتقل می شود. ثبت مشتری و نمایش سایت مشتری از رویدادهای بارش شدید شناسایی شده با یک برنامه دسکتاپ جاوا قابل حمل مبتنی بر نوسان انجام می شود که دارای رابط کاربری گرافیکی (GUI) نشان داده شده در شکل 12 است.. در سمت چپ رابط کاربری گرافیکی برای ثبت نام به تصویر کشیده شده است. با توجه به هر چک باکس فعال شده، به محض کلیک روی دکمه “اشتراک”، ثبت نام برای هر منطقه خاص انجام می شود. در سمت راست شکل 12 ، نواحی مشخص شده قرمز، مناطقی هستند که در آن یک رویداد بارش شدید رخ داده است.
Ijgi 04 01076 g012 1024
شکل 12. رابط کاربری گرافیکی (GUI) برنامه تشخیص بارش سنگین.

5. نتایج

از آنجایی که SOS و به خصوص توابع فیلتر آن باید اطلاعات را از داده های شطرنجی استخراج کند، اجزای نرم افزاری برای انتخاب داده های شطرنجی بر اساس دیدگاه های جغرافیایی یا موضوعی طراحی و پیاده سازی شدند. فیلترهای بردار که توسط استاندارد SOS تعریف شده اند باید به داده های شطرنجی ترجمه می شدند. بنابراین چالش یافتن مصالحه ای بین ذخیره سازی کارآمد داده و جستجوی کارآمد در داده های شطرنجی بود. از یک طرف، سیستم باید بتواند از شاخص های پایگاه داده برای جستجوی کارآمد برای اطلاعات موضوعی در داده های شطرنجی استفاده کند. از سوی دیگر، به دلیل حجم عظیمی از رکوردهایی که یک سری زمانی می تواند داشته باشد، امکان ذخیره هر رکورد داده شطرنجی در جدول خاص خود وجود ندارد. یک راه حل با یک شبکه درشت قابل انتخاب آزاد و با ذخیره داده های شطرنجی در یک میدان باینری بزرگ (BLOB) از پایگاه داده انجام شد. وضوح شبکه درشت به گونه ای انتخاب شد که هر مش شطرنجی یک رکورد را می توان در یک جدول به عنوان یک ردیف درج کرد و بنابراین می توان از یک فهرست پایگاه داده برای انجام جستجوی سریعتر استفاده کرد. برای این کار یک الگوریتم جابجایی کارآمد توسعه داده شد که نواحی را از داده های شطرنجی ذخیره شده باینری که توسط شبکه درشت انتخاب شده بودند می خواند.
برخی از مدل‌های مختلف پاسخ O&M توسط استاندارد SOS مجاز هستند که با دقت و بیان آن‌ها قابل تشخیص هستند. در مقایسه با سایر مدل‌های مورد استفاده، DiscreteCoverageObservationمدل دقیق ترین و قابل بیان ترین مدل را برای توصیف داده های شطرنجی ارائه می دهد. بنابراین این مدل برای بازگرداندن داده های شطرنجی فیلتر شده قوی استفاده شد. با افزایش دقت، اندازه اسناد برگشتی افزایش می یابد، به همین دلیل است که امکان بازیابی تعداد بیشتری از رکوردهای داده با استفاده از این مدل وجود ندارد. یک مدل O&M دوم برای ارائه مقادیر جدا شده با کاما استفاده شد، که اندازه سند را تا ضریب 100 کاهش داد. برای ارائه داده های سری زمانی شطرنجی در یک قالب شناخته شده و رایج علمی، ما یک پاسخ سازگار با SOS را در چنین قالبی پیاده سازی کردیم. روشی که می توان فایل های NetCDF را به پاسخ پیوست کرد و توسط سند O&M پاسخ داده شده ارجاع داد.
برای بررسی این مسائل، 14 سناریو در نظر گرفته شد و با توجه به تأخیر آنها مقایسه شد. نتایج در جدول 2 نشان داده شده است . هشت سناریو اول رکوردهای کامل شطرنجی را از SOS بازیابی کردند ( جدول 1 ، خطوط 1 تا 8 را ببینید). سیستم بیش از 10 دقیقه برای رمزگذاری یک رکورد داده با مدل DiscreteCoverageObservation نیاز داشت ( جدول 2 ، خط 1 را ببینید). حجم فایل ایجاد شده حاوی یک رکورد داده شطرنجی منفرد (640000 مش شطرنجی) بیش از 600 مگابایت بود. با استفاده از مدل عمومی O&M با استفاده از مقادیر جدا شده با کاما، زمان پاسخ به 1.8 ثانیه و اندازه سند به 7 مگابایت کاهش یافت ( جدول 2 را ببینید).، خط 2). فشرده سازی Gzip باعث کاهش بیشتر اندازه فایل به 1 مگابایت شد ( جدول 2 ، خط 3).
جدول
جدول 2. سناریوهایی برای تجزیه و تحلیل تاخیر پاسخ.
علاوه بر رکوردهای شطرنجی تکی، بازیابی سری های زمانی رکوردهای شطرنجی کامل با استفاده از مدل عمومی با مقادیر جدا شده با کاما یا پیوست شده در فایل NetCDF نیز امکان پذیر است ( جدول 2 ، خطوط 4 تا 8 را ببینید ). فشرده‌سازی زمانی کارآمدتر است که داده‌ها از طریق اینترنت منتقل می‌شوند ( جدول 2 ، ستون «Net» را ببینید)، زیرا هزینه فشرده‌سازی با اندازه کمتر داده‌های انتقال‌دهنده جبران می‌شود ( جدول 2 ، خطوط 6 تا 7 را ببینید). . سناریو 8 یک سری زمانی از سوابق کامل داده های شطرنجی را در یک دوره زمانی یک ماهه بازیابی می کند که در قالب فایل NetCDF کدگذاری و فشرده شده است. فایل برگشتی به حجم 365 مگابایت حاوی 5,507,200,000 مقدار داده است و در کمتر از یک ساعت ساخته، فشرده و تحویل داده شده است.
در سناریوهای 9 تا 11، 60 رکورد داده های فیلتر شده مکانی و موضوعی بازیابی شد. دو سناریو آخر داده‌های سری زمانی کدگذاری شده با مدل TimeSeriesObservation را بازیابی کردند . شصت رکورد انتخاب شده است که در سناریوی 12 مقدار مش و در سناریوی 13 مقدار متوسط ​​یک ناحیه مستطیلی برگردانده شده است.

6. بحث

تا آنجا که می دانیم، این اولین پیاده سازی استاندارد SOS برای دسترسی استاندارد به داده های شطرنجی است. بر اساس نسخه 1.0 استاندارد SOS، پیاده سازی ما شامل عملیات اصلی اجباری SOS GetCapabilities ، DescribeSensor و GetObservation است . در سال 2012، نسخه 2.0 استاندارد SOS توسط OGC اقتباس شد. با این حال، کار بر اساس نسخه قدیمی تر است، زیرا توسعه در سال 2010 آغاز شد، زمانی که پروژه TERENO تاسیس شد. مفاهیم ارائه شده در اینجا، به ویژه فرمت های نتیجه، به راحتی می توانند در نسخه 2.0 اعمال شوند.
رویکرد رایج برای انتشار داده های شطرنجی استاندارد OGC WCS است که قادر به مدیریت آرایه های چند بعدی است زیرا نسخه 2.0 می تواند برای گنجاندن یک بعد زمانی استفاده شود. WCS(-EO) از یک طرف برای ارائه مجموعه داده های بزرگ طراحی شده است. از سوی دیگر، در نظر گرفتن رابطه زمانی به عنوان یک افزودنی با استفاده از یک مجموعه فراداده اضافی ارائه شده با هر مجموعه داده شطرنجی اجرا می شود. استاندارد OGC SOS، به عنوان یکی از اجزای چارچوب OGC SWE، برای دسترسی استاندارد به انواع داده های سری زمانی شطرنجی و برداری با رابطه مکانی با زمین طراحی شده است، رابطه زمانی هر مجموعه داده را به ارث می برد و امکان تعریف فیلترهای فضایی و موضوعی از سوی دیگر، تا به حال از SOS بیشتر برای درجا استفاده می شده استحسگرها، از آنجایی که مفاهیم کلی برای ترکیب ژئوپردازش مبتنی بر برداری ذاتی با داده های شطرنجی در دسترس نیست، البته، به دلیل فقدان مدل های بازگشت داده کارآمد. اجرای رستر-SOS ما همه عملکردهای WCS(-EO) را به دلیل استانداردهای مختلف اجرا نمی کند. به عنوان مثال، یک SOS فقط از داده های مکانی دوبعدی پشتیبانی می کند. داده های 1-D یا 3-D که احتمالاً به عنوان خروجی مدل ایجاد می شوند، نه در محدوده پیاده سازی ما هستند و نه توسط مؤلفه های SWE پشتیبانی می شوند. از سوی دیگر، یک رستر-SOS قابلیت‌های اضافی را ارائه می‌کند که برای استاندارد SOS منحصربه‌فرد هستند، به عنوان مثال، فیلتر فضایی موضوعی و گسترده.
تجزیه و تحلیل سناریوها نشان داد که مدل om:DiscreteCoverageObservation به دلیل حجم زیاد داده قادر به ارائه داده های شطرنجی نیست. از سوی دیگر، می‌توانیم نشان دهیم که واقعاً می‌توان داده‌های شطرنجی را در زمان و اندازه معقول با استفاده از مدل عمومی (به جدول 2 ، سناریوهای 4 تا 7 مراجعه کنید) یا پیوست کردن یک فایل NetCDF (به جدول 2 ، سناریو 8 مراجعه کنید) امکان‌پذیر است. . در عمل، حتی در پیاده‌سازی‌های SOS مبتنی بر برداری، داده‌ها معمولاً با استفاده از مدل عمومی و نه از طریق مدل‌های گویاتر و دقیق‌تر، که برای این نوع داده‌ها نیز در دسترس هستند (مانند مدل om:Measurement [10, ) بازگردانده می‌شوند . 21 ]).
با وجود تفاوت زیاد در پاسخگویی بین مدل‌های DiscreteCoverageObservation و TimeSeriesObservation ، بیان و دقت و همچنین نیاز ذخیره‌سازی هر دو مدل برابر است. دلیل امتیاز خوب مدل TimeSeriesObservation این است که همیشه فقط یک مش یا یک مقدار متوسط ​​از ناحیه ای از شبکه با این مدل کدگذاری شده است. در واقع، این مدل امکان بازیابی مقادیر متوسط ​​را معرفی می کند (به عنوان مثال حوضه های آبریز رودخانه)، که امکان تعیین آن در جای دیگری در GetObservation وجود ندارد.درخواست. سناریوی 8 نشان می دهد که داده های شطرنجی تحویل داده شده در یک فایل NetCDF این فرصت را می دهد تا داده های سری زمانی شطرنجی قابل توجهی در قالبی از نظر علمی شناخته شده ارائه شود. استفاده متقابل از داده های تحویل شده هنوز با استفاده از کنوانسیون CF ارائه می شود.
روش OUT-OF-BAND امکان دسترسی به داده های سری زمانی شطرنجی را می دهد که توسط سرویس های خارجی ارائه می شود. برای برنامه ما تجسم داده های رادار آب و هوا کافی بود و از منظر عملکرد لازم است داده ها را به صورت تصاویر رنگی ارجاع داده شده زمینی کدگذاری کنیم. فراتر از آن، ارائه داده های واقعی شطرنجی با این روش، نه توسط WMS بلکه با یک سرویس پوشش وب (WCS) امکان پذیر است [ 33 ، 34 ]، که داده های واقعی شطرنجی را ارائه می دهد [ 14]] و نه تنها تصاویر مشتق شده. یک سوال هیجان انگیز در مورد این است: “چگونه می توانیم یک فیلتر فضایی یک درخواست SOS GetObservation را به یک درخواست GetCoverage WCS تبدیل کنیم؟” یک رویکرد ممکن برای این کار اجرای درخواست GetCoverage به طور مستقیم از SOS است. در این مورد SOS به عنوان یک پروکسی بین مشتری و WCS عمل می کند. اگر هر دو روش پاسخ WMS و WCS باید ارائه شوند، در این صورت امکان تمایز آن در درخواست GetObservation نیز باید در دسترس باشد. از آنجا که هر دو نوع باید پارامتر درخواست RequestMode را روی OUT-OF-BAND تنظیم کنند، فقط پارامتر ResponseMode هنوز باقی مانده است. بنابراین یک مشخصه یکپارچه از مقادیر بالقوه برای پارامتر ResponseFormat مطلوب است که هر دو مورد (WCS و WMS) را در نظر بگیرد.

7. نتیجه گیری

در این مقاله ما مفاهیم و اجرای یک SOS سازگار با OGC را برای دسترسی متقابل به داده‌های سری زمانی شطرنجی مربوط به منطقه ارائه کردیم. علاوه بر این، یک برنامه وب برای دسترسی سریع، استاندارد و قابل همکاری به داده های شطرنجی برای بازرسی سریع کیفیت بصری پیاده سازی شده است. سیستمی کشف شد که داده‌های رادار آب‌وهوای فیلتر شده را از SOS به روشی استاندارد و سازگار بازیابی می‌کند تا رویدادهای بارش شدید را شناسایی کند و به کاربران ثبت‌نام شده در این مورد هشدار دهد.
برای موارد استفاده از نوع اول، سیستمی ساخته شد که ترکیبی از SOS و WMS است که دسترسی سریع به رکوردهای شطرنجی یک سری زمانی را فراهم می کند. با توجه به این موضوع، ابرداده های مدیریت شده توسط SOS با نقشه های شطرنجی مدیریت شده توسط WMS ترکیب شده اند. این ارتباط توسط مهرهای زمانی انجام می شود که از یک طرف بخشی از ابرداده هستند، اما از طرف دیگر بخشی از نام لایه WMS نیز هستند. تصاویر شطرنجی به صورت موقت از داده هایی که در مدل داده SOS ذخیره می شوند تولید می شوند. برای این یک بهار [ 35پلاگین مبتنی بر ] برای GeoServer سازگار با OGC و WMS توسعه داده شد. سیستم پایگاه داده ای که برای مدیریت داده ها توسط SOS استفاده می شود، از بازیابی سریع ابرداده ها پشتیبانی می کند و بنابراین تأخیر خدمات کوتاهی را ارائه می دهد. این سیستم که با بیش از 420000 رکورد داده جمع آوری شده است، منابع WMS مورد نظر را در محدوده دو یا یک رقمی میلی ثانیه استخراج و رمزگذاری می کند. بنابراین تأخیر با ضریب 1000 در بخشی از سیستم قدیمی که تصاویر رادار را در یک سیستم مدیریت محتوا (CMS) ذخیره می‌کرد و از طریق سرویس کاتالوگ OGC (CSW) دسترسی قابل‌عملی ایجاد می‌کرد، کوتاه شده است. قابلیت همکاری را می توان با استفاده از SOS بهبود بخشید، زیرا یک SOS به ویژه برای مدیریت متقابل داده های سری زمانی طراحی شده است.
یک مورد استفاده از نوع دوم، که رویدادهای بارش شدید را با اعمال فیلترها تشخیص می‌دهد و به کاربران ثبت‌شده در این مورد هشدار می‌دهد، توسط یک سیستم نرم‌افزاری محقق شد که پیام‌های هشدار مربوط به آن رویدادها را به سرویس هشدار سنسور (SAS) ارسال می‌کند. از سوی دیگر، این سیستم یک رابط کاربری گرافیکی برای تعاملات و تجسم مشتری فراهم می کند. علاوه بر کاربرد مشخصی که رویدادهای بارش شدید را تشخیص می دهد، یک چارچوب برای انتقال پیام هشدار از طریق پروتکل XMPP به SAS نیز ایجاد شده است که قابلیت استفاده مجدد از اجزای نرم افزار توسعه یافته را امکان پذیر می کند. بر اساس اجزای جاوا نوسان، رابط کاربری گرافیکی یک فرصت آسان برای استفاده و کاربر پسند برای ثبت پیام های هشدار و مشاهده مناطق برجسته شده، که در آن رویدادهای باران شدید رخ داده است، ارائه می دهد.
نتیجه گیری ما این است که استاندارد SOS فرصت بسیار خوبی برای انتشار داده های سری زمانی شطرنجی به روش استاندارد شده است. با توجه به داده‌های مکانی دوبعدی، رویکرد SOS در مقایسه با رویکرد رایج WCS(-EO) به دلیل قابلیت‌های فیلتر زمانی و موضوعی آن غالب است، اما به‌ویژه به دلیل امکان توصیف تجهیزات اندازه‌گیری، فرآیندهای اندازه‌گیری و مشاهدات با جزئیات توسط استانداردهای ابرداده، که دقیقا برای این منظور تعریف شده است. کار اضافی برای مشخص کردن یک پسوند هسته SOS 2.0 برای داده های شطرنجی انجام خواهد شد، که از مدل پوشش OGC [ 36 ] برای تسهیل رمزگذاری داده های شطرنجی به روشی کارآمدتر از نسخه SOS 1.0 و مفاهیم استفاده شده ISO 19123 استفاده می کند.

منابع

  1. OGC. OGC ® Sensor Web Enablement Architecture ; Open Geospatial Consortium Inc.: Wayland، MA، USA، 2008; پ. 66. [ Google Scholar ]
  2. زکریا، س. بوگنا، اچ. سامانیگو، ال. مائودر، ام. فوس، آر. پوئتز، تی. فرنزل، م. شوانک، ام. بیسلر، سی. باترباخ باهل، ک. و همکاران شبکه ای از رصدخانه های محیطی زمینی در آلمان. Vadose Zone J. 2011 ، 10 ، 955-973. [ Google Scholar ] [ CrossRef ]
  3. کانکل، آر. سورگ، ج. Eckardt، R. کلدیتز، او. رینک، ک. Vereecken، H. TEODOOR: زیرساخت داده های جغرافیایی توزیع شده برای داده های رصد زمینی. محیط زیست علوم زمین 2013 ، 69 ، 507-521. [ Google Scholar ] [ CrossRef ]
  4. برورینگ، آ. اکترهوف، جی. جیرکا، س. سیمونیس، آی. اوردینگ، تی. استاش، سی. لیانگ، اس. Lemmens, R. فعال سازی وب سنسور نسل جدید. Sensors 2011 , 11 , 2652-2699. [ Google Scholar ] [ CrossRef ]
  5. OGC. مشخصات پیاده سازی سرویس مشاهده سنسور OpenGIS ; Open Geospatial Consortium Inc.: Mayland, MA, USA, 2006; پ. 91. [ Google Scholar ]
  6. OGC. استاندارد رابط سرویس مشاهده سنسور OGC ; Open Geospatial Consortium Inc.: Wayland, MA, USA, 2012; پ. 148. [ Google Scholar ]
  7. OGC. مشاهدات و اندازه‌گیری‌ها – بخش 2 – ویژگی‌های نمونه‌برداری ; Open Geospatial Consortium Inc.: Wayland، MA، USA، 2007; پ. 36. [ Google Scholar ]
  8. OGC. اطلاعات جغرافیایی: مشاهدات و اندازه گیری ها. در OGC Abstract Specification مبحث 20 ; Open Geospatial Consortium Inc.: Wayland, MA, USA, 2010; جلد 2.0.0، ص. 57. [ Google Scholar ]
  9. OGC. مشاهدات و اندازه گیری ها. در پیاده سازی XML ; Open Geospatial Consortium Inc.: Wayland, MA, USA, 2011; جلد 2.0، ص. 76. [ Google Scholar ]
  10. OGC. مشاهدات و اندازه‌گیری‌ها – بخش 1 – طرح‌واره مشاهده ; Open Geospatial Consortium Inc.: Wayland، MA، USA، 2007; پ. 85. [ Google Scholar ]
  11. OGC. زبان مدل سنسور OpenGIS (SensorML). در مشخصات پیاده سازی ; کنسرسیوم فضایی باز: Wayland، MA، ایالات متحده آمریکا، 2007; جلد 1.0.0، ص. 180. [ Google Scholar ]
  12. OGC. مشخصات اجرای خدمات هشدار سنسور OGC® ; Open Geospatial Consortium Inc.: Wayland، MA، USA، 2007; پ. 128. [ Google Scholar ]
  13. OGC. مشخصات رابط سرویس رویداد سنسور OpenGIS® (پیشنهاد شده) ; Open Geospatial Consortium Inc.: Wayland، MA، USA، 2008; پ. 88. [ Google Scholar ]
  14. ننگ چنگ، سی. لیپینگ، دی. گئونگ، ی. Min, M. یک سرویس مشاهدات حسگر جغرافیایی انعطاف پذیر برای داده های حسگر متنوع بر اساس وب سرویس. ISPRS J. Photogramm. Remote Sens. 2009 , 64 , 234-242. [ Google Scholar ]
  15. فایفر، تی. Wenk، A. PostgreSQL: Das Praxisbuch ; Galileo-Press: بن، آلمان، 2010. [ Google Scholar ]
  16. اوبه، RO; Hsu، LS PostGIS در عمل ؛ انتشارات منینگ: گرینویچ، CT، ایالات متحده آمریکا، 2011. [ Google Scholar ]
  17. Holl, S. PostGIS Raster Workshop ; FOSSGIS: Dessau-Rosslau، آلمان، 2012; پ. 18. [ Google Scholar ]
  18. کمپر، ​​ا. Eickler، A. Datenbanksysteme—Eine Einführung ; Oldenbourg Wissenschaftsverlag GmbH: München، آلمان، 2006. [ Google Scholar ]
  19. گوتینگ، RH; Dieker, S. Datenstrukturen und Algorithmen ; Teubner Verlag: Wiesbaden، آلمان، 2004. [ Google Scholar ]
  20. OGC. استاندارد پیاده سازی OpenGIS® برای اطلاعات جغرافیایی—دسترسی به ویژگی های ساده—بخش 1: معماری مشترک ; Open Geospatial Consortium Inc.: Wayland, MA, USA, 2011; پ. 92. [ Google Scholar ]
  21. برورینگ، ا. Meyer, O. Bereitstellung und visualisierung hydrologischer zeitreihen mit hilfe standardisierter webdienste. در مجموعه مقالات AGIT2008 Symposium und Fachmesse، سالزبورگ، Österreich، 2-4 ژوئیه 2008.
  22. ISO Geoinformation—Coverage Geometrie—und Funktionsschema (ISO 19123: 2005) ; DIN Deutsches Institut für Normung: برلین، آلمان، 2005; پ. 71. [ Google Scholar ]
  23. OGC. مشخصات پیاده سازی سرور نقشه وب OpenGIS® ; Open Geospatial Consortium Inc.: Wayland، MA، ایالات متحده آمریکا، 2006. [ Google Scholar ]
  24. Kirschke, T. Implementierung eines OGC-konformen WMS als Plugin für einen Geoserver. FH-Aachen: آخن، آلمان، 2012. [ Google Scholar ]
  25. Rew، RK; دیویس، GP; Emmerson, S. NetCDF: رابطی برای دسترسی به داده های علمی. محاسبات IEEE. نمودار Appl. 1990 ، 10 ، 76-82. [ Google Scholar ] [ CrossRef ]
  26. ایتون، بی. گریگوری، جی. دراچ، بی. تیلور، ک. کنوانسیون‌های فراداده اقلیمی و پیش‌بینی (CF) هانکین، S. NetCDF. در دسترس آنلاین: http://cfconventions.org/ (دسترسی در 30 ژانویه 2015).
  27. ناتیوی، س. کارون، جی. دیویس، ای. Domenico، B. طراحی و پیاده سازی زبان نشانه گذاری netCDF (NcML) و پسوند مبتنی بر GML آن (NcML-GML). محاسبه کنید. Geosci. 2005 ، 31 ، 1104-1118. [ Google Scholar ] [ CrossRef ]
  28. کارگروه مهندسی اینترنت (IETF). درخواست نظرات: 2392—شناسه محتوا و شناسه پیام یکسان منبع یاب. در دسترس آنلاین: https://www.ietf.org/rfc/rfc2392.txt (در 13 اکتبر 2014 قابل دسترسی است).
  29. مارشال، جی اس؛ Palmer, WM توزیع قطرات باران با اندازه. J. Meteorol. 1948 ، 5 ، 165-166. [ Google Scholar ] [ CrossRef ]
  30. گروه توسعه جهانی PostgreSQL. درایور PostgreSQL JDBC. در دسترس آنلاین: http://jdbc.postgresql.org/ (دسترسی در 30 ژانویه 2015).
  31. هانسون، آر. Tacy، A. GWT im Einsatz : AJAX-Anwendungen entwickeln mit dem Google Web Toolkit ; Carl Hanser Verlag: München، آلمان، 2007. [ Google Scholar ]
  32. کارگروه مهندسی اینترنت (IETF). درخواست برای نظرات: 6120 — پروتکل پیام رسانی و حضور قابل توسعه (XMPP): هسته. در دسترس آنلاین: https://tools.ietf.org/html/rfc6120 (در 20 سپتامبر 2014 قابل دسترسی است).
  33. OGC. خدمات پوشش وب (WCS) ; Open Geospatial Consortium Inc.: Wayland, MA, USA, 2003; پ. 67. [ Google Scholar ]
  34. OGC. استاندارد رابط OGC® WCS 2.0-Core ; Open Geospatial Consortium Inc.: Wayland, MA, USA, 2010; پ. 45. [ Google Scholar ]
  35. راهنمای مبتدیان آموتان، جی . Packt Pub.: بیرمنگام، بریتانیا، 2014. [ Google Scholar ]
  36. OGC. OGC® GML Application Schema—Coverages ; Open Geospatial Consortium Inc.: Wayland, MA, USA, 2012; پ. 35. [ Google Scholar ]

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

آموزش کاربردی ArcGISالهام ابراهیم زادهکاربرد جی ای اسکاربرد جی ای اس در زمین شناسی

بدون نظر

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

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

همواره حمایت دانشجویان عزیزمان همراه ما بوده و این سببب شده که گامی محکم به‌سوی ایجاد یک مرجع برای آموزش GIS برداریم. با این امید که بتوانیم قدردان حمایت شما بزرگواران باشیم.

  • خانه
  • آموزش
  • فیلم آموزشی
  • تماس با ما
  • درباره ما
  • وبلاگ
  • سمنان /خیابان کاشانی/ساختمان فناوری اطلاعات/پ 8
  • 09120049370