pp2web

ما هو؟

pp2web (post-processing to web) تطبيق ويب يعمل على الخادم لمعالجة بيانات الجلسات الخام لاحقًا، مثل تلك المسجَّلة بتطبيق الهاتف rawX، في الأوضاع التالية:

• Single
• الساكن
• الحركي
• Stop&Go (جديد)

كيف يُستعمل؟

بعد التسجيل عبر البريد الإلكتروني solutop@gmail.com يمكن طلب تفعيل تجريبي (محدد المدة) أو دائم. وبعد الحصول على بيانات الدخول استعمل هذا الرابط للدخول.

يتيح pp2web ما يلي:

• اختيار وضع المعالجة اللاحقة (Single، الساكن، الحركي، Stop&Go)
• رفع ملف خام للروفر بصيغة .ubx (Single، الساكن، الحركي)
• رفع ملف RINEX لمحطة الأساس بصيغة .YYo أو .obs (للأوضاع الساكن والحركي وStop&Go فقط)
• رفع ملف فترات Stop وGo للروفر بصيغة .csv (لوضع Stop&Go فقط)
• إدخال LLE إن كانت الإحداثيات الجغرافية الدقيقة لمحطة الأساس معلومة (للأوضاع الساكن والحركي وStop&Go فقط)
• معالجة الملف أو الملفات المرفوعة
• عرض النقاط على خريطة OSM
• تنزيل ملف مضغوط يضم ملف .csv وتقريرًا بصيغة PDF منسّقًا بـ LaTeX
• إعادة تشغيل التطبيق لاستعماله من جديد

التموضع النسبي

لنعُد خطوة إلى الوراء ولنفهم ما هو التموضع النسبي.

عند الحديث عن المعالجة اللاحقة لبيانات GNSS يُقصد تقنيات التموضع النسبي التي تتيح تحديد فرق الإحداثيات (خط الأساس) بين نقطتين أو أكثر تشغلها في الوقت نفسه عدة أجهزة استقبال قادرة على تسجيل الشيفرة والطور معًا.

ويمكن إجراؤه في الوضع الساكن (تبقى أجهزة الاستقبال في مكانها طوال جلسة قياس تتراوح مدتها بين دقائق وساعات بحسب طول خط الأساس) أو في الوضع الحركي (يبقى جهاز ثابتًا بينما يتحرك الآخر أو الآخرون فيشغلون النقاط المراد رصدها تباعًا أو يتبعون مسارًا متصلًا).

ملاحظة

وتُجرى الحسابات لاحقًا (أي ليس في الزمن الحقيقي) انطلاقًا من البيانات الخام المسجَّلة في الأجهزة. ويبلغ الوضع الساكن دقة تموضع نسبي في حدود 0,5–1 سم، ويُستعمل لتحديد شبكات خطوط الأساس لأغراض الإطار المرجعي أو لمراقبة التشوّهات.

أما الوضع الحركي فيُستعمل خصوصًا لإعادة بناء المسارات وحركية المركبات (السجل العقاري للطرق، دراسة حركة المركبات، ...). وفيما يلي مثال على التموضع النسبي

الشكل 1 تقنية التموضع النسبي بـ GNSS

في حالة الشكل أعلاه يرصد الجهازان الأقمار الصناعية نفسها في اللحظة نفسها. ثم تُعالَج هذه الرصدات لتقدير خط الأساس (متجه ثلاثي الأبعاد) بين الجهازين.

تلميح

وطريقة قياس الروفر هي التي تحدّد تقنية التموضع. وكثيرًا ما يُستعمل GNSS كصندوق مغلق: يُسجَّل القياس دون معرفة حدوده، ولذلك يجدر تخصيص بعض الوقت لفهم كيفية عمل تقنية التموضع هذه.

وتتوقف الدقة على:

• نوع أجهزة الاستقبال (نوع الرصدات التي يمكن تسجيلها)
• المسافة بين الأجهزة (من أقل من 10 كم إلى أكثر من 500 كم)
• طريقة المسح (مدة الوقوف على النقاط)
• أسلوب معالجة البيانات (الزمن الحقيقي، المعالجة اللاحقة)
• 1–2 م (نسبي على الشيفرات في الزمن الحقيقي) يُستعمل في الملاحة
• بضعة سنتيمترات (تردّدان، ساكن سريع) المساحة وأعمال نظم المعلومات الجغرافية
• مليمترية (تردّدان، ساكن طويل مع تقنيات التسوية) تشوّه القشرة الأرضية

