It's time to start the first scientific session of the symposium. The first scientific session is dedicated to three keynote speech with invited speakers. The first one is a speaking titled,

Current Status and Future Development of Grass, and is presented by Marcus Netler, who stay now here in Trento at ITC. Marcus, please.

Oh, welcome to the open source and free software grass users conference here at Trento. I'm really glad to be here and to be able to present

the current status and future ideas for the grass development. I discovered that this seems to be the first conference if I'm well informed since 1995, the first international conference, I must say. There have been local user meetings in Italy, several and so on, but this is the first international conference for several years now,

and it's great to have that. Before I start to discuss a bit about the future and status, I want to thank the organizers, Dr. Ben Cholini, Paolo Satelli, Marco Choli, and the University of Trento for organizing and hosting this conference.

As we can see, they have done a big job of collecting so many papers from all over the world. We have seen the impressive proceedings, and I think we will have an exciting gate here and inspiring session.

Next, it's a pleasure for me to announce that Grass 500 is finally released. We have been working on that for two and a half years, and we were, of course, not starting from scratch, but picking up from the US Army the initial floating point development.

They've been already, I don't know, working one or two years on this code, on the code change to implement floating point support into Grass, and the development time for the Grass development team was two and a half years. The final change was done in September 2002,

and the source code and also some binaries have been released on 5th September. This is really great and psychologically important because now we have a free, we consider to be a reliable, free system available, which fills another gap in building

the free GNU software system. Let me shed some light on the Grass code evolution and the development as it is established now. Back in the history, somewhere in 1997, we had the Grass IV releases, several of them,

where the US Army was organizing these developments, and this was a phase of innovation for GIS. Maybe not all of you know that the current open GIS consortium evolved from the Open Grass Foundation, which is quite interesting.

So Grass was, at times, a very important GIS, and also a visionary system for other companies. And later it diverged, and the open GIS consortium focused on different things, and so it's divided up into several organizations.

I'm not sure if there's a possibility to see the Grass Clippings Journal. There has been a journal published for several years. I think Helena Mitersova brought some issues. We may see them outside later. It is really worth to look at these issues,

how much work was done at times. Then the transition phase from 1997 to 1999, somewhere here, and all this time, the code remained in public. And later, there was the important change

to a new general public license, which was written by several people. And so we started to develop the Grass Five Zero Code, you know, with several releases, and three releases, better releases, and so on, under GPA license. The idea was to protect the rights for the office,

which also made it quite interesting for several developers to contribute. During the magic, or let's say one day before the magic year 2000 change, we put all the code into the CVS,

into our automated code management system, to be sure that it is safe and won't get lost. And all the years before, say about, so I cannot say anything, but for the Grass four to one release, it was always manual code management with a lot of work.

And this CVS is hosted in Germany, as well as the backtracking system from a company, Interivazione. And I think they are really doing an important job for the Grass community to provide a stable technical environment. It's also interesting that Grass now starts to become part of some standard Linux distribution,

such as Mandrake. I think it should be available in Mandrake nine, as far as I know, and also Debian release should ship with Grass. We are using several management tools.

Okay, before I close the details for management tools, I want to mention that the Grass development is really 24 hours development. This is well known from several open source projects. And this is a very incomplete work map of developers. And you can see they are really spread everywhere. And we don't have all coordinates of the developers.

So this map is not showing everybody. And server is located here. The Grass master site is located here in this city at ITC years where I'm working. And from this master site, several mirrors are popping every day to copy to different countries

to have good code dissemination. These are some of the development tools we are using. Code development is not just working with the compiler, but it is also a lot of administration work. We need mailing lists, we need backtracking systems and so on.

And the recent evolution of the code management tools and software engineering tools is quite important for us. It's interesting to know that Grass was always distributed internet-based. I think the first distribution was placed on internet in 1989, so more than 10 years ago.

And of course, there have been nearly no internet users, civil internet users at that time. And this was growing and the code dissemination by internet is a quite important factor for Grass development. We have the website, we have the mirror site mailing list,

the backtrack system and so on. Also maybe a difference to some industrial projects is that the developers are part of the users group. That means they are well-informed what users need. If users complain, they usually can quickly help.

