Apache Hop Vector Raster Plugin – Benutzerhandbuch

Eine Hop-Zeile enthält benannte, typisierte Felder, beispielsweise eine Nummer, einen Namen und eine Geometrie. Der Vector Reader erzeugt pro Feature eine Zeile. Die Geometrie liegt als gemeinsamer Hop-Typ Geometry vor, nicht als WKT-Text. Das separate Geometry-Type-Plugin stellt diesen Typ bereit.

Der Vector Writer ist ein Senken-Transform: Er schreibt die eingehenden Zeilen und gibt keine Ergebniszeilen aus. Raster Reader erzeugt einen typisierten Rasterwert, standardmässig im Feld raster. Ohne vorgelagerten Transform liefert er eine Zeile, mit Eingaben ergänzt er jede Zeile. Clip und Reproject ersetzen das Rasterfeld oder ergänzen ein neues; sie schreiben keine Datei. Erst Raster Writer ergänzt beim Schreiben <prefix>output_file und <prefix>status. ZonalStats ergänzt pro Polygonzeile die gewünschten Kennzahlen. Rasterpixel werden nicht einzeln als Hop-Zeilen transportiert.

${PROJECT_HOME}/data/terrain.tif ist ein Beispiel für einen konstanten Pfad mit Hop-Variable. Die Variable wird beim Ausführen aufgelöst. Ein Eingabefeld, etwa raster_url, wird bei den Raster-Transforms über das zugehörige Kontrollkästchen ausgewählt. Ohne dieses Kästchen wird der Text als konstanter Wert interpretiert.

Raster Reader bindet den Quellpfad über source Field an eine Eingabespalte; Raster Writer bindet den Ausgabepfad über output Field. Clip und Reproject lesen mit bbox Fields alle vier Bounding-Box-Werte aus Spalten. Reproject bietet zusätzlich target Crs Field und resolution Fields für Ziel-CRS und beide Pixelgrössen. Raster- und Geometriefelder bezeichnen immer Spalten und benötigen keine zusätzliche Checkbox. Die Beschriftungen entsprechen der GUI; in HPL-Dateien heissen die Eigenschaften beispielsweise sourceField, outputField, bboxFields, targetCrsField und resolutionFields. NoData- und Präfix-Einstellungen akzeptieren Hop-Variablen, keine impliziten Feldreferenzen. Vector Reader/Writer verwenden konfigurierte Dateipfade mit Variablen, keine Dateiauswahl pro Eingabezeile.

Die ASCII-Ansichten zeigen schematische Dialoge mit generischen Beispielwerten. <leer> bedeutet ein leeres Eingabefeld, [ Wert v ] ein Auswahlfeld; [ ] und [x] kennzeichnen ausgeschaltete beziehungsweise eingeschaltete Checkboxen. (deaktiviert) bedeutet sichtbar, aber nicht editierbar. Das v ersetzt den Auswahlpfeil. Pfade, Transformnamen und ausgefüllte Beispielwerte sind keine Vorgaben; Defaults werden bei den Einstellungen erklärt. Öffnen Sie die Eigenschaften des jeweiligen Transforms in Hop GUI. OK übernimmt die Konfiguration, Cancel verwirft die Dialogänderungen. Lange Skizzen können im Handbuch horizontal gescrollt werden.

Ein CRS beschreibt, wie Koordinaten zu interpretieren sind. EPSG:2056 bezeichnet Schweizer LV95-Koordinaten in Metern. EPSG:4326 verwendet geografische Winkel; Raster-Pixelgrössen werden dort in Grad angegeben. Die Raster-Transforms verwenden XY beziehungsweise Longitude/Latitude.

Eine Geometry kann eine numerische SRID tragen. Clip und Zonal Statistics verwenden eine explizite Geometrie-CRS-Angabe, falls vorhanden; sonst benötigen sie eine SRID ungleich null. Die Eingabegeometrie bleibt unverändert.

NoData kennzeichnet fehlende Messwerte. Null ist gültig, sofern sie nicht ausdrücklich als NoData deklariert wurde. Maskierte und nichtendliche Werte werden bei der Rasterauswertung ausgeschlossen. Ein NoData-Override ersetzt den deklarierten Sentinel. Details zu Interpolation und Ausgabe stehen in den Raster-Kapiteln.

Rohwerte können eine bandweise Skalierung besitzen: physikalischer Wert = Rohwert × scale + offset. Statistiken verwenden physikalische Werte. Clip und Reproject verarbeiten Rohwerte und erhalten Scale/Offset; erst der Writer schreibt die Datei.

Raster werden als typisierte Werte weitergegeben: Raster Reader → Raster Clip → Raster Reproject → Raster Writer. Installieren Sie zusätzlich das passende Raster-Type-ZIP. Clip und Reproject erzeugen keine Zwischendateien; bestehende dateibasierte Raster-Pipelines müssen migriert werden.

Das Plugin-ZIP enthält seine Rasterbibliotheken sowie SQLite JDBC. Das Geometry-Type-Plugin stellt den Geometry-Datentyp und die gemeinsame GeoTools-/Imagen-Runtime direkt für den gemeinsamen Classloader sogeo-geometry bereit. Vector/Raster wiederholt dessen Ordner nicht in dependencies.xml, damit dieselben Imagen-Ressourcen nicht über relative Pfad-Aliase doppelt geladen werden; dort stehen nur die Raster-Type-Ordner. Das Vector/Raster-ZIP enthält keine eigenen Geometry-/JTS-Kopien. Bei Updates den gesamten Vector/Raster-Ordner ersetzen. Es werden weder GDAL noch eine Hadoop-Installation benötigt.

Kopieren Sie keine zusätzlichen JTS- oder Geometry-JARs manuell in andere Plugin-Verzeichnisse; verwenden Sie die mitgelieferten ZIPs. Fehlende Transforms oder Fehler beim Laden von Geometry beziehungsweise Raster deuten oft auf eine unvollständige oder doppelte Installation hin.

Unter Geospatial stehen diese Transforms zur Verfügung:

Die Pipeline speichert die Plugin-ID im type-Element des Transforms. Bei einem unbekannten Transform prüfen Sie diese ID und die Installation.

Die alten IDs SOGIS_RASTER_CLIP, SOGIS_RASTER_REPROJECT und SOGIS_RASTER_ZONAL_STATS bezeichnen nur Legacy-Transforms. Sie melden einen Migrationsfehler; die neue Verarbeitung verwendet Rasterwerte. Die Migrationsanleitung beschreibt den Umstieg.

