نقشه راه پردازش بازتابنده راداری؛ از SLC تا نتیجه قابل دفاع

۱. دامنه، شیوه استفاده و شرط شروع

این نقشه راه برای پردازش بازتابنده راداری با داده Sentinel-1 SLC و زنجیره مبتنی بر SNAP و GECORIS تنظیم شده است. ترتیب کار، قرارداد فایل‌ها، نقاط توقف و شواهد پذیرش را کنار هم می‌آورد. جزئیات هر مرحله باید با نسخه واقعی کد، داده و هدف اندازه‌گیری تطبیق داده شود؛ وجود یک فرمان در مستندات به معنی اجرای موفق آن در محیط شما نیست.

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

۲. نقشه کلان؛ سه مسیر متفاوت

انتخاب مسیر از محصول مورد نیاز شروع می‌شود. پایش عملیاتی پاسخ و مکان‌یابی روی تصاویر آماده‌شده در هندسه بومی انجام می‌شود؛ پیش‌بینی SCR و InSAR به مجموعه هم‌مرجع‌شده نیاز دارند. در روال خودکار CR-InSAR، پایش بازتابنده پیش‌نیاز است. [۱، ۲، ۳، ۴]

نمودار وابستگی سه مسیر پردازشراهنمای مفهومی

۳. مرحله صفر؛ تعریف مسئله و معیار پذیرش

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

معیار پذیرش پیش از مشاهده نتیجه مطلوب تعریف شود. آستانه SCR، کیفیت فاز، باقیمانده شبکه و اختلاف با مرجع مستقل باید با کاربرد و بودجه خطا سازگار باشند. برای یک محیط و بازه زمانی ناشناخته، کپی‌کردن آستانه‌های مثال نرم‌افزار مبنای علمی کافی ندارد.

• شناسه پروژه، شناسه هدف، مسئول پردازش و تاریخ بازبینی را ثبت کنید.
• نقش هدف را تعیین کنید: نقطه متحرک، مرجع یا هدف کالیبراسیون.
• دوره قبل از نصب، تاریخ نصب، شروع بهره‌برداری و تعمیرها را جدا کنید.
• داده مستقل و چارچوب مقایسه را از ابتدا طراحی کنید؛ آن را به پایان پردازش موکول نکنید.
• خروجی مورد انتظار، شواهد پذیرش و موارد توقف را در برنامه پایلوت ثبت کنید.

۴. محیط اجرایی و سازگاری نسخه‌ها

نسخه Python، SNAP، Java، رابط Python، کتابخانه‌های عددی و نسخه یا commit کد باید مشخص باشند. مستندات GECORIS 0.1 به محیط قدیمی ارجاع می‌دهند؛ این تنظیمات را دستور نصب عمومی برای نسخه‌های جدید تلقی نکنید. در SNAP جدید رابط esa_snappy مطرح است، درحالی‌که کد قدیمی ممکن است snappy را وارد کند. تغییر نام import به‌تنهایی سازگاری کل زنجیره را اثبات نمی‌کند. [۵، ۶]

محدودیت حافظه Python و Java، فضای موقت و فضای دیسک خروجی را جدا بررسی کنید. با یک محصول و محدوده کوچک، مصرف واقعی و زمان اجرا را اندازه بگیرید؛ اعداد بزرگ ram و cores در مثال مستندات برای رایانه شما الزام یا پیشنهاد قطعی نیستند.

1. وجود و دسترسی به کد مورد نیاز هر شاخه را کنترل کنید؛ به‌ویژه ماژول‌های InSAR.
2. در محیط انتخاب‌شده، رابط SNAP را import و یک محصول واقعی را باز کنید.
3. ابعاد، نام باندهای مختلط و فراداده را بخوانید؛ سپس محصول را ببندید.
4. یک عملیات کوچک SNAP را اجرا و خروجی را دوباره باز کنید؛ import موفق کافی نیست.
5. گزارش نسخه‌ها، مسیر ابزارها، پارامتر حافظه و نتیجه آزمون را نگه دارید.

۵. نظم فایل‌ها و دفتر ثبت اجرا

داده خام را تغییرناپذیر نگه دارید و خروجی هر اجرا را با run_id مستقل ثبت کنید. جدول زیر ساختار پیشنهادی پروژه است؛ نام و محل مورد انتظار پوشه‌های پردازش را با کد واقعی تطبیق دهید. از یک مسیر مشترک برای چند مدار یا چند آزمایش پارامتر استفاده نکنید.