From this system, I want to pick up the backtracking and wish management system, which is quite important and could be even improved a bit. They use in an optimized way. We have two possibilities, either user sends a request or developers detect a bug.

And usually the users are sending their reports to the mailing list. And this backtracking system is quite important and to help for development because every time when you write a report to such system, it is stored in the system with some tickets, trouble ticket number, and all communication on this back is stored along this number.

So for the developers, it's much easier to handle bugs request. Maybe they have not a quick solution, but later and so I can recommend to use this request tracker. This is quite easy. On the website, you find a bug report form and you can fill out this form, say this is not working under this condition

and then developers can try to help. Other developers are notified by this backtracking system. Once the mail is sent to this back tracker or this form is filled, an email is automatically posted to the developer's mailing list so everybody gets informed that something

is eventually going wrong. And from this, some interaction happens. Of course, new features are also implemented in the CBS. This is apart from the backtracking system, but important for the code repository because all changes are certainly stored here.

And from this code repository, we are extracting new bugs releases regularly on a weekly base. We have the CBS snapshot. Maybe in future, we may decide to also build binaries on a weekly base, but this must be discussed because the CBS may also contain unstable versions.

And so we don't want to discourage people by using unstable software. We want to focus them first on the stable release and then say, okay, if you are well experienced and interested to participate in development, then you may go for the development version.

It's unfortunately not to be seen completely. Some comments on the development models. You will know the terms of a recruitment, the cathedral development type,

and also bazaar development type, cathedral closed group, maybe no source code publication and rarely releasing any version. Opposite to that, the bazaar type with heterogeneous group

that people are regularly contributing also release often paradigm. So something totally in opposite to that. For GRASS, I think we have something in between. We can consider the GRASS development team as a sort of council type. My opinion, we should, maybe even simulated through this conference,

we should manage to shift a bit more to the bazaar type because we need some, I dream of some increased development where people are not only focusing on the current releases or something, but also develop contributional packages

such as hydrology modules, image processing, whatever, where they have their expertise. And since GRASS is a modular system, it is rather easy to connect new systems, new models to the main system. And I think during this conference, we get lots of inspirations

because lots of tools are shown here, what I got from the proceedings. I made a small analysis about the GRASS contributions about the last two years. It's looking like that. I was using R of course to develop this graph

and the time range, I hope you can see this from June, 1999. This was the initial beginning of the GRASS five, zero, eta one. And up to last week, here we had the table really.

I wonder why is this curve looking such a strange and not smoothly. The reason is that we don't have daily information about the GRASS contribution. There have been many releases that days. So we had to beta for A, beta for B, beta for C and so on.

But I only know for beta A, for beta one, two, three, when it has been released. So it is looking, it is somewhat accumulated here. And from that is quite early in this development, the release under GPL, the change of the license to the new general license.

And then this red line indicates when we started to use the CVS management. We can see is that the curve is a bit less steep after changing to CVS that may be related to the fact that the developers had to get used to the development.

I can just get here, I don't know. I used to, sorry, used to get used to the CVS development system. And we of course had to learn how to do this and how to change code with managing the history. As you can see a real boost here in the end of the year 2000, similar to this boost here.

This one was related to many changes for portability reasons. People were interested to run the system on Dega Alpha stations and other systems. So a lot of code changes were required to change code to on the coding standard and so on.

Here, there was another heavy change and sometimes it's even related to one developer who is committing some hundred changes and doing a lot in a short time. Finally, we see a sort of saturation of this curve. This is related to the fact that the developers

were a bit nervous to change anything because they considered the system to be stable and they didn't want to break anything by introducing some code enhancement and so on. So this curve is flattening and obviously it was time to release the stable version.

So there are of course, lots of needs and this is maybe talking a bit about the unpredictable future. What's an answer, a question hardly to answer. We have collected numerous ideas for GRASS 5.1

which should be the next version and which is already started and things which may have been partially started but also sometimes waiting for implementation. Important fact is that people need multiple session support.

So if you want to run GRASS several times as one user that is currently say not possible with doing some tricks and we want to get this smoothly but this requires of course several changes in the code. Second is that the projection library needs to support geodetic data and transformation.

