University of LAquila

Department of Electrical and

Information Engineering

Geographic Web Application

Enrico Ippoliti

Building complete web

applications
This section discuss how to build

complete web mapping applications

from scratch using the OpenGeo
Webapp SDK as well as OpenLayers

Creating and deploying apps

with OpenGeo Webapp SDK
OpenGeo Webapp SDK provides tools for

building web mapping applications backed by

OpenGeo Suite. The application development
life-cycle are as follows:
Creation- Generating a new template
application
Customization- Adding features and
functionality to the template application
Testing- Deploying the application in a test
mode to verify functionality and debug
Deployment- Deploying the application in a
production environment

Creating and deploying apps

with OpenGeo Webapp SDK
Prerequisites:
OpenGeo Webapp SDK installed. See the
next section for installation details
AJava Development Kit (JDK). A standard
Java Runtime Environment (JRE) is not
sufficient
Apache Ant installed and on the PATH

Installation
Downloaded the SDK

fromhttp://boundlessgeo.com/solutions/
solutions-software/software/
Extract the archive to a suitable location
on the file system
Ensure the SDK bin is on the PATH
To verify the SDK is installed properly
execute the command suite-sdk from a
command prompt

Creating a new application

The SDK comes with an application template that

can be useful for getting started developing with

the Suite. To create a new application based on
this template, run the suite-sdk create command:
suite-sdk create path/to/myapp
In the above command, the app will be called

myapp and will be placed in the path/to/myapp

directory. This directory will contain all required
client-side resources for your application.

Testing the application

The SDK comes with a server that can be used to

debug your application during development. The server

loads all of your JavaScript as individual, unminified
scripts - very useful for debugging in a browser, but not
suitable for production.
Run the following command to launch a server that
loads the application in debug mode:
suite-sdk debug path/to/myapp
This server will publish the app at http://localhost:9080/

. Open this URL in a browser to see your application.

Typing Ctrl-C in the terminal window will shut down the
server.

Deploying the application

Deploying your application is the process of

publishing an application on an OpenGeo Suite

instance. This process will concatenate and
minify all JavaScript resources, and then copy
them to a remote OpenGeo Suite.
To deploy your application to your (remote)
OpenGeo Suite instance, run the following
command:
suite-sdk deploy -d example.com -r 8080 -u
<username> -p
<password> -c <container>
path/to/myapp

Application development with

the Webapp SDK
This tutorial will discuss how to create

an application using the OpenGeo Suite

Webapp SDK.
The full API documentation for the SDK
is available at
http://suite.opengeo.org/opengeodocs/sdk-api/, and is included with this
documentation bundle.

Creating a viewer
The central object in the architecture of

the SDK is the viewer (gxp.Viewer).

Primarily, a viewer combines a map
panel with tools, but it can do much
more.

Creating a viewer
The main configuration options for a

gxp.Viewer are:

Setting up a new project

suite-sdk create /path/to/myviewer
suite-sdk debug /path/to/myviewer

Application details
In the example application, the main component (gxp.Viewer) is created with a single configuration

object, exposing a single global variable named app.

The gxp.Viewer instance is configured to create a viewport filled with a border layout, which has
two items, a container in the west region 200 pixels wide, and the map in the center region.
Please note that all tools in the Client SDK are Ext plugins, so they can be created with a ptype
shortcut in the config, similar to the xtype shortcut for Ext components. This viewer application
defines the following tools:
A Layer Tree, which will be rendered in the west panel defined in the portalConfig.
The Add Layers tool, a button that, when clicked, creates a dialog to add new layers to the map.
This tool will be part of the top toolbar of the layer tree.
The Remove Layer tool, which will be shown both in the top toolbar of the layer tree and in the
context menu of the layer tree. This tool can be used to remove a layer from the map.
The Zoom to Extent tool, which will be shown in the top toolbar of the map. This can be used to
zoom to the maximum extent of the map.
The Zoom tool, which will create two buttons in the map top toolbar, to zoom in and zoom out
with a factor 2 centered on the current map center.
The Navigation History tool, which will create two buttons in the maps top toolbar, to navigate
through visited map extents.

Application details
The viewer configuration defines two layer sources, a

WMS-C (cacheable WMS) source to a local GeoServer