۶. دریافت داده و کنترل فهرست مشاهدات

برای هر Stack، مدار نسبی، جهت گذر، حالت IW، قطبش و پوشش زیرنوار/Burst را کنترل کنید. تاریخ پوشش محدوده به‌تنهایی سازگاری داده‌ها را نشان نمی‌دهد. شناسه سنجنده و نسخه پردازش محصول نیز ثبت شوند؛ ادغام محصولات از واحدهای مختلف مأموریت نیازمند کنترل سازگاری است.

فهرست تاریخ‌های انتخاب‌شده را با فایل‌های واقعاً دریافت‌شده تطبیق دهید. فایل ناقص، نسخه تکراری یک برداشت، sliceهای یک گذر و مشاهدات خارج از بازه را تفکیک کنید. شمار فایل‌های ZIP الزاماً برابر شمار مشاهدات مستقل نیست. زمان را در دفتر پردازش با UTC و قالب مشخص نگه دارید.

• بسته SLC باید داده مختلط و فراداده مربوط را داشته باشد؛ تصویر پیش‌نمایش یا GRD جایگزین نیست.
• برای محصول SAFE، manifest، annotation و measurement و اطلاعات کالیبراسیون مرتبط بررسی شوند.
• پوشش مکانی واقعی هدف و حاشیه لازم برای استخراج پاسخ کنترل شود.
• سرویس SLC Burst می‌تواند داده مختلط ارائه کند، اما سازگاری قالب آن با ورودی wrapper باید جدا آزموده شود. [۷]
• جدول وضعیت هر مشاهده داشته باشید: دریافت‌شده، معتبر، مشکوک یا کنارگذاشته‌شده همراه دلیل.

۷. انتخاب محدوده مکانی و بازه زمانی

محدوده کوچک برای آزمون خواندن داده و تشخیص قله مفید است؛ محدوده لازم برای شبکه PS، اتصال مرجع و برآورد جو ممکن است بسیار بزرگ‌تر باشد. هم وسعت جغرافیایی و هم Burstهای مورد نیاز را بررسی کنید. هدف نباید بر اثر برش نزدیک مرز، حذف یا بخشی از پاسخ آن بریده شود.

داده پیش از نصب برای ارزیابی زمینه مفید است؛ اما از همان مختصات نمی‌توان حرکت بازتابنده‌ای را استنباط کرد که هنوز وجود نداشته است. تاریخ نصب و تاریخ شروع عملکرد معتبر ممکن است یکسان نباشند. پس از جابه‌جایی یا تغییر جهت اساسی، پیوستگی سری زمانی باید دوباره ارزیابی شود.

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

۸. آماده‌سازی Burstها و حفظ اطلاعات مختلط

در مسیر مستند GECORIS، batchPrepare از تنظیمات snap.parms برای آماده‌سازی استفاده می‌کند و Burstهای استخراج‌شده در slaves قرار می‌گیرند. گزارش مدار و پوشش هر خروجی را بررسی کنید؛ صرف وجود پوشه slaves نشانه کامل‌شدن همه تاریخ‌ها نیست. [۱]

برای این مسیر، تبدیل زودهنگام به تصویر شدت یا اجرای فیلتر اسپکل مخصوص GRD روی ورودی تحلیل فاز درست نیست. اعمال عملگرهایی مثل Deburst، کالیبراسیون یا بازنمونه‌برداری باید مطابق گراف مورد استفاده باشد؛ افزودن دستی یک عملگر بدون شناخت انتظار مرحله بعد می‌تواند قالب یا هندسه مورد نیاز را تغییر دهد.

۹. Station Log و Stack Log؛ اتصال واقعیت میدان به داده

پیش از Monitoring، هویت بازتابنده و Stack باید بدون ابهام به هم وصل شوند. مختصات را با نقشه و موقعیت مورد انتظار در تصویر کنترل کنید. خطای جابه‌جایی latitude/longitude، واحد زاویه یا ارتفاع ممکن است به انتخاب هدف دیگری منجر شود، درحالی‌که برنامه بدون خطا اجرا شده است.

قالب رسمی reflectors.json مشخصات زمان فعالیت، جهت‌های مشاهده، مختصات و geometry را جدا نگه می‌دارد. مقادیر نمونه مانند شناسه، چارچوب اروپایی یا ابعاد بازتابنده مستندات، تنظیمات پایلوت ما نیستند. [۸]