This is an issue which is not trivial and in GRASS 5.0 stable there is support for the North American data but not general data and transformation support. So if you use the projection tool so we still get some shift if you change maybe from WGS 84 to Rome 40 data more of the national data.

Data is information that someone is working on this and so I hope that this issue will be solved as well. It is related to the full integration of the projection library, projection four which is supporting data and transformation but still it's like integration of data and transformation.

Then already started has been internationalization. That means that GRASS will in future someday support several languages so that it will detect the local language of your system maybe Italian, maybe Russian and so on. A time where basic error messages

and so on already available in Russian language or the Russian has doing this implementation and later we need of course people who are doing the translation network to get all messages into the different languages. This requires also some cleanup of the code that means that the messages have to be reorganized

internally in the code structure. Then of course we are also dreaming of an improved display system for example to support projected views. Something like this maybe looking at this example you can see it's not a fake it is already existing.

And the funny thing is that this is existing for five years already or maybe seven years because this graphical user interface has been developed for GRASS 4.1. Unfortunately we don't have the code but the author told me that he's currently working on upgrading this code to GRASS 5.0.

So I think in near future we should be able to get it and you can see that all sorts of projected display is possible. And here it is a bit maybe a bit difficult to read for you but in the paper and the proceedings you'll find another range of that. You can select maps here, you can select projection

and so on and so on and I think this looks promising. Related to this was wishes from a user's perspective but we have also wishes for the source code. From a user's perspective we can say

that the stable release is somewhat reliable hopefully reliable but I think we have tested it well and from a source code perspective software engineering development is somehow different. And if you look into the source code you can see that there are some strange sometimes strange organization

there's obligated code and so on. To illustrate the problem I want to cite this short mail I received once some months ago. Someone was asking me about ideas how to implement a GRASS Python interface. He was writing, do you think that writing the wrapper would be difficult as an example

of the TK inter wrapper function to allow Python to write OpenGL accelerated graphics. I will go back to this and see how they do it. Maybe that will give me ideas how to treat the GRASS library. The problem is this person never wrote again so obviously he was giving up. And this is something we of course have to change.

We have to change the source codes to get such attractive that people who want to do a GRASS implementation cannot resist to use this code. It must be a clear structure so that people can say looking 15 minutes at the code and the documents and get a rough idea if a project is feasible or not.

And for this we have to do a lot of code reorganization a lot of source code consolidation. And one issue is that clones have to be removed. There are a lot of clones in the GRASS code. Clone means that some algorithm appears several times

in the source code base. And you can find instances where you have the same algorithm maybe seven times in the source code available in some modules maybe in the library but the modules are not using the library function and so on. And it is important to remove this duplicated code because for example if this code contains a bug

you have to change it. You have to change it not one time but several times. This is multiplying the efforts for code maintenance. And we have to go through the code. There are luckily software engineering tools for clone detection. And from that we are able to identify such code

to move it to the library and to change the modules to use the related library functions. But this of course requires quite some work and some new projects have been started to implement a sort of graph quality source code quality system

where maybe in a sort of automated way the source code is regularly revised by automated algorithm and the results are posted on the webpage. That means that the developers can every day look up about the source code quality and there should be also some indication where problems may occur

where maybe new fixes have introduced problems for portability or whatever. So we'll see this is under development. Another point is library refactoring for shared libraries. Shared libraries means that the libraries are at the minimum that you don't compile the libraries statically

into the modules and you get a much less amount of binary code. For example, if you compile, which is already possible, graph 5.0 with shared libraries so that the graph libraries are shared libraries, you need only a 35 megabyte instead of 100 megabytes

on the new Linux PC system. This is just by using a different compilation method. And of course, after optimizing the libraries, the size would be even there. This is quite important if you want to use a graph on handheld devices because of course you cannot install 35 megabytes on some PDA, this is quite important.

Then we should repackage graphs. We should use some system to split up graphs into topic oriented or task oriented packages, maybe four tools with libraries, basic tool with display,

import routines and so on, image processing package for the image processing tools and so on. So that the user can download only the packages he wants to get, he needs for his work or her work. For that we could consider a graph update system. So when one package is updated,

