أكثر

حساب الغطاء الشجري على مساحة معينة من البيانات النقطية

حساب الغطاء الشجري على مساحة معينة من البيانات النقطية


في العام الماضي Hansen et al. خريطة Global Forest Change المنشورة كمجموعة من البيانات النقطية المتاحة بتنسيق TIFF. هذه صور الأقمار الصناعية بدقة 30 مترًا بقيم بكسل تتراوح من 0 (بدون غابة) إلى 100 (غابة كاملة).

أود أن أحسب برمجيًا مساحة الغطاء الشجري على بلد معين له حدوده الموصوفة بواسطة ملف الشكل. منذ أن بدأت للتو مع GIS ، هل يمكنك أن تكون لطيفًا وتنصحني من أين أبدأ؟ ما هي المكتبات المتاحة التي يمكن أن تساعدني؟

أعتقد أن مشكلتي ليست جديدة على الإطلاق ، ولكن مع معرفتي المحدودة لم أتمكن من العثور على الموارد المناسبة (أو التعرف عليها على هذا النحو). أفضّل أن يكون C ++ أو Python ، نظرًا لأن هذا الأخير يحتوي على بعض المكتبات عالية الأداء.

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


ما تحاول القيام به ، يسميه موظفو نظم المعلومات الجغرافية "إحصائيات المنطقة". هناك العديد من الطرق للقيام بذلك ، إما في Desktop Gis أو "scriptwise".

فيQGISهناك توصيل يسمىإحصائيات المنطقةhttps://docs.qgis.org/2.6/en/docs/user_manual/plugins/plugins_zonal_statistics.html التي تجدها في Rastermethods.

كما ذكرت أنك إما تريد أن تفعل ذلك فيC ++أوبايثون، أوصي بهذا الأخير.بايثونلديها بعض المكتبات الجغرافية القوية جدًا. الشخص الذي تبحث عنه يسمىنقطية. https://github.com/perrygeo/python-rasterstats و / أو http://pythonhosted.org/rasterstats/. في صفحة github (كما هو موضح أعلاه) يمكنك أن ترى أن ما تحاول القيام به سهل للغاية.

من rasterstats import zonal_stats stats = zonal_stats ("country_shapefile.shp"، "forestcover.tif") stats [1] .keys ()> ['count'، 'min'، 'max'، 'mean'] [f [' يعني '] لـ f في الإحصائيات]> [756.6057470703125، 114.660084635416666]

إذا كنت ترغب في استخدام لغة برمجة ، فيمكنك استخدام GDAL المتاح لكل من Python و C ++.


بعد تجربة بعض الخيارات ، تبين أن الأفضل حتى الآن هو استخدام Google Earth Engine ، منصة الحوسبة السحابية للحسابات الجغرافية المكانية. إنها حاليًا نسخة تجريبية ، بدون اتفاقية مستوى خدمة (SLA) ، ولكنها متاحة أيضًا مجانًا. هذا هو بالضبط المكان الذي تم فيه إنتاج خريطة Global Forest Change.

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

في بحثنا قمنا بحساب مساحة الغابات لخرائط التوزيع لما يقرب من 12000 نوع ، تغطي معًا ما يقرب من 1000 مليون كيلومتر مربع. إليك الشفرة الكاملة مع رابط المقالة التي نشرناها.


إنشاء نقطية بقيم PatchStat من SDMTools في R.

لدي ملف نقطي للغطاء الأرضي الذي قمت بتقليصه لاحتواء خلايا الغطاء الشجري فقط. لقد استخدمت الكتلة في الحزمة النقطية لتجميع () المناطق المتجاورة من الغابة. هذا يعطي كل الخلايا التي تلامس بعضها البعض نفس المعرف لأنها جزء من نفس التصحيح.
ثم أرغب في معرفة PatchStat () لكل كتلة ، وهو ما أفعله عن طريق تحويل البيانات النقطية المتكتلة إلى مصفوفة as.matrix. حاولت الحصول على PatchStat () للقيام بذلك إلى البيانات النقطية لكنها لن تعمل إلا إذا كانت في مصفوفة.

أريد الآن عمل نقطي بإخراج إحصائيات التصحيح ، أي "perim.area.ratio". لذا ، ستحصل كل خلية تتوافق مع الكتلة 1 على القيمة perim.area.ratio التي تتوافق مع الكتلة 1. للقيام بذلك ، صنعت data.frame () من البيانات النقطية المتكتلة التي تحتوي على: lon ، lat ، layer (clumpID) ، cellID.
حاولت دمج data.frame النقطية المتكتلة الخاصة بي مع إخراج PatchStat باستخدام طبقة و تصحيح. ومع ذلك ، يحدث خطأ:

خطأ في fix.by (by.x، x): يجب أن يحدد "بواسطة" عمود (أعمدة) صالح.

هل من أفكار حول كيفية القيام بذلك بطريقة أخرى ، أو لماذا هذه الأعمدة غير صالحة؟ الرمز أدناه.


نظرة عامة على مجموعة البيانات

المحققون: العدل ، د. ديلي ، وف. روبين.

وصف:

تصنف مجموعة بيانات الغطاء الأرضي لنيو هامبشاير GRANIT الغطاء الأرضي واستخدام الأراضي إلى 23 فئة ، تعتمد إلى حد كبير على تصنيف 12 صورة من صور Landsat Thematic Mapper (TM). تم التركيز بشكل خاص على تقديم أكبر قدر ممكن من التفاصيل في فصول الغابات والزراعة. تم إنجاز التصنيفات الخاصة بالفئة من خلال سلسلة من مجموعات الصور الفرعية والأقنعة وتكرارات التصنيف لبيانات ذاكرة الترجمة لإنتاج المنتج النهائي.

