واجهة درجات-اليوم

درجات-يوم التدفئة والتبريد من إعادة تحليل ERA5-Land الساعية، رجوعًا إلى 1950، في أي بقعة يابسة — بما فيها الأماكن التي لا محطة أرصاد فيها ضمن 60 كم. وscope واحد — dju — يغطي هذه الصفحة كلها.

درجات-اليوم#

GEThttps://api.climatememory.com/v1/degree-daysscope: dju2 أرصدة، +1 عن كل مدة كاملة من 365.25 يومًا ضمن المجال

درجات-يوم التدفئة والتبريد لإحداثية.

المعاملات

المعامل	النوع	الافتراضي	الوصف
`lat`	float	—	مطلوب.
`lon`	float	—	مطلوب.
`base`	number \| preset \| csv	18	أي حرارة أساس بالدرجة المئوية، أو قيمة جاهزة: `uk` (15.5) أو `ashrae` (18.333) أو `iso` أو `france` أو `eurostat`. وحتى 60 قيمة مفصولة بفواصل، بلا تكلفة إضافية — انظر أدناه.
`method`	string	hourly	`hourly` أو `costic` أو `mean` أو `eurostat`. وعقدك هو من يقرر هذا لا نحن.
`start`	ISO date	1 يناير من سنة النهاية	10 سنوات كحد أقصى لكل طلب.
`end`	ISO date	اليوم
`type`	string	both	`HDD` أو `CDD` أو `both`.
`breakdown`	string	monthly	`daily` أو `weekly` أو `monthly` أو `yearly`.
`elevation`	float (m)	—	الارتفاع الأرضي الحقيقي لموقعك. ينقل السلسلة من ارتفاع الخلية إلى ارتفاعك — انظر أدناه.
`format`	string	json	`json` أو `csv`. وCSV ميزة في الخطط المدفوعة.

{
  "location": {
    "latitude": 36.75, "longitude": 3.06,
    "grid_cell": { "latitude": 36.7, "longitude": 3.1,
                   "distance_km": 6.61, "resolution_km": 9 }
  },
  "parameters": {
    "base_temperature_c": 18.0, "method": "hourly",
    "start": "2025-07-01", "end": "2026-06-30"
  },
  "totals": { "hdd": 781.86, "cdd": 1331.61 },
  "quality": {
    "days": 365, "coverage": 1.0,
    "missing_hours": 0, "provisional_days": 0
  },
  "breakdown": [ { "year": 2025, "month": 7, "hdd": 0.0, "cdd": 289.4, "days": 31 } ]
}

كتلة quality ليست زينة. فـ coverage دون 1.0 يعني أن ساعات كانت ناقصة من الأرشيف. وprovisional_days يعدّ الأيام المملوءة من التنبؤ بدل إعادة التحليل النهائية، لأن ERA5-Land يُنشر بتأخير خمسة أيام تقريبًا.

وإن كنت تسوّي عقدًا بهذه الأرقام فتحقق منهما معًا. فمجموع محسوب على تغطية 0.98 ليس خاطئًا، لكنه ليس الادعاء نفسه الذي يقوم على 1.0 — والفرق غير مرئي في totals.

ما درجة-اليوم، في فقرة واحدة

درجة-يوم التدفئة تقيس كم انخفض هواء الخارج دون حرارة أساس، وكم دام ذلك. فعند الأساس 18 °م تسهم ساعة عند 16 °م بمقدار (18 − 16) / 24 = 0.083 HDD. اجمع الساعات فيكون لديك رقم يتناسب مع الطاقة التي احتاجها المبنى. ودرجات-يوم التبريد مرآتها: كم ارتفع الهواء فوق الأساس. وهي الطريقة المعيارية لمقارنة موسم تدفئة بآخر بعد إخراج الطقس من المقارنة.

أسس كثيرة، طلب واحد، سعر واحد#

GEThttps://api.climatememory.com/v1/degree-days?base=15,15.5,18,18.5,20scope: djusame as one base

حتى 60 حرارة أساس في نداء واحد، بسعر واحدة.