there may be some functionality for the users to find out about this and automatically update only the subsection of the code so that not a full reinstallation is required. I mean, inspired a bit by the R system, there are the R contributions and it is quite easy

to plug in some new contribution into the R36 system. The last slide I was showing the some potential new graphical user interface, but for the future, we need to really rewrite a new display system, rewrite of the display system to also support cartographic elements,

maybe something what is ES mapped somehow providing, but okay, this is not fully convenient if you want to do it interactively with mouse placing the legend and so on. But finally, I want to suggest the graph daemon.

This has been already discussed in the developers mailing list. Graph daemon could be a sort of session manager, especially if we are enabled to use graphs in multiple sessions, we need something to manage the region extents, the resolutions and so on. And also to connect external software such as the R statistical interface to graph

or maybe a GPS device or other systems, we need something to interact with the graph system to send metadata and so on. This is also on the long list of ideas and this list can be certainly extended.

Concerning modeling, just briefly because Helena Mitajova will show in the next slide, the next presentation much more on this. We need to improve the support for C++. A lot of people are writing applications in C++ and so enable them to integrate these applications.

We have to improve the input output functionality of graphs maybe to separate this as a library so that people are sort of invited to connect their models and environmental models to graph.

The C3D support is still in transition. There are some problems and I think during this conference, we will see some 3D applications and I guess we also see some new solutions for this and I'm really interested to look what has changed already.

Quite important, also the time series support. Time stamps can be thought already but time stamps are not exciting at all. We need some more sophisticated modeling tools. This figure is showing some temperature data series from the MODIS satellite.

These are temperature maps for this area here and this is just a step of following days so this is around one week here and you get from MODIS satellite, for example, every day a temperature map. And if you now want to do a long-term study or say for one year, you already have obviously 364 maps.

If you use more than one product from MODIS, you can get about 40 products like snow cover map, like cloud distribution and so on and so on. You will have thousands of maps and we need to improve the management of these maps and also to be able to do vertical,

say in the temporal sense analysis as well as spatial analysis. And I think there's lots of potential, maybe also for some PhD thesis and so on. Something different, not directly related to graphs but even an important issue is,

what is a GIS without data? Nothing, in my opinion. And we have the big problem that free data are rarely available. We were, Elena Mitersova and me were discussing this yesterday already. Question is, is there a trend for commercialization of public domain data in USA or not?

My opinion there is, but of course I'm living in Europe. I'm not, maybe not well informed but we can see that a lot of data are now sold which has been available earlier and at least that they start to charge something for delivering data, which is okay, in some sense understandable but on the other hand, maybe showing the wrong direction.

I'm not sure. But if we look at the European situation, this is really worse. And in Europe, it is pretty difficult to find any free data with high precision. We neither find elevation data say at 100 meter resolution. At least I didn't find them yet.

Nor you find vector data like roadmaps or other basic spatial information. And this is quite a problem and something we have to think about. And I think there could be an idea or this is pollution could be of course,

trying to convince people that public data should remain public. It means that data which are paid by the taxpayer should be also available to the taxpayer. This is something usually possible in US but quite a problem in Europe. But we could also think about releasing GIS research results to the public.

It means from our work, we are doing daily to release such results with all constraints, which I know sometimes there are limitations on that so that you are not allowed to transfer anything. But if possible, we should really do that.

And for this free geo data license is required to protect these data so that not anybody can pick them up and start to sell them or whatever. And I think this is an issue maybe for the Free Software Foundation because they are focusing on free software and I consider free data also sort of free software, data software for me.

And we have to discuss this and maybe during this conference, we get some ideas. Well, let's go back to our conference. I've been looking at the proceedings and we see a lot about online mapping, about map server and so on.

And this is one example, the map server which directly reads from the graph database. This is already possible if you use the GDAL libraries, compiling them with the option to read graph data. It is currently still restricted to graph data. And then you can really make a nice collection of tools

and put everything onto the website. We will see interesting things during the conference. But mobile graph is also another issue. This one you may have seen this morning, these mountains. We are currently in this valley here and this is something we will also hear about