شكر (ق): تم نشر مجموعة البيانات هذه في الأصل بواسطة EOS-WEBSTER ، وهي مكتبة رقمية لبيانات علوم الأرض وشريك معلومات علوم الأرض ، لموقع EOS-EarthData في جامعة نيو هامبشاير ، دورهام ، نيو هامبشاير. تم تقديم بيانات المصدر إلى EOS-WEBSTER بواسطة NH GRANIT ، مركز أبحاث الأنظمة المعقدة ، معهد دراسة الأرض والمحيطات والفضاء ، جامعة نيو هامبشاير. تم نقل العديد من منتجات بيانات EOS-WEBSTER إلى ORNL DAAC للأرشفة الدائمة.


اكتشاف الاحتمالية / الاحتمال

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

الجمع بين أقصى مسافة اكتشاف واحتمالية الاشتعال


2 إجابات 2

لتقسيم عقدة إلى عقدتين فرعيتين مختلفتين ، تتكون إحدى الطرق من تقسيم العقدة وفقًا للمتغير الذي يمكنه زيادة اكتساب المعلومات إلى أقصى حد. عندما تصل إلى عقدة ورقية خالصة ، فإن كسب المعلومات يساوي 0 (لأنه لا يمكنك الحصول على أي معلومات بتقسيم عقدة تحتوي على متغير واحد فقط - المنطق).

في المثال الخاص بك Entropy (S) = 1.571 هو الانتروبيا الحالية - تلك التي لديك قبل الانقسام. دعنا نسميها HBase. ثم تقوم بحساب الانتروبيا اعتمادًا على العديد من المعلمات القابلة للتقسيم. للحصول على مكاسب المعلومات الخاصة بك ، يمكنك استبدال إنتروبيا العقد التابعة لك بـ HBase -> كسب = Hbase - child1NumRows / numOfRows * entropyChild1 - child2NumRows / numOfRows * entropyChild2


3.5 الارتفاع

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

أماتولي وآخرون. (2018) مجموعة من المتغيرات الطبوغرافية العالمية بدقة 1 كم المصممة للاستخدام في نمذجة التوزيع. تتوفر مجموعة من المتغيرات ، بما في ذلك الارتفاع والمنحدر والخشونة والعديد من المتغيرات الأخرى التي سنركز عليها هنا ، ولكن يمكن تطبيق النهج بسهولة على متغيرات أخرى. للبدء ، قم بزيارة موقع الويب للحصول على هذه البيانات ، وقم بتنزيل منتج الارتفاع المتوسط ​​بدقة 1 كم ، واحفظ الملف (elevation_1KMmd_GMTEDmd.tif) في البيانات / الدليل الفرعي لمشروعك:

بعد ذلك ، سنقوم بتحميل الملف ، ونقصه من النطاق العالمي الكامل إلى الجزء الذي نحتاجه فقط لـ BCR 27 ، ونعيد إسقاطه إلى الإسقاط الجيبي MODIS.

نقوم الآن باستخراج قيم الارتفاع داخل المنطقة المجاورة لكل موقع من مواقع قائمة التحقق تمامًا كما فعلنا من قبل لبيانات الغطاء الأرضي. ثم سنقوم بحساب الوسيط والانحراف المعياري للارتفاع داخل كل حي.

سنحتاج إلى تكرار هذه العملية لحساب متغيرات الارتفاع لسطح التنبؤ.

أخيرًا ، سنجمع بين متغيرات الارتفاع هذه والمتغيرات المشتركة للغطاء الأرضي.

هذا يكمل إعداد البيانات. ستركز الفصول التالية على استخدام هذه البيانات لنمذجة توزيعات الأنواع.


استنتاج

في هذه الدراسة ، للأعوام 2000 و 2006 و 2012 ، توزيع فئات الغطاء الأرضي بناءً على مجموعة بيانات الغطاء الأرضي CORINE ، وتأثيراتها على GPP و NPP ممثلة في إجمالي GPP السنوي وإجمالي NPP السنوي ، والتنفس و تم تحليل نسبة NPP / GPP بناءً على تصنيف الغطاء الأرضي CORINE ، وتم تحليل النقاط الساخنة والبقع الباردة للتنفس ونسب NPP / GPP في شليسفيغ هولشتاين. أظهرت النتائج التي تعرض توزيعات الغطاء الأرضي في شليسفيغ هولشتاين أن "الأراضي الصالحة للزراعة غير المروية" و "المراعي" و "أنماط الزراعة المعقدة" كانت فئات الغطاء الأرضي السائدة لعامي 2000 و 2006. "الأراضي الصالحة للزراعة غير المروية" احتلت "المراعي" و "النسيج الحضري غير المستمر" مساحة أكبر بكثير من فئات الغطاء الأرضي الأخرى في عام 2012. كانت "المراعي" و "الأراضي الصالحة للزراعة غير المروية" أكثر فئات الغطاء الأرضي انتشارًا في شليسفيغ هولشتاين.

يشير إجمالي GPP و NPP السنوي ، إجمالي GPP و NPP المخزن سنويًا والنقاط الساخنة والبقع الباردة لإجمالي GPP و NPP السنوي إلى قدرة مخزونات الكربون في Schleswig-Holstein. شكلت النقاط الساخنة والبقع الباردة من إجمالي GPP و NPP مناطق مهمة مجاورة ذات إجمالي سنوي إجمالي GPP و NPP ، وتقع من وسط غرب إلى المناطق الجنوبية الوسطى من شليسفيغ هولشتاين. كانت مناطق البقع الباردة ذات إجمالي الإنتاج السنوي المنخفض GPP و NPP تقع في المقام الأول على الحافة الغربية والجزء الشرقي من الولاية. كان معدل التنفس المحسوب في عام 2006 أعلى منه في عامي 2000 و 2012 ، وكان عام 2000 هو أقل معدل تنفس بين السنوات الثلاث. كان متوسط ​​النسب السنوية لصافي الطاقة الإنتاجية / الإنتاج المحلي الإجمالي 0.5647 و 0.5350 و 0.5573 في أعوام 2000 و 2006 و 2012 على التوالي.


نتائج

حالة الغطاء الشجري الإقليمي.