(with the embedded GeoWebCache), and an
OpenStreetMap source. Layer sources are also
implemented as Ext plugins, so configured with a
ptype. The configuration for the map defines the initial
map extent (centered on the USA) and the layers to
load in the map, in this case an OSM base layer and the
usa:states layer from an OpenGeo Suites default
GeoServer setup. (See Proxying GeoServer for how to
link this application to a GeoServer instance.) Finally, a
zoom slider is defined. Note that this can also be done
using mapItems.

Proxying GeoServer
suite-sdk debug -g

http://localhost:8080/geoserver
/path/to/myviewer
suite-sdk debug -g
http://demo.opengeo.org/geoserver
/path/to/myviewer

Proxying GeoServer

Customizing the Viewer

Adding an Add a New Server dialog
Adding a Zoom to Layer Extent tool
Adding a WMS GetFeatureInfo tool
Adding a legend tool
Adding a Google Geocoder search field
Adding a Google base layer
Changing the projection of the viewer
Changing the locale of the viewer

Adding an Add a New Server

dialog
src/app/app.js

Add the following dependency to the top of the file: *

@require overrides/override-ext-ajax.js
Add a proxy to the gxp.Viewer configuration: proxy:
"<PROXY_URL>", substituting the location of the proxy for
<PROXY_URL>. This proxy is necessary to bypass the
Same Origin Policy when accessing remote resources
through JavaScript.
Restart the application. The dialog will be visible after
clicking the Add Layers button. It is titled View available
data from: and contains a list box.
Clicking on the list box and selecting Add a New Server
will enable the user to enter a URL containing a WMS
endpoint. The list of layers available through that endpoint
will then be displayed.

Adding an Add a New Server

dialog

Adding a Zoom to Layer Extent

tool
src/app/app.js
* @require plugins/ZoomToLayerExtent.js
Now find the tools section in app.js and add the
following tool configuration:
{

ptype: "gxp_zoomtolayerextent",
actionTarget: ["tree.tbar", "tree.contextMenu"]
}
The actionTarget property tells the plugin where to
place its buttons. In this case we want it in the top
toolbar of the layertree (tree.tbar), and in the trees
context menu (tree.contextMenu)

Adding a WMS GetFeatureInfo

tool
The ptype for

gxp.plugins.WMSGetFeatureInfo is
gxp_wmsgetfeatureinfo, so we will add
an entry in the tools configuration of
app.js:
{
ptype: "gxp_wmsgetfeatureinfo
}
* @require
plugins/WMSGetFeatureInfo.js

Adding a WMS GetFeatureInfo

tool

Adding a legend tool

The ptype for gxp.plugins.Legend is

gxp_legend. Open up app.js, and

configure this tool:
{
ptype: "gxp_legend",
actionTarget: "map.tbar"
}
* @require plugins/Legend.js

Adding a Google Geocoder

search field
This plugin requires the Google Maps v3

API to be present in the application. Add

the following script tag to index.html in
your app directory:
<script
src="http://maps.google.com/maps/api/js?
v= 3.6&amp;sensor=false"></script>

Adding a Google Geocoder

search field
Now open up app.js again, and add the tool

configuration for this plugin. We want the

geocoder field to show up in the maps top
toolbar:
{
ptype: "gxp_googlegeocoder",
outputTarget: "map.tbar",
outputConfig: {
emptyText: "Search for a location ..."
}
}
* @require plugins/GoogleGeocoder.js

Editing tools
Setting up a feature manager
Setting up a feature editor
Snapping features
Adding a feature grid

Setting up a feature
manager
* @require plugins/FeatureManager.js
Then search for the tools section and add the

following:
{
ptype: "gxp_featuremanager",
id: "states_manager",
paging: false,
layer: {
source: "local",
name: "usa:states"
}
}

Setting up a feature
manager
In the above case the feature manager is

configured with a fixed layer. However, its also

possible to have the feature manager listen to
the active (selected) layer in the layer tree. In
the latter case, the feature manager would be
configured without a layer and with
autoSetLayer set to true:
{
ptype: "gxp_featuremanager",
id: "states_manager",
paging: false,
autoSetLayer: true
}

Setting up a feature
manager
Reloading the application will not show any

visible change. This is because the feature

manager is an invisble tool that can be used
by other tools, such as the FeatureEditor.
However, if we would open up Firebug we
would see two additional requests: a SLD WMS
DescribeLayer request, and a WFS
DescribeFeatureType request for the
configured layer.

