Good afternoon. My name is Cian de Moulouse. I'm working with a company called GeoSpark. And we have an open source product which is called GeoMajas, or GeoMajas, or GeoMaja.

You just can use the pronunciation that you want. I will give you a short introduction to GeoMajas today. I realize that my slides are a bit old school compared

to my peers, but OK. Today's menu is, what is GeoMajas? What is the product? I will show you some code samples. And I will, if time permits, I will maybe talk a little bit about security.

But since this is Sunday afternoon, I don't know if people are ready for that. I will give a quick demo. And I will let you fire off some questions. So what is GeoMajas? GeoMajas is basically something

we started at least five years ago now. And it's an open source platform. At the time when we started it, there was no such thing as, for instance, open layers. There was GeoServer. But there was not really a framework or something

that you could call a framework for web applications. Or web map applications, let's say. So what we did is we made our own. We decided to take some technologies like,

first it was Dojo, now it's GWT or GWT, and combine that with a Java backend. Because mainly we are Java developers. We know there exists something like JavaScript, but we have not yet learned to embrace it

like the rest of the world. So we like to make stable and testable software. And at that time, Java was one of the better options. So what is it? It is a collection of free and open source GIS libraries. It's basically all you need to build a GIS application

without leaving your Eclipse IDE, let's say. What does it provide? It provides client and server libraries. So it has a server side. The server side is pretty common. It's based on the layer concept.

Just like, well, we are actually using you for part of that. And it has an additional feature, which is the built-in security. So we have very fine-grained security as opposed to, for instance, other products which have

only layer level security. So the language is GWT, or G-W-T, on the client side. And on the server side, it's Java. So basically, it's Java. And we have lots of plugins. This is just a few of the libraries.

So you have the client. You have the server. You can actually just use the client as a standalone client. In that case, you would connect to a geospatial server like GeoServer, a WMS, or a WFS.

And then it's pretty much comparable to what you have with the Google Maps API, or what you would have with an OpenLayers client. But you could also connect to the GMS server, in which case you would use the GWT RPC protocol. And you would be in a client server setup,

which is basically just moving the client to the server in terms of OGC services. So you talk to the same OGC services, but you are doing that on the server side. Technology-wise, so I already said it. We have GWT. We have Java. We use Spring a lot on the back end.

It's all Spring and Beam-based. We use GeoTools, JTS, of course, and Hibernate Spatial, which is actually also a spin-off project of ours, as we were already using Hibernate.

And we decided to add the spatial component to that. So there are some technical examples, which I will not show you right now, because that would take too much time. But one that really hits the eye is, for instance,

you can do polygon splitting. And you can just edit a line and use that to split up a polygon. In this case, the country of Italy. So it's not just showing data.

It's also working with the data, editing, stuff like that. Just a short view of the client side.

On the client side, we have the blue blocks, which are just using the standard services directly from the client. And we have the orange or reddish blocks, which are directly talking to the GeoMIS server.

On top of that, we have some really specific Plohins, like the editing Plohin, which is used for editing geometries. And we have several widget Plohins, as well, for doing things like layer trees and stuff like that.

Now, since this is a developer audience, I thought I would just show you a couple of code samples, just to get to grips with what it is like coding with GeoMIS. First thing is creating a map.

This is not very different from what you would do with an Open Layers map, I think. You just start by creating a map configuration. You just choose a particular reference system, the CRS. You set the maximum bounds of the map,

and you set a series of levels on the map, and a series of resolutions. Then you create this map presenter object, and then you simply add that map presenter as widgets to the rest of your layout. So it's like 10 lines of code creating a map.

Could be shorter if you use less resolutions, or if you use a predefined set of resolutions. Adding layers. So for each type of layer, we have a particular client

instance. So in this case, it's the TMS client. So you get this as a single form. It's a get instance, a call. And you pass it a URL to a TMS server. In this case, the URL actually is on a different server. So you have to do some proxying on the server side.

This is using an asynchronous interface. So you will receive a callback with the various, well, in this case, the single layer that you have asked for. And then you just call the get layers model on the map, and you add your layer.

And in this case, it will also set it to animated, which means it will animate on zooming. Same case for WMS. So in this case, we also define a tile configuration.

We define a base URL, a format, a version of the WMS, and we add the layer name, so the type name in the WMS. We use, in this case, the WMS client, get instance,

and create the layer, and add it to the map. And third sample is a server side layer. In this case, actually, it's easier, because what you do here is you take the GMI server extension.

You get the instance, and you initialize the map. And you will pass it a reference to a map, which is actually defined on the server. So on the server side, you will have your complete map defined in XML, which saves you from having to define the different layers on the client side in JavaScript or with.

I will show you if you're not, well, but this is actually the bean, the spring bean that defines the map on the server side.

And as you can see here, it has four layers in this case. So you can define whatever layer type over there on the server side, and you can decide which layers are visible and that kind of thing. Initial bounds, selection style, and so on.

So this is basically the easy stuff, let's say, creating your map, adding the layers. I'm going to, well, this is a more complex example, which is a map controller. What are map controllers?