كان الغطاء الشجري 18٪ عبر منطقة الدراسة ، وتراوح من 49٪ إلى 3٪ في مزارعنا (الوسيط ، 12٪ الشكل S1). ما يقرب من ثلاثة أرباع منطقة الدراسة بها غطاء شجري ≤30٪ ، وثلثيها 10٪ غطاء شجري (محسوب ضمن نافذة متحركة دائرية مساحتها 2 هكتار الشكل 1).أ). كان الغطاء الشجري الذي تم استشعاره عن بعد ضمن دائرة مساحتها 2 هكتار حول كل موقع من مواقع المسح البالغ عددها 126 مرتبطًا بشكل كبير بعدد الأشجار داخل الموقع (ص & lt 0.001 ص 2 = 0.81 شكل 1ب والجدول S1). كانت هذه العلاقة مهمة سواء تم تضمين مواقع التحقق أم لا ، مما يشير إلى أنها كانت قوية. استنادًا إلى العلاقة بين النسبة المئوية للغطاء الشجري وعدد الأشجار في منطقة مساحتها 2 هكتار ، قدرنا عبر منطقة الدراسة عدد الأشجار الموجودة على مستويات مختلفة من الغطاء الشجري (الشكل 1).ج). حدث ما يقرب من 3 ملايين شجرة بكثافة 30٪ ، ووقع 1.5 مليون شجرة بكثافة 10٪ لكل 2 هكتار (الشكل 1).ج).

غطاء شجرة على مستوى المناظر الطبيعية لمنطقة الدراسة ، استنادًا إلى نافذة متحركة مساحتها هكتاران لحساب النسبة المئوية للغطاء الشجري من البيانات المستشعرة عن بُعد وفي 126 موقعًا للمسح الميداني. لاحظ أن بعض الأجزاء كثيفة الأشجار في منطقة الدراسة كانت أراضٍ عامة. (أ) النسبة التراكمية لمنطقة الدراسة التي تحدث على مستويات مختلفة من الغطاء الشجري داخل نافذة متحركة بمساحة 2 هكتار (على سبيل المثال ، 75٪ من منطقة الدراسة بها غطاء شجري 30٪). (ب) نسبة الغطاء الشجري من الاستشعار عن بعد مقابل عدد الأشجار المقاسة في المواقع الأرضية (ص 2 = 0.81 ص & lt 0.001). الدوائر تشير إلى مواقع المسح الأولية ، والعلامات المتقاطعة تشير إلى مواقع التحقق من الصحة. الخط المتقطع هو 95٪ فاصل الثقة للعلاقة المتوقعة. (ج) مرتكز على أ و ب، العدد المتوقع للأشجار التي تحدث بكثافات مختلفة في منطقة الدراسة (على سبيل المثال ، 3 مليون شجرة حدثت بكثافة 30٪).

تم توحيد أقطار جميع أنواع الأشجار ، بحيث يمكن مقارنة المواقع ذات الأنواع المختلفة (انظر طرق SI). تباينت توزيعات قطر الشجرة بشكل منهجي عبر المواقع ذات الكثافة الشجرية المختلفة (الشكل 2). في مواقع الرعي ومواقع الأشجار المتناثرة ، كان متوسط ​​أقطار الأشجار أعلى. في كلا نوعي الموقع ، كان متوسط ​​قطر الشجرة مساويًا تقريبًا لمتوسط ​​القطر ، مما يشير إلى انتشار متماثل للأقطار (الشكل 2). تم العثور على أقطار متوسطة ومتوسطة أصغر في غابات الرعي ، وأكثر من ذلك في الغابات غير المرعى بها. كانت توزيعات القطر في هذه المواقع منحرفة لليمين ، بمتوسط ​​أقطار أصغر من الأقطار المتوسطة (الشكل 2).

متوسط ​​عدد الأشجار (والخطأ المعياري) في فئات القطر المختلفة عبر أنواع المواقع الأربعة [paddock (أ)، مبعثر (ب) مرعى (ج) ، وغير مرعى (د)] ، بغض النظر عن نظام المزرعة أو الرعي. يشار إلى متوسط ​​القطر التقريبي لجميع الأشجار ، في جميع المزارع وأنظمة الرعي ، في نوع موقع معين بخط أحمر منقط ، يُشار إلى القطر المتوسط ​​التقريبي بخط أخضر متصل. تم توحيد الأقطار قبل التحليل لمقارنة المواقع بأنواع الأشجار المختلفة (انظر طرق SI).

انخفض الحد الأدنى لقطر الشجرة في موقع ما بشكل ملحوظ مع زيادة عدد الأشجار في الموقع ، كما انخفض أيضًا مع انخفاض مستويات الفوسفور المتاح (الشكل 3).أ والجدول S2). أي أن التجديد حدث مؤخرًا في مناطق بها العديد من الأشجار وتنخفض فيها نسبة الفوسفور في التربة. كانت هذه المتغيرات مهمة سواء تم تضمين مواقع التحقق أم لا ، مما يشير إلى أن النموذج كان قويًا. بناءً على معدل نمو قطر ثابت تقريبًا يبلغ 0.8 سم سنويًا حتى عمر 100 عام (23) ، يبلغ عمر الشجرة التي يبلغ قطرها 50 سم أكثر من 60 عامًا. لم تتجدد أي من مواقع الرعي التي تحتوي على 5 أشجار أو أقل خلال الستين عامًا الماضية (الشكل 3أ). في ظل ظروف ارتفاع الفوسفور ، تجاوز الحد الأدنى المتوقع لعمر الأشجار في مواقع الرعي 100 عام (الشكل 3)أ).

