deegree iGeoPortal - Standard Edition v2.4

Change log

1. Introduction

deegree is a Java Framework offering the main building blocks for Spatial Data Infrastructures (SDIs). Its entire architecture is developed using standards of the Open Geospatial Consortium (OGC) and ISO Technical Committee 211 – Geographic information / Geoinformatics (ISO/TC 211). deegree encompasses OGC Web Services as well as clients. deegree is Free Software protected by the GNU Lesser General Public License (GNU LGPL) and is accessible at http://www.deegree.org.

deegree2 is the new release of deegree supporting a number of features that deegree1 was not able to handle. This documentation describes setup and configuration of the new deegree iGeoPortal standard edition, a client imple­mentation of OGC's Web Map Service Implementation Specification 1.1.1 using OGC's Web Map Context documents for configuration.

deegree iGeoPortal is the web-based portal framework of deegree. It offers visualization of geodata through a standard web browser like Mozilla, Firefox or MSIE. The demo download that accompanies this document includes the standard functionality of iGeoPortal. This is basically a „Web-GIS“ using WMS servers as map source.

Additional modules not configured in this download package enable the user to search for and download data or digitize online and insert the result including its properties via transactional WFS into a database backend like Postgresql/Postgis, and navigate the displayed map using an OGC Gazetteer (WFS-G). Each user is able to store the current state of the portal in an OGC Web Map Context document that can be loaded again later to restore the portals state. If assigned to deegree users and a right management system (iGeoSecurity) the portal can limit this and other functions to authorized users and enable personalized configuration. A component for accessing OGC catalogue services for ISO 19115/19119 metadata is also under development.

The demo portal is preconfigured to work with a remote deegree2.2 demo Web Map Service (WMS), but there is no limitation on using other OGC WMS, for example UMN MapServer or other, (proprietary) servers that can be installed on remote machines. iGeoPortal is not limited to be used with just one WMS. You can combine several WMSs in one predefined context as well as load additional WMSs 'on the fly'. Additionally a simple search module based on a deegree2.2 demo WFS-G (Web Feature Service – Gazetteer enabled) is implemented.

To get an overview about deegree WMS and other deegree components that may be used within the context of iGeoPortal please have a look at the respective documentation. This document will deal only with the administration of iGeoPortal.

Besides iGeoPortal, deegree comprises a number of additional services and clients. A complete list of deegree components can be found at:

http://www.lat-lon.de → Products

Downloads of packaged deegree components can be found at:

http://www.deegree.org → Download

The web services of deegree are realized as Java modules controlled by one central servlet (the “dispatcher”). This servlet has to be deployed to the respective web server/servlet engine. Most of the common web servers support servlet technology, thus making deegree a universal product. The Apache-Tomcat 5.5 Servlet-Engine is recommended due to its widespread use and its status as an open-source product.

2. Download / Installation

   1. Prerequisites

For deegree2 iGeoPortal to run you need:

• Java (JRE or JSDK) version 1.5.x

• Tomcat 5.5.x

For installation of these components refer to the corresponding documentation at java.sun.com and tomcat.apache.org.

2. deegree iGeoPortal release

deegree iGeoPortal can be downloaded from http://www.deegree.org. The release is packed as a WAR-archive (igeoportal-std.war). Simply put this file into your $TOMCAT_HOME$/webapps directory and (re-)start Tomcat. The installation of iGeoPortal is already done with this, as long as you run tomcat on port 8080 and it is accessible via 'localhost'. The package comes preconfigured with a remote deegree2.3 demo WMS, why there is no further configuration needed to get it up an running.

Note: It is also possible to extract the WAR archive (which is nothing but a renamed .zip file) into another place of your computer and direct Tomcat to this place. Because of this possibility, in the remainder of this document, the directory you extracted the files to is referred to as $iGeoPortal_home$ (=$TOMCAT_HOME$/webapps/igeoportal-std in the standard case).

The example uses a deegree WMS but this is not required. Each WMS compliant to OGC WMS 1.1.0 – 1.1.1 specifications can be used as well.

3. Testing the installation

After deploying the application to tomcat, the portal can be started by entering:

http://localhost[:port]/igeoportal-std