۱۰. شاخه A؛ پایش رادیومتری و مکان‌یابی

پایش روی هندسه بومی تصاویر آماده‌شده انجام می‌شود و در روال مستند به coreg نیاز ندارد. مختصات پیش‌بینی‌شده هدف، ناحیه پاسخ و قله مشاهده‌شده برای هر تاریخ بررسی می‌شوند. خروجی‌های RCS، SCR و ALE/APE را جدا بخوانید؛ بازتاب قوی معادل مکان‌یابی درست یا اندازه‌گیری جابه‌جایی درست نیست. [۲]

نام اسکریپت ورودی Monitoring در این صفحه حدس زده نمی‌شود. آن را از README و فایل‌های همان نسخه تعیین کنید؛ تابع یا اسکریپتی که فقط در یک شاخه وجود دارد ممکن است در نسخه دیگر موجود نباشد. ابتدا یک هدف و چند تاریخ را بررسی و سپس اجرای دسته‌ای را توسعه دهید.

• ناحیه جست‌وجو باید پاسخ هدف را دربر بگیرد و با هدف روشن مجاور اشتباه نشود.
• Oversampling محل قله را درون‌یابی می‌کند؛ افزایش آن به معنی افزایش تفکیک مستقل سنجنده نیست.
• RCS با واحد خطی یا لگاریتمی مشخص، SCR بر حسب dB و خطای مکان‌یابی با جهت و واحد ثبت شود.
• نمونه‌های دارای آب‌گرفتگی، تغییر جهت یا پاسخ غیرعادی با گزارش میدانی تطبیق داده شوند.
• برآورد نویز ناشی از SCR را با عدم‌قطعیت کامل جابه‌جایی شامل جو و مرجع برابر نگیرید.

۱۱. انتخاب مرجع هندسی و هم‌مرجع‌سازی

برای شاخه‌های B و C، یک تصویر مرجع هندسی انتخاب می‌شود و نمونه‌ها در هندسه مشترک قرار می‌گیرند. در پیاده‌سازی توصیف‌شده GECORIS از ساختار single-master و تصحیح ESD استفاده می‌شود. کیفیت داده، پوشش و فاصله‌های زمانی و مداری در انتخاب master مهم‌اند. [۱]

کنترل را به دیدن دو تصویر روی هم محدود نکنید: باقیمانده هم‌مرجع‌سازی، وضعیت ESD، مرزهای Burst و نواحی بدون داده بررسی شوند. خطاهای TOPS ممکن است به شکل نوار یا جهش فاز ظاهر شوند. اگر master یا مجموعه Burst تغییر کند، سازگاری خروجی‌های قبلی را دوباره بررسی کنید.

1. مرجع هندسی و دلیل انتخاب آن را ثبت کنید؛ شناسه محصول را به تاریخ تنها محدود نکنید.
2. برای هر مشاهده، نتیجه تطبیق هندسی و پوشش مشترک را نگه دارید.
3. خروجی شکست‌خورده یا نیمه‌کاره را با موفق تلقی‌کردن پوشه از کنترل عبور ندهید.
4. چند نمونه هم‌مرجع‌شده را از نظر دامنه و فاز و مرزها بررسی کنید.
5. فقط تاریخ‌های پذیرفته‌شده را با همان فهرست و ترتیب به شاخه بعد منتقل کنید.

۱۲. شاخه B؛ پیش‌بینی SCR محل پیشنهادی

ورودی planning.json باید مختصات محدوده، RCS مورد انتظار طراحی و Stack سازگار را مشخص کند. در قالب مستند، cropSize شعاع بر حسب متر و RCS مقدار لگاریتمی نسبت به یک مترمربع است؛ خروجی scrSimul یک GeoTIFF از SCR پیش‌بینی‌شده است. [۳]

برای مقایسه محل‌ها، فرض طراحی و دوره مشاهدات را ثابت یا تغییر آن را صریح کنید. اگر داده پس از نصب استفاده شود، پاسخ خود هدف نباید به عنوان کلاتر قبل از نصب تفسیر شود. نواحی بدون داده، CRS، اندازه پیکسل و بازه مقادیر فایل خروجی را بررسی کنید.

تصمیم نهایی علاوه بر نقشه، به دید مستقیم، پایداری محل، اهداف مزاحم، نگهداری و هندسه نصب وابسته است. یک مقدار پیش‌بینی‌شده بالا، تأیید RCS واقعی یا تضمین دقت InSAR نیست.