تذكير

• تُطبَّق المعالجة اللاحقة على عمليات المسح المنفَّذة بالتموضع النسبي
• يلزم لكل نقطة من نقاط المسح تسجيل قياسات الطور (وتسمى أيضًا الرصدات)، ويُستحسن تسجيل قياسات الشيفرة أيضًا.
• تلزم المعلومات المتعلقة بمدارات أقمار الملاحة (ملفات brdc التي تتضمن معاملات المدارات، وملفات sp3 التي تتضمن مسارات المدارات)
• يجب أن تُجرى التسجيلات في وقت واحد على نقطة أو أكثر معلومة الإحداثيات وعلى النقاط المرصودة
• يتولى برنامج المعالجة حلّ الغموض الصحيح للطور
• زمن الوقوف أساسي لحلّ الغموض الصحيح للطور
• وتتوقف أزمنة الوقوف على نوع جهاز الاستقبال وطول خط الأساس وهندسة الأقمار الصناعية ووجود مصادر لتعدّد المسارات

Stop&Go

وضع Stop&Go تقنية مسح بجهازَي استقبال GNSS جيوديسيين (أحدهما ثابت والآخر متحرك)، تستفيد من رصدات طور الموجات الحاملة للحصول على إحداثيات عالية الدقة.

ملاحظة

وبخلاف الوضع الساكن الذي يبقى فيه الروفر ثابتًا على كل نقطة من 10 إلى 30 دقيقة، يتوقف الروفر في Stop&Go على كل نقطة وقفة قصيرة (10–30 ثانية) بعد مرحلة أولية لتثبيت الغموض.

مراحل العمل

أ. التهيئة (تثبيت الغموض)

• يُبدأ من نقطة معلومة أو نقطة ضبط.
• ويبقى الروفر ثابتًا من دقيقتين إلى خمس ليتمكن البرنامج من حلّ الغموض الصحيح (العدد الصحيح لدورات الموجة الحاملة بين الأقمار الصناعية وأجهزة الاستقبال).
• وعند اكتمال التثبيت (حل «fixed») يمكن الانتقال إلى رصد النقاط التالية.

ب. الانتقال بين النقاط (Go)

• ينتقل المشغّل إلى النقطة الجديدة دون إطفاء الجهاز أو مقاطعته، محافظًا على استمرار الرصدات.

تحذير

• ومن الضروري عدم فقدان الإشارة أو الحل fixed أبدًا. فالدخول في الأنفاق أو تحت الأشجار الكثيفة أو حجب رؤية الأقمار الصناعية قد يفقدك التثبيت.

ج. رصد النقاط (Stop)

• على كل نقطة مطلوبة يوضع الروفر ويثبَّت نحو 10 إلى 30 ثانية.
• وخلال هذه المدة تُجمع بيانات GNSS لحساب الإحداثيات بدقة سنتيمترية أو دون السنتيمترية.
• ويُدوَّن معرّف النقطة وزمن الوقوف وأي ملاحظات.

نصيحة

• ويُستحسن العودة إلى بعض النقاط المقيسة سابقًا للتحقق من الدقة (إغلاق المضلّع، اختبار قابلية التكرار).
• وإذا فُقد الحل fixed وجب إعادة التهيئة على نقطة معلومة.

الشكل 2 المسح في الوضع الحركي Stop&Go

المزايا

• دقة عالية (مليمترية إلى سنتيمترية).
• مرونة أكبر من الوضع الساكن الخالص.
• أسرع من المسح الساكن التقليدي.

العيوب

• يتطلب رؤية متصلة للأقمار الصناعية وللإشارة الواردة من محطة الأساس.
• يتطلب مرحلة تثبيت أولية وانتباهًا لعدم فقدان تعقّب الطور.

الأجهزة

