Geographic Web Application

University of L Aquila 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 A Java Development Kit (JDK). A standard Java Runtime Environment (JRE) is not sufficient Apache Ant installed and on the PATH

Installation Downloaded the SDK from http://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 map s 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 Suite s 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 tree s 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&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 map s 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, it s 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 manager s 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 process s 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).