SPM GEO / RESEARCH

ثبت CR و پیکربندی؛ شناسنامه قابل ردیابی از میدان تا GECORIS

راهنمای مختصات مرکز فاز، هندسه و زمان اعتبار، reflectors.json، stacks.json و gecoris.parms — بازبینی ۱۶ اکتبر ۲۰۲۶.

راهنمای فنی · بازبینی ۱۶ اکتبر ۲۰۲۶ مشاهده پرونده پایلوت ←

فهرست این صفحه

۱. ثبت CR؛ حلقه اتصال میدان و پردازش

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

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

۲. نقش فایل‌ها و جداسازی سوابق

ارتباط پرونده میدان با reflectors.json و stacks.json و فایل اجرای GECORIS — شکل ۱ — معماری پیشنهادی ثبت و اجرا؛ پرونده میدان، ورودی مستقیم GECORIS نیست.

مرجع پایش و اتصال فایل‌ها ↗

فیلد یا موضوع	معنا و کنترل
reflectors.json	شناسه و وضعیت زمانی بازتابنده، مختصات دو هندسه دید و مشخصات فیزیکی
stacks.json	شناسه مجموعه، محل داده، سنجنده، زیرنوار و نوع ورودی
gecoris.parms	اتصال فایل‌های ثبت به پروژه و تنظیمات اجرای پایش
پرونده میدان مستقل	برداشت اصلی، مدل تبدیل، آفست، عکس، عدم‌قطعیت و رویدادها؛ قالب داخلی پیشنهادی SPM GEO
ثبت اجرای پردازش	نسخه کد و محیط، hash پیکربندی، داده ورودی و خروجی

۳. هویت بازتابنده و شناسه پایدار

برای هر نمونه فیزیکی یک شناسه یکتا و ثابت تعریف کنید؛ برای مثال CR-QZ-001 صرفاً نمونه نام‌گذاری است. جابه‌جایی، تعویض یا تغییر هندسه با یک رویداد و نسخه ثبت شود؛ تغییر اسم دلخواه نباید ارتباط سوابق را از بین ببرد.

فهرست stations در فایل ثبت، حاوی رکوردهای بازتابنده است. type=CREF در نمونه رسمی برای کرنر رفلکتور آمده است. نمونه رسمی همچنین بخش stacks را در همان فایل دارد؛ برای مدیریت روشن‌تر این پروژه، فایل‌های ثبت بازتابنده و Stack جدا باشند و مسیر هرکدام در parms مشخص شود.

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

قالب اصلی reflectors.json؛ شامل مقدارهای نمونه خارجی ↗

۴. زمان نصب، شروع معتبر و دوره‌های اختلال

installDate زمان نصب فیزیکی است؛ startDate آغاز دوره قابل قبول برای تحلیل است. ممکن است تنظیم نهایی یا تثبیت پایه بعد از نصب انجام شده باشد. endDate پایان بازه معتبر را بیان می‌کند. قالب نمونه YYYYMMDDTHHMMZ است؛ Z به معنی UTC است، نه ساعت محلی.

تاریخ شمسی و ساعت محلی را در پرونده میدان نگه دارید و تبدیل مستند به میلادی و UTC انجام دهید. برای نمونه صرفاً آموزشی، ۲۰۲۶/۱۰/۱۶ ساعت ۱۲:۰۰ تهران، با اختلاف +۰۳:۳۰، برابر 20261016T0830Z است؛ این زمان نصب پایلوت نیست.

نشانگر 99999999T9999Z در فایل رسمی دیده می‌شود، اما تاریخ تقویمی معتبر نیست. فقط اگر Reader نسخه شما آن را می‌پذیرد از آن استفاده کنید؛ null یا رشته خالی را نیز خودسرانه معادل پایان باز نگیرید.

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

نمودار شماتیک نصب و تنظیم و تعمیر و بازه‌های معتبر بازتابنده — شکل ۲ — تفاوت نصب با آغاز اعتبار و اثر تعمیر میانی؛ تاریخ و مدت‌ها فرضی و بدون مقیاس‌اند.

۵. ascending و descending؛ دو پرونده هندسی