• محطة أساس GNSS (ثابتة): توضع على نقطة معلومة، وتسجّل بيانات RINEX أو ترسل تصحيحات RTK.
• روفر GNSS (متحرك): يستقبل بيانات الأقمار الصناعية والتصحيحات من محطة الأساس.
• عمود بميزان تسوية: لضمان شاقولية النقطة.
• حامل ثنائي القوائم: لضمان شاقولية العمود
• وحدة تحكم ببرنامج ميداني: لتسجيل النقاط والبيانات الوصفية.

التطبيقات

• أعمال المسح العقاري وعالية الدقة.
• مراقبة المنشآت أو البيئة.
• شبكات الإطار الجيوديسي.
• المناطق التي لا تغطيها الإشارات اللاسلكية (الجبال، الجزر، المناطق النائية).

الإجراء

يبيّن الشكل أدناه الشاشة الرئيسية عند الدخول إلى تطبيق الويب عبر الرابط المذكور أعلاه

الشكل 1 شاشة تطبيق الويب عند التشغيل

ثم يُختار وضع معالجة البيانات الخام بين single والساكن والحركي وstop&go كما في الشاشة أدناه

الشكل 2 اختيار وضع المعالجة

ثم أكّد الوضع وأدخل:

• ملف الروفر بصيغة .ubx
• ملف محطة الأساس بصيغة .YYo أو .obs
• الملف الذي يتضمن فترات stop وgo (وضع stop&go فقط)
• ارتفاع الجهاز بالأمتار عند الاقتضاء (للأوضاع single والساكن والحركي فقط)
• إحداثيات محطة الأساس إن كانت متوفرة لديك كما في الشكل 3

ملاحظة: العملية متسلسلة، ولذلك يستحيل الإخلال بترتيب الإجراء كما في الشكل 3

ملاحظة

تجدر الإشارة إلى أن وضع single يعالج ملف الروفر بصيغة .ubx وحده، إذ لا يلزم أي ملف لمحطة الأساس في هذا الخيار لأن المعالجة تكون بحل منفرد (دقة مترية). وقد يفيد ذلك مثلًا لمعرفة الإحداثيات التقريبية للنقطة المسجَّلة في النظام الجغرافي WGS84 (L، L، E)

الشكل 3 استيراد الملفات واختيار الإحداثيات الجغرافية

ملاحظة

وإن كانت لديك ملفات RINEX افتراضية للمعالجة الساكنة أو الحركية، فلن تحتاج عند إدخال الملفات إلى كتابة LLE يدويًا للحصول على إحداثيات محطة الأساس الصحيحة، لأنها في ترويسة ملف RINEX للمحطة تكون دقيقة لا تقريبية.

وفيما يلي مثال لملف RINEX مأخوذ مثلًا من محطة أساس مرجعية دائمة؛ لاحظ في ترويسة الملف السطر «APPROX POSITION XYZ» المميَّز أدناه:

     2.11           OBSERVATION DATA    M (MIXED)           RINEX VERSION / TYPE
teqc  2016Apr1      OGS/CRS             20160608 12:19:48UTCPGM / RUN BY / DATE
Linux 2.4.21-27.ELsmp|Opteron|gcc|Linux x86_64|=+           COMMENT
BIT 2 OF LLI FLAGS DATA COLLECTED UNDER A/S CONDITION       COMMENT
UDI1                                                        MARKER NAME
12719M002                                                   MARKER NUMBER
David Zuliani       OGS/CRS                                 OBSERVER / AGENCY
618-01139           TPS NET-G3A         4.1 May,31,2013     REC # / TYPE / VERS
24204               ASH701945E_M    SCIT                    ANT # / TYPE
  4317305.9964  1016832.9984  4568261.5793                  APPROX POSITION XYZ
        0.0083        0.0000        0.0000                  ANTENNA: DELTA H/E/N
     1     1                                                WAVELENGTH FACT L1/2
     5    L1    L2    C1    P2    P1                        # / TYPES OF OBSERV
     1.0000                                                 INTERVAL
Forced Modulo Decimation to 1 seconds                       COMMENT
 SNR is mapped to RINEX snr flag value [0-9]                COMMENT
  L1 & L2: min(max(int(snr_dBHz/6), 0), 9)                  COMMENT
pseudorange smoothing corrections not applied               COMMENT
  2016     6     8    11     0    0.0000000     GPS         TIME OF FIRST OBS
    17                                                      LEAP SECONDS
                                                            END OF HEADER

