We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Stand des GRASS GIS Projekts: Nicht was Sie denken!

00:00

Formal Metadata

Title
Stand des GRASS GIS Projekts: Nicht was Sie denken!
Title of Series
Number of Parts
119
Author
Contributors
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
In unserem Vortrag geben wir einen Überblick über die neuesten Entwicklungen und Fortschritte des GRASS GIS Projekts, das im Sommer 2023 sein 40-jähriges Jubiläum feierte. Der Fokus liegt darauf, Missverständnisse rund um das Projekt aufzuklären und die tatsächliche Vielseitigkeit und Modernität der aktuellen GRASS GIS Version zu verdeutlichen. Der Vortrag wird einige häufige Missverständnisse ausräumen, wie z.B. "es ist nur eine Kommandozeile", "es ist nur ein Desktop GIS" und mehr.
Keywords
14
67
Grass (card game)CONSULTANT <Datenbank>Gastropod shellWorld Wide WebAPIPlotterDegree (graph theory)Processing <Programmiersprache>Game theoryZoom lensGraphical user interfaceGrass (card game)Process (computing)Projective planeSoftware engineeringSoftware developerFunctional (mathematics)Service (economics)Single-precision floating-point formatElectronic visual displayMenu (computing)Heat transferOrder (biology)WindowMereologyParameter (computer programming)Series (mathematics)Connected spaceWeb browserView (database)Physical systemFocus (optics)Representation (politics)User interfaceOpen sourceChainData managementStatisticsCodeResultantVideo gameComputer programmingInterface (computing)FunktionalitätSeries (mathematics)Statement (computer science)Processing <Programmiersprache>StatisticsBerechnungProgramming languageGraph of a functionUniformer RaumSource codeComputer animationLecture/Conference
Grass (card game)Gastropod shellLevel (video gaming)Endliche ModelltheorieNeuroinformatikInterface (computing)Scripting languageOperator (mathematics)Physical systemCalculationStatisticsPoint cloudVector spaceFlow separationProcess (computing)Raster graphicsBitImage resolutionScripting languageSystems <München>StatisticsComputer animationLecture/Conference
Django <Informatik>APIPoint cloudDesktopGrass (card game)Project <Programm>Projective planeMultiplication signSimulationPhysical systemPoint cloudExtension (kinesiology)Field (computer science)BitDatabaseComputer programmingRepresentational state transferCodeRoutingUniform resource locatorStudent's t-testSoftwareUniverse (mathematics)SurfaceWebsiteSoftware developerPoint cloudUniformer RaumGoogleField extensionProject <Programm>Lecture/ConferenceComputer animation
Grass (card game)Physical systemInternetworkingSoftwareSoftware developerOpen sourceSystems <München>InternetComputer programming
Grass (card game)Lattice (order)ResultantBitMixture modelCodeMischung <Mathematik>Computer animation
Grass (card game)Projective planeComputer animationLecture/Conference
Source codeGrass (card game)Open sourceData miningCombinational logicComputer animation
Air-start systemGrass (card game)Contribute <Programm>Absolute valueSource codeGcc <Compiler>CodeSource codeOpen sourceStandard deviationPhysical quantityC++CodeSound effectSoftwareCompilerAutomationSoftware developerSet (mathematics)Computer programmingComputer programmingOpen setLine (geometry)File formatHookingLattice (order)Computer fileBitGrass (card game)Entire functionLevel (video gaming)Constructor (object-oriented programming)Term (mathematics)Computer animationSource codeLecture/ConferenceXML
Grass (card game)ChainRepresentational state transferProcess (computing)Descriptive statisticsComputer animation
DemosceneData analysisUser interfaceGrass (card game)AdditionProjective planeGroup actionMereologyCore dumpGraphical user interfacePermanentPhysical systemMoment (mathematics)Open sourceWeb browserSoftware developerWikiData analysisCapability Maturity ModelCalculationCASE <Informatik>SphereWebsiteLink (knot theory)Interface (computing)Vector spaceGrass (card game)INTEGRALContext awarenessDescriptive statisticsRaster graphicsRevision controlField (computer science)Endliche ModelltheorieCondition numberCodeoutputLattice (order)SoftwareMultiplication signWater vaporExpert systemCodeComputer programmingStaff (military)NeuroinformatikSelf-organizationStudent's t-testNumberLimit (category theory)Extension (kinesiology)Direction (geometry)Different (Kate Ryan album)MathematicsEvent horizonBitOnline chatGeographic information systemWritingSage <Programm>CalculationJames <Programm>AlgorithmUniformer RaumSystems <München>Eigenvalues and eigenvectorsWeb pageGrand Unified TheoryInterface (computing)Row (database)Field extensionComputer animationLecture/Conference
Ich freue mich sehr darauf, Markus Nethelaar hier zu begrüßen für die Session zum Thema Gras Gresgis und den Neuerungen, die dabei passiert sind und übergebe sehr gerne das Wort und das kann umgeschaltet werden.
Wunderbar. Aus der Reihe, also guten Morgen nochmal online, aus der Reihe Stand der OSGEO-Projekte mit Fokus auf Gras Gis in diesem Fall.
Ich stelle also vor den Stand des Gras Gis-Projekts und zwar mit besonderem Hinblick auf Mythen, die es so weiterhin hartnäckig gibt und die vielleicht gar nicht mehr wahr sind. Ich bin also hier als Repräsentant des Projees der Projektleitungsgruppe, Project Steering Committee hier und habe natürlich den Talk nicht ganz alleine vorbereitet.
Seit acht Jahren wohne ich wieder in Deutschland, habe die Firma Mundialis mitgegründet in Bonn, war da vor 15 Jahren als Wissenschaftler in Italien in Trento an einem Forschungsinstitut beschäftigt, habe aber schon mein ganzes Leben mich mit Open Source Gis beschäftigt und insbesondere natürlich mit dem Gras Gis-Projekt.
Ganz wichtig ist beim Gras Gis-Projekt, dass es sich eben um ein Community-Projekt handelt, auch wenn manche von uns vielleicht Firmenhüte aufhaben oder an der Uni arbeiten, im Endeffekt oder Freelancer sind, was auch immer, im Endeffekt ist es die Community, die das Projekt weiter treibt.
Hier auf dem Foto, das haben wir im letzten Jahr beim 40. Geburtstag gemacht in Prag, um den 40. Geburtstag des Projektes zu feiern. Die dienstälteste Entwicklerin, die da sitzt auf dem Bild, ist auch erst seit 1990 dabei gewesen,
das heißt, kam zwölf Jahre später, als das ganze Projekt überhaupt gestartet hat. Was ist Gras Gis heute, möchte ich stellen und eben ein paar Mythen aufzeigen. Hartnäckigst, was mir so die letzten vielen Jahre aufgefallen ist, dass gesagt wird, Gras ist doch nur Kommandozeilen-Gis.
Natürlich ist es so, Gras hat immer noch die Kommandozeile, weil wir sie auch gerne brauchen und gerne behalten möchten, aber es ist auch ein Desktop-Gis. Es gibt seit einigen Jahren eine komplett neu geschriebene Benutzeroberfläche, die jetzt inzwischen auch als Einzelfenster-System, also Single-Window, sich darstellt. Man kann die einzelnen Teile immer noch dekomponieren, wenn man das möchte,
aber viele sind doch sehr zu Hause, wenn alles in einem Fenster sich befindet. Welche Möglichkeiten der Nutzung haben wir? Wir haben natürlich nicht nur die Nutzung Desktop- oder Kommandozeile, sondern es gibt noch viele weitere Möglichkeiten, die ich kurz zeigen möchte.
Einmal die Python-API, man kann also über Python Gras benutzen, Berechnungen anstellen und das Ganze auch visualisieren. Hier ein Beispiel für ein Jupyter Notebook, für alle, die Jupyter Notebooks nicht kennen, die werden wir auch morgen unter anderem im Workshop zeigen. Es gibt die Möglichkeit, in einem Browser zu arbeiten
und entsprechend einzelne Befehle einzugeben in dem Browser und dann ausführen zu lassen. Und darüber ist es sehr einfach, Code und Erklärung und grafische Darstellung miteinander zu verknüpfen. Dann gibt es das Interface zur R-Statistischen Programmiersprache.
Das wurde auch nochmal in den letzten zwei Jahren komplett renoviert, um auch quasi mit den Neuerungen, die im R-Projekt stattfinden, weiterzumachen und weiterzukommen, um da die Kompatibilität zu halten. Hier ist nur ein Beispiel, wie man aus einer Gras-Session die R-Session startet,
das kann auch R-Studio sein oder was auch immer. Und dann kann man entsprechend hin und her agieren, die Daten von einem System ins andere transferieren, die statistischen Analysen machen, zum Beispiel die Ergebnisse wieder zurückschreiben usw. Gras kann natürlich nicht alles, was R kann, umgekehrt ist es genauso. Gras ist ja auch dafür bekannt, extrem schnell zu sein für viele Analysen
und insofern kann man das hier komplementär verarbeiten. Für die Menschen, die gerne mit Kugis arbeiten, gibt es natürlich weiterhin das Processing Interface. Das heißt, hier im Menü ist Processing und da entsprechend viel Funktionalität dargestellt.
Sie ist auch zum Teil vereinfacht worden in einem Sinne, dass vielleicht im originalen Grascommando sehr viele Parameter sind, die hier aber noch mal thematisch unterteilt wurden, sodass man da sehr schnell navigieren kann. Auch hier gibt es auf Kugis-Seite einige Neuerungen, die im Hintergrund stattfinden, um quasi die Komplimität zwischen den Versionen beizubehalten,
sodass neues Kugis auch mit neuem Grasakt weiterarbeiten kann. Auch wenn teilweise immer noch Gras 7 bei paketierten Versionen dabei steht, das funktioniert genauso mit Gras 8, weil wir im Grasprojekt eben auch extrem auf Kompatibilität in Rückwärtsrichtung achten,
sodass quasi nicht, dass es sehr unwahrscheinlich ist, dass irgendwelche Systemprozessketten usw. kaputt gehen. Kommandozeile hatte ich schon genannt, die gibt es tatsächlich noch. Die benutzen wir intensiv, um Rechenoperationen durchzuführen,
die mehrere Schritte zum Beispiel beinhalten oder die dafür da sind, um große Datenmengen zu verarbeiten. Man kann Dinge oft automatisieren. Es gibt in Gras auch einen grafischen Modellierer. Da habe ich jetzt keinen Screenshot für, mit dem man quasi sich den Arbeitsfluss zusammenklicken kann
und das Ganze dann als Python-Script exportieren. Seit kurzem gibt es auch die Möglichkeit, das für Actinia als Cloud-Prozesskette zu exportieren. Den komme ich gleich noch zu usw. Wir achten immer sehr darauf, dass die Schnittstellen zu anderen Systemen gegeben sind. Es gibt auch noch den Exec-Befehl hier, der ist vielleicht ein bisschen spezieller,
aber da könnte man diese Schritte, die da zu sehen sind, lese eine Vektorkarte oder setze die Berechnungsregion auf eine Vektorkarte, setze eine Rasterauflösung und anschließend importiere eine Punktwolke da rein mit statistischer Analyse. Das kann man sich eben auch als Script speichern
und dann einfach in Zukunft automatisiert ausführen. Und das Ganze ist natürlich noch spannender, wenn jetzt diese Scripte noch ein bisschen länger sind. So, auf die Cloud bin ich kurz schon eingegangen. Da werden wir morgen eben auch einen Workshop zu veranstalten zu Actinia. Actinia ist eine REST-API um Grasgis drum herum.
Und es ist auch nicht nur auf Grasgis beschränkt, sondern da drin stecken natürlich noch GDAL und die Projektionssoftware, ESA Snap beispielsweise, man kann auch alles Mögliche weitere reinstecken, um sozusagen um dieses Arbeitspferd eine REST-API drum herum zu haben und dann entsprechend programmieren zu können.
Als Erweiterung gibt es von der Firma Open Plains noch eine Software, eine Actinia-Erweiterung, die Django-basiert ist, um grafische Oberflächen erstellen zu können. Das wird auch teilautomatisch gemacht. Und es gibt einige Simulationserweiterungen, die sehr spannend sind, zum Beispiel im Bereich urbaner Entwicklung,
wie entwickelt sich eine Stadt in die Zukunft, also Simulation dahingeht. So, die grafische Oberfläche ist noch weiter modernisiert worden, das geht kontinuierlich weiter. Die ist original mal aus einem Google Summer of Code Project entstanden, von einer Studentin geschrieben worden,
die inzwischen mit der Uni studierenden Laufbahn durch ist in Prag. Und entsprechend viele weitere Leute haben darin programmiert. Beim Start von GRAS wird jetzt ein Projekt geladen sofort. Die, die schon länger GRAS gesehen haben, können sich vielleicht noch vage an diesen Begrüßungsbildschirm erinnern, den gibt es schon länger nicht mehr.
Und GRAS startet letztlich auch, wie andere GISS-Systeme auch. Wir werden jetzt die Terminologie noch ein bisschen modernisieren. In GRAS wird immer von Location und Mapset gesprochen. Das ist einerseits korrekt natürlich, aber andererseits auch vielleicht ein bisschen achtziger.
Und daher sind wir gerade dabei, vorsichtig durchzugehen, denn wir wollen natürlich auch nicht die gesamte Dokumentation neu schreiben müssen, sondern das vorsichtig anzupassen, dass Location in Projekt umbenannt wird. Mapset wird wohl erst mal so bleiben. Und dann hat man eben die Struktur, das ist jetzt hier als Verzeichnis mal gezeichnet,
da sind alle Daten drin, Datenbank. Dann das Projekt, meinetwegen Stadt Hamburg und unter Projekt Neuer Radweg heißt erst mal noch weiterhin Mapset. Und wird wahrscheinlich dann in Subproject oder irgendwas geniales, Vorschläge willkommen, umbenannt. So, auf den Geburtstag bin ich vorhin schon eingegangen.
Es ist schon wirklich eine Seltenheit, dass eine Software 40 Jahre alt ist und open source ist. Denn wir erinnern uns vage, in den 80ern war das Internet zum ersten gar nicht da oder jedenfalls nicht in dieser Form. Und WWW ist seit Anfang, Mitte der 90er Jahre da. Das heißt, das passierte schon 10, 15 Jahre,
bevor überhaupt diese heutzutage üblichen Internetmethoden und Systeme existiert haben, gab es schon Softwareentwicklung. Community-Feste sind immer sehr interessant. Wir sehen hier die Mischung aus Coden und Feiern. Das ist also eine Sache, die wir gerne jedes Jahr machen.
Und sofern möglich natürlich. Und bei diesen Treffen, die international sind, kommen immer sehr tolle Ergebnisse heraus, weil man natürlich, wie wir alle wissen, in Personatreffen noch mal möglicherweise ein Stück produktiver sind. So, ich habe ja von Alter gesprochen.
40 Jahre, das ist schon was. Was bedeutet das denn? Gibt es zum Beispiel ein Projektbudget, das immer so sprudelt und alles finanziert? Wenn es schon so lange existiert, dann müsste das ja eigentlich so sein. Könnte eine Idee sein. Die Realität sieht ja so aus. Die Bagger mit kleinen Kindern daneben.
Meine sind inzwischen schon ein bisschen größer, die malen woanders. Aber diese Kombination ist durchaus gang und gäbe. Und letztlich ist das jetzt hier die dritte Generation, die vielleicht irgendwann auch mal in Open Source Giz sich betätigen wird, wissen wir noch nicht. Aber das Ganze führt dann auch zu tollen Ergebnissen.
Hier sehen wir einen Hinweis auf den NSF Grand Pose. Das NSF ist sowas wie die Deutsche Forschungsgemeinschaft für die USA, die National Science Foundation. Und die hat tatsächlich eine große Förderung genehmigt. Leider mit dem Haken, dass sie nur in den USA verwendet werden kann.
Ein bisschen schade für die Europäer. Aber wir müssen glaube ich auch noch ein bisschen besser werden, was die relevante Förderung von Open Source Softwareentwicklung ist. Also auf EU-Ebene. Es gibt schon einige Dinge vielleicht auf nationaler Ebene, aber da geht bestimmt noch mehr. Die Idee ist hier, dass Infrastruktur verbessert werden soll und dass auch die Richtlinien für Beiträge überarbeitet werden sollen.
Was bedeutet das? Im Endeffekt müssen wir immer darauf achten, dass der Source Code zum Beispiel lizenzkompatibel ist. Und wenn jetzt externe Beiträge kommen, dann müssen die natürlich lizenzkompatibel bleiben. Sonst kriegen wir ein Problem mittelfristig. Und der Aufbau von Community, der Gemeinschaft,
das geht natürlich immer weiter und da muss auch immer wieder was gemacht werden. Wichtig ist zu sagen, dass der NSF-Grant keine Finanzierung ersetzt, steht explizit drin. So, deshalb haben wir parallel, ganz neu ist es nicht mehr, aber relativ neu über Open Collective, das ist eine Spendensammelplattform, etwas gestartet,
wo eben gespendet werden kann. Und wir würden uns natürlich sehr freuen, wenn das auch passiert. Das kommt dann nicht den Entwicklern und Entwicklerinnen privat zugute, sondern das wird eben für Treffen usw. benutzt. Ja, und da kann man sich entsprechend betätigen. So, Mythos Alter Source Code, 40 Jahre Source Code.
Na ja, die Standards haben sich schon ein bisschen geändert. Was ist denn da so passiert? Da haben wir einiges gemacht in den letzten Jahren. Es sind tatsächlich über 3000 C- und C++-Dateien überarbeitet worden, damit sie mit modernen Compilern gut zusammenarbeiten, keine Warnings existieren, keine überraschenden Effekte auftreten
bei der Verwendung der Software. Und das Ganze ist auch automatisiert worden. Das heißt, wenn heutzutage neuer Source Code in das Projekt geladen wird, das geht natürlich nicht direkt, sondern macht das mit sogenannten Pull Requests in Git, dann wird auch automatisch gleich kontrolliert, ob der Code konform ist zu den Richtlinien.
Und das ist sehr einfach, man lernt auch eine Menge dabei, da wird nämlich angezeigt, an dieser Stelle ist die Formatierung nicht richtig, oder hier ist was undefiniert oder wie auch immer. So, das Ganze haben wir auch für Python gemacht. Ein Drittel des Source Codes ist ungefähr Python, zwei Drittel sind C und C++.
Die selbe Arbeit auch hier. Python ist natürlich eine andere Sprache, entsprechend sind die Tools anders, aber im Großen und Ganzen auch hier Automatisierung der Workflows. Das ist auch für die Langzeitpflege der Software sehr wichtig, dass wir da quasi die Standards hochhalten und erst mal überhaupt, wir reden von ungefähr einer Million Zeilen,
Source Code insgesamt, diese eine Million dahin bekommen. So, Features, ein paar versteckte Dinge, die man so nicht unbedingt mitkriegt. Die Leute, die hier in Python programmieren oder gerne programmieren möchten, die haben es jetzt deutlich einfacher. Mit drei Zeilen kann man also eine gesamte Grassession starten
und dann in Gras arbeiten. Mehr ist jetzt inzwischen nicht mehr notwendig, das ist neu und vereinfacht worden. Was auch relativ neu ist, ist die Beschreibung aller Kommandos mit JSON. Das heißt, wenn ich an einem Befehl – JSON dranhänge, dann wird das Ganze in JSON übersetzt
und das Ganze kann in Prozessketten und REST APIs und sonst was verwendet werden. Datenanalyse Workflows mit Jupyter hatte ich vorhin schon genannt, morgen eben wie gesagt ein Workshop dazu. Das Ganze ist wirklich sehr schön zu benutzen in einem Webbrowser, mehr braucht man nicht. Dieses Beispiel lässt sich auch hier ausprobieren,
braucht man nicht zu installieren. Das ist eine Binder-Online-Version von der Grass-Software mit der entsprechenden Beispiele. So, noch zwei Dinge am Schluss. Wir haben ein Mentoring-Programm, weil wir natürlich immer wieder neue Leute heranführen wollen an die Software
und natürlich auch gerne gezeigt werden soll, wie man gute Software schreibt, unter der Annahme, dass das bei uns der Fall ist. Aber wir haben wirklich einige Expertinnen und Experten im Team, die da sehr kompetent sind und zeigen auch, wie man in eigene Arbeitsabläufe Gras reinbekommen kann. Das Ganze wird auch durch diese NSF-Förderung mitgestützt.
Das heißt, es ist Personal angestellt worden an der Uni von North Carolina, die sich jetzt explizit darum kümmern können. Und wir haben ein Stipendienprogramm, was auch freundlicherweise vom Foskis e.V. mitfinanziert wird, um quasi so ähnlich wie bei Google Summer of Code, falls das jemand kennt,
für einen begrenzten Zeitraum einige Euros zur Verfügung stellen zu können, damit eine Person sich mit einem bestimmten Thema beschäftigt. Und vieles davon, was wir hier sehen, wird oft über solche Dinge getan. Das sind Studierende beispielsweise, ist aber nicht notwendig, Studierende zu sein, kann sich aber auf ein Stipendium bewerben.
So, und dann haben wir noch neue Arbeitsgruppen, die auch im Rahmen dieser Förderung entstehen gerade. Die vier Gruppen sind Geoprocessing Engine, also wie verarbeite ich Software, gute Nachbarn sein im Open-Source-Ökosystem. Das halten wir für extrem wichtig.
Wir haben vorhin schon gesehen, wie die einzelnen Projekte ineinander verzahnt sind, und das soll natürlich auch so bleiben. Dokumentation, Dauerbrenner natürlich, und Förderung der Gemeinschaft. Was kann man an Community Sprints und sonstigen tun? Auf der Wiki-Seite übrigens sind die Folien auf der Pre-Talk-Seite unten schon verlinkt.
Da kann man drauf gehen und gucken. Da kann man sich weiter informieren. So, und allen Interessierten stellen wir dann eine Lifetime-License zur Verfügung. Oben ist die Webseite und wir haben den nächsten Community Sprint geplant, jetzt im Juni wieder in Prag. Der ist offen, also wir würden uns freuen, vielleicht kommen ja Interessierte hin.
Es geht auch nicht nur ums Programmieren, es geht um alles Mögliche, was sich in diesem Kontext bewegt und sehr gerne auch andere Projekte, QGIS, AR, was auch immer, um eben die Zusammenarbeit gut hinzubekommen. Ja, und damit danke ich für die Aufmerksamkeit.
Wir haben noch Zeit für Fragen wahrscheinlich. Genau, wunderbar. Vielen Dank, Markus. So, wir haben in Online-Belle des Chats aktuell gar nichts drin. Deshalb die Frage jetzt hier in den Raum.
Gibt es denn momentan Fragen, die wir so äußern wollen? James ist da, hat ein Mikrofon. Organisatorisch ist wichtig, dass die Fragen ins Mikrofon gesprochen werden. Aber, ja, sehr schön.
Vielen Dank für den Vortrag. Wenn du vielleicht sagen könntest, oder ich weiß nicht, in zwei, drei Sätzen irgendwie so, wie grenzt sich Gras, sagen wir, oder wo ist der Unterschied zwischen Gras und QGIS, sagen wir, oder wo liegen die Stärken von Gras, irgendwie QGIS jetzt nicht abdeckt oder andersrum etc.
In die Richtung. Ja, eine Frage, die immer wieder gestellt wird und die sich, wo die Antwort sich auch jedes Jahr ändert. Sag mal so, Gras, wie schon gehört, existiert ja deutlich länger, was erstmal gar nichts heißt. Ich glaube, die Zielgruppen sind vielleicht leicht, die überlappen sich, aber sie sind nicht identisch.
Und Gras ist, würde ich jetzt erstmal so als echtes analytisches Geoinformationssystem betrachten, mit einer sehr starken Rastavektor und so weiter Zeitreihenverarbeitung, die für, was weiß ich, Copernicus Sentinel-Daten geeignet ist und andere Dinge. Und das finden wir natürlich zum Teil in QGIS auch, das ist richtig. Aber ich glaube, bei bestimmten Algorithmen sind, sag mal so, könnte es sein, dass die noch,
wir haben ja auch QGIS-Leute hier im Raum, und es geht um das friedvolle Miteinander. Also ich möchte jetzt gar nicht mal unbedingt sagen, Gras ist hier besser und QGIS ist da besser. Das ist teilweise so, aber ich glaube, dass bestimmte Dinge wie zum Beispiel Rechengeschwindigkeit
und Ausgereiftheit von bestimmten speziellen Fragestellungen, zum Beispiel, wie berechne ich ein Wassereinzugsgebiet. Das ist eine Fragestellung, die hängt extrem von den Eingangsdaten ab. Und da sind jetzt 40 Jahre, 30, 35 Jahre Zeit in die Watershed-Berechnung von Gras eingeflossen,
mit allen möglichen Sonderbedingungen, die durch merkwürdige Höhenmodelle und so weiter entstehen können. Das ist jetzt nur ein Spezialthema. Ja, solche Dinge könnte sein, dass die in Gras noch einen Hauch besser funktionieren. Ich selber benutze auch QGIS, ja, überhaupt kein Problem. Natürlich ist das grafische Benutzerinterface auch sehr schön da drin.
Und die Integration gibt mir auch die Möglichkeit, beide Systeme zu benutzen. Also friedvolle Koexistenz. QGIS ist sicherlich dafür geeignet, um auch Leute schnell abzuholen, die vielleicht aus einer ganz anderen Gis-Ecke kommen, um dann den Sprung in die Open-Source-Software zu machen.
Um dann natürlich auch entsprechend, ich meine, wir wissen selber, es gibt unfassbar viele Erweiterungen und so weiter in QGIS. Und die Kernsysteme sind auch toll. Also, hängt vom Problem ab, was man lösen möchte. Aber ich glaube, die Ergänzung der beiden Systeme ist das, was ich hier am meisten vorheben möchte.
Wunderbar. Da sehe ich auch, dass die Online-Variante funktioniert. Das ist nämlich eine Frage da, die sogar in eine sehr ähnliche Kerbe schlägt. Sie lautet, entwickelt ihr selbst die QGIS-Schnittstelle oder ist das eher die QGIS-Community? Also, wir hatten beim letzten CodeSprint in Prag eine lange Sitzung mit einem der Kernentwickler,
der auf der Südtalkugel lebt und da dann entsprechend überlegt, wie das weitergehen kann. Es kommt einiges aus dem QGIS-Projekt selbst. Also, da gibt es glücklicherweise eben auch genügend Leute, die dafür sprechen, dass das Gras-QGIS-Interface beibehalten wird und modernisiert wird regelmäßig.
Und ich selber habe auch schon mal alle Beschreibungen vor ein paar Jahren überarbeitet. Das ist umgeben und nehmen, würde ich mal sagen. Und jetzt im Sommer ist wieder geplant, bei dem Junitreffen in Prag, was hier auch angezeigt wird, daran weiterzumachen, um eben die Schnittstelle noch weiter zu verbessern.
Das geht auch nur im Team. Keine Frage. Okay. Gibt es in einem Raum gerade noch weitere Fragen? Ansonsten habe ich einfach direkt eine. Nämlich, wie viel Coding-Kenntnisse erwartet ihr denn,
wenn ich jetzt zum Beispiel zu einem Community-Meeting kommen würde? Also, was müsste ich mitbringen? Einen Rechner und dann sind wir eigentlich auch schon fertig. Denn Coding-Kenntnisse werden keine benötigt. Aber es wird natürlich ein gewisses Wohlwollen gegenüber Coding. Es ist, sagen wir mal so, schön.
Aber wie gesagt, wir suchen ja auch Leute, die sich zum Beispiel mit der Dokumentation beschäftigen. Es ist auch eher Texte schreiben als Coden. Und entsprechend kann man da völlig ohne Kenntnisse kommen. Und wir machen dann gerne auch Einführungen, um ein bisschen zu zeigen, was ist wo. Also, herzlich willkommen auch ohne Coding-Kenntnisse.
Ach so, das Event wird auch teilweise online sein. Also, man muss nicht notwendigerweise hinfahren. Ist aber schöner. Okay, wunderbar. Dann vielen Dank, Markus. Gerne. Und hier geht es organisatorisch in fünf Minuten schon direkt weiter. Mit dem zweiten Teil dieser Session zu der Frage, wie ich denn ein Add-on für Querskis programmieren kann.
Und dazu machen wir gleich weiter. Denkt daran, nichts liegen zu lassen, etwaige Flaschen wieder mitzunehmen. Ansonsten geht es hier gleich weiter. Dankeschön.