Solar API 概念
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
Solar API 通过 buildingInsights 和 dataLayers 端点提供太阳能发电潜力数据。如需使用 Solar API 数据,了解以下概念可能会有帮助:
太阳辐射和日照
建筑物的太阳能发电潜力很大程度上取决于它所接收的阳光量以及其他因素。太阳辐射是落在给定区域上的光量,而日照量衡量的是该区域在一段时间内收到的平均太阳辐射。
千瓦 (kW) 是一种衡量功率(即设备使用能量的速度)的度量单位,而千瓦时 (kWh) 是一种对使用量或能源容量的衡量。太阳辐射以千瓦为单位测量,而太阳日照则以千瓦时测量。
1 千瓦时/千瓦时等于 1 个太阳小时,即阳光强度平均达到每平方米 1,000 瓦(1 千瓦)的一小时。
例如,如果屋顶某处的太阳能日照量为 2000 千瓦时/千瓦/年,那么放置在此处的 1 千瓦时太阳能电池板阵列的产能将达到 2000 千瓦时/年。放置在同一位置的 4 kW 阵列每年可产生 8000 千瓦时电能。
标准测试条件是用于确定太阳能电池板功率输出的业界标准基准。在 STC 时,太阳能电池板的输出功率会变为其最大额定功率(即容量)。在 STC 条件下,一块 1 kW 的电池板将产生 1 kWh 的能源。
光度和日照分位数
Solar API 将“日照度”定义为屋顶特定部分相对于屋顶其余部分接收的日照量(平均每年)。由于附近建筑物的阴影或树木覆盖,屋顶的某些部分可能比其他部分更暗,而屋顶的其他部分可能始终完全暴露在天空中,从而接收到更多阳光。
buildingInsights 响应中的 sunshineQuantiles 字段针对屋顶或部分屋顶的日照度提供 11 个分桶(十分之一)。Solar API 会获取屋顶上的所有点,按“日光度”对其进行排序,并确定最高、最低和 9 个等距中间值。
例如,假设给定屋顶最光照的部分 (1%) 的能效为 1100 千瓦时/千瓦/年,而同一屋顶最暗的部分(也是 1 百瓦时)的电能为 400 千瓦时/千瓦/年。紧接着最暗的 20% 的屋顶得到 500 kWh/kW/年下一个阳光充足的 50% 屋顶的太阳能电池能为每年 900 千瓦时/千瓦时。
余下的 28 家企业可获得 1000 千瓦时/年的电量。
光栅
dataLayers 端点返回以 GeoTIFFs(一种光栅类型)编码的太阳能信息。
光栅由行列排列的单元矩阵(即像素矩阵)组成。每个像素都包含一个表示该位置相关信息的值,例如海拔、树冠、日照等等。
光栅会存储离散数据和连续数据。离散数据(例如土地覆被或土壤类型)是主题数据或分类数据。连续数据表示没有明确边界的现象,例如海拔或航拍图像。
光栅由频段组成,频段测量数据集的不同特征。光栅可以有一个或多个频段。每个频段都由存储信息的单元格矩阵(即像素)组成。像素可以存储浮点值或整数值。
根据公式 2n,像素的位深表示像素可以存储的值的数量,其中 n 是位深。例如,一个 8 位像素最多可存储 256 (28) 个值,范围为 0 到 255。

Flux
您可以使用 dataLayers 端点来请求流量图。Solar API 将“通量”定义为屋顶每年的日照量(以 kWh/kW/年为单位)。在计算通量时,Solar API 会考虑以下变量:
- 位置信息:Solar API 使用来自各种天气组的每小时太阳辐射数据,这些数据通常位于 4 到 10 公里的网格上。该 API 会计算一年中每个小时太阳在天空中的位置。这取决于具体的地理位置,因此可能会有所变化。
- 天气模式(云朵):这些模式会计入太阳辐射数据中。
- 附近障碍物的遮蔽:计算时会考虑树木、其他建筑物和屋顶其他部分的阴影。
- 方向:屋顶各个部分的倾斜度和方位角。
- 真实效率:Solar API 计算的值与电池板的能效无关。要计算发电量,您必须乘以电池板的千瓦,并将其他系统损耗考虑在内。如需了解详情,请参阅计算太阳能的成本和节约。
Solar API 不会考虑以下变量:
- 逆变器效率和其他损耗:大多数值以 DC kWh 为单位计算,但有些值转换为 AC kWh(假设系统效率为 85%)。
- 泥土和雪:这些情况不包括在计算中。
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2024-06-26。
[null,null,["最后更新时间 (UTC):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."]]