So, GRASS basically is a C project written in C. As Marcus said, it's over 30 years of development and it's quite interesting that actually a lot of the basic C functions

that were developed over 30 years ago are actually still there, are still working. So it's a quite stable source base even though it has changed a lot over time. Very early on shell scripts were integrated into the GRASS source base and were used as a way to kind of glue together different parts of GRASS for some tasks.

But we've had over the time appearance of new generations of developers used to coding in different languages and we have the arrival of new languages as well. And so now we have different application programming interfaces to GRASS and the aim

of this presentation is kind of to give you a quick overview of these different APIs so that you have a notion of what you can do with GRASS, how you can program with GRASS. So actually the first thing I want to say is that GRASS in itself is an API. GRASS was built up following the Unix philosophy, the KISS principle.

Each individual GRASS module does one thing, does it well and has defined parameters. Marcus just showed you how you can look at them in different ways including as WPS, XML descriptions. But so each module can almost be seen as a function that you can then chain together

to build your own applications. When you create output as a map from a GRASS module, it is automatically stored in this database, the GRASS database or as TIFF files or whatever format you want to but normally

in the GRASS format in the GRASS database. And other types of outputs from models can be stored either in files or you can actually pipe them through the standard input, standard output flows from one model to another. So just changing these models can be considered writing a program and here you see a very

simple, very simplistic as well program saying let's test if any of our points fall into let's say very roughly designed flood risk areas and you have the chaining of a series of commands that actually take an elevation model that estimate out of that

where streams are most probably to be, where water accumulation is going to be most important. Transform that to vector, buffer it and then check which of our points, in this

case we're using capping grounds, fall into a 500 meter radius around these streams. So you can really easily chain GRASS commands and a lot of the GRASS commands really allow you to work with very basic functions and so you can chain those and write your own programs in a certain way just by doing that.

When you do that, the memory handling and the garbage collection if you want to is handled by the system because each model is an autonomous program. So once the model is over, everything is just freed after that by the system. Error handling is done by each model so if GRASS is such as not a standalone or not

a monolithic application so when you have a model that crashes, it's only the model that crashes, you don't have a whole program that crashes. And actually you can call GRASS and the modules through any language that can do system calls and here you see two examples in Python and in C so if you want you can integrate

calls to Python models within an application that you write within any program in any language. So this is one way to program in and for GRASS.

It has some, let's say, disadvantages obviously that you sometimes using these system calls you need to really be informed about how to handle shell expansion and it's not always easy to handle output of the models when they're not maps. You really already have to know how to do that in your respective programming languages.

And so a Python scripting library was developed to ease, let's say, these system calls to GRASS modules. These are essentially, the entire library is built around subprocess Popen within Python

and generally almost all the different functions of that library are just wrappers around that. And you have specific functions to handle different types of input output. You can read output line by line, you can put it out as Python dictionaries or you can actually work through the standard flows as well.

So some examples here. You have, if you want to the basic system call run command, just call the command and then it puts out to standard output whatever it puts out. But you can do the same and get out a string separated line by line which you can then treat for example with split lines or whatever functions you use in Python to do that.

Or you can put out a Python dictionary. So you have these different functions in the GRASS scripting library that allow you to call GRASS commands in different ways and to have different types of outputs. This makes the call to GRASS modules really easy and so it makes it easier to actually

develop Python scripts around that. There's a series of other wrappers that you can use which have been built kind of as goodies if you wanted to allow easier calls to some tasks that are often needed within

GRASS. So for example, creation of a new GRASS project location or listing, for example, whatever vector maps you have in your map set, et cetera. All the scripts that are part of the GRASS source base and that used to be shell scripts have been rewritten to this new Python library in GRASS 7.

And as Marcus said, if you use the GRASS modeler, the graphical modeler, you can actually program graphically a script which will then use this Python scripting library as its base. Now the Python scripting library that I just presented is very easy to use for very

basic scripting but it does have some, let's say, disadvantages. It does not give you a low level access to GRASS GIS functions or data. You only get access to the GRASS modules as such.

And in a certain way it's not a very Pythonic way of programming when you use the Python script language. It's a very simple scripting approach and it does not really encourage the user to really work within the Python's paradigms. So as part of a Google Summer of Code project, a new library was developed called PyGrass

