استفاده از مراجع درجا در پایش رصد زمین یک نیاز اساسی است. LUCAS (بررسی چارچوب کاربری و منطقه تحت پوشش) فعالیتی است که از سال 2006 هر سه سال یک بار در اروپا بررسی های مکرر در محل انجام داده است. اما در حال حاضر از طریق یک رابط استاندارد، ماشین به ماشین در دسترس نیست. علاوه بر این، تکامل نظرسنجی ها عملکرد تجزیه و تحلیل تغییر را با استفاده از مجموعه داده محدود می کند. هدف ما توسعه یک سیستم منبع باز برای پر کردن این شکاف ها بود. این مقاله یک راه حل سیستم توسعه یافته برای هماهنگ سازی و توزیع داده های درجا LUCAS ارائه می کند. ما یک سیستم مشتری-سرور چند لایه طراحی کرده‌ایم که ممکن است در جریان‌های کاری انتها به انتها ادغام شود. این داده ها را از طریق یک رابط سازگار OGC (کنسرسیوم فضایی باز) ارائه می دهد. علاوه بر این، یک کاربر مکانی ممکن است داده ها را از طریق یک API پایتون (رابط برنامه نویسی کاربردی) ادغام کند تا استفاده در گردش کار با فیلترهای مکانی، زمانی، ویژگی و موضوعی را آسان کند. علاوه بر این، ما یک پلاگین QGIS را برای بازیابی زیر مجموعه های مکانی و زمانی داده ها به صورت تعاملی پیاده سازی کرده ایم. علاوه بر این، API پایتون شامل روش هایی برای مدیریت اطلاعات موضوعی است. این سیستم عملکرد پیشرفته ای را ارائه می دهد که در دو مورد استفاده نشان داده شده است. API پایتون شامل روش هایی برای مدیریت اطلاعات موضوعی است. این سیستم عملکرد پیشرفته ای را ارائه می دهد که در دو مورد استفاده نشان داده شده است. API پایتون شامل روش هایی برای مدیریت اطلاعات موضوعی است. این سیستم عملکرد پیشرفته ای را ارائه می دهد که در دو مورد استفاده نشان داده شده است.

کلید واژه ها:

لوکاس ; درجا ؛ هماهنگ سازی داده ها ; توزیع داده ها ; خدمات وب ; افزونه QGIS

1. مقدمه

استفاده از مراجع مستقل در محل در پایش رصد زمین یک نیاز اساسی است [ 1 ]. در حال حاضر، حجم مجموعه داده های مکانی تولید شده به طور قابل توجهی در حال افزایش به داده های بزرگ است [ 2 ]. چنین داده هایی با حجم زیاد، ارزش بالا، تنوع بالا و سرعت بالقوه بالا و صحت بالا مشخص می شوند [ 3 ]. به منظور فراهم کردن فرصت کامل برای جامعه علوم زمین برای کشف بینش‌های ناشناخته قبلی، چنین مجموعه‌های داده باید از طریق یک فناوری استاندارد، مقیاس‌پذیر و توسعه‌پذیر ارزیابی شوند که امکان ادغام کامل در جریان‌های کاری علمی سرتاسر را فراهم می‌کند.
فعالیت‌های نقشه‌برداری پوشش زمین قاره اروپا، که از تصاویر رصد زمین استفاده می‌کنند، به منابع قابل اعتماد و نماینده در محل برای اعتبارسنجی و کالیبراسیون نقشه‌برداری خودکار در سراسر اروپا نیاز دارند [ 4 ]. چنین ارجاعی معمولاً در کمپین‌های تولید پوشش زمین به صورت موقت از عکس‌های هوایی یا تصاویر با وضوح بسیار بالا ایجاد می‌شوند، اما بررسی‌های درجا به ندرت انجام می‌شوند. مشکلات مربوط به مراجع نماینده زمانی که نقشه‌برداری تشخیص تغییر پوشش زمین انجام می‌شود، بزرگ‌تر می‌شوند.
LUCAS، بررسی چارچوب کاربری و منطقه تحت پوشش، فعالیتی است که توسط Eurostat مدیریت می شود که از سال 2006 هر سه سال یک بار در اروپا بررسی های درجا انجام می دهد [ 5 ].]. امروزه مجموعه ای از مشاهدات 2006، 2009، 2012، 2015 و 2018 وجود دارد. نقشه برداران عمدتاً پوشش زمین در محل (76 طبقه) و کاربری زمین (41 طبقه) را بررسی می کنند و عکس می گیرند (یک عکس رو به رو و چهار عکس منظره در جهت قطب نمای اصلی)، اما همچنین اطلاعات زراعی و زیست محیطی را ارزیابی می کنند و 500- می گیرند. گرم نمونه خاک سطحی در یک نقطه از ده. اخیرا (بررسی 2018)، ویژگی های Copernicus، INSPIRE (زیرساخت اطلاعات فضایی در اروپا) و EUNIS (سیستم اطلاعات طبیعت اروپا) اضافه شده است. هدف اولیه از نمونه برداری، ارائه تخمین مساحت برای تحلیل های فضایی و سرزمینی مانند آمار کشاورزی [ 6 ] بود.]. با این حال، استفاده از مجموعه داده LUCAS چندگانه است. 168402 (2006)، 234623 (2009)، 270272 (2012)، 339696 (2015) و 337854 (2018) نقطه نمونه در مجموعه داده LUCAS بررسی شده است. این مجموعه ای از 651,377 نقطه بررسی فردی را در قلمرو کشورهای عضو اتحادیه اروپا (EU) ارائه می دهد، در حالی که 319,150 نمونه حداقل دو بار و 35,204 نمونه به طور مکرر در تمام سال های بررسی شده بازدید شده اند، که امکان ارزیابی تغییرات زمین را فراهم می کند. مجموعه داده ها در مجموع 1،350،847 فردی در محل تجزیه و تحلیل نقطه.
فعالیت‌های نمونه‌گیری دیگری مانند Geo-Wiki.org [ 7 ] و ESA GlobCover [ 8 ] وجود دارد که مجموعه داده‌های اعتبارسنجی را ارائه می‌کنند. با این حال، اینها با مقدار قابل توجهی کمتری از داده های جمع آوری شده و بدون مشاهدات تکراری مداوم در طول زمان کار می کنند. از این نظر، مجموعه داده LUCAS از چندین جنبه منحصر به فرد است، از جمله تراکم نمونه برداری مکانی آن (شبکه 2×2 کیلومتر) که کشورهای عضو اتحادیه اروپا را پوشش می دهد، تعداد کل سایت های بازدید شده در محل، وضوح زمانی آن (فرکانس سه ساله)، و پوشش موضوعی آن
مجموعه داده LUCAS در بسیاری از فعالیت های تحقیقاتی استفاده شده است. Close et al. [ 9 ] و ویگاند و همکاران. [ 10 ] از مجموعه داده LUCAS به عنوان داده های مرجع آموزشی و اعتبار سنجی همراه با Sentinel-2 برای طبقه بندی نظارت شده بر پیکسل در سطح ملی استفاده از زمین و پوشش زمین استفاده کرد. Pflugmacher و همکاران [ 11 ] پوشش زمین سراسر اروپا را با استفاده از معیارهای طیفی-زمانی Landsat بر اساس بررسی اروپایی LUCAS 2018 ترسیم کرد. گائو و همکاران [ 12 ] از داده های LUCAS برای ارزیابی نقشه های جهانی پوشش زمین در اتحادیه اروپا استفاده کرد. d’Andrimont و همکاران. [ 13 ] از داده‌های LUCAS، همراه با تصاویر Sentinel-1، برای نقشه‌برداری انواع محصول با وضوح فضایی 10 متر در سطح اروپا برای سال 2018 استفاده کرد. Borrelli و همکاران. [14 ] یک ماژول فرسایش خاک را با بررسی خاک سطحی LUCAS 2018 برای نظارت بر وضعیت سلامت خاک در سراسر اتحادیه اروپا و حمایت از اقدامات برای جلوگیری از تخریب خاک ادغام کرد. همه نویسندگان فوق از مجموعه داده LUCAS به عنوان مجموعه داده وضعیت در تجزیه و تحلیل خود استفاده کردند. با این حال، آنها تنها یک سال از بررسی استفاده کردند، در حالی که پتانسیل اندازه گیری های مکرر در محل استفاده نشده باقی ماند. ما معتقدیم که داده ها پتانسیل بسیار بالاتری را حفظ می کنند.
با این وجود، از آنجایی که فعالیت LUCAS از سال 2006 تکامل یافته است، تفاوت‌هایی در نظرسنجی‌های جداگانه وجود دارد که باید هماهنگ شوند. d’Andrimont و همکاران. [ 13 ] تعدادی از مراحل هماهنگ سازی مربوط به تغییر نام ستون های پایگاه داده، کدگذاری مجدد متغیرها و اصلاح مختصات مکان نظری را پیشنهاد و اعمال کرد. ویگاند و همکاران [ 10 ] چندین طرح پیش پردازش برای داده های LUCAS (دو رویکرد موقعیت یابی و سه رویکرد انتخاب معنایی) پیشنهاد کرد. استفاده از داده های LUCAS تأثیر مثبتی بر دقت طبقه بندی پوشش زمین و به ویژه تصحیح موقعیت نقاط نشان داد.
ما همچنین اهمیت مجموعه داده های مرجع باز را که به صورت آنلاین در دسترس هستند با استفاده از فناوری پیشرفته زمین فضایی برای امکان ادغام کامل داده ها (ماشین به ماشین) در خطوط لوله پردازش خودکار، به عنوان مثال، در ابر بحث می کنیم. محیط ها طبیعی است که از یک رابط سازگار با OGC استفاده کنید که امکان ادغام گسترده با استفاده از استانداردها را فراهم می کند. قابلیت همکاری و استانداردسازی برای دستیابی به ماژولار بودن سیستم اطلاعاتی به منظور اتصال یکپارچه ماژول ها یا اجزای نرم افزاری مختلف، همانطور که در نشریه Jeppesen و همکاران ارائه شده است، بسیار مهم هستند. [ 15 ]. استانداردهای OGC برای اطمینان از قابلیت همکاری سیستم های اطلاعات جغرافیایی (GIS) و زیرساخت داده های مکانی (SDI) به طور کلی طراحی شده اند [ 16 ]]. بسیاری از پیاده‌سازی‌های گردش کار علمی مطابق با OGC در دسترس هستند [ 17 ، 18 ، 19 ، 20 ]. نمونه‌ای از هماهنگی خودکار خدمات وب OGC برای تولید نقشه‌های موضوعی در انتشارات Rautenbach و همکاران توضیح داده شده است. [ 21 ]. OGC چندین فرمت داده باز و سرویس وب مناسب برای توزیع داده های مکانی و تبادل داده را مشخص می کند. خدمات ویژه وب (WFS) [ 22 ] و ویژگی‌های OGC API [ 23 ] که برای درخواست داده‌های برداری خام مناسب هستند، مورد توجه خاص هستند. در SDI مبتنی بر OGC، کاربر می‌تواند به طور یکپارچه به داده‌های ذخیره‌شده در قالب‌های جغرافیایی مبتنی بر فایل یا پایگاه‌داده‌گرا دسترسی داشته باشد [ 24 ]]. ویژگی‌های برداری معمولاً توسط سیستم‌های مدیریت پایگاه داده رابطه‌ای شی با یک پسوند مکانی نصب شده ذخیره و نگهداری می‌شوند. در تنظیمات منبع باز، سیستم پایگاه داده PostgreSQL با پسوند geospatial PostGIS به طور گسترده به عنوان یک پایگاه داده سازگار با OGC پذیرفته شده است [ 25 ، 26 ].
در حال حاضر، مجموعه داده‌های مجزای LUCAS برای دانلود در فایل‌های مقادیر جداشده با کاما (CSV) از پورتال Eurostat [ 27 ] و عکس‌ها از طریق نمایشگر آنلاین LUCAS [ 28 ] در دسترس هستند. این نوع فناوری توزیع فاقد راحتی یکپارچه‌سازی است، که از استفاده از داده‌ها در گردش‌های کاری گسترده‌تر انتها به انتها جلوگیری می‌کند. ما بررسی‌های فردی را در حین تهیه نقشه‌برداری فضایی-زمانی پوشش زمین در دوره بین سال‌های 2000 و 2019 در مقیاس اروپایی بررسی کردیم [ 29 ]] و سه حوزه زیر را برای بهبود احتمالی شناسایی کرد: (1) هماهنگی مقادیر داده در پایگاه داده (شامل نام متغیرها و انواع داده ها)، (2) تجمع مکانی-زمانی مجموعه داده های فردی (از جمله هماهنگ سازی مختصات مکانی) و (3) استقرار یک سیستم توزیع منطبق با OGC برای ارائه دسترسی تعاملی ماشین به ماشین.
این مقاله یک راه حل فناورانه برای بازیابی زیرمجموعه های مکانی و زمانی داده های هماهنگ LUCAS به عنوان بخشی از توسعه پروژه Geo-Harmonizer پیشنهاد و توسعه می دهد و سیستم را به عنوان یک کد منبع باز با جامعه علوم زمین به اشتراک می گذارد.
در اینجا، ما یک سیستم SpaceTime_LUCAS (ST_LUCAS) را ارائه می کنیم که برای پردازش سه ناحیه ذکر شده در بالا توسعه داده ایم. ما هدف کلی را به چند هدف تقسیم کردیم:
O1
ذخیره سازی داده ها در یک لایه ماندگاری؛
O2
اتوماسیون کامل و قابل تنظیم فرآیند هماهنگ سازی برای به روز رسانی های نظرسنجی LUCAS گذشته و آینده و تجمیع فضا-زمان برای تجزیه و تحلیل تغییرات.
O3
توسعه نرم افزار برای دسترسی به داده ها از طریق یک سرویس وب استاندارد شده (OGC).
O4
توسعه یک کلاینت Python API و افزونه QGIS برای بازیابی زیرمجموعه های داده های LUCAS بر اساس فیلترهای مکانی، زمانی و موضوعی؛
O5
توسعه روش‌های ترجمه برای ارائه داده‌های پوشش زمین LUCAS در نام‌گذاری‌های دیگر و امکان تحلیل‌های تعریف‌شده توسط کاربر مانند تجمیع افسانه‌ها.
در نهایت، استفاده از سیستم توسعه‌یافته را در دو مورد استفاده در بخش 5 نشان می‌دهیم .

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