رکورد رسمی دو شاخه ascending و descending دارد. orientation در آن boolean است؛ زاویه آزیموت را در این فیلد ننویسید. true بودن دو شاخه نمونه به معنی مناسب‌بودن هر CR برای هر دو گذر نیست.

برای هر شاخه، پوشش واقعی Track و جهت‌دهی دهانه را بررسی کنید. اگر شاخه‌ای استفاده نمی‌شود، قرارداد Reader برای غیرفعال‌کردن آن را رعایت کنید؛ حذف کلید، false و null لزوماً هم‌معنا نیستند. قالب همراه تا تعیین وضعیت، مقدار null دارد و آماده اجرا نیست.

band در نمونه رسمی برابر * است. این مقدار را بدون بررسی Reader به VV یا C تغییر ندهید؛ نام فیلد به‌تنهایی ثابت نمی‌کند که منظور قطبش، باند فرکانسی یا الگوی انتخاب باند نرم‌افزار است. قطبش مورد استفاده را جدا در پرونده Stack ثبت کنید.

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

۶. کدام نقطه باید مختصات داشته باشد؟

سه نقطه را از هم جدا کنید: نشانه ثابت زمینی یا پایه، نقطه اندازه‌گیری‌شده با GNSS/توتال، و نقطه مرجع الکترومغناطیسی بازتابنده مطابق مدل. مختصات گوشه بیرونی ورق یا بالاترین رأس سازه لزوماً مختصات نقطه مورد انتظار مدل نیست.

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

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

تفکیک نقطه برداشت GNSS و نقطه مرجع بازتابنده و بردار اتصال میان آن‌ها — شکل ۳ — مفهوم بردار اتصال؛ شکل مکانیکی CR در این نمودار بازسازی نشده و ابعاد واقعی نیست.

مقاله اصلی GECORIS و مدل اندازه‌گیری ↗

\mathbf r_{\mathrm{CR}}^{\mathrm{ECEF}}=\mathbf r_{\mathrm{survey}}^{\mathrm{ECEF}}+\mathbf R_{\mathrm{ENU}\rightarrow\mathrm{ECEF}}\,\Delta\mathbf r_{\mathrm{survey}\rightarrow\mathrm{CR}}^{\mathrm{ENU}}

انتقال مختصات با بردار اتصال؛ هر دو جمله باید در یک چارچوب و epoch سازگار باشند.

۷. طول، عرض و ارتفاع؛ واحدها و ترتیب

در خروجی JSON، عدد اعشاری با نقطه و ارقام لاتین نوشته می‌شود؛ از جداکننده هزارگان، ویرگول اعشاری یا نوشتن واحد داخل مقدار عددی خودداری کنید. latitude باید در بازه ±۹۰ و longitude در بازه ±۱۸۰ باشد؛ عبور از این کنترل ساده به معنی درست‌بودن Datum یا محل نقطه نیست.

فیلد یا موضوع	معنا و کنترل
longitude / latitude	در قالب نمونه، طول و عرض جغرافیایی درجه اعشاری؛ از جابه‌جایی ترتیب جلوگیری کنید
elevation	ارتفاع نقطه مرجع با تعریف سازگار با مسیر ژئودتیکی؛ مرجع عمودی صریح باشد
UTM	Easting/Northing متری ورودی مستقیم longitude/latitude نیست؛ تبدیل با زون، نیمکره و Datum صحیح
دقت عددی	تعداد زیاد اعشار، دقت برداشت را اثبات نمی‌کند؛ عدم‌قطعیت جدا ثبت شود
مختصات خام و نهایی	هر دو نگه داشته شوند؛ روش تبدیل و آفست بین آن‌ها ثبت شود
کنترل متقابل	نمایش روی نقشه و تبدیل رفت‌وبرگشت؛ کنترل نقطه و واحد ارتفاع

۸. ارتفاع بیضوی و ارتومتریک

برای محاسبات سه‌بعدی متصل به مدار، نوع ارتفاع اهمیت مستقیم دارد. اگر داده برداشت H ارتومتریک است و مسیر به h بیضوی نیاز دارد، تبدیل با مدل ژئوئید سازگار و علامت درست انجام شود. مدل را صرفاً بر اساس در دسترس بودن انتخاب نکنید.