graph on IPAC. This is from last weekend. Graph also infected the DAWOS system, which is a rather new PDA running on Linux and the USGS, there's someone at USGS who was providing me this photo.

And so I hope that it is possible also to run it on other systems. It will require changes for the display system, but okay, this is a free software system. People can contribute as they like and I hope that this is continuing to grow. The only thing is that this system

is also connected by LAS. So while being outside of the office, this is connected to the graph database. But we will hear more about that later. Looking at the proceedings, I found a lot of new modules. This is the very incomplete list of modules. I found that Viti has been writing a program for that

to extract these names from the paper automatically. And you see, this is quite a number of new tools. We will hear about that during the conference and I think it will be really exciting to see what has happened and about new features.

So finally, I want to thank again the organizers of this meeting and wish you a pleasant and interesting conference. Time for some questions right now.

We'll discuss a bit at the end of the session. Yes?

Yes.

Okay, and question about Digitizer, with Digit program. Do you feel that there would be any place

to develop that further, for instance, to get node points seen more clearly and dangling nodes and such, because, for instance, to close sometimes polycons

might be difficult to find the gap in the polygon.

The library, which will be introduced later today, will show that there have been quite some improvements on the vector library. And from this improvement results

that there's a much better programming interface to the vector library. This is not finished yet, this is work in progress, but this library will enable us to simplify the code of the Digit. And so I think that quite some hope to get a better digitizing software.

This of course always a question, how many people contribute? And if we have more contributors on the development, of course it will be quicker done. And that's a message for the future, but I see quite some potential that this will change.

What is the financial situation of GRASS? Is there any need of supplementary fundings or so? That's things. At the time, people are funded by themselves.

So they use GRASS for their work. They are doing the changes, they're doing it at home. Wherever, we don't have any budget currently for GRASS, but this is something which may change in future. I think we should find a way to establish a sort of payment system to fund specific problems,

to maybe both to send money to some developers to solve a special problem. But on the other hand, there's always the problem that this is a free software project. And we always have to keep the balance between people who are contributing and eventually maybe not paid and others who wants to get paid for that directly.

There's a sort of indirect payment that people receive funds from their solutions from their companies, but currently no direct payment. And this has to be considered very carefully how to change that if we want to change that and so on.

But it is always possible and if you look on the GRASS webpages, there's one site how to support GRASS and there's a list of companies who are doing GRASS development. So if you really have a problem, urgent problem you want to solve and you also have the money to spend, you can directly contact these companies and say, can you please solve this problem for us?

They will hopefully do it and they will send the results to the GRASS development team. I think this is currently the best way. As far as I know, there are more than five companies currently in the world and it would be easy to find a company which is solving specific problems.

So on the website, there's how to fund GRASS, how to support GRASS page explaining the issue. Yes, I would like to ask about the, I think one of the important milestones for GRASS development was a book that you were writing,

published by Kluwer. And I was hoping to see the book at this conference. Can you tell me something about the expected release date and when it's going to be out? I'm not sure about that but okay, maybe this is not the place to advertise the book.

This is available from bookshop and I think that, okay, we can later have a look at the book if you like.

Yeah, I do.

Copy, buy the two authors a photograph copy at the conference, maybe I would like to have one at least, yeah. Other questions?

Ask, tell your name, just beginning. My name is Philip Donahy. I just want to make a comment. Actually, it's not a question. I'm really glad that you mentioned the notion of creating a free data resource and the thought that I had is to create

multiple GRASS servers that allow the upload of data from users. Users obtain the data and the servers could be created so that they could have the capability

of receiving an upload of data that would then be freely available to all the users. I don't know if you've, have you thought about that? That sort of structure or architecture? I think that's a nice idea and there should be plenty of software tools available

to implement such a system. So think about it and discuss it maybe in the free GIS list. This is not only related to GRASS. Maybe it's an issue for the free GIS mailing list and we could start to collect ideas there

and hardware should not be that issue. It's the data issue and if people start to contribute, I hope that we get things rolling. Let's try. If the data come along with the related papers,

I think it's a really great source of information or also for research, not just for data dissemination. Okay, thank you Marcus.