قراءة السلسلة الساعية وفك ترميزها هي تكلفة جواب درجات-اليوم كلها. وما إن تصير تلك المصفوفة في الذاكرة حتى يصبح أي أساس آخر مجرد طرح عليها، فيكلّف طلب ستين أساسًا ما يكلّفه طلب أساس واحد.

وتكسب الاستجابة مصفوفة by_base تحمل كل الأسس بالترتيب الذي ذكرتها به. ويبقى totals وbreakdown واصفَين للأول، فتظل الشيفرة المكتوبة قبل وجود هذه الميزة تعمل بلا تغيير.

"by_base": [
  {"base": 15.0,  "hdd": 402.11, "cdd": 1731.4},
  {"base": 15.5,  "hdd": 431.02, "cdd": 1706.3},
  {"base": 18.0,  "hdd": 781.86, "cdd": 1331.6}
]

وهو مفيد حين لا تعرف بعد أي أساس يعيد إنتاج أرقام عقد ما، أو حين يُسوّى المبنى نفسه على أسس مختلفة من أطراف مختلفة — فمالك على 15.5 ومورّد طاقة على 18 كلاهما محق، وهذا يعيدهما معًا في نداء واحد.

طرائق الحساب#

GEThttps://api.climatememory.com/v1/degree-days/compare-methodsscope: dju2 أرصدة، +1 عن كل مدة كاملة من 365.25 يومًا ضمن المجال

الطرائق الأربع كلها على الفترة نفسها، جنبًا إلى جنب.

GEThttps://api.climatememory.com/v1/methodsلا حاجة إلى مفتاح0 أرصدة

تعريفات الطرائق وقيمها الجاهزة. دون حاجة إلى مفتاح.

الطريقة معامل لأن عقدك هو من يقررها لا نحن. البيانات نفسها، والأساس نفسه، والسنة نفسها، في الجزائر العاصمة:

الطريقة	HDD 18 °C	CDD 18 °C	متى تُستعمل
`hourly`	781.9	1331.6	الافتراضية. تكامل العجز الساعي — وهي الأوفى فيزيائيًا.
`costic`	741.7	1349.5	DJU unifiés الفرنسية. تفرضها عقود الأداء الطاقي الفرنسية.
`mean`	659.9	1267.8	المتوسط اليومي مقابل الأساس. وهو العرف الدولي الأكثر شيوعًا.
`eurostat`	587.7	656.6	إحصاءات أوروبية. عتباتها مثبَّتة في التعريف نفسه وتتجاهل `base`.

الطريقة الساعية والمتوسط اليومي يفترقان بنسبة 18 % على البيانات نفسها. وهذا ليس فرق تقريب — بل هو الفرق بين ربح خلاف على فاتورة طاقة وخسارته. اختر الطريقة التي تعيد إنتاج أرقام عقدك قبل أن تلتزم بخطة؛ ولهذا وُجد compare-methods، وتكلفته طلب واحد.

وeurostat يتجاهل base تجاهلًا تامًا: فالتعريف يثبّت عتباته الخاصة، واحترام معاملك كان سينتج رقمًا ليس درجة-يوم بحسب Eurostat مع ادعائه ذلك.

/v1/methods لا يحتاج مفتاحًا. استعمله لملء قائمة اختيار الطريقة في واجهتك دون إنفاق شيء، ودون تثبيت قائمة في الشيفرة ستتقادم.

درجات-اليوم حسب المدينة#

GEThttps://api.climatememory.com/v1/degree-days/city/{country}/{slug}scope: dju2 أرصدة، +1 عن كل مدة كاملة من 365.25 يومًا ضمن المجال

الشيء نفسه، مع المنطقة الزمنية للمدينة وتصحيح جزيرة حرارتها الحضرية.

يطبّق تصحيحين لا تقدر عليهما إحداثية مجردة: المنطقة الزمنية للمدينة، فتُقطَّع الأيام محليًا، وإزاحة جزيرة الحرارة الحضرية المعايَرة الخاصة بها.

فإعادة التحليل تقرأ المناطق المبنية أقل بمقدار 1–3 °م. وذلك يحيز درجات-يوم التبريد نحو الانخفاض — وهو أمر جوهري إن كنت تحسب حجم التكييف، وغير مرئي إن لم تكن تعرف أن عليك البحث عنه.