طراحی معماری سیستم ST_LUCAS از اهداف ذکر شده در مقدمه مشتق شده است. فرآیند روش شناختی چندین مرحله را دنبال می کند. با توجه به اهداف (نیازهای سیستم)، ما یک معماری استاتیک سطح بالا با عملکرد عمومی طراحی کردیم. برای هر یک از اجزای سیستم، هدف، عملکرد، ورودی ها و خروجی ها را مشخص کردیم. این ما را قادر ساخت تا عملکرد کلی سیستم را ارزیابی کنیم. در مرحله بعد، رابط های بین اجزا را شناسایی کرده و جریان داده را طراحی کردیم. پس از معماری استاتیک، یک معماری پویا سیستم طراحی کردیم تا تعامل سیستم را به صورت متوالی ارزیابی کنیم. ما همچنین مجموعه‌ای از آزمایش‌ها را برای تأیید اعتبار همه مؤلفه‌ها، رابط‌ها و داده‌ها تعریف کردیم.
ما سیستم را با استفاده از نمودارهای گردش کار عمومی در زبان مدلسازی یکپارچه (UML) 2.5، به ویژه مؤلفه UML و نمودارهای متوالی طراحی کردیم. این سیستم با استفاده از Bash، Python 3 و زبان پرس و جو ساختاریافته (SQL) کدگذاری شده است. سیستم کلی با استفاده از فناوری مجازی سازی Docker مستقر شد.

هماهنگ سازی داده های LUCAS