Build und lokale Installation sind in der Entwickleranleitung beschrieben. Bauen und installieren Sie zuerst die Maven-Artefakte des Raster-Type-Repositories und entpacken Sie dessen passendes ZIP in Hop. Das Skript scripts/dev-sync-hop-plugin.sh baut und installiert danach Geometry Type und Vector/Raster und startet Hop GUI neu; Raster Type bereitet es nicht selbst vor. Für die normale Benutzung genügt die Installation der Release-ZIPs.

Raster Type stellt den gemeinsamen Raster-Datentyp bereit. Seine Klassen werden nur einmal installiert; Vector/Raster bringt den GeoTools-Adapter und die Raster-Transforms mit. Für bisherige Dateikonfigurationen ist die Migration auf Reader → Operation → Writer erforderlich.

Die schematische Ansicht zeigt eine ausgefüllte Beispielkonfiguration; siehe Dialoglegende. Ein leeres Eingabefeld übernimmt nur dort eine Vorgabe, wo dies in der Einstellungstabelle beschrieben ist.

Die Ansicht verwendet den beispielhaften Layer buildings mit Attribut name und Geometriespalte geometry. Feldlängen und Präzision hängen von der Quelldatei ab. Für die Ordnerauswahl einer FileGDB wählen Sie ausdrücklich FILEGEODATABASE; der Button lautet dann Browse folder…​. Bei AUTO bleibt der normale Dateiauswahldialog erhalten.

Die Layerliste wird aus der ausgewählten Datei gelesen. Die schreibgeschützte Schemapreview zeigt Attribute, Geometriespalte, Geometrietyp, Dimension und CRS, soweit verfügbar. Ändern Sie Layer oder Datei, kontrollieren Sie die Vorschau vor dem Ausführen erneut. Eine noch nicht auflösbare Variable oder ein Probe-Fehler wird im Dialog angezeigt; das tatsächliche Lesen kann erst mit einem gültigen Pfad gelingen.

Für Shapefiles bestimmt das Feld DBF encoding (empty: auto) die Zeichenkodierung der DBF-Attribute. Der Reader verwendet zuerst eine explizite Eingabe, andernfalls die CPG-Datei und danach eine erkannte DBF-Codepage (LDID). Fehlen diese Angaben, verwendet er ISO-8859-1 und meldet encoding-fallback. Es gibt keine automatische Erkennung anhand der Textbytes.

Gültige Eingaben sind beispielsweise UTF-8, ISO-8859-1, Latin1 und windows-1252. Latin1 ist ein Alias für ISO-8859-1; die Schreibweise Latin-1 wird dagegen nicht akzeptiert. Wählen Sie die tatsächliche Kodierung der Quelldatei: UTF-8-Daten erscheinen mit ISO-8859-1 beispielsweise als Gewässer, mit UTF-8 korrekt als Gewässer. Tragen Sie in diesem Fall UTF-8 ein, übernehmen Sie die Einstellung mit OK und führen Sie die Pipeline erneut aus.

Jede Änderung im Encoding-Feld löst sofort eine neue Schema-Abfrage aus, auch während des Tippens. Bei einem unbekannten Encoding-Namen leert der Dialog die Layer-Auswahl und zeigt No schema information available. sowie den nicht erkannten Namen, beispielsweise Latin-1. Die Meldung bedeutet in diesem Fall, dass die Zeichenkodierung nicht unterstützt wird. Nach Eingabe eines gültigen Namens wird das Schema erneut geladen. Eine erfolgreiche Schema-Abfrage bestätigt jedoch nicht, dass die Textwerte mit dieser Kodierung korrekt dargestellt werden; kontrollieren Sie dazu die gelesenen Zeilen.

Feature-Layer liefern die typisierten Attribute und die Geometry-Spalte. FileGDB-Attributtabellen können auch ohne Geometriespalte gelesen werden. GeoPackage-Geometrie steht am Ende der Zeile. Ein Geometry-Ausgabename darf nicht mit einem Attribut kollidieren. Die Quelldatei bleibt unverändert; der Reader legt keine räumlichen Indizes an.

Die Auswahl der Zeichenkodierung ist unter DBF-Zeichenkodierung beschrieben. Fehlende PRJ bedeutet unbekanntes CRS mit Warnung; tragen Sie nur dann einen Override ein, wenn Sie das tatsächliche Koordinatensystem kennen. Fehlerhafte Kodierung, widersprüchliche Dateikomponenten oder ungültige Geometrieheader führen zum Fehler. Vektor-I/O meldet solche technischen Fehler als fehlgeschlagenen Transform; die Raster-Error-Hop-Regeln gelten hier nicht automatisch.

Die vollständigen Regeln für Attribute, Kurven, NULL/EMPTY und Dimensionen stehen unter Formate. FlatGeobuf, Parquet, GENERATE und Rasterdateien sind keine Reader-Eingabeformate.

Verbinden Sie den Reader mit einem Vorschau- oder Verarbeitungs-Transform. Überprüfen Sie, dass geometry ein echtes Geometry-Feld ist und seine SRID zum Layer passt.

Die schematische Ansicht zeigt eine ausgefüllte Beispielkonfiguration; siehe Dialoglegende. Ein leeres Eingabefeld übernimmt nur dort eine Vorgabe, wo dies in der Einstellungstabelle beschrieben ist. Das Feld Layer (optional) ist ein freies Eingabefeld mit Variablenunterstützung. Vorhandene GeoPackage-Layer und FileGDB-Datasets werden in der Vorschau angezeigt, aber nicht automatisch als Auswahl in dieses Feld übernommen.

Die dargestellte Konfiguration schreibt Parzellen als indiziertes FlatGeobuf. Die Wahl unter Format steuert die sichtbaren Formatoptionen.

Für leere oder ausschliesslich NULL-haltige Shapefile-/FlatGeobuf-/Parquet-Ausgaben geben Sie Typ und Dimension explizit an. Bei AUTO werden maximal 10'000 anfängliche NULL/EMPTY-Zeilen bis zur Schemaableitung gepuffert. Alle weiteren Geometrien müssen zum festgelegten Schema passen. GeoPackage hat eine eigene XY-Inferenz und kann reine NULL-Streams nicht ableiten.

Wählen oder entfernen Sie Attribute vor dem Writer mit üblichen Hop-Transforms. Eine zweite Geometry-Spalte und komplexe Werte müssen vor der Ausgabe auf ein unterstütztes Format abgebildet werden.

