unklare Alternativen

[gisma]

CaseStudies/documents/CaseStudy_DB.txt

Line 34 in 263c621

Alternativ könnte VAT (vorübergehend) das zentrale Login übernehmen, falls dadurch der Usecase besser zeitnah umgesetzt werden kann (falls dort eine entsprechende Benutzerverwaltung existiert).

Mir ist nicht ganz klar wie der Nutzer mit diesen Alternativen umgehen soll.

Wenn es Alternativen auf der Entwicklerseite sein sollen bin ich der Aufassung dass die effizienteste (Vermutlich 1 oder 3) sinnvoll sind.

[swoellauer]

Ich gehe davon aus, dass diese Funktionalität in einem (vom Benutzer konfigurierbaren) VAT-Operator abgebildet wird.
Welche der Alternativen passt besser in das VAT-Konzept? (Für verschiedene Workflows können alle drei Varianten sinnvoll sein.)

1. VAT-Operator, der Raster Ausschnitte aus RasterDB extrahiert
2. VAT-Operator, der auf einem in VAT vorhandenen Raster Ausschnitte extrahiert (schon vorhanden?)
3. VAT-Operator, der eine spezifische Prozessierungs-Anfrage an RasterDB sendet

[jdroenner]

Aus unserer Sicht sollte Option 2 funktionieren.

[swoellauer]

Ein LAI-Raster-Layer des Gebiets ("natur40_lai") ist in RasterDB vorhanden und kann von VAT geladen werden (2x2 Meter Auflösung). Details in der API Beschreibung der CaseStudy.

[gisma]

Für den usecase sollte das reichen aber was ist wenn ich als Nutzer z.B. 1**m haben möchte? Ist es sinnvoll die Prozessierung der Daten direkt mit zu berücksichtigen?

[swoellauer]

Ein Anwender würde in RasterDB ein neues Raster (mit z.B. 1x1 Meter) anlegen, eine Prozessierung ausführen und dann für den weiteren Workflow zu VAT wechseln.

Es ist nicht unproblematisch beliebigen Anwendern aufwendige Prozessierungen zu überlassen. Es können viele Ressourcen gebunden werden. z.B. hat diese Prozessierung ("natur40_lai") bei Vollauslastung (16 Kerne) 12 Minuten gedauert.