رسم الخرائط بالطائرات المسيرة مع OpenDroneMap

في مقال كيف تعمل الخرائط الرقمية رأينا الإحداثيات والمربعات Tiles، وفي مقال خرائطك على سيرفرك عرضنا خريطة OpenStreetMap من سيرفرنا، وفي مقال سيارات المسح رأينا كيف تجمع الشركات صور الشوارع. ولكن كل ذلك يعتمد على بيانات جمعها غيرك، وصور الأقمار الصناعية المتاحة قد تكون قديمة أو بدقة لا ترى فيها حفرة في الطريق أو تشققاً في سقف. وهنا يأتي دور الطائرة المسيرة: تطير فوق المكان الذي تريده اليوم، وتلتقط عشرات الصور، ثم يحولها برنامج على سيرفرك إلى خريطة دقيقة ونموذج ارتفاعات وسحابة نقاط ثلاثية الأبعاد. وفي هذا المقال سوف نقوم بذلك على بيانات حقيقية مفتوحة، ونقيس كم تأخذ المعالجة على جهاز عادي.

وسوف نناقش في هذا المقال ما يلي:

• المسح التصويري Photogrammetry: كيف تصبح الصور المسطحة شكلاً ثلاثي الأبعاد.
• التداخل Overlap وحجم البكسل على الأرض GSD ونقاط التحكم الأرضية GCP، ولماذا تحدد دقة الخريطة قبل أن تقلع الطائرة.
• المخرجات: الصورة المصححة Orthophoto، ونموذج السطح DSM، ونموذج الأرض DTM، وسحابة النقاط Point Cloud.
• OpenDroneMap وWebODM ورخصتهما، والانفصال الأخير بينهما.
• تجربة عملية على 77 صورة مفتوحة الرخصة، بالوقت الحقيقي والمخرجات الحقيقية، ثم نحذف ثلثي الصور لنرى ماذا يحدث.
• مؤشر الغطاء النباتي NDVI والفحص، وما تحتاجه لهما.

كيف تصبح الصور خريطة؟

الفكرة نفسها التي تجعلك ترى العمق بعينين: كل نقطة في المكان تظهر في صورتين من موقعين مختلفين بإزاحة بسيطة، ومن الإزاحة نحسب بعدها. والبرنامج يفعل ذلك على نطاق واسع، فيبحث في كل صورة عن آلاف النقاط المميزة Features، مثل زاوية سقف أو حجر، ثم يطابق النقطة نفسها بين الصور، ومن هذه المطابقات يحسب في الوقت نفسه موقع الكاميرا واتجاهها لحظة كل صورة وموقع كل نقطة في الفراغ، وهذا يسمى البنية من الحركة Structure from Motion (واختصاراً SfM). بعد ذلك يكثف النقاط إلى سحابة نقاط كثيفة، ويبني منها سطحاً، ويلون السطح من الصور، ثم يسقطه من الأعلى ليعطيك الخريطة. والصورة التالية تبين المراحل:

وقد يتساءل البعض: لماذا لا نلصق الصور جنباً إلى جنب مثل صورة بانورامية ونكتفي بذلك؟ والإجابة أن الصورة من الأعلى ليست خريطة، فالمبنى العالي يظهر مائلاً إلى الخارج كلما ابتعد عن مركز الصورة، والأرض المرتفعة تبدو أقرب وأكبر من المنخفضة، وبالتالي المسافة في الصورة لا تساوي المسافة على الأرض. أما الصورة المصححة Orthophoto فهي صورة أزيلت منها هذه التشوهات بمعرفة شكل السطح، فيصبح لها مقياس ثابت في كل مكان، وتستطيع أن تقيس عليها المسافات والمساحات، وتضعها طبقة فوق خريطة كما في طبقات الخريطة.

التداخل وحجم البكسل على الأرض

كل نقطة يجب أن تظهر في عدة صور حتى يستطيع البرنامج أن يحسب مكانها، لذلك تطير الطائرة في خطوط متوازية وتلتقط الصور بحيث تشترك كل صورة مع التي بعدها ومع الصورة المجاورة في الخط التالي بجزء كبير، وهذا الجزء يسمى التداخل Overlap. وتوصي صفحة نصائح الطيران في OpenDroneMap للخرائط والنماذج ثنائية الأبعاد بتداخل بين 70 و80 بالمئة مع ميل خفيف للكاميرا من 5 إلى 10 درجات عن الوضع العمودي، وبقرابة 80 إلى 83 بالمئة للمباني والنباتات المعقدة.

