Wenn Sie beim Hochladen von Bildern in Google Earth Engine (EE) mehr Flexibilität als mit der Code-Editor-Benutzeroberfläche oder dem Befehl upload
des Befehlszeilentools „earthengine“ benötigen, können Sie einen Bildupload mithilfe einer JSON-Datei beschreiben, die als „Manifest“ bezeichnet wird, und den Befehl upload image --manifest
des Befehlszeilentools verwenden.
Ein vollständiges Beispiel für das Hochladen von Bildkacheln als einzelnes Asset mithilfe eines Manifests finden Sie in diesem Colab-Notebook.
Einmalige Einrichtung
- Manifest-Uploads funktionieren nur mit Dateien in Google Cloud Storage. Wenn Sie Google Cloud Storage verwenden möchten, erstellen Sie ein Google Cloud-Projekt, falls Sie noch keines haben. Für die Einrichtung muss eine Kreditkarte für die Abrechnung angegeben werden. EE selbst erhebt derzeit keine Gebühren. Die Übertragung von Dateien in Google Cloud Storage vor dem Hochladen in EE ist jedoch mit geringen Kosten verbunden. Bei typischen Uploaddatenmengen (z. B. zehn oder hunderte Gigabyte) sind die Kosten recht niedrig.
- Aktivieren Sie die Cloud Storage API und erstellen Sie einen Bucket.
- Installieren Sie den Earth Engine Python-Client. Es enthält das
earthengine
-Befehlszeilentool, das wir zum Hochladen von Daten verwenden. - Für automatisierte Uploads können Sie ein Google Cloud-Dienstkonto verwenden, das mit Ihrem Projekt verknüpft ist. Für die Tests benötigen Sie kein Dienstkonto. Machen Sie sich aber trotzdem mit der Verwendung vertraut.
Sehr große Quelldateien (100 GB oder mehr) können schneller hochgeladen werden, wenn sie in mehrere Kacheln aufgeteilt werden.
Asset-IDs und ‑Namen
Verwenden Sie für Assets, die zu einem Cloud-Projekt gehören, folgende Konvention für Asset-Namen:
projects/some-project-id/assets/some-asset-id
.
Informationen zu Asset-Namen für alte Projekte und von Nutzern erstellte Assets
Bei älteren Legacy-Projekten muss sich der Asset-Name im Manifest geringfügig von der Asset-ID unterscheiden, die an anderer Stelle in Earth Engine zu sehen ist. Wenn du Assets hochladen möchtest, deren Asset-IDs mit users/some_user
oder projects/some_project
beginnen, muss dem Asset-Namen im Manifest der String projects/earthengine-legacy/assets/
vorangestellt werden. Die EE-Asset-ID users/username/my_geotiff
sollte beispielsweise mit dem Namen projects/earthengine-legacy/assets/users/username/my_geotiff
hochgeladen werden.
Ja, das bedeutet, dass IDs wie projects/some_projects/some_asset
in Namen umgewandelt werden, in denen projects
zweimal vorkommt: projects/earthengine-legacy/assets/projects/some_projects/some_asset
.
Das ist verwirrend, aber notwendig, um den Google Cloud API-Standards zu entsprechen.
Manifeste verwenden
Unten sehen Sie das einfachste mögliche Manifest. Es lädt eine Datei namens small.tif
aus einem Google Cloud Storage-Bucket namens gs://earthengine-test
hoch.
{ "name": "projects/some-project-id/assets/some-asset-id", "tilesets": [ { "sources": [ { "uris": [ "gs://earthengine-test/small.tif" ] } ] } ] }
Speichern Sie es in einer Datei mit dem Namen manifest.json
und führen Sie folgenden Befehl aus:
earthengine upload image --manifest /path/to/manifest.json
Die Datei gs://earthengine-test/small.tif
ist vorhanden und öffentlich lesbar. Sie können sie zum Testen verwenden.
Kachelsätze
Die etwas komplizierte Manifeststruktur von JSON ist erforderlich, um genügend Flexibilität für eine häufige Upload-Herausforderung zu bieten: Wie können alle möglichen Kombinationen von Pixeln aus mehreren Quelldateien in einem einzelnen Asset beschrieben werden? Es gibt zwei unabhängige Möglichkeiten, Dateien zu gruppieren:
- Mosaike. Manchmal stehen mehrere Dateien für mehrere Kacheln (z. B. wenn jede Kachel ein Quadrat von 1 × 1 Grad ist). Solche Dateien müssen in einem EE-Asset in dasselbe Band zusammengesetzt (zusammengeführt) werden.
- Trennen Sie die Bänder. Manchmal stehen mehrere Dateien für mehrere Bänder. Solche Dateien müssen als Bänder in einem EE-Asset übereinandergeschichtet werden.
Möglicherweise müssen beide Methoden gleichzeitig verwendet werden, was aber selten vorkommt.
Zur Beschreibung dieser Optionen wird in Manifesten der Begriff tileset eingeführt. Ein einzelner Tileset entspricht einer einzelnen GDAL-Quelle. Aus diesem Grund müssen alle Quellen in einem einzelnen Tileset dieselbe GDAL-Struktur haben (Anzahl und Typ der Bänder, Projektion, Transformation, fehlender Wert). Da eine GDAL-Quelle mehrere Bänder haben kann, kann ein Tileset Daten für mehrere EE-Bänder enthalten.
Bei der Aufnahme von Mosaikdaten sieht das Manifest so aus:
{ "name": "projects/some-project-id/assets/some-asset-id", "tilesets": [ { "sources": [ { "uris": [ "gs://bucket/N30W22.tif" ] }, { "uris": [ "gs://bucket/N31W22.tif" ] } ] } ] }
Bei separaten Bändern sieht das Manifest so aus. Außerdem musst du einen bands
-Abschnitt hinzufügen, wie unten beschrieben:
{ "name": "projects/some-project-id/assets/some-asset-id", "bands": ..., "tilesets": [ { "id": "tileset_for_band1", "sources": [ { "uris": [ "gs://bucket/band1.tif" ] } ] }, { "id": "tileset_for_band2", "sources": [ { "uris": [ "gs://bucket/band2.tif" ] } ] } ] }
Bei separaten Bändern müssen wir jedem Tileset aus Gründen der Übersichtlichkeit eine eigene Tileset-ID zuweisen. Die tileset-ID kann ein beliebiger String sein. Diese Strings werden nicht im hochgeladenen Asset gespeichert. Die tileset-IDs werden nur bei der Datenaufnahme verwendet, um gestapelte tilesets voneinander zu unterscheiden.
Bänder
Das zweite wichtige Konzept ist die Zuordnung von Quelldateien zu EE-Asset-Bändern.
Dies geschieht über den Bereich bands
des Manifests.
Der Abschnitt bands
kann weggelassen werden. In diesem Fall werden die Bänder zuerst aus den Dateien im ersten Dataset, dann aus dem nächsten Dataset usw. erstellt.
Standardmäßig heißen die Bänder „b1“, „b2“ usw. Wenn Sie die Standardbänderamen überschreiben möchten, fügen Sie am Ende einen Abschnitt „bands“ hinzu, z. B. so:
{ "name": "projects/earthengine-legacy/assets/users/username/some_folder/some_id", "tilesets": [ { "sources": [ { "uris": [ "gs://bucket/rgb.tif" ] } ] } ], "bands": [ { "id": "R", "tilesetBandIndex": 0 }, { "id": "G", "tilesetBandIndex": 1 }, { "id": "B", "tilesetBandIndex": 2 } ] }
Die Anzahl der EE-Bänder muss mit der Gesamtzahl der Bänder in allen Datasets übereinstimmen.
Wenn Sie nicht alle Bänder aus einer Datei aufnehmen möchten, können Sie im Feld tilesetBandIndex
angeben, welche der GDAL-Bänder aufgenommen werden sollen.
Das erste Band hat den tilesetBandIndex 0.
Beispiel:
Angenommen, die Quelldatei hat vier Bänder: „tmin“, „tmin_error“, „tmax“ und „tmax_error“. Wir möchten nur „tmin“ und „tmax“ aufnehmen. Die relevanten Manifestabschnitte sehen so aus:
{ "name": "projects/earthengine-legacy/assets/users/username/some_folder/some_id", "tilesets": [ { "id": "temperature", "sources": [ { "uris": [ "gs://bucket/temperature.tif" ] } ] } ], "bands": [ { "id": "tmin", "tilesetBandIndex": 0, "tilesetId": "temperature" }, { "id": "tmax", "tilesetBandIndex": 2, "tilesetId": "temperature" } ] }
Maskenbänder
Die Bandmaskierung wird über die maskBands
-Komponente des Manifests gesteuert.
Es werden drei mögliche Maskenkonfigurationen unterstützt. Das Maskenband wird jedoch immer als letztes Band in einer bestimmten Datei angenommen.
- Maske für alle Datenbänder in der gleichen Datei.
- Maske für alle Datenbänder aus allen anderen Dateien.
- Datenbänder teilweise maskieren
1. Am häufigsten wird ein einzelnes GeoTIFF verwendet, dessen letztes Band als Maske für die anderen Bänder dient. Dies funktioniert nur für GeoTIFFs vom Typ „Byte“. Verwenden Sie das folgende Manifest:
{ "name": "projects/earthengine-legacy/assets/users/username/some_folder/some_id", "tilesets": [ { "id": "data_tileset", "sources": [ { "uris": [ "gs://bucket/data_file.tif" ] } ] } ], "bands": [ { "id": "data_band", "tilesetId": "data_tileset" }, { "id": "qa_band", "tilesetId": "data_tileset" } ], "maskBands": [ { "tilesetId": "data_tileset" } ] }
2. Wenn Sie eine GeoTIFF-Maske als Maske für alle Bänder in einem anderen GeoTIFF verwenden möchten, verwenden Sie das folgende Manifest:
{ "name": "projects/earthengine-legacy/assets/users/username/some_folder/some_id", "tilesets": [ { "id": "data_tileset", "sources": [ { "uris": [ "gs://bucket/data_file.tif" ] } ] }, { "id": "mask_tileset", "sources": [ { "uris": [ "gs://bucket/mask_file.tif" ] } ] } ], "bands": [ { "id": "data_band", "tilesetId": "data_tileset" }, { "id": "qa_band", "tilesetId": "data_tileset" } ], "maskBands": [ { "tilesetId": "mask_tileset" } ] }
3. Wenn Sie ein GeoTIFF als Maske für ein bestimmtes Band in einer anderen Datei verwenden möchten, verwenden Sie das folgende Manifest. Der Unterschied zum vorherigen Fall besteht darin, dass das Feld bandIds
in maskBands
festgelegt ist:
{ "name": "projects/earthengine-legacy/assets/users/username/some_folder/some_id", "tilesets": [ { "id": "data_tileset", "sources": [ { "uris": [ "gs://bucket/data_file.tif" ] } ] }, { "id": "mask_tileset", "sources": [ { "uris": [ "gs://bucket/mask_file.tif" ] } ] } ], "bands": [ { "id": "data_band", "tilesetId": "data_tileset" }, { "id": "qa_band", "tilesetId": "data_tileset" } ], "maskBands": [ { "tilesetId": "mask_tileset", "bandIds": ["data_band"] } ] }
Im letzten Beispiel arbeiten wir mit zwei Bändern aus dem data_tileset
-Satz, wenden aber nur auf eines der Bänder (data_band
) eine Maske an, wie im Feld bandIds
des einzigen bereitgestellten maskBands
-Listenobjekts angegeben.
Hinweis: Als Maskenband wird nur das letzte Band des in maskBands
genannten Datasets verwendet.
Richtlinie zu Pyramidensystemen
Wenn in Earth Engine während der Datenaufnahme Bildpyramiden erstellt werden, müssen Raster mit 2 × 2 Pixeln wiederholt auf ein einzelnes Pixel reduziert werden, wobei der Pixelwert auf eine bestimmte Weise umgewandelt wird. Standardmäßig werden die Pixelwerte gemittelt. Das ist in den meisten Fällen die richtige Vorgehensweise, wenn das Rasterband mehr oder weniger kontinuierliche Daten darstellt. Es gibt jedoch zwei Situationen, in denen die Verwendung des Standardwerts zu falschen Ergebnissen führt. In diesen Fällen muss das Feld pyramidingPolicy
in der Banddefinition festgelegt werden. Wenn dies nicht der Fall ist, wird standardmäßig der Wert „MITTELWERT“ angenommen.
Bei der Klassifizierung von Rasterbildern (z. B. für die Bodenbedeckungsklassifizierung) ist die sinnvollste Methode zur Pyramidenbildung von Pixeln, den Großteil der vier Werte zu verwenden, um den nächsten Wert zu generieren. Dies geschieht über die Pyramidierungsrichtlinie „MODE“:
{ "name": "projects/earthengine-legacy/assets/users/username/some_folder/some_id", "tilesets": [ { "sources": [ { "uris": [ "gs://bucket/landcover.tif" ] } ] } ], "bands": [ { "id": "landcover", "pyramidingPolicy": "MODE" } ] }
Für Rasterbänder, bei denen weder „MITTELWERT“ noch „MODUS“ sinnvoll sind (z. B. bitkomprimierte Pixel), sollte die Pyramidierungsrichtlinie „BEISPIEL“ verwendet werden. Bei „SAMPLE“ wird immer der Wert des oberen linken Pixels in jedem Raster mit 2 × 2 Pixeln verwendet. Im folgenden Beispiel wird die Pyramidierungsrichtlinie „MITTELWERT“ einem Band zugewiesen, das eine kontinuierliche Variable („NDVI“) darstellt, und „BEISPIEL“ dem QA-Band der Daten.
{ "name": "projects/earthengine-legacy/assets/users/username/some_folder/some_id", "tilesets": [ { "sources": [ { "uris": [ "gs://bucket/ndvi.tif" ] } ] } ], "bands": [ { "id": "NDVI", "tilesetBandIndex": 0, "pyramidingPolicy": "MEAN" }, { "id": "QA", "tilesetBandIndex": 1, "pyramidingPolicy": "SAMPLE" } ] }
Beginn und Ende
Für alle Assets sollten Start- und Endzeit angegeben werden, um den Daten mehr Kontext zu geben, insbesondere wenn sie in Sammlungen enthalten sind. Diese Felder sind nicht erforderlich, werden aber nach Möglichkeit empfohlen.
Start- und Endzeit beziehen sich in der Regel auf die Zeit der Beobachtung, nicht auf die Zeit, zu der die Quelldatei erstellt wurde.
Die Endzeit wird aus Gründen der Einfachheit als exklusive Grenze behandelt. Geben Sie beispielsweise für Assets, die genau einen Tag umfassen, als Start- und Endzeit die Mitternacht von zwei aufeinanderfolgenden Tagen an (z. B. 1980-01-31T00:00:00 und 1980-02-01T00:00:00). Wenn das Asset keine Dauer hat, muss die Endzeit mit der Startzeit übereinstimmen. Zeitangaben in Manifesten als ISO 8601-Strings darstellen. Wir empfehlen, davon auszugehen, dass die Endzeit exklusiv ist (z. B. Mitternacht des nächsten Tages für tägliche Assets), um die Datumswerte zu vereinfachen.
Beispiel:
{ "name": "projects/some-project-id/assets/some-asset-id", "tilesets": [ { "sources": [ { "uris": [ "gs://bucket/img_20190612.tif" ] } ] } ], "startTime": "1980-01-31T00:00:00Z", "endTime": "1980-02-01T00:00:00Z" }
Referenz zum Aufbau eines Manifests
Die folgende JSON-Struktur enthält alle möglichen Manifestfelder für den Bildupload. Felddefinitionen finden Sie im folgenden Abschnitt Manifest-Felddefinitionen.
{ "name": <string>, "tilesets": [ { "dataType": <string>, "id": <string>, "crs": <string>, "sources": [ { "uris": [ <string> ], "affineTransform": { "scaleX": <double>, "shearX": <double>, "translateX": <double>, "shearY": <double>, "scaleY": <double>, "translateY": <double> } } ] } ], "bands": [ { "id": <string>, "tilesetId": <string>, "tilesetBandIndex": <int32>, "missingData": { "values": [<double>] }, "pyramindingPolicy": <string> } ], "maskBands": [ { "tilesetId": <string>, "bandIds": [ <string> ] } ], "footprint": { "points": [ { "x": <double>, "y": <double> } ], "bandId": <string> }, "missingData": { "values": [<double>] }, "pyramidingPolicy": <string>, "uriPrefix": <string>, "startTime": { "seconds": <integer> }, "endTime": { "seconds": <integer> }, "properties": { <unspecified> } }
Manifestfelddefinitionen
name
string
Der Name des zu erstellenden Assets.
name
hat das Format „projects/*/assets/**“ (z. B. „projects/earthengine-legacy/assets/users/USER/ASSET“).
Tilesets
list
Eine Liste von Wörterbüchern, die Eigenschaften für Ansichtensätze definieren.
Weitere Informationen finden Sie in den folgenden Feldern des tilesets
-Wörterbuchelements.
tilesets[i].dataType
string
Gibt den numerischen Datentyp der Daten an. Der Standard ist der von GDAL gemeldete Typ. In diesem Fall muss er nicht definiert werden.
Datentyp | Wert |
---|---|
Ohne Angabe | „DATA_TYPE_UNSPECIFIED“ |
Vorzeichenbehaftete 8-Bit-Ganzzahl | „INT8“ |
Vorzeichenlose 8-Bit-Ganzzahl | „UINT8“ |
Vorzeichenbehaftete 16-Bit-Ganzzahl | "INT16" |
Vorzeichenlose 16-Bit-Ganzzahl | „UINT16“ |
Vorzeichenbehaftete 32-Bit-Ganzzahl | „INT32“ |
Vorzeichenlose 32-Bit-Ganzzahl | „UINT32“ |
32-Bit-Gleitkommazahl | „FLOAT32“ |
64-Bit-Gleitkommazahl | „FLOAT64“ |
tilesets[i].id
string
Die ID des Tilesets. Muss unter den im Asset-Manifest angegebenen Datasets eindeutig sein. Diese ID wird während des Verarbeitungsschritts verworfen. Sie wird nur verwendet, um einen Tileset mit einem Band zu verknüpfen. Der leere String ist eine gültige ID.
tilesets[i].crs
string
Das Koordinatenreferenzsystem des Pixelrasters, nach Möglichkeit als Standardcode (z. B. EPSG-Code) und andernfalls im WKT-Format angegeben.
tilesets[i].sources
list
Eine Liste von Wörterbüchern, die die Eigenschaften einer Bilddatei und ihrer Sidecars definieren. Weitere Informationen finden Sie in den folgenden Feldern des sources
-Wörterbuchelements.
tilesets[i].sources[j].uris
list
Eine Liste der URIs der Daten, die aufgenommen werden sollen. Derzeit werden nur Google Cloud Storage-URIs unterstützt. Jeder URI muss im folgenden Format angegeben werden:
gs://bucket-id/object-id
.
Das Hauptobjekt sollte das erste Element der Liste sein und Sidecars sollten danach aufgeführt werden. Jedem URI wird ImageManifest.uriPrefix
vorangestellt, wenn diese Option festgelegt ist.
tilesets[i].sources[j].affineTransform
dictionary
Eine optionale affine Transformation. Sollte nur angegeben werden, wenn die Daten aus uris
(einschließlich Sidecars) nicht ausreichen, um die Pixel zu platzieren.
Wird als Wörterbuch mit den folgenden Schlüsseln bereitgestellt:
„scaleX“, „shearX“, „translateX“, „shearY“, „scaleY“, „translateY“.
Weitere Informationen finden Sie
in diesem Artikel.
Beispielschlüssel und ‑werte:
{ "scaleX": 0.1, "shearX": 0.0, "translateX": -180.0, "shearY": 0.0, "scaleY": -0.1, "translateY": 90.0 }
Bänder
list
Eine Liste von Wörterbüchern, die die Eigenschaften eines einzelnen Layers aus einem Dataset definieren.
Die Bandreihenfolge des Assets stimmt mit der Reihenfolge von bands
überein.
Weitere Informationen finden Sie in den folgenden Feldern des bands
-Wörterbuchelements.
bands[i].id
string
Die ID (Name) der Band.
bands[i].tilesetId
string
Die ID des Rasterbildsatzes, der der Band entspricht.
bands[i].tilesetBandIndex
int32
Der nullbasierte Bandindex aus dem Dataset, der dem Band entspricht.
bands[i].missingData.values
list
Eine Liste von Werten vom Typ „Doppelt“, die keine Daten im Band darstellen.
bands[i].pyramidingPolicy
string
Die Richtlinie zu Pyramidensystemen. Weitere Informationen finden Sie unter diesem Link. Zu den Optionen gehören:
- „MITTELWERT“ (Standard)
- „MODUS“
- „SAMPLE“
maskBands
list
Eine Liste von Wörterbüchern, die die Eigenschaften eines einzelnen Maskenbands aus einem Dataset definieren.
Derzeit kann maximal ein Maskenband angegeben werden.
Weitere Informationen finden Sie in den folgenden Feldern des maskBands
-Wörterbuchelements.
maskBands[i].tilesetId
string
Die ID des Rasterbildsatzes, die dem Maskenband entspricht. Das letzte Band des Datasets wird immer als Maskenband verwendet.
maskBands[i].bandIds
list of strings
Liste der IDs der Bänder, auf die das Maskenband angewendet wird. Wenn das Feld leer ist, wird das Maskierungsband auf alle Bänder im Asset angewendet. Jedes Band darf nur ein entsprechendes Maskenband haben.
digitaler Fußabdruck
dictionary
Ein Dictionary, das die Eigenschaften des Footprints aller gültigen Pixel in einem Bild definiert.
Wenn das Feld leer ist, entspricht der Standard-Footprint dem gesamten Bild. Weitere Informationen finden Sie in den folgenden Feldern des footprint
-Wörterbuchelements.
footprint.points
list
Eine Liste von Punkten, die den Footprint aller gültigen Pixel in einem Bild definieren. Ein Punkt wird durch ein Wörterbuch mit den Schlüsseln „x“ und „y“ mit Gleitkommawerten definiert. Eine Liste von Punkten beschreibt einen Ring, der die Außenseite eines einfachen Polygons bildet, das die Mittelpunkte aller gültigen Pixel des Bildes enthalten muss. Dies muss ein linearer Ring sein: Der letzte Punkt muss mit dem ersten identisch sein. Die Koordinaten sind in der Projektion des durch bandId
angegebenen Bandes.
Hinweis: Verwenden Sie nicht ganzzahlige Koordinaten wie den Mittelpunkt jedes Pixels, da footprint
ein Pixel enthält, wenn das Pixel (ein Rechteck mit einer Größe von 1 × 1) den Footprint schneidet. Verwenden Sie keine Koordinaten mit Ganzzahlwerten, um versehentlich benachbarte Pixel auszuwählen, da dies die Grenzen zwischen Pixeln sind. Wenn Sie den Fußabdruck entlang der Pixelzentren zeichnen, werden unbeabsichtigte Pixel ausgeschlossen, die zu Fehlern führen können, wenn beabsichtigte Pixel an eine Kartengrenze wie den Antimeridian oder einen Pol angrenzen.
Für ein 2 × 2 Pixel großes Bild mit allen vier gültigen Pixeln ist beispielsweise Folgendes ein möglicher Ring:
[ { "x": 0.5, "y": 0.5 }, { "x": 0.5, "y": 1.5 }, { "x": 1.5, "y": 1.5 }, { "x": 1.5, "y": 0.5 }, { "x": 0.5, "y": 0.5 } ]
footprint.bandId
string
Die ID der Band, deren CRS die Koordinaten des Fußabdrucks definiert. Wenn leer, wird das erste Band verwendet.
missingData.values
list
Eine Liste von Werten vom Typ „Doppelt“, die in allen Bändern des Bilds keine Daten darstellen. Gilt für alle Bänder, für die keine eigene missingData
angegeben ist.
pyramidingPolicy
string
Die Richtlinie zu Pyramidensystemen. Wenn keine Angabe erfolgt, wird standardmäßig die Richtlinie „MITTELWERT“ angewendet. Gilt für alle Bänder, für die keine eigene angegeben ist. Weitere Informationen finden Sie unter diesem Link. Zu den Optionen gehören:
- „MITTELWERT“ (Standard)
- „MODUS“
- „SAMPLE“
uriPrefix
string
Ein optionales Präfix, das allen im Manifest definierten uris
vorangestellt wird.
startTime
integer
Der Zeitstempel, der mit dem Asset verknüpft ist (falls vorhanden). Dieser entspricht in der Regel der Zeit, zu der ein Satellitenbild aufgenommen wurde. Bei Assets, die einem bestimmten Zeitraum entsprechen, z. B. Durchschnittswerten über einen Monat oder ein Jahr, entspricht dieser Zeitstempel dem Beginn dieses Zeitraums. Wird in Sekunden und (optional) Nanosekunden seit der Epoche (1970-01-01) angegeben. Es wird davon ausgegangen, dass sich die Zeitzone in UTC befindet.
endTime
integer
Bei Assets, die einem bestimmten Zeitraum entsprechen, z. B. Durchschnittswerten über einen Monat oder ein Jahr, entspricht dieser Zeitstempel dem Ende dieses Zeitraums (exklusiv). Wird in Sekunden und (optional) Nanosekunden seit der Epoche (1970-01-01) angegeben. Es wird davon ausgegangen, dass sich die Zeitzone in UTC befindet.
Properties
dictionary
Ein beliebiges flaches Dictionary mit Schlüssel/Wert-Paaren. Schlüssel müssen Strings sein und Werte können entweder Zahlen oder Strings sein. Listenwerte werden für von Nutzern hochgeladene Assets noch nicht unterstützt.
Beschränkungen
Größe des JSON-Manifests
Die maximal zulässige Dateigröße für JSON-Manifestdateien beträgt 10 MB. Wenn Sie viele Dateien hochladen möchten, sollten Sie überlegen, wie Sie die Anzahl der Zeichen für die Beschreibung des Datensatzes reduzieren können. Mit dem Feld uriPrefix
müssen Sie beispielsweise nicht für jeden URI in der Liste uris
den GCP-Bucket-Pfad angeben. Wenn eine weitere Größenreduzierung erforderlich ist, kürzen Sie die Dateinamen.