تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
المطوّرون في المنطقة الاقتصادية الأوروبية
تعرض نقطة النهاية dataLayers بيانات مرمّزة كملفات GeoTIFF، ويمكن استخدامها في أي تطبيق لنظام المعلومات الجغرافية (GIS) لتصميم أنظمة الطاقة الشمسية.
يحتوي كل سلسلة في استجابة dataLayers على عنوان URL يمكنك استخدامه لجلب ملف GeoTIFF المقابل. تكون عناوين URL صالحة لمدة تصل إلى ساعة واحدة بعد إنشائها من طلب طبقات البيانات الأصلي. يمكن تخزين ملفات GeoTIFF لمدة تصل إلى 30 يومًا.
باستثناء طبقة RGB، لا يتم عرض ملفات GeoTIFF بشكل صحيح باستخدام عارض الصور، لأنّ المحتوى هو بيانات مرمّزة وليس صور RGB. لا يمكن أيضًا استخدام ملفات GeoTIFF مباشرةً كصورة تراكب مع Maps JavaScript API.
يوضّح الجدول التالي كل طبقة بالتفصيل.
طبقة
عمق البكسل
الدقة
الوصف
نموذج السطح الرقمي (DSM)
قيمة عائمة تشغل 32 بت
0.1 متر/بكسل
بيانات الارتفاع التي تمثّل تضاريس سطح الأرض، بما في ذلك المعالم الطبيعية والمبنية تكون القيم بالأمتار فوق مستوى سطح البحر. يتم تخزين المواقع الجغرافية غير الصالحة أو المناطق التي لا تتوفّر لدينا بيانات عنها بالقيمة -9999.
صورة جوية للمنطقة يحتوي ملف صور GeoTIFF على ثلاث نطاقات تتوافق مع قيم الأحمر والأخضر والأزرق بالترتيب لتكوين قيمة RGB ذات 24 بت لكل بكسل.
تبلغ دقة البكسل تلقائيًا 0.1 متر/بكسل.
قناع المبنى
1 بت
0.1 متر/بكسل
بت واحد لكل بكسل يشير إلى ما إذا كان يتم اعتبار هذا البكسل جزءًا من سطح أحد المباني.
التدفق السنوي
قيمة عائمة تشغل 32 بت
0.1 متر/بكسل
خريطة التدفق السنوي أو أشعة الشمس السنوية على الأسطح في المنطقة
القيم هي كيلوواط ساعة/كيلوواط/السنة.
يتم احتساب معدّل التدفق لكل موقع جغرافي، وليس فقط لأسطح المباني. يتم تخزين المواقع الجغرافية غير الصالحة أو المناطق التي لم نتمكّن من احتساب معدل التغيّر فيها بالقيمة -9999. المواقع الجغرافية خارج
نطاق التغطية
غير صالحة.
ملاحظة: هذا هو التدفق غير المحجوب.
التدفّق الشهري
قيمة عائمة تشغل 32 بت
0.5 متر/بكسل
خريطة التدفق الشهري (ضوء الشمس على الأسطح، مقسّمًا حسب الشهر) للمنطقة القيم هي كيلوواط ساعة/كيلوواط/السنة. يحتوي ملف صور GeoTIFF على 12 نطاقًا تتوافق مع الفترة من كانون الثاني (يناير) إلى كانون الأول (ديسمبر)، بالترتيب.
الظل كل ساعة
عدد صحيح 32 بت
متر واحد لكل بكسل
12 عنوان URL لخرائط الظل كل ساعة، تتوافق مع الفترة من يناير إلى ديسمبر، بالترتيب
يحتوي كل ملف GeoTIFF على 24 نطاقًا تتوافق مع
24 ساعة في اليوم. كل بكسل هو عدد صحيح 32 بت، ويتوافق مع (ما يصل إلى) 31 يومًا من ذلك الشهر. يشير الرقم 1 إلى أنّ الموقع الجغرافي المعنيّ يمكنه رؤية الشمس في ذلك اليوم وفي تلك الساعة من ذلك الشهر.
يتم تخزين المواقع الجغرافية غير الصالحة بالقيمة -9999 ويتم ضبط البت 31، لأنّ
ذلك يتوافق مع اليوم الثاني والثلاثين من الشهر وبالتالي يكون غير صالح.
فك ترميز بيانات نقطية خاصة بالظل كل ساعة
يتم ترميز بيانات الظل بالساعة في بيانات نقطية متعددة النطاقات. لمزيد من المعلومات حول أساسيات الصور النقطية، يُرجى الاطّلاع على مفاهيم Solar API.
عند تقديم طلب للحصول على بيانات الظل كل ساعة، يمكنك تلقّي ما يصل إلى 12 صورة نقطية، واحدة لكل شهر من السنة التقويمية (من كانون الثاني/يناير إلى كانون الأول/ديسمبر). يتألف كل صورة نقطية من 24 طبقة أو نطاق، تتوافق مع 24 ساعة في اليوم.
يتم تمثيل كل نطاق بمصفوفة من الخلايا أو وحدات البكسل. يحتوي كل بكسل على عمق 32 بت، وهو ما يتوافق مع (الحد الأقصى) 31 يومًا من الشهر.
لذلك، يتطلّب فك ترميز بيانات الظل حسب اليوم والوقت والشهر فهم البت والنطاق والصورة النقطية التي تحلّلها.
على سبيل المثال، لتحديد ما إذا كان موقع جغرافي معيّن بالإحداثيات (س، ص) قد شهد
الشمس في الساعة 4:00 مساءً في 22 يونيو، اتّبِع الخطوات التالية:
إرسال طلب طبقات بيانات لجميع الطبقات الخاصة بالموقع الجغرافي (س، ص)
بما أنّ شهر يونيو هو الشهر السادس من السنة، يجب استرداد عنوان URL السادس في القائمة hourlyShadeUrls.
يتم عرض النطاقات الزمنية بالساعة بتنسيق الوقت المكوّن من 24 ساعة. للحصول على بيانات الساعة 4:00 مساءً (16:00)، ابحث عن القناة رقم 17.
فهرس الأجزاء (الأيام) بدءًا من 0 للحصول على بيانات اليوم الثاني والعشرين من يونيو، اقرأ البت رقم 21.
توفّر وحدات البت بيانات ثنائية تشير إلى ما إذا كان الموقع الجغرافي قد شهد شروق الشمس في التاريخ والوقت المحدّدين. إذا كانت القيمة 1، يعني ذلك أنّ الموقع الجغرافي شهد شروق الشمس. إذا كانت قيمة البت 0،
يعني ذلك أنّ الموقع الجغرافي شهد ظلًا.
تاريخ التعديل الأخير: 2025-08-27 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-08-27 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\u003cp\u003eThe dataLayers endpoint provides access to various geographical data layers like elevation, aerial imagery, and solar potential, encoded in GeoTIFF format for use in GIS applications.\u003c/p\u003e\n"],["\u003cp\u003eGeoTIFF URLs are valid for one hour and the downloaded files can be stored for up to 30 days, with most layers requiring specialized software for proper visualization due to data encoding.\u003c/p\u003e\n"],["\u003cp\u003eThe hourly shade layer is encoded to indicate sun exposure for each location at a specific time and day of the month, requiring bitwise operations to decode the information.\u003c/p\u003e\n"],["\u003cp\u003eThe hourly shade data uses the location's regional time zone, assumes no leap days or daylight savings, and treats all days as 24 hours long with standard time noon.\u003c/p\u003e\n"]]],["The `dataLayers` endpoint provides GeoTIFF files for solar system design, accessible via URLs valid for one hour, and storable for 30 days. These files include: Digital Surface Model (DSM) for elevation; RGB imagery; Building mask indicating rooftop pixels; Annual flux showing annual sunlight; Monthly flux with sunlight data per month and hourly shade containing 12 rasters, with 24 layers for each hour of the day each month, each one represented by bits indicating whether the location saw the sun on a given day, hour and month.\n"],null,["# About GeoTIFF files\n\n**European Economic Area (EEA) developers** If your billing address is in the European Economic Area, effective on 8 July 2025, the [Google\n| Maps Platform EEA Terms of Service](https://cloud.google.com/terms/maps-platform/eea) will apply to your use of the Services. [Learn more](/maps/comms/eea/faq). In addition, certain content from the Solar API will no longer be returned. [Learn more](/maps/comms/eea/solar).\n\nThe [dataLayers](/maps/documentation/solar/data-layers) endpoint\nreturns data encoded as GeoTIFF files, which can be used in any geographic\ninformation system (GIS) application to design solar systems.\n\nEach string in the dataLayers response contains a URL, which you can\nuse to fetch the corresponding GeoTIFF. URLs are valid for up to an hour after\nthey are generated from the original data layers request. GeoTIFF files can be\nstored for up to 30 days.\n\nWith the exception of the RGB layer, GeoTIFF files don't display correctly with\nan image viewer, as the content is encoded data rather than RGB images. GeoTIFF\nfiles also cannot be used directly as an overlay image with Maps Javascript API.\n\nThe following table describes each layer in detail.\n\n| Layer | Pixel depth | Resolution | Description |\n|-----------------------------|----------------|------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Digital Surface Model (DSM) | 32-bit float | 0.1 m/pixel | Elevation data that represents the topography of Earth's surface, including natural and built features. Values are in meters above sea level. Invalid locations, or areas where we don't have data, are stored as -9999. |\n| RGB | 8-bit | 0.1 m/pixel 0.25 m/pixel 0.5 m/pixel 1 m/pixel | An aerial image of the region. The GeoTIFF imagery file contains three bands corresponding to red, green and blue values in order to form 24-bit RGB value for each pixel. By default, the pixel resolution is 0.1 m/pixel. |\n| Building mask | 1-bit | 0.1 m/pixel | One bit per pixel indicating whether that pixel is considered to be part of a rooftop. |\n| Annual flux | 32-bit float | 0.1 m/pixel | The annual flux map, or annual sunlight on roofs, of the region. Values are kWh/kW/year. Flux is computed for every location, not just building rooftops. Invalid locations, or areas where we couldn't calculate flux, are stored as -9999. Locations outside our [coverage area](/maps/documentation/solar/coverage) are invalid. **Note:** This is unmasked flux. |\n| Monthly flux | 32-bit float | 0.5 m/pixel | The monthly flux map (sunlight on roofs, broken down by month) of the region. Values are kWh/kW/year. The GeoTIFF imagery file contains 12 bands corresponding to January --- December, in order. |\n| Hourly shade | 32-bit integer | 1 m/pixel | 12 URLs for hourly shade maps corresponding to January --- December, in order. Each GeoTIFF file contains 24 bands, corresponding to the 24 hours of the day. Each pixel is a 32 bit integer, corresponding to the (up to) 31 days of that month. A 1 bit means that the corresponding location is able to see the sun on that day, at that hour, in that month. \u003cbr /\u003e Invalid locations are stored as -9999 and have bit 31 set, as that corresponds to the 32nd day of the month and is therefore invalid. |\n\nDecode hourly shade rasters\n---------------------------\n\nHourly shade data is encoded in multiband rasters. To learn more about raster\nbasics, see [Solar API Concepts](/maps/documentation/solar/concepts).\n\nWhen you make a request for hourly shade data, you can receive up to 12 rasters,\none for each month of the calendar year (January through December). Each raster\nis composed of 24 layers, or *bands*, which correspond to the 24 hours of the\nday.\n\nEach band is represented by a matrix of cells, or *pixels*. Each pixel has a\ndepth of 32 bits, which correspond to the (maximum) 31 days of the month.\nDecoding the day, time, and month of shade data, therefore, requires\nunderstanding the bit, band, and raster that you are analyzing.\n\nFor example, to identify whether a given location at coordinates (x, y) saw the\nsun at 4:00 PM on June 22, do the following:\n\n1. Make a data layers request for all layers for location (x, y).\n2. Because the month of June is the sixth month of the year, fetch the sixth URL in the `hourlyShadeUrls` list.\n3. Hourly bands are given in 24-hour time. To get data for 4:00 PM (16:00), look up the 17th channel.\n4. Bits (days) index from 0. To get data for the 22nd day of June, read bit 21.\n5. Bits provide binary data indicating whether that location saw sun at the given date and time. If the bit is 1, the location saw sun. If the bit is 0, the location saw shade.\n\nThe following code summarizes the steps above: \n\n```transact-sql\n(hourly_shade[month - 1])(x, y)[hour] & (1 \u003c\u003c (day - 1))\n```\n| **Note:** Hourly shade data is based on the regional time zone of the requested location. Hourly shade data also assumes that there are no leap days and that Daylight Savings Time does not exist. All days are assumed to be 24 hours long and noon is always \"standard time\" noon (12:00)."]]