أما حجم البكسل على الأرض Ground Sampling Distance (واختصاراً GSD) فهو المسافة على الأرض التي يغطيها بكسل واحد من الصورة، فإذا كان GSD يساوي 2 سم فأصغر شيء تستطيع أن تميزه في الخريطة في حدود بضعة سنتيمترات. وهو يتحدد بالكاميرا والارتفاع، فكلما ارتفعت الطائرة غطت الصورة مساحة أكبر وكبر GSD وقلت التفاصيل، وتقول صفحة الدقة في OpenDroneMap إن الارتفاع الأعلى يعني بصمة صورة أكبر وGSD أكبر ودقة أقل. والصورة التالية تبين الفكرتين:

الدقة النسبية والمطلقة، ونقاط التحكم الأرضية

هناك نوعان من الدقة يجب أن تفرق بينهما، وتعرفهما صفحة الدقة: الدقة النسبية Relative Accuracy وهي مدى تطابق المسافات بين النقاط في الخريطة مع المسافات الحقيقية، والدقة المطلقة Absolute Accuracy وهي مدى تطابق موقع الخريطة كلها مع موقعها الحقيقي على الأرض. وقد تكون الخريطة دقيقة في الشكل والمقاسات ولكنها مزاحة عدة أمتار عن مكانها. وتقول الصفحة نفسها إن الدقة النسبية المتوقعة من 1 إلى 3 أضعاف متوسط GSD، أما المطلقة فتعتمد على GPS الطائرة، والأفقية في GPS العادي عادة بين 2 و6 أمتار والرأسية من 3 إلى 4 أضعافها، ومع نقاط التحكم الأرضية يمكن أن تتحسن إلى 2.5 ضعف GSD أفقياً و4 أضعافه رأسياً.

ونقطة التحكم الأرضية Ground Control Point (واختصاراً GCP) هي بحسب توثيق OpenDroneMap موقع مقاس على الأرض، عادة بجهاز GPS عالي الدقة، تضعه على علامة ظاهرة في الصور، فيستخدمها البرنامج لتصحيح التشوه وربط الخريطة بنظام إحداثيات معروف. ويوصي التوثيق بأن تكون 5 نقاط على الأقل لأغلب المشاريع، و8 إلى 10 للمشاريع الكبيرة، موزعة أفقياً وبين المرتفع والمنخفض، وبحيث تظهر كل نقطة في 5 صور على الأقل. ومتى تحتاجها؟ تقول الصفحة إن متابعة تقدم مشروع بناء أو قياس مساحة حريق لا تحتاج GCP لأن الموقع المطلق لا يغير القرار، أما مطابقة المشروع للمخططات أو مسح حدود الأراضي فتحتاج دقة مطلقة عالية. وأجهزة GNSS بتصحيح RTK التي شرحناها في مقال سيارات المسح هي ما يقيس به المساحون هذه النقاط.

المخرجات: Orthophoto وDSM وDTM وسحابة النقاط

• الصورة المصححة Orthophoto: ملف GeoTIFF، أي صورة معها إحداثياتها، تفتحه في QGIS أو تحوله إلى مربعات لخريطة ويب.
• سحابة النقاط Point Cloud: ملايين النقاط لكل منها موقع ولون، بصيغة LAZ أو PLY، ومنها تقيس الأحجام مثل كومة رمل أو حفرة.
• النموذج ثلاثي الأبعاد Textured Model: سطح ملون من الصور بصيغة OBJ.
• نموذج السطح DSM ونموذج الأرض DTM: صورتان كل بكسل فيهما ارتفاع، والفرق بينهما في الصورة التالية.

وبحسب صفحة المخرجات فإن DSM هو نموذج «قمم كل شيء» وDTM هو «الأرض»، ولا ينتجهما ODM إلا إذا طلبتهما بالخيارين --dsm و--dtm. ولاحظ أن DTM يحتاج أن يعرف البرنامج أي النقاط أرض وأيها مبان وأشجار، ولذلك يشغل ODM تصنيف النقاط تلقائياً عند طلب DTM، كما سوف ترى في أول سطر من مخرج التجربة.

OpenDroneMap وWebODM: من هو من؟