into the address bar of your browser (this usually is http://localhost:8080/igeoportal-std). Doing this should open the entry page.

Figure 1: Welcome page of deegree iGeoPortal

Figure 2: Initial page when starting deegree iGeoPortal

Congratulations – you now have iGeoPortal running!

3. Basic Configuration

The central configuration files of deegree iGeoPortal are XML documents that are valid against the XML-schema defined in OGC's Web Map Context specification 1.0.0. This schema defines two sections that are allowed to contain any well formed XML fragments. These sections (extensions in WMC syntax) are used by iGeoPortal to define layout and additional data access methods. Nevertheless a deegree iGeoPortal context document is a compliant WMC document and iGeoPortal is able to read and use WMC documents from other vendors.

As stated above, an OGC WMC document is divided into several parts. Apart from the mandatory or optional parts of the WMC specification it is possible to use elements called <Extension> to define vendor specific elements/behaviours. The content of the the <Extension> element is defined as <xs:any> so the only restriction is that it has to be a well formed XML fragment.

deegree iGeoPortal uses these elements mainly for definition of the graphical structure of the portal and definition of access paths to resources required by the portal. A detailed description of the content of all elements defined by the OGC can be found within the WMC specification that can be downloaded from the OGC pages (see https://portal.opengeospatial.org/files/?artifact_id=3841). Therefore only those elements will be explained in this documentation which are crucial for deegree iGeoPortal.

1. Basic Structure of Map Context Files

The root element of each map context configuration file is <ViewContext>. It contains the required namespace definitions and two child elements, <General> and <LayerList>.

<?xml version="1.0" encoding="UTF-8"?>

<ViewContext xmlns="http://www.opengis.net/context"
xmlns:sld="http://www.opengis.net/sld"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
version="1.0.0" id="String">

<General>

...

<!-- described in chapter 3.2 -->

...

</General>

<LayerList>

...

<!-- described in chapter 3.3 -->

...

</LayerList>

</ViewContext>

The contents of these elements will be described in detail in the following paragraphs.

2. General definitions

The element <General> contains definitions of map size, map extent and of vendor and content description. In detail these are:

• size of the map window in pixel (<Window>),

• geographic extent of the map including coordinate reference system to be used (<BoundingBox>)

• name of the map/portal context (<Title>),

• optional list of keywords describing the map/portal context (<KeywordList>),

• optional description of the map/portal context(<DescriptionURL>),

• contact information (<ContactInformation>)

• several extensions (<Extension>) made by deegree that will be explained in the next few sections.

<General>

<!-- specifies the map size and must correspond to the module MapView definded further below. The <BoundingBox ...> sets the used CRS and the initial extend (used for button View full extent). BBox must have the same proportion as the <Window ...> settings. →

<Window width="700" height="550" />

<BoundingBox SRS="EPSG:26912" minx="17300" miny="4049850" maxx="867300" maxy="4699850" />

<Window width="700" height="550" />

<BoundingBox SRS="EPSG:26912" minx="17300" miny="4049850" maxx="867300"
maxy="4699850" />

<Title>deegree iGeoPortal</Title>

<KeywordList>

<Keyword>deegree</Keyword>

<Keyword>iGeoPortal</Keyword>

<Keyword>SDI</Keyword>

<Keyword>GDI</Keyword>

<Keyword>lat/lon</Keyword>

<Keyword>utah</Keyword>

</KeywordList>

<DescriptionURL format="text/html">

<OnlineResource xlink:type="simple" xlink:href="http://www.deegree.org" />

</DescriptionURL>

<ContactInformation>

<ContactPersonPrimary>

<ContactPerson>Andreas Poth</ContactPerson>

<ContactOrganization>lat/lon</ContactOrganization>

</ContactPersonPrimary>

<ContactPosition>developer</ContactPosition>

<ContactAddress>

<AddressType>postal</AddressType>

<Address>Aennchenstr. 19</Address>

<City>Bonn</City>

<StateOrProvince>NRW</StateOrProvince>

<PostCode>53177</PostCode>

<Country>Germany</Country>

</ContactAddress>

<ContactVoiceTelephone>++49 228 184960</ContactVoiceTelephone>

<ContactElectronicMailAddress>poth@lat-lon.de</ContactElectronicMailAddress>

</ContactInformation>

<Extension xmlns:deegree="http://www.deegree.org/context">

<deegree:IOSettings>

...

<!-- described in chapter 3.2.1 -->

...

</deegree:IOSettings>

<deegree:Frontend scope="JSP">

...

<!-- described in chapter 3.2.2 -->

...

</deegree:Frontend>

<deegree:MapParameter>

...

<!-- described in chapter 3.2.3 -->

...

</deegree:MapParameter>

</Extension>

</General>

1. Extension – IOSettings

The element <IOSettings> describes some directories, where iGeoPortal stores files such as print files. If you change the configuration of one of the demo context files or define one of your own, you should keep in mind that only the definition of <PrintDirectory> and <TempDirectory> is mandatory. If some or all of the other directory definitions are missing, deegree will use the <TempDirectory> instead. Depending on the used functionalities of a portal instance it may not be necessary to publish all directories to the web. In this case a directory can be located outside the web context or below the WEB-INF directory. To access the directories content a web application must be defined in <deegree:Access> instead of the path to the directory.

The iGeoPortal demo uses the following reduced IOSettings. Because no module for user defined styles (SLD) is offered at the moment, corresponding directory definitions would not make sense.

<Extension xmlns:deegree="http://www.deegree.org/context">

<deegree:IOSettings>

<deegree:TempDirectory>

<deegree:Name>../../../tmp</deegree:Name>

<deegree:Access>

<OnlineResource xlink:type="simple"
xlink:href="http://localhost:8080/igeoportal-std"/>

</deegree:Access>

</deegree:TempDirectory>

<deegree:PrintDirectory>

<deegree:Name>./../../../print</deegree:Name>

<deegree:Access>

<OnlineResource xlink:type="simple"
xlink:href="http://localhost:8080/igeoportal-std/print?"/>

</deegree:Access>

</deegree:PrintDirectory>

<deegree:DownloadDirectory>

<!-- relative path to the folder referenced in the DownloadServlet of
igeoportals web.xml -->

<deegree:Name>../../downloads</deegree:Name>

<deegree:Access>
<OnlineResource xlink:type="simple"
xlink:href="http://localhost:8080/igeoportal-std" />
</deegree:Access>
</deegree:DownloadDirectory>

<deegree:SLDDirectory>

<deegree:Name>../../../</deegree:Name>

<deegree:Access>

<OnlineResource xlink:type="simple"
xlink:href="http://localhost:8080/igeoportal-std" />

</deegree:Access>

</deegree:SLDDirectory>
</deegree:IOSettings>

...

</Extension>

2. Extension – Frontend

The element defined within the <Extension> element associated to layout is the <Frontend> element. It is used to define the graphical user interface, as well as other system-specific parameters, not seen by the end-user. A short overview is given here, the details will follow below.

<deegree:Frontend scope="JSP">

<deegree:Controller>...</deegree:Controller>

<deegree:Style>...</deegree:Style>

<deegree:Header>...</deegree:Header>

<deegree:Footer>...</deegree:Footer>

<deegree:CommonJS>...</deegree:CommonJS>

<deegree:North hidden="false">...</deegree:North>

<deegree:East hidden="false">...</deegree:East>

<deegree:West hidden="false">...</deegree:West>

<deegree:South hidden="false">...</deegree:South>

<deegree:Center hidden="false">...</deegree:Center>

</deegree:Frontend>

The idea of iGeoPortal is to encapsulate different functionalities in separate modules. These modules work as independent as possible from each other and they all use the same interface. So e.g. the map, its legend, or the layer list are all realized by separate modules. Each module can be located anywhere in the portals predefined layout frames. Except for map view and (the invisible) map model the registration of modules is optional. So it's your decision which functions to offer users of the map context instance (consider: each map context can define its own collection of available modules!).

Figure 3: Area definitions of iGeoPortal

All modules are dynamically located on the portal's skin based on their settings. To enable the administrator of a portal to influence the portals layout deegree defines seven areas. A module can be assigned to five of these areas (North, East, South, West, Center); the other two areas (Header, Footer) are designed for taking links to simple HTML-content (static or dynamic). Usually they will be used for corporate identity, menus, external links etc.

The Controller will receive all portal driven events (zoomin, pan, print etc.) and delegates them to the responsible modules.

<deegree:Frontend scope="JSP">

<deegree:Controller>./controller.jsp</deegree:Controller>

<deegree:Style>./css/deegree.css</deegree:Style>

<deegree:Header>header.jsp</deegree:Header>

<deegree:Footer>footer.jsp</deegree:Footer>

<deegree:CommonJS>

<deegree:Name>htmllayer.js</deegree:Name>

<deegree:Name>layergroup.js</deegree:Name>

<deegree:Name>pushbutton.js</deegree:Name>

<deegree:Name>recentertolayer.js</deegree:Name>

<deegree:Name>togglebutton.js</deegree:Name>

<deegree:Name>./javascript/envelope.js</deegree:Name>

<deegree:Name>./javascript/event.js</deegree:Name>

<deegree:Name>./javascript/exception.js</deegree:Name>

<deegree:Name>./javascript/feature.js</deegree:Name>

<deegree:Name>./javascript/geometries.js</deegree:Name>

<deegree:Name>./javascript/geometryfactory.js</deegree:Name>

<deegree:Name>./javascript/geometryutils.js</deegree:Name>

<deegree:Name>./javascript/geotransform.js</deegree:Name>

<deegree:Name>./javascript/json2.js</deegree:Name>

<deegree:Name>./javascript/layerutils.js</deegree:Name>

<deegree:Name>./javascript/rpc.js</deegree:Name>

<deegree:Name>./javascript/rendering.js</deegree:Name>

<deegree:Name>./javascript/request_handler.js</deegree:Name>

<deegree:Name>./javascript/style.js</deegree:Name>

<deegree:Name>./javascript/utils.js</deegree:Name>

<deegree:Name>./javascript/wktadapter.js</deegree:Name>

</deegree:CommonJS>

...

</deegree:Frontend>

The Controller definition is followed by setting the central stylesheet document which controls the portals layout. Definitions made here can be overwritten by CSS definitions made in an HTML-page assigned to a loaded module. Afterwards the optional content of the header and footer section will be defined (note: contents of header and footer does not have to be a static HTML-page). Definition of 'common' JavaScript files used by more than one module is optional too but it strongly recommended. If a JavaScript or HTML file is defined without absolute or relative path settings, the file must be located in $iGeoPortal_home$ directory. Relative path settings use this directory as the starting point.

After this follows the definition of the used areas (each area is allowed to be empty or can be left out completely) and the modules contained in these areas. The following example demonstrates how the module 'MenuBarTop' is assigned to the 'North' area.

<deegree:Frontend>

...

<deegree:North hidden="false">

<deegree:Module hidden="false" type="content" width="990" height="22"

scrolling="no">

<deegree:Name>MenuBarTop</deegree:Name>

<deegree:Content>menubartop.html</deegree:Content>

<deegree:ModuleJS>menubar.js</deegree:ModuleJS>

</deegree:Module>

</deegree:North>

...

</deegree:Frontend>

Each area may include the optional attribute 'hidden' to define if an area should be visible when the context is loaded into the portal. This may be useful if an area's content just is intended to be visible in some situations. Its default value is 'false'.

At the example above the 'MenuBarTop' module is embedded within the 'North' area. Even if the example shows just one module within an area there is no limit to the numbers of modules that can be registered to an area (if you register too many modules you may get a somehow strange portal layout). If more than one module is registered to an area deegree tries to arrange the modules considering their real size, preferred size (width, height attributes) and available space. Modules within 'North' and 'South' area will be arranged horizontally, modules within 'West', 'Center' and 'East' will be arranged vertically.

Five attributes can be assigned to each module registered to an area. But just one of them (the type) is mandatory:

• hidden: defines whether a module should be visible when the context is loaded (default = false)

• type: defines the type of the module, (content | toolbar); no default

• width: preferred module width (may be modified by deegree)

• height: preferred module height (may be modified by deegree)

• scrolling: defines whether scrollbars should appear if a module exceeds available space (auto | no | yes; default = auto)

As sub-element of a <Module> element its name (<Name>), resource of its content (<Content>) and a JavaScript file will be set. The last contains a JavaScript object having the identical name as the module it is assigned to (this is mandatory, see below) (MenuBarTop in the example above). If the content (e.g. a static HTML page) already contains a JavaScript object with the same name as the module <ModuleJS> can be left out.

For each module a parameter definition may be given. Each parameter (name/value) will be passed to the constructor of the JavaScript object assigned to a module. If a module receives more than one parameter the parameter definition must be in the same order the JavaScript object constructor expects it.

<deegree:Module hidden="false" type="content" width="150" height="35">

<deegree:Name>DefaultContentSwitch</deegree:Name>

<deegree:Content>defaultcontentswitch.html</deegree:Content>

<deegree:ModuleJS>contentswitch.js</deegree:ModuleJS>

<deegree:ParameterList>

<deegree:Parameter>

<deegree:Name>targetIFrame</deegree:Name>

<deegree:Value>'LayerListView'</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>sourceModules</deegree:Name>

<deegree:Value>'LayerListView|layerlistview.html</deegree:Value>

</deegree:Parameter>

/deegree:ParameterList>

</deegree:Module>

All modules available for the demo of deegree iGeoPortal Std. Ed. are described in chapter 4.

1. Overlay of areas and modules

With version 2.3 the portal opens up the strict layout of north, east, south, west and center areas. It is now possible to define areas and modules to "float" above other elements as overlays. Areas and modules marked as overlay will get their fixed absolute position through the attributes top and left. All in all there are four new attributes that enable to define areas or modules as overlay.

• overlay: (true | false) defines whether the area or module should be positioned as overlay. If set to "true", then the next three parameters need to be specified as well.

• top: defines the distance of the overlay window to the top of the portal ("75")

• left: defines the distance of the overlay window to the left side of the portal ("10")

• header: (true | false) defines, whether the overlay window should have a title bar with buttons for minimising and maximising this overlay window.

An example for module marked as overlay with the extra attributes (overlay, top left, header) is given below.

<deegree:Module hidden="false" type="content" width="150" height="150"

overlay="true" header="true" top="75" left="10" scrolling="no">

<deegree:Name>MapOverview</deegree:Name>

<deegree:Content>mapoverview.html</deegree:Content>

<deegree:ModuleJS>mapoverview.js</deegree:ModuleJS>

<deegree:ParameterList>

...

</deegree:ParameterList>

</deegree:Module>

If an area is marked as overlay, it may not contain any overlay modules. Thus, modules marked as overlay may only appear in areas that are not overlayed themselves.

Each area and each module marked as overlay need their own css class in ./css/deegree.css. Following rules apply: classes for modules are named as the module prefixed with "class", classes for areas are called as the area and postfixed with "Window".

First example for a module: The css class for the module "MapOverview" is called "classMapOverview".

.classMapOverview {
position: absolute;
background: #FFFFFF;
border: #000000 2px solid;
opacity: .80;
filter: alpha(opacity=80);
-moz-opacity: 0.80;
}

The first two lines (position, background) are necessary for every overlay module. The other parameters (border, opacity, filter and -moz-opacity) are being used for the window titel bar, enabling the portal user to open and close the overlayed window. They only need to be specified, if the modules attribute header is set to true (see abve).

Second example for an area: The css class for the "east" area is called "eastWindow".

.eastWindow {
position: absolute;
background: #FFFFFF;
border: #000000 2px solid;
opacity: .90;
filter: alpha(opacity=90);
-moz-opacity: 0.90;
}

The above example contains the same css parameters as the module example. Also possible would be a definition as the one below:

.eastWindow {

position:absolute;

background-image:url( '../images/space.gif' ) ;

}

Please remember that it is not the css that defines whether an area or a module are displayed as overlay. Only the style information is provided here. To define an area or a module as overlay, you need to set the respective attributes in the web map context files.

3. Extension – MapParameter

Below the frontend description (list of available modules) the parameters of deegree:MapParameters describe the behaviour of the map in general. The section defines the format of the GetFeatureInfo request, the factor for zooming in or out, the factor for paning the map and the minimum and maximum scale that is permitted for the map view in general.

<deegree:MapParameter>

<deegree:OfferedInfoFormats>

<deegree:Format>application/vnd.ogc.gml</deegree:Format>

<deegree:Format selected="true">text/html</deegree:Format>

</deegree:OfferedInfoFormats>

<deegree:OfferedZoomFactor>

<deegree:Factor selected="true">25</deegree:Factor>

</deegree:OfferedZoomFactor>

<deegree:OfferedPanFactor>

<deegree:Factor selected="true">15</deegree:Factor>

</deegree:OfferedPanFactor>

<deegree:MinScale>1</deegree:MinScale>

<deegree:MaxScale>100000</deegree:MaxScale>

</deegree:MapParameter>

Note: These values are currently not evaluated! Changing the values does not result in a changed behaviour of the portal. Hope for future releases.

3. LayerList

After the general definition of the layout and the registered functions of the portal follows the definition of the available layers and their resources, according to OGC Web Map Context (WMC) Specification. All WMC specific information is encapsulated within the <LayerList> element. One <LayerList> contains any amount of <Layer>-elements. The sequence of the layers describes the sequence of visible layers. Beneath all kinds of elements of WMC specification, every layer is extended by the <Extension>-element where you can define any other characteristics. deegree iGeoPortal uses some extensions for describing the data resources.

A <Layer>-Element has the following syntax:

<Layer queryable="1" hidden="1">

<!-- service="OGC:WMS" version="1.1.1"

principally iGeoportal is also capable of requesting WFS; this feaure is not usable yet.

The title="deegree Demo WMS" must be unique for every requested WMS, in case you configure more than one WMS.

xlink:href specifies the online resource of the service -->

<Server service="OGC:WMS" version="1.1.1" title="deegree Demo WMS">

<OnlineResource xlink:type="simple"

xlink:href="http://testing.deegree.org/deegree-wms/services?" />

</Server>

<!-- <Name> must be the WMS layer name -->

<Name>Springs</Name>

<!-- Title can be chosen freely and should be human readable -->

<Title>Springs</Title>

<!-- Specifies the requested CRS to the WMS. Should be identical to the Web Map Context (WMC) configuration -->

<SRS>EPSG:26912</SRS>

<FormatList>

<!-- sets the requested image format. Must be offered by WMS -->

<Format current="1">image/jpeg</Format>

</FormatList>

<StyleList>

<Style current="1">

<!-- set the style to be used. Must be offered by WMS -->

<Name>default</Name>

<Title>default</Title>

</Style>

</StyleList>

<Extension xmlns:deegree="http://www.deegree.org/context">

...

</Extension>

</Layer>

Each layer element contains two attributes for determining if a GetFeatureInfo-Request is possible (queryable="1") or if the layer is visible at start-up (hidden="1"). The first child element <Server> describes which Web Service delivers a specific layer. Via three attributes, its service type, -version and -title are set. Theoretically, WFS and WCS Services could be requested here. At the moment, neither the WMC specification nor deegree implements them, so only OGC:WMS instances can be referred to. The <Server>-element contains the OnlineResource with the URL of a WMS and its according layer. The title="WMS title" needs to be unique for every implemented (WMS)- Service.

After defining the WMS, there are some definitions that are pretty similar to the ones of a Capabilities Document of a WMS. It is important to mention that the statements are identical to the Capabilities or respectively subsets of them. For instance, the layer's name in the WMC document has to be identical to the WMS Capabilities document's layer name. The title can be different. The requested SRS for each layer of the portal has to be supported by the WMS. The same applies to the image format and style definition. Not all available formats, SRS and styles have to be defined.

1. Layer Extension

deegree specific informations for <Layer> are stored within an element named <Extension>. For example deegree iGeoPortal stores information on data access, authentication mechanism and valid scale range of a layer here.

<Extension xmlns:deegree="http://www.deegree.org/context">

<deegree:DataService>

<Server service="OGC:WFS" version="1.1.0" title="deegree WFS">

<OnlineResource xlink:type="simple"

xlink:href="http://testing.deegree.org/deegree-wfs/services?" />

</Server>

<deegree:GeometryType>

{http://www.deegree.org/app}:geometry

</deegree:GeometryType>

<deegree:FeatureType>

{http://www.deegree.org/app}:StateBoundary

</deegree:FeatureType>

</deegree:DataService>

<deegree:ScaleHint min="0" max="18000"/>

<deegree:UseAuthentication>none</deegree:UseAuthentication>

</Extension>

DataService: Via the element <DataService> the portal server knows, where it can get the original vector data for downloading. If no DataService for a layer is defined, downloads are not possible (proper support from version 2.4 onwards).

ScaleHint: Additionally, the scale range for visualizing a layer can be defined. It corresponds to the <ScaleHint> information of the WMS Capabilities and is optional.

If a <ScaleHint> is defined and the current map view is out of that scale range, the according layer in the layerlist is greyed out. This parameter will not overwrite the WMS ScaleHint settings. Therefore the map wil be displayed anyway. This parameter should only be used, if a WMS does not provide ScaleHint information in its capabilities (as should be done), but confines the map response to a certain scale range nonetheless.

Background info: According to WMS specification the <ScaleHint> is defined as 'the ground distance in metres of the southwest to northeast diagonal of the middle pixel of the map'.

UseAuthentication: The optional element <UseAuthentication> can be defined to give deegree a hint if authentication information is to be used when accessing capabilities of an OWS. The default value is 'none' which means that no authentication information will be used when accessing an OWS. To force authentication usage, either 'user/password' or 'sessionID' can be used. Using 'user/password' iGeoPortal adds the parameters USER and PASSWORD to requests against the OWS offering the requested layer; using sessionID a parameter named SESSIONID will be added.

When using 'user/password' or 'sessionID' you have to ensure, that:

1. a user's authentication is available for the client which loads a WMC

2. the OWS assigned with a layer is able to handle password authentication information

3. each layer within a WMC assigned to the same OWS must define the same value for <UseAuthentication> element.

2. Layer specialities

deegree iGeoPortal v2.3 comes with a Web Map Context (WMC) containing layers with direct access to OpenStreetMap slippy maps and layers based on OpenStreetMap data stored in a DB. The path to this WMC document is:

$igeoportal-HOME$/WEB-INF/conf/igeoportal/users/default/wmc_testOSM.xml.

Both, the slippy map layers and the layers based on OpenStreetMap data, will only work with the adequate configuration of a deegree Web Map Service. For further information, please look into the deegree Web Map Service documentation v2.3 (or later).

4. Available Modules

There are numerous modules available with iGeoPortal Standard Edition. In the demo releases at http://demo.deegree.org the start web map context is set to "Utah" (wmc_start_utah.xml), with the possibility to switch to "Salt Lake City" (wmc_saltlake.xml) for an example with raster data, or to our "Playground" (wmc_testPlayground.xml) where most new modules get integrated.

Since v2.3, a fourth web map context has been added to this list: "OpenStreetMap.NRW" (wmc_testOSM.xml) is an example for integrating the OpenStreetMap data (licensed under CC-by-sa) in the portal.

Some features activated in the online demo will not work out of the box for your downloaded and privately set up iGeoPortal. This holds true for those modules that need to be configured to your own requirements. You will find a comment in the description to these modules.

1. MenuBarTop/MenuBarBottom

Description: menu bar containing links to functions of the portal and internal or external HTML-pages. Both modules are simple in their construction. It isn't a problem to extend or limit the pre-defined link list.

Init-parameters: none

2. ContextSwitcher

Description: As described above the map context document is the basis for functions and modules visible in an iGeoPortal instance. The portal itself offers a 'container' where any valid map context document can be processed and visualized. ContextSwitcher represents a module that enables loading of other contexts during runtime and switching content of a portal instance. This enables offering different views or themes within one instance of iGeoPortal. All context documents that should be available for switching between must be stored in directory $iGeoPortal_home$/WEB-INF/conf/igeoportal.

The module is realised as an HTML-page with a combo box that is filled by the assigned JavaScript object evaluating the passed init-parameters.

Init-parameters:

<deegree:Module hidden="false" type="content" width="150" height="60">

<deegree:Name>ContextSwitcher</deegree:Name>

<deegree:Content>contextswitcher.html</deegree:Content>

<deegree:ModuleJS>contextswitcher.js</deegree:ModuleJS>

<deegree:ParameterList>

<deegree:Parameter>

<deegree:Name>label</deegree:Name>

<deegree:Value>'Theme selection:'</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>listOfContexts</deegree:Name>

<!--

If you want to test digitizerModule, gazetteerClient,

securityEnabledPortal, pdf printing or legend view

switch to the second <deegree:Value> entry OR load a stored

portal context.

-->

<deegree:Value>'Utah|wmc_start_utah.xml;Salt Lake City|

wmc_saltlake.xml;Playground|

wmc_testPlayground.xml;OpenStreetMap.NRW|

users/default/wmc_testOSM.xml'

</deegree:Value>

<!--

<deegree:Value>'Utah|wmc_start_utah.xml;Salt Lake City|

wmc_saltlake.xml;Playground|wmc_testPlayground.xml;

OpenStreetMap.NRW|users/default/wmc_testOSM.xml;

TestDynamicLegend|users/default/wmc_testDynLegend.xml;

TestPdfPrint|users/default/wmc_testPdfPrint.xml;

TestCustomTab|users/default/wmc_testCustomTab.xml;

TestLegendView|users/default/wmc_testLegend.xml;

TestFullScreen|users/default/wmc_testFullScreen.xml;

TestDigitizer|users/default/wmc_testDigitizer.xml;

TestGaz|users/default/wmc_testGazClient.xml;

TestSecurity|users/default/wmc_testSecurity.xml;

TestCSW|users/default/wmc_testCswClient.xml'</deegree:Value> -->

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>size</deegree:Name>

<deegree:Value>1</deegree:Value>

</deegree:Parameter>

<!--

optional param. if not set, value will be taken from deegree.css

(.pContextSwitcher)

-->

<!--

<deegree:Parameter>

<deegree:Name>bgcolor</deegree:Name>

<deegree:Value>'#cccccc'</deegree:Value>

</deegree:Parameter>

-->

</deegree:ParameterList>

</deegree:Module>

Four init-parameters are passed to the module. By using the 'label' we can define the headline above the combo box. Parameter 'listOfContexts' contains a comma separated list of available context documents. Each list entry consists of two parts. The first part is the context name as displayed in the combo box. The second, separated by a '|' character, is the name of the context document file as stored in $iGeoPortal_home$/WEB-INF/conf/igeoportal directory. The third init-parameter defines the size of the HTML select element displaying the list of available contexts. A value of '1' results in the display of a combo box. A value > 1 will force displaying a HTML list. The last parameter enables definition of the modules background color.

3. DefaultContentSwitch

Description: deegree iGeoPortal arranges all modules assigned to an area considering their size, the preferred size and available space automatically. Especially if a large number of modules should be registered to a portal/context available space may be exceeded. For this case iGeoPortal offers the DefaultContentSwitch module. It represents a module that enables loading more than one module inside one portal area and switching its content during runtime. One can switch to the needed module through list boxes, menu items, tab panes or whatever a ContentSwitcher offers. The DefaultContentSwitcher available with the demo iGeoPortal uses a combo box for switching between layer list and legend view.

To enable switching between different modules these modules have to be registered first as described above within a portal area. The provider/administrator of a module must ensure that only one of these modules is set to visible (hidden='false') all others have to be invisible (hidden='true'). After this the DefaultContentSwitcher will be 'informed' through its init-parameters between which modules switching has to be enabled.

Init-parameters:

<deegree:ParameterList>

<deegree:Parameter>

<deegree:Name>targetIFrame</deegree:Name>

<deegree:Value>'LayerListView'</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>sourceModules</deegree:Name>

<deegree:Value>

'LayerListView|layerlistview.html;Legend|legend.html'

</deegree:Value>

</deegree:Parameter>

</deegree:ParameterList>

The first parameter contains the name of the module that will be visible when loading the context. The second parameter contains a comma separated list of modules, between which switching will be possible. Each entry of the list contains two parts. The first part is the name of the module as displayed in the switchers combo box. The second is the name of content document assigned to a module.

4. CustomTabSwitch

Description: The CustomTabSwitch is a variation of the above Default­ContentSwitch. It also enables you to switch between layer list and legend view, but it uses tab panes instead of a combo box.

To test this functionality, please refer to the Web Map Context wmc_testCustomTab.xml.

Init-parameters: this module has the same init-parameters as the DefaultContentSwitch.

<deegree:Module hidden="false" type="content" height="25" width="175">

<deegree:Name>CustomTabSwitch</deegree:Name>

<deegree:Content>customtabswitch.html</deegree:Content>

<deegree:ModuleJS>customtabswitch.js</deegree:ModuleJS>

<deegree:ParameterList>

<deegree:Parameter>

<deegree:Name>targetFrame</deegree:Name>

<!-- value must correspond to first entry in
sourceModules value -->

<deegree:Value>'LayerListView'</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>sourceModules</deegree:Name>

<!-- order of entries in list is important. first entry
must be the visible module (targetFrame) -->

<deegree:Value>
'LayerListView|layerlistview.html;Legend|legend.html'
</deegree:Value>

</deegree:Parameter>

</deegree:ParameterList>

</deegree:Module>

The targetFrame contains the name of the module that will be visible when loading the context. The second parameter contains a comma separated list of modules, between which switching will be possible. The order of entries in this list is important. The first entry in the list must match the module that is chosen as initial module in targetFrame.

5. Legend

Description: The 'Legend' module is able to visualise the legend of the associated map. It calls the GetLegendGraphic-Function of an appropriate Web Map Service offering that optional function. The parameters used are mostly for controlling the layout.

Init Parameters:

<deegree:ParameterList>

<deegree:Parameter>

<deegree:Name>label</deegree:Name>

<deegree:Value>'Legend'</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>bgcolor</deegree:Name>

<deegree:Value>'#cccccc'</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>layerlist</deegree:Name>

<deegree:Value>this.layerList</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>width</deegree:Name>

<deegree:Value>20</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>height</deegree:Name>

<deegree:Value>20</deegree:Value>

</deegree:Parameter>

</deegree:ParameterList>

The parameter 'label' is for labeling the entire legend graphic; with 'bgcolor' the background color is defined. Initially the key 'layerlist' should not be changed; it is a reference to an internal list of map layers of the portal. It makes sense to change the key, if an instance of the portal contains more than one map in order to generate a separate legend for each map. With the parameter 'width' and 'height' you can define the size of the legend symbols (!), not the entire legend graphic itself.

6. Dynamic Legend

Description: This module is a variation of the standard legend module. Instead of simply creating a GetLegendGraphic request and sending this request to the WMS of the respective layer, its functionality is more complex:

If a layer definition in the map contexts LayerList (see chapter 3.3) provides a layer name, and a style definition including the style name and a legend URL, then this URL is used to retrieve the legend image.

If no legend URL is set in the map context, then it is checked whether the WMS capabilities document contains a URL for this layer and style.

If no legend URL can be retrieved from the capabilities document, but the WMS can answer GetLegendGraphics requests, such a request will be sent and the response will be used to display the legend.

If the WMS does not provide GetLegendGraphics requests, or if no legend URL is available for the respective layer, no legend will be displayed. Instead, the image defined as 'missingLegend' (see below) will be shown.

Please refer to wmc_testDynLegend.xml for testing this module.

Init parameter in wmc:

The only parameter needed in the module configuration is the 'label' used for labeling the entire legend graphic.

<deegree:Module hidden="true" type="content" width="250" height="460">

<deegree:Name>Legend</deegree:Name>

<deegree:Content>legend_dyn.jsp</deegree:Content>

<deegree:ParameterList>

<deegree:Parameter>

<deegree:Name>label</deegree:Name>

<deegree:Value>'Legend'</deegree:Value>

</deegree:Parameter>

</deegree:ParameterList>

</deegree:Module>

Since this module carries out many more tasks than the simple Legend module (chapter 4.5), it needs to call the server side to generate the legend. It is therefore necessary to add an event handler to the controller.xml as described in chapter 7.2.

Init parameter in controller.xml:

The configuration parameters for the drawLegend event are described inline.

<event name="mapClient:drawLegend"
class="org.deegree.portal.standard.wms.control.DynLegendListener"
next="legend_dyn.jsp" alternativeNext="container.jsp">

<parameter>

<!-- left space to edge of legend -->

<name>leftMargin</name>

<value>0</value>

</parameter>

<parameter>

<!-- right space to edge of legend -->

<name>rightMargin</name>

<value>0</value>

</parameter>

<parameter>

<!-- top space to edge of legend -->

<name>topMargin</name>

<value>10</value>

</parameter>

<parameter>

<!-- bottom space to edge of legend -->

<name>bottomMargin</name>

<value>10</value>

</parameter>

<parameter>

<!-- printing the layer titles? true (yes) or false (no) -->

<name>useLayerTitle</name>

<value>true</value>

</parameter>

<parameter>

<!-- just for GetLegendGraphicRequests:
if a legend is smaller than eg. 50px the layer title will
be printed into the legend image -->

<name>maxNNLegendSize</name>

<value>50</value>

</parameter>

<parameter>

<!-- separating the legend images from each other
by an image -->

<name>separator</name>

<value>images/legendSeparator.gif</value>

</parameter>

<parameter>

<!-- image displayed if no legend can be found -->

<name>missingImage</name>

<value>images/missingLegend.gif</value>

</parameter>

<!-- for iGeoSecurity only: list of servers which need to be
accessed through an owsproxy to get a LegendGraphic -->
<parameter>

<name>users</name>

<!-- the value *must* be adjusted to your system -->

<value>
http://demo.deegree.org/deegree-wms/services;username;password|
http://deegree.org/owsproxy/proxy;username;password
</value>

</parameter>

</event>

The last parameter ('users') only needs to be set in GDI-environments using iGeoSecurity (see respective documentation for details). If only iGeoPortal is running, and no server is accessed via owsproxy, this parameter must be omitted.

If one or more servers need to be accessed through an owsproxy, the parameter 'users' needs to be set. The 'value' contains a list separated by | (pipe), where each entry consists of server-address;username;password. Username and password are the admin's login values for the respective owsproxy.

7. LayerListView

Description: The module 'LayerListView' is pretty similar to the 'Legend'-module. It describes also a list of the layers of a map but unlike the legend module it can be changed during runtime: layers can be shifted in their sequence and can be switched on or off. Besides, it is possible to define layers which can be queried by a GetFeatureInfo-request.

There are two implementations of 'LayerListView' available. The first (available through JavaScript file layerlistview.js) enables selecting one and only one layer for being target for GetFeatureInfo request (example context wmc_start_utah.xml). The other implementation (available through JavaScript file layerlistview_allfi.js) will always select all layers that are visible and queryable for GetFeatureInfo requests (example context wmc_saltlake.xml).

Init parameters:

<deegree:ParameterList>

<deegree:Parameter>

<deegree:Name>name</deegree:Name>

<deegree:Value>'layerlistview'</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>layerlist</deegree:Name>

<deegree:Value>this.layerList</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>label</deegree:Name>

<deegree:Value>'Wuppertal'</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>bgcolor</deegree:Name>

<deegree:Value>'#c1d3ed'</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>fgcolor</deegree:Name>

<deegree:Value>'#4D96DE'</deegree:Value>

</deegree:Parameter>

</deegree:ParameterList>

The name, given first, is used for clear identification of the module; 'layerlist', 'label' and 'bgcolor' are used identically as for the module 'legend' above. Since the list of layer is generated dynamically, the font color for the list has to be set.

8. MapOverview

Description: The 'MapOverview' module provides an overview map at a set display resolution for the area of the entire context. MapOverview can be provided by a map server dynamically or simply by a georeferenced map graphic. Besides a JavaScript-object having the same name as the module, another JavaScript file is required (wz_jsgraphics_box.js) that is used for painting the current box describing the current extent of visible map.

Init parameter:

<deegree:Module hidden="false" type="content" width="150" height="150"
scrolling="no">

<deegree:Name>MapOverview</deegree:Name>

<deegree:Content>mapoverview.html</deegree:Content>

<deegree:ModuleJS>mapoverview.js</deegree:ModuleJS>

<deegree:ModuleJS>wz_jsgraphics_box.js</deegree:ModuleJS>

<deegree:ParameterList>

<deegree:Parameter>

<deegree:Name>src</deegree:Name>

<deegree:Value>'./images/overview.gif'</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>minx</deegree:Name>

<deegree:Value>2570000</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>miny</deegree:Name>

<deegree:Value>5668000</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>maxx</deegree:Name>

<deegree:Value>2593000</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>maxy</deegree:Name>

<deegree:Value>5691000</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>foregroundColor</deegree:Name>

<deegree:Value>'#ff0000'</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>width</deegree:Name>

<deegree:Value>150</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>height</deegree:Name>

<deegree:Value>150</deegree:Value>

</deegree:Parameter>

</deegree:ParameterList>

</deegree:Module>

The parameter 'src' describes the source of the map overview presentation. A reference to a file as well as a GetMap-Request referring to a specific Web Map Service is permitted. The parameters 'minx', 'miny', 'maxx' and 'maxy' define the bounding box of the map overview. 'foregroundColor' controls the color of the painted box showing the extent of the actual mapview. 'width' and 'height' determine the size of the map overview in pixels.

9. Toolbar

Description: Above the map window is a tool bar for navigating the map in different ways: ZoomIn, ZoomOut, ZoomToLayer, go back to initial bounding box, recenter the map, drag the map. Also buttons for adding additional WMS to the portal and for creating a print pre-view are available. The amount, sequence and position of the visible buttons as well as their tool tips are controlled by the init parameters. Button parameter name

Init parameters:

<deegree:ParameterList>

<deegree:Parameter>

<deegree:Name>refresh|refresh map</deegree:Name>

<deegree:Value>PushButton</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>movetoprevious|move to previous map</deegree:Name>

<deegree:Value>PushButton</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>movetonext|next to previous map</deegree:Name>

<deegree:Value>PushButton</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>zoomin|zoomin by mouse click or mouse drag</deegree:Name>

<deegree:Value>ToggleButton</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>zoomout|zoomout by mouse click</deegree:Name>

<deegree:Value>ToggleButton</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>zoom2layer|zoomtolayer by mouse click</deegree:Name>

<deegree:Value>PushButton</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>fullextent|zoom to full extent</deegree:Name>

<deegree:Value>PushButton</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>recenter|recenter the map by mouse click</deegree:Name>

<deegree:Value>ToggleButton</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>
move|drag the map by mouse with pressed mouse button
</deegree:Name>

<deegree:Value>ToggleButton</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>
featureinfo|get info to a object within the map
</deegree:Name>

<deegree:Value>ToggleButton</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>addwms|add additonal WMS to the map</deegree:Name>

<deegree:Value>PushButton</deegree:Value>

</deegree:Parameter>

<!-- for printing choose EITHER "plain print" OR "pdf print" method -->

<!-- PLAIN PRINT -->

<deegree:Parameter>

<deegree:Name>print|generate print view</deegree:Name>

<deegree:Value>PushButton</deegree:Value>

</deegree:Parameter>

<!-- PDF PRINT -->

<deegree:Parameter>

<deegree:Name>pdfprint|generate pdf</deegree:Name>

<deegree:Value>PushButton</deegree:Value>

</deegree:Parameter>

<!-- please delete the printing method that is not used →

<deegree:Parameter>

<deegree:Name>download|download WFS data</deegree:Name>

<deegree:Value>PushButton</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>selected</deegree:Name>

<deegree:Value>zoomin</deegree:Value>

</deegree:Parameter>

<deegree:Parameter>

<deegree:Name>bgcolor</deegree:Name>

<deegree:Value>'#e0e9f9'</deegree:Value>

</deegree:Parameter>

</deegree:ParameterList>

Apart from the last two parameters – one controls the tool that is activated after initialising the portal (selected); the other one defines the background color of the tool bar – all others are defining a whole set of useful buttons. There are two kinds of buttons: 'PushButton' and 'ToggleButton'. The first returns to its initial condition after being pressed (similar to the Ok-button in a dialog); 'ToggleButton' stays switched on (or off) after clicking and activates a certain tool.

ToggleButtons are 'zoomin', 'zoomout',, 'recenter', 'move' and 'featureinfo'. PushButtons are 'refresh', 'movetoprevious', 'movetonext', 'zoom2layer', 'fullextent', 'addwms', 'print', 'pdfprint', 'download'.

All init parameters, linked to an action/button, have a name consisting of two elements which are divided by '|'. The first one describes the name of the function for the according button. Currently deegree iGeoPortal comprises the following functions:

• refresh: Refresh Map if content has changed

• fullextent: Zoom to full extend

• home: Go to initial state of a map context

• movetoprevious: move to previous map

• movetonext: move to next map

• zoomin

• zoomout

• zoom2layer: zoom to the default bbox of the selected layer (4.9.1)

• featureinfo: Query Feature by click

• move: drag map by mouse click

• recenter: Recenter Map to click point

• addwms: Add other Web Map Services (4.9.2)

• print: Print current extent of Map (4.9.3)

• pdfprint: Print current extent of Map using iReport (4.9.4)

• fullScreen: Switch to a predefined version of the current context with reduced functionality but a much larger Map (4.9.5)

• download:Download WFS data for the selected bounding box as either Shape file or GML (4.9.6).

The functions zoom2layer, addWMS, print, pdfprint, fullscreen and download are configured using separate HTML-files described in the following sub-sections.

The layout of the buttons is defined by two graphic files that have to fulfil the naming convention and have to be placed in the appropriate directory $iGeoPortal_home$/images:

$componentname$.gif and $componentname$_a.gif

Example:

• zoomin.gif and zoomin_a.gif

• addwms.gif and addwms_a.gif

The first file represents the button in inactivate state; the second in its activated one. The file names are case sensitive! In order to change the layout of the buttons, you just have to exchange these 2 graphic files.

1. Zoom2Layer

The function zoom2Layer depends on the two files recentertolayer.html and recentertolayer.js in $iGeoPortal_home$ on the client side and the class org.deegree.portal.standard.wms.control.RecenterToLayerListener on the server side. In order to use this function a single layer has to be selected from the layer list (by clicking the layer name).

The mechanism is as follows: if the selected layer has a LatLonBBox (WMS Capabilities), but no ScaleHint, then the zoom goes to LatLonBBox. If the layer has both LatLonBBox and ScaleHint, it is first checked, if the scale hint reduces the size of the bounding box. If so, the reduced bbox is taken for zoom in. Otherwise, the original LatLonBBox is used to zoom in.

2. AddWMS

Via mouse click on 'addWMS', a dialog is opened for adding additional WMS instances: Either by typing the entire URL or by selecting a preconfigured entry. A list of preconfigured WMS instances can be predefined by the administrator in $iGeoPortal_home$/addwms.html.

...

<td width="30">&nbsp;</td>

<td width="90">known WMS: </td>

<td width="*">

<select id="knownwms" onchange="change()">

<option value="http://">select ...</option>

<option value="http://demo.deegree.org/deegree-wms/services">deegree demo WMS</option>

<option value="http://localhost:8080/deegree-wms/services">local deegree WMS</option>

</select>

</td>

...

By editing the select-block of the HTML document, the administrator is able to manipulate the preconfigured services.

3. Printing

By activating the print-button, the portal generates a representation of the actual map extent in a higher resolution to get high quality printings. By manipulating the parameters in $iGeoPortal_home$/printviewopener.html, the administrator can adapt size and quality of the printouts.

iGeoPortal communicates with the according server components via Remote Procedure Calls (RPCs). They contain the name of the function and potential parameters. In printviewopener.html you can find the JavaScript-function 'getRPCValues()' that provides the appropriate RPC for creating the print preview.

...

var s = "<?xml version='1.0' encoding='UTF-8'?><methodCall>" +

"<methodName>mapView:print</methodName><params>" +

"<param><value><struct>" +

"<member><name>paperFormat</name><value><string>A4</string></value></member>" +

"<member><name>resolution</name><value><string>150</string></value></member>" +

"<member><name>orientation</name><value><string>hoch</string></value></member>"+

"<member><name>format</name><value><string>jpeg</string></value></member>" +

"</struct></value></param>" +

...

The print preview is opened in a new window. Its contents may be adapted by changing the file $iGeoPortal_home$/printview.jsp. The map view is displayed with a lower resolution on screen than what is used for printing. The scaling might be adjusted by changing the style values for img.map width.

<style type="text/css">

@media print {

img.map {

width: 600; /* might need to be adjusted */

}

}

</style>

4. PDFPrinting

Since: v2.2

Description: The PDF printing module uses jasper templates (iReport) to create a PDF file for the current map on the basis of predefined templates. The module comes with two templates, portrait and landscape, but the administrator of iGeoPortal may add further templates, or edit the existing ones if need be. This of course requires some experience with Jasper reports and iReport.

WebMapContext: As the pdfprint module is integrated into the toolbar, the toolbar module needs the "pdfprint" entry:

<!-- PDF PRINT -->

<deegree:Parameter>

<deegree:Name>pdfprint|generate pdf</deegree:Name>

<deegree:Value>PushButton</deegree:Value>

</deegree:Parameter>

controller.xml: This server side module requires one listener, with a large number of self explaining init parameters.

<event name="mapView:pdfprint"
class="org.deegree.portal.standard.wms.control.SimplePrintListener"
next="modules/pdfprint/printresult.jsp"
alternativeNext="modules/pdfprint/printresult.jsp">

<parameter>

<name>WIDTH</name>

<value>500</value>

</parameter>

<parameter>

<name>HEIGHT</name>

<value>500</value>

</parameter>

<parameter>

<name>LEGENDWIDTH</name>

<value>300</value>

</parameter>

<parameter>

<name>LEGENDHEIGHT</name>

<value>1000</value>

</parameter>

<parameter>

<!-- folder where the generated pdf files are stored -->

<name>TEMPDIR</name>

<value>print</value>

</parameter>

<parameter>

<!-- optional parameter; defaults to: "WEB-INF/igeoportal/print" -->

<name>TEMPLATE_DIR</name>

<value>WEB-INF/conf/igeoportal/printtemplates</value>

</parameter>

</event>

Module pages: The following table describes all the files for user interaction in the pdf printing module.

Table 1: PDF print module in $iGeoPortal_home$/modules/pdfprint/

Jasper templates: The jasper templates are stored within the WEB-INF folder of the webapp as they should not be accessible by the portals users directly.

Table 2: Jasper templates for PDF print module in $iGeoPortal_home$/WEB-INF/conf/igeoportal/printtemplates/

If you would want to change the contents or the layout of the PDF result (other than a different map area or scale) you would need to adjust one of the existing templates, or create a new one. But don't forget that you would also need to add/edit the module pages, as they contain the forms to collect the user input for many of the placeholders of the jasper templates. If you add new form fields with different kind of content, you would need to make server side adjustments/extensions as well. Check the SimplePrintListener in package org.deegree.portal.standard.wms.control for details.

Please refer to wmc_testPlayground.xml or wmc_testPdfPrint.xml for testing.

5. FullScreen

Since: v2.2

Description: This module enables to easily switch to a larger map, by hiding both East and West areas (see Figure 3) from the portal. The Map area will change in width only. The displayed section of the map will change as follows: From "normal" view to "full screen" view the width of the displayed area stays the same. But as the available area increases, this automatically causes a zoom in and thus a change in scale. From "full screen" back to "normal" view, the map gets switched back to the original scale and bbox (if the user has not changed the selected map segment by mooving or zooming in/out, while in full screen mode).

WebMapContext: As the FullScreen module is integrated into the toolbar, the toolbar module needs the "fullScreen" entry:

<deegree:Parameter>

<deegree:Name>fullScreen|shows a full screen</deegree:Name>

<deegree:Value>PushButton</deegree:Value>

</deegree:Parameter>

controller.xml: This module requires one listener without any init parameters.

<event name="mapClient:fullScreen"
class="org.deegree.portal.standard.context.control.FullScreenListener"
next="container.jsp" alternativeNext="container.jsp"/>

frontend.xsl: The module needs a new hidden form which is used to switch between normal screen and full screen.

<!-- new form is used to switch from NormalScreen to FullScreen and vice versa -->

<form action="control" id="scaleScreen" name="test" method="post">

<input type="hidden" id="hiddenScaleScreen" name="rpc" value=""/>

</form>

viewcontext.xsl: The module needs to be referenced in the toolbar section of the actionPerformed() method.

<xsl:if test="starts-with( ./deegree:Name, 'fullScreen' )">

switchScreen("mapClient:fullScreen");

</xsl:if>

<xsl:if test="starts-with( ./deegree:Name, 'normalScreen' )">

switchScreen("mapClient:normalScreen");

</xsl:if>

Further, it needs a new function that calles the java script object of this module.

function switchScreen( methodName ) {

var req = new ScreenSwitcher().switchToFullScreen( methodName );

document.getElementById( 'hiddenScaleScreen' ).value = req;

document.getElementById( 'scaleScreen' ).submit();

}

screenswitcher.js: This file contains the actual call of the server side, where the portal gets stripped from its east and west areas (or where they are added back on again).

Please refer to wmc_testPlayground.xml or wmc_testFullScreen.xml for testing.

6. Download for WFS data

Since: v2.3 (bug fixes in v2.4)

Description: This module enables the portal user to download vector data for WFS based WMS layers. Only the data currently visible in the mapview will be made available for download. The user will be informed by email where she can download the data. This is to ensure that the portal does not get blocked while the data is being collected and ziped. Therefore, the user needs to either provide her email address or to log in (then her email address is taken from the users session and the connected security components).

The download module consist of two different parts: The client to request the data, and the servlet providing the means for the actual download. Both parts need to be configured properly.

WebMapContext: First of all, the toolbar module needs the "download" entry:

<deegree:Parameter>

<deegree:Name>download|download WFS data</deegree:Name>

<deegree:Value>PushButton</deegree:Value>

</deegree:Parameter>

Secondly, the General/Extension/IOSettings need to contain the download directory. The name provides the path to the physical location on the mashine, while the access entry provides the base URL of the online resource for downloading.

<deegree:DownloadDirectory>

<deegree:Name>../../downloads</deegree:Name>

<deegree:Access>
<OnlineResource xlink:type="simple"
xlink:href="http://localhost:8080/igeoportal-std" />
</deegree:Access>
</deegree:DownloadDirectory>

controller.xml: Two Listeners and their respective init params need to be set. For <event name="mapView:initDownload"> there are five optional parameters. The first four are necessary, if the portal is used together with the deegree security components (U3R). Then the database driver, URL, username and password need to be provided:

<parameter>

<name>driver</name>

<value>org.postgresql.Driver</value>

</parameter>

<parameter>

<name>url</name>

<value>jdbc:postgresql://localhost:5432/your_users_rights_security_db</value>

</parameter>

<parameter>

<name>user</name>

<value>postgres</value>

</parameter>

<parameter>

<name>password</name>

<value></value>

</parameter>

The fifth parameter may be set to specify which download formats shall be supported. If this parameter is ommitted, then SHP (shape file) will be the only returned format. Supported formats are: SHP, GML. Multiple formats are separated with a colon:

<parameter>

<name>DOWNLOAD_FORMAT</name>

<value>SHP,GML</value>

</parameter>

For <event name="mapView:downloadFeatures" ..> there are two optional init parameters. The first is used as default value for WFS/DefaultMaxFeatures. This value is used, if a WFS does not provide this info in its capabilities. If not specified here, then the default value is 0.

<parameter>

<name>DEFAULT_MAX_FEATURES</name>

<value>10</value>

</parameter>

The second parameter is a boolean (either true or false). If TEST_MAX_HITS is true, then a featuretype is not provided for download, when the number of requested features exceeds the number of features a WFS is able to provide. The default value is false.

<parameter>

<name>TEST_MAX_HITS</name>

<value>false</value>

</parameter>

web.xml: It is necessary to provide a special servlet for the process of downloading the data (after the user received an email):

<servlet>

<servlet-name>Download</servlet-name>

<servlet-class>org.deegree.enterprise.servlet.DownloadServlet</servlet-class>

<init-param>

<param-name>DOWNLOAD_DIR</param-name>

<param-value>./WEB-INF/downloads/</param-value>

</init-param>

<init-param>

<param-name>ALLOWED_IP_ADDRESS</param-name>

<param-value>127.0.0.1</param-value>

</init-param>

</servlet>

It is very important to make sure that DOWNLOAD_DIR corresponds to the folder given in the WMC configuration in the section: General / Extension / IOSettings. The second parameter ALLOWED_IP_ADDRESS may be used to restrict downloads to a certain IP-Address. If ALLOWED_IP_ADDRESS is omitted, any IP-Address will be accepted.

Please refer to wmc_testSecurity.xml for testing.

10. MapView

Description: The module 'MapView' contains the central map view of the portal. Attention: Some JavaScript files are linked to this module.

<deegree:ModuleJS>mapview.js</deegree:ModuleJS>

<deegree:ModuleJS>mapcontroller.js</deegree:ModuleJS>

<deegree:ModuleJS>mapmodel.js</deegree:ModuleJS>

<deegree:ModuleJS>wmsrequestfactory.js</deegree:ModuleJS>

<deegree:ModuleJS>wmslayer.js</deegree:ModuleJS>