So we have the last talk for today, and I ask Sigrid to come here and complete. Can you stay in 20 minutes? Can you keep the 20 minutes?

I hope, yes. Yes, please. Because 15 will be close. Yes, 15. I hope to get my 12 minutes. We can have questions. We can have a guest.

Thank you, Chairman. So I hope you're still awake to listen to the last presentation, the final light of this day, Graph on the Web. I will start to give you an overview of the four points

of my presentation, the subject of my presentation here. The second point will confirm the first question technique, the web interface, the two common techniques.

And the third point will be an example of interactive PHP requests with Graph. I will show you an example of this application with Graph. And the last point will be the discussion outlook about the presentation.

A state of the art. What is web mapping? Web mapping is the interactivity between the user and GIS that enables online requests of real-time computed spatial data

and secondly the generation of cartographic results. So it's a function of four points. Yes, web mapping has a function of updating of data and the second point is security and authentication of the user.

That is perhaps a problem, but it could be resolved. I will show it in the example I present. The third thing is the collection of user-filled forms because you want to make a request by web browser

and how to access the databases by this web mapping technique. There are three methods, three concepts actually. You can, such web mapping can be performed by static, dynamic and animated map concepts. So, if we have a look back to the mid-90s on the internet,

there were only a few websites available. Today you have tens of thousands of websites. These last ten years we have an enormous development on the web. Yes, but the most web mapping applications are limited

to a simple online map request, but, yes, of geospatial data by map generators or map browser services. So, I will come up to the objectives.

We want to create a method that exceeds these conventional requests, interactive request services, map browser services. So, the question is the aptitude of GRASS is a development tool for real-time map calculation.

The central question is to which extent is GRASS able to support web interfacing? Yes, there are two come browser scripting techniques, but, yes, linking GRASS to a map server,

GRASS interface application is important for access of geocoded data through a web browser. So, yes, the issues of the standard communication between a web server and GIF

are functions by programming interfaces, CGI, and we need an interface script that controls the web user interface. This interface could be written in any language, in any programming language.

The two main concepts which are existing are the server-sided and the client-sided concept. The server-sided was chosen for this application that functions with dynamic HTML scripts.

The client-side strategy I will also present uses Java applets. So, I will come up to the first one, the clever-side strategies with Java applets that functions that the work of some user request

is shifted from the server to the user computer. That could be an advantage, but also an disadvantage. I will come up later to this point. Also related with this method is an automatic download from capabilities to the client. I have presented here a little graphic that shows the function.

First, the client sends the request to the server, and the second point... Oh, I wanted to show you first the client-sided configuration, but it's perhaps not so important, so I'm quicker.

So, the CGI script is now the important point. The server processes the request and sends the information to the CGI script. The CGI script treats the request and puts it back to the server.

And finally, the response is sent back to the client. I will show this example later with the Quest application so it will be more clear. Yes, and the second point, the client can use his browser interface

to visualize the data he requested. So, yes, I was putting up here some advantages of server-sided concepts

in comparison to client-sided concepts. One interesting point for the server-sided concept, the advantage is that processing power of the client computer doesn't have to have high capacities.

Only low capacity is enough because the request is treated on the server side. Yes, the advantage, and from the client-sided concept, yes, you need a high capacity on your computer

because the Java applets are sent to the user computer and treated there directly. So, I think it would be a disadvantage because... Yes, OK, I put it at disadvantage. The next point is processing of large and complex data on a high capacity server.

And the advantage for the server-sided concept is that there is no web transfer necessary because the data are directly treated on the server. And on the client side, it's necessary to access the large and complex data as heads.

So, yes, third point, the check of client permissions is well implemented on the server side but less implemented on the client side. Fourth thing is the problem of compatibility of software versions.

This point is on the server side, not existent because data are treated on the server. So, it's a disadvantage for the client side because you always have perhaps another version on your computer

and you get some problems of incompatibility with the Java applets which are sent to your computer. So, the last point is the dynamic generation of diverse graphic formats is possible

and on the client side, dependent on Java library. So, there are also some disadvantages of the server-sided version. Yes, the client to server request is server dependent and the network capacity and internet traffic perhaps is also a problem on the server-sided concept

because it's highly dependent on the... If you have to transfer the data, you want to get from the server back to your computer but on the client side, you still have downloaded these data

and the data are directly treated on the user computer. The use of the client computer capacity is on the server side only important for the request and on the client side for data processing and request processing.

So, we used in this case for the interface scripting, the PHP protocol script which has the advantage that it is a simple language. This protocol uses a simple language.

It's quick and it sends replies on highly frequented servers. The third point is the portability is a given for many operation systems and the library for the development of portable graphic user interfaces is also vast.

You have access to many relational databases is the last advantage of this concept. The disadvantage is you have a performance loss with interactivity

of computationally intense GIS applications. So, the conclusion is there are some hybrid concepts between the server client, the server-sided and the client-sided concepts

which minimize the use of client resources and optimize in time the server client performance. The conclusion is the client-sided strategy is best for services for a small user group of users which are really familiar with GIS applications.

And I would say in an intranet the server-side strategy is better for applications for mass processing of mass data and in the meantime a high number of users.