مثال آموزشی: اگر H=1200.000 m و N=−20.000 m باشد، h=1180.000 m است. اعداد، نمونه محاسباتی‌اند و ارتفاع یا ژئوئید محل پایلوت را نشان نمی‌دهند. مدل‌های منطقه‌ای آمریکا در مرجع NGS برای ایران قابل استفاده مستقیم نیستند.

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

توضیح رسمی رابطه ارتفاع در NGS ↗

h=H+N

h ارتفاع بیضوی، H ارتفاع ارتومتریک و N جدایی ژئوئید از بیضوی؛ مرجع‌ها باید سازگار باشند.

۹. CRS، FRAME، EPOCH و EPSG

نمونه رسمی از ETRS-89، ETRF2000 و epoch برابر 2010.0 استفاده می‌کند. این مقادیر شناسنامه نمونه اروپایی هستند؛ برای قزوین نباید از آن‌ها تقلید کرد. مرجع واقعی حل GNSS و اتصال آن به مرجع مورد انتظار پردازش باید معلوم باشد.

EPSG نام سامانه مختصات را مشخص می‌کند، ولی نوشتن آن به‌تنهایی تبدیل مختصات اجرا نمی‌کند. یک CRS دوبعدی نیز خودبه‌خود مرجع عمودی elevation را تعریف نمی‌کند. FRAME تحقق مرجع و EPOCH دوره مختصات است؛ epoch مرجع چارچوب با زمان مشاهده یا دوره مختصات یکسان فرض نشود.

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

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

۱۰. ثبت هندسه و قرارداد زاویه‌ها

مشخصات هندسی را از نقشه ساخت و اندازه‌گیری نمونه نهایی استخراج کنید. shape نام قراردادی مدل و flipped وضعیت هندسی مطابق همان مدل است. پذیرش نام مدل‌های دیگر یا ترکیب دلخواه shape/flipped را بدون بررسی نسخه کد فرض نکنید.

leglength را با تعریف طول ساق در شکل رسمی تطبیق دهید؛ ضلع بیرونی سازه، قطر دهانه، ارتفاع پایه و طول ساق لزوماً برابر نیستند. مقدار حدود یک متر اعلام‌شده برای ورق، بدون کنترل هندسی نباید مستقیم به این فیلد منتقل شود.

azimuthDip و zenithDip را با شکل تعریف GECORIS و قرارداد محور/علامت همان نسخه تطبیق دهید. این‌ها را با heading ماهواره، incidence angle، زاویه ارتفاع دید یا شیب یک ورق به‌صورت خودکار برابر نگیرید. صفر در مدل می‌تواند وضعیت اسمی مدل را توصیف کند، نه افقی‌بودن ورق یا حذف زاویه نصب.

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

۱۱. RCS0، مقدار مجهول و مقدار صفر

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

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

در ثبت مهندسی، مقدار، واحد و منشأ جدا باشند. اگر واحد dB نسبت به یک مترمربع باشد، صفر dBm² برابر یک مترمربع است، نه نبود بازتاب. مقدارهای لگاریتمی و خطی را با هم میانگین نگیرید مگر روش تعریف شده باشد.

واحد RCS در مثال پیش‌بینی SCR ↗

\sigma_{\mathrm{dBsm}}=10\log_{10}\!\left(\frac{\sigma}{1\,\mathrm{m}^{2}}\right)

رابطه RCS خطی و dBsm (یا dBm²)؛ واحد مورد انتظار RCS0 همچنان باید در نسخه Reader کنترل شود.

۱۲. stacks.json؛ هویت داده و مسیر واقعی

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

sensor، subswath و type با مقادیر مورد انتظار Reader تنظیم شوند. raw در مسیر پایش مستند به داده SLC آماده در هندسه بومی اشاره دارد؛ آن را با محصول Sentinel-1 RAW Level-0 اشتباه نگیرید. coreg را صرفاً با عوض‌کردن رشته type جایگزین نکنید.