Setting up a feature editor

* @require plugins/FeatureEditor.js
Then add the following to the tools

section:
{
ptype: "gxp_featureeditor",
featureManager: "states_manager",
autoLoadFeature: true
}

Setting up a feature editor

Snapping features
Snapping is the act of making features automatically touch when they

are approximately close to each other. When editing, it might make

sense to use snapping. For example, it might make sense to snap to
the states layer, so when digitizing a new state, we make sure it aligns
well with another state.
Open up app.js and add a tool to the tools section to configure a
snapping agent:
{
ptype: "gxp_snappingagent",
id: "snapping-agent",
targets: [{
source: "local",
name: "usa:states"
}]
}
This creates a snapping agent that will load the usa:states data using a
BBOX Strategy and hooking it up with an OpenLayers snapping control.

Snapping features
Now we hook up our feature editor with the snapping agent. Replace

the existing feature editor tool code block from the previous section:
{
ptype: "gxp_featureeditor",
featureManager: "states_manager",
autoLoadFeature: true
}
with the following:
{
ptype: "gxp_featureeditor",
featureManager: "states_manager",
autoLoadFeature: true,
snappingAgent: "snapping-agent
}
* @require plugins/SnappingAgent.js

Adding a feature grid

Open up app.js and edit the items

section of portalConfig by adding a

container in the south region:
{
id: "south",
xtype: "container",
layout: "fit",
region: "south",
border: false,
height: 200
}

Adding a feature grid

Then go to the tools section, and add a

feature grid:
{
ptype: "gxp_featuregrid",
featureManager: "states_manager",
outputConfig: {
loadMask: true
},
outputTarget: "south
}

Adding a feature grid

The grid will still be empty, since the

feature manager only loads a feature in

our current application when there is a
click on the map matching a state. So
go to the feature manager section in
app.js, and add autoLoadFeatures: true
to the feature managers configuration
(gxp_featuremanager):
autoLoadFeatures: true
* @require plugins/FeatureGrid.js

Adding a feature grid

Adding a feature grid

Creating application plugins for

the Webapp SDK
This tutorial will show how to add additional

functionality to applications built using the OpenGeo

Webapp SDK, in the form of plugins. Plugins (also
known as tools) can have actions and/or output. An
action refers to a button or a menu item, while an
output refers to something visible on the screen like
a pop-up window or a panel.
Three examples will be shown:
Plugin with an action
Plugin with an output
Plugin with a combination of action and output
These examples illustrate how to draw a box on a
map and how to query that box.

Creating application plugins for

the Webapp SDK

Plugin with action only

New application setup
To begin, create a new application and
run it in debug mode.
Creating a basic plugin

In the src/app directory inside the

application, create a plugins directory.
In a text editor, create a new file called
DrawBox.js in the plugins directory. This
file will contain the plugin code.
Add the following content to DrawBox.js:

Plugin with action only

Plugin with action only

Connect plugin to application
Now that the plugin has been created, it must be
connected to the application. Open src/app/app.js
and add a dependency at the top:
* @require plugins/DrawBox.js

In the tools configuration section of the file add the

following item to the bottom of the list:
}, {
ptype: "myapp_drawbox",
actionTarget: "map.tbar"
}],

Plugin with action only

Adding functionality
The Draw Box button currently does
nothing, so the next step is to add some
functionality to it. Open DrawBox.js for
editing again. Replace the existing
addActions function with the following:

Plugin with action only

Plugin with action only

The layer that contains the drawn boxes

should always remain visible even when new

layers get added to the map. To accomplish
this, the raiseLayer function is called as a
listener for the addlayer event on the map.
This function calls setLayerIndex to set the
index for the new layer to the highest number
(based on the total number of layers in the
map). This ensures the new layer will be drawn
last, superimposed over any other layers.Add
the following code to the DrawBox.js:

Plugin with action only

Since these functions depend on additional

classes from OpenLayers and GeoExt,
these dependencies must be added to the
top of DrawBox.js:

* @require GeoExt/widgets/Action.js

* @require OpenLayers/Control/DrawFeature.js

* @require
OpenLayers/Handler/RegularPolygon.js

* @require OpenLayers/Layer/Vector.js

