Solar API 概念
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
Solar API 可透過 buildingInsights 和 dataLayers 端點提供太陽能潛在資料。如要使用 Solar API 資料，瞭解下列概念可能會有幫助：
太陽輻射和溶解
建築物的「太陽能潛力」主要取決於建築物收到的陽光量以及其他因素。太陽輻射是指特定區域的光量，太陽能發電則是特定區域在一段時間內接收的平均太陽輻射量的測量結果。
千瓦 (kW) 是用來測量「功率」，或東西使用能量的速率，千瓦小時 (kWh) 則是使用「能源」或能源容量的測量依據。太陽輻射的測量單位為千瓦，而太陽能則以千瓦小時為單位。
1 kWh/kW 等於 1 日日，定義為一小時的日照強度，每平方公尺的發電量平均為 1,000 瓦 (1 千瓦)。
舉例來說，如果部分屋頂的太陽能隔熱量為 2000 kWh/kW/年，則在這裡放置的 1 kW 太陽能板陣列每年會產生 2000 kWh。放在相同位置的 4 kW 陣列每年會產生 8000 kWh。
標準測試條件是業界標準的基準測試，可用於判斷太陽能板的功率。在 STC 方面，太陽能板輸出的功率成為其最大功率 (或容量)。STC 採用 1 kW 面板可產生 1 kWh 的能源。
陽光和陽光的分位數
Solar API 將「日光」定義為相對於屋頂其他部分，屋頂特定部分所接收的日照量 (每年平均平均值)。屋頂的某些部分可能會因為鄰近建築物或樹皮遮蔽而變暗，而屋頂其他部分可能會隨時完全暴露在天空中，因此會接收較多陽光。
buildingInsights 回應中的 sunshineQuantiles 欄位可呈現屋頂或部分屋頂的日照量 11 分塊 (或分位數)。Solar API 會取用屋頂上的所有點，按「日光度」排序，並識別最高、最低和 9 個中間的中間間距值。
舉例來說，假設特定屋頂的日落部分 (1%) 每年收到 1100 kWh/kW/年，而同一屋頂最暗的部分 (也 1%) 則接收到 400 kWh/kW/year/year 狀態。下一個最暗的 20 屋頂屋頂是每年 500 千瓦時/千瓦/年。下一個晴天的屋頂是 50 千瓦時，每年可達到 900 千瓦時/千瓦時的水準。
其餘 28%；每年 1000 kWh/kW/年。
光柵
dataLayers 端點會傳回以 GeoTIFFs 中編碼的太陽能資訊，而這類資訊是一種光柵類型。
「光柵」是由一連串的儲存格 (或稱「像素」) 所組成，並依列和欄排列。每個像素都包含一個值，代表該位置的相關資訊，例如海拔、樹冠、日照等等。
光柵儲存離散和連續的資料。離散資料 (例如土地覆蓋或土壤類型) 是主題或類別型的資料。連續資料表示沒有明確邊界的現象，例如海拔或空拍圖像。
光柵是由「頻帶」組成，用來測量資料集的不同特性。光柵可以單一錶帶或多款錶帶。每個錶帶都是由儲存格矩陣 (又稱「像素」) 所組成，可儲存資訊。像素可以儲存浮點值或整數值。
像素的「位元深度」會根據公式 2n 指出像素可儲存的值數，其中 n 是位元深度。舉例來說，8 位元像素可儲存多達 0 到 255 之間的 256 (28) 值。
彈性
您可以使用 dataLayers 端點要求流動地圖。Solar API 將「flux」定義為屋頂的日照量，以千瓦時/千瓦/年為單位。計算流感時，Solar API 會將下列變數納入考量：
- 位置資訊：Solar API 會使用各種天氣組合的每小時太陽能發生率資料，通常為 4 到 10 公里的格線。API 會計算一年中每個小時的太陽位置。實際位置因地區而異，因此可能有所變動。
- 天氣模式 (雲)：在太陽輻射資料中顯然。
- 鄰近障礙物：計算時會將樹木、其他建築物和屋頂其他部分的著色納入考量。
- 方向：屋頂各部分的傾斜和方位角度。
- 真實效率：Solar API 計算的值與固定樣本效率無關。如要計算能源產量，您必須將面板的千瓦率乘以樣本數，並考量其他系統損失值。詳情請參閱「計算太陽能成本和節約效益」。
Solar API 不會將下列變數納入考量：
- 反相效率和其他損失：大部分值皆以 DC kWh 計算，但有些值會假設系統效率為 85&percnt，並轉換成 AC kWh。
- 積雪與雪：不會計入計算結果。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2024-06-26 (世界標準時間)。
[null,null,["上次更新時間：2024-06-26 (世界標準時間)。"],[[["\u003cp\u003eThe Solar API offers solar potential data for buildings, primarily focusing on sunlight exposure and utilizing two endpoints: \u003ccode\u003ebuildingInsights\u003c/code\u003e and \u003ccode\u003edataLayers\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eSolar irradiance quantifies the amount of sunlight on a surface, while solar insolation measures the average irradiance over time, both crucial for determining a building's solar potential.\u003c/p\u003e\n"],["\u003cp\u003eSunniness is a relative measure of sunlight received by different roof sections, categorized into quantiles to represent variations in exposure due to shading.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003edataLayers\u003c/code\u003e endpoint provides solar information through GeoTIFF rasters, which are grid-based images containing pixel values representing solar characteristics like flux.\u003c/p\u003e\n"],["\u003cp\u003eFlux, representing annual sunlight on roofs in kWh/kW/year, is calculated by the Solar API considering factors like location, weather, shade, roof orientation, and inherent efficiency.\u003c/p\u003e\n"]]],["The Solar API uses the buildingInsights and dataLayers endpoints to provide solar potential data. Key concepts include solar irradiance (light on an area) and insolation (average irradiance over time), measured in kilowatts (kW) and kilowatt-hours (kWh). Sunniness, quantified in 11 deciles, describes a roof's relative sunlight exposure. Rasters, composed of pixels with value data, store discrete and continuous information. Flux, the annual sunlight on roofs (kWh/kW/year), factors in location, weather, shading, and roof orientation.\n"],null,["# Solar API Concepts\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 Solar API provides solar potential data through the\n[buildingInsights](/maps/documentation/solar/reference/rest/v1/buildingInsights/findClosest) and [dataLayers](/maps/documentation/solar/reference/rest/v1/dataLayers/get) endpoints. To use Solar API data,\nunderstanding the following concepts may be helpful:\n\n- [Solar irradiance and insolation](#solar-irradiance)\n- [Sunniness and sunshine quantiles](#sunniness)\n- [Rasters](#rasters)\n- [Flux](#flux)\n\nSolar irradiance and insolation\n-------------------------------\n\nA building's [solar potential](/maps/documentation/solar/reference/rest/v1/buildingInsights/findClosest#solarpotential) is largely based on the amount of sunlight it\nreceives, along with other factors. *Solar irradiance* is the amount of light\nthat falls on a given area, while *solar insolation* is a measurement of the\naverage solar irradiance an area receives over time.\n\nA *kilowatt* (kW) is a measure of *power* , or the rate at which something uses\nenergy, while a *kilowatt-hour* (kWh) is a measure of *energy* used or energy\ncapacity. Solar irradiance is measured in kilowatts, while solar insolation is\nmeasured in kilowatt-hours.\n\n1 kWh/kW equals 1 sun hour, which is defined as one hour where the intensity of\nsunlight reaches an average of 1,000 Watts (1 kilowatt) of energy per square\nmeter.\n\nFor example, if a part of a roof has a solar insolation of 2000 kWh/kW/year, a 1\nkW solar panel array placed there will produce 2000 kWh/year. A 4 kW array\nplaced in the same location will produce 8000 kWh/year.\n\n[Standard Test\nConditions](https://footprinthero.com/standard-test-conditions) are\nan industry standard benchmark used to determine solar panel power output. At\nSTC, the amount of power a solar panel outputs becomes its maximum power rating,\nor capacity. A 1 kW panel will generate 1 kWh of energy under STC.\n\nSunniness and sunshine quantiles\n--------------------------------\n\nThe Solar API defines \"sunniness\" as the level of sunlight received by a\nparticular section of a roof relative to the rest of the roof, annually on\naverage. Some parts of a roof may be darker than others, due to shade from\nnearby buildings or tree cover, while other parts of a roof may be fully exposed\nto the sky at all times and therefore receive more sunlight.\n\nThe [sunshineQuantiles](/maps/documentation/solar/reference/rest/v1/buildingInsights/findClosest#sizeandsunshinestats) field in the [buildingInsights](/maps/documentation/solar/reference/rest/v1/buildingInsights/findClosest) response provides 11\nbuckets, or deciles, of the sunniness of a roof or part of a roof. The\nSolar API takes all of the points on the roof, sorts them by their\n\"sunniness,\" and identifies the highest, lowest, and 9 intermediate evenly\nspaced values.\n\nFor example, assume that the sunniest part (1%) of a given roof receives\n1100 kWh/kW/year, while the darkest part (also 1%) of the same roof\nreceives 400 kWh/kW/year. The next darkest 20% of the roof receives 500\nkWh/kW/year. The next sunniest 50% of the roof receives 900 kWh/kW/year.\nThe remaining 28% receives 1000 kWh/kW/year.\n\nRasters\n-------\n\nThe [dataLayers](/maps/documentation/solar/reference/rest/v1/dataLayers/get) endpoint returns solar information encoded in [GeoTIFFs](/maps/documentation/solar/geotiff), which\nare a type of raster.\n\nA *raster* is composed of a matrix of cells, or *pixels*, arranged in rows and\ncolumns. Each pixel contains a value that represents information about that\nlocation, such as elevation, tree canopy, sunlight, among others.\n\nRasters store *discrete* and *continuous* data. *Discrete* data, such as land\ncover or soil type, is thematic, or categorical. *Continuous* data represents\nphenomena that have no clear boundaries, such as elevation or aerial imagery.\n\nRasters are composed of *bands* , which measure different characteristics of a\ndataset. Rasters can have a single band or multiple bands. Each band is composed\nof a matrix of cells, or *pixels*, which store information. Pixels can store\nfloat or integer values.\n\nThe *bit depth* of a pixel indicates the number of values that a pixel can\nstore, based on the formula 2^n^, where *n* is the bit depth. For\nexample, an 8-bit pixel can store up to 256 (2^8^) values ranging from\n0 to 255.\n\nFlux\n----\n\nYou can request [flux maps](/maps/documentation/solar/data-layers) using the [dataLayers](/maps/documentation/solar/reference/rest/v1/dataLayers/get) endpoint. The\nSolar API defines *flux* as the annual amount of sunlight on roofs in\nkWh/kW/year. In calculating flux, the Solar API takes the following\nvariables into account:\n\n- **Location information:** The Solar API uses hourly solar irradiance data from various weather sets, which are typically on a 4 to 10 km grid. The API computes the position of the sun in the sky at each hour of the year. This is location-dependent and may vary as a result.\n- **Weather patterns (clouds):** These are accounted for in the solar irradiance data.\n- **Shade from nearby obstacles:** Shading from trees, other buildings, and other parts of the roof are taken into account in calculations.\n- **Orientation:** The pitch and azimuth of each part of the roof.\n- **True efficiency:** The values computed by the Solar API are independent of the panel efficiency. To calculate energy production, you must multiply by the kilowattage of the panels and factor in other system losses. For more information, see [Calculate solar costs and\n savings](/maps/documentation/solar/calculate-costs-us).\n\nThe Solar API does not take the following variables into account:\n\n- **Inverter efficiency and other losses:** Most values are computed in DC kWh, but some are converted to AC kWh assuming an 85% system efficiency.\n- **Soiling and snow:** These are not included in the calculations."]]