Get fields übernimmt die eingehenden Felder in die DBF-Zuordnung. Die Tabelle DBF fields (double-click to edit) bietet Quellname, Zielname, Bytebreite und Dezimalstellen. -1 verwendet die abgeleiteten Einstellungen. Preview DBF schema zeigt die tatsächlich resultierenden Namen und Breiten. Remove selected mapping entfernt die explizite Zuordnung; das Attribut wird dadurch wieder automatisch konfiguriert, nicht aus der Ausgabe entfernt.

Namenskürzung, Zeichenersetzung, Textkürzung, Rundung und Dimensionsregeln sind unter Shapefile erklärt.

Ohne Index bleibt die Eingabereihenfolge erhalten. Die Formatbeschreibung erläutert Attribute und Speicher-/Platzbedarf.

Es entsteht natives räumliches Parquet, kein GeoParquet-Metadatendokument.

Geography interpolation bleibt bei GEOMETRY sichtbar, ist aber deaktiviert. Erst die Auswahl GEOGRAPHY aktiviert das Feld.

Nur einfache Point-, LineString- und Polygon-Geometrien ohne Löcher werden akzeptiert. Die sechs Ausgabedialekte und Einschränkungen stehen unter GENERATE.

Wählen Sie GEOPACKAGE im Hauptdialog. Der folgende Ausschnitt zeigt die Formatoptionen mit den Vorgaben für eine neue Datei; die gemeinsamen Felder stehen darüber.

Layer laden zeigt vorhandene Layer und bei Append das Zielschema in der Vorschau. Eingangsschema prüfen vergleicht die Eingabefelder mit dem Append-Ziel. Tragen Sie den gewünschten Layer selbst in Layer (optional) ein; die Vorschau füllt das Feld nicht aus. Die Formatbeschreibung erläutert Transaktionen, Indexpflege und Schemaeinschränkungen.

Wählen Sie FILEGEODATABASE. Der Ausschnitt zeigt die Vorgaben für eine neue GDB.

Neue Transforms verwenden AUTO für CRS-abhängige Präzisionsvorgaben. Alte HPLs ohne diese Einstellung behalten LEGACY. Leere XY-Felder übernehmen die Vorgaben des gewählten Modus. Ein JSON-Schema überschreibt die Schema-/XY-Einstellungen. Für mehrere Datasets oder Beziehungen verwenden Sie den separaten FileGDB Writer. Datasets laden zeigt vorhandene Datasets; Eingangsschema prüfen prüft das Append-Ziel. Die Formatbeschreibung erläutert Präzision, Domains und Einschränkungen.

Verwenden Sie einen eindeutigen Zielpfad pro Writer und genau eine Transform-Kopie. Die Ausgabe wird erst nach erfolgreichem EOF veröffentlicht. Ein Abbruch soll keine teilweise geschriebene Zieldatei hinterlassen; Details unterscheiden sich nach Format. Fehler bei Schema, Geometrie, CRS, Kodierung oder Dateikonflikten stoppen den Writer.

Ein explizites Multipart-Schema akzeptiert auch die entsprechende einfache Geometrie. Für dieses Beispiel müssen Quelle und Ziel dasselbe CRS besitzen; der Writer rechnet Koordinaten nicht um.

Plugin-ID: SOGIS_RASTER_READER.

Raster Reader erzeugt einen typisierten Hop-Rasterwert aus einer lokalen GeoTIFF-Datei oder einer öffentlichen HTTP/HTTPS-COG-Adresse. Ohne Eingabe erzeugt er eine Zeile; mit Eingabe ergänzt er jede Zeile um das Rasterfeld. source Field (sourceField in HPL) bezieht die Adresse aus einer Spalte. Der Quellpfad ist anfangs leer, die Checkbox ausgeschaltet. Reader liest Metadaten, keine vollständigen Pixelbestände. Standard-Rasterfeld: raster.

Raster Clip (SOGIS_RASTER_VALUE_CLIP) liest dieses Rasterfeld. Das leere Ausgabefeld ersetzt die Eingabe; ein anderer Name ergänzt einen zweiten Rasterwert. Andere Attribute bleiben erhalten. Er schreibt keine Datei.

Alle Boxfelder bleiben auch bei POLYGON sichtbar. Bei BOUNDING_BOX geben Sie die vier Grenzen und das CRS in explicit Crs ein; bbox Fields bindet die Grenzen stattdessen an Eingabespalten. Die Grenzen und das explizite CRS sind anfangs leer, bbox Fields ist ausgeschaltet. Bei POLYGON wird geometry Field verwendet; dessen SRID genügt, wenn kein explizites CRS gesetzt ist.

Die Box wird vor dem Zuschnitt ins Raster-CRS transformiert und auf die überlappenden Quellpixel beschränkt. Polygonmasken verwenden Pixelzentren inklusive Rand, berücksichtigen Löcher und MultiPolygone. Ungültige/gekrümmte Geometrien müssen vorgelagert behandelt werden. Leere und vollständig disjunkte Clips sind Fehler. RGB/RGBA bleibt bei vollständiger Bandauswahl Farbe; Polygonmasken verwenden Alpha. Teilmengen werden gegebenenfalls numerisch. Paletten bleiben bei Zuschnitt erhalten; Polygonmasken benötigen einen gültigen NoData-Palettenindex.

Raster Info (SOGIS_RASTER_INFO) ergänzt ausgewählte Felder width height crs bands mit einem Präfix. Breite/Höhe sind Integer, CRS ist WKT, Bänder sind ein JSON-String. Dabei werden keine Pixel berechnet. Die Skizze zeigt die Defaults; mit dem Präfix raster_ entstehen raster_width, raster_height, raster_crs und raster_bands. Bereits vorhandene gleichnamige Felder sind Fehler.

Raster Writer (SOGIS_RASTER_WRITER) schreibt einen Rasterwert als lokale GeoTIFF-Datei und ergänzt <prefix>output_file sowie <prefix>status = OK. Standardpräfix: raster_. Der Ausgabepfad ist anfangs leer. output Field liest ihn aus einer Eingabespalte; overwrite erlaubt das Ersetzen vorhandener Ziele. Beide Checkboxen sind standardmässig ausgeschaltet. Quellen dürfen auch über Dateisystemaliasse nicht überschrieben werden. Alle Eingabeattribute bleiben erhalten; Namenskollisionen mit den Ergebnisfeldern sind Fehler. Verwenden Sie pro Ausgabeauftrag einen geeigneten Zielpfad. Ausgabe: DEFLATE, 512 × 512 Pixel grosse Tiles, ab geschätzten 2 GiB Rohdaten BigTIFF; keine zugesicherte COG-Erzeugung. Das Elternverzeichnis muss existieren. Fehler/Abbruch entfernen die temporäre Nachbardatei und erhalten ein bestehendes Ziel.

