What is GeoNetwork?

GeoNetwork is a server side application that allows you to maintain a geographic referenced metadata catalogue. This means: a search portal that allows to view metadata combined with maps.

GeoNetwork logo
The yoga man

Based on Free and Open Source Software, it strictly follows different standards for metadata, from Inspire to OGC. It implements the CSW interface to be able to interact with generic clients looking for data. It also has built-in harvesters to connect to other servers and populate data.

This has allowed GeoNetwork to expand to a lot of organizations. For example: the swiss geoportal or the brasilian one, not forgetting the New zealander. GeoNetwork is the most used open sourced spatial catalog in the world. You can find it in most of the public administrations that use free and open source software.

The catalogue deploys on a java application container (like tomcat or jetty). It works over the Jeeves framework. Jeeves is based on XSLT transformation server library. This allows a powerful development of interfaces, for humans (HTML) or machines (XML). Therefore, it makes metadata from GeoNetwork to be easily accessible by different platforms.

Recently half-refactored to Spring and AngularJS, GeoNetwork has a REST API and an event hook system to make extensions and customizations easier.

Notes on the GeoServer Workshop

These are the notes I took on the GeoServer workshop at the last gvSIG Conference.

Data Directory

It is important to change the settings of the geoserver_data_dir in the web.xml file to keep the data each time you restart the application container (like Tomcat). It is also good to check out the other settings as it contains interesting facts such as the type of projections to be used or the size of the cache. There are configurable data on the fly and data not configurable on the fly.

Let’s try adding some data sources to generate the layers. To add a shapefile, you have to copy the file in the same physical server machine. To include the shapefile in GeoServer, look for the option of adding a new shapefile datastore type. If you use the location “file: data /…” you use a relative uri to geoserver. You can also search using the “Browse” and use absolute paths.

Warning: Do not you give permission to any user on the configuration interface because they can see all the physical hard disk in this type of dialog.

Memory Mapped Buffers

It is best to use memory mapped buffers (unless you use Windows) if you have enough RAM, then you will avoid continuous access to physical disk. Also, it is best to reproject from native to declared projection. If the shapefile is very big, calculate the bounding box take some time. This does not happen in real databases where spatial indexes.

GeoServer allows you to insert watermarks in your data (for example to use OpenStreetMap).

When you use database connections, you should check the validate connection option, because you never know when the connection is going to crash.

GeoWebCache

GeoWebCache allows, on the latest version of GeoServer, to set up easily which layers will be cached.

You can use data which varies through time, for example for storms and hurricanes. On the database table, you will have a column for time. You can also use elevation data, but then you have to use it with Google Earth. The interesting thing is that, once you have the data, some hipothetical free visor can be used to support it…

Notes of the gvSIG 2.0 workshop

This are the notes that I took over gvSIG 2.0 on the latests Jornadas GvSIG.

Pre-requisites

  • Java
  • Eclipse
  • Ant (should)
  • Maven (should)
  • gvSIG (this is recursive :))

The main advantage of gvSIG 2.0 is that you can create a new plugin without knowing how does gvSIG work or having to compile it. We already have a gvSIG installation that deploys the binaries to the workspace. But we don’t have to change the source code. Unless, of course, something doesn’t work (bugs) or we have to add some new functionality to the core. Better if you don’t touch it, ask the developers and they will take care.

Creating the workspace

With the binary, there is a wizard which creates an Eclipse workspace with a default template. That leaves all set up but to compile our extension. It also includes a wizard to easily generate installables. These wizards are accessible through the application, at the application menu.

Org.gvsig.tools is the basic infrastructure library to develop plugins. The main functionality is focused on the registration of extension points, utilities to separate API, implementations, SPI (service provider), and monitoring tasks (which in version 1.0 used to freeze the application). This library also supports events, persistence, etc …

gvSIG Plugins

A library is a jar. When our application contains the jar, org.gvsig.tools prepares and initializes this library within the core. The classes in the library implement the interface Library (AbstractLibrary).

The managers (PluginsManager) is the entry point of the features. They are like factories (singletons) (at least one per library) that raises the request of the functionality included in the library. It also saves the configuration of the module.

The locators (PluginsLocator) allow to register implementations of managers.We can recover a specific manager API. “Give me the manager of this library.”

A Plugin is a piece that adds a functionality: buttons and toolbars, menu options, data providers and types of documents. Andami has not evolved much since version 1.x. Andami is the framework for the plugins.

The plugin will always have at least two files:

  • config.xml indicating the classes that implement the plug-in units and menus
  • package.info indicating the version, name, build, … of the plugin.

gvSIG Extensions

An extension (IExtension) is a set of tools associated with a plugin inside a toolbar or menu and they work together. A group of plugins, you may say. The extension that implements ExclusiveUIExtension specify what tools are or not visible, without touching the core code.

To create a new plugin, we make use of the tool menu generation of plugins available from the development version. This generates the workspace automatically and installs the plugin from which we generated the plugin. If you have no development release, you will have to compile the sources.

You should be starting a plugin with the wizard while reading this notes or you will be lost.

The plugin consists of two maven projects: org.gvsig.plugin and org.gvsig.plugin.app. org.gvsig.plugin provide the functionality of the library independently of gvSIG (business logic). May have library dependencies, but should be able to operate without having to open the application. That is, it requires nothing of Andami, for example. In org.gvsig.plugin.app.mainplugin (within org.gvsig.plugin.app) we will implement the functionality.

The “api” packages should contain interfaces and the “impl” packages should contain implementations.

Now the workspace is ready to work with Eclipse if we import the project with the maven plugin. If we took an appropriate template to generate the plugin sources, almost all the work is done (except for the exact business logic of our plugin).

Final Advices

It is important to have a java project to test our plugin with its own main, without having to start gvSIG. Also it is recommended that the library has unit tests. That is, we can make an application with the full power of gvSIG, but without using gvSIG itself, ie as if it was a powerful library GIS. Conclusion: if we do well, we could even use our plugin into another no application … as Gofleet.

Each plugin contains own installer, which created by a wizard inside the application.