۱۳. شاخه C؛ امکان اجرا و آماده‌سازی مجموعه InSAR

مستندات عمومی GECORIS 0.1 بخش InSAR را دارای محدودیت دسترسی معرفی می‌کنند. پیش از برنامه‌ریزی اجرا، وجود کد، مجوز استفاده، توابع و قالب فایل‌ها در نسخه دریافت‌شده احراز شود. اگر این ماژول در دسترس نیست، مسیر جایگزین باید با ورودی و خروجی مشخص طراحی و اعتبارسنجی شود؛ داشتن SNAP به‌تنهایی نبود ماژول را جبران نمی‌کند. [۱۰]

در مجموعه تحلیل، SLCهای هم‌مرجع‌شده، فراداده، تاریخ‌ها، ماسک‌ها و شناسه هدف باید هم‌اندازه و هم‌ترتیب باشند. نمونه‌های نامعتبر، صفرهای ناحیه بدون داده و CR پیش از نصب را از مشاهده معتبر جدا کنید. انتخاب کاندیدهای PS از دامنه، غربال اولیه است و تضمین کیفیت فاز نیست.

این سه نام در مستندات مسیر استخراج InSAR آمده‌اند؛ <stackId> جای شناسه واقعی قرار می‌گیرد. وجود فایل بدون کنترل محتوا نشانه موفقیت مرحله نیست. [۱۰]

• فایل‌های HDF، JSON و فهرست تاریخ‌ها باید به یک Stack و یک اجرای مشخص تعلق داشته باشند.
• محصول میانی را باز کنید و کلیدها، شکل آرایه‌ها، تعداد تاریخ‌ها و تعداد نقاط را کنترل کنید.
• بستن فایل HDF پیش از بازکردن یا تغییر نسخه دیگر و پرهیز از نوشتن هم‌زمان ضروری است.
• مشخص کنید خروجی فاز رادیان است یا خروجی جابه‌جایی متر/میلی‌متر؛ تبدیل را از نام نمودار حدس نزنید.

۱۴. شبکه نقاط و رفع ابهام زمانی

ابتدا نقاط مناسب و ارتباط‌های آن‌ها انتخاب می‌شوند؛ اختلاف فاز در طول زمان روی ارتباط‌ها برای برآورد پارامترهای مدل و تعداد چرخه‌ها استفاده می‌شود. شبکه باید هم پوشش کافی داشته باشد و هم ارتباط‌های قابل اعتماد. تعداد زیاد نقاط با شبکه گسسته یا ارتباط‌های آلوده لزوماً بهتر نیست.

مدل خطی، فصلی یا مدل دیگر باید با پدیده و مدت مشاهده سازگار باشد. بازه مجاز سرعت یا ارتفاع باقیمانده را بر اساس شواهد تعیین کنید؛ محدودکردن بیش از حد مدل می‌تواند حرکت واقعی را حذف یا ابهام غلط را ترجیح دهد. پس از حذف ارتباط نامعتبر، نقاط جداافتاده و پوشش مکانی دوباره کنترل شوند.

چرخه حل و کنترل کیفیت InSARراهنمای مفهومی

۱۵. سه مرجع را از هم جدا نگه دارید

هر نتیجه باید با سه انتخاب مرجع قابل بازسازی باشد. تغییر هر کدام اثر متفاوت دارد و نباید با تغییر دیگری پنهان شود.

۱۶. جو، حل تکراری و جلوگیری از حذف حرکت واقعی

در تحلیل سری زمانی باید سهم جو از حرکت و خطاهای دیگر جدا شود. برآورد APS به توزیع نقاط، وسعت محدوده، طول سری و فرض‌های مکانی–زمانی وابسته است. کوچک‌بودن محدوده، جو را خودکار صفر نمی‌کند؛ بزرگ‌بودن محدوده نیز به‌تنهایی کافی‌بودن مدل را تضمین نمی‌کند.

پیش و پس از تصحیح، الگوی مکانی، وابستگی به ارتفاع، طیف زمانی و رابطه با رخدادهای واقعی بررسی شوند. پنجره زمانی نامناسب می‌تواند سیگنال حرکت را جذب کند یا اثر جو را باقی بگذارد. وقتی تنظیمات جو تغییر می‌کند، حل شبکه و کیفیت نتیجه دوباره ارزیابی شود و مرجع مکانی حفظ یا تغییر آن مستند شود.