Pixel werden erst von Writer oder Statistik angefordert. Pixel-Lesefehler erreichen deren konfigurierten Error Hop; ohne Fehlerbehandlung bricht der Lauf ab. Fehlermeldungen enthalten Quelle und Operationskontext. Konfigurationsfehler werden bereits bei der jeweiligen Operation erkannt.

Raster Reader akzeptiert direkte öffentliche COG-URLs. Server und Proxy müssen gültige Byte-Range-Antworten mit HTTP 206 und passendem Content-Range liefern. Ein Server, der stattdessen die vollständige Datei liefert, wird abgelehnt; es gibt keinen Voll-Download-Fallback. Der Reader-Dialog bietet keine Konfiguration für Zugangsdaten oder eigene HTTP-Header.

Die alten Datei-Transforms benötigen eine Migration:

Das Skript erhält die alte Pipeline und schreibt eine neue. Für Clip/Reproject ergänzt es Reader, Operation und Writer; für Statistik einen Reader vor der Operation. Die alte Clip-Einzelbandauswahl wird als bands übernommen. Ein zusätzlicher Select-Values-Schritt entfernt das Hilfs-Rasterfeld aus den Ergebniszeilen; konfigurierte Error Hops erhalten ebenfalls passende Bereinigung. Für direkte Rasterwertketten können Zwischen-Writer und die zugehörige Bereinigung entfernt werden. Verbinden Sie dann die Operationen über dasselbe Rasterfeld und entfernen Sie es erst nach dem letzten Verbraucher. Ein Beispiel ohne Zwischendateien steht zum Download bereit.

Die Ansicht folgt der Dialoglegende. Die Auflösung 2 ist ein Beispiel für Meterkoordinaten; beide Auflösungsfelder sind anfangs leer und müssen gesetzt werden. Der Dialogtitel lautet Raster REPROJECT (GeoTools).

target Crs Field, resolution Fields und bbox Fields sind standardmässig ausgeschaltet. Sie binden Ziel-CRS, beide Auflösungen beziehungsweise alle vier Grenzen an Eingabespalten. Boxfelder bleiben auch bei AUTO sichtbar; ausgewertet werden sie nur bei BOUNDING_BOX. Explizite Grenzen liegen im Ziel-CRS. Ausgabefeld, Ziel-CRS, Grenzen und NoData-Overrides sind anfangs leer.

Das Zielraster ist nordorientiert. Zellgrenzen liegen auf ganzzahligen Vielfachen der Pixelgrössen, bezogen auf den Ursprung des Ziel-CRS. Die Ausdehnung wird nach aussen gerundet, pro Seite um weniger als ein Pixel. Gleiche CRS- und Auflösungseinstellungen erzeugen deckungsgleiche Zellgrenzen. Es gibt keine automatische Pixelgrössenwahl und keine Übernahme eines Referenzrasters.

AUTO transformiert die tatsächlichen äusseren Pixelkanten der Quelle mit 256 Segmenten pro Kante, auch bei gedrehten Quellrastern. Mehrdeutige Grenzen, Longitude-Wraparound, fehlendes CRS und Transformationsfehler werden abgelehnt. Ein vollständig disjunkter expliziter Ausschnitt ist ein Fehler. Bei teilweiser Überlappung bleibt die Zielbox vollständig bestehen; ausserhalb der Quelle entstehen NoData beziehungsweise transparente Pixel. Ein überlappender NoData-only-Bereich darf erfolgreich geschrieben werden.

NEAREST wählt den nächsten Quellwert und eignet sich für Klassenwerte. BILINEAR interpoliert kontinuierliche Werte aus bis zu vier Nachbarn. Ungültige Nachbarn werden ausgeschlossen und die Gewichte der gültigen Beiträge neu normiert. Ohne gültigen Beitrag entsteht NoData. Das ist keine flächenbasierte Mittelung aller Pixel beim Vergröbern.

AUTO erhält bei Nearest den Quelltyp, bei Bilinear entsteht Float64. SOURCE mit Integer-Werten rundet zum nächsten Integer, bei exakt halben Werten zur geraden Zahl. Überlauf führt zum Fehler. Rohwerte werden interpoliert; bandweises Scale/Offset bleibt erhalten. Reihenfolge und Anzahl numerischer Bänder bleiben unverändert.

NoData, Masken und nichtendliche Werte gehen nicht als Messwerte ein; Null bleibt gültig. Der Ausgabe-Sentinel muss genau im Ausgabetyp darstellbar sein. Integer-Ausgabe ohne geerbten Sentinel erfordert eine Angabe. Ein gültiger Ergebniswert, der mit dem Sentinel kollidiert, ist ein Fehler. Der Ausgabe-TIFF-Sentinel ist gemeinsam; die Gültigkeit der Quellbänder wird unabhängig beurteilt.

Die TIFF-Farbinterpretation entscheidet, ob Daten als Farben oder Messwerte gelten. Drei Bänder allein bedeuten nicht RGB. Numerische Typoptionen verändern keine Farbraster. RGB und Grau mit Alpha behalten Byte/UInt16 beziehungsweise ihren Float-Typ; Float-Farbe und Float-Alpha verwenden 0–1. RGB-Ausgabe enthält ein nicht vormultipliziertes Alphaband, Grau mit Alpha bleibt zweibandig.

Die Interpolation erfolgt in der gespeicherten Farbkodierung, ohne zusätzliche Farbraumkonvertierung.

Reproject gibt einen abgeleiteten Rasterwert weiter. Erst Raster Writer materialisiert ihn als GeoTIFF und ergänzt Dateipfad und Status. Ein neues Raster-Ausgabefeld darf nicht mit einem vorhandenen Feld kollidieren. Pixel-Lesefehler treten beim Verbraucher auf; Planungs- und Konfigurationsfehler können bereits Reproject betreffen. Fehler während der zeilenweisen Verarbeitung können an einen Error Hop gehen; ungültige Metadaten beziehungsweise Ausgabeschemata stoppen bereits die Initialisierung.

