deegree configuration tool
This page describes how to setup and use the deegree configuration tool.
Contents
1. Overview
The deegree configuration tool can be used to configure a WMS with simple WFS based layers and WCS based layers. Simple WFS featuretypes can be created as well as coverages for the WCS. It can either operate directly on the services, or use a (possibly remote) configuration service.
The configuration tool is an OpenJUMP package comprising a few plugins. Since it operates directly with services such as WMS, WFS etc. it is required that recent versions of the deeJUMPplugin and the WFSplugin are installed as well.
2. Setting up OpenJUMP and plugins
The deeJUMPplugin page contains a lot of information about setting up the various required plugins. In short, installing the configtool amounts to the following:
download and unzip a recent nightly build of OpenJUMP
download the library package and unzip into your OpenJUMP lib folder
copy the deejump.jar into your OpenJUMP lib/ext folder
copy the wfsplugin.jar into your OpenJUMP lib/ext folder
copy the owsconfig_stable.jar into your OpenJUMP lib/ext folder if you want the stable version, OR
copy the owsconfig.jar into your OpenJUMP lib/ext folder if you want the bleeding edge version
IMPORTANT NOTE: the nightly build of OpenJUMP is currently not available. You should use a prepackaged, inofficial version from OpenJumpPackages instead and swap .jars as needed.
You'll probably end up with too many libraries in the lib folder, if you use the stable version, but that should be alright (makes upgrading later on easier).
If I didn't make a mistake here, you should by now have an OpenJUMP version with a 'deegree' menu. That already enables you to edit services locally, but the configuration service makes many things more convenient even if you only use it on your own machine.
3. Releases
Here you can find specific "released" versions of the config tool packages (it is best to rename them to the basename, ie. owsconfig-0.9.jar -> owsconfig.jar after downloading):
- 0.9:
- 0.9.1:
You can run java -jar owsconfig.jar resp. java -jar wcfgs.jar to find out which version you have right now (this only works from 0.9 upward).
4. Configuration service
The configuration service is just another Java web application that can be used with tomcat. The following steps may help you to set it up on your machine:
download the stable example archive OR
download the bleeding edge example archive
- deploy the archive in a servlet container of your choice, preferably an Apache Tomcat 5.5 ...
Stop the web application so you can edit the configuration to suit your needs. The configuration is found in the WEB-INF/web.xml file. In particular the following parameters are interesting:
baseurl: this is the directory where new services should be deployed
tomcat*: with these parameters services can be restarted
postgis* or oracle*: these parameters define the database connection(s) to be used. At least one of postgis* and oracle* must be used.
- many other options are explained below
- now restart the configuration service
People who wish to upgrade to the latest bleeding edge version of the service download the wcfgs.jar here.
4.1. Configuration options
Here's an explanation of all configuration parameters. Almost all of these exist in both the stable and the unstable version of the service (it is noted where not).
users: This file will be used to store the users and their passwords. Do not edit this file by hand. Default is WEB-INF/conf/users.
services: This file will be used to store services that are controlled by this service. Do not edit this file by hand. Default is WEB-INF/conf/services.
template: This file will be used as a template for new services. Edit this file to suit your needs (eg. replace the deegree2.jar by a new version). Remember to leave the conf directory empty. Default is WEB-INF/conf/template.war.
admin: This user is the administrator for the configuration service. He is allowed to add, removed and modify users. Default is admin, with password admin.
tomcataddress: The reload address of the tomcat which can be used to restart services. Default: http://localhost:8080/manager/html/reload?path=
tomcatuser: The tomcat user that is allowed to use the manager to restart services. Default is tomcat.
tomcatpassword: The password for the tomcat user. Default is tomcat.
duration: How long sessions will be valid, in seconds. Default is 3600.
baseurl: The directory where new services will be deployed. Default is ${catalina.home}/webapps.
wmstemplate: The configuration template for new WMS services. Default is to use the internal one.
wfstemplate: The configuration template for new WFS services and the WMS LOCALWFS_capabilities.xml. Default is to use the internal one.
wcstemplate: The configuration template for new WCS services and the WMS LOCALWCS_capabilities.xml. Default is to use the internal one. Only available in the bleeding edge version of the service.
stylestemplate: The template for the WMS styles.xml. Default is to use the internal one.
featureinfo2htmltemplate: The template for the featureinfo2html.xsl script. Default is to use the internal one.
featureinfo2gmltemplate: The template for the featureinfo2gml.xsl script. Default is to use the internal one.
postgisaddress, postgisuser, postgispassword: Connect information for the PostGIS database. Choose at least one of PostGIS or Oracle.
oracleaddress, oracleuser, oraclepassword: Connect information for the Oracle database. Choose at least one of PostGIS or Oracle.
deleteTables: if set to true, users can be equipped with the right to delete database tables upon removal of a WMS layer. Default is false.
arbitraryDatabaseAccess: if set to true, users can be equipped with the right to access arbitrary databases. Default is false.
5. Using the config tool
The config tool can be used in a variety of ways. Some common scenarios will be explained in the following sections.
The options can be roughly grouped into three types. There are options to manage local services, options to manage remote services and admin functions for a remote service.
All options related to WCS and coverages are only available in the bleeding edge version.
5.1. Using the config tool without the service
The most straightforward functions to use the config tool are the ones labelled Edit local W*S. With these functions one can edit already existing services. One can also create new local services with this function, although this only includes editing the service configuration itself (and no handling of libraries, tomcat contexts etc.). In particular, one can edit the service metadata of all the service types.
The editing of the services itself should be straightforward as well, you can edit feature types, layers, remove them etc. They should be fairly self-explanatory. Adding new components is only available for WCS here, all other services have special wizards to create new feature types/layers.
The Add to ... WMS configuration option can only be used if you opened a shape file and selected the related OpenJUMP layer.
WCS coverages are usually created using the RasterTreeBuilder. The Create new coverage option provides a front end to this command line tool.
5.2. Using the config tool with the service
In principle, you have similar options here as with local editing of services. You find them under the menu entry Manage services, where one can also add and remove services. Users of the bleeding edge version can also start, restart and stop services here.
When adding a new service, one is asked to provide a server address. This is the value that will be used in all related configuration documents as the new services' address. If the service will be reached by the address http://www.deegreelovers.org/MyNewService/services?request=... you should enter http://www.deegreelovers.org here.
There are also the special options Extract WFS/WCS and Overwrite local WFS/WCS. Every WMS has a local WFS and/or WCS integrated. These internal services can be extracted and overwritten with these options. This is useful if you want to edit the style of a WFS layer, add a few more coverages, rename coverages, edit feature types etc. of these services. For the time the services are extracted, they can be used just like any other service.
Please take note that some of the wizards behave a little different than their local counterparts. For example, adding a new WFS feature type locally may be based directly on a shape file. If you add a remote feature type, the shape file will be stored in a database. The same is true for adding WMS layers, which are always based on shape files when used locally, and always stored in a databased when used remotely.
5.3. Using the config tool to manage the service/users
Besides changing your own password, an administrator may also add, edit and remove users for the remote configuration service. Depending on the administrators wishes, the service can be used in different ways.
It's possible to set up new users so they cannot add/remove services. If that's what's desired, the administrator should create some services for a new user and add them to his list. The new user will only be able to edit the services which he is allowed to.
The administrator can also add the same service to several users. This has the advantage that not too many services are used, but the disadvantage that concurrent changing of services may lead to consistency problems. Do it on your own risk.
The most flexible way is that users can add/remove their own services.
5.4. Customizing the config tool so as not to confuse its users
Administrators installing the configuration tool for users may wish to control which features the users have access to. This may be done by placing a owsconfig.properties in the user's $HOME/.jump/ directory. Separators can be added with a line like -=yes. The default file looks like this:
ManageUsers=yes ChangePassword=yes -=yes ManageServices=yes AddRemoteWMS=yes CreateRemoteWFS=yes AddWFSLayer=yes Style2RemoteWMS=yes -=yes AddLocalWMS=yes CreateLocalWFS=yes CreateNewCoverage=yes EditLocalWMS=yes EditLocalWFS=yes EditLocalWCS=yes
6. Issues
The issues are now collected at wald.
Issues fixed in the unstable version:
- use transaction blocks when inserting shape files into DBs
7. Wishes/Improvements
The issue tracker at wald supports wishes and improvements, so they shouldn't go here any more.
Issues fixed in the latest trunk:
- first step of
- When a layer will be deleted, delete the tables as well. User complain when the want to reimport the same data and they cannot do it (In a first step, give them more advice what to do next. Instead of just "The table XXX already exists.", they could get the info to rename their layer. In a second step create the layernames and tablesname automatically.)
- tables are now deleted if the user is allowed to do it and if the user confirms the deletion (upon removing WMS layers)
- username/password are remembered now
- separators are used in the menu now
- names of CRS are used now in addition to EPSG codes
8. Tips
The best tip is to setup a PostGIS database somewhere, get some shape files, setup the config service and try it out. By using the tool you'll get a feel for how it works. Setting up a deegree WMS from a shape file has never been so easy.
Since you'll probably jump on one bug or another, feel free to contact Andreas <schmitz AT SPAMFREE lat-lon DOT de> so he can fix them.