داده‌های اولیه Eurostat LUCAS جمع‌آوری‌شده در طول پنج بررسی سال‌های 2006، 2009، 2012، 2015 و 2018 [ 30 ، 31 ، 32 ، 33 ، 34 ] ورودی‌های اصلی سیستم هستند. نظرسنجی های فردی توزیع شده به عنوان فایل CSV به همراه اسناد فنی مربوطه در سیستم فایل دانلود شدند. شبکه نظری LUCAS 2018 2 × 2 کیلومتر مربع از Eurostat [ 35 ] نیز اضافه شد.
پس از تعریف هدف دوم (O2) به عنوان هماهنگ کردن مجموعه داده های LUCAS در طول سال های بررسی، ابتدا دستورالعمل های نقشه برداران و منابع فنی طبقه بندی [ 36 ، 37 ، 38 ، 39 ] و توصیفگرهای رکورد داده های اولیه [ 40 ] را بررسی کردیم. ، 41 ، 42 ، 43 ، 44] برای شناسایی تغییرات بین نظرسنجی‌های فردی LUCAS، که بین سال‌های 2006 و 2018 تکامل یافته‌اند. این یافته‌ها اساس فرآیند هماهنگ‌سازی را تشکیل می‌دهند. به طور کلی، این فرآیند شامل هماهنگ سازی مختصات مکانی، تغییر نام ویژگی ها، هماهنگ سازی مقادیر داده ها و یکسان سازی انواع داده ها است. ما نظرسنجی 2018 را توسعه یافته ترین می دانیم و همچنین حاوی اطلاعات موضوعی جدیدی است. از این رو ما از امسال به عنوان مرجع استفاده کردیم. تمام ویژگی های پایگاه داده و مقادیر آنها با این مرجع هماهنگ شده است. این مراحل هماهنگی با مفروضات ساخته شده توسط d’Andrimont و همکاران بررسی شد. [ 13 ] در طول توسعه سیستم در پروژه Geo-harmonizer. ویژگی های هماهنگ مجموعه داده ST_LUCAS در جدول A2 پیوست A فهرست شده است . کاربران همچنین می توانند جداول کدگذاری و نقشه برداری را به صورت آنلاین در وب سایت ST_LUCAS ( https://geoforall.fsv.cvut.cz/st_lucas ، نسخه 1.0 منتشر شده توسط نویسندگان در 9 ژوئن 2022) کاوش کنند.
مجموعه داده‌های هماهنگ منفرد از سال‌های 2006، 2009، 2012، 2015 و 2018 در نتیجه در یک پایگاه داده مشترک از طریق تجمع فضا-زمان ادغام شدند. هدف ایجاد یک پایگاه داده مشترک LUCAS بود که در آن بردار اطلاعات موضوعی که امکان ارزیابی مستقیم، به عنوان مثال، تغییرات پوشش زمین در طول سال‌های جداگانه را فراهم می‌آورد، توسط کاربر برای هر نقطه بازدید مکرر در محل بازیابی شود. با توجه به این واقعیت که بازدیدهای مربوطه توسط GPS اندازه گیری شده است، مختصات مکانی اطلاعات جمع آوری شده از نظر زمانی برای هر نقطه با یک شناسه منحصر به فرد متفاوت است. تفاوت ها از متر تا صدها متر متفاوت است ( شکل 1 در زیر).
بنابراین، هندسه نماینده را به عنوان یک میانه هندسی اندازه گیری های مکرر GPS محاسبه کردیم ( شکل 2 ). میانه توسط تابع PostGIS [ 45 ] با استفاده از الگوریتم Weiszfeld [ 46 ] برای جلوگیری از تأثیر عوامل پرت احتمالی موجود محاسبه شد. علاوه بر این، ویژگی جدیدی را معرفی کردیم (SURVEY_DIST، ضمیمه A  جدول A2 )، که فاصله بین مختصات GPS بررسی و مختصات میانه هندسی را اندازه می‌گیرد. همه مختصات فضایی (اندازه‌گیری‌شده، نظری، و میانه) به سیستم مرجع مختصات مشترک ETRS89-extended/LAEA اروپا (EPSG 3035) تبدیل شدند.

3. طراحی سیستم

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

3.1. معماری سطح بالا سیستم

معماری سیستم از یک مدل مشتری-سرور چند لایه معمولی پیروی می کند که برای دستیابی به اهداف تعریف شده در بخش 1 سفارشی شده است. سیستم وظایف را بین سمت سرور با مجموعه داده LUCAS و مشتریان تقسیم می کند، و کاربرانی که زیر مجموعه های مکانی-زمانی داده های LUCAS را مصرف می کنند. علاوه بر این، طراحی همچنین از ایده مهندسی نرم افزار مبتنی بر مؤلفه (CBSE) پیروی می کند که برای مثال توسط Vale و همکارانش توضیح داده شده است. [ 47 ].
سیستم، همانطور که در شکل 3 نشان داده شده است، به سه لایه اصلی متشکل از چندین جزء تجزیه می شود ( جدول 1) در هر یک از لایه ها. لایه پایداری وسیله ای برای ذخیره داده های LUCAS ورودی، متوسط ​​(سال های جداگانه) و هماهنگ نهایی فضا-زمان (O1) فراهم می کند. نقش اصلی این لایه حفظ داده ها در ذخیره سازی غیر فرار برای توزیع بیشتر است. جزء اصلی این لایه یک سیستم پایگاه داده (پایگاه داده SQL با قابلیت فضایی) است. لایه کاربرد، رویه‌های استقرار و هماهنگ‌سازی سیستم (O2) و سرویس وب توزیع داده (O3) را ارائه می‌کند. عملکرد توزیع توسط سرویس ویژگی وب OGC به دست می آید. لایه مشتری از طریق یک رابط داخلی با سرویس توزیع داده ارتباط برقرار می کند که داده های هماهنگ LUCAS را در اختیار کاربر نهایی قرار می دهد. عملکرد اصلی لایه مشتری توسط بسته نرم افزاری پایتون ارائه می شود. نیاز اصلی ایجاد درخواست ها بر اساس فیلترهای مکانی، ویژگی، موضوعی و زمانی تعریف شده توسط کاربر است. لایه مشتری دو راه برای بازیابی و فیلتر کردن زیرمجموعه های داده ها (O4)، از طریق یک رابط خط فرمان (CLI) یا از طریق یک رابط کاربری گرافیکی (GUI) ارائه می دهد. لایه مشتری دارای یک عملکرد تعریف شده اضافی برای ترجمه نامگذاری پوشش زمین LUCAS به افسانه های دیگر (O5) یا تجمیع افسانه بر اساس نیاز مشتری است.
این سیستم برای سه کاربر بالقوه سطح بالا طراحی شده است. مدیر سیستم می تواند سیستم را همانطور که طراحی شده است مستقر کند یا آن را برای استفاده سفارشی شده از برنامه پیکربندی کند. توسعه‌دهنده مکانی می‌تواند به مجموعه داده هماهنگ LUCAS از طریق API پایتون (مثلاً با استفاده از نوت‌بوک Jupyter یا مستقیماً توسط کد پایتون) در یک خط لوله پردازش کاملاً خودکار دسترسی پیدا کند. کاربر GIS قادر است به صورت تعاملی زیر مجموعه های مجموعه داده LUCAS را از طریق برنامه دسکتاپ QGIS (افزونه QGIS) کاوش و دانلود کند.
سیستم ST_LUCAS برای امکان مقیاس پذیری کامل طراحی شده است. مقیاس پذیری عمودی ممکن است با استقرار سیستم در یک محیط ابری به دست آید. مقیاس پذیری افقی سیستم ارائه شده ممکن است با افزودن چندین نمونه سرور نقشه در لایه برنامه به دست آید.

3.2. رابط های سیستم

سیستم کلی به‌عنوان اجزای نرم‌افزار مجزا کپسوله‌شده طراحی شده است که مجموعه‌ای از عملکردهای مرتبط را ارائه می‌کند. اجزای نرم افزار از طریق رابط [ 48 ] با یکدیگر ارتباط برقرار می کنند . دو نوع اینترفیس وجود دارد: رابط های داخلی و رابط های خارجی. رابط های داخلی و خارجی با استفاده از نمودار مؤلفه UML در شکل 4 نشان داده شده اند. رابط داخلی ارتباط بین لایه پایدار و لایه کاربردی (IF1) را فراهم می کند. این یک رابط بین سیستم پایگاه داده و وب سرویس با استفاده از مشخصات OGC WFS است که در آن جریان داده LUCAS هماهنگ است. رابط داخلی دیگر ارتباط بین لایه برنامه (وب سرویس) و بسته پایتون کلاینت (IF2) را فراهم می کند که توسط مشخصات OGC WFS تعریف شده است. رابط های خارجی بین برنامه مشتری (CLI یا GUI) و بسته Python لایه مشتری (IF3) قرار دارند. در اینجا، وب سرویس درخواست ها را به پایگاه داده مکانی-زمانی ارسال می کند و این سرویس داده های هماهنگ شده LUCAS را در قالب ویژگی های زبان نشانه گذاری جغرافیایی (GML) به مشتری نهایی کاربران نهایی ارائه می دهد. یک پلاگین QGIS/Notebook Jupyter (لایه مشتری) از طریق API بسته Python با سیستم ST_LUCAS ارتباط برقرار می کند.

3.3. معماری پویا سیستم

معماری پویا با استفاده از نمودارهای متوالی UML برای برنامه ریزی تعاملات اجزای سیستم طراحی شده بالا در طول زمان طراحی شده است. معماری پویا به دو مرحله تقسیم شد: مرحله استقرار سیستم و فرآیند تعامل با کاربر.
شکل 5یک نمودار متوالی UML در مرحله استقرار ارائه می دهد که تعامل بین اجزای اصلی لایه برنامه (بسته استقرار و وب سرویس) و لایه پایداری (سیستم فایل و سیستم پایگاه داده) است. این فرآیند با پیکربندی سیستم اولیه، با توجه به نیازهای مدیر شروع می شود. بعد، بسته استقرار (A1) سه عملیات عمده را انجام می دهد. ابتدا، داده های اولیه LUCAS توزیع شده در قالب CSV ساده به طور خودکار از ارائه دهنده داده مشخص شده در پیکربندی سیستم دانلود می شوند. در مرحله دوم، پس از دانلود موفقیت آمیز فایل های CSV اولیه در سیستم فایل سرور (P1)، سیستم پایگاه داده (P2) مستقر می شود. استقرار سیستم پایگاه داده به ده عملیات فرعی تقسیم می شود که با یک مرحله اولیه سازی پایگاه داده شروع می شود و سپس داده های اولیه LUCAS را به پایگاه داده اولیه وارد می کند. فرآیند هماهنگ سازی شامل یکسان سازی مختصات فضایی، نام ویژگی ها، انواع داده های ویژگی و مقادیر داده است. این عملیات به طور جداگانه برای هر سال بررسی انجام می شود. پس از آن، تجمع فضا-زمان مشاهدات هماهنگ LUCAS اعمال می شود. فرآیند استقرار با ایجاد یک فایل dump پایگاه داده برای ایجاد پایگاه داده مکانی-زمانی تکمیل می شود. ثالثاً، مؤلفه وب سرویس سیستم (A2) مستقر شده است. در مرحله بعد، داده های هماهنگ شده LUCAS در سیستم پایگاه داده ممکن است توسط وب سرویس منتشر شود. هر یک از مراحل متوالی با آزمایش هایی برای ارزیابی عملکرد سیستم دنبال می شود. و مقادیر داده این عملیات به طور جداگانه برای هر سال بررسی انجام می شود. پس از آن، تجمع فضا-زمان مشاهدات هماهنگ LUCAS اعمال می شود. فرآیند استقرار با ایجاد یک فایل dump پایگاه داده برای ایجاد پایگاه داده مکانی-زمانی تکمیل می شود. ثالثاً، مؤلفه وب سرویس سیستم (A2) مستقر شده است. در مرحله بعد، داده های هماهنگ شده LUCAS در سیستم پایگاه داده ممکن است توسط وب سرویس منتشر شود. هر یک از مراحل متوالی با آزمایش هایی برای ارزیابی عملکرد سیستم دنبال می شود. و مقادیر داده این عملیات به طور جداگانه برای هر سال بررسی انجام می شود. پس از آن، تجمع فضا-زمان مشاهدات هماهنگ LUCAS اعمال می شود. فرآیند استقرار با ایجاد یک فایل dump پایگاه داده برای ایجاد پایگاه داده مکانی-زمانی تکمیل می شود. ثالثاً، مؤلفه وب سرویس سیستم (A2) مستقر شده است. در مرحله بعد، داده های هماهنگ شده LUCAS در سیستم پایگاه داده ممکن است توسط وب سرویس منتشر شود. هر یک از مراحل متوالی با آزمایش هایی برای ارزیابی عملکرد سیستم دنبال می شود. جزء سرویس وب سیستم (A2) مستقر شده است. در مرحله بعد، داده های هماهنگ شده LUCAS در سیستم پایگاه داده ممکن است توسط وب سرویس منتشر شود. هر یک از مراحل متوالی با آزمایش هایی برای ارزیابی عملکرد سیستم دنبال می شود. جزء سرویس وب سیستم (A2) مستقر شده است. در مرحله بعد، داده های هماهنگ شده LUCAS در سیستم پایگاه داده ممکن است توسط وب سرویس منتشر شود. هر یک از مراحل متوالی با آزمایش هایی برای ارزیابی عملکرد سیستم دنبال می شود.
شکل 6 یک نمودار متوالی UML از فرآیند تعامل کاربر را نشان می دهد. این فرآیند تعامل بین اجزای اصلی سمت کلاینت (کلاینت‌های CLI/GUI – C3، بسته پایتون – C1) و سمت سرور است که توسط وب سرویس لایه برنامه (A2) ارائه داده‌ها از لایه پایدار (سیستم پایگاه داده) ارائه می‌شود. -P2). علاوه بر این، سیستم فایل محلی کاربران (C2) در شکل 3 برای نشان دادن تعامل پویا با سیستم ST_LUCAS معرفی شده است.
کاربر نهایی می تواند با استفاده از یک رابط کاربری گرافیکی طراحی شده برای پلت فرم منبع باز QGIS یا از طریق API پایتون با سیستم تعامل داشته باشد. پلاگین QGIS (C3) در بالای بسته Python (C1) ساخته شده است که امکان دسترسی آسان به داده های هماهنگ شده فضا-زمان LUCAS را فراهم می کند. از طرف دیگر، نوت بوک Jupyter ممکن است برای تعامل داده های مبتنی بر کد در زبان برنامه نویسی پایتون استفاده شود.
در ابتدا، دسترسی سرور باید برای دسترسی به وب سرویس (A2) از طریق بسته Python (C1) در سمت مشتری پیکربندی شود. به محض اینکه سرور (وب سرویس) اطلاعاتی در مورد اتصال موفقیت آمیز ارائه می دهد، کاربر می تواند درخواست های داده را تعریف کند. کاربر درخواستی را بر اساس فیلترهای مکانی، ویژگی، موضوعی و زمانی ایجاد می کند تا زیر مجموعه ای از مجموعه داده هماهنگ LUCAS را به دست آورد. درخواست توسط بسته Python (C1) به مؤلفه وب سرویس سمت سرور (A2) ارسال می شود. پاسخ سرور شامل زیرمجموعه ای از مجموعه داده هماهنگ LUCAS است که با فیلترهای تعریف شده در درخواست کاربر مطابقت دارد. داده های بازیابی شده از یک وب سرویس (A2) توسط بسته پایتون (C1) در سیستم فایل محلی (C2) ذخیره می شود.

3.4. اعتبار سنجی سیستم