dataPath را با قرارداد Reader تطبیق دهید: ممکن است ریشه Track را بگیرد و خودش slaves را پیدا کند. تنها وجود پوشه کافی نیست؛ روی یک محصول واقعی بررسی کنید کدام فایل خوانده می‌شود. مسیر دوباره‌شده مانند slaves/slaves نشانه خطای قرارداد مسیر است.

قالب رسمی stacks.json ↗

فیلد یا موضوع	معنا و کنترل
id	شناسه ثابت مجموعه و پیوند خروجی‌ها
dataPath	مسیر قابل خواندن توسط محیط اجرای واقعی؛ نه مسیر رایانه دیگر
sensor	مقدار نمونه Sentinel-1؛ پشتیبانی سکو و metadata جدا کنترل شود
subswath	IW1، IW2 یا IW3 متناسب با پوشش واقعی
type	raw برای مسیر نمونه؛ شاخه‌های دیگر نیازمند تأیید Reader

۱۳. تنظیمات gecoris.parms و اثر آن‌ها

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

تصحیح تأخیر جوی در مکان‌یابی مطلق را با برآورد APS در شبکه InSAR یکی نگیرید. فعال‌بودن flag باید با موجودبودن داده خارجی، وضعیت اجرا و ثبت تصحیح همراه باشد.

فیلد یا موضوع	معنا و کنترل
project	شناسه پروژه؛ مستقل از نام یک بازتابنده
stationLog / stackLog	مسیر فایل‌های ثبت معتبر و بازبینی‌شده
outDir	پوشه خروجی همان run_id؛ جلوگیری از اختلاط نتایج
precisePosFlag	۰ مسیر تقریبی / ۱ دقیق در نمونه؛ ۱ به‌تنهایی تضمین دقت نیست
atmoFlag	۰ یا ۱ برای استفاده از مدل خارجی تأخیر جو؛ دریافت و کاربرد واقعی باید کنترل شود
plotFlag	۰ بدون نمودار، ۱ مختصر، ۲ تفصیلی در مستند نمونه
ovsFactor	عامل oversampling FFT؛ ۳۲ نمونه رسمی است، نه مقدار بهینه اثبات‌شده برای پایلوت

۱۴. JSON و فایل پارامتر را اشتباه نگیرید

JSON استاندارد از کوتیشن دوتایی، true/false و null استفاده می‌کند؛ کامنت و کامای انتهایی ندارد. فایل .parms نمونه با نحو Python است و می‌تواند از True/False/None استفاده کند. parse شدن یک قالب فقط صحت نحوی را نشان می‌دهد، نه قبول‌شدن توسط GECORIS.

در مسیر Windows داخل JSON، بک‌اسلش باید escape شود یا از مسیر با / استفاده شود؛ برای نمونه D:/SAR/project/config/reflectors.json. مسیرهای Linux و Windows را در یک اجرا مخلوط نکنید. مطمئن شوید نام فایل‌ها UTF-8 و مقادیر عددی با ارقام لاتین هستند.

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

bash

python -m json.tool config/reflectors.json
python -m json.tool config/stacks.json
# Syntax checks only; reader and scientific checks are still required.

۱۵. پرونده میدان و عکس‌های لازم

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

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

۱۶. قالب‌های آماده تکمیل و مثال کنترل‌شده

فایل‌های همراه، پیش‌نویس‌اند. null یعنی ثبت‌نشده و صفر نیست؛ رشته REPLACE_* یعنی جایگزینی لازم است. تا تکمیل، کنترل واحدها و آزمون Reader، آن‌ها را اجرا نکنید. زمان، مختصات، هندسه و نتیجه‌ای برای پایلوت ساخته نشده است.

روال پیشنهادی: ابتدا پرونده میدان را پر کنید؛ سپس مقادیر نهایی تأییدشده را به قالب نرم‌افزار انتقال دهید. کلیدهای پیشنهادی داخلی مثل uncertainty و photos را بدون پشتیبانی صریح به ورودی GECORIS اضافه نکنید.

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

۱۷. کنترل پیش از اجرا و آزمون کوچک

