Bildmanifest hochladen

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

  1. 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.
  2. Aktivieren Sie die Cloud Storage API und erstellen Sie einen Bucket.
  3. Installieren Sie den Earth Engine Python-Client. Es enthält das earthengine-Befehlszeilentool, das wir zum Hochladen von Daten verwenden.
  4. 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.

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.

  1. Maske für alle Datenbänder in der gleichen Datei.
  2. Maske für alle Datenbänder aus allen anderen Dateien.
  3. 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.