اعتبار سنجی سیستم بخشی از طراحی سیستم است. اعتبارسنجی در دو سطح انجام می شود. در سطح طراحی (اسناد) که امکان ردیابی بین اجزای مدل در فاز معماری و سطح نرم افزار را برای آزمایش هر جزء و رابط سیستم طراحی شده در استقرار سیستم، اجرا و دسترسی کاربران خارجی فراهم می کند.
ما تست های واحد را برای هر جزء نرم افزاری با توجه به طراحی دقیق معماری سیستم تعریف کردیم ( شکل 3 ، شکل 4 و شکل 5 ). فرآیند استقرار سیستم ST_LUCAS توسط جزء نرم افزاری A1 کنترل می شود. این فرآیند با سه مرحله اصلی شکل می گیرد که در شکل 5 نشان داده شده است: (1) دانلود داده های اولیه (P1)، (2) استقرار پایگاه داده (P2) و (3) استقرار وب سرویس (A2). تست های واحد (1) فرآیند دانلود داده های اولیه LUCAS را همانطور که در پیکربندی مشخص شده است تأیید می کند. مجموعه آزمون‌های واحد زیر (2) تأیید می‌کند که آیا DB (P2) مقداردهی اولیه شده است (2a)، داده‌های اولیه وارد شده (2b)، فرآیند هماهنگ‌سازی داده‌های LUCAS اعمال شده (2c-2h)، داده‌های هماهنگ‌شده LUCAS آماده‌شده برای انتشار (2i) ، و فایل بازیابی DB ایجاد شده است (2j). آخرین مجموعه از تست های واحد (3) تأیید می کند که آیا وب سرویس (A2) عملیاتی است (3a) و داده های ST_LUCAS (3b) و ابرداده ها (3c) منتشر شده اند. برای لایه مشتری، تست های واحد بسته پایتون (C1) و اجزای سیستم فایل محلی (C2) را پوشش می دهند. برای پلاگین QGIS (C3)، تأیید دستی انجام می شود. یک نمای کلی از آزمون های واحد در جدول 2 نشان داده شده است. هر تست در صورتی موفقیت آمیز ارزیابی می شود که نتیجه آزمایش با پیکربندی سیستم مطابقت داشته باشد. در غیر این صورت شکست خورده ارزیابی می شود.
تعامل بین اجزای نرم افزار توسط تست های یکپارچه سازی تایید می شود. برای هر رابط ( شکل 4 )، مجموعه ای از تست های یکپارچه سازی طراحی شد ( جدول 3). ترکیبات مختلفی از فیلترهای مکانی، زمانی، ویژگی و موضوعی آزمایش می شوند. یک درخواست بر اساس مجموعه مشخصی از فیلترها توسط بسته Python (C1) ساخته شده و به سرور ارسال می شود. وب سرویس (A2) یک زیر مجموعه مرتبط از داده های هماهنگ LUCAS (IF2) را برمی گرداند. زیرمجموعه با یک مجموعه رکورد ارائه شده توسط یک پرس و جو مستقیم به پایگاه داده (P2) با استفاده از دستورات SQL (IF1) مقایسه می شود. تست‌های ادغام تنها در صورتی با یک نتیجه قبولی ارزیابی می‌شوند که هر دو رابط (IF1 و IF2) زیرمجموعه یکسانی از داده‌های LUCAS را برگردانند. مدیر سیستم به طور منظم از طریق اعلان‌های ایمیلی از نتایج آزمون یکپارچه‌سازی مطلع می‌شود. این تضمین می کند که مدیران سیستم در زمان واقعی از خرابی احتمالی سیستم مطلع می شوند، که جنبه مهمی از استقرار عملیاتی سیستم ST_LUCAS است. برای رابط IF3،
تست های واحد ( جدول 2 ) و یکپارچه سازی ( جدول 3 ) با بسته پایتون پایتون [ 49 ] خودکار می شوند. بنابراین تأیید در طول اجرای نرم افزار انجام می شود که به صورت پویا رفتار نرم افزار را بررسی می کند. نتایج آزمایش واحد توسط مدیر سیستم در مرحله استقرار تأیید می شود. در صورتی که یکی از تست های واحد ناموفق باشد، فرآیند استقرار خاتمه می یابد و سیستم مستقر نمی شود. نتایج تست یکپارچه سازی به طور مکرر در مرحله اجرای سیستم تأیید می شود. نتیجه هر عملیات آزمایشی در یک فایل گزارش مرتب شده است که در دسترس عموم است (نمایش سیستم ST_LUCAS، https://geoforall.fsv.cvut.cz/st_lucas، نسخه 1.0 منتشر شده توسط نویسندگان در 9 ژوئن 2022) و بنابراین ممکن است توسط کاربر تأیید شود.

4. پیاده سازی سیستم

پیاده سازی و استقرار سیستم ST_LUCAS از طراحی که در بخش 3 توضیح داده شده است پیروی می کند . این سیستم برای اطمینان از تکرارپذیری، شفافیت و توسعه پذیری آن کاملاً بر روی اجزای نرم افزار منبع باز است ( پیوست A  جدول A1 ). به طور کلی، معماری سیستم را به کلاینت (frontend) و سمت سرور (backend) تقسیم می کند. از این رو، جنبه های پیاده سازی به طور جداگانه شرح داده شده است.

4.1. Backend

پشتیبان، سمت سرور متشکل از لایه های پایداری و کاربردی، از اجزای نرم افزاری تشکیل شده است که وظیفه ذخیره سازی داده ها، هماهنگ سازی داده های LUCAS و توزیع داده ها را بر عهده دارند. اجزاء (نمایش داده شده در شکل 3 ) به عنوان مجموعه ای از خدمات پیاده سازی می شوند (به بخش 4.3 مراجعه کنید ). هر سرویس در یک محفظه Docker ایزوله که بر روی هر سیستم عاملی که توسط فناوری مجازی سازی Docker پشتیبانی می شود اجرا می شود [ 50 ] مدیریت می شود. دو جزء اصلی نرم‌افزار پشتیبان وجود دارد: سیستم مدیریت پایگاه داده، راه‌اندازی یک DB مکانی-زمانی (P2)، و سرور نقشه، ارائه‌دهنده یک وب سرویس (A2). سیستم مدیریت پایگاه داده توسط یک سرور منبع باز شی-رابطه ای PostgreSQL نشان داده می شود [ 51]. این سیستم پایگاه داده از نظر قابلیت اطمینان، یکپارچگی و صحت داده ها شهرت زیادی دارد. علاوه بر این، گسترش داده‌های مکانی را فراهم می‌کند، به اصطلاح PostGIS، که پایگاه داده PostgreSQL را از نظر فضایی فعال می‌کند [ 52 ]. PostGIS همچنین از OpenGIS “Simple Features Specification for SQL” توسط OGC پیروی می کند. در اینجا، ما از PostGIS نسخه 3.1 استفاده می کنیم. اجزای P2 و A2 توسط بسته استقرار سیستم (A1) مستقر می شوند.
فرآیند جمعیت پایگاه داده توسط مجموعه ای از اسکریپت های پیاده سازی شده در زبان های برنامه نویسی Python 3 و Bash کنترل می شود که تمام مراحل را همانطور که در معماری سیستم پویا توضیح داده شده است پوشش می دهد ( شکل 5 ). فرآیند هماهنگ سازی داده های LUCAS رویه ای است. به عنوان یک سری مراحل محاسباتی که در سطح پایگاه داده توسط اسکریپت های نوشته شده در SQL انجام می شود تجزیه می شود. پیکربندی فرآیند هماهنگ سازی توسط مجموعه ای از فایل های CSV و JavaScript Object Notation (JSON) مدیریت می شود. پیکربندی قوی اما هنوز هم آسان برای استفاده به مدیران سیستم اجازه می دهد تا بر نتیجه فرآیند هماهنگ سازی تأثیر بگذارند. به همین ترتیب، سیستم ممکن است به راحتی توسط مشاهدات جدید LUCAS که قرار است در سال 2022 منتشر شود، گسترش یابد. کتابخانه GDAL [ 53] برای وارد کردن داده های اولیه LUCAS از سیستم فایل (P1) به جداول پایگاه داده PostGIS (P2) استفاده می شود.
وب سرویس (A2) به عنوان یک سرور نقشه پیاده سازی شده است که توسط نرم افزار منبع باز GeoServer نسخه 2.19 [ 54 ] ارائه شده است.]. GeoServer یک پیاده سازی منطبق بر OGC از تعدادی استانداردهای باز مانند خدمات نقشه وب (WMS) و سرویس پوشش وب (WCS) است. قالب‌های اضافی و گزینه‌های انتشار به عنوان افزونه در دسترس هستند، از جمله خدمات پردازش وب (WPS) و خدمات کاشی نقشه وب (WMTS). همچنین با استاندارد OGC WFS مطابقت دارد که به اشتراک گذاری ویژگی های برداری در سمت مشتری امکان استفاده را می دهد. کاربران می‌توانند مجموعه داده LUCAS را در خطوط لوله پردازش و برنامه‌های کاربردی خود بگنجانند، داده‌ها را آزاد می‌کنند و اجازه شفافیت بیشتر را می‌دهند. هنگامی که داده ها از فرآیند استقرار در دسترس می شوند، GeoServer داده های هماهنگ LUCAS را از طریق یک رابط استاندارد WFS از طریق پروتکل انتقال ابرمتن (HTTP) ارائه می دهد.
کد منبع بسته استقرار از مخزن GitLab در دسترس است ( https://gitlab.com/geoharmonizer_inea/st_lucas/st_lucas-system-deployment ، نسخه 1.0 منتشر شده توسط نویسندگان در 9 ژوئن 2022).

4.2. Frontend

قسمت جلویی، سمت کلاینت، از بسته Python (C1) و کلاینت های CLI یا GUI تشکیل شده است، همانطور که در شکل 3 نشان داده شده است. بسته Python عملکرد اصلی سمت کلاینت را برای استفاده توسط کاربر نهایی حفظ می کند، یا از طریق افزونه QGIS (C3) بدون نیاز به برنامه نویسی/اسکریپت اضافی، در حالی که توسعه دهنده مکانی ممکن است از بسته API Python به طور مستقیم برای استفاده از آن استفاده کند. زیر مجموعه های هماهنگ شده LUCAS را در خطوط لوله رصد زمین کدگذاری شده خود ادغام کنند.

4.2.1. بسته پایتون

فرانت اند بر اساس مولفه اصلی، بسته پایتون (C1) توسعه یافته است که ارتباط بین وب سرور (A2) و مشتریان کاربران را از طریق API فراهم می کند. بسته پیاده سازی شده در زبان برنامه نویسی Python 3 از سه ماژول تشکیل شده است: (1) درخواست ایجاد یک درخواست با تعیین فیلترهای مکانی، زمانی، ویژگی یا موضوعی. (2) io برای بازیابی داده های هماهنگ LUCAS ارائه شده توسط وب سرویس (A2) بر اساس درخواست ارسال شده، و ذخیره داده های بازیابی شده در سیستم فایل محلی کاربر (C2) در قالب داده مشخص. و (3) تجزیه و تحلیل برای پردازش داده های LUCAS هماهنگ دریافتی – LUCAS طبقه های پوشش زمین تجمع و ترجمه نامگذاری.
برای استفاده از Python API، کاربر درخواستی توسط LucasRequest ایجاد می کندکلاس پایتون در یک درخواست، ترکیبی از فیلترهای مکانی، زمانی، ویژگی و موضوعی ممکن است استفاده شود. فیلتر فضایی ممکن است با یک کادر محدود، کد کشور NUTS0 یا توسط یک لایه برداری چند ضلعی تعریف شده توسط کاربر تعریف شود. مختصات مکانی باید در سیستم مرجع مختصات ETRS89-extended/LAEA Europe (EPSG 3035) مشخص شود. فیلتر فضایی طبق درخواست مورد نیاز است. فیلترهای دیگر اختیاری هستند. فیلتر زمانی با فهرستی از سال‌های نظرسنجی که باید درخواست شود مشخص می‌شود. فیلتر ویژگی توسط یک عملگر، یک نام ویژگی و لیستی از مقادیر ارائه می شود. فیلتر موضوعی زیرمجموعه ای از ویژگی های هماهنگ LUCAS را برای بازیابی تعریف می کند. مثال زیر (فهرست 1) ترکیبی از تمام فیلترهای ممکن را نشان می دهد. فیلتر فضایی با یک کادر محدود ( request.bbox) پوشش کل قلمرو اتحادیه اروپا؛ فیلتر زمانی ( request.years ) نتیجه را به سال های بررسی 2015 و 2018 محدود می کند. و فیلتر مشخصه ( request.propertyname ، request.operator ، request.literal و request.logical ) فقط مشاهدات LUCAS را با کلاس های پوشش زمین (ویژگی LUCAS LC1)، C21 (در جنگل های مخروطی تحت سلطه صنوبر)، یا C22 (تحت تسلط کاج) انتخاب می کند. جنگل های سوزنی برگ). فیلتر موضوعی ( request.group ) زیرمجموعه ای از ویژگی های هماهنگ LUCAS را فقط برای آنهایی که مربوط به گروه موضوعی “پوشش زمین، کاربری زمین” هستند (کد LC_LU در ضمیمه A  جدول A2 ) تعریف می کند.
فهرست 1. درخواست ایجاد کنید.
from st_lucas import LucasRequest
from owslib.fes import PropertyIsEqualTo، یاrequest = LucasRequest ()
request.bbox = (1510105, −2292253, 8582000, 5306000) request.years
= [2018]
request.opertyproty 1 , 201 request.
= PropertyIsEqualTo
request.literal = [‘C21’, ‘C22’]
request.logical = یا
request.group = ‘LC_LU’
بازیابی زیر مجموعه LUCAS با توجه به فیلترهای تعریف شده و ذخیره سازی داده ها توسط یک کلاس LucasIO Python مدیریت می شود. داده های LUCAS از وب سرویس (A2) با روش LucasIO.download() بر اساس نمونه کلاس LucasRequest مشخص شده بازیابی می شوند. تعداد نمونه های LUCAS بازیابی شده با روش LucasIO.count() برگردانده می شود (فهرست 2).
لیست 2. زیر مجموعه LUCAS را بر اساس درخواست دانلود کنید.
از st_lucas import~LucasIO

