Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Développeurs de l'Espace économique européen (EEE)
Le point de terminaison dataLayers renvoie des données encodées sous forme de fichiers GeoTIFF, qui peuvent être utilisées dans n'importe quelle application de système d'information géographique (SIG) pour concevoir des systèmes solaires.
Chaque chaîne de la réponse dataLayers contient une URL que vous pouvez utiliser pour récupérer le GeoTIFF correspondant. Les URL sont valides pendant une heure maximum après leur génération à partir de la requête de calques de données d'origine. Les fichiers GeoTIFF peuvent être stockés pendant 30 jours maximum.
À l'exception de la couche RVB, les fichiers GeoTIFF ne s'affichent pas correctement avec un lecteur d'images, car le contenu est constitué de données encodées plutôt que d'images RVB. Les fichiers GeoTIFF ne peuvent pas non plus être utilisés directement comme image de superposition avec l'API Maps JavaScript.
Le tableau suivant décrit chaque couche en détail.
intégrée
Profondeur de pixel
Solution
Description
Modèle numérique de surface (MNS)
Float 32 bits
0,1 m/pixel
Données d'altitude représentant la topographie de la surface de la Terre, y compris les éléments naturels et artificiels. Les valeurs sont exprimées en mètres au-dessus du niveau de la mer. Les zones non valides ou pour lesquelles nous ne disposons pas de données sont stockées sous la forme -9999.
RVB
8 bits
0,1 m/pixel 0,25 m/pixel 0,5 m/pixel 1 m/pixel
Une image aérienne de la région. Le fichier d'imagerie GeoTIFF contient trois bandes correspondant aux valeurs rouge, verte et bleue afin de former une valeur RVB de 24 bits pour chaque pixel.
Par défaut, la résolution des pixels est de 0,1 m/pixel.
Masque de bâtiment
1 bit
0,1 m/pixel
Un bit par pixel indiquant si ce pixel est considéré comme faisant partie d'un toit.
Flux annuel
Float 32 bits
0,1 m/pixel
Carte du flux annuel ou de l'ensoleillement annuel des toits de la région.
Les valeurs sont exprimées en kWh/kW/an.
Le flux est calculé pour chaque emplacement, et pas seulement pour les toits des bâtiments. Les zones non valides ou celles pour lesquelles nous n'avons pas pu calculer le flux sont stockées sous la valeur -9999. Les zones géographiques situées en dehors de notre zone de couverture ne sont pas valides.
Remarque : Il s'agit d'un flux non masqué.
Flux mensuel
Float 32 bits
0,5 m/pixel
Carte du flux mensuel (lumière du soleil sur les toits, ventilée par mois) de la région. Les valeurs sont exprimées en kWh/kW/an. Le fichier d'imagerie GeoTIFF contient 12 bandes correspondant aux mois de janvier à décembre, dans l'ordre.
Ombre horaire
Entier de 32 bits
1 m/pixel
12 URL pour les cartes d'ombrage horaires correspondant à janvier-décembre, dans l'ordre.
Chaque fichier GeoTIFF contient 24 bandes, correspondant aux 24 heures de la journée. Chaque pixel est un entier de 32 bits, correspondant aux (jusqu'à) 31 jours de ce mois. Un bit à 1 signifie que l'emplacement correspondant peut voir le soleil ce jour-là, à cette heure-là, au cours de ce mois.
Les emplacements non valides sont stockés sous la forme -9999 et le bit 31 est défini, car cela correspond au 32e jour du mois et n'est donc pas valide.
Décoder les rasters d'ombrage horaires
Les données d'ombrage horaire sont encodées dans des rasters multibandes. Pour en savoir plus sur les bases des rasters, consultez Concepts de l'API Solar.
Lorsque vous demandez des données d'ombrage horaires, vous pouvez recevoir jusqu'à 12 rasters, un pour chaque mois de l'année civile (de janvier à décembre). Chaque raster est composé de 24 couches, ou bandes, qui correspondent aux 24 heures de la journée.
Chaque bande est représentée par une matrice de cellules, ou pixels. Chaque pixel a une profondeur de 32 bits, ce qui correspond aux 31 jours (maximum) du mois.
Pour décoder le jour, l'heure et le mois des données d'ombrage, vous devez comprendre le bit, la bande et le raster que vous analysez.
Par exemple, pour savoir si un lieu donné aux coordonnées (x, y) a été ensoleillé à 16h le 22 juin, procédez comme suit :
Envoyez une requête de calques de données pour tous les calques de l'emplacement (x, y).
Étant donné que le mois de juin est le sixième mois de l'année, récupérez la sixième URL de la liste hourlyShadeUrls.
Les tranches horaires sont indiquées au format 24 heures. Pour obtenir les données de 16h00, recherchez le 17e canal.
Index des bits (jours) à partir de 0. Pour obtenir les données du 22 juin, lisez le bit 21.
Les bits fournissent des données binaires indiquant si l'emplacement a été ensoleillé à la date et à l'heure données. Si le bit est défini sur 1, cela signifie que l'emplacement a été ensoleillé. Si le bit est défini sur 0, l'emplacement est à l'ombre.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/27 (UTC).
[null,null,["Dernière mise à jour le 2025/08/27 (UTC)."],[[["\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)."]]