OpenDroneMap (واختصاراً ODM) برنامج سطر أوامر مفتوح المصدر يأخذ مجلد صور ويخرج كل ما سبق، ورخصته بحسب مستودعه هي AGPL-3.0، وآخر إصدار وقت الكتابة هو v3.6.2 الصادر في أغسطس 2026، ويوزع كـ Docker Image باسم opendronemap/odm. أما WebODM فهو واجهة ويب لإدارة المشاريع ورفع الصور وعرض النتائج، وكان لسنوات جزءاً من مشروع OpenDroneMap، ولكن في 6 أبريل 2026 أعلن مطوره في إعلان الانفصال أن WebODM انفصل رسمياً عن OpenDroneMap، وانتقل مستودعه إلى منظمة WebODM برخصة AGPL-3.0، ويقول ملف README فيه إنه لا يتبع OpenDroneMap ولا يستخدم ODM للمعالجة، وإنما ODX وهو فرع Fork من ODM. وبالتالي إذا قرأت دليلاً قديماً يقول إن WebODM هو واجهة ODM فاعلم أن هذا تغير، وفي التجربة نستخدم ODM مباشرة من سطر الأوامر، لأنه الأداة نفسها التي تعالج الصور، والنتائج تفتح في أي برنامج GIS.

التجربة العملية: 77 صورة تصبح خريطة

سوف نستخدم مجموعة صور odm_data_aukerman التي ينشرها مشروع OpenDroneMap، وهي 77 صورة جوية لحديقة عامة في ولاية أوهايو الأمريكية، ورخصتها CC0 1.0، أي أنها في الملك العام وتستطيع استخدامها دون شروط، وتاريخ التقاطها بحسب تقرير ODM هو 29 يونيو 2016. والجهاز الذي نعالج عليه حاسوب عادي فيه Docker Desktop على Windows، أعطيناه 8 أنوية و31 جيجابايت ذاكرة، وحددنا للمعالجة 6 أنوية بالخيار --max-concurrency، والصور في مجلد على قرص Windows نفسه.

تشغيل المعالجة

الأوامر التالية تنزل الصور وتشغل ODM 3.6.2 عليها مع طلب DSM وDTM:

mkdir -p datasets/aukerman
curl -L -o aukerman.zip https://github.com/OpenDroneMap/odm_data_aukerman/archive/refs/heads/master.zip
unzip -q aukerman.zip && mv odm_data_aukerman-master/images datasets/aukerman/
ls datasets/aukerman/images | wc -l

docker run -d --name lab-drone-odm -v "$PWD/datasets:/datasets" opendronemap/odm:3.6.2 \
  --project-path /datasets aukerman --dsm --dtm --max-concurrency 6
docker logs -f lab-drone-odm

والمخرج سوف يكون كما يلي (مختصراً على الأسطر المهمة):

77
[INFO]    DTM is turned on, automatically turning on point cloud classification
[INFO]    Initializing ODM 3.6.2 - Sun Oct 11 21:05:30  2026
...
[INFO]    Running opensfm stage
[INFO]    Finished opensfm stage
[INFO]    Running openmvs stage
[INFO]    Finished openmvs stage
...
[INFO]    Running odm_orthophoto stage
[INFO]    Finished odm_orthophoto stage
[INFO]    Running odm_report stage
[INFO]    Finished odm_report stage
[INFO]    ODM app finished - Sun Oct 11 23:53:10  2026

في المخرج أعلاه لاحظ التالي:

• السطر الأول بعد عدد الصور يؤكد ما قلناه عن DTM: طلبه شغل تصنيف النقاط تلقائياً.
• المعالجة كلها أخذت ساعتين و47 دقيقة على هذا الجهاز، وODM يكتب زمن كل مرحلة في ملف benchmark.txt داخل مجلد المشروع.

cat datasets/aukerman/benchmark.txt

dataset runtime: 198.456355 seconds
split runtime: 0.037921 seconds
merge runtime: 9.4e-05 seconds
opensfm runtime: 3477.658431 seconds
openmvs runtime: 4652.788321 seconds
odm_filterpoints runtime: 60.877544 seconds
odm_meshing runtime: 653.081567 seconds
mvs_texturing runtime: 798.172206 seconds
odm_georeferencing runtime: 89.186904 seconds
odm_dem runtime: 77.478732 seconds
odm_orthophoto runtime: 23.033071 seconds
odm_report runtime: 29.122196 seconds
odm_postprocess runtime: 0.000115 seconds