lucasio = LucasIO ()
lucasio.download (درخواست)
چاپ (‘تعداد امتیاز LUCAS:’، lucasio.count ())

داده‌های دانلود شده LUCAS ممکن است در یک سیستم فایل محلی (C2) به‌عنوان یک فایل OGC GeoPackage با روش LucasIO.to_gpkg() برای پردازش بیشتر در برنامه‌های GIS ذخیره شوند یا با روش LucasIO.to_geopandas() به یک شی GeoDataFrame تبدیل شوند. ممکن است توسط کتابخانه GeoPandas در کد پایتون پردازش و تجزیه و تحلیل شود [ 55 ].
ماژول تجزیه و تحلیل پایتون دو قابلیت تحلیلی را ارائه می دهد. کلاس Python LucasClassAggregate تجمیع کلاس های پوشش زمین LUCAS را پیاده سازی می کند. علاوه بر تجمیع کلاس‌های پوشش زمین، این ماژول همچنین امکان ترجمه نام‌گذاری LUCAS به نام‌گذاری‌های دیگر را با استفاده از کلاس LucasClassTranslate Python ارائه می‌دهد. استفاده پیچیده Python API در چندین مورد استفاده نشان داده شده است و در بخش 5 مورد بحث قرار گرفته است .
API کلاینت پایتون ممکن است مستقیماً توسط کد پایتون (CLI)، اجرای نوت بوک Jupyter یا افزونه توسعه یافته QGIS (GUI) استفاده شود. Jupyter Notebook به عنوان یک پلت فرم محاسباتی تعاملی مبتنی بر وب، امکان کاوش داده های تعاملی [ 56 ] را برای توسعه دهندگان فضایی فراهم می کند. کد منبع بسته پایتون و نوت‌بوک‌های Jupyter که قابلیت‌های سیستم را نشان می‌دهند در مخزن GitLab موجود هستند ( https://gitlab.com/geoharmonizer_inea/st_lucas/st_lucas-python-package ، نسخه 1.0 منتشر شده توسط نویسندگان در 9 ژوئن 2022). ).
4.2.2. افزونه QGIS
یکی دیگر از گزینه‌های هماهنگ شده فضا-زمان LUCAS، استفاده از افزونه ST_LUCAS QGIS است. این افزونه یک رابط کاربری گرافیکی است که در پلتفرم منبع باز QGIS یکپارچه شده است. رابط کاربری ( شکل 7) به سه تب تقسیم می شود: (1) دانلود; (2) تجزیه و تحلیل؛ و (3) عکس. ارزش افزوده استفاده از GIS انتخاب تعاملی فیلترهای مکانی، ویژگی، زمانی و موضوعی از GUI (برگه دانلود) است. به طور خاص، انتخاب یک منطقه مورد علاقه (فیلتر فضایی) را بر اساس وسعت بوم نقشه، مشخصات یک کشور از لیست کشورهای اتحادیه اروپا یا استفاده از لایه داده چند ضلعی بردار تعریف شده توسط کاربر را امکان پذیر می کند. رابط افزونه اجازه می دهد تا لیستی از سال های انتخاب شده (فیلتر زمانی) و گروهی از ویژگی ها (فیلتر موضوعی) نیز مشخص شود. در مجموع پنج گروه موضوعی برای انتخاب وجود دارد که هر گروه علاوه بر ویژگی های اساسی، دارای ویژگی های موضوعی خاصی نیز می باشد. گروه های زیر در دسترس هستند: پوشش زمین، کاربری زمین. پوشش زمین، کاربری اراضی، خاک; جنگلداری؛ کوپرنیک؛ و الهام بخش PLCC (ضمیمه A  جدول A2 ). کاربر همچنین می تواند نقاط LUCAS را با تمام ویژگی های موجود دانلود کند.
برگه Analyze عملکردی را برای انجام یک تجمع کلاس تعریف شده توسط کاربر با استفاده از یک فایل JSON و یک ترجمه نامگذاری با استفاده از یک فایل CSV یکپارچه می کند. نمونه ای از استفاده در اسناد افزونه موجود به صورت آنلاین در وب سایت ST_LUCAS ( https://geoforall.fsv.cvut.cz/st_lucas/qgis_plugin/ ، نسخه 1.0 منتشر شده توسط نویسندگان در 9 ژوئن 2022) گنجانده شده است.
کاربران همچنین می‌توانند عکس‌ها (یک عکس روبه‌رو و چهار عکس منظره در جهت قطب‌نمای اصلی) یک نقطه LUCAS انتخابی را در برگه عکس ( شکل 8 ) که توسط سرویس GISCO ارائه شده است، مرور کنند [ 57 ].
زیرمجموعه داده های هماهنگ فضا-زمان LUCAS بازیابی شده از سرور در قالب OGC GeoPackage با یک سبک از پیش تعریف شده برای استفاده بیشتر ذخیره می شود. سبک نقاط LUCAS برای تشخیص طبقات پوشش زمین در سطح اول نامگذاری LUCAS همانطور که در شکل 7 نشان داده شده است، تعریف شده است . علاوه بر این، نقاط با نماد دایره ای نشان می دهد که عکس ها برای نمایش در دسترس هستند. نقاط با علامت مربع برعکس را نشان می دهند.
کد منبع افزونه QGIS در مخزن GitLab موجود است ( https://gitlab.com/geoharmonizer_inea/st_lucas/st_lucas-qgis-plugin ، نسخه 1.0 منتشر شده توسط نویسندگان در 9 ژوئن 2022).

4.3. استقرار سیستم ST_LUCAS

به منظور افزایش قابلیت حمل سیستم ST_LUCAS توسعه یافته، فناوری مجازی سازی Docker [ 50] استخدام شده. تمام اجزای Backend از طریق مجازی سازی مستقر می شوند. چهار سرویس مستقر وجود دارد که توسط ابزار Docker-compose مدیریت می‌شوند که هر کدام در یک محفظه Docker ایزوله اجرا می‌شوند: (1) db: مسئول استقرار پایگاه داده مکانی-زمانی (P2) شامل داده‌های فضا-زمان هماهنگ LUCAS. (2) gs: مسئول اجرای یک سرور نقشه ارائه دهنده سرویس OGC WFS (A2) است. (3) gsp: مسئول انتشار داده های هماهنگ فضا-زمان LUCAS به عنوان یک سرویس WFS. فرآیند انتشار زمانی انجام می شود که استقرار پایگاه داده با موفقیت کامل شود. در این مرحله، فراداده و اسناد سیستم نیز پر می شود. هنگامی که فرآیند انتشار با موفقیت تکمیل شود، سرویس خاتمه می یابد. و (4) gst: تست های یکپارچه سازی مکرر را انجام می دهد ( جدول 3) کنترل عملیاتی بودن سیستم. سیاههها به صورت عمومی در دسترس هستند. و مدیر سیستم از طریق ایمیل مطلع می شود.
استقرار سیستم ST_LUCAS اجزای موجود در لایه های پایداری و کاربردی را همانطور که در شکل 3 نشان داده شده است، کنترل می کند . DB مکانی-زمانی (P2) توسط یک ظرف Docker (db) مدیریت می شود که سیستم فایل سرور (P1) را به عنوان یک حجم نصب می کند. از آنجایی که بسته استقرار سیستم (A1) تمام مراحل استقرار را مدیریت می کند، برای همه کانتینرهای Docker (db، gs، gsp، و gst) از طریق حجم نصب شده در دسترس است.
استقرار کامل سیستم ST_LUCAS توسط یک فرمان انجام می شود: docker-compose up .
نصب نمایشی سیستم ST_LUCAS، موجود در https://geoforall.fsv.cvut.cz/st_lucas (نسخه 1.0 منتشر شده توسط نویسندگان در 9 ژوئن 2022)، در سیستم عامل گنو/دبیان نسخه 11 مستقر شده است.

5. بحث

سیستم ST_LUCAS توسعه یافته دارای چندین کاربرد است. مدیران سیستم ممکن است سیستم را بگیرند و آن را (ظرفیت های داکر) در مؤسسات خود همانطور که هست نصب کنند (هدف O1). توسعه دهندگان زمین فضایی ممکن است از سیستم فعلی استفاده کنند (مثلاً پیکربندی کنند) و اجازه دهند برای اهداف خود اجرا شود (O2). کاربران زمین مکانی ممکن است با استفاده از API پایتون ماشین به ماشین یا پلاگین تعاملی QGIS (O4) به مجموعه داده هماهنگ مکانی-زمانی LUCAS و زیر مجموعه های آن دسترسی داشته باشند. داده ها توسط یک رابط استاندارد تعریف شده توسط OGC WFS (O3) ارائه می شود. این سیستم به توسعه دهندگان و کاربران زمین فضایی اتوماسیون کامل و قابل تنظیم فرآیند هماهنگ سازی برای به روز رسانی های نظرسنجی LUCAS گذشته و آینده، زیرمجموعه مکانی-زمانی و موضوعی داده ها بر اساس فیلترهای تعریف شده توسط کاربر، ترجمه افسانه پوشش زمین به یک نامگذاری تعریف شده را ارائه می دهد.
در مرحله بعد، استفاده از سیستم ST_LUCAS را از طریق دو مورد استفاده ( بخش 5.1 و بخش 5.2 )، علاوه بر استفاده از سیستم توصیف شده توسط Witjes و همکاران، نشان داده و مورد بحث قرار می دهیم. [ 29 ] برای نقشه برداری پوشش زمین در مقیاس اروپایی بین سال های 2000 و 2019.

5.1. داده های LUCAS برای تجزیه و تحلیل تغییر پوشش زمین

در اولین مورد استفاده، نحوه بازیابی بردار تغییر پوشش زمین را از سیستم ST_LUCAS نشان می‌دهیم. با فرض اینکه کاربر فضای مکانی بخواهد مدل تغییر طبقه بندی را کالیبره کند یا محصول تغییر پوشش زمین موجود را تأیید کند، باید زیر مجموعه ای از داده ها را با بازدیدهای مکرر از نقاط جغرافیایی یکسان بازیابی کنیم. این کار ممکن است به سادگی با انتخاب نقاط LUCAS که در آن بازدیدهای مکرر بیشتر از یک است تنظیم شود. همانطور که در بخش 1 ذکر شد ، در مجموع 319150 نقطه نمونه حداقل دو بار و 35204 نمونه پنج بار بازدید می شود.
در زیر، یک کد قطعه پایتون (فهرست 3) نحوه بازیابی نقاط LUCAS را با بازدیدهای مکرر برای تجزیه و تحلیل تغییر پوشش زمین با استفاده از ویژگی SURVEY_COUNT برای AOI (مناطق مورد علاقه) در جمهوری چک نشان می دهد. 11084 نقطه با فیلتر مکانی و زمانی اولیه بازیابی شد، در حالی که با اضافه کردن شرط SURVEY_COUNT > 1 زیر مجموعه ای از 6175 امتیاز دریافت کردیم.
فهرست 3. درخواستی برای تجزیه و تحلیل تغییر پوشش زمین ایجاد کنید.
از st_lucas واردات LucasRequest
از owslib.fes import~PropertyIsGreaterThan درخواست= LucasRequest ()

request.countries = [‘CZ’]
request.st_aggregated = True
request.group = ‘LC_LU’

request.propertyname = ‘SURVEY_COUNT’
request.operatorGreaT = خواص
تحت اللفظی = 1

در شکل 9 ، نمونه ای از بردار تغییر پوشش زمین (کدهای LC1: B16، B15، B55، E10، و E20) را برای مورد پنج بازدید مکرر در محل (2006، 2009، 2012، 2015، و 2018) نشان می دهیم. ، همراه با عکس های اورتوفوتو در پس زمینه. این به وضوح تغییر چشم انداز مستند شده توسط ارتوفوتوها و تغییر کدهای LC در پایگاه داده LUCAS را نشان می دهد.

5.2. داده های LUCAS برای اعتبارسنجی محصول زمین

در مورد استفاده بعدی، استفاده از داده‌های LUCAS را برای اعتبارسنجی محصول زمین نشان می‌دهیم. در این مورد، اعتبار سنجی سیستم شناسایی قطعه زمین در سطح ملی (LPIS) جمهوری چک برای سال 2018، که یک مجموعه داده باز است [ 58 ]. ما اعتبارسنجی را به دو کلاس کشاورزی ساده کردیم، زمین‌های زراعی (کلاس 1) و علفزار (کلاس 2)، که اکثر زمین‌های کشاورزی را در LPIS نشان می‌دهند. در ابتدا، ما زیرمجموعه داده‌های LUCAS را با فیلترهای مکانی و زمانی مربوطه در فرآیند اعتبارسنجی، مشابه قطعه کد در فهرست 1، بازیابی کردیم. سپس از LucasClassAggregate استفاده کردیم.کلاس پایتون از بسته توسعه یافته پایتون برای ساده کردن نامگذاری به افسانه تعریف شده در بالا (فهرست 4). آرگومان متد یک فرهنگ لغت پایتون است که نگاشت کلاس ها را برای فرآیند تجمیع تعریف می کند.
فهرست 4. تجمیع طبقه پوشش زمین را انجام دهید.
از st_lucas import~LucasClassAggregate

lc1_to_agri = {
“1”: [“B11”, “B12″، “B13″، “B14”, “B15″، “B16”, “B17”, “B18”,
“B19″, ” B21، B22، B23، B31، B32، B33، B34،
B35، B36، B37، B41، B42، B43 “B44″، “B45”
“B51″، “B52″، “B53″، “B54″، “B55”, “B71″، “B72″، “B73″،
“B74″، “B75″، “B76” “B77”, “B81”, “B82”, “B83”, “B84”]،
“2”: [“E10”, “E20”, “E30”]
}

lucasaggr = LucasClassAggregate(lucasio.data, mappings =lc1_to_agri)
lucasaggr.apply ()

لایه برداری بازیابی شده با نامگذاری تجمیع شده با محصول LPIS پوشانده شد و شاخص های اعتبارسنجی محاسبه شد ( جدول 4 ). می توان نتیجه گرفت که محصول LPIS از دقت موضوعی بالایی برخوردار است، با امتیاز کلی F1 96٪ در مقایسه با بررسی درجا LUCAS در سال 2018.

6. نتیجه گیری

این مقاله یک سیستم داده های مکانی ST_LUCAS توسعه یافته را ارائه می دهد. یک چارچوب متن باز همه کاره برای هماهنگ سازی مجموعه داده LUCAS، توزیع توسط رابط سازگار با OGC، API کلاینت پایتون و افزونه QGIS برای بازیابی زیرمجموعه های داده، و روش هایی برای مدیریت ترجمه نامگذاری، تجمع کلاس ها و اطلاعات موضوعی. کد منبع، مستندات و دستورالعمل‌های نصب به صورت عمومی در GitLab در دسترس است ( https://gitlab.com/geoharmonizer_inea/st_lucas ، نسخه 1.0 منتشر شده توسط نویسندگان در 9 ژوئن 2022). بسته استقرار ST_LUCAS و بسته کلاینت پایتون تحت مجوز MIT و افزونه QGIS تحت GNU GPL v3 منتشر شده‌اند.
این سیستم در یک مدل مشتری-سرور چند لایه طراحی شده است که امکان ادغام با گردش‌های کاری سرتاسر را فراهم می‌کند. ادغام سیستم در گردش‌های کاری کامل از انتها به پایان توسط API پایتون تسهیل می‌شود. قابلیت انتقال سیستم به نقاط انتهایی سرور مختلف با مجازی سازی در سطح سیستم عامل با استفاده از کانتینرهای Docker تسهیل می شود. این به مخاطبان متنوعی از توسعه دهندگان و دانشمندان زمین فضایی اجازه می دهد تا از قابلیت های سیستم ST_LUCAS در محیط های خود استفاده کنند. علاوه بر این، سیستم ممکن است بر اساس نیازهای کاربر خاص پیکربندی شود. این سیستم برای بررسی جدید LUCAS در سال 2022 به محض در دسترس قرار گرفتن عمومی آماده شده است.
ما استفاده از سیستم ST_LUCAS را از طریق دو مورد استفاده ( بخش 5 ) مورد بحث قرار می دهیم. قابلیت‌های مدیریت گردش کار قبلاً برای تهیه یک مجموعه داده LUCAS مکانی-زمانی هماهنگ برای نقشه‌برداری پوشش زمین در مقیاس اروپایی بین سال‌های 2000 و 2019 آزمایش شده‌اند [ 29 ]. تجربه به‌دست‌آمده از این مورد استفاده در مقیاس بزرگ، ضرورت روش‌های کمکی را برای ترجمه و تجمیع نام‌گذاری پوشش زمین، که یک ویژگی رایج در سیستم‌های توزیع خالص نیست، اثبات کرد.
به طور کلی، ما معتقدیم که سیستم ST_LUCAS دسترسی و قابلیت استفاده بهتری از مجموعه داده اروپایی LUCAS را از طریق یک رابط استاندارد OGC فراهم می کند. پیشرفت خاص در تجمیع فضا-زمان داده‌ها است که بر استفاده از یک پایگاه داده بررسی درجا بسیار ارزشمند برای تجزیه و تحلیل تغییرات به عنوان اولویت همه پروژه‌های نظارت بر زمین تأکید دارد. علاوه بر این، سیستم ST_LUCAS به طور کامل در پلت فرم دسکتاپ QGIS یکپارچه شده است و امکان کاوش تعاملی داده های LUCAS و تجزیه و تحلیل مستقیم GIS را فراهم می کند. به عنوان ادامه توسعه ST_LUCAS، ما قصد داریم موارد استفاده نمایشی گسترده را اجرا کنیم. به طور خاص، ما قصد داریم ارزش بازدیدهای مکرر در محل را برای تشخیص تغییر پوشش زمین بررسی کنیم. برای انجام این وظیفه، جداول ترجمه را از افسانه پوشش زمین LUCAS به نامگذاری های مختلف توسعه خواهیم داد.
سیستم ST_LUCAS بر اساس دانش فعلی از داده‌های اولیه به‌دست‌آمده در سال 2018 و بررسی‌های قبلی انجام‌شده از سال 2006 پیاده‌سازی شده است. این سیستم ممکن است با توجه به تغییرات در مجموعه داده LUCAS از نظرسنجی‌های بعدی به به‌روزرسانی‌های آینده نیاز داشته باشد.

اختصارات

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

API رابط برنامه نویسی کاربردی
CBSE مهندسی نرم افزار مبتنی بر کامپوننت
CLI رابط خط فرمان
CSV مقادیر جدا شده با کاما (فرمت فایل)
EPSG مجموعه داده پارامترهای ژئودتیک EPSG
اتحادیه اروپا اتحادیه اروپا
EUNIS سیستم اطلاعات طبیعت اروپا
GIS سیستم اطلاعات جغرافیایی
رابط کاربری گرافیکی رابط کاربر گرافیکی
HTTP پروتکل انتقال ابرمتن
الهام بخشیدن زیرساخت اطلاعات فضایی در اروپا
JSON نشانه گذاری شی جاوا اسکریپت
LC پوشش زمین
لوکاس بررسی قاب کاربری و منطقه تحت پوشش
آجیل و خشکبار نامگذاری واحدهای سرزمینی برای آمار
OGC کنسرسیوم فضایی باز
PLCC اجزای پوشش زمین خالص
SDI زیرساخت داده های مکانی
SQL زبان پرس و جو ساختاریافته
UML زبان مدلسازی یکپارچه
WCS خدمات پوشش وب
WFS سرویس ویژگی وب
WMS خدمات نقشه وب
WMTS خدمات کاشی نقشه وب
WPS خدمات پردازش وب

منابع

  1. آکیتسو، TK; مشاهدات ناساهارا، KN در محل در مقیاس وضوح متوسط ​​برای اعتبار سنجی محصولات اکولوژیکی ماموریت مشاهده تغییر جهانی-اقلیم: تعیین کمیت عدم قطعیت در داده های مرجع اکولوژیکی. بین المللی J. Appl. زمین Obs. Geoinf. 2022 ، 107 ، 102639. [ Google Scholar ] [ CrossRef ]
  2. لی، جی جی; کانگ، ام. داده های بزرگ جغرافیایی: چالش ها و فرصت ها. بیگ دیتا Res. 2015 ، 2 ، 74-81. [ Google Scholar ] [ CrossRef ]
  3. ایشوارپا; Anuradha, J. مقدمه ای مختصر بر ویژگی های Big Data 5Vs و فناوری Hadoop. Procedia Comput. علمی 2015 ، 48 ، 319-324. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  4. کوباراکیس، م. استامولیس، جی. بیلیداس، دی. Ioannidis، T. پانتازی، DA; ولاسوف، وی. پایبره، ق. وانگ، تی. شیخ الاسلامی، س. هاگوس، دی اچ. و همکاران فناوری‌های هوش مصنوعی و کلان داده برای داده‌های کوپرنیک: پروژه EXTREMEEARTH در مجموعه مقالات کنفرانس 2021 در مورد داده های بزرگ از فضا، رویداد مجازی، 18 تا 20 مه 2021؛ ص 9-12. [ Google Scholar ] [ CrossRef ]
  5. بررسی اجمالی – آمار پوشش زمین/استفاده. در دسترس آنلاین: https://ec.europa.eu/eurostat/web/lucas (در 11 آوریل 2022 قابل دسترسی است).
  6. بتیو، ام. دلینسه، جی. برویاس، پ. کروی، دبلیو. Eiden، G. بررسی چارچوب منطقه: هدف، اصول و بررسی های عملیاتی. در ساخت شاخص های کشاورزی و زیست محیطی، با تمرکز بر چارچوب منطقه اروپا بررسی LUCAS ; یورواستات: لوکزامبورگ، 2002; ص 12-27. [ Google Scholar ] [ CrossRef ]
  7. فریتز، اس. مک کالوم، آی. شیل، سی. پرگر، سی. گریل مایر، آر. آچارد، اف. کراکسنر، اف. Obersteiner, M. Geo-Wiki.Org: استفاده از جمع سپاری برای بهبود پوشش جهانی زمین. Remote Sens. 2009 ، 1 ، 345-354. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  8. دفورنی، پی. مایو، پی. هرولد، ام. Bontemps، S. تجارب اعتبار سنجی نقشه جهانی پوشش زمین: به سوی توصیف عدم قطعیت کمی. در سنجش از دور کاربری و پوشش زمین ; Giri, CP, Ed. CRC Press: Boca Raton، FL، USA، 2016; ص 207-223. [ Google Scholar ] [ CrossRef ]
  9. بستن، O. بنیامین، بی. پتیت، اس. فریپیات، ایکس. هالوت، E. استفاده از پایگاه داده Sentinel-2 و LUCAS برای فهرست کاربری اراضی، تغییر کاربری زمین، و جنگلداری در والونیا، بلژیک. Land 2018 , 7 , 154. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  10. ویگاند، ام. استاب، ج. ورم، م. Taubenböck، H. اثرات فضایی و معنایی نمونه‌های LUCAS بر طبقه‌بندی کاربری زمین/پوشش زمین کاملاً خودکار در داده‌های Sentinel-2 با وضوح بالا. بین المللی J. Appl. زمین Obs. Geoinf. 2020 , 88 , 102065. [ Google Scholar ] [ CrossRef ]
  11. Pflugmacher، D.; رابه، ا. پیترز، ام. Hostert، P. نقشه برداری پوشش زمین سراسر اروپا با استفاده از معیارهای طیفی-زمانی Landsat و بررسی اروپایی LUCAS. سنسور از راه دور محیط. 2019 ، 221 ، 583-595. [ Google Scholar ] [ CrossRef ]
  12. گائو، ی. لیو، ال. ژانگ، ایکس. چن، ایکس. می، جی. Xie, S. تجزیه و تحلیل ثبات و ارزیابی دقت سه محصول جهانی 30 متری با پوشش زمین در اتحادیه اروپا با استفاده از مجموعه داده LUCAS. Remote Sens. 2020 , 12 , 3479. [ Google Scholar ] [ CrossRef ]
  13. d’Andrimont، R. یوردانوف، م. مارتینز-سانچز، ال. آیزلت، بی. پالمیری، آ. دومینیسی، پی. گالیگو، جی. رویتر، HI; جوبگس، سی. لموئین، جی. و همکاران هماهنگ سازی پوشش زمین و پایگاه داده استفاده از LUCAS در محل برای بررسی های میدانی از سال 2006 تا 2018 در اتحادیه اروپا. علمی داده 2020 ، 7 ، 352. [ Google Scholar ] [ CrossRef ]
  14. بورلی، پی. پوسن، جی. Vanmaercke، M. بالابیو، سی. هرواس، جی. مرکر، ام. اسکارپا، اس. Panagos، P. نظارت بر فرسایش خندقی در اتحادیه اروپا: یک رویکرد جدید بر اساس بررسی قاب کاربری زمین/منطقه پوششی (LUCAS). بین المللی حفظ آب خاک Res. 2022 ، 10 ، 17-28. [ Google Scholar ] [ CrossRef ]
  15. Jeppesen، JH; عبید، ای. یاکوبسن، RH; Toftegaard، TS زیرساخت فضایی باز برای مدیریت داده ها و تجزیه و تحلیل در تحقیقات بین رشته ای. محاسبه کنید. الکترون. کشاورزی 2018 ، 145 ، 130-141. [ Google Scholar ] [ CrossRef ]
  16. ویمن، اس. براونر، جی. کاراش، پی. هنزن، دی. برنارد، ال. طراحی و نمونه اولیه یک سیستم اطلاعاتی کیفیت هوای آنلاین قابل عملیات. محیط زیست مدل. نرم افزار 2016 ، 79 ، 354-366. [ Google Scholar ] [ CrossRef ]
  17. لی، دبلیو. وانگ، اس. Bhatia, V. PolarHub: یک موتور خزنده وب در مقیاس بزرگ برای کشف خدمات OGC در زیرساخت سایبری. محاسبه کنید. محیط زیست سیستم شهری 2016 ، 59 ، 195-207. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  18. کلاگ، اچ. Kmoch، A. پورتال آب زیرزمینی SMART: یک چارچوب سازماندهی خدمات وب OGC برای هیدرولوژی برای بهبود دسترسی و تجسم داده ها در نیوزیلند. محاسبه کنید. Geosci. 2014 ، 69 ، 78-86. [ Google Scholar ] [ CrossRef ]
  19. بهترین، BD; هالپین، PN; فوجیوکا، ای. بخوانید، ای جی. کیان، اس.اس. هازن، LJ; سرویس‌های وب جغرافیایی شیک، RS در یک گردش کار علمی: پیش‌بینی زیستگاه‌های پستانداران دریایی در یک محیط پویا. Ecol. به اطلاع رساندن. 2007 ، 2 ، 210-223. [ Google Scholar ] [ CrossRef ]
  20. روزاتی، جی. زورزی، ن. زولیانی، دی. پیفر، اس. Rizzi، A. یک اکوسیستم وب سرویس برای ارزیابی خطر جریان زباله با کیفیت بالا و مقرون به صرفه. محیط زیست مدل. نرم افزار 2018 ، 100 ، 33-47. [ Google Scholar ] [ CrossRef ]
  21. راوتنباخ، وی. کوتزی، اس. ایوانیاک، الف. هماهنگی خدمات وب OGC برای تولید نقشه های موضوعی در زیرساخت اطلاعات مکانی. محاسبه کنید. محیط زیست سیستم شهری 2013 ، 37 ، 107-120. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  22. سرویس ویژگی وب|OGC. در دسترس آنلاین: https://www.ogc.org/standards/wfs (در 11 آوریل 2022 قابل دسترسی است).
  23. OGC API—ویژگی ها در دسترس آنلاین: https://ogcapi.ogc.org/features/ (در 11 آوریل 2022 قابل دسترسی است).
  24. جولیانی، جی. ری، ن. Lehmann, A. زیرساخت داده‌های فضایی مبتنی بر شبکه برای علوم محیطی: چالش‌ها و فرصت‌ها. ژنرال آینده. محاسبه کنید. سیستم 2011 ، 27 ، 292-303. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  25. Blauth، DA; Ducati, JR یک سیستم مبتنی بر وب برای مدیریت تاکستان ها، مربوط به داده های موجودی، بردارها و تصاویر. محاسبه کنید. الکترون. کشاورزی 2010 ، 71 ، 182-188. [ Google Scholar ] [ CrossRef ]
  26. زیوتی، ف. فریرا، KR; کی روش، GR; Neves، AK; کارلوس، اف.ام. سوزا، اف سی؛ سانتوس، لس آنجلس؛ Simoes, REO پلت فرمی برای ادغام داده های کاربری و پوشش زمین و تحلیل مسیر. بین المللی J. Appl. زمین Obs. Geoinf. 2022 ، 106 ، 102655. [ Google Scholar ] [ CrossRef ]
  27. داده ها – آمار پوشش زمین/استفاده. در دسترس آنلاین: https://ec.europa.eu/eurostat/web/lucas/data (در 11 آوریل 2022 قابل دسترسی است).
  28. سالنامه منطقه ای یوروستات 2021. در دسترس آنلاین: https://ec.europa.eu/statistical-atlas/viewer/ (در 11 آوریل 2022 قابل دسترسی است).
  29. ویتجس، م. پارنت، ال. ون دیمن، سی. هنگل، تی. لاندا، م. برادسکی، ال. هالونووا، ال. کریزان، جی. آنتونیک، ال. ایلی، سی. و همکاران یک چارچوب یادگیری ماشین مجموعه فضایی-زمانی برای تولید نقشه‌های سری زمانی کاربری/پوشش زمین برای اروپا (2000-2019) بر اساس LUCAS، CORINE و GLAD Landsat. PeerJ-Life Environ. 2022; پذیرفته شد . [ Google Scholar ] [ CrossRef ]
  30. LUCAS Primary Data 2006. در دسترس آنلاین: https://ec.europa.eu/eurostat/en/web/lucas/data/primary-data/2006 (در 8 آوریل 2022 قابل دسترسی است).
  31. LUCAS Primary Data 2009. در دسترس آنلاین: https://ec.europa.eu/eurostat/en/web/lucas/data/primary-data/2009 (در 8 آوریل 2022 قابل دسترسی است).
  32. داده های اولیه LUCAS 2012. در دسترس آنلاین: https://ec.europa.eu/eurostat/en/web/lucas/data/primary-data/2012 (در 8 آوریل 2022 قابل دسترسی است).
  33. داده های اولیه LUCAS 2015. در دسترس آنلاین: https://ec.europa.eu/eurostat/en/web/lucas/data/primary-data/2015 (در 8 آوریل 2022 قابل دسترسی است).
  34. داده‌های اولیه LUCAS 2018. در دسترس آنلاین: https://ec.europa.eu/eurostat/en/web/lucas/data/primary-data/2018 (در 8 آوریل 2022 قابل دسترسی است).
  35. LUCAS Grid — آمار پوشش زمین/استفاده. در دسترس آنلاین: https://ec.europa.eu/eurostat/web/lucas/data/lucas-grid (در 8 آوریل 2022 قابل دسترسی است).
  36. LUCAS 2009. سند مرجع فنی C3 طبقه بندی (پوشش زمین و کاربری زمین). در دسترس آنلاین: https://ec.europa.eu/eurostat/documents/205002/208938/LUCAS2009_C3-Classification_20121004.pdf (در 27 مه 2020 قابل دسترسی است).
  37. LUCAS 2012. سند مرجع فنی C3 طبقه بندی (پوشش زمین و کاربری زمین). موجود به صورت آنلاین: https://ec.europa.eu/eurostat/documents/205002/208012/LUCAS_2012_C3-Classification_20131004_0.pdf (در 27 مه 2020 قابل دسترسی است).
  38. LUCAS 2015. سند مرجع فنی C3 طبقه بندی (پوشش زمین و کاربری زمین). در دسترس آنلاین: https://ec.europa.eu/eurostat/documents/205002/6786255/LUCAS2015_C3-Classification_20160729.pdf (در 27 مه 2020 قابل دسترسی است).
  39. LUCAS 2018. سند مرجع فنی C3 طبقه بندی (پوشش زمین و کاربری زمین). در دسترس آنلاین: https://ec.europa.eu/eurostat/documents/205002/8072634/LUCAS2018-C3-Classification.pdf (در 27 مه 2020 قابل دسترسی است).
  40. محتویات داده های اولیه لوکاس 2006. در دسترس آنلاین: https://ec.europa.eu/eurostat/documents/205002/209869/Contents_LUCAS_2006_primary_data.xls (در 27 مه 2020 قابل دسترسی است).
  41. LUCAS Survey 2009 Technical Reference Document c-1: Instructions for Surveyors. در دسترس آنلاین: https://ec.europa.eu/eurostat/documents/205002/208938/LUCAS+2009+Instructions (در 27 مه 2020 قابل دسترسی است).
  42. LUCAS Survey 2012 Technical Reference Document c-1: Instructions for Surveyors. در دسترس آنلاین: https://ec.europa.eu/eurostat/documents/205002/208012/LUCAS2012_C1-InstructionsRevised_20130110b.pdf (در 27 مه 2020 قابل دسترسی است).
  43. LUCAS Survey 2015 Web CSV Record Descriptor. در دسترس آنلاین: https://ec.europa.eu/eurostat/documents/205002/6786255/WebCsv_RecordDescriptor20161006.pdf (در 27 مه 2020 قابل دسترسی است).
  44. توصیفگر رکورد CSV وب بررسی LUCAS 2018. در دسترس آنلاین: https://ec.europa.eu/eurostat/documents/205002/8072634/LUCAS2018-RecordDescriptor-190611.pdf (در 27 مه 2020 قابل دسترسی است).
  45. اسناد PostGIS-ST_GeometricMedian. در دسترس آنلاین: https://postgis.net/docs/ST_GeometricMedian.html (در 11 آوریل 2022 قابل دسترسی است).
  46. وایزفلد، ای. Plastria, F. در نقطه ای که مجموع فاصله های n نقطه داده شده حداقل است. ان اپراتور Res. 2009 ، 167 ، 7-41. [ Google Scholar ] [ CrossRef ]
  47. واله، تی. کرنکویچ، آی. د آلمیدا، ES; دا موتا سیلویرا نتو، PA; کاوالکانتی، YC; de Lemos Meira، SR بیست و هشت سال مهندسی نرم افزار مبتنی بر کامپوننت. جی. سیست. نرم افزار 2016 ، 111 ، 128-148. [ Google Scholar ] [ CrossRef ]
  48. Nierstrasz، O. Meijler، TD جهت تحقیق در ترکیب نرم افزار. کامپیوتر ACM. Surv. 1995 ، 27 ، 262-264. [ Google Scholar ] [ CrossRef ]
  49. Pytest: به شما کمک می کند تا برنامه های بهتری بنویسید—Pytest Documentation. در دسترس آنلاین: https://docs.pytest.org/en/7.1.x/ (در 13 آوریل 2022 قابل دسترسی است).
  50. مرکل، دی داکر: ظروف سبک لینوکس برای توسعه و استقرار مداوم. Linux J. 2014 ، 2014 ، 2. موجود به صورت آنلاین: https://dl.acm.org/doi/10.5555/2600239.2600241 (در 13 آوریل 2022 قابل دسترسی است).
  51. PostgreSQL: پیشرفته ترین پایگاه داده منبع باز جهان. در دسترس آنلاین: https://www.postgresql.org/ (دسترسی در 13 آوریل 2022).
  52. اسناد PostGIS. در دسترس آنلاین: https://postgis.net/ (در 13 آوریل 2022 قابل دسترسی است).
  53. اسناد GDAL. در دسترس آنلاین: https://gdal.org/ (دسترسی در 13 آوریل 2022).
  54. اسناد GeoServer. در دسترس آنلاین: https://geoserver.org/ (در 13 آوریل 2022 قابل دسترسی است).
  55. اسناد GeoPandas. در دسترس آنلاین: https://geopandas.org/en/stable/ (در 13 آوریل 2022 قابل دسترسی است).
  56. Perkel، JM BY Jupyter، همه چیز منطقی است. طبیعت 2018 ، 563 ، 145-146. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  57. داده های مرجع – GISCO. در دسترس آنلاین: https://gisco-services.ec.europa.eu/lucas/photos/ (دسترسی در 11 آوریل 2022).
  58. سیستم شناسایی قطعه زمین – LPIS. در دسترس آنلاین: https://eagri.cz/public/app/lpisext/lpis/verejny2/plpis/ (در 1 فوریه 2022 قابل دسترسی است).
شکل 1. فاصله بین GPS اندازه گیری شده و نقاط نظری (ویژگی OBS_DIST). در مجموع 35509 نقطه با مسافت بیش از 1000 متر در این شکل نشان داده نشده است.
شکل 2. تجمیع فضا-زمان مکان های مشاهده شده LUCAS GPS (نماد دایره) با استفاده از میانه هندسی (نماد الماس). مکان تئوری به LUCAS 2×2 کیلومتر رسید 22شبکه با یک نماد مستطیل نشان داده می شود. فواصل بین مکان های GPS و میانه با خطوط چین دار فلش نشان داده می شود.
شکل 3. معماری سطح بالای ثابت سیستم ST_LUCAS. نوت بوک Jupyter (خط نقطه چین) به عنوان یک جزء نرم افزاری در نظر گرفته نشده است. نوت بوک Jupyter در این کار برای ارائه عملکرد بسته Python (C1) و ارائه تأییدیه دستی استفاده می شود.
شکل 4. اجزای نرم افزار سیستم ST_LUCAS با رابط های تعریف شده.
شکل 5. معماری پویا ST_LUCAS (استقرار سیستم).
شکل 6. معماری پویا ST_LUCAS تعامل کاربر سیستم.
شکل 7. پلاگین ST_LUCAS QGIS (با یک کادر قرمز برجسته شده است) که داده های هماهنگ LUCAS را برای قلمرو جمهوری چک بازیابی می کند (نقشه پایه پس زمینه: OpenStreetMap — سرویس نمای عمومی WMS).
شکل 8. نمایش عکس های LUCAS از سرویس GISCO توسط افزونه ST_LUCAS QGIS.
شکل 9. نمونه ای از تغییر پوشش زمین در طول زمان برای POINT_ID = 46642928 همانطور که در مجموعه داده LUCAS ثبت شده است (عکس های پس زمینه: اداره نقشه برداری زمین و کاداستر ایالت چک — سرویس نمای عمومی WMS).

بدون دیدگاه

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