elevation لا يُطبَّق على هذا المسار، وهذا الإغفال متعمَّد. فإزاحة المدينة محسوبة أصلًا مقابل محطات مُعيَّرة إلى ارتفاع المدينة نفسها، فتصحيح تدرّج حراري ثانٍ كان سيحسب الارتفاع نفسه مرتين — في الاتجاه نفسه، وبقدر من المعقولية يكفي لألا ينتبه أحد. وإن احتجت ارتفاع مبنى بعينه فاستعمل نقطة نهاية الإحداثيات مع elevation وتخلَّ عن تصحيح جزيرة الحرارة.

درجات-اليوم لمبناك أنت لا لخلية الشبكة#

GEThttps://api.climatememory.com/v1/degree-days?elevation={metres}scope: djusame

تصحيح بمعدل التناقص الحراري من ارتفاع أرض الخلية إلى ارتفاعك.

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

وهو اختياري، والاستجابة تقول بالضبط ما فعلته:

"elevation": {
  "applied": true,
  "model_elevation_m": 42.0,
  "location_elevation_m": 1200,
  "temperature_offset_c": -7.53,
  "caveat": "Lapse-rate correction. It assumes temperature falls smoothly with
             height, which a valley floor under a winter inversion does not."
}

والتنبيه يسافر داخل الاستجابة لا في هذه الصفحة وحدها، لأن من سيقرأ ذلك الـ JSON بعد ستة أشهر ليس من قرأ التوثيق.

تثبيت خلية، ليبقى خط الأساس قابلًا للمقارنة#

GEThttps://api.climatememory.com/v1/cells/resolvescope: dju1 رصيد

أي خلية ستجيب عن نقطة، وكم تبعد.

GEThttps://api.climatememory.com/v1/degree-days/cell/{cell_id}scope: dju2 أرصدة، +1 عن كل مدة كاملة من 365.25 يومًا ضمن المجال

درجات-اليوم لخلية مسمّاة — دون أي بحث عن أقرب خلية، أبدًا.

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

ومع اتساع الأرشيف تتغير أقرب خلية إلى موقع بعينه — وهو تحسّن في التغطية كان سيصل إلى بياناتك في صورة قفزة بلا تفسير.

# مرة واحدة، عند الإعداد
GET /v1/cells/resolve?lat=45.19&lon=5.72
  → { "id": "era5l_45.20_5.70", "distance_km": 1.4, "resolution_km": 9 }

# وفي كل مرة بعد ذلك
GET /v1/degree-days/cell/era5l_45.20_5.70?base=18&start=2015-01-01&end=2025-12-31

وdistance_km يساوي 0 في الطلب المثبَّت بحكم البناء: فقد سمّيت الخلية، فلم يُستبدل بها شيء. والخلية التي لم تعد موجودة تعيد 404 cell_not_found بدل الارتداد صامتة إلى جارة — وهو ما كان سيعيد الاستبدال ذاته الذي ثبّتّها لتجنبه.

/v1/cells/resolve هو أيضًا الطريق الرخيص لتعرف قبل أن تدفع ثمن بيانات أن أقرب خلية تبعد 60 كم. فهو لا يفك ترميز شيء ولا يقرأ أي سلسلة زمنية، وسعره موافق لذلك: رصيد واحد.

فترات التفصيل#

GEThttps://api.climatememory.com/v1/degree-days?breakdown={daily|weekly|monthly|yearly}scope: djusame

جمّع الطلب نفسه إلى الفترة التي يُسوّى عليها عقدك.

تحمل كل استجابة درجات-يوم مصفوفة breakdown مجمَّعة إلى الفترة التي تطلبها. والعقود تُسوّى على فترات مختلفة، فالأربع كلها متاحة في الطلب نفسه وبالسعر نفسه.

الفترة	ما يحمله كل صف
`daily`	التاريخ وHDD وCDD والحرارة الدنيا/العليا/المتوسطة
`weekly`	سنة ISO وأسبوعها، وتاريخ بدايته، والمجاميع
`monthly`	السنة والشهر والمجاميع — وهو الافتراضي
`yearly`	السنة والمجاميع