ولاحظ أن مرحلتين فقط أخذتا قرابة 80 بالمئة من الوقت: OpenSfM، وهي مطابقة النقاط وحساب مواقع الكاميرا، بنحو 58 دقيقة، وOpenMVS، وهي تكثيف سحابة النقاط من خرائط العمق، بنحو 78 دقيقة. وجزء من هذا البطء سببه الجهاز نفسه، فالبيانات في مجلد على قرص Windows يصل إليه Docker عبر طبقة مشاركة الملفات، والمعالجة كتبت قرابة 7.9 جيجابايت في مجلد المشروع، لذلك على سيرفر Linux بقرص محلي سريع سوف يكون الوقت أقل، والأرقام هنا للتوضيح وليست مقياس أداء.

ماذا خرج من المعالجة؟

ODM يكتب ملخصاً في odm_report/stats.json وتقريراً بصيغة PDF، وهذه أهم القيم من الملف كما قرأناها منه:

reconstruction_statistics: initial_shots_count 77, reconstructed_shots_count 77,
                           reconstructed_points_count 58022, components 1, has_gcp false
processing_statistics:     area 46467.26, Feature Extraction 1117.5 s, Reconstruction 732.7 s
point_cloud_statistics:    count 15902818, file odm_georeferenced_model.laz (79 MB)
odm_processing_statistics: total_time_human "2.0h:47.0m:18.0s", average_gsd 2.736

والقيم تقول إن الصور السبع والسبعين كلها دخلت في نموذج واحد، وإن المساحة المغطاة قرابة 46 ألف متر مربع، وإن سحابة النقاط الكثيفة فيها قرابة 15.9 مليون نقطة، وإن متوسط GSD هو 2.74 سم، أي أن كل بكسل في الصور يغطي قرابة 2.7 سم على الأرض. ثم نفحص الصورة المصححة ونموذجي الارتفاع بأداة gdalinfo الموجودة داخل Docker Image نفسها:

docker run --rm --name lab-drone-gdal -v "$PWD/datasets:/datasets" --entrypoint bash opendronemap/odm:3.6.2 -c '
export PATH=/code/SuperBuild/install/bin:$PATH; cd /datasets/aukerman
gdalinfo odm_orthophoto/odm_orthophoto.tif | grep -E "Size is|Pixel Size|ID\[\"EPSG\",326"
for f in dsm dtm; do gdalinfo -stats odm_dem/$f.tif | grep "Minimum="; done'

Size is 7419, 5959
    ID["EPSG",32617]]
Pixel Size = (0.049998679820509,-0.049993638835852)
  Minimum=214.961, Maximum=272.659, Mean=244.902, StdDev=8.319
  Minimum=214.939, Maximum=264.291, Mean=240.936, StdDev=5.614

في المخرج أعلاه لاحظ التالي:

• الصورة المصححة 7419 × 5959 بكسل، وكل بكسل فيها 5 سم وليس 2.74 سم، والسبب أن الخيار --orthophoto-resolution قيمته في هذا التشغيل 5 سم لكل بكسل كما في ملف options.json الذي كتبه ODM، فإذا أردت دقة أعلى فاطلبها بنفسك وتحمل حجم الملف ووقت المعالجة.
• الإحداثيات بنظام UTM المنطقة 17 شمالاً (EPSG:32617)، وهو الإسقاط المناسب لهذا المكان، والإسقاط نفسه شرحناه في مقال الخرائط الرقمية.
• السطر الأول للإحصاءات هو DSM والثاني DTM: أعلى نقطة في DSM على ارتفاع 272.7 متراً وفي DTM على 264.3 متراً، والفرق قمم الأشجار التي أزالها DTM، ومتوسط DSM أعلى من متوسط DTM بقرابة 4 أمتار للسبب نفسه.

والصورة التالية هي الصورة المصححة نفسها مصغرة، والمناطق السوداء خارج حدود ما صورته الطائرة:

وحتى ترى الفرق بين DSM وDTM على البيانات نفسها رسمنا التظليل Hillshade لكل منهما بأداة gdaldem hillshade:

ولاحظ في DTM الخطوط والزوايا المستقيمة في مكان الغابة الكثيفة، والسبب أن الكاميرا لا ترى الأرض تحت الأشجار الكثيفة أصلاً، فلا توجد نقاط أرض هناك، فيملأ البرنامج الفراغ من الأطراف، وبالتالي الأرض تحت الغابة في DTM تقدير وليست قياساً. وهذا من الفروق بين التصوير والليزر LiDAR الذي شرحناه في مقال سيارات المسح.

نكسر الإعداد: ثلث الصور فقط

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

