- edited description
Generation of example / test data
Please change enmapbox/utils/codegen/TestTestdataInitPyGenerator.py to include the logic that I already implemented in:
-
enmapbox/make/make.createTestData(dirSrc, dirDst, BBOX, drv=None):
- generation of spatial test data based on a predefined rectangle (BBOX)
- raster + vector files (misses spatial subsetting yet)
-
enmapbox/make/make.createFilePackage(dirData):
- generation of package variables like "TestFileA = r"path/to/testfile.bsq" on initial package call
- self test if files are not available -> this might be not the case, e.g. if git lfs was not installed
-
The idea behind the entire make.py module is to include functionality required to deploy the EnMAP-Box but not necessarily to run it. E.g. the generation of documentation files might depend on modules / external program not required to run the Box itself.
-
I'd further prefer to bundle functions in modules, instead of one function = one module
Comments (6)
-
-
reporter Ein TestCoverage für ein make-file? Ist das Dein Ernst?
Bitte benenne was Du mit "ungünstigen Abhängigkeiten zu PyQt und QGIS" meinst. Da die EnMAP-Box als QGIS Plugin entwickelt wird sind PyQt und PyQGIS in der jeweiligen Laufzeitumgebung jederzeit verfügbar, zumal das gemäß (3.) eh sichergestellt ist.
zu 4. Der scope des make.py moduls ist der eines Makefiles bzw. die Generierung von Dateien, die z.B. für ein Release benötigt werden. Im besten fall nur einmal. bestenen
-
- changed status to closed
Ich close den Issue mal, haben wir ja alles geklärt, wa?
-
reporter - changed status to on hold
schau dir erstmal die classification in urbangradient an
-
Oh, in dem Issue ging es auch um den UrbanGradient :-)
Wäre gut, wenn du die noch offenen Punkte in einzelne Issues aufteilen würdest, damit wir diese besser überblicken/abarbeiten können.
-
- changed status to closed
outdated
- Log in to comment
Hi @jakimowb, das enmapbox/make/make.py ist sehr unübersichtlich. Es enthält ungünstige Abhängigkeiten zu PyQt und QGIS, viele Zuständigkeiten auf verschiedensten Abtraktionsebenen mit teilweise sehr langen Methoden. Es fällt mir schwer diese Vorarbeit nachzunutzen/zu refactoren, da ich keine TestCoverage habe.
Ich werde den Make-Mechanismus von grundauf neu implementieren und bisherige Features später nachziehen.
Die Testdata init.py Generierung sollte hinreichend sein. Wenn über LFS keine Files heruntergeladen wurden, dann steht in "TestFileA" der Pfad drin, wo das Bild eigentlich liegen sollte. Wenn dieser Pfad dann benutzt wird, erfährt der Nutzer, dass das Bild nicht im Ordner liegt. Macht so wie es jetzt ist, total Sinn für mich. Oder? Wozu noch ein Selbsttest?
Ja, der Ansatz ist sehr gut!
Ein Modul sollte aber immer einen klar erkennbaren Scope haben. Auf oberster Modulebene sollten nur Funktionen/Klassen gleicher Abtraktion liegen. make() und fileNeedsUpdate() auf gleicher Ebene zu definieren ist sehr unschön.