العلاقات المتوقعة الهامة من النماذج المختلطة الخطية المعممة (لا يتم عرض فترات الثقة لأن طرق حسابها في وجود تأثيرات عشوائية مثيرة للجدل في نقاط العلوم الإحصائية تشير إلى مواقع المسح الأولية ، بينما تشير التهجينات إلى مواقع التحقق من الصحة). (أ) يختلف الحد الأدنى (المعياري) للقطر بشكل كبير في الاستجابة لعدد الأشجار في الموقع والفوسفور المتاح في التربة (انظر الجدول S2 للحصول على التفاصيل). تشير النقاط الأكثر قتامة إلى المواقع التي تحتوي على تركيزات أعلى من الفوسفور. يشير الخطان إلى ظروف منخفضة وعالية الفوسفور. (ب) يختلف احتمال وجود الشتلات بشكل كبير مع عدد الأشجار في الموقع وكمية النيتروجين في التربة. يتم عرض العلاقة المتوقعة لمتوسط ​​عدد الأشجار في أنواع مواقع الرعي الثلاثة ، بافتراض الرعي المستمر (انظر الجدول S3 للحصول على التفاصيل). (ج) اختلفت احتمالية وجود الشتلات أيضًا بشكل كبير بين أنظمة تناوب الثروة الحيوانية. كانت الاختلافات الزوجية كبيرة بين أي من الخطين العلويين المتوقعين ، وبين أي من الخطين السفليين المتوقعين (ص = 0.004 انظر الجدول S3 للحصول على التفاصيل). تعتمد العلاقة المتوقعة على متوسط ​​تركيزات النيتروجين الكلية (0.26٪).

التجديد الأخير.

زاد احتمال حدوث الشتلات في الموقع (أي التجديد الأخير) بشكل كبير مع عدد الأشجار الموجودة ، وانخفض بشكل كبير مع كمية النيتروجين الكلي في التربة (الشكل 3).ب والجدول S3). يعتمد احتمال التجديد أيضًا بشكل كبير على درجة دوران المخزون (الشكل 3ج والجدول S3). كان للمواقع غير المرصوفة أعلى احتمالية للتجديد ، تليها مواقع الدوران السريع ، والمواقع التي يتم رعيها باستمرار ، ومواقع الدوران البطيء (الشكل 3).ج). كانت هذه المتغيرات مهمة سواء تم تضمين مواقع التحقق أم لا ، مما يشير إلى أن النموذج كان قويًا. أظهر التحقيق في الأخطاء المعيارية لجميع الفروق الزوجية أن الفروق بين عدم الرعي والدوران السريع ، وبين التدوير البطيء والرعي المستمر ، لم تكن معنوية (الفروق & lt1 الخطأ المعياري) ، بينما كان الفرق بين المجموعتين معنويا (فرق & gt2). الأخطاء المعيارية الأهمية الإجمالية ص = 0.004 جدول S3).


تقنيات الطبوغرافيا

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

مسح مباشر

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

على الرغم من أن الاستشعار عن بعد قد أدى إلى تسريع عملية جمع المعلومات بشكل كبير ، وسمح بمزيد من التحكم في الدقة عبر مسافات طويلة ، إلا أن المسح المباشر لا يزال يوفر نقاط التحكم الأساسية وإطار العمل لجميع الأعمال الطبوغرافية ، سواء كانت يدوية أو قائمة على نظم المعلومات الجغرافية.

في المناطق التي كان هناك برنامج مسح ورسم خرائط مباشر مكثف (معظم أوروبا والولايات المتحدة القارية ، على سبيل المثال) ، تشكل البيانات المجمعة أساس مجموعات بيانات الارتفاع الرقمية الأساسية مثل بيانات USGS DEM. غالبًا ما يجب "تنظيف" هذه البيانات لإزالة التناقضات بين الاستطلاعات ، لكنها لا تزال تشكل مجموعة قيمة من المعلومات للتحليل على نطاق واسع.

لم تتضمن المسوحات الطبوغرافية الأمريكية الأصلية (أو مسوحات "Ordnance" البريطانية) تسجيل الإغاثة فحسب ، بل تشمل تحديد معالم المعالم والغطاء الأرضي النباتي.

الاستشعار عن بعد

الاستشعار عن بعد هو مصطلح عام لجمع البيانات الجغرافية على مسافة من مجال الموضوع.

الصور الجوية والأقمار الصناعية

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

المسح التصويري

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

الرادار والسونار

يعد رسم خرائط الرادار الساتلية إحدى التقنيات الرئيسية لتوليد نماذج الارتفاع الرقمية (انظر أدناه). يتم تطبيق تقنيات مماثلة في مسوحات قياس الأعماق باستخدام السونار لتحديد تضاريس قاع المحيط. في السنوات الأخيرة ، LIDAR (ليght دetection أاختصار الثاني صanging) ، وهي تقنية استشعار عن بعد تستخدم الليزر بدلاً من الموجات الراديوية ، وقد تم استخدامها بشكل متزايد لتلبية احتياجات رسم الخرائط المعقدة مثل رسم المظلات ومراقبة الأنهار الجليدية.


حساب الغطاء الشجري على مساحة معينة من البيانات النقطية - نظم المعلومات الجغرافية

نموذج تدفق الكربون العالمي للغابات