الأسابيع أسابيع ISO، فالأسبوع ينتمي إلى السنة التي يقع فيها خميسه. و1 يناير 2023 يقع في الأسبوع 52 من 2022، وهناك نبلّغ عنه — وهو ما سيفعله جدولك الحسابي أيضًا، ومخالفة الجدول الحسابي هي ما يبدأ به اجتماع تسوية.

ويحمل كل وعاء أيضًا days، فيبدو الشهر الناقص عند حافة مجالك ظاهرًا لا قصيرًا في صمت. فشهر فبراير الذي فيه "days": 12 شهر لا ينبغي أن تقارنه بشهر كامل.

مجاميع شهرية لسنة#

GEThttps://api.climatememory.com/v1/degree-days/monthlyscope: dju2 أرصدة

اثنا عشر مجموعًا شهريًا لسنة تقويمية واحدة، بلا سلسلة يومية.

GEThttps://api.climatememory.com/v1/coverageلا حاجة إلى مفتاح0 أرصدة

ما يحويه الأرشيف: أول يوم وآخر يوم فيهما بيانات، والمحور الذي سينمو فيه. دون حاجة إلى مفتاح.

اختصار للحالة الشائعة: ?lat=&lon=&year=2025 فتعود اثنا عشر صفًا. وهي البيانات نفسها التي يعطيها /v1/degree-days?breakdown=monthly على المجال نفسه؛ بمعاملات أقل عرضة للخطأ.

و/v1/coverage يذكر أول يوم في الأرشيف وآخره واستبانته، ولا يحتاج مفتاحًا، وهو الشيء الصحيح للتحقق منه قبل أن تطلب فترة قريبة من حافة الحاضر — فـ ERA5-Land متأخر نحو خمسة أيام، وprovisional_days في استجابتك هي النتيجة.

{
  "start": "1950-01-01",
  "end": "2026-07-29",        // آخر يوم يحمل بيانات فعلًا
  "axis_end": "2026-12-31",   // حيث سيتوقف هذا التشغيل عن النمو
  "hours": 671256, "axis_hours": 674976,
  "cells": 86274, "resolution_km": 9.0,
  "run": "world-1950-2026-p1000"
}

end وaxis_end سؤالان مختلفان، والأول وحده يتعلق بالبيانات. فالتشغيل يُكتب مقابل التقويم كله الذي سيملؤه في النهاية — فأرشيف 1950-2026 يحجز كل ساعة حتى 31 ديسمبر 2026 — والتحديث يملؤه كلما نشر Copernicus.

وحتى 2026-08-03 كانت نقطة النهاية هذه تذكر المحور بوصفه end، فتنسب إلى الأرشيف نحو خمسة أشهر من الساعات كانت فارغة. وend هو ما يمكنك طلبه اليوم؛ والطلب الواقع كله بعده يعطي 404 outside_archive لا جوابًا سليم البنية مجموعه صفر.

تصدير CSV#

GEThttps://api.climatememory.com/v1/degree-days?format=csvscope: dju4× the JSON call

صفوف التفصيل في ملف CSV. للخطط المدفوعة فقط.

أضف format=csv إلى أي طلب درجات-يوم. فتحصل على صفوف breakdown في ملف CSV، مسمّى باسم الموقع والتواريخ ليبقى معروفًا بعد ستة أشهر في مجلد التنزيلات.

year,month,hdd,cdd,days,t_mean,coverage,provisional
2024,1,205.03,2.88,31,11.48,1.0,false
2024,2,168.44,4.10,29,12.31,1.0,false

للخطط المدفوعة فقط، وبحدود: المجال الأقصى نفسه الذي لطلب JSON، وصفوف مجمَّعة فقط — لا السلسلة الساعية أبدًا — وتكلفته أربعة أرصدة عن كل رصيد يكلّفه نداء JSON المكافئ. والمفتاح المجاني يحصل على 402 export_not_in_plan.

وهذا متعمَّد لا متبرَّم به. فالأرشيف هو ما تدفع ثمنه، والتصدير بلا حدود هو الطريق الذي يستولي به منافس عليه في أصيل يوم. وهذه الحدود هي ما يتيح لهذه الصيغة أن توجد أصلًا.