Beim Verbraucher werden Quelle und Leser wiederverwendet, solange die Quelle gleich bleibt. Quellcache: höchstens 64 MiB pro Kopie; zusätzliche Ausgabe-/Operationscaches: 16/8 MiB. Quellblöcke werden auf höchstens 262144 Pixel begrenzt und bei starker Vergröberung weiter unterteilt. Diese Cache-Limits sind keine Gesamtgrenze für den JVM-Heap. Gelesen wird in Originalauflösung ohne Overviews.

Die Auswertung erfolgt erst beim Verbraucher. Quellen werden dort über aufeinanderfolgende Zeilen wiederverwendet. Operationsketten teilen begrenzte Caches; vollständige Raster werden nicht im Heap aufgebaut.

Die Skizze zeigt die Default-Einstellungen; Transformname ist ein Beispiel. Die Auswahlfelder sind editierbar, explicit Crs und no Data sind anfangs leer. Siehe Dialoglegende. Der Dialogtitel lautet Raster STATS (GeoTools).

Ein Pixel wird gezählt, wenn sein Zentrum vom Polygon überdeckt wird, einschliesslich Zentren genau auf der Grenze. Löcher und MultiPolygone sind möglich. Ungültige oder gekrümmte Geometrien müssen vorgelagert behandelt werden. Die Geometrie wird bei Bedarf als Kopie in das Raster-CRS transformiert; Originalgeometrie und Attribute bleiben erhalten. ZonalStats wertet das Rasterfeld auf dessen aktuellem Zellraster aus und führt selbst kein zusätzliches Resampling durch. Vorgeschaltete Clip-/Reproject-Operationen werden dabei ausgewertet.

NoData, Masken und nichtendliche Werte werden vor Scale/Offset ausgeschlossen. Die Kennzahlen beziehen sich danach auf physikalische Werte. Nullwerte werden berücksichtigt. stddev ist die Standardabweichung der Grundgesamtheit, nicht die Stichproben-Standardabweichung. Flächengewichtung, ALL_TOUCHED, Perzentile und Quantile werden nicht angeboten.

Die ausgewählten Kennzahlen erscheinen in angegebener Reihenfolge, danach count, falls noch nicht enthalten, und status. count ist Hop Integer, die übrigen Kennzahlen sind Hop Number, status ist String. Bei prefix = height_ und statistics = mean min max stddev entstehen:

Vorhandene Felder dürfen nicht mit den neuen Feldnamen kollidieren. Technische Fehler während der zeilenweisen Verarbeitung gehen an einen konfigurierten Error Hop oder stoppen den Transform; sie werden niemals als erfolgreiche count-0-Zeile kaschiert. Ungültige Metadaten beziehungsweise Ausgabeschemata stoppen bereits die Initialisierung. Für HTTP-COGs gelten die Range-/Authentifizierungsgrenzen aus Öffentliche HTTP/HTTPS-COGs. Leser schliessen bei Quellenwechsel, EOF, Fehler und Disposal.

Esri File Geodatabases (.gdb) werden ohne GDAL und ohne native Bibliotheken über die Bibliothek filegdb4j gelesen und geschrieben. Der Reader liest Feature Classes mit Punkt-, Multipoint-, Linien- und Polygon-Geometrien einschliesslich Z und M, Attribute als gespeicherte Werte. Normale Attributtabellen sind ohne Geometriespalte lesbar. Der Schema-Dialog zeigt Domains, Feldzuordnungen und Relationship Classes. Diese Definitionen werden nicht automatisch in die Hop-Feldmetadaten übernommen. Der separate FileGDB Catalog Reader gibt sie als normale Metadatenzeilen aus.

Der Vector Writer erstellt eine neue GDB, ergänzt eine Feature Class oder hängt Features an. Der FileGDB Writer kombiniert mehrere benannte Eingänge mit den Aktionen CREATE_DATASET und APPEND_ROWS. JSON definiert neue Datasets, Domains und einfache 1:1-/1:n-Beziehungen, auch zu vorhandenen Datasets. Reine Appends benötigen kein JSON. Beispiele stehen unter docs/examples/filegdb, insbesondere extend.hpl und extend.json.

Beim Append bestimmt das Ziel Feldtypen, Defaults, Domains, Geometrie, CRS und Präzision. Felder werden unabhängig von Gross-/Kleinschreibung nach Namen zugeordnet. Unbekannte Felder und eingehende systemverwaltete OBJECTIDs werden abgelehnt; Quell-IDs vorher umbenennen oder entfernen. Fehlende Felder benötigen einen Default oder Nullable. Domainwerte werden geprüft; fachliche Eindeutigkeit und referenzielle Integrität bleiben Aufgabe der Pipeline. Die Dialoge laden Datasets und prüfen Eingangsschemata.

Alle Änderungen entstehen in einer vollständigen benachbarten Arbeitskopie. Erst nach Erfolg wird diese mittels Sicherungsverzeichnis und dauerhaftem Übernahmeprotokoll übernommen; unterbrochene Übernahmen werden vor der nächsten Bearbeitung wiederhergestellt. Andere Programme müssen die GDB schliessen. Eine Dateisperre wartet maximal fünf Sekunden; Änderungen am Original werden vor der Übernahme erkannt. Vorhandene räumliche Indizes werden immer nachgeführt, fehlende bei aktivierter Indexoption angelegt.

Updates, Upserts, Schemaänderungen und Dataset-Ersetzung sind ausgeschlossen. Bearbeitung von Datasets mit Attributindizes, GlobalID-Automatik, verwalteten Flächen-/Längenfeldern, Subtypes, Regeln, Attachments oder komplexen Beziehungen/Topologien wird abgelehnt. Nicht betroffene Datasets bleiben erhalten. Kreisbögen werden in XY, XYZ, XYM und XYZM nativ geschrieben; Bézier- und Ellipsensegmente können nicht geschrieben werden.

Die Writer-Optionen enthalten XY-Auflösung, XY-Toleranz, beide Ursprünge und das Erstellen eines räumlichen Indexes. Neue Transforms verwenden CRS-abhängige Vorgaben (AUTO), alte Pipelines ohne diese Einstellung behalten LEGACY. Die Auflösung bestimmt das Speicherraster; die Toleranz ist Metadateninformation und keine Linearisierungsgenauigkeit.

