Reviewing Topic is almost done. Remaining sections to be updated are

• create parameters explanation sites

Sensor Web Client Installation

Currently there is no pre-built version available. However, having Subversion and Maven installed should be sufficient to fetch and build your own version very quickly.

1. Fetch sources from GitHub
   • Fork (or clone) the code on GitHub: https://github.com/52North/SensorWebClient.git
2. Configuration
   • Configure SOS instances within src/main/webapp/ds/sos-instances.data.xml
   • Copy ${project_root}/sensorwebclient-build-example.properties to ${user.home}/sensorwebclient-build-dev.properties and adjust settings (alternatively, you can configure all properties in the root pom.xml)
3. Build and Install/Deploy
   • Do a mvn clean install -P env-dev to build the client with your custom settings (If you only changed properties within the root pom.xml it is ok to just run mvn clean install.
     • You can have arbitrary setting files laying at ${user.home} using the file pattern sensorwebclient-build-. Doing a mvn clean install -P env-dev -Denv= will build the client using the appropriate settings file
     • See BestPracticeDifferentPropertySetsInMaven for detailed information
   • Deploy the sensorwebclient-webapp/target/sensorwebclient-webapp-3.x.y.war in your servlet engine (e.g. Apache Tomcat)

Configuration

The client has more than one single location where to configure the parameters used by the different components, i.e. server, client, SES, SOS, etc. During further developmen we will keep an eye on reducing these different file locations and invest more and more efforts to clean up some (still) splitted config locations.

Where to configure the parameters differ from either configuring an already built web application or if you intend to build on your own via Maven build tool. Configuration locations are explained below for both production and development.

To give you an overview of the config locations and which parameters to edit, just read on.

Configuration file locations

For production mode you can edit the following files:

SOS Client Configuration

Open file ${webapplication_root}/properties/client-properties.xml.

Parameter	Description	Value/Format
tabs	The tabs section leverages the user to enable/disable core UI components of the client. However, this is a relict from older versions. The mechanism to exchange UI components will be replaced in future versions	DiagramTab and SesTab
defaultInterval	...	...
defaultOverviewInterval	...	...
toasterFadeout	for how long the message box shall show messages before fading away	milliseconds
showStationSelectorAtStartup	if the station selection window shall be shown when client loads	true or false
defaultHydrographStyle	Default styles for the line	1=line, 2=area, 3=dots, 4=dashed
defaultSumLineStyle	Default styles for the sumline	1=line, 2=area, 3=dots, 4=dashed
defaultPhenomenonMappings	style mapping for individual phenomena (syntax: ,,,)	default_style: 1=line, 2=area, 3=dots, 4=dashed; line_or_sumline: line=1, sumline=2, e.g. urn:ogc:def:property:OGC::Temperature,3,1,#FF0000
minTimeFrameZoom	Minimum zoom in the timeframe in the diagram	minutes
mapSrs	Spatial reference system for the client's map windows (as EPSG code)	EPSG:4326
mapUrl	the Web Map Service URL of the map's background layer. Choose OSM to use Open Street Map	WMS URL or OSM
wmsLayerName	the comma separated WMS' layer names (not used when OSM is the chosen as mapUrl)	e.g. layer1,layer2
wmsStyles	...	default
wmsFormat	image format	image/png
wmsIsTransparent	if WMS layers shall be transparent	true or false
wmsBGColor	...	...
defaultExtent	the initial map view (obselete since a selected SOS is auto zoomed)	...

detailed info on parameters configuration will follow

SES Client Configuration

Open file ${webapplication_root}/properties/ses-client.properties. detailed info on parameters configuration will follow

Preconfigured SOS Instances

Open file ${webapplication_root}/ds/sos-instances.data.xml.

Each SOS instance can be configured individually. This not only enables the Sensor Web Client to handle several SOS dialects available. There are also some fine tweaks which allows to better display extent and station retrieval.

Parameter	Description	Example
itemName	Item name of the SOS instance (must be unique)	Weather Stations
url	Service URL	http://localhost:8080/52n-sos-3.5.0/sos/
version	SOS Version	either 1.0.0 or 2.0.0
waterML	Username of the mailing account	either true or false
metadataHandler	The MetadataHandler supporting the SOS dialect	org.n52.server.oxf.util.parser.DefaultMetadataHandler
requestChunk	How many stations should be requested from server side (could be useful when maaaany stations are provided)	300
autoZoom	If the map should zoom automatically to the SOS when selecting it	either true or false
llEasting	"Lower left" longitude of the extent where stations shall be requested	double
llNorthing	"Lower left" latitude of the extent where stations shall be requested	double
urEasting	"Upper right" longitude of the extent where stations shall be requested	double
urNorthing	"Upper right" latitude of the extent where stations shall be requested	double
defaultZoom	Username of the mailing account (Must be within 0-18)	13

detailed info on parameters configuration will follow

Logging Parameters

Open file ${webapplication_root}/WEB-INF/classes/logback.xml. detailed info on parameters configuration will follow

Database Parameters

Open file ${webapplication_root}/WEB-INF/classes/hibernate.cfg.xml. detailed info on parameters configuration will follow

Facade Compression

Open file ${webapplication_root}/WEB-INF/classes/generalizer.properties. Some SOS implementations provide means to generalize observation values (this is not standardized). If you do not configure such an SOS verify that FACADE_COMPRESSION is set to false in the web.xml. If the SOS provides generalization you can configure a generalization method for each observedProperty, like Temperatur=urn:ogc:generalizationMethod:IFGI:douglas-peucker-dynamic-tolerance

Web Application

Open file ${webapplication_root}/WEB-INF/web.xml.

Most parameters in the web.xml are not intended for user configuration. Relevant user configuration parameters has been shifted to other files or have been made unnecessary. Configuring parameters in web.xml is advanced configuration and may mess up your setup. However, configuration of the SES client mail capabilities still remain here and have to be changed directly in the web.xml if the client was downloaded as a pre-built package. If you build the client from Maven please configure mailing from the properties file!

Parameter	Description	Value
DEV_MODE	If application is started in DEV_MODE only a subset of stations are loaded from the SOS to increase startup time during development	boolean
FACADE_COMPRESSION	Tell SOS instance to generalize values (not standard SOS behavior!)	boolean
MAIL_USERNAME	Username of the mailing account	string
MAIL_PASSWORD	Password of the mailing account	string
MAIL_SENDER_ADDRESS	WEmail address of the sender	email
MAIL_SMTP_HOST	SMTP host of the email server the account uses to send emails	SMTP URL
MAIL_STARTTLS_ENABLE	If sending requires TLS security	string
MAIL_PORT	The port used to send emails	int
MAIL_AUTH	If authorization is required at the smtp host	boolean
MAIL_SSL_ENABLE	If SSL shall be used	boolean

Localization

Currently the SensorWebClient ships two languages: English and German. Both are declared within the SensorWebClient.gwt.xml so that the GWT compiler creates dedicated permutations for each language (with English as fallback language). To determine the right display language the client uses the following search order to find the correct locale:

1. Query parameter: if URL contains a 'locale' request parameter, e.g. http://sensorweb.demo.52north.org/sensorwebclient-webapp-3.0.0-rc.2/?locale=de
2. User Agent: using the locale the browser was setup with to requests URLs
3. Using fallback: In this case english is the fallback

Custom Localization

to be done

FAQ

Configuration

Where can I add my own SOS instance?

There is a ds/sos-instances.data.xml file where you can add and configure custom SOS instances. Note that the instance parameter has to be unique.

The Web Frontend does not start when application is installed behind a Proxy/Reverse Proxy. What is wrong here?

Actually, Proxy handling seems to be a GWT problem. There is no appropriate forwarding of incoming requests to the correct web application context. You can solve this issue by configure Proxy/Reverse Proxy Forwarding in Apache Web Server like this

<VirtualHost *:80>
     ServerName www.myservice.com
     ServerAlias www.myservice.com/swe_client
     ProxyPass / http://localhost:8080/
     ProxyPassReverse / http://localhost:8080/
     RewriteEngine on
     Options +FollowSymlinks
     RewriteCond %{REQUEST_URI} !(swe_client/)(.*)
     RewriteRule ^(.*)$ http://www.myservice.com/swe_client/
</VirtualHost> 

However, this solution has limits as it does not allow you to have external links without a subpath, i.e. using just swe_client.myservice.com is currently not possible. If you may find a solution to that, please let use know under sensorweb@52north.org (https://list.52north.org/mailman/listinfo/sensorweb).