Map controllers are just Java classes which are used to do something on the map. So you receive user events in your map controller, and you will, for instance, use that to navigate the map in case you are just driving, for instance. Or you will use it to edit a geometric object on the map

feature. In this case, I've made it a bit more complex by combining two controllers. We have something which is called the abstract rectangle controller. That's a controller which will allow you to drag a rectangle

and do something with it. So in this case, it will draw the rectangle, or the user will draw the rectangle, and it will be used to start an editing service by calling this geometry method. And the editing service will start editing the rectangle.

And I will show you later on how this actually looks like in real life in the demo. So it's basically combining the power of the rectangle controller and the editing controller to start creating a geographic filter object.

The server side looks rather complicated here, but it's not really that complicated. It's command based. So we are using the command pattern,

which means that every communication happens by sending a request, which is then processed by a command beam on the server side. We have various layer services, of course, for the layers on the map. We have both vector and raster layer services.

And we have whatever custom services that one likes to implement. So a usual GeoMIS application has a lot of custom commands as well, because different applications need different requirements, of course.

And it has to be incorporated in the general command system. We have a rather complex possibility of supporting domain models in the sense

that, well, it's not complex. It's more that we have tried to combine both what people are usually non-GIS people using, which is Hibernate, with the concept of layers in GIS.

So that means that you can just write your POJO object, your Java object, and then you can expose that as a layer in GeoMIS. This is what we call the Hibernate layer. And the good thing about that is that you can also support associations, like one-to-one or one-to-many,

and still keep using your standard Hibernate stuff on the server side. Besides that, you can also make custom layers. So it's very simple to implement a layer which is, for instance, based on some exotic REST services

that you know of and that can be used to retrieve spatial data. So what you have to do there is to just create an implementation of the vector layer interface. And that means, well, if you know GeoTools, it's a bit like a data store.

So you have to implement stuff to create features, save or update features. And the blue things here is just to read stuff, so getting elements out of it. So it's fairly easy to implement a layer based on some other web service.

Because you are, in some cases, working with generic Java objects, you will also have to implement a feature model in that case. So that will allow you to define, in a custom way,

how, for instance, you get the geometry out of your object. So in the simple case, it's just a layer implementation. In the more complex case, you have a layer and a feature implementation that you need to implement.

The spring stuff is, well, we like to use spring as much as possible. And one interesting example that I can give you is the fact that we use it to create a pipeline in the back end, a pipeline consisting of several pipeline steps.

And each of these steps can be used to do a dedicated task. For instance, you can have a pipeline step that applies a filter or prepares a filter, a pipeline step that fetches the data, a pipeline that creates the style.

And that makes it easy to modify your layers. So if you say my geometries are too complex or I want to merge them in bigger geometries, you just add an extra step to it, which is a simplifying step, for instance, which takes a lot of features and groups them together to another feature, which is something that you could also do on the client in some cases,

of course. But that depends on the size of your data and the complexity. And another thing is you can add security here. So what we did is add our custom security in the pipeline to do some checking on whether people are

allowed to see features or not, for instance. And that brings me to the security part, which is probably something I'd rather skip now because it doesn't add too much. I will summarize in terms of what it is.

It provides a way to split off authentication and authorization. Authentication, you can do it the Spring way, or you can do it through different systems, whatever authentication system you'd like to use. And based on that, we create a security context

in Spring, which is just an auto-wired object, which knows what kind of policies the user has, what he can do, and what he can't do. And just to show you some sample code on this or a sample of how fine-grained it is, this is actually a feature authorization interface.

And depending on the feature, it will decide whether it should be visible to the end user or whether it should be updatable, deleteable, and that kind of thing. So by implementing this in your own way,

you can configure whatever kind of security you want on the feature level. That brings me to a short demo.

So this is basically an application. It's a portal. If you could be able to see that this

is the upper part of Belgium, which is called Flanders. Belgium is complicated. But this application is just showing

the subterranean layers of the Belgian soil, basically. So it's called the Bodumverkand, which means the soil explorer or something like that. And the way it works is that you can add layers

from different trees of layers. So we have different WMS servers out there from which you can add layers to the map. So I will just, for instance, add this one, which is called historic.

It's called historic soil profiles. And it's just a set of, well, they've done various drillings in the soil, the whole Flanders. And they have made profiles based on that type of drilling.

Now, what I was going to show you is the special controller I was talking about. And that's this controller here. So what you can do is you just draw a rectangle. And as you can see, immediately when

I finish drawing the rectangle, the request is going to the server. It will actually go to all servers for which there is a layer in this map. And it will return the data which is within the rectangle. And the user has the option to change this rectangle

by adding points. And in real time, the filter will change. And it will fetch new data based on the new geometry. And this is basically what this application is all about.

You can show labels, for instance, here. You can change the transparency. You can show a legend, actually all the stuff you've used when you use other map tools.

But in this case, it's all based on Java and GWT, of course. So I think that more or less concludes my talk here. Are there any questions?

So if you are interested in checking it out or working it, just go to geomayers.org and have a look at it. This is not the free software, but there are applications

that you can download which show you similar stuff.