Vier optionale Reader-Grenzen filtern inklusiv nach der Geometrie-Boundingbox im Quell-CRS. Diese Einstellungen haben derzeit keine Controls im Reader-Dialog. Für fortgeschrittene HPL-/Metadatenkonfiguration setzen Sie fileGdbXMin, fileGdbYMin, fileGdbXMax und fileGdbYMax gemeinsam; einzelne Grenzen reichen nicht aus. Neue FileGDB-Indizes und fremde Punktindizes werden verwendet; fremde Linien-/Polygonindizes führen für diese Abfragesemantik zu einem Scan. Der Schema-Dialog zeigt die gespeicherten XY-Einstellungen. Beim Erstellen wird eine eingehende OBJECTID als SOURCE_OBJECTID exportiert; eine Namenskollision wird abgelehnt.

Für explizite Linearisierung dienen linearize_curves beziehungsweise coverage_linearize im Geoprocessing-Plugin. Bei Coverages müssen dessen Zielraster und das Writer-Raster identisch sein.

Ob ein Layername bereits existiert, wird aus dem Katalog gelesen; die Auswahl eines Layers beim Lesen entspricht Verhalten und Fehlermeldungen von GeoPackage.

Unterstützt werden Point, MultiPoint, PolyLine und Polygon einschliesslich Multipart und Löchern. MultiPatch und heterogene GeometryCollections werden abgelehnt. Kurven werden mit der vorhandenen linearen Darstellung des Geometry-Typs geschrieben; Kurven mit Z/M sind nicht unterstützt. Expliziter Geometrietyp und explizite Dimension erlauben auch leere und ausschliesslich NULL-haltige Ausgaben. Bei AUTO bestimmt die erste nichtleere Geometrie das Schema; höchstens 10'000 anfängliche NULL/EMPTY-Zeilen werden gepuffert.

Z muss bei XYZ/XYZM endlich vorhanden sein. Fehlendes M wird als Esri-NoData kleiner als -1e38 gespeichert. Z-Shape-Header dürfen einen optionalen M-Teil besitzen. NULL und EMPTY werden beide Null-Shape; bei EMPTY wird der Informationsverlust protokolliert. Zusätzliche Dimensionen werden nicht still entfernt.

Ein fehlendes PRJ bedeutet unbekanntes CRS mit Warnung. EPSG/WKT weist ein CRS zu; widersprüchliche bekannte SRIDs werden zurückgewiesen. Eine SHX ist beim Lesen optional; vorhandene Komponenten und Offsets werden geprüft. Als gelöscht markierte DBF-Zeilen werden übersprungen.

Die Lesekodierung folgt expliziter Einstellung, CPG, DBF-Codepage, dann ISO-8859-1 mit Warnung. Ungültige Bytefolgen führen zum Fehler. Der Writer verwendet standardmässig UTF-8 und schreibt eine CPG. Nicht darstellbare Zeichen und Kürzungen werden gemeldet; Texte werden an gültigen Zeichengrenzen auf die Bytebreite gekürzt. DBF-Feldnamen sind ASCII, maximal zehn Zeichen; Kollisionen erhalten stabile Suffixe.

Vom Writer ausgegebene NULL-Werte und leere Strings sind in DBF-Zeichenfeldern nicht unterscheidbar. Keine Append-/Update-Funktion, QIX-Erzeugung oder räumliche Reader-Filterung; Komponenten über 2 GiB werden nicht unterstützt. Der Writer stellt die Sidecar-Dateien zunächst temporär bereit. Ihre Veröffentlichung ist kein atomarer Austausch des gesamten Dateibündels. Ohne Overwrite existing file werden vorhandene Zieldateien beziehungsweise Sidecars abgelehnt. Mit aktivierter Option werden bekannte Sidecars ersetzt und veraltete entfernt.

Der Reader ermittelt Layer über gpkg_contents und gpkg_geometry_columns. Layernamen werden zuerst exakt, danach ohne Beachtung der Gross-/Kleinschreibung aufgelöst. Die Geometry-Spalte steht zuletzt; ihr Quellname bleibt ohne explizite Umbenennung erhalten. Geometrie-SRID und Layer-CRS müssen übereinstimmen.

Neben linearen XY-Geometrien werden CircularString, CompoundCurve, CurvePolygon, MultiCurve und MultiSurface unterstützt. NULL und EMPTY bleiben verschieden. Z/M, nicht unterstützte Geometrieheader und Kurven in generischen GeometryCollections werden abgelehnt. Beim Schreiben werden die passenden gpkg_geom_<TYPE>-Erweiterungen registriert. Die Geometrieausgabe verwendet Little Endian ohne eingebettete EWKB-SRID und ohne Envelope im GeoPackage-Header.

String, Integer, Number, BigNumber, Boolean, Date, Timestamp und Binary werden unterstützt. SQLite REAL garantiert keine exakten Dezimalwerte; bei entsprechenden Anforderungen ein anderes Zielformat wählen. Datumswerte verwenden UTC. Ein Integer-Primärschlüssel ist Feature-ID und erscheint nicht nochmals als gewöhnliches Attribut. Bei einer Namenskollision mit fid wählt der Writer einen anderen internen Schlüsselspaltennamen.

Der Vector Writer bietet drei GeoPackage-Schreibmodi: neue Datei erstellen (CREATE_FILE), neuen Layer in einer bestehenden Datei anlegen (ADD_LAYER) und Features an einen bestehenden Layer anhängen (APPEND_FEATURES). Bei Neuanlage kann das Geometrieschema explizit angegeben oder aus der ersten nichtleeren Geometrie ermittelt werden. Der aktuelle Writer benötigt auch bei explizitem Schema zusätzlich ein Geometriebeispiel. Ein explizites Schema genügt daher nicht für leere Quellen oder Quellen, deren erste Zeile eine NULL-Geometrie enthält. Ohne explizites Schema werden anfängliche NULL/EMPTY-Zeilen bis zur Schemaableitung gepuffert; reine NULL-Streams lassen sich nicht ableiten. Beim Anhängen gilt das vorhandene Zielschema; dies funktioniert auch mit leeren Eingängen. Attribute werden ohne Beachtung der Gross-/Kleinschreibung nach Namen zugeordnet. Die ausgewählte Quellgeometrie wird der Zielgeometriespalte zugeordnet. Fehlende Attribute benötigen Nullable oder einen Datenbank-Default; unbekannte Eingangsattribute, Typkonflikte und Eingaben für den generierten Primärschlüssel werden abgelehnt. Bekannte abweichende CRS werden abgelehnt; SRID 0 wird beim Anhängen dem Ziel-CRS zugeordnet, ohne Reprojektion.