يحدد هذا النموذج إجمالي انبعاثات غازات الدفيئة السنوية من الغابات ، وعمليات إزالة الكربون الإجمالية (عزل) بواسطة الغابات ، والفرق بينها (التدفق الصافي) ، كل ذلك بين عامي 2001 و 2020. وتشمل الانبعاثات الإجمالية ثاني أكسيد الكربون ، والناتش 4 ، و N20 وجميع مجمعات الكربون ، وتشمل عمليات الإزالة الإجمالية عمليات الإزالة إلى كربون الكتلة الحيوية فوق الأرض وتحت الأرض. على الرغم من تشغيل النموذج لجميع كثافات مظلة الأشجار (وفقًا لـ Hansen et al. 2013) ، إلا أنه أكثر ارتباطًا بالبكسل مع كثافة المظلة بنسبة 30٪ في عام 2000 أو وحدات البكسل التي اكتسبت لاحقًا زيادة في الغطاء الشجري (وفقًا لـ Hansen et al. 2013). ويغطي الغابات المزروعة في معظم أنحاء العالم ، وأشجار المانغروف ، والغابات الطبيعية غير المانغروف ، ويستثني مزارع زيت النخيل التي كانت موجودة منذ أكثر من 20 عامًا. وهي تطبق بشكل مكاني قواعد الجرد الوطنية لغازات الاحتباس الحراري (المبادئ التوجيهية لعام 2016) الخاصة بالهيئة الحكومية الدولية المعنية بتغير المناخ (IPCC) للغابات. وهو يغطي فقط الغابات التي تحولت إلى غابات وغير غابات تم تحويلها إلى غابات وغابات متبقية (لا توجد انتقالات أخرى لاستخدام الأراضي). تم وصف النموذج ونشره في Harris et al. (2021) تغير المناخ الطبيعي "خرائط عالمية لتدفقات كربون الغابات في القرن الحادي والعشرين" (https://www.nature.com/articles/s41558-020-00976-6). على الرغم من أن النموذج المنشور غطى 2001-2019 ، فقد تم استخدام نفس الأساليب لتحديث النموذج ليشمل 2020.

هناك حاجة إلى أكثر من عشرين مدخلاً لتشغيل هذا النموذج. معظمها مكاني ، لكن بعضها جدولي. يتم تحويل جميع البيانات المكانية إلى بلاطات نقطية 10 × 10 درجة بدقة 0.00025 × 0.00025 درجة (حوالي 30 × 30 مترًا عند خط الاستواء) قبل إدراجها في النموذج. البيانات المجدولة هي بشكل عام عوامل إزالة الكتلة الحيوية السنوية (أي عزل) (مثل أشجار المانغروف والغابات المزروعة والغابات الطبيعية) ، والتي يتم تطبيقها بعد ذلك على البيانات المكانية. تشمل البيانات المكانية فقدان الغطاء الشجري السنوي ، وكثافة الكتلة الحيوية في عام 2000 ، ومحركات فقدان الغطاء الشجري ، والمناطق البيئية ، ومدى الغطاء الشجري في عام 2000 ، والارتفاع ، وما إلى ذلك. هناك حاجة إلى مدخلات مختلفة لخطوات مختلفة في النموذج. يتضمن هذا المستودع نصوصًا لمعالجة جميع المدخلات المطلوبة. يمكن معالجة العديد من المدخلات بنفس الطريقة (على سبيل المثال ، يمكن معالجة العديد من البيانات النقطية باستخدام نفس وظيفة gdal) ولكن بعضها يحتاج إلى معاملة خاصة. تنتشر نصوص معالجة الإدخال بين جميع المجلدات تقريبًا ، لسوء الحظ ، إرث تاريخي لكيفية إنشاء هذا الأمر الذي لم أقم بإصلاحه. توجد البرامج النصية لإعداد البيانات بشكل عام في المجلد الذي تكون مخرجاتها أكثر صلة به.

يمكن تنزيل المدخلات من تخزين AWS s3 أو استخدامها إذا وجدت محليًا في المجلد / usr / local / tile / في حاوية Docker. يبحث النموذج عن الملفات محليًا قبل تنزيلها. لا يزال من الممكن تشغيل النموذج بدون تنزيل مدخلات بيانات اعتماد AWS من s3 ولكن لن يتم تحميل المخرجات إلى s3. في هذه الحالة ، سيتم تخزين المخرجات محليًا فقط.

هناك ثلاثة نواتج رئيسية تم إنتاجها: إجمالي انبعاثات غازات الدفيئة ، وعمليات الإزالة الإجمالية ، وصافي التدفق ، وجميعها مجمعة للفترة 2001-2020. يتم إنتاجها بدقة 2: 0.00025 × 0.00025 درجة (حوالي 30 × 30 مترًا عند خط الاستواء) في خطوط نقطية 10 × 10 درجات (لجعل المخرجات بحجم يمكن التحكم فيه) ، و 0.04 × 0.04 درجة (حوالي 4 × 4 كم عند خط الاستواء ) كخطوط نقطية عالمية.

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

يتم تحميل البيانات النقطية للإخراج وسجلات النموذج إلى s3 ما لم يتم تنشيط علامة - no-upload (-nu) كوسيطة لسطر الأوامر أو لم يتم توفير بيانات اعتماد AWS s3 في حاوية Docker. عند حدوث أيٍّ من هذين الأمرين ، لا يتم تحميل مخرجات البيانات النقطية ولا السجلات إلى s3. يعد هذا أمرًا جيدًا لعمليات الاختبار المحلية أو إصدارات النموذج المستقلة عن s3 (أي ، يتم تخزين المدخلات محليًا وليس في s3 ، وليس لدى المستخدم اتصال بوحدة تخزين s3 أو بيانات اعتماد s3).

تُستخدم المخرجات التي يبلغ طولها 30 مترًا لتحليلات إحصاءات المناطق (أي الانبعاثات أو عمليات الإزالة أو الشبكة في المضلعات ذات الأهمية) ورسم الخرائط على منصة الويب العالمية لمراقبة الغابات أو على نطاقات صغيرة (حيث يمكن تمييز 30 مترًا من البكسل). يمكن تعيين سنوات للانبعاثات الفردية بناءً على خسارة هانسن أثناء التحليلات الإضافية ، لكن عمليات الإزالة وصافي التدفق تراكمي على مدار تشغيل النموذج بأكمله ولا يمكن تخصيص سنوات محددة. هذا الناتج 30 مترًا بالميغا غرام (Mg) من مكافئ ثاني أكسيد الكربون / هكتار 2001-2020 (أي الكثافة) ويتضمن جميع كثافات غطاء الأشجار ("المدى الكامل"): (((TCD2000 & gt0 AND WHRC AGB2000 & gt0) أو كسب هانسن = 1 أو غابات المنغروف AGB2000 & GT0 ) ليس في مزارع ما قبل عام 2000). ومع ذلك ، فقد تم تصميم النموذج ليتم استخدامه خصيصًا للغابات ، لذا فإن النموذج ينشئ ثلاثة مخرجات مشتقة 30 مترًا لكل ناتج رئيسي (إجمالي الانبعاثات ، عمليات الإزالة الإجمالية ، صافي التدفق) أيضًا (فقط للنموذج القياسي ، وليس لتحليلات الحساسية ):

  1. قيم البكسل لمدى النموذج الكامل (جميع كثافات الغطاء الشجري): (((TCD2000 & gt0 و WHRC AGB2000 & gt0) أو كسب هانسن = 1 أو غابات المنغروف AGB2000 & gt0) ليس في مزارع ما قبل عام 2000)
  2. قيم لكل هكتار لوحدات بكسل الغابة فقط: (((TCD2000 & gt30 و WHRC AGB2000 & gt0) أو كسب هانسن = 1 أو غابات المنغروف AGB2000 & gt0) ليس في مزارع ما قبل عام 2000)
  3. قيم البكسل لوحدات بكسل الغابة فقط:
    (((TCD2000 & gt30 و WHRC AGB2000 & gt0) أو ربح هانسن = 1 أو غابات المنغروف AGB2000 & gt0) ليس في مزارع ما قبل عام 2000)

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

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

تحتوي جميع مخرجات النموذج تقريبًا على بيانات وصفية مرتبطة بها ، ويمكن عرضها باستخدام أداة سطر أوامر gdalinfo (https://gdal.org/programs/gdalinfo.html). تتضمن البيانات الوصفية الوحدات وتاريخ الإنشاء وإصدار النموذج والمدى الجغرافي والمزيد. لسوء الحظ ، لا يمكن عرض البيانات الوصفية في ArcMap أو في إصدارات هذه الملفات التي يمكن تنزيلها من بوابة البيانات المفتوحة Global Forest Watch (https://data.globalforestwatch.org/).

تُستخدم النواتج التي يبلغ طولها 4 كيلومترات للخرائط الثابتة واسعة النطاق ، كما هو الحال في المنشورات والعروض التقديمية. الوحدات هي Mt CO2e / pixel / year (من أجل إظهار القيم المطلقة). يتم إنشاؤها باستخدام "مدى الغابة" لكل بكسل نقطي بحجم 30 مترًا ، وليس "المدى الكامل" 30 مترًا نقطيًا. لا ينبغي استخدامها للتحليل.

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

يعمل النموذج من سطر الأوامر داخل حاوية Linux Docker. بمجرد تكوين Docker على نظامك ، واستنساخ هذا المستودع ، وتهيئة الوصول إلى AWS (إذا رغبت في ذلك ، أو تخزين ملفات الإدخال محليًا) ، ستتمكن من تشغيل النموذج.

هناك طريقتان لتشغيل النموذج: كسلسلة من البرامج النصية الفردية ، أو من برنامج نصي رئيسي ، يقوم بتشغيل البرامج النصية الفردية بالتتابع. أي واحد تستخدمه يعتمد على ما تحاول القيام به. بشكل عام ، تعد البرامج النصية الفردية (التي تتوافق مع مراحل نموذج محددة) أكثر ملاءمة للتطوير والاختبار ، بينما يعد البرنامج النصي الرئيسي أفضل لتشغيل الجزء الرئيسي من النموذج من البداية إلى النهاية دفعة واحدة. في كلتا الحالتين ، يجب استنساخ الكود من هذا المستودع (في سطر الأوامر في المجلد الذي تريد النسخ إليه ، git clone https://github.com/wri/carbon-budget). تشغيل عالميًا ، يتكرر كلا الخيارين من خلال قائمة

275 × 10 بلاط. (تحتوي مراحل النموذج المختلفة على أعداد مختلفة من المربعات.) قم بتشغيل كل المربعات في نطاق النموذج بالكامل خلال مرحلة نموذج واحدة قبل البدء في المرحلة التالية. (يقوم البرنامج النصي الرئيسي بذلك تلقائيًا.) إذا أراد المستخدم تشغيل النموذج على مربع واحد أو عدة مربعات ، فيمكن القيام بذلك من خلال وسيطة سطر الأوامر (--tile-id-list أو -l). إذا تم سرد المربعات الفردية ، فسيتم تشغيل تلك المربعات فقط. هذا نظام طبيعي للاختبار أو لتشغيل النموذج للدول الفردية. يمكنك رؤية حدود التجانب في pixel_area_tile_footprints.zip. على سبيل المثال ، لتشغيل النموذج لمدغشقر ، يجب تشغيل المربعات 10S_040E و 10S_050E و 20S_040E فقط وستكون وسيطة سطر الأمر هي -l 10S_040E ، 10S_050E ، 20S_040E.

يمكنك القيام بما يلي في سطر الأوامر في نفس المجلد مثل المستودع على نظامك. سيؤدي هذا إلى إدخال سطر الأوامر في حاوية Docker

للتشغيل على جهاز كمبيوتر محلي ، استخدم docker-compose بحيث يتم تعيين Docker على محركات أقراص الكمبيوتر. أفعل هذا من أجل التطوير والاختبار. إذا كنت تعمل على كمبيوتر آخر ، فستحتاج إلى تغيير المجلد المحلي الذي يتم تعيينه في docker-compose.yaml لمطابقة بنية دليل جهاز الكمبيوتر الخاص بك. إذا كنت تريد أن يكون النموذج قادرًا على التنزيل والتحميل إلى s3 ، فستحتاج أيضًا إلى توفير مفتاح AWS السري الخاص بك ومفتاح الوصول كمتغيرات البيئة (-e) في أمر docker-compose run.

تشغيل إنشاء عامل الإرساء --rm -e AWS_SECRET_ACCESS_KEY =. - ه AWS_ACCESS_KEY_ID =. ميزانية الكربون

إذا لم يكن لديك بيانات اعتماد AWS ، فلا يزال بإمكانك تشغيل النموذج في حاوية عامل الإرساء ولكن لن تحدث عمليات التنزيل والتحميل. في هذه الحالة ، تحتاج إلى جميع ملفات الإدخال الأساسية لجميع المربعات في مجلد عامل الإرساء / usr / local / البلاط / على جهاز الكمبيوتر الخاص بك.

تشغيل عامل البناء - ميزانية الكربون rm

للتشغيل على جهاز بقعة AWS r5d (لتشغيل النموذج الكامل) ، استخدم بناء عامل الإرساء. تحتاج إلى توفير بيانات اعتماد AWS للنموذج للعمل لأنه بخلاف ذلك لن تتمكن من الحصول على مربعات الإدخال على آلة التركيز أو إخراج البلاط من آلة التركيز.

بناء عامل ميناء. -t gfw / ميزانية الكربون

تشغيل عامل الإرساء --rm -it -e AWS_SECRET_ACCESS_KEY =. - ه AWS_ACCESS_KEY_ID =. gfw / ميزانية الكربون

قبل تشغيل النموذج ، تأكد من صحة تواريخ مجلدات الإدخال والإخراج ذات الصلة s3 في constants_and_names.py. اعتمادًا على ما يقوم المستخدم بتشغيله بالضبط ، قد يضطر المستخدم إلى تغيير الكثير من التواريخ في مجلدات s3 أو عدم تغيير أي منها. لسوء الحظ ، لا يمكنني حقًا تقديم إرشادات أفضل من أنها تعتمد حقًا على أي جزء من النموذج يتم تشغيله وكيف. (أريد أن أجعل المواقف التي يغير المستخدمون بموجبها تواريخ المجلدات أكثر اتساقًا في النهاية.)

يمكن تشغيل النموذج إما باستخدام معالجات متعددة أو معالج واحد. الأول مخصص لعمليات تشغيل النماذج الكبيرة الحجم ، في حين أن الأخير مخصص لتطوير النماذج أو تشغيله في البلدان الصغيرة التي لا تستخدم سوى عدد قليل من المربعات. يمكن للمستخدم التبديل بين هذين الإصدارين من خلال التعليق على أجزاء التعليمات البرمجية المناسبة في كل برنامج نصي. يتم التعليق على خيار المعالج الفردي افتراضيًا. من الأمور المهمة التي يجب ملاحظتها أنه إذا حاول المستخدم استخدام عدد كبير جدًا من المعالجات ، فسوف ينفد النظام من الذاكرة ويمكن أن يتعطل (خاصة في مثيلات AWS EC2). وبالتالي ، من المهم عدم استخدام الكثير من المعالجات في وقت واحد. Generally, the limitation in running the model is the amount of memory available on the system rather than the number of processors. Each script has been somewhat calibrated to use a safe number of processors for an r5d.24xlarge EC2 instance, and often the number of processors being used is 1/2 or 1/3 of the actual number available. If the tiles were smaller (e.g., 1x1 degree), more processors could be used but then there'd also be more tiles to process, so I'm not sure that would be any faster. Users can track memory usage in realtime using the htop command line utility in the Docker container.

The flux model is comprised of many separate scripts (or stages), each of which can be run separately and has its own inputs and output(s). Combined, these comprise the flux model. There are several data preparation scripts, several for the removals (sequestration/gain) model, a few to generate carbon pools, one for calculating gross emissions, one for calculating net flux, and one for aggregating key results into coarser resolution rasters for mapping. Each script really has two parts: its mp_ (multiprocessing) part and the part that actually does the calculations on each 10x10 degree tile. The mp_ scripts (e.g., mp_create_model_extent.py ) are the ones that are run. They download input files, do any needed preprocessing, change output folder names as needed, list the tiles that are going to be run, etc., then initiate the actual work done on each tile in the script without the mp_ prefix. The order in which the individual stages must be run is very specific many scripts depend on the outputs of other scripts. Looking at the files that must be downloaded for the script to run will show what files must already be created and therefore what scripts must have already been run. Alternatively, you can look at the top of run_full_model.py to see the order in which model stages are run. The date component of the output directory on s3 generally must be changed in constants_and_names.py for each output file unless a date argument is provided on the command line.

Each script can be run either using multiple processors or one processor. The former is for full model runs, while the latter is for model development. The user can switch between these two versions by commenting out the appropriate code chunks.

The master script runs through all of the non-preparatory scripts in the model: some removal factor creation, gross removals, carbon pool generation, gross emissions, net flux, and aggregation. It includes all the arguments needed to run every script. Thus, the table below also explains the potential arguments for the individual model stages. The user can control what model components are run to some extent and set the date part of the output directories. The emissions C++ code has to be be compiled before running the master script (see below). Preparatory scripts like creating soil carbon tiles or mangrove tiles are not included in the master script because they are run very infrequently.

python run_full_model.py -t std -s all -r -d 20219999 -l all -ce loss -p biomass_soil -tcd 30 -ma -us -si -ln "This will run the entire standard model, including creating mangrove and US removal factor tiles, on all tiles and output everything in s3 folders with the date 20219999. It will save intermediate files."

Argument Short argument Required/Optional Relevant stage وصف
model-type -t مطلوب الجميع Standard model ( std ) or a sensitivity analysis. Refer to constants_and_names.py for valid list of sensitivity analyses.
stages -s مطلوب الجميع The model stage at which the model should start. all will run the following stages in this order: model_extent, forest_age_category_IPCC, annual_removals_IPCC, annual_removals_all_forest_types, gain_year_count, gross_removals_all_forest_types, carbon_pools, gross_emissions, net_flux, aggregate, create_supplementary_outputs
run-through -r Optional الجميع If activated, run stage provided in stages argument and all following stages. Otherwise, run only stage in stages argument. Activated with flag.
run-date -d مطلوب الجميع Date of run. Must be format YYYYMMDD. This sets the output folder in s3.
tile-id-list -l مطلوب الجميع List of tile ids to use in the model. Should be of form 00N_110E or 00N_110E,00N_120E or all
no-upload -nu Optional الجميع No files are uploaded to s3 during or after model run (including logs and model outputs). Use for testing to save time. When AWS credentials are not available, upload is automatically disabled and this flag does not have to be manually activated.
log-note -ln Optional الجميع Adds text to the beginning of the log
carbon-pool-extent -ce Optional Carbon pool creation Extent over which carbon pools should be calculated: loss or 2000 or loss,2000 or 2000,loss
pools-to-use -p Optional Emissions Options are soil_only or biomass_soil. Former only considers emissions from soil. Latter considers emissions from biomass and soil.
tcd-threshold -tcd Optional Aggregation Tree cover density threshold above which pixels will be included in the aggregation. Defaults to 30.
std-net-flux-aggreg -std Optional Aggregation The s3 standard model net flux aggregated tif, for comparison with the sensitivity analysis map.
mangroves -ma Optional run_full_model.py Create mangrove removal factor tiles as the first stage. Activate with flag.
us-rates -us Optional run_full_model.py Create US-specific removal factor tiles as the first stage (or second stage, if mangroves are enabled). Activate with flag.
save-intermdiates -si Optional run_full_model.py Intermediate outputs are not deleted within run_full_model.py . Use for local model runs. If uploading to s3 is not enabled, intermediate files are automatically saved.

Running the emissions model

The gross emissions script is the only part of the model that uses C++. Thus, it must be manually compiled before running. There are a few different versions of the emissions script: one for the standard model and a few other for sensitivitity analyses. The command for compiling the C++ script is (subbing in the actual file name):

c++ /usr/local/app/emissions/cpp_util/calc_gross_emissions_[VERSION].cpp -o /usr/local/app/emissions/cpp_util/calc_gross_emissions_[VERSION].exe -lgdal

For the standard model and the sensitivity analyses that don't specifically affect emissions, it is:

c++ /usr/local/app/emissions/cpp_util/calc_gross_emissions_generic.cpp -o /usr/local/app/emissions/cpp_util/calc_gross_emissions_generic.exe -lgdal

Several variations of the model are included these are the sensitivity variants, as they use different inputs or parameters. They can be run by changing the --model-type ( -t ) argument from std to an option found in constants_and_names.py . Each sensitivity analysis variant starts at a different stage in the model and runs to the final stage, except that sensitivity analyses do not include the creation of the supplementary outputs (per pixel tiles, forest extent tiles). Some use all tiles and some use a smaller extent.

Sensitivity analysis وصف Extent Starting stage
std Standard model Global mp_model_extent.py
maxgain Maximum number of years of gain (removals) for gain-only and loss-and-gain pixels Global gain_year_count_all_forest_types.py
no_shifting_ag Shifting agriculture driver is replaced with commodity-driven deforestation driver Global mp_calculate_gross_emissions.py
convert_to_grassland Forest is assumed to be converted to grassland instead of cropland in the emissions model Global mp_calculate_gross_emissions.py
biomass_swap Uses Saatchi 1-km AGB map instead of Baccini 30-m map for starting carbon densities Extent of Saatchi map, which is generally the tropics mp_model_extent.py
US_removals Uses IPCC default removal factors for the US instead of US-specific removal factors from USFS FIA Continental US mp_annual_gain_rate_AGC_BGC_all_forest_types.py
no_primary_gain Primary forests and IFLs are assumed to not have any removals Global mp_forest_age_category_IPCC.py
legal_Amazon_loss Uses Brazil's PRODES annual deforestation system instead of Hansen loss Legal Amazon mp_model_extent.py
Mekong_loss Uses Hansen loss v2.0 (multiple loss in same pixel). NOTE: Not used for flux model v1.2.0, so this is not currently supported. Mekong region N/A

Updating the model with new tree cover loss

For the current general configuration of the model, these are the changes that need to be made to update the model with a new year of tree cover loss data. In the order in which the changes would be needed for rerunning the model:

Update the model version variable version in constants_and_names.py .

Change the tree cover loss tile source to the new tree cover loss tiles in constants_and_names.py . If the tree cover loss tile pattern is different from the previous year, that will need to be changed in several places in various scripts, unfortunately.

Change the number of loss years variable loss_years in constants_and_names.py .

Make sure that changes in forest age category produced by mp_forest_age_category_IPCC.py and the number of gain years produced by mp_gain_year_count_all_forest_types.py still make sense.

Obtain and pre-process the updated drivers of tree cover loss model in mp_prep_other_inputs.py .

Create a new year of burned area data using mp_burn_year.py (multiple changes to script needed, and potentially some reworking if the burned area ftp site has changed its structure or download protocol).

In constants.h , change the number of model years.

In equations.cpp , change the number of model years.

Strictly speaking, if only the drivers, burn year, and tree cover loss are being updated, the model only needs to be run from forest_age_category_IPCC onwards (loss affects IPCC age category but model extent isn't affected by any of these inputs). However, for completeness, I suggest running all stages of the model from model_extent onwards for an update so that model outputs from all stages have the same version in their metadata and the same dates of output as the model stages that are actually being changed.

Other modifications to the model

It is recommended that any changes to the model be tested in a local Docker instance before running on an EC2 instance. I like to output files to test folders on s3 with dates 20219999 because that is clearly not a real run date. A standard development route is:

Make changes to a single model script and run using the single processor option on a single tile (easiest for debugging) in local Docker.

Run single script on a few representative tiles using a single processor in local Docker.

Run single script on a few representative tiles using multiple processor option in local Docker.

Run the master script on a few representative tiles using multiple processor option in local Docker to confirm that changes work when using master script.

Run single script on a few representative tiles using multiple processors on EC2 instance (need to commit and push changes to GitHub first).

Run master script on all tiles using multiple processors on EC2 instance. If the changes likely affected memory usage, make sure to watch memory with htop to make sure that too much memory isn't required. If too much memory is needed, reduce the number of processors being called in the script.

Depending on the complexity of the changes being made, some of these steps can be ommitted. Or if only a few tiles are being modeled (for a small country), only steps 1-4 need to be done.


شاهد الفيديو: الدرس 7-1: نمذجة البيانات بإستعمال طريقة IDW