شناسه‌ها یکتا باشند و مسیرهای stationLog و stackLog واقعاً به نسخه مورد تأیید اشاره کنند.
هیچ مقدار الزامی null یا REPLACE_* باقی نمانده باشد؛ نوع عدد، boolean و رشته با Reader منطبق باشد.
طول/عرض، ارتفاع، چارچوب و epoch با گزارش برداشت و تبدیل تطبیق داده شوند.
علامت و واحد آفست، زاویه‌ها و RCS، و نقطه مرجع هندسی تأیید شوند.
بازه‌های فعال با زمان UTC برداشت‌های Sentinel-1 تطبیق داده شوند؛ رویدادهای میانی لحاظ شوند.
روی یک CR و یک Stack، بارگذاری فایل‌ها و تشخیص محصول را در نسخه واقعی کد آزمون کنید.
محل پیش‌بینی‌شده را با اطراف هدف مقایسه کنید؛ صرف نزدیک‌بودن یک پیکسل روشن، اثبات تطابق هدف نیست.
یک برداشت معتبر پس از نصب و در صورت دسترسی یک برداشت پیش از نصب را برای کنترل هویت و کلاتر بررسی کنید.
در صورت فعال‌کردن تصحیحات، موجودبودن و اعمال واقعی آن‌ها را در log بررسی کنید.
پیکربندی پذیرفته‌شده را با شناسه اجرا، نسخه کد و hash آرشیو کنید.

۱۸. خطاهای متداول و راه تشخیص

فیلد یا موضوع	معنا و کنترل
هدف در محل پیش‌بینی‌شده نیست	ترتیب طول/عرض، UTM به جای درجه، آفست مرکز فاز، FRAME و epoch
خطای ارتفاع بزرگ یا ثابت	H به جای h، علامت N، ارتفاع آنتن یا نقطه مرجع اشتباه
عدم دریافت تصویر برای Stack	dataPath، قرارداد slaves، Track، زیرنوار و بازه زمانی
پاسخ ضعیف در یک جهت	orientation، هندسه واقعی، قطبش، سایه یا مانع؛ نه الزاماً خطای نرم‌افزار
رکورد JSON خوانده نمی‌شود	کوتیشن، کاما، null/None و مسیر Windows
RCS مرجع غیرعادی	واحد خطی/لگاریتمی، طول ساق، مدل شکل و اولویت کلید RCS0
نتیجه پس از تعمیر عوض شده	تغییر زاویه/مرکز فاز/محیط؛ نیاز به نسخه جدید شناسنامه
خطای ثابت در همه تاریخ‌ها	بایاس مختصات یا قرارداد مرجع را بررسی کنید؛ آن را خودکار حرکت زمین تعبیر نکنید
تنظیم دقیق فعال است ولی کیفیت تغییر نمی‌کند	مسیر کد، پیش‌نیازها و اعمال واقعی تصحیح را ممیزی کنید

۱۹. نسخه‌بندی و خروجی پایلوت

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

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

ادامه: انتخاب محل و پیش‌بینی SCR ↗

فیلد یا موضوع	معنا و کنترل
شناسه و عکس‌های واقعی CR	در انتظار تکمیل
مختصات مرکز فاز و عدم‌قطعیت	در انتظار برداشت/کنترل
CRS، FRAME، epoch و مرجع ارتفاع	در انتظار تأیید
هندسه، زاویه‌ها و قرارداد واحد	در انتظار اندازه‌گیری و تطبیق کد
جهت گذر و Stackهای معتبر	در انتظار کنترل داده
تاریخ نصب، شروع اعتبار و رویدادها	در انتظار ثبت
نسخه Reader و نتیجه آزمون کوچک	در انتظار اجرا
پیکربندی نهایی و امضای بازبینی	در انتظار پذیرش

بخش قبلآماده‌سازی و هم‌ثبت‌سازی ادامه مطالعهپیش‌بینی SCR محل ←

همکاری برای ارزیابی میدانی

برای گفت‌وگو درباره محل پایلوت، داده راداری یا اندازه‌گیری مستقل با تیم پژوهش در ارتباط باشید.

ارتباط با تیم پژوهش ←