Im GeoPackage-Optionsbereich lassen sich bestehende Layer laden und das Eingangsschema prüfen. Beim Anhängen werden Zielschema und Indexstatus angezeigt; Geometrietyp, Dimension und Ziel-CRS sind nicht editierbar. Datei- und Layernamen sind variablenfähig. Der Overwrite-Schalter gilt nicht für GeoPackage.

Ein räumlicher RTree-Index wird standardmässig erstellt, falls er fehlt, einschliesslich bereits vorhandener Features. Vorhandene Indizes werden immer nachgeführt. Index, Layer-Ausdehnung und Änderungszeit werden zusammen mit den Features in derselben Transaktion aktualisiert. Kurvenextrema werden berücksichtigt; NULL und EMPTY werden nicht indiziert. Fehler und Abbruch rollen diesen Writer-Lauf vollständig zurück. Neue Dateien werden nach Erfolg aus einer temporären Datei veröffentlicht. Pro Datei ist nur ein aktiver Writer erlaubt; mehrere Writer müssen nacheinander laufen. Externe Schreibsperren führen nach fünf Sekunden zum Fehler. Beispielpipelines stehen unter docs/examples/geopackage-append. Keine Updates, Upserts, Layerersetzung, automatische Schemaänderung oder Raster-Tile-Unterstützung. SQLite JDBC bringt seine plattformspezifischen Bibliotheken im gemeinsamen ZIP mit; eine separate Installation ist nicht nötig.

Die Ausgabe unterstützt Point, MultiPoint, LineString, MultiLineString, Polygon und MultiPolygon. Ein explizites Multipart-Schema akzeptiert die entsprechende einfache Geometrie. Heterogene Collections und weitere Geometry-Attribute werden abgelehnt. Typ/Dimension explizit setzen, wenn die Eingabe leer oder ausschliesslich NULL ist; AUTO puffert maximal 10'000 anfängliche NULL/EMPTY-Zeilen. Z muss vorhanden sein, fehlendes optionales M bleibt NaN. Kurven werden mit Warnung linearisiert.

Der standardmässige räumliche Index sortiert Features nach Hilbert-Schlüssel; bei Gleichstand zählt die Eingabeposition. Der gepackte R-Baum hat Knotengrösse 16. Die externe Sortierung verwendet 64 MiB Arbeitsbudget und maximal 64 offene Läufe; Indexebenen liegen auf der Platte. Temporärer Platzbedarf wächst mit Daten und Index, einzelne grosse Features benötigen weiterhin Speicher.

Mit Index sind NULL/EMPTY standardmässig Fehler. Skip NULL/EMPTY geometries with warning lässt diese Zeilen aus und protokolliert ihre Anzahl. Ohne Index bleibt die Eingabereihenfolge erhalten, NULL wird erhalten und EMPTY mit Warnung zu NULL. Eine Datei ohne Features besitzt keinen Index.

NULL-Attribute werden ausgelassen und bleiben von leeren Strings unterscheidbar. Bekannte CRS-Autorität, Code und verfügbares WKT kommen in den Header; unbekanntes CRS wird nicht als WGS84 markiert. Doppelte/leere Feldnamen und komplexe Attribute müssen vorgelagert korrigiert werden.

Der Writer verwendet Apache Parquet Java 1.17.0 und die nativen logischen Typen GEOMETRY/GEOGRAPHY. Ein Client benötigt Unterstützung dafür oder muss die WKB-Binärspalte selbst interpretieren. Ein GeoParquet-geo-Metadatendokument wird nicht erzeugt. Hadoop oder zusätzliche JNI-Kompressionsbibliotheken sind nicht erforderlich.

Geometriefamilien, Schemaableitung, Z/M und Kurvenlinearisation entsprechen FlatGeobuf. NULL und EMPTY bleiben hier verschieden. ISO-WKB verwendet Dimensionscodes ohne EWKB-Flags oder eingebettete SRID. Das CRS liegt am logischen Typ; unbekanntes GEOMETRY-CRS wird explizit als srid:0 angegeben. Binäre Min-/Max-Statistiken der Geometriespalte sind deaktiviert; zusätzliche räumliche Statistiken werden nicht zugesichert.

GEOMETRY beschreibt planare Kanten. GEOGRAPHY verlangt ein bekanntes geografisches CRS und Longitude/Latitude in [-180, 180] beziehungsweise [-90, 90]. Die Interpolationsannotation SPHERICAL, VINCENTY, THOMAS, ANDOYER oder KARNEY beschreibt Kanten, führt selbst keine Berechnung durch. Standardkompression ist GZIP; UNCOMPRESSED ist die Alternative. 128 MiB Row-group-Grösse ist ein Zielwert, keine harte Heap-Grenze.

Für BigNumber müssen Hop-Metadaten explizit length = Gesamtpräzision und precision = Skala liefern, beispielsweise durch Select Values. Fehlende Angaben, Überlauf oder erforderliche Rundung führen zum Fehler; es erfolgt keine Umwandlung über Double. Auch Nanosekunden-Überlauf bei Timestamp wird abgelehnt.

FlatGeobuf und Parquet schreiben zuerst eine Nachbardatei. Erfolg veröffentlicht sie mittels atomarem Rename beim Überschreiben beziehungsweise Hardlink ohne Überschreiben. Dateisysteme ohne diese Unterstützung werden abgelehnt. Fehler/Abbruch erhalten vorhandene Ziele; Elternverzeichnis und eindeutiger Zielpfad pro Transform-Kopie sind erforderlich. Die Adapter enthalten den MIT-Hinweis zu gpkg2cloudformats in META-INF/NOTICE.txt.

ARCINFO_GENERATE beziehungsweise AUTO mit .gen schreibt homogene ASCII-Dateien. Nur einfache Point, LineString und Polygon ohne Löcher sind erlaubt; Multipart, Collections, Kurven, ungültige Geometrien und nichtendliche Koordinaten werden abgelehnt. Bei Bedarf vorgelagert explodieren oder linearisieren. Polygonringe werden geschlossen und im Uhrzeigersinn ausgegeben, ohne die Eingabe zu verändern.

Diese Dialekte sind nicht mit jedem .gen-Importer austauschbar. Erwartet ein Empfänger Polygone als geschlossene Linien, wandeln Sie die Geometrie vorher in ihre Grenze um und wählen LINE. Die Ausgabe wird gegen exakte Referenztexte getestet; ein Import in ein lizenziertes Esri-Produkt wurde nicht durchgeführt. Die sechs kleinen Referenzdateien sind unter docs/examples verfügbar.