mkdir -p datasets/aukerman-third/images
ls datasets/aukerman/images | awk 'NR % 3 == 1' | while read f; do cp "datasets/aukerman/images/$f" datasets/aukerman-third/images/; done
ls datasets/aukerman-third/images | wc -l

docker run -d --name lab-drone-odm-third -v "$PWD/datasets:/datasets" opendronemap/odm:3.6.2 \
  --project-path /datasets aukerman-third --dsm --dtm --max-concurrency 4

والمخرج من عدد الصور ثم من تقرير الجودة odm_report/report.pdf للتشغيلين سوف يكون كما يلي:

26

                                   77 photos           26 photos
Reconstructed Images               77 over 77 (100%)   26 over 26 (100%)
Reconstructed Points (Sparse)      58022               19066
Reconstructed Points (Dense)       15,902,818          4,279,766
Average GSD                        2.7 cm              2.7 cm
GPS errors                         0.85 meters         1.05 meters
Area Covered                       0.046467 km²        0.046010 km²

وهنا نتيجة لم نتوقعها: ODM لم يفشل، فكل الصور الست والعشرين دخلت في النموذج، والمساحة المغطاة تقريباً نفسها. والسبب أن هذه البيانات صورت بتداخل أعلى بكثير مما تحتاجه الخريطة، فبقي بعد حذف الثلثين تداخل كاف لمطابقة النقاط. ولكن لاحظ الثمن: سحابة النقاط الكثيفة نقصت من 15.9 مليون نقطة إلى 4.3 مليون، أي بنحو 73 بالمئة، لأن كل نقطة على الأرض أصبحت تظهر في صور أقل، والنموذج ثلاثي الأبعاد والقياسات منه تعتمد على هذه الكثافة. والصورة التالية تبين المنطقة نفسها من الصورتين المصححتين بالدقة الكاملة:

والدرس من ذلك أن الصورة المصححة تتحمل نقص التداخل أكثر من النموذج ثلاثي الأبعاد، ولكنك لا تعرف مقدار التداخل الكافي لمكانك إلا بعد المعالجة، وعندها تكون الطائرة قد عادت والطيار قد غادر الموقع، لذلك خطط بالتداخل الذي توصي به OpenDroneMap ولا تنقص منه. ولاحظ أننا شغلنا هذه المعالجة بأربعة أنوية وبينما كانت تجربة أخرى تعمل على الجهاز نفسه، فأخذت ساعة و45 دقيقة بحسب التقرير، وهذا الرقم لا يصلح للمقارنة مع التشغيل الأول.

تنظيف المختبر

docker rm lab-drone-odm lab-drone-odm-third
rm -rf datasets

الأمر الأول يحذف ال Containers التي أنشأناها بالاسم فقط، والثاني يحذف الصور والمخرجات، فانسخ ما تحتاجه منها قبله.

مؤشر الغطاء النباتي NDVI والفحص

النبات السليم يعكس الأشعة تحت الحمراء القريبة Near Infrared بقوة ويمتص الأحمر، والنبات المريض أو الجاف يعكس أقل، ومن هنا جاء مؤشر الغطاء النباتي Normalized Difference Vegetation Index (واختصاراً NDVI)، وتعرفه هيئة المساحة الجيولوجية الأمريكية USGS بأنه يقيس اخضرار النبات ويفيد في فهم كثافته وتقييم التغير في صحته، ويحسب هكذا:

NDVI = (NIR - Red) / (NIR + Red)

والقيمة بين سالب واحد وواحد، وكلما اقتربت من الواحد كان النبات أكثف وأصح، وتشرح ناسا NASA الفكرة نفسها من صور الأقمار الصناعية. ولاحظ أن الكاميرا العادية لا تلتقط الأشعة تحت الحمراء القريبة، فصور التجربة لا تصلح لحساب NDVI، وتحتاج كاميرا متعددة الأطياف Multispectral، ويقول توثيق OpenDroneMap إنه يدعم منذ الإصدار 0.9.9 التطبيع الإشعاعي Radiometric Normalization لإنتاج صور انعكاس من هذه الكاميرات، ومنها تحسب NDVI لكل بكسل. وتطبيقه العملي أن ترى في المزرعة البقع التي ضعف فيها النبات قبل أن تراها العين، فترسل الماء أو السماد إليها وحدها.