* @require OpenLayers/Renderer/SVG.js

* @require OpenLayers/Renderer/VML.js

Plugin with action only

Plugin with output only

Creating a basic panel
The first step is to create a plugin that
outputs some static text. Create a file called
BoxInfo.js in the plugins directory.
Open this file in a text editor and add the
following:

Plugin with output only

Connecting to the application

* @require plugins/BoxInfo.js
Add a container for the output to the items section
of the portalConfig definition in src/app/app.js:
}, {
id: "southpanel",
xtype: "container",
layout: "fit",
region: "south",
height: 100
}],

Plugin with output only

In the tools section, add an entry for the boxinfo tool and direct its output to the
south panel:
}, {
ptype: "myapp_boxinfo",
outputTarget: "southpanel"
}],

Adding dynamic content

To connect this panel to dynamic content, it needs a reference to the vector

boxLayer that is created by the DrawBox tool. This reference is established by
attaching an id to the DrawBox tool in app.js. The BoxInfo tool will then reference
this id value. Add the id to app.js after ptype: "myapp_drawbox" and before
actiontarget: "map.tbar".
}, {
ptype: "myapp_drawbox",
id: "drawbox",
actionTarget: "map.tbar"
}, {

Plugin with output only

Add the reference to the boxinfo config, between

ptype: "myapp_boxinfo" and outputTarget:
"southpanel":
}, {
ptype: "myapp_boxinfo",
boxTool: "drawbox",
outputTarget: "southpanel"
}],

Now, switching back over to BoxInfo.js, replace the

addOutput function of the BoxInfo tool with the
following code. With this change, the application will
depict information about the box that has been
drawn.

Plugin with output only

Plugin with output only

Add the following code below the code

added in the previous step:

Plugin with output only

Plugin with action and

output
Open the DrawBox.js file in a text editor.
Add an event listener to the

DrawFeature control to display a pop-up

containing the area of the box by
replacing the existing control with the
following code.

Plugin with action and

output
Add the displayPopup function to the

DrawBox.js file, which will create the

output in the form of a GeoExt.Popup.
Insert it before the raiseLayer function:

Plugin with action and

output
Add the dependency for the

GeoExt.Popup in the top of the

DrawBox.js file:
* @require GeoExt/widgets/Popup.js
Open app.js and add an outputTarget for
the DrawBox tool, in between id:
"drawbox", and actionTarget:
"map.tbar":

Plugin with action and

output

Building web map applications

with OpenLayers 3

Building web map applications

with OpenLayers 3

Spatial processing and

analysis

Web Processing Service

One powerful method of performing spatial processing is through the Web Processing
Service, or WPS. This OGC-based protocol, analogous to other protocols such as Web
Map Service (WMS) and Web Feature Service (WFS), allows for client-server
interaction with server-hosted processes. A server can provide WPS processes,
which can then be executed by clients on data they supply or applied to existing
server-side datasets.
Processes fall into three categories: vector, raster, and geometry, referring to the
type of geospatial content used as the processs input. These categories are broad,
as processes can take multiple types of input.
WPS is a service published by GeoServer and so is an integral part of the OpenGeo
Suite. It provides a collection of many standard processes along with the ability to
add additional ones. These processes can be employed inside custom applications,
built with the OpenGeo Client SDK, for a full web-based spatial processing solution.
For example, one can run the JTS:union process on a collection of geometries to
output a single geometry that is the union of them. Processes can be chained, so one
can run the gs:Reproject process to reproject a raster image to a different SRS, then
take the output of that and run gs:CropCoverage to crop the raster down to a certain
bounds. The result can be fed into the gs:Import process to save the resulting
coverage as a new layer in GeoServer, for use by other clients.

Spatial processing and

analysis
SQL Views

Another way to perform spatial processing is by using the

SQL Views functionality in GeoServer. When backed by
the powerful capabilities of a database such as PostGIS,
SQL Views provide an effective way to transform and
analyze spatial datasets. Using a SQL View, a layer can
be defined as the result of a spatial query on a PostGIS
dataset. This layer can then be visualized by WMS,
queried via WFS, and even used in further processing
operations. Spatial queries in PostGIS support a wide
variety of spatial processing, including data
transformation, spatial analysis, and even raster
processing (OpenGeo Suite 3.0 / PostGIS 2 and newer).