التاريخ الساعي#

GEThttps://api.climatememory.com/v1/historicalscope: dju(years + 1) × (variables ÷ 2), rounded down, min 1

أرشيف إعادة التحليل مقدَّمًا خامًا: طقس ساعي منذ 1950.

المعاملات

المعامل	النوع	الافتراضي	الوصف
`lat`	float	—	مطلوب.
`lon`	float	—	مطلوب.
`start`	ISO date	—	مجال الطلب الواحد مسقوف — انظر الخطط.
`end`	ISO date	—
`variables`	csv	مجموعة جزئية معقولة	اسأل `/v1/historical/variables` عمّا يحويه هذا الأرشيف.
`hourly`	bool	true	تضمين السلسلة ساعة بساعة.
`daily`	bool	`false` — و`true` للمدن	تضمين التجميعات اليومية، مقطَّعة على الأيام التقويمية المحلية.

الأرشيف نفسه الذي تُبنى منه درجات-اليوم، مقدَّمًا مباشرة: ساعيًا، منذ 1950، على شبكة 9 كم، في كل بقاع اليابسة. المضيف نفسه والـ scope dju نفسه — فإن كنت تستطيع نداء درجات-اليوم فأنت تستطيع نداء هذا.

هذا الأرشيف اليوم يحمل الحرارة ولا شيء غيرها. فقد أُدخل من أجل درجات-اليوم، ودرجات-اليوم تحتاج متغيرًا واحدًا. وقد وعدت هذه الصفحة بـ«الرطوبة والرياح والهطول والإشعاع الشمسي» حتى 2026-08-03 والأرشيف لم يحمل شيئًا منها قط.

/v1/historical/variables هو الجواب المحدَّث دائمًا — فهو يقرأ التشغيل المرقَّى لا هذه الجملة، ولا يحتاج مفتاحًا، ولا يكلّف شيئًا. نادِه قبل أن تبني على حقل.

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

وللقيم اليومية على مدى فترة طويلة، أو للمعدلات والاتجاهات، استعمل بدلًا من ذلك واجهة المناخ — فهي تحمل الحقول اليومية مشتقة مسبقًا، ولا حدّ 9 كم/1950 فيها، وتجيب بمناخ كامل في نداء واحد.

التاريخ حسب المدينة#

GEThttps://api.climatememory.com/v1/historical/city/{country}/{slug}scope: dju(years + 1) × (variables ÷ 2), rounded down, min 1

مطابق، مع المنطقة الزمنية للمدينة وتصحيح جزيرة الحرارة.

شيئان لا تحملهما إحداثية: المنطقة الزمنية للمدينة، فتُقطَّع الأيام حيث تعيشها المدينة فعلًا، وتصحيح جزيرة الحرارة الحضرية المعايَر الخاص بها. وdaily هنا افتراضه true، لأن طلب المدينة يكاد يكون دائمًا طلبًا عن أيام.

المتغيرات المتاحة#

GEThttps://api.climatememory.com/v1/historical/variablesلا حاجة إلى مفتاح0 أرصدة

ما يحويه الأرشيف الآن، بوحداته، وأي الحقول مشتقة. دون حاجة إلى مفتاح.

يسرد ما يحويه الأرشيف الآن، بوحداته، وأي الحقول مشتقة لا مخزَّنة. فالأرشيف المُدخَل لأجل درجات-اليوم وحدها لا يحمل إلا الحرارة، وهذه نقطة النهاية تقول ذلك صراحة بدل أن تعيد أعمدة من null.

بعض الحقول محسوبة لا مخزَّنة: الرطوبة من نقطة الندى، وسرعة الريح واتجاهها من المركبتين u وv. فتخزين ما يُحسب في ميكروثوانٍ كان سيزيد الأرشيف الثلث بلا فائدة — لكن الحقل المشتق لا يظهر إلا حين تكون مصادره في التشغيل، ولهذا كانت الحقيقة عمّا يمكنك طلبه هي هذه النقطة لا قائمة مكتوبة في صفحة. وفي الأرشيف المرقَّى اليوم المصادر غائبة، فالجواب هو temperature_2m وحده.