أما الفحص Inspection فلا يحتاج خريطة دائماً، فطائرة تقف أمام برج اتصالات أو لوح شمسي وتلتقط صوراً قريبة تكفي في الغالب، ولكن النموذج ثلاثي الأبعاد مفيد عندما تريد أن تقيس شيئاً، مثل ميل جدار أو حجم كومة، أو أن تقارن المكان نفسه بين شهرين، ومع صور حرارية Thermal يظهر اللوح الشمسي المعطل أسخن من جيرانه.

قبل أن تطير للمسح

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

أخطاء شائعة

• تداخل قليل لتوفير البطارية: رأيت في التجربة أن ثلث الصور أنقص سحابة النقاط بنحو 73 بالمئة، والأفضل أن تقلل المساحة في الطيران الواحد على أن تقلل التداخل.
• الطيران عالياً للانتهاء أسرع: GSD يكبر مع الارتفاع، وما لم تصوره بالتفاصيل لن يخرجه البرنامج.
• الوثوق بالموقع المطلق دون GCP: المقاسات النسبية جيدة، ولكن الخريطة قد تكون مزاحة أمتاراً عن مكانها الحقيقي.
• معالجة البيانات على قرص بطيء أو مجلد مشترك: المعالجة تكتب وتقرأ عشرات الجيجابايتات، فضعها على قرص محلي سريع.
• NDVI من كاميرا عادية: بدون قناة الأشعة تحت الحمراء القريبة لا يوجد NDVI حقيقي.

تدريب عملي

1. أعد تجربة الكسر بصورة من كل ست صور بدل كل ثلاث، ولاحظ في التقرير كم صورة دخلت في النموذج.
2. أعد المعالجة بالخيار --fast-orthophoto وقارن الوقت وشكل الصورة المصححة بالنتيجة الكاملة.
3. افتح odm_orthophoto.tif وdsm.tif في QGIS، وقس طول ملعب أو طريق في الصورة وقارنه بالخريطة الحقيقية.

الخلاصة

• المسح التصويري يحسب شكل المكان ومواقع الكاميرا معاً من نقاط مشتركة بين الصور، لذلك التداخل شرط وليس رفاهية.
• GSD يحدد أصغر تفصيل في الخريطة، ويتحدد بالكاميرا والارتفاع قبل أن تقلع الطائرة.
• الدقة النسبية تأتي من الصور، والمطلقة تحتاج GPS دقيقاً أو نقاط تحكم أرضية.
• DSM يتبع قمم كل شيء وDTM يتبع الأرض، والفرق بينهما ارتفاع المباني والأشجار.
• ODM برخصة AGPL-3.0، وWebODM انفصل عنه في أبريل 2026 ويعالج بـ ODX.
• NDVI يحتاج كاميرا متعددة الأطياف، والكاميرا العادية لا تكفي.

دليلالطائرات المسيرة للمبتدئين: كيف تطير ومم تتكونكيف تقف الطائرة المسيرة في الهواء وتميل وتدور بتغيير سرعة محركاتها فقط، ومم تتكون، وأي نوع يناسب أي عمل.دليلأنظمة الطائرات المسيرة في السعودية قبل أن تطيرما الذي تطلبه هيئة الطيران المدني قبل أن تطير بطائرة مسيرة في السعودية، من التسجيل والشهادة إلى المناطق الممنوعة والتصوير.دليلكيف تعمل الخرائط الرقمية؟ الإحداثيات والمربعات Tilesكيف تتحول خطوط العرض والطول إلى مربعات يرسمها المتصفح، ولماذا تبدو جرينلاند بحجم قارة، وكيف تحسب المسافة بين مدينتين بشكل صحيح.دليلخرائطك على سيرفرك مع OpenStreetMap وMapLibreكيف تعرض خريطة تفاعلية لمدينتك من سيرفرك ببيانات OpenStreetMap، بالعربية والإنجليزية ودون مفتاح API أو مزود خارجي.دليلسيارات مسح الخرائط: ماذا تجمع وأي عتاد تحمل؟ما الذي تسجله السيارات التي تجوب الشوارع بالكاميرات والليزر، وكيف تتحول صورها وقياساتها إلى عناوين وخرائط على هاتفك.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، والتجربة على OpenDroneMap 3.6.2 (opendronemap/odm:3.6.2) مع بيانات odm_data_aukerman برخصة CC0 في Docker Engine 29.8.0، والمعلومات من توثيق OpenDroneMap وإعلان WebODM وصفحات USGS وNASA كما قرأناها في 11 أكتوبر 2026.