Ein ID-Feld muss Hop Integer enthalten; ohne Feld beginnen fortlaufende IDs bei 1. Überlauf ist ein Fehler, Eindeutigkeit wird nicht überprüft. Der Empfänger muss den verwendeten 64-Bit-ID-Bereich unterstützen; Polygon-ID -99999 ist wegen der Esri-Inselkonvention verboten. XYZ verlangt endliches Z; XYM ersetzt XYZ nicht. Zusätzliche Ordinaten dürfen nur mit ausdrücklichem Discard extra Z/M ordinates entfallen.

Standardmässig bleibt die Double-Präzision in einfacher Dezimalschreibweise erhalten. 0–15 Dezimalstellen runden HALF_UP; geometrischer Kollaps nach Rundung wird abgefangen. Dezimalpunkt und LF-Zeilenenden sind unabhängig vom Gebietsschema; negative Null wird normalisiert. Trennzeichen ist Leerzeichen oder optional Komma. NULL/EMPTY führt ohne Skip-Option zum Fehler. CRS und beliebige Attribute werden nicht eingebettet; Koordinaten müssen bereits im Ziel-CRS vorliegen.

Der Zielordner muss existieren. Eine Transform-Kopie besitzt die Datei; Überschreiben muss explizit aktiviert sein. Temporäre Ausgabe wird erst bei erfolgreichem EOF veröffentlicht; Abbruch erhält das vorherige Ziel. Auch ein erfolgreicher leerer Stream erzeugt ein abschliessendes END.

Die Grammatik folgt Esris How Generate works, ASCII 3D To Feature Class, Feature Class Z To ASCII und Generate (Inselkonvention).

Parameter: INPUT_VECTOR (lokales .shp/.gpkg), INPUT_LAYER (leer: erster Layer), OUTPUT_FILE. Beispiel: /data/parcels.gpkg, parcels, /data/parcels.fgb. Der Reader benennt die Geometrie geometry; Attribute werden weitergereicht. FlatGeobuf verwendet den räumlichen Index und lehnt NULL/EMPTY ab. Parquet verwendet GEOMETRY, GZIP und 128-MiB-Row-Groups. Für leere Quellen Typ/Dimension im Writer explizit einstellen; fehlende Dezimalmetadaten vor Parquet ergänzen.

Parametrisierte Clip-Pipeline herunterladen

In der Clip-Vorlage steht Bands (ALL or 1-based list) (bands) auf 1; in der Statistikvorlage steht band auf 1. Beides sind feste Einstellungen, keine variablen Parameter.

Die URL ist ein Beispiel, keine dauerhaft zugesicherte Datenversion. Dieselbe Pipeline akzeptiert lokale GeoTIFFs. Sie schneidet genau ein Band auf dem Quellraster aus; sie erzeugt keine neue Auflösung. Der eingebundene Raster Writer ergänzt raster_output_file und raster_status = OK.

Die Parameter stehen jeweils in der HPL-Datei: INPUT_RASTER, OUTPUT_FILE, TARGET_CRS, PIXEL_SIZE_X, PIXEL_SIZE_Y und gegebenenfalls OUTPUT_NODATA. Für reine Auflösungsänderung TARGET_CRS leer lassen. Numerisches Beispiel: lokales Höhenmodell EPSG:2056, Pixelgrössen 2/2, neue Zieldatei. Für EPSG:4326 werden die Pixelgrössen in Grad angegeben, beispielsweise 0.00001/0.00001. Die automatische Ausdehnung folgt der Quelle; das Höhenmodell-Beispiel besitzt eine feste Box und verlangt dazu passende CRS-Einstellungen.

Bei Paletten muss ein Sentinel ein vorhandener, nicht gültig verwendeter Index sein, falls zusätzliche ungültige Bereiche entstehen. BILINEAR wandelt Paletten zu RGBA16 um. Weitere Regeln stehen unter Reproject / Resample.

Vector Reader → Raster Zonal Statistics herunterladen

Parameter: INPUT_VECTOR, INPUT_LAYER, INPUT_RASTER, GEOMETRY_CRS, NODATA. GEOMETRY_CRS darf bei korrekter Geometry-SRID leer bleiben. Beispiel: Gebäude-Polygone EPSG:2056 und https://files.geo.so.ch/ch.swisstopo.lidar_2023.ndsm_buildings/aktuell/ch.swisstopo.lidar_2023.ndsm_buildings.tif, Band 1, Statistiken mean min max (im Dialog erweitern, etwa um stddev sum). Das Gebäude-nDSM beschreibt Höhen über Terrain; verwenden Sie seine Werte direkt.

Die Beispielpipeline liefert Ergebniszeilen zur Vorschau; sie schreibt keine neue Vektordatei. Zum Speichern fügen Sie einen Vector Writer mit neuem Zielpfad hinzu. Überprüfen Sie neben raster_mean, raster_min, raster_max stets raster_count und raster_status. NULL-Statistikwerte bei NO_VALID_PIXELS sind keine Höhe null.

Raster Reader → Clip → Reproject → Writer herunterladen

Diese Pipeline gibt das Feld raster direkt von Operation zu Operation weiter und schreibt erst am Ende. Setzen Sie die in der HPL-Datei definierten Parameter auf Ihre Daten; es entstehen keine Zwischendateien.

scripts/check-doc-examples.py führt Clip und Statistik aus den echten HPL-Dateien mit kleinen, lokal erzeugten Testdaten aus. Benötigt werden Java 21 einschliesslich javac, Python 3 und eine saubere, entbehrliche Apache-Hop-2.19.0-Installation ohne bereits installierte Geometry-, Raster-Type- oder Vector/Raster-Plugins. Das Skript installiert die Plugins in diese Testinstallation. Bauen Sie zuerst die passenden Raster-Type- und Geometry-Artefakte sowie das Vector/Raster-ZIP; siehe Entwickleranleitung. In assemblies/assemblies-hop-vector-raster/target muss genau ein Vector/Raster-ZIP liegen. Setzen Sie HOP_HOME, GEOMETRY_ZIP und RASTER_TYPE_ZIP auf absolute Pfade und führen Sie vom Repository-Stamm aus:

Externe COGs gehören nicht zur verpflichtenden Prüfung.