ملاحظة: الإحداثيات المذكورة مركزية أرضية.

وبعد إدخال الملفات وإحداثيات محطة الأساس عند الاقتضاء، تبدأ المعالجة بالنقر على زر «معالجة»؛ وتُنفَّذ بمعاملات قياسية، ولا تتيح هذه النسخة حاليًا تعديلها. وفي حال وجود أخطاء تُعرض رسائلها على الشاشة ويتحول زر المعالجة إلى الأحمر فيمنع المراحل التالية، كما في الشكل 4

الشكل 4 معالجة الملفات المدخلة

وبعد انتهاء مرحلة المعالجة تأتي الخطوة التالية: عرض النقاط على خريطة OSM، مما يتيح تحققًا بصريًا سريعًا من البيانات المعالجة. وهذه المرحلة تلقائية وتلي السابقة مباشرةً

الشكل 5 نتيجة المعالجة على الخريطة

وبانتهاء هذه المرحلة أيضًا يمكن تنزيل النتائج في ملف مضغوط يضم:

• ملفًا بصيغة .csv يتضمن الإحداثيات ذات الحل fix لجميع الحقب في وضعَي single والساكن، إضافةً إلى الإحداثي الوحيد للوضع الساكن الناتج عن المتوسط الموزون لجميع الإحداثيات ذات الحل fix
• وملفًا بصيغة .pdf يتضمن تقريرًا مفصّلًا يرد شرحه في القسم التالي

التقرير النهائي

يصف التقرير النهائي نتائج المعالجة في مجملها ويتضمن:

• الرصدات والبيانات الوصفية (Observation Metadata)

  • المدة الإجمالية للرصدات
  • الفترة الزمنية بتوقيت UTC
  • الوضع
  • الترددات المستعملة
  • المعاملات: أدنى زاوية ارتفاع، تصحيحات الأيونوسفير، تصحيحات التروبوسفير، الجداول الفلكية
  • نسبة الحلول
  • الأقمار الصناعية المستعملة
  • ارتفاع الجهاز (للأوضاع single والساكن والحركي فقط)

• المسار الحركي (GRD Track)

• السلسلة الزمنية للموقع (Position Time Series)

• ملخص البيانات (Data Summary)

المسار الحركي

في الشكل 6 أدناه مثال لرسم بياني يمثّل المسار الذي سلكه جهاز استقبال GNSS أثناء الرصد. وهو يبيّن بصريًا حركة الجهاز على خريطة (إن وُجدت) أو عبر تسلسل من الإحداثيات المسجَّلة بنظام UTM مع اختيار المنطقة تلقائيًا.

الشكل 6 رسم بياني يمثّل الحل المستوي في E وN

البيانات المقدَّمة:

• الإحداثيات الجغرافية: خط العرض وخط الطول وارتفاع جهاز الاستقبال
• تغيّرات الموقع مع الزمن
• جودة الحل (Fix/Float وغيرهما)
• إمكان الربط البياني بخريطة المنطقة

الغرض:

• تحليل المسار والتحقق منه في سياقه المكاني

السلسلة الزمنية

في الشكل 7 أدناه مثال لرسم بياني يمثّل سلسلة زمنية مفصّلة للمواقع التي سجّلها جهاز استقبال GNSS أثناء الرصد.

الشكل 7 رسم بياني يمثّل الحل في E وN وH

البيانات المقدَّمة:

• الطابع الزمني: لكل موقع وقت محدد بتوقيت UTC
• الإحداثيات: خط العرض وخط الطول والارتفاع (بالأمتار)
• الدقة: الانحرافات المعيارية الأفقية (SDH) والرأسية (SDV)
• جودة الحل: كل موقع موسوم بـ Fix (دقة عالية) أو Float (دقة أقل)

الغرض:

• تحليل مفصّل لجودة القياسات بدلالة الزمن ولاستقرار النظام.

ملخص البيانات

في الشكل 8 أدناه جزء من مثال للملخص العام للرصدات والمعالجة. وتَرِد فيه جميع الحقب ثانيةً بثانية بصرف النظر عن جودة النقطة.

الشكل 8 ملخص الحقب المعالجة

البيانات المقدَّمة:

• إحصاءات عامة: المدة الكلية للجلسة مع المواقع حقبةً حقبة بصيغة LLE (بالدرجات)
• الدقة العامة: المتوسطات والانحرافات المعيارية للقياسات الأفقية والرأسية والحل حقبةً حقبة

الغرض:

• تقييم موجز لأداء النظام وللإعدادات المستعملة

ملاحظة

لا تتيح النسخة الحالية «ضبط المعاملات»، أي اختيار الكوكبات ومعاملات الأيونوسفير والتروبوسفير وزاوية القطع وغيرها، بل تستعمل تبسيطًا ملف إعداد قياسيًا وتحوّل ملفات الروفر الخام بخطوة ثانية واحدة

وفي وضع stop&go يعرض Data Summary ارتفاع الجهاز في عمود إضافي كما في الشكل 9 أدناه:

الشكل 9 الملخص مع النقاط المثبَّتة في stop&go

التعامل مع الطوابع الزمنية

المقياس	الوصف	مثال
UTC	التوقيت المدني العالمي، ويشمل الثواني الكبيسة	14:40:32
GPST	زمن نظام GPS المتصل، يبدأ من 6/1/1980، و**لا** يشمل الثواني الكبيسة	14:40:50

الفارق الحالي: GPST = UTC + 18 ثانية (قيمة سارية منذ 1/1/2017).

في رسائل UBX يدرج جهاز الاستقبال MS2 دائمًا الحقل leapS الذي يحمل الثواني الثماني عشرة الحالية، فيتمكن البرنامج التالي من إجراء التحويل بنفسه.

┌─────────────────────────┐
│   Ricevitore  MS2       │
│  rcvTow + week + leapS  │
└────────────┬────────────┘
             │  stream binario UBX
             ▼
┌─────────────────────────┐                ┌──────────────────────┐
│   App Android  rawX     │   eventi       │   CSV Stop&Go        │
│                         ├───────────────►│   Timestamp UTC      │
│                         │                │   (orologio telefono)│
└────────────┬────────────┘                └──────────┬───────────┘
             │ raw bytes                              │
             ▼                                        │
┌─────────────────────────┐                           │
│   File  .ubx  (GPST)    │                           │
└────────────┬────────────┘                           │
             │                                        │
╔════════════▼════════════════════════╗               │
║  pp2web — post-processing           ║               │
║  (motore RTKLIB)                    ║               │
║                                     ║               │
║   UBX → RINEX (GPST)                ║               │
║   ↓                                 ║               │
║   PPK con out-timesys = utc         ║               │
║   ↓                                 ║               │
║   File .pos  (UTC) ◄── conversione  ║               │
║                       GPST→UTC      ║               │
║   ↓                                 ║               │
║   modulo Stop&Go                    ║◄──────────────┘
║   confronta CSV (UTC) con .pos (UTC)║
║   sulle finestre Stop→Go            ║
╚════════════════════╤════════════════╝
                     │
                     ▼
┌──────────────────────────────────────────┐
│  *_events_filtrato.csv                    │
│  *_events_media.csv  ← coordinate finali  │
└──────────────────────────────────────────┘

بيانات مأخوذة من جلسة ميدانية حقيقية بتاريخ 19/06/2025.

# Modalità: Stop&Go
Point,Timestamp,Action,Height
1A,2025/06/19 14:40:32.925,Stop,2.07
1A,2025/06/19 14:41:32.945,Go,2.07
2A,2025/06/19 14:43:12.162,Stop,2.07
2A,2025/06/19 14:43:14.008,Go,2.07

والوقت مكتوب بتوقيت UTC من ساعة الهاتف.

الحقل	القيمة
rcvTow	398 450,981 ثانية (منذ بداية أسبوع GPS)
week	2371
leapS	18
GPST المعاد بناؤه	2025-06-19T14:40:50.981
UTC بعد طرح leapS	2025-06-19T14:40:32.981

	UTC	GPST
الطابع الزمني من ملف CSV	14:40:32.925	—
الطابع الزمني المعاد بناؤه من UBX	14:40:32.981	14:40:50.981
الفارق بتوقيت UTC	+56 مللي ثانية
الفارق بتوقيت GPST		−18 056 مللي ثانية