برای تصحیح خارجی نیز پوشش زمانی و مکانی، نوع تأخیر، واحد و تبدیل آن به دید مایل روشن باشد. حضور یک فایل هواشناسی در پوشه به معنی اعمال صحیح تصحیح نیست. گزارش باید نشان دهد کدام مؤلفه واقعاً محاسبه و اعمال شده است.

۱۷. حل نهایی، نویز مرجع، تراکم و مکان‌گذاری

پس از حل اولیه و بررسی جو، عوامل تبدیل ارتفاع به فاز و حل دقیق‌تر، اثر نویز مرجع، افزایش تراکم و مکان‌گذاری خروجی بررسی می‌شوند. در زنجیره مستند GECORIS این مراحل پس از شبکه اولیه آمده‌اند. افزودن نقاط یا کاهش باقیمانده، به‌تنهایی تأیید نهایی نتیجه نیست. [۱۰]

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

پیش از خروجی GIS، شناسه نقطه، مختصات، واحد جابه‌جایی و سرعت، قرارداد علامت، تاریخ‌ها و مرجع را تطبیق دهید. داده غایب باید به شکل مقدار نامعتبر مشخص شود؛ صفر جابه‌جایی داده غایب نیست. تعداد رکوردها و پوشش خروجی را با مجموعه نهایی مقایسه کنید.

۱۸. اتصال CR به سری زمانی و چندمداره

در CR-InSAR، هویت هدف و شناسه Stack باید به سری زمانی همان هندسه متصل شوند. پاسخ هدف با داده پیش از نصب، هدف مجاور یا بازتابنده سمت دیگر مخلوط نشود. مستندات توصیه می‌کنند پیش از اجرای خودکار، تحلیل محدوده به‌صورت کنترل‌شده انجام شود. [۴]

اگر CR در غربال اولیه PS انتخاب نشد، ابتدا علت روشن شود: مدت فعالیت کوتاه، تغییر دامنه، نصب میان دوره یا داده نامعتبر. استخراج دستی یا ورود اجباری نقطه به شبکه مجوز عبور از کنترل فاز نیست. تنظیمات اختصاصی و معیار پذیرش آن نقطه باید ثبت شود. [۱۱]

برای ترکیب صعودی و نزولی، هدف فیزیکی یا اتصال بین اهداف، دوره زمانی، مرجع و بردارهای دید باید سازگار باشند. دو LOS مستقل برای بازیابی آزاد سه مؤلفه کافی نیست؛ تفکیک قائم و شرق–غرب به فرض درباره مؤلفه شمالی یا داده کمکی نیاز دارد. ناهم‌زمانی برداشت‌ها و خطای درون‌یابی نیز باید گزارش شوند.

۱۹. دفتر پارامترها؛ مقدار پیش‌فرض، تصمیم پروژه نیست

این جدول معنای تنظیمات را برای کنترل مرور می‌کند؛ فهرست API ثابت همه نسخه‌ها نیست. مقدار واقعی، واحد، دلیل انتخاب و نتیجه آزمون حساسیت باید کنار هر تنظیم در پرونده اجرا ثبت شود.

۲۰. فرمان‌های مستند؛ مرحله‌به‌مرحله، نه اجرای کور

فرمان‌های زیر الگوی مستند هستند و در این پروژه اجرا نشده‌اند. از ریشه مخزن سازگار و پس از ساخت و بررسی فایل پیکربندی واقعی اجرا شوند. config/ یک قرارداد پیشنهادی این راهنماست. هر بلوک فقط پس از پذیرش مرحله قبل اجرا شود؛ شاخه B و C دو هدف جدا دارند. [۱، ۳، ۴]

اسکریپت Monitoring و جزئیات اجرای InSAR باید با نسخه در دسترس مشخص شوند. کپی‌کردن یک فرمان که فایل آن وجود ندارد، مسیر اجرایی کامل نمی‌سازد. پیش از اجرا، نام فایل و نحوه خواندن پارامتر را بررسی کنید.

# Preparation: only after input and configuration checks
python gecoris/batchPrepare.py config/snap.parms

# Branches B/C: only after prepared-product QC
python gecoris/getMaster.py config/snap.parms
python gecoris/batchCoreg.py config/snap.parms

# Branch B: only with verified planning assumptions
python gecoris/scrSimul.py config/planning.json

# Branch A: use the Monitoring entry point of your actual revision.
# Branch C: requires available InSAR modules, accepted coregistration,
# validated Monitoring and a reviewed AOI-specific configuration.
python gecoris/CR_insar.py config/gecoris.parms