So, the last concept I have chosen for the demonstration of my GIS application. Yes, there are some premises of this concept. The concept of platform independent was the first premise and uses an open TCP IP protocol that makes possible the transfer to the web.

We have to suppose a user with no skills in graph utilization and last point, this application is only exclusive for the use of text-based commands of graphs.

That was the four points. The design has some requirements. A proper management of concurrent requests

because there are, for example, server users which are starting in the meantime a request and the management of this has to be done. Another problem is the computing time because if you send a request normally you want to have a quick answer

and if you want to make, as I show here, not only a request of data which exists but a request of calculation of data, of data which are calculated with graphs, it could take much more time because calculation takes the time,

the transfer of the data also takes its time. So, two command set files are produced by the PHP interpreter. First, the graph command set file and in second point, the Unix command set with the initial graph activation.

Then we have to clean temporary files for not to have too much capacity, disk capacity occupied and at last, this technique is based on the map is calculated

and then sent by email to the user. That's the trick to overcome the time problem because you can't wait all time. You have perhaps some interruptions of the connection, internet connection and that was the solution to overpass this problem.

The NITA send command also has to be fixed in the Unix command set. The second point of the design is the execution of a cross daemon. A daemon is a program which permanently runs in the background and replies to requests only executing the files but not analyzing the content

and it makes a queue check of different command set files of the communication director with the effect that finally the oldest amongst them are removed and as I said, that is for the reason of economic disk space.

The third and last point is the security concerns. The user is not registering on the server

so it's with the consequence of the open public avoids this application and the inter-user protection system. The other problem is the web server as a patch

can't run a PHP script as a root, that's not possible but to solve this problem, we named user in a simple configuration file. The solution of this was that many privileges are given to all these daemons.

Protection of application by checking all input data for content of correct information is given by this.

And secondly, appropriate check of the email address has also to be done because some jokey person could for example make a command like I don't know, fake add xcom and then the Unix command removes RS

and so the consequence is that all files on the servers which are touched are deleted and to protect against this, the daemon has to be prepared for this.

So, for the example for the representation of a graph with web mapping was the module point sun mask, that's a module which calculates on elevation model the shadows.

And there are two ways to do it. This module is based on the sun position algorithm and as I said you have to put in a digital elevation model. You have to do in the first step to realize a request of a shadow map by the PHP code,

a program of this code. In the second step the definition of the graph commands are sun mask and for the output and postscript a PSMap and in the last point the program of a PHP script.

So, this is the request form and you have to put in the date and your mirror address and if you put the OK button you get for example this result of a shadow map. This is the example sparebrush region and the graph gives a GIS environment

and I put the date, I have chosen one date, I also put the center of the map and I got the output about a sun element and sun angle

but we're not interested in this case because we only wanted to have the visual output product of a map which was calculated by GRASS with the sun mask operator yes, on the request form, also program in PHP.

So, discussion and outlook, we come to the end. GRASS is really suitable for web interfacing because there is a possible conversion between GRASS script and the web-based application.

Geo-coded data of GRASS-based are reachable by distance. For example, if you are in the field, you make some field work and you want to request some special data by means of wireless portfolio and that could be the future. The second point is this template application demonstrates the flexibility of GRASS and PHP

and in third, yes, we have to do some operability tests with other GRASS GIS applications because to test larger data sets and to have perhaps a much more functional

and interesting application on the web. Yes, the mapping is limited with GRASS by the availability of free data. So, that's a little bit out of the problem for further testing.

Thank you for listening. Thank you for a colorful presentation. I think you will be the only pendant speaker.

What do you say? Okay, any questions? You talked about security concerns and I have to tell you a bad story

because I wanted to... I wrote a CGI script for using at the university of... I wrote a study and it wasn't able to use this script because of the restriction of the computer system.

They don't allow such scripts and I know many people, even in big firms, the situation is the same. So, I think you're happy if you can use such a solution

but I have a different suggestion. Wouldn't it be possible to use the new scalable vector format of a web consortium? Would that be an alternative way of producing that mapping?

Perhaps you know a new generation of internet browsers will support vector formats, scalable vector formats and perhaps that's another way.

I have to admit I didn't think over to this problem because this is an raster application and that couldn't be the same way.

Maybe I can try to answer that question. Any program you run as a web service, you will have security concerns. So, no matter how you design it, any program you run that the user can make

over the internet give parameters to will have to be made under security in mind and grass has not been made with security in mind. So, once you have a grass application running, you have to be careful that with the permissions this grass application has,

it cannot do any damage because it's not protected. It's not a security enhanced application to say so. But no matter how you design it, any system administrator will be careful to let you run anything on his system because any program might be damaging.

It's not a matter of the technical architecture. It's a principal problem. Okay. Let me comment that, well, we'll have other talks. There is a post outside regarding the problem of map server and web services.

So, maybe we can also proceed in these days and with other experts which are here. Thank you. I think that most of the problem of security with web is that HTTP is a stateless protocol.

And sometimes you see a CD application which makes a first check of access right and nothing more after. It's clear that you can easily intercept the string which is sent with the request

and that's why to implement properly security on a web application, we have to always transmit a key which is generated by the server and checked at each time as a general recommendation.

Okay. Let me thank again all the speakers of this last session for today

and from the organization management committee. See you tomorrow at 9 o'clock for the next day. Have a good night.