which has two layers to it if you want to. The first layer can be seen as a sort of a replacement of the Python GRASS scripting library which does functions to call GRASS modules. And the second allows a lower level access to the GRASS GIS API via the C types Python library.

This allows to integrate, let's say, both Python programming philosophy with the GRASS philosophy, let's say, much closer.

So as an example here, you have the access to modules, the first layer I spoke about. So you can create objects out of GRASS module calls and then handle them in classical object-oriented ways. You can set flags or parameters on the way and then call your model that way.

You can also actually create shortcuts, Python shortcut calls which then really make your Python code almost look like GRASS code. You call the G region module exactly with the name G region or the V info, V dot info

and V dot info, et cetera. So that is a way to allow people also to, let's say, use Python scripting but still stay within the known realm of GRASS module calls. So interesting difference to the GRASS scripting library is the fact that modules are treated

as objects and then you can play around with them in, let's say, a more Pythonic way. However, output handling is not as easy as it just takes the output as the standard output from the modules. So you already have to know a bit more about how to handle that in order to be able

to use that. Currently, the two libraries coexist and in a very, let's say, very subjective, my personal simplified differentiation of the two, I would say the first one is a very, let's say, GRASS just user-oriented library which allows them to start scripting whereas the

second is maybe a bit more Python-oriented which allows people who like Python to use GRASS in a more sophisticated way. The second layer of the PyGRASS library allows a much lower level access to the GRASS functions and GRASS data.

It uses C types to access the GRASS C API and it kind of combines the ease of Python programming with the performance of the GRASS C API. So you can actually really get the great performance that Marcus was just speaking about through Python accessing the actual C libraries there.

There's different packages but notably raster vector and general GIS, let's say, handling and more generic tasks. Just a very quick example here. Here you have an example of dealing with a vector map, point map which you can just

open and then your first task is just look at how many points do we have. We then create a new point which we can then add to the map so very easily to actually add new elements to maps in a Pythonic way. But you also have access, for example, you can iterate over geometric features within

the map and you have access to specific functions such as buffering, such as overlays, et cetera, which then use the actual C-based GRASS functions behind the screens to then apply these functions.

So again, the difference between the two Python APIs is one is really, let's say, a scripting allowing people to chain GRASS commands very easily. The second is more of a Python access to GRASS.

Finally, for those who really want to go down into the code, there's obviously the C API which has known over 30 years of development. Parts have remained, as I've already said, extremely stable over the period. So it's quite interesting to see with what quality the initial functions were often programmed.

But there's been tons and tons and thousands of additions on the way. I've just selected a few of them to highlight how things have evolved. So you had the interaction of floating point and null support in GRASS 5, the whole new vector library, including the network tools that Markus showed in GRASS 6, and the whole performance

optimization, large file support, and much better cross-platform usability in GRASS 6.7. I think now by GRASS 7, we can really say that the Windows port of GRASS is stabilized as well, much more than it might have in the past.

There's three main core libraries. Again, the general fundamental operations of this library. You have the raster and the vector libraries. But there's many, many other libraries. I won't list them all here, but specific mathematical calculations. You have treatment of satellite imagery, displaying maps, et cetera, et cetera.

There's a consistent naming scheme across the libraries now, which really allows you to very quickly identify from which library within this whole GRASS C API the functions come from. There's obviously a host of different data structures that are really specific to GRASS and just needs in there.

So you can have a look at the programming manual to have really the details, obviously, of the C API. But just some ideas of what that looks like. One here treating a vector map and going through it point by point, for example, or in the bottom here, the fact of going through raster data.

Quite interesting discussion about the fact that OTB doesn't allow row-based access to raster. GRASS actually allows you different types of access to raster data, either row-based or segment-based, et cetera. This allows quite flexibility also in terms of how you want to access

and how you want to deal with raster data. Just as a final note, GRASS allows very easy user interface creation. You just define the different elements that you need in your user interface and you get both a command line interface and a graphical interface automatically back out of that.

Final notes. All the examples I've shown of running GRASS from different programming languages, you have to be within, let's say, an environment set up for GRASS usage. Either you launch the startup script or you can do that manually. GRASS also encourages people to really use a series of coding standards

and these are all listed here in the submitting page. That was it and enjoy GRASS 7.