۲۱. ایستگاه‌های کنترل و تصمیم ادامه

۲۲. عیب‌یابی از نشانه به علت

در هر خطا، ابتدا آخرین مرحله‌ای را پیدا کنید که شواهد آن معتبر بوده است. پارامترها را یکی‌یکی یا در آزمایش تعریف‌شده تغییر دهید؛ تغییر هم‌زمان چند گزینه، علت بهبود یا افت را نامعلوم می‌کند.

۲۳. اعتبارسنجی، عدم‌قطعیت و گزارش نتیجه

مشاهده مستقل باید همان کمیت را اندازه بگیرد یا به آن تبدیل شود. برای GNSS، جابه‌جایی سه‌بعدی را روی بردار دید تصویر کنید؛ برای ترازیابی یا اندازه‌گیری قائم، اثر احتمالی حرکت افقی را در مقایسه توضیح دهید. مرجع مکانی، تاریخ صفر و زمان‌های برداشت باید هم‌تراز شوند.

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

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

• جابه‌جایی تجمعی، سرعت و پارامتر فصلی به‌صورت جدا با واحد گزارش شوند.
• حساسیت به مرجع، مدل و تنظیمات جو در محدوده معقول بررسی شود.
• داده حذف‌شده با دلیل و اثر آن بر نتیجه ثبت شود؛ نتیجه قبل و بعد از حذف قابل مقایسه باشد.
• نتایج آزمایشی، اندازه‌گیری‌شده و تأییدشده برچسب متفاوت داشته باشند.

۲۴. افزودن تاریخ جدید و تکرار کنترل‌شده

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

نسخه پذیرفته‌شده قبلی را نگه دارید و در اجرای جدید، جدول تاریخ‌ها و تمام فراداده وابسته را یکسان به‌روزرسانی کنید. اگر یک مشاهده کنار گذاشته می‌شود، فقط حذف فایل تصویر کافی نیست؛ فهرست‌ها، ماسک‌ها و داده‌های مشتق باید با آن تصمیم سازگار شوند. نمونه‌های GECORIS نیز بر هماهنگی مجموعه و فراداده تأکید دارند. [۱۱]

برای آزمایش پارامترهای شبکه، استخراج دوباره داده همیشه لازم نیست؛ ولی تغییر AOI، master، ورودی یا نحوه آماده‌سازی می‌تواند داده میانی قبلی را نامعتبر کند. پیش از استفاده مجدد، وابستگی هر خروجی به تنظیمات را بررسی کنید.

۲۵. بسته تحویل و آزمون نهایی بازتولید

تحویل باید به نفر دیگری اجازه دهد منشأ هر مقدار را دنبال کند. نتیجه معتبر فقط نمودار یا فایل CSV نیست؛ ورودی‌ها، تصمیم‌ها و محدودیت‌ها بخشی از محصول‌اند.

۲۶. ترتیب پیشنهادی برای شروع پایلوت

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

1. یک هدف، یک هندسه و یک پرسش روشن انتخاب کنید؛ دفتر نصب و مختصات را تکمیل کنید.
2. آزمون محیط را با یک SLC واقعی و یک عملیات کوچک به پایان برسانید.
3. چند تاریخ نمونه را آماده کنید و قله، پوشش و فراداده را دستی کنترل کنید.
4. Monitoring را بررسی کنید؛ پس از آن دامنه زمانی را برای شناخت رفتار پاسخ افزایش دهید.
5. برای انتخاب محل، شاخه B را با داده زمینه و فرض RCS مستند اجرا کنید.
6. برای جابه‌جایی، دسترسی به ماژول و coreg و شبکه و مرجع را تأیید و سپس شاخه C را اجرا کنید.
7. مدل و جو و ابهام‌ها را ارزیابی و با داده مستقل مقایسه کنید.
8. تنها خروجی دارای شواهد پذیرش را در قسمت نتایج پایلوت قرار دهید.

۲۷. منابع و حدود دستورالعمل

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

منابع ۱ تا ۵ و ۸ تا ۱۱ به مستندات عمومی GECORIS و قالب‌های آن مربوط‌اند؛ منبع ۶ رابط رسمی SNAP و منبع ۷ قالب داده Burst را توضیح می‌دهد. تفاوت نسخه‌ها، کلیدهای ناسازگار در مثال‌ها و محدودیت دسترسی InSAR باید پیش از اجرای واقعی حل شوند.