الـ −18 ثانية هي تحديدًا الثواني الكبيسة، أما الـ −56 مللي ثانية فهي الانحراف الطفيف لساعة Android عن زمن GPS.

ينسّق pp2web ثلاث مراحل داخلية مستعملًا RTKLIB محركًا للحساب:

يُحوَّل ملف .ubx إلى رصدات RINEX. وفي هذه المرحلة يظل الزمن بمقياس GPS: فملف الرصد لم يُحوَّل إلى UTC بعد.

وهنا يجري التحويل الأساسي. فالإعداد الداخلي لـ pp2web يوجّه RTKLIB بالمعامل out-timesys = utc: يقرأ المحرك الثانية الكبيسة الواردة من جهاز الاستقبال وينتج ملف .pos بحقب بتوقيت UTC مباشرةً. ومن هذه اللحظة يصبح الزمن موحّدًا: المقياس نفسه المستعمل في ملف CSV للأحداث.

يأخذ pp2web نوافذ Stop → Go من ملف CSV، ويختار لكل نافذة من ملف .pos جميع الحقب التي تقع طوابعها الزمنية داخل الفترة. ثم يحسب على تلك الحقب المتوسط الموزون للإحداثيات (خط العرض وخط الطول والارتفاع) بأوزان مقلوب مربع الانحرافات المعيارية، ويطرح أخيرًا ارتفاع الجهاز للنقطة. وكلا التدفقين (CSV وحقب .pos) بتوقيت UTC أصلًا، فلا يُطبَّق أي تصحيح للثواني الكبيسة.

و«الحيلة» أن كل مكوّن في السلسلة يؤدي دوره مرة واحدة فقط:

1. rawX لا يعرف شيئًا عن GPS، بل يكتب التوقيت المدني UTC.
2. جهاز الاستقبال MS2 يكتب زمن GPS ويرفق الثانية الكبيسة.
3. pp2web (عبر RTKLIB) هو المكوّن الوحيد الذي يحوّل بين المقياسين، ويفعل ذلك مرة واحدة عند إنتاج ملف .pos.
4. أما مرحلة الدمج مع أحداث Stop&Go فتعمل بتوقيت UTC وحده، على تدفقين متوافقين أصلًا.

وبعبارة أخرى: مسؤولية التحويل بين GPST وUTC مركزة في pp2web، وتتوقف على سطر إعداد واحد (out-timesys = utc) مضبوط داخليًا.

العَرَض	السبب المحتمل	أين تبحث
نقاط ملف .pos لا تقع داخل نوافذ ملف CSV (فارق نحو 18 ثانية)	إعداد pp2web بمقياس زمني خاطئ	ملف إعداد معالجة PPK
استبعاد الوقفات برسالة «ثانيتان أو ثلاث على الأقل»	العد التنازلي في rawX قصير جدًا	ضبط العد التنازلي في التطبيق
الفارق بين CSV وUBX أكبر من ثانية بتوقيت UTC	ساعة Android غير متزامنة	إعدادات الهاتف ← التاريخ والوقت التلقائيان
جميع الحلول Q5 (نقطة منفردة)	ملف RINEX لمحطة الأساس لا يغطي الجلسة	التغطية الزمنية لمحطة الأساس

• الثواني الكبيسة الثماني عشرة لا تُطبَّق يدويًا: يتولاها pp2web عبر إعداده الداخلي (out-timesys = utc المُمرَّر إلى RTKLIB).
• ملف .csv من rawX بتوقيت UTC أصلًا (ساعة Android عبر NTP).
• وملف .pos الذي ينتجه pp2web يصبح بتوقيت UTC بعد التحويل الداخلي.
• والدمج النهائي لأحداث Stop&Go يقارن UTC بـ UTC: فلا خطر من عدم التطابق.
• ولا يبقى إلا انحراف ساعة الهاتف، وهو عادةً بضع عشرات من المللي ثانية — وهذا غير مؤثر في Stop&Go بوقفة لا تقل عن ثانيتين.

فيديوهات تعليمية

يعرض هذا القسم كيفية استعمال تطبيق الويب في فيديوهات تعليمية تشرح وظائفه المختلفة بالتفصيل والنتائج النهائية.

• مقدمة
• Single
• الساكن
• الحركي
• Stop&Go
• التحديث إلى الإصدار 1.1