Wie schreibe ich ein GRASS GIS Addon?
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 119 | |
| Autor | ||
| Mitwirkende | ||
| Lizenz | CC-Namensnennung 4.0 International: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/67670 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
00:00
SoftwareGeoinformationssystemGRASS <Programm>ModularitätDatenbankEXTRACTmakeSkript <Programm>Print <4->UpdateMereologieProzess <Informatik>HilfesystemDeskriptive StatistikRepository <Informatik>SchlussregelFunktionalEin-AusgabeOpen SourceSoftwareKette <Mathematik>DatenbankOffene MengeParametersystemElektronische PublikationSchreiben <Datenverarbeitung>GeradeMomentenproblemSpeicherabzugQuellcodeSoftwareentwicklerBimodulMultiplikationsoperatorHochdruckDokumentenserverDifferenteVersionsverwaltungRechter WinkelHöheNabel <Mathematik>Print <4->RollbewegungDateiModularitätVorlesung/KonferenzComputeranimation
05:43
Skript <Programm>Lokales MinimumDateiHTMLPrint <4->makeInklusion <Mathematik>HyperbelverfahrenElektronische PublikationMikroprozessorRechter WinkelTechnische ZeichnungDiagrammComputeranimation
06:57
Cookie <Internet>CodeBimodulDeskriptive StatistikElektronische PublikationAutorisierungFitnessfunktionMomentenproblemComputeranimation
08:01
GNU <Software>Cookie <Internet>GRASS <Programm>ParserParametersystemEin-AusgabePolygonFahne <Mathematik>Typ <Informatik>Aussage <Mathematik>Ein-AusgabeRechenschieberGit <Software>ModulFahne <Mathematik>ParametersystemDateiMereologieFunktionalBimodulElektronische PublikationKonfiguration <Informatik>Befehl <Informatik>DifferentePlastikkarteVerschlingungPunktFunktion <Mathematik>SoftwareentwicklerRechter WinkelE-MailComputeranimationVorlesung/Konferenz
11:26
QuellcodeGRASS <Programm>GeoinformationssystemSkript <Programm>Cookie <Internet>Ein-AusgabeVersion <Informatik>DefaultEin-AusgabeModulParametersystemChipkarteSprachausgabeSchreib-Lese-KopfSkript <Programm>PlastikkarteBimodulParserMessage-PassingGeradeEinsFormale SpracheSichtenkonzeptHilfesystemSchnittmengeBitFlächentheorieGraphische BenutzeroberflächeE-MailComputeranimationTechnische ZeichnungDiagramm
15:20
CodeRepository <Informatik>HTMLVersion <Informatik>GRASS <Programm>GeoinformationssystemStichprobeVersion <Informatik>SoftwaretestHook <Programmierung>GeradeRepository <Informatik>Elektronische PublikationSchlussregelFahne <Mathematik>KonfigurationsraumComputeranimation
18:12
GRASS <Programm>GeoinformationssystemHTMLDateiParserSkript <Programm>AdditionAPIServerUploadingGeoServerEditorSoftwaretestOpen SourceHilfesystemDateiLanding PageBimodulElektronische PublikationLokales MinimumBitmap-GraphikBildgebendes VerfahrenBitRechenbuchProgrammbibliothekProzess <Informatik>Computeranimation
21:18
Kartesische KoordinatenGüte der AnpassungProzess <Informatik>Familie <Mathematik>Rechter WinkelKette <Mathematik>CASE <Informatik>Vorlesung/Konferenz
22:58
HTMLSkript <Programm>GRASS <Programm>ParserParametersystemQuellcodeDefaultBenutzerführungDatenmodellGNU <Software>Cookie <Internet>Ein-AusgabePolygonFahne <Mathematik>Computeranimation
23:23
Print <4->Skript <Programm>makeBimodulFunktionalMultiplikationsoperatorMailing-ListeVorlesung/KonferenzComputeranimation
24:13
Skript <Programm>Print <4->makeMengensystemMinimumPunktFamilie <Mathematik>Mailing-ListeRechter WinkelVorlesung/KonferenzComputeranimation
24:39
Vektor <Datentyp>FeldrechnerParserFahne <Mathematik>Bitmap-GraphikProzess <Informatik>BimodulSchreiben <Datenverarbeitung>Konfiguration <Informatik>GRASS <Programm>VektorraumVorlesung/Konferenz
26:11
ParserGRASS <Programm>Cookie <Internet>GNU <Software>Ein-AusgabeParametersystemTyp <Informatik>QuellcodeGeoinformationssystemSkript <Programm>EXTRACTFehlermeldungTechnische ZeichnungComputeranimation
26:44
Vorlesung/Konferenz
Transkript: Deutsch(automatisch erzeugt)
00:07
Und ich begrüße auch sehr herzlich die neu dazu gekommenen zum zweiten Teil der Session zum Vortrag von Carmen Tawalika zu, wie ich denn nun ein Add-on zu Quesqes schreiben kann.
00:21
Vielen Dank, ja willkommen. Schön, dass Sie da sind. Freut mich, dass Sie sich dafür interessieren. Ich möchte Ihnen erklären, wie man oder wie ich oder wie wir ein Quesqes Add-on schreiben. Die Community ist natürlich sehr groß. Das hat man ja bei Markus eben schon gesehen. Und in dem Vortrag möchte ich Ihnen zeigen, wie wir bei Mundialis hauptsächlich Best Practice Artic Add-ons schreiben.
00:47
Mundialis, wir sind eine Firma in Bonn, schreiben Open Source Software, produzieren meist offene Daten, nutzen freie Open Source Software und entwickeln diese auch aktiv weiter. Unter anderem auch Quesqes und Actinia und ja noch einige andere Dinge.
01:08
Ich selbst bin Carmen Tawalika, bin bei Mundialis seit 2015 angestellt als Entwicklerin und habe auch schon viele verschiedene Dinge mitentwickelt. Momentan arbeite ich in der Actinia-Entwicklung, bin da auch im PSC und habe auch über die Zeit noch andere Rollen übernommen.
01:26
Zu dem Talk, den ich jetzt vortrage. Erstmal gibt es eine kleine Einführung, ganz kurz und knapp. Da gehen wir auch schon direkt ins Detail, wie das aussehen könnte. Dann Konzepte und Praxis ist so mit der Hauptteil. Da gibt es dann ganz viele verschiedene Hilfestellungen, Hinweise, Best Practice Aufzählungen, wie man das am besten macht mit dem Add-on.
01:47
Dann gibt es noch ein paar Arbeitserleichterungen und wie man auch die Qualität steigern kann, ohne dass man dafür selbst viel tun muss. Und zu guter Letzt möchte ich Ihnen noch ein paar Add-ons vorstellen, die wir bei Mundialis geschrieben haben, die man auch auf GitHub finden kann.
02:02
Dann zuerst mal zur Einführung. Um zu verstehen, wie man einfach ein Add-on schreiben kann, ist es recht wichtig, eins der Hauptkonzepte von Quesqes zu kennen, das ist die Modularität. Es gibt 542 offizielle Quesqes-Module, die auch im Quesqes-Core-Sourcecode zu finden sind, stand letzte Woche irgendwann.
02:27
Und dazu gibt es noch ein offizielles Add-on-Repo und es gibt unzählige inoffizielle Repositories. Da ist ein kleines Sternchen dran, unauffindbar, da gehe ich später noch drauf ein.
02:41
Und diese ganzen Module, die kann man alle auch zusammen stecken und hintereinander schalten. Also man kann damit Daten importieren, Prozessierungen machen, Daten exportieren und vieles mehr. Wozu soll man jetzt noch ein eigenes Add-on schreiben? Da ist natürlich dann zum einen der Vorteil, dass man bestehende Grass Add-ons auch benutzen kann in seiner Prozesskette und dann ein eigenes Add-on,
03:06
was vielleicht noch Anforderungen, wenn man Anforderungen hat, die noch nicht erfüllt sind, die man dann mit reinbringen kann. Man kann direkt die Daten, wie sie in der Grass-Datenbank liegen, nutzen. Das hat auch einen großen Vorteil, weil das Recht performant ist.
03:23
Grass ist ja auch ein topografisches GIS und da kann man eben dann auch diese Vorteile nutzen, die Daten direkt zu verwenden und nicht immer hin und exportieren, wenn man andere Grass-Funktionalitäten benutzen möchte. Zum anderen, was bei uns bei Mundialis ja auch eine Rolle spielt, ist die Nutzung von Actinia.
03:43
Also wenn wir in Actinia Sachen prozessieren möchten, dann ist das auf jeden Fall hilfreich, wenn wir das in ein Grass-GIS-Add-On packen, weil dann können wir es einfach in diese Prozesskette mit aufnehmen und dann Actinia schicken und dann wird das dort alles prozessiert. Noch ein weiterer Vorteil ist, wenn man die, ich nenne es mal, Regeln befolgt, die zu einem Grass-GIS-Add-On dazugehören,
04:04
dann hat man automatisch schon Dokumentation und Beschreibung von Input- und Output-Parametern und somit hat man schon eine recht hohe Qualität an seinem eigenen Code, was natürlich auch gut für die Wiederverwendbarkeit ist und unzählige andere Vorteile, die es bestimmt auch noch gibt.
04:22
Dann sehen wir jetzt schon direkt eine Minivalversion. Die ist laufähig, aber sie ist jetzt wirklich ganz minimal, um die Grundlagen mal erklären zu können. Oben rechts sieht man die Ordner-Struktur, dann ist der Name. Ich habe das Add-On jetzt mal t-foskis-fortune genannt und da sind drei Dateien minimal notwendig.
04:44
Das ist ein Makefile, da sieht man unten vier Zeilen, die in einem Makefile stehen müssen, um das quasi installieren zu können. Dann sieht man eine HTML-Datei, für die Minivalversion kann die sogar leer sein und eine Python-Datei, wo einfach eine Main-Funktion drin ist, die einen Print ausgibt.
05:02
Das könnte man gerade so schon Kraskis-Add-On nennen, da kann man sich darüber streiten. Das kann man aber, ich bin jetzt hier in der interaktiven Shell mit Kraskis eingeloggt, mit G-Extension schon installieren. Also ich kann da den Namen angeben und die URL installiert und am Ende steht,
05:24
also kommen ein paar Warnings, weil eben ein paar Sachen noch nicht so ganz, also einfach fehlen und dann ist die Installation erfolgreich installiert. Dann kann man das aufrufen, t-foskis-fortune und dann kommt das Print, was in der Python-Datei erwähnt wurde.
05:45
So, das war jetzt kurz und knapp, was ist das eigentlich? Und jetzt kommen wir zum Kern, zu den Konzepten und zur Praxis. Kann man das jetzt noch verbessern? Ist das mit dem Mikro-Vorausfall, kann man das irgendwie besser? Geht das?
06:08
So, dann zunächst zum Vorgehen. Wie fängt man an? Es gibt ja schon so viele Menschen, die in Kraskis entwickeln, die Add-Ons entwickelt haben. Da guckt man natürlich am besten einfach mal irgendwo ab.
06:21
Wir haben dazu einen Add-On auf GitHub, das heißt v-example. Das kann man sich auschecken und auch anpassen, da sind schon so einige Best Practices mit drin. Und dann haben wir auch noch eine README, how to create a Kraskis Add-On. Das ist auch quasi eine Anleitung, wie man das auch noch verbessern kann. Rechts sieht man die Dateilstruktur.
06:44
In rot markiert sind die Dateien, die wir jetzt schon gesehen haben. Das ist die HTML-Datei, die Python-Datei, das Makefile und verschiedene andere Dateien, auf die wir später noch eingehen. Dann kann man anfangen und kann die Dokumentation verbessern.
07:01
Das ist die HTML-Datei, die eben noch leer war. Jetzt sieht man unten links den Code dafür. Da steht quasi die Beschreibung drin, was das ist und mit was das irgendwie noch verwandt ist. Outdoor ist dabei. Hier steht jetzt ausführliche Beschreibung.
07:20
Das ist natürlich viel besser als das, was ich da unten gemacht habe, aber das passt halt nicht auf diese Folie. Und man kann auch im besten Fall noch ein Bild verlinken und das auch in diese Dokumentation hinzufügen. Das, was man sieht, was in der HTML-Datei sieht, wird am Ende in der Dokumentation verwendet. Das ist jetzt mal ein Beispiel-Screenshot von Online-Dokumentation von einem Krask-Modul.
07:42
Und das, was in rot eingekreist ist, das ist das, was in der HTML-Datei steht, was da eigentlich rauskommt. Alles andere wird über den Code eingelesen, was es natürlich als Entwickler sehr viel angenehmer macht. Man muss nicht so viel Dokumentation doppelschreiben, sondern es wird automatisch übernommen. Da sehen wir gleich auch noch mehr zu.
08:02
Dann als nächstes fangen wir mit der Python-Datei an oben. Shibang und header. Da wird die Lizenz angegeben, wie das Modul heißt, Outdoor. Das ist in vExample zum Beispiel auch. Das habe ich da auch bei Git ausgecheckt und ein bisschen angepasst.
08:20
Und der Datei header ist jetzt hier ein bisschen gepülst, dass es auf die Folie passt. Aber das ist im Prinzip schon eine Sache, um mit der Head-on-Entwicklung weiterzukommen. Und dann kommen wir fast zum Hauptpunkt, würde ich sagen. Ich glaube, da mit dieser Folie könnte man einen ganzen Vortrag füllen. Ich versuche mich mal kurz zu halten.
08:43
Also der Krass-Parser ist ein ziemlich mächtiges Tool. Das sieht jetzt aus wie Kommentare. Das ist aber in Wirklichkeit die Anweisung, mit der Krass unter anderem auch die Dokumentation generiert. Und auch sagen kann, was In- und Outputs sind von dem Modul. Da kann man Keywörter vergeben, man kann Optionen vergeben.
09:04
Also ich habe ja den Modulnamen und kann dann sagen, Input ist gleich eine Karte zum Beispiel. Oder Output eine andere Karte oder verschiedene andere Parameter. Das kann man da alles definieren. Und es gibt auch Standardoptionen, bei denen man sich bedienen kann. Hier im Beispielrecht sieht man GeoPvInput.
09:23
Da kommen dann einfach schon einige Dinge mit, die man nicht nochmal alle extra auflisten muss. Die dann automatisch zur Verfügung stehen. Da ist auch verlinkt, wo da eine Dokumentation zu ist, dass man sich die alle mal angucken kann. Die Slides selbst sind übrigens auch in den Pre-Talks verlinkt unten. Dann kann man auch auf diese ganzen Links nochmal zugreifen.
09:44
Es gibt auch noch Rules zum Beispiel. Damit kann man dann sagen, diese Option ist auf jeden Fall vorgeschrieben, die muss verwendet werden. Oder auch, wenn diese Option verwendet wird, dann darf nie nicht verwendet werden. Oder man kann auch verschiedene andere Aussagen treffen, wie die Optionen miteinander zu benutzen sind.
10:06
Und in der MainPy können die Optionen dann aufgerufen werden. Das ist noch jetzt der Teil, der in der Dokumentation dabei ankommt. Also, ich habe oben Keywords vergeben, der Name des Moduls, wie man das aufrufen kann.
10:22
Dann die ganzen Flags und die ganzen Optionen. Das kommt eben alles aus diesem Teil und muss nicht händisch nochmal neu geschrieben werden. Dann im nächsten Teil die MainPy und auch eine Cleanup-Funktion, wenn man das braucht und möchte. Und in der MainPy sieht man, dass man da dann diese ganzen Optionen auch aufrufen und einlesen und benutzen kann und damit weiterarbeiten kann.
10:46
In dieser Python-Datei sind beliebig viele Methoden möglich. Das Wichtige ist halt, dass es eine MainPy gibt. Und auf der nächsten Folie ist noch ein anderer wichtiger Punkt. Und hier ist jetzt auch noch eine Cleanup-Methode als Beispiel.
11:02
Das haben wir für uns auch so, oder das ist sogar krass offiziell, best practice, dass man eine Cleanup-Methode entwickelt, die dann am Ende auch aufgerufen wird. Das heißt, wenn dieses Addon ausgeführt wird, egal ob erfolgreich oder mit Fehler, dann wird auf jeden Fall diese Cleanup-Methode nochmal aufgerufen, dass man nicht irgendwelche temporären Dateien da noch rumliegen hat.
11:28
Genau, hier sieht man jetzt auch noch, wie immer noch nicht, aber krass script. Das ist auch noch ein sehr mächtiger Teil, wenn man in Python was mit krass machen möchte.
11:41
Das kann man auch einfach importieren und dann viele verschiedene vorgefertigte Funktionen benutzen. Das ist auch noch mal ein Link, was da alles dabei ist. Als Beispiel kann man damit zum Beispiel andere krass Module aufrufen. Also ich kann in meinem Addon sagen, ich möchte jetzt diese und jene Module aufrufen
12:01
und kann dann mit dem Output was machen oder auch mit den erzeugten Karten was machen. Man kann auch Messages drucken, also man kann Warnings ausgeben oder auch Fehler. Wenn man zum Beispiel Krass Fatal benutzt, dann beendet sich auch automatisch das Modul.
12:23
Genau, der Aufruf ist ein bisschen ähnlich, wie wenn man die Commando-Zeile benutzt, wenn man das kennt. Da kann man dann auch mit Krass Pass Commands zum Beispiel arbeiten und dann das Modul so aufrufen, wie man möchte. Und noch eine Sache ist die Internationalisierung. Wenn man diese Sprachausgabe benutzt, da sieht man jetzt diesen Unterstrich.
12:44
Der mag ein bisschen ungewohnt erscheinen. Der ist dafür da, dass man das auch einfach in andere Sprachen übersetzen kann und krass dann erkennt, an welchen Stellen was übersetzt werden müsste oder könnte. Okay, dann haben wir jetzt einen Zwischenstand.
13:00
Wir können schon oben diesen Header schreiben. Dann haben wir die Dinge, die aussehen, die Kommentare von dem Krass Passer, wo wir angeben, was Inputs und Outputs von unserem Modul alles sein können. Dann können wir mit Krass Script mit dem Import arbeiten und Nachrichten ausgeben, andere Krass Module aufrufen oder auch andere Dinge.
13:25
Und dann haben wir die Main Funktion. Das habe ich eben, glaube ich, vergessen zu erwähnen. Da ist nämlich dieser Krass Passer in der Main Funktion nicht, aber da, wo sie unten aufgerufen wird. Davor wird eben der Passer aufgerufen, um die ganzen Optionen einlesen zu können.
13:44
Dann kann auch die Cleanup-Module aufgerufen werden und dann geht es quasi los mit dem Addon. Und so, wie das jetzt bei uns aussieht. Wir können das jetzt installieren. Ich habe da jetzt nicht alle Zeilen hingedruckt, aber da kommen jetzt nicht mehr die Warnings wieder vor.
14:02
Dadurch, dass wir eben den Krass Passer zum Beispiel aufgerufen haben. Und wenn wir jetzt TFORSCIS FORTUNE minus minus help aufrufen, bekommen wir schon automatisch die Hilfe generiert, wo man sieht, wie man das benutzen kann, welche Parameter notwendig sind oder nicht, welches es alle gibt, welche Flex.
14:22
Und eben diese Ansicht, wie das zu benutzen ist. Da ist mir eben bei Markus' Vortrag aufgefallen, dass ich schon sehr auf die Kommandozeile fixiert bin. Und ich hätte da jetzt natürlich auch einen schönen Screenshot von der GUI reinmachen können. Aber da habe ich einfach nicht dran gedacht. Aber dadurch, dass das eben so definiert ist, würde das jetzt auch in der Oberfläche mit CRASCIS schon erscheinen.
14:45
Und da würden auch die Input und Output Parameter und Flex alle schon sichtbar sein. Genau, und dann können wir das Motul aufrufen. Und da wurde ja FORTUNE installiert, was einfach einem schöne Sprüche ausdruckt.
15:02
Und das funktioniert jetzt auch. Also haben wir jetzt schon unser erstes CRASCIS-Wertung geschrieben. Gut, dann war das jetzt der Exkurs in die Konzepte und Praxis. Und dann kommen wir jetzt noch zu Verbesserungen, die man machen kann.
15:22
Da gibt es zum einen, das haben wir auch auf GitHub, wiederverwendbare Workflows. Also wir finden das einfach praktisch, die auf GitHub liegen zu haben. Dann kann jeder sie weiterverwenden. Und wir haben einfach schon einen Haufen Tools, die man dafür nehmen kann, um Qualitätssicherung zu machen.
15:41
Da haben wir zum einen Linting Workflows. In rot sind jetzt die ganzen neuen Dateien, die dazugekommen sind. Das ist jetzt erst mal fast doppelt so viel, wie wir vorher hatten. Aber da ist halt eine Beispiel-Konfigurationsdatei zum Linden. Das bedeutet, ich darf maximal so viele Zeilen in einer Zeile haben, dass es leserlicher wird.
16:04
Oder bestimmte andere Regeln, Leerzeichen, vor und nach Kommata, Doppelpunkt und so weiter, was man alles prüfen kann. Und unten sieht man dann den Workflow. Das ist hier die Linting-Yaml in dem Fall. Da kann man dann einfach Users, mundiales GitHub Workflows und dann den Fahrt zu dieser Linting-Yaml,
16:23
bei sich selbst in dem Addon einfügen. Und dann wird das automatisch verwendet. Also bei uns ist die Linting-Yaml schon, ich weiß nicht wie lang die ist, aber da ist halt Flag8 drin, Pylint, Markdown-Lint, also verschiedene andere Linter schon kombiniert. Da muss man sich quasi nicht mehr drum kümmern.
16:41
Und wir versuchen auch die Regeln zu nehmen, die Kraskes selbst im Source, also im Hauptrepo verwendet, dass wir dazu eben kompatibel sind. Dann relativ nah verwandt. Da gibt es noch die Pre-Commit Hooks.
17:01
Weil das sehr oft passiert ist bei uns, dass wir diese Linting-Workflows eingeführt haben. Kommitted, Pipeline schlägt fehl, nächster Commit, Linting. Das ist eigentlich so ein Klassiker. Und dann haben wir irgendwann einen Pre-Commit eingeführt, weil es bedeutet, dass man das bei sich lokal installiert. Und wenn man dann commited, dann läuft das lokal schon durch.
17:22
Und dann sieht man, ich habe irgendeinen Linting-Fehler. Da muss ich nochmal irgendwie was verbessern. Und es geht nicht erst nach GitHub. Und dann muss man dann noch einen neuen Commit machen. Genau, das kann man eben auch. Da sind auch in diesem Refo erklärt, wie man das bei sich einbinden kann.
17:41
Und noch Renovate, das aktualisiert automatisch die Version. Das ist auch ganz praktisch, dann veraltet das nicht, sondern man kann das selbst immer aktuell halten dadurch. Und noch ein letzter Workflow, das sind die Tests. Hier in rot sieht man jetzt, wie das im Addon aufgebaut sein kann, dass man einen Test schreibt.
18:01
Test A, das habe ich nicht unbenannt. Test For Example Pie. Da wird dann, wenn man diesen Workflow verwendet, das auch automatisch aufgerufen und dann läuft der Test durch. Und dann noch eine Sache, die Kraskes Helpers. Das ist eine Bibliothek, die wir auch auf GitHub liegen haben,
18:22
die gerne jeder auch mitverwenden kann. Und auch unten steht Contributions Welcome. Also gerne mal durchgucken, ob da was für die eigenen Addons gebraucht werden können. Und auch gerne zurückcontributen. Also nicht, dass ganz viele Kopien irgendwann irgendwo rumliegen, die ein bisschen angepasst sind. Dann lieber einmal refrakturieren und wieder zurückspielen.
18:42
Dann haben ganz viele was davon. So, dann versuche ich noch. Wrap up. Ganz kurz. Wir haben ein paar Minimalbeispiele erstellt. Dann haben wir ganz viele Konzepte gesehen. Den Paser zum Beispiel oder auch das Skript, um das zu einem richtig ausgereiften Kraskes Addon zu machen.
19:05
Und zum Schluss noch ein paar Dinge, die man, wenn man GitHub nutzt, verwenden kann. Workflows automatisiert, die einem schon ein bisschen Arbeit abnehmen und Tests starten. Dann noch zum Schluss Addons von uns in einer Minute.
19:23
Auf GitHub haben wir 38 Addons liegen, wobei da auch, das habe ich noch gar nicht angesprochen, die Multimodule existieren. Das heißt, das ist ein übergeordnetes Modul, was noch verschiedene zusammenfassen kann, die man häufig zusammen benutzt. Da gibt es auch eine Landingpage für,
19:40
die man da als Screenshot sieht. Da kann man sich auch gerne mal durchklicken, ob da irgendwas dabei ist, was man gebrauchen kann. Und vielleicht erinnern Sie sich noch an das Sternchen ganz am Anfang der Präsentation. Ich habe gesagt, es gibt offizielle Addons und es gibt ganz viele, die man nicht finden kann, weil man nicht weiß, wo sie sind. Und deshalb die Bitte, das Tag Kraskis Addons zu verwenden.
20:03
Weil damit kann man auf GitHub suchen und man kann ganz GitHub durchsuchen. Das habe ich letzte Woche gemacht. Wir machen das ganz viel. Und sonst habe ich sechs weitere Addons gefunden auf ganz GitHub, die dieses Tag verwenden. Dann noch Beispiele. Ein Modul, was alte Corona-Spionagesatelliten
20:23
prozessieren kann. Und die Orthoretifizierung macht. Ein Addon, womit man Dateien berechnen kann in Kraskis und sie dann über die KrassRest API veröffentlichen kann als Layer, als Image-Mosaik. Oder auch in einem Krass-Raster-Geo-Server-Raster-Geo-Store.
20:41
Data-Store. Der auch Open Source ist, den wir noch viel zu wenig verwenden. Der quasi den Geo-Server oder die Daten im Geo-Server in Krass gucken lässt. Und man muss sie nicht als Geo-Tiff oder so exportieren. Und zum Beispiel haben wir auch noch Dinge mit Alkes, wie man Alkes-Daten runterladen kann.
21:04
Ja, damit komme ich zum Schluss. Und vielen Dank für Ihre Aufmerksamkeit. Und haben Sie Fragen. Wunderbar. Vielen Dank, Carmen.
21:20
Also ich habe schon mal drei Fragen gerade online. Und dort würde ich zuerst mal eine vorziehen, die ziemlich allgemein gehalten ist. Dann habe ich noch zwei spezielle. Dann gibt es vielleicht im Raum auch noch Fragen. Die allgemeine ist, warum sollte man ein Grasges-Add-on schreiben, anstatt beispielsweise ein Kyogis-Add-on? Was sind da die Vorteile?
21:42
Da hoffe ich, dass der oder die Fragesteller bei Markus schon zugehört hat. Da muss ich nicht mehr so viel erklären. Also Grasges hat ja viele spezielle Prozessierfunktionen. Ich kenne mich da in Kyogis jetzt nicht so gut aus. Aber die einfach da in diesen Workflow sehr gut reinpassen.
22:01
Und dann macht es natürlich Sinn, in diese Prozesskette einfach verwenden zu können. Oder eine andere Sache wäre, wenn man Actinia zum Beispiel verwenden möchte, dann kann man das auch mit einem Grasges-Add-on machen und einer Prozesskette. Ja. Kommt auf den Anwendungsfall einfach drauf an.
22:21
Alles klar. Wolltest du, Markus, dazu noch was sagen? Okay, gut. Dann habe ich den Blick nicht richtig interpretiert. Dann kurz der Blick in den Raum. Gibt es hier etwas, was noch nicht online steht? Das sieht nicht so aus. Okay, dann direkt weiter.
22:42
Wie findet man denn heraus, in welcher Grasfamilie ein Add-on eigentlich reingehört? Stimmt, da habe ich, glaube ich, irgendwas zu kurz gesagt. So, gucken wir mal, ob ich die Schnelle finde.
23:16
Nee. Bist ihr das noch?
23:32
Also... Ah, ja. Da, genau. Das habe ich, glaube ich, übersprungen.
23:43
Da steht als Liste, was es alles gibt. Das sind alles Abkürzungen. Also V für Vektor, R für Raster, Db für Datenbank, E für Imagery und so weiter. T für Time. Und im Prinzip geht es darum,
24:01
die Hauptfunktion des Moduls zu vielleicht benennen und dann zu überlegen, was da am besten passen könnte. Also, ja. Und vielleicht als Follow-up. Also hier die Liste, da ist dann zum Schluss mit Punkt, Punkt, Punkt. Gibt es irgendwo die Übersicht, welche Familien es insgesamt gibt?
24:21
Also, ich habe unten die Abkürzung aufgelistet. Und oben, das sind quasi vier Beispiele, wo der Name dran steht, was die Abkürzung quasi bedeuten soll. Aber, ja. Okay, genau. Das steht auch im Haupthandbuch drin. Dann habe ich noch eine. Nämlich habt ihr auch Anleitungen, wie man Add-ons in C schreibt.
24:45
Da schiebe ich mal darüber. Ja, die gibt es allerdings nicht. Jetzt direkt von uns, von Mundialis. Die gibt es schon viel länger. Und die sind in direkt Gras-Core auch drin. Da gibt es auch diese Beispielmodule.
25:01
Eins für Rasterverarbeitung und eins für Vektorverarbeitung. Die sind in C geschrieben und beschreiben so die grundsätzlichen Abläufe, wie man eben mit den direkten C-Funktionen auf Raster- oder Vektordaten zugreifen kann. Das Prinzip ist genau das Gleiche, auch was Carmen jetzt zum Beispiel zu dem PASA erzählt hat.
25:20
Da werden genauso Optionen und Flex definiert. Und als Anwender, als User später, sieht man eigentlich gar nicht, ob es jetzt ein Python oder ein C-Modul ist, das man gerade benutzt. Die in der Handhabung verhalten, die sich genau gleich. Und die Beispiele, die Anleitungen dafür, gibt es eben schon seit vielen Jahren direkt in Gras-Core.
25:43
Okay, alles klar. Vielen Dank. Dann habe ich eine allerletzte Kleine noch. Nämlich kann ich in einer Main-Funktion andere externe Python-Pakete, zum Beispiel NumPy, einbinden? Ja, also Python-Best-Practices ist ja,
26:03
die Importe nicht in der Main Funktion zu machen, sondern als Import oben. Ist ja auch irgendwo hier. Ich habe hier zum Beispiel auch Fortune importiert.
26:23
Da ist keine MainPy, hier. Also oben ist der Import von GrasScript. Und in dem Beispiel habe ich jetzt Fortune in ein Try-Accept gepackt, falls halt lokal das nicht installiert ist, dass es halt eine Fehlermeldung gibt. Und in der Main wird das dann aufgerufen. Also ja, kann man durchaus machen.
26:43
Okay, alles klar. Dann sind wir mit den Fragen online durch, wenn es im Raum auch nichts weiter gibt, wonach es nicht aussieht. Und dann nochmal vielen Dank für den Vortrag, vielen Dank für die